Deposits are everywhere in business. A customer wants custom work? You ask for money up front. A vendor has a long lead time? They want a check before they start. The question is how your ERP handles that money between the day it moves and the day the real invoice posts.
Welcome to Round 35 of our Dynamics GP vs. Dynamics Business Central: Functionality Face-Off series. Today we look at prepayments on orders — and a difference in philosophy that shows up the moment you ask for a deposit.
Here’s the short version. GP records the money: a deposit field on a sales order, a prepayment check on a purchase order. Business Central invoices the deposit: it creates an actual prepayment invoice document, tracks whether it’s been paid, and can refuse to ship until it is.
How you do it in Dynamics GP
GP handles the two sides of prepayments in two different ways.
On the purchasing side, GP has real PO prepayment functionality, described in Microsoft’s Purchase Order Processing guide:
- Turn it on. In Purchase Order Processing Setup (Purchasing >> Setup >> Purchase Order Processing), mark Allow Purchase Order Prepayments, set an optional password, and assign the prepayment posting account.
- Enter the prepayment on the PO. When you create the purchase order, fill in the Prepayment field at the bottom. One prepayment per PO — and the amount can’t exceed the line totals, so freight and tax can’t be prepaid.
- Cut the check. For a computer check, build a payables batch and mark it as a Purchasing Prepayment Batch; GP pulls in the PO prepayments, prints the checks, and posts them. A manual payment posts when you save the PO.
- Receive and invoice. When you receive or invoice against the PO, the posted prepayment applies automatically and reduces what you owe. If money is left over, it sits as an unapplied payment — and the PO must be closed or canceled before you can apply it to anything else.
On the sales side, there’s less machinery. Sales Order Processing lets you record a deposit in the Amount Received field when you enter the order. That works fine when the customer hands you money. But notice what’s missing: GP never produces a document that asks for the deposit. If your process is “invoice the customer 30% up front,” you’re building that invoice outside the system — and remembering on your own which orders still owe you a deposit.
How you do it in Business Central
Business Central treats a deposit as what it really is: an invoice. The flow is laid out in Microsoft’s prepayment setup and prepayment invoicing guides.
- Set it up once. Assign prepayment posting accounts in the general posting setup and number series for prepayment documents. Then set default prepayment percentages where they belong: 30% on a customer’s card, 20% on an item, or a specific rate for one customer buying one item. Vendors work the same way for purchases.
- Create the order. When you enter a sales order for that customer, the prepayment percentage fills in automatically. You can override it per line, set one percentage for the whole order, or type an exact prepayment amount in the order statistics.
- Post the prepayment invoice. Choose Actions > Posting > Post Prepayment Invoice. BC creates a real posted invoice you can print or email to the customer — a document with a number, a due date, and payment terms of its own. The order status changes to Pending Prepayment.
- Let the system enforce it. Turn on Check Prepayment when Posting in Sales & Receivables Setup, and BC will not ship or invoice an order until its prepayment invoice is paid. No sticky notes, no memory required.
- Finish the order. When you post the final invoice, BC deducts the prepaid amount automatically. Customer adds items after the deposit? Post another prepayment invoice for just the difference. Need to undo one? Post a prepayment credit memo.
The same flow works in purchasing: the vendor’s percentage defaults onto the purchase order, you post a prepayment invoice, pay it like any vendor invoice, and the final invoice arrives with the prepayment already netted out.
Side by side
| Dynamics GP | Business Central | |
|---|---|---|
| Sales-side deposit | Amount Received field on the order | Posted prepayment invoice sent to the customer |
| Document requesting the deposit | None — handled outside the system | Real invoice with number, terms, and due date |
| Default deposit rules | None — entered per transaction | Percentages on customer, vendor, or item cards |
| Purchase prepayments | One per PO, capped at line totals | Percentage or amount, per line or whole order |
| Enforcement | Manual — staff must remember | Optional block on shipping or invoicing until paid |
| Order changes after deposit | Leftover sits unapplied until PO closes | Additional prepayment invoice for the difference |
| Undoing a prepayment | Void and reapply in Payables | Prepayment credit memo |
| Taxes and freight | Can’t be prepaid on a PO | Included in the prepayment calculation |
Why BC comes out ahead
GP’s PO prepayment feature is genuinely useful — it ties the check to the PO, applies it at receiving, and rides along with the normal check run. For the “vendor wants money before they ship” case, it does the job.
But prepayments are really an accounts receivable problem too, and that’s where GP runs out of road. There’s no deposit invoice to send a customer, no default percentages, and nothing stopping a shipment that hasn’t been paid for. The process lives in your team’s discipline.
Business Central makes the deposit a first-class document on both sides of the house. The percentage defaults from the card, the invoice posts and emails like any other, the order literally waits in Pending Prepayment status, and the final invoice nets everything out. When the rules live in the system instead of in someone’s head, deposits stop leaking.
Thinking about the move?
Aisling Dynamics helps GP users bring processes like this into Business Central every day — including the ones GP made you handle by hand. Learn more about what we offer, or contact us at (251) 293-0555 to talk through how your deposit workflow would look in BC.
Next round: landed cost — GP’s Landed Cost module vs. BC item charges.