Yesterday we entered a sales order. Today the goods go out the door and the customer owes us money. Simple, right?
In Business Central, yes — it’s one button on the order. In Dynamics GP, the order has to become a different document first. GP calls it transferring, and there’s an entire chapter of Microsoft’s documentation devoted to how it works. Round 16 of the Face-Off is about the step in the middle: getting from “they ordered it” to “they owe us for it.”
How You Do It in Dynamics GP
In GP’s Sales Order Processing module, an order and an invoice are two different document types. An order can’t be posted — only invoices (and returns) post. So when it’s time to bill, GP moves your lines from the order onto a brand-new invoice document. Microsoft’s Sales Order Processing Part 4 documentation covers this in Chapter 27, “Transferring documents.”
Step 1: Make sure the transfer is allowed. Before anything moves, GP checks the setup: the order’s Type ID must have transfer options marked in Sales Order Processing Setup, the document needs a batch ID, there must be quantities available to transfer, and if you use approval workflows, the document must be approved. Orders can transfer to invoices and back orders — that routing was decided when the Type ID was configured.
Step 2: Choose Transfer. From the Sales Order Transactions list (or the Sales Transaction Entry window), select the order and choose Transfer. This opens the Sales Transfer Documents window.
Step 3: Answer the transfer questions. Which document types are you transferring to? Should GP transfer deposits, freight, and miscellaneous charges too? (That’s the Include Totals and Deposits checkbox — easy to miss, and your freight charge stays behind if you do.) And once again, our old friend from Round 15: quantity shortage options. If items aren’t fully allocated, you decide how the shortfall is handled — often by spinning the unshipped quantity onto a new back order document.
Step 4: GP creates a new document. The invoice gets its own number from the invoice Type ID’s numbering — so order ORD10234 becomes invoice INV20567. Anyone tracing the sale later follows the breadcrumb trail from quote to order to invoice, each with a different number.
Step 5: Post the invoice. The invoice now sits in a batch until someone posts it. Then the customer balance, inventory, and General Ledger update.
GP shops run this cycle every day, and it works. But notice how much of it is decisions: transfer options, totals and deposits, shortage handling, batch IDs. And notice what you end up with — more documents, each holding part of the story.
How You Do It in Business Central
Business Central doesn’t transfer anything, because it doesn’t need to. The sales order itself does the whole job. Microsoft’s guide to posting sales documents shows the entire flow:
Step 1: Open the order and choose Post. On the Posting menu you get Post, Post and New, Post and Send — which emails the customer a PDF as it posts — plus Preview Posting if you want to see every ledger entry before committing, and Post Batch to run a stack of orders at once.
Step 2: Choose what’s happening. BC asks one question: Ship, Invoice, or Ship and Invoice? Shipping records that goods left the building. Invoicing records that the customer owes you. Do both at once, or ship today and invoice at month-end — your call.
Step 3: Partial? Just type the quantity. Ordered 100, shipping 60? Set Qty. to Ship to 60 and post. The order stays open, tracking what’s left, and BC won’t let you invoice more than you’ve shipped — the guardrail is built in, per Microsoft’s sales order guide. No back order document is created because none is needed; the remaining 40 simply stay on the same order.
Step 4: The paper trail builds itself. Posting creates a posted sales shipment and a posted sales invoice, both linked to the order. One order number ties the whole story together. And if someone shipped by mistake, Undo Shipment reverses it cleanly — as long as it hasn’t been invoiced.
One document. One Post button. One trail.
Side by Side
| Dynamics GP | Business Central | |
|---|---|---|
| Order becomes an invoice by | Transferring to a new invoice document | Posting the order itself |
| New document numbers | Yes — invoice gets its own number | No — shipment and invoice link to the order |
| Partial shipment | Transfer creates a back order document | Type the Qty. to Ship and post |
| Deposits, freight | Transferred only if you mark Include Totals and Deposits | Stay on the order automatically |
| Shortage handling | Shortage options asked again at transfer | Remaining quantity stays on the open order |
| Email the invoice | Print, then send separately | Post and Send in one action |
| Batch of orders | Transfer and post by batch | Post Batch |
| Oops, wrong shipment | Reverse statuses, correct documents | Undo Shipment (if not yet invoiced) |
Why BC Comes Out Ahead
GP’s transfer step exists because its document types are separate containers, and moving between them takes rules, options, and new numbers. None of that is your customer’s problem — they just want their stuff and a correct bill. Business Central collapses the middle step entirely: the order ships and invoices itself, partially or fully, and the history stays stitched to one document.
That’s fewer decisions per sale, fewer places for freight and deposits to fall off, and a much shorter answer to the question every AR person gets: “what happened with this order?” In GP, the answer is a trail of document numbers. In BC, it’s one page.
Thinking About the Switch?
Aisling Dynamics keeps GP transfer workflows humming and moves teams to Business Central when the document shuffle stops earning its keep. If your order desk is ready for the one-button version, learn about our team, visit our GP vs. BC hub, or contact us at (251) 293-0555.
Come back tomorrow for Round 17: shipping in depth — GP fulfillment orders vs. BC posting shipments now and invoicing later.