Sales and purchasing in Business Central

The sales and purchasing modules are where most day-to-day Business Central users spend their time. Both follow the same document-driven pattern — quote → order → shipment/receipt → invoice → posting — which keeps the system consistent and easy to learn. Understand the pattern once and you understand half the application: the same logic that turns a sales order into a posted shipment turns a purchase order into a posted receipt, a transfer order into a transfer shipment, and a return order into a reversal.

Sales (order-to-cash)

Sales starts with a customer card carrying credit terms, prices, currency, and posting groups — see payment terms and methods for how the terms themselves are configured, and customer hierarchies for modelling parent-child customer relationships on top. From there, salespeople create sales quotes, which convert to sales orders once accepted. Orders can be partially or fully shipped (creating posted shipments and inventory transactions), and partially or fully invoiced (creating posted invoices and ledger entries). Standalone sales invoices and credit memos exist for transactions that don't need order tracking. Sales and purchase returns are handled through return orders that reverse inventory and value, with exact cost reversal keeping the GL and inventory value straight on both sides.

Two document types deserve more attention than they usually get. Blanket sales orders hold a negotiated quantity over a period and release call-off orders against it — the right tool for contract customers, and much cleaner than cloning orders month after month. Drop shipments and special orders link a sales line directly to a purchase line, so goods ship from your vendor to your customer without touching your warehouse; the requisition worksheet picks these up and creates the linked purchase orders for you.

Pricing and discounts

Pricing is driven by price lists, customer-specific prices, line and invoice discounts, and customer/item discount groups. The practical guidance: keep the structure as flat as you can. Every layer of customer-specific pricing you add is a layer someone has to maintain and a layer that makes "why did this order get that price?" harder to answer. Line discounts and invoice discounts also post differently — see the line vs invoice discount comparison before you design salesperson commission or margin reporting around them.

Purchasing (procure-to-pay)

Purchasing mirrors sales: vendor cards, purchase quotes, purchase orders, partial receipts and invoices, and posted credit memos for returns. The requisition worksheet plans purchases based on demand from sales, projections, or minimum stock, suggesting POs to release. A built-in vendor item catalog lets you map your item numbers to a vendor's, and price/discount agreements can be time-bounded.

Item charges are the piece new implementations most often miss: freight, duty, and insurance invoices can be allocated across received lines — by amount, quantity, weight, or volume — so landed cost actually lands in inventory value rather than sitting in a freight expense account distorting margins. If your business imports, set this up on day one; retrofitting correct landed cost after months of posting is painful.

The gap between "received" and "invoiced" matters in purchasing more than people expect. Goods received but not yet invoiced sit in the GR/IR-style interim accounts defined by posting setup, and month-end close includes reconciling them. Three-way match — order, receipt, invoice — is the default behaviour, not an add-on.

Approvals

Both sides support workflow-driven approvals — sales quotes over a threshold, purchase orders over a vendor limit, customer credit-limit overrides — configured in the workflow designer and routed through users or roles. Approvers can act from Outlook, Teams, or the web client. Keep approval chains short: every additional mandatory approver is a place where an order sits still. The most successful setups approve on the exception (over threshold, new vendor, credit override), not on every document. For deeper chains and delegation rules, see approval workflows in Business Central, and for how the per-user limits and routing hierarchy behind those thresholds are actually configured, approval limits and hierarchies.

Documents and reporting

Posted documents are immutable and can be reprinted, emailed, or sent as PDFs — and increasingly as e-invoices where the country localization or an ISV connector supports the local format. Each posted document writes to the relevant vendor ledger, customer ledger, item ledger, and value entry tables, which are the foundation for AR/AP ageing, sales analytics, and inventory valuation. Immutable doesn't mean unfixable — see reverse and undo for the supported ways to correct a wrongly posted shipment, receipt, or invoice rather than reaching for a manual journal. Vendor invoices themselves usually arrive as a document to file against the purchase, which is what incoming documents handles, and adjustment postings on either side typically carry a reason code so the "why" survives in the ledger, not just the "what".

Where implementations go wrong

Three patterns account for most of the mess we see in running systems. First, posting groups configured in a hurry: general business and product posting group combinations decide which GL accounts every sale and purchase hits, and untangling a wrong mapping after a year of posting is a project. Second, open orders never closed: partially shipped orders that will never complete should be closed, or they haunt the planning engine and the order lists forever. Third, using invoices where orders belong — standalone invoices skip inventory reservation and warehouse handling, which is fine for services and fatal for stocked goods.

Get the document flow, posting groups, and item charges right at the start, and sales and purchasing in Business Central largely runs itself; the daily work becomes exceptions and approvals rather than data entry.