Purchasing Management in Business Central

Purchasing is where an ERP earns its keep or quietly leaks money, and in my experience the difference is rarely the software. Business Central ships with a genuinely capable procure-to-pay engine: structured vendor records, a clean document flow from quote through order to invoice, a pricing layer that handles negotiated prices and line discounts, planning worksheets that turn demand into suggested purchases, and matching and approval controls that stop unauthorised or incorrect spend before it hits the ledger. The trouble is that most of these controls are optional, so a lightly configured Business Central will happily let a buyer raise a purchase order for anything, receive whatever arrives, and post an invoice that nobody checked. This guide walks the whole process the way it actually runs, and points out where the controls live so the system protects you rather than just recording what happened.

The message up front: procure-to-pay in Business Central is a chain of linked documents that carry data forward so you never rekey it. The quote becomes the order, the order drives the receipt, the receipt and order together validate the invoice, and the invoice becomes a payable that finance settles. When that chain is intact and the matching and approval controls are switched on, purchasing is fast and safe. When people short-circuit the chain, posting invoices directly without orders and receipts, you lose every control the platform gives you. The skill is keeping the chain intact without making it bureaucratic.

1. The procure-to-pay process at a glance

Before drilling into individual documents, it helps to see the whole arc, because every screen in Business Central purchasing is a station on the same track. Procure-to-pay, sometimes called P2P, is the end-to-end journey from recognising that you need something to paying the supplier who provided it. In Business Central that journey has a natural sequence, and each step creates a record the next step relies on.

At the highest level the flow runs like this: a need is identified, either manually by a buyer or automatically by the planning engine; a vendor is selected from the vendor list; optionally a request for quotation goes out and a purchase quote comes back; a purchase order is created and, if approvals are configured, routed for authorisation; goods or services are received against that order, which posts a receipt and updates inventory; the vendor's invoice arrives and is matched against the order and the receipt; the invoice is posted, creating an entry in the vendor's payables; and finally a payment is issued and applied to that invoice, closing the cycle. Every one of those steps is a document or a posting in Business Central, and the data flows forward automatically so the buyer keys the requirement once and the rest is carried through.

The reason this sequence matters is that Business Central lets you skip steps, and skipping the wrong ones costs you control. You can post a purchase invoice with no order behind it. You can receive and invoice in a single posting. Those shortcuts are legitimate for some scenarios, a taxi fare, a one-off service, but treat them as exceptions, not the norm. The full chain is what gives you the audit trail, the accruals, and the matching. For where purchasing sits inside the wider platform, the complete guide to Business Central features maps how procurement, inventory, finance and warehousing connect.

2. Vendor management: vendor cards, terms and bank details

Everything in purchasing starts with the vendor, and the vendor card is the master record that every purchase document inherits from. Get the vendor card right and every order, invoice and payment for that supplier is easier and more accurate. Get it wrong and you spend the rest of the relationship correcting the same defaults on every document.

A vendor card in Business Central carries far more than a name and address. The fields that actually shape day-to-day purchasing are the defaults and the posting setup. Payment terms tell the system when an invoice is due and whether an early-settlement discount applies, so entering "30 days net" once means every invoice for that vendor calculates its due date automatically. The payment method records how you normally pay them, bank transfer, cheque, direct debit. The currency code sets the default transaction currency, which matters enormously for overseas suppliers because it drives exchange-rate handling. Gen. business posting group and VAT business posting group control which general-ledger and tax accounts the vendor's transactions post to, and these are the fields that quietly cause the most trouble when they are wrong, because they route money to the wrong accounts silently.

Bank account details live on the vendor's bank account records, linked to the card. For any organisation paying by electronic transfer this is critical data: the IBAN, the SWIFT or BIC code, the account number and the bank branch. Business Central can generate payment files from these details, so an error here becomes a misdirected payment. This is exactly the kind of master data that deserves a change-control discipline, because a fraudster changing a vendor's bank details is one of the most common and most damaging finance frauds, and the platform will faithfully pay whatever bank account is on file.

The caution on vendor bank details: treat changes to vendor bank accounts as a controlled event, not routine data entry. A common attack is an email that appears to come from a supplier asking to update their bank details before the next payment run. Business Central does exactly what the record says, so the control has to sit in your process: verify the change through a known contact, keep the change log, and separate the person who edits bank details from the person who releases payments. The system will not save you here; your procedure has to.

Beyond the essentials, vendor cards support useful controls: a blocked field that can stop new orders, payments, or all activity for a vendor; a purchaser code that ties the vendor to a responsible buyer; and location and shipping defaults. Vendors can also be grouped and posted through vendor posting groups that map to the correct payables control accounts. Spend the time to standardise these once, because the vendor card is the single most reused record in the whole purchasing module.

3. Purchase quotes, orders, invoices and credit memos

Business Central models the buying process as a set of related purchase documents, and understanding what each one does, and how they hand off to one another, is the core of using the module well. They all share the same shape, a header carrying vendor and terms, and lines carrying what you are buying, but they play different roles in the flow.

• Purchase quote: the earliest document, used when you are still negotiating and want to record a vendor's offered prices without committing. A quote has no accounting impact and does not touch inventory. When you accept it, Business Central converts the quote directly into a purchase order, carrying the lines and prices forward, so nothing is rekeyed. Quotes are optional; many buyers go straight to an order for routine purchases.
• Purchase order: the commitment. This is the workhorse document. It records what you have agreed to buy, from whom, at what price, for delivery to a given location by a given date. It is also the document you receive against and invoice against, which is what makes three-way matching possible. A purchase order stays open, and visible as a commitment, until it is fully received and fully invoiced, at which point it moves to the posted history.
• Purchase invoice: records the vendor's bill. It can be created independently, for a purchase with no order behind it, or, better, generated from the receipt of a purchase order so it inherits the received quantities and agreed prices. Posting a purchase invoice creates a vendor ledger entry, the payable that finance will later settle, and posts the cost and tax to the general ledger.
• Purchase credit memo: the reverse of an invoice, used when you return goods or a vendor over-charges you. It reduces what you owe the vendor and reverses the inventory and cost effect. A related document, the purchase return order, handles the physical return of goods and can produce the credit memo, keeping the return flow parallel to the buying flow.

The elegance of this design is the handoff. A quote becomes an order with one action. An order produces a receipt when goods arrive and an invoice when the bill comes in, and because both post against the same order, the order line knows how much has been received and how much invoiced. You can partially receive and partially invoice, and Business Central tracks the outstanding balance on each line. That running balance is what lets a buyer see, at a glance, what has been ordered but not yet delivered, which is one of the most valuable operational views the module offers.

4. Purchase pricing, discounts and the pricing experience

Entering a price by hand on every line is fine for a business that buys occasionally, but any operation with negotiated supplier agreements needs prices to fill themselves in correctly and consistently. Business Central handles this through its purchase pricing and discount capabilities, and modern versions consolidate this into a price-list-based experience.

The idea is straightforward: you record the prices and discounts you have negotiated with each vendor once, and the system applies them automatically when you create purchase lines. A negotiated unit cost for a particular item from a particular vendor drops onto the order line the moment you enter that item. Prices can be made specific to a vendor, to a group of vendors, or apply more broadly, and they can be date-bound so a price agreement that runs for a quarter automatically stops applying when it expires. They can also vary by quantity, so a higher volume unlocks a better unit cost, which is exactly how real supplier agreements are structured.

Two kinds of reduction exist and it is worth keeping them straight. A negotiated purchase price sets the unit cost itself, the number on the line. A line discount is a percentage taken off that line, recorded separately so both the gross price and the discount are visible. On top of line discounts, an invoice discount can apply a reduction to the whole document once it passes a value threshold, which models the common "spend over a certain amount and get a percentage off the order" arrangement. The distinction matters at reporting time, because a discount recorded as a discount can be measured, whereas a discount buried in a hand-keyed net price is invisible to procurement analytics.

The insight on pricing discipline: the value of the pricing engine is not that it saves keystrokes, it is that it makes your negotiated agreements enforceable and measurable. When prices come from recorded agreements, a buyer cannot accidentally pay above the agreed rate, and procurement can report on realised savings, price variance and discount capture. When prices are hand-keyed, none of that is possible and you are trusting each buyer's memory and honesty on every line. Configuring supplier prices properly is one of the highest-return, lowest-glamour tasks in a Business Central purchasing setup.

A practical note: the pricing experience has evolved across Business Central versions, moving from separate price and discount tables toward a unified price list model. If you are working on a recent version you will find price lists that hold both prices and discounts together, with the older structures still supported for continuity. Whichever you are on, the functional goal is identical: record what you negotiated, and let the system apply it so people cannot drift away from the agreement.

5. The requisition worksheet and supply planning

So far the buyer has been deciding manually what to purchase. For anything held in inventory, Business Central can do that thinking for you, and the requisition worksheet is where that planning surfaces as concrete purchase suggestions. This is one of the features that separates an ERP from a glorified order-entry system.

The requisition worksheet looks at the demand for items, the sales orders, service demand, and forecasts, and at the supply you already have, on-hand inventory and open purchase orders, and at the planning parameters on each item, and it calculates what you need to buy and when. The planning parameters live on the item card and drive the whole calculation: the reorder point, the reorder quantity or the target maximum inventory, the safety stock, the vendor lead time, and the reordering policy that says whether to replenish to a fixed quantity, to a maximum level, or lot-for-lot to exactly cover demand. Set those correctly and the worksheet produces a clean list of what to order, from which vendor, in what quantity, by when.

The buyer's job then becomes reviewing and accepting suggestions rather than calculating requirements from scratch. You run the worksheet, look at the suggested purchase lines, adjust anything that judgement says needs adjusting, and then carry the accepted suggestions out, which creates the actual purchase orders in a single action, grouped sensibly by vendor. For an operation stocking spare parts, consumables or components, this turns replenishment from a manual chore prone to stockouts and overstocking into a repeatable, parameter-driven routine. How well it works depends entirely on the quality of the item planning data, which is why inventory setup and purchasing planning are two sides of the same coin. The inventory management deep-dive covers those item planning parameters in detail, and they are the input this worksheet depends on.

A related tool, the planning worksheet, extends the same idea to manufacturing and more complex supply networks, balancing demand and supply across production, transfers between locations, and purchasing together. For a purely purchasing-focused operation the requisition worksheet is the one you live in, but it is worth knowing the planning worksheet exists for when supply chains get more layered.

6. Receiving goods and the warehouse connection

When goods arrive, receiving them against the purchase order is the step that updates inventory and creates the receipt half of the matching trio. How this works depends on how much warehouse sophistication you have enabled, and Business Central scales from very simple to quite advanced.

In the simplest configuration, a user opens the purchase order, enters the quantity that actually arrived on each line, and posts a receipt. That posting increases inventory, records who received what and when, and stamps the order lines with the received quantity so the outstanding balance drops. If the full quantity arrived, the line is fully received; if only part arrived, the line stays partly open and the rest remains an expected receipt. This direct-on-the-order receiving is perfectly adequate for many businesses and keeps the process lightweight.

As warehouse needs grow, Business Central offers dedicated warehouse documents that separate the physical receiving from the accounting. With inventory put-away or warehouse receipt documents enabled on a location, the goods-in team works from a warehouse-specific document, records the physical arrival, and directs stock to bin locations, while the link back to the purchase order is preserved so the financial receipt still ties to the order. At the highest tier, with directed put-away and pick enabled, the warehouse runs bin-level control, with the system directing where each received item should be placed. The right level depends on the operation: a small stores function does not need directed put-away, and a large distribution centre cannot run without it.

The important principle across all of these is that the receipt is what converts a promise into an asset. Until you post the receipt, the purchase order is an expectation. After you post it, the inventory is real, the cost is captured, and the receipt document becomes the physical-evidence leg of three-way matching. That is why disciplined, prompt receiving matters so much: an invoice cannot be properly matched until the receipt it should match against actually exists. For the full picture of receiving, put-away, bins and the physical flow, see the dedicated warehouse management deep-dive, which picks up exactly where this section leaves off.

7. Three-way matching: order, receipt and invoice

Three-way matching is the single most important financial control in purchasing, and it is the reason the whole document chain is worth keeping intact. The principle is simple: before you pay a vendor's invoice, three documents must agree. The purchase order says what you agreed to buy and at what price. The receipt says what you actually received. The invoice says what the vendor is billing you for. When all three line up, on quantity and on price, the invoice is safe to pay. When they disagree, something needs investigating before money moves.

In Business Central this works because the invoice is created from, or matched to, the purchase order and its receipts. When you generate a purchase invoice from a received order, it pulls the received quantities and the ordered prices onto the invoice, so by construction it matches. When a vendor sends an invoice that differs, more units than were received, or a higher unit price than the order agreed, that discrepancy becomes visible instead of quietly being paid. The receipt leg is what stops you paying for goods that never arrived, and the price leg is what stops you paying more than you agreed.

Business Central supports this at the practical level in a few ways. Quantities carry forward from receipt to invoice so a quantity mismatch is apparent. Prices carry forward from the order so a price mismatch is apparent. For organisations that want a formal control, item charge and cost handling let landed costs be attributed accurately, and tolerance settings can define how much variance is acceptable before a mismatch has to be resolved. The depth of automated enforcement varies by version and configuration, and this is one area where I always advise clients to be explicit about what they want the system to block versus merely flag.

The caution on matching shortcuts: three-way matching only protects you if the receipt actually exists as a separate step. The moment someone posts a combined receive-and-invoice in one action for goods they have not verified, or posts an invoice with no order behind it, the control collapses because there is no independent receipt to check the invoice against. The temptation to skip receiving "to save time" is exactly how paying for undelivered or over-billed goods happens. Keep receiving as its own deliberate step for anything that matters, and reserve the combined shortcut for genuine low-value exceptions.

Deeper treatment of the accounting mechanics behind matching, tolerances and cost variance is worth its own study, and the discipline of Problem-Cause-Action style resolution when a match fails keeps investigations consistent. The point to carry away is that matching is not a report you run after the fact; it is a gate you put in front of payment.

8. Purchase approvals and spend control

Matching checks that an invoice is correct. Approvals check that the spend was authorised in the first place, and this is the second pillar of keeping purchasing under control. Business Central includes a built-in approval workflow capability that can require documents to be authorised before they proceed, and purchase documents are a primary target for it.

The mechanism works through approval workflows and an approval user setup. Each user who can request or approve is given an approval user record that defines who their approver is and, critically, their approval limit, the maximum value they are allowed to authorise. A workflow is then configured so that when a purchase order or purchase invoice is submitted, it routes to the right approver based on the amount and the requester. A buyer submits a purchase order; if it is within their own limit the workflow can auto-approve, and if it exceeds the limit it escalates up the chain of approvers until it reaches someone whose limit covers it. Until the document is approved, it stays blocked from being released, received or posted, depending on how the workflow is set.

This is what converts a policy on paper into a control the system enforces. "Purchases over a certain value need manager sign-off" stops being a rule people remember or forget and becomes a gate the document cannot pass without the required approval, with a recorded approval entry showing who authorised what and when. Notifications tell approvers there is something waiting, and the requester can see where their document sits in the chain. For finance and audit, the approval history is a clean record that spend followed policy.

The design decisions that matter are the limits and the routing. Set approval limits to match your real delegation of authority, and think about the escalation path so that documents do not stall waiting for an unavailable approver. Substitute approvers and delegation handle absence. The whole mechanism is deep enough to deserve its own treatment, and the Business Central approval workflows guide covers workflow configuration, approval user setup, limits and escalation in full. Combined with three-way matching, approvals give you both halves of spend control: authorisation before the commitment, and verification before the payment.

9. Drop shipments and special orders

Not every purchase flows through your own warehouse, and Business Central handles the two common exceptions with purpose-built features: drop shipments and special orders. Both link a purchase directly to a customer sale, which is why they matter for any business that sells goods it does not stock.

A drop shipment is where the vendor ships the goods directly to your customer, and they never physically pass through your premises. You still sell to the customer and still buy from the vendor, so you still need the sales order and the purchase order and their respective invoices, but you do not receive and re-ship the stock yourself. Business Central supports this by linking a sales order line to a purchase order so the two are tied together: the purchase order is flagged as a drop shipment, the vendor delivers to the customer's address, and the documents stay connected so the margin, the cost and the revenue all reconcile even though the goods never touched your inventory. This is the natural pattern for high-value or bulky items, or any arrangement where handling the goods yourself adds cost without adding value.

A special order is the related but distinct case where a customer wants something you do not normally stock, and you purchase it specifically for them, but the goods do come through your warehouse on the way. Business Central links the special purchase to the originating sales order so the item you buy is earmarked for that customer rather than going into general stock, and the receiving and shipping still happen at your location. The difference from a drop shipment is the physical routing: special orders pass through you, drop shipments bypass you.

Both features exist to keep the demand-to-supply link explicit. Without them you would be raising unlinked purchases and hoping the right goods reach the right customer. With them the system holds the connection, so when the vendor delivers, the corresponding customer order is satisfied and the costs land against the right sale. For a trading or distribution business these are not edge cases, they are core patterns, and knowing they exist saves a lot of manual reconciliation.

10. Vendor payments and the finance link

Posting an invoice does not pay the vendor; it creates a payable. The final leg of procure-to-pay is settling that payable, and this is where purchasing hands off to finance. Understanding this handoff clears up a lot of confusion about where purchasing ends and accounting begins.

When a purchase invoice posts, Business Central creates a vendor ledger entry, an open item representing money owed to that supplier, carrying the due date calculated from the vendor's payment terms and any settlement discount available for early payment. That open entry is what shows up when finance looks at what is owed and when. Paying it happens through the payment journal, where the accounts-payable team either enters payments manually or, far more powerfully, uses the suggest-vendor-payments function to have the system propose which invoices to pay based on due dates and available discounts. The team reviews the proposal, adjusts it, and posts it, which applies each payment against its corresponding invoice and clears the open entry.

For electronic payment the payment journal can generate a bank payment file from the vendor bank details discussed earlier, so the approved payment run becomes a file the bank processes. When the bank statement comes back, payment reconciliation matches the actual bank movements against the posted payments, confirming the money left as expected. Early-settlement discounts are handled automatically: if you pay within the discount window the system can take the agreed discount, which is a small but real saving that adds up across a year of payables.

The key concept is application: a payment is not just money leaving the bank, it is money applied to a specific invoice so that both are marked settled and the vendor's open balance reflects reality. Unapplied payments and unpaid invoices sitting side by side are how vendor accounts drift out of truth. Because every posting flows to the general ledger, the payables control account always reconciles to the sum of open vendor entries, which is the discipline that keeps the sub-ledger and the main ledger in agreement. The mechanics of ledger entries, posting groups, control accounts and reconciliation belong to finance, and the financial management deep-dive covers how the payables sub-ledger, the payment journal and the general ledger fit together.

11. Purchasing analytics and reporting

A purchasing process that captures clean, structured data is also a rich source of insight, and Business Central provides several ways to turn the transactions into decisions. The reporting is only as good as the discipline upstream, which is one more reason to keep prices, discounts and matching structured rather than hand-keyed.

The built-in reporting answers the questions a procurement function actually asks. Purchases by vendor and by item show where the money goes and concentrate attention on the suppliers and categories that matter. Outstanding purchase orders show what has been committed but not yet delivered, which is essential for cash planning and for chasing late deliveries. The aged accounts payable view shows what is owed and when it falls due, the core of payables management. Vendor performance, on-time delivery, price variance against agreed rates, and quantity discrepancies at receipt, all become measurable when the underlying documents are structured, because the data to compute them was captured as a byproduct of running the process properly.

Beyond the standard reports, Business Central exposes purchasing data to analysis tools. Account schedules and the financial reporting layer can summarise spend against budget. The dimensions you attach to purchase lines, department, project, cost centre, let you slice spend along whatever axes your organisation cares about, so "how much did we spend with this vendor on this project this quarter" is answerable without a spreadsheet. And because the data sits in a structured database, it feeds Power BI and analytical dashboards cleanly for organisations that want continuous procurement analytics rather than periodic reports.

The practitioner's caveat, and it applies to every ERP, is that analytics inherit the quality of the data entry. Dimensions left blank cannot be reported on. Discounts hidden in net prices cannot be measured. Receipts posted late distort delivery performance. The reporting layer is not where you fix data problems, it is where they become visible. If you want procurement analytics that hold up, the investment is in the disciplined capture during the process, not in the report design at the end.

Final thoughts

Purchasing in Business Central is a well-designed chain: vendor to quote to order to receipt to invoice to payment, with pricing feeding the lines, planning suggesting the orders, matching guarding the invoice, and approvals guarding the commitment. The platform gives you every control you need to run procurement tightly, but almost all of them are optional, so the quality of your purchasing operation is decided at configuration time and reinforced by process discipline, not handed to you by installing the software. Switch on the pricing engine so agreements are enforced, keep receiving as a real step so matching works, configure approvals to match your delegation of authority, and keep vendor master data under control, and Business Central will run a clean, auditable, efficient procure-to-pay process.

The failures I see are almost never the software falling short; they are the chain being broken for convenience. Invoices posted with no orders, receiving skipped to save a few minutes, prices hand-keyed instead of recorded, approvals treated as optional. Each shortcut removes a control the platform was ready to give you for free. Keep the chain intact and make the controls match your real policies, and purchasing stops being where money leaks and becomes where the ERP earns its keep. That is the difference between a Business Central that records your spending and one that manages it.

Related reading: The complete guide to Business Central features, Inventory management in Business Central, Warehouse management in Business Central, Approval workflows in Business Central, Financial management in Business Central.