
In Round 16 we turned a sales order into an invoice. But we skipped over something real: the warehouse. Orders don’t ship themselves. Somebody picks the items, packs the box, and puts it on a truck — and your ERP needs to know that happened, ideally without holding up the billing.
That’s today’s Face-Off: how Dynamics GP and Business Central handle the gap between “it left the building” and “we billed for it.” The two systems think about that gap very differently.
How You Do It in Dynamics GP
GP’s Sales Order Processing module offers two levels of shipping, depending on how deep your setup goes. Both are covered in Microsoft’s Sales Order Processing documentation.
The everyday version: paperwork from the order. For many GP shops, shipping is driven by printed documents. You print a picking ticket so the warehouse knows what to pull, and a packing slip to go in the box. When the goods go out, someone transfers the order to an invoice — the step we walked through in Round 16 — and posts it. The catch: GP doesn’t really have a “shipped but not yet billed” state for the order itself. The shipment is recorded by making the invoice. If you ship today and bill at month-end, the order just sits there in between, and your inventory and paperwork drift apart until someone does the transfer.
The advanced version: fulfillment orders. If you turn on GP’s sales fulfillment workflow, you get a sixth document type — the fulfillment order. Sales information transfers from a quote, order, or back order to a fulfillment order, which then moves through workflow statuses as the warehouse confirms picking and packing. GP tracks each status change (behind the scenes, every step writes a record — GP admins know them by table name, SOP10112). When the workflow completes, the fulfillment order becomes an invoice, ready to post. Add Advanced Picking, and large warehouses can print bulk picking tickets across orders.
It’s a genuinely capable system. But notice the shape of it: shipping visibility requires its own document type, its own workflow setup, and its own transfers. The simple version has no shipped state; the powerful version adds moving parts.
One more wrinkle: one order, one invoice. However you get there, each GP invoice traces back through its own transfer chain. Shipping one order in three waves generally means juggling back orders or multiple invoices — and consolidating a month of shipments onto one bill isn’t a built-in button.
How You Do It in Business Central
Business Central treats shipping and invoicing as two independent events on the same order — no extra document type required.
Step 1: Ship what shipped. Open the sales order, set Qty. to Ship on each line (all or partial), choose Post, and pick Ship. BC creates a posted sales shipment — a permanent record that goods left — while the order stays open with nothing billed yet, per Microsoft’s posting sales guide. Warehouse teams can print the shipment documents, and if your operation is bigger, BC’s warehouse features handle picks and put-aways — but none of that is required just to record a shipment.
Step 2: Invoice when you’re ready. Bill the same order later by posting Invoice, or build the bill from the shipments themselves: create a sales invoice, choose Get Shipment Lines, and pull in exactly the shipment lines you’re billing, as described in Microsoft’s combine shipments article. Every line stays linked to its shipment, so the audit trail survives.
Step 3: Or let BC build the invoices for you. Ship a customer ten times a month and bill once? Flag Combine Shipments on the customer card, and the Combine Shipments batch job sweeps every posted-but-uninvoiced shipment into one invoice per customer — it can even post them automatically. The field Qty. Shipped Not Invoiced tracks exactly what’s still waiting to be billed, so nothing falls through the crack between the warehouse and accounting.
Shipping is a posting choice. Invoicing is a separate posting choice. Everything in between is visible.
Side by Side
| Dynamics GP | Business Central | |
|---|---|---|
| Recording a shipment | Print paperwork, then transfer to invoice — or run fulfillment workflow | Post Ship on the order |
| “Shipped, not billed” state | Not really — invoice is the record (unless using fulfillment orders) | Built in: posted shipments + Qty. Shipped Not Invoiced |
| Extra document types | Fulfillment order (requires workflow setup) | None — same order throughout |
| Partial shipments | Back orders and transfers | Qty. to Ship, post, repeat |
| Bill many shipments at once | Manual consolidation | Get Shipment Lines or Combine Shipments batch job |
| Monthly billing customers | Juggle documents | Combine Shipments toggle on the customer card |
| Warehouse depth | Advanced Picking with setup | Warehouse features, optional by location |
| Undo a mistake | Correct through document chain | Undo Shipment (before invoicing) |
Why BC Comes Out Ahead
GP makes you choose between simple-but-blind and powerful-but-heavy. Without fulfillment workflow, there’s no clean shipped-not-billed state; with it, you’re maintaining another document type and its statuses. Business Central gives every company the middle path by default: every shipment is a posted record the moment it happens, billing happens whenever billing should happen, and the system tracks the gap for you.
And Combine Shipments is the quiet win for anyone who bills monthly. What takes document juggling in GP is a checkbox and a batch job in BC — one clean invoice per customer, every line still traceable to its shipment.
Thinking About the Switch?
Aisling Dynamics helps GP warehouses run tight fulfillment workflows, and helps companies move to Business Central when ship-now-invoice-later should just be how the system works. If your warehouse and your billing are drifting apart, learn about our team, visit our GP vs. BC hub, or contact us at (251) 293-0555.
Come back tomorrow for Round 18: the plain sales invoice — billing without an order in GP vs. BC.