Business Central Accounts Payable: The Complete Setup and Process Guide

Accounts payable is one of the easiest setup areas in Business Central, but also one of the most misunderstood areas of this system. In AP, the system requires minimal configuration to support linear payable processes, where the flow from purchase order to payment is smooth and requires no intervention. In such cases, which are not uncommon, you can find third-party apps for AP automation that can automate part of the AP process.

The configuration and setup exceptions happen when the system needs to support non-linear processes. For example, when a vendor issues an invoice where quantities do not match, or when we can get a payment discount or apply a tolerance.

This post covers the vendor setup fields that drive AP behaviour downstream, how invoice matching and payment tolerance work in BC, and the three problems that appear most often in post-go-live AP reviews — with the fix for each.

How accounts payable works in Business Central: the end-to-end flow

The purchase-to-payment cycle in BC runs in four steps.

Once a purchase order is raised and approved, goods or services are received, and a purchase receipt is posted against it. The vendor invoice is then matched to that receipt and posted as a purchase invoice, creating the payable in the vendor ledger. Payment is prepared via Suggest Vendor Payments, which filters open invoices by due date and currency, and is posted to the bank through a payment journal. Though BC supports variations of this process, what is described is the backbone of a typical AP process in Business Central.

Each step maps to a control category. The purchase order and goods receipt are obligation-to-pay controls: they establish that the liability is real before it is recorded. This is a contractual element, not an accounting liability, because in BC, the amount payable hits the ledgers only when the purchase invoice is posted. The purchase invoice entry is a data entry control: it records the liability accurately, to the right vendor, amount, G/L account, and posting period.

The payment journal is a payment control: it ensures that only approved amounts reach verified vendors and only for the right invoices. A well-configured AP setup enforces all three controls, and it ensures that the system is configured to support the organisation’s reporting, control and auditing requirements, and cash flow.

One change worth noting for implementations running BC28 (2026 Release Wave 1, now generally available): a new action on the purchase invoice allows matching to multiple purchase order lines regardless of whether receipts have been posted, more flexible than the existing Get Receipt Lines action, which matches line to line from posted receipts only. That feature will be covered separately in an upcoming post.

Setting up vendors: beyond the name and address

The Vendor Card is where the data entry control environment is configured. Most implementations treat it as an address book with payment terms attached. It is not. Five fields on the Invoicing tab determine how every transaction for that vendor will post for as long as the vendor is active.

The Vendor Posting Group is a critical field for AP control on the vendor card, as it determines which balance sheet account to post the liability when a purchase invoice is posted, but also payment tolerance and discount general ledger accounts.

Vendor Posting Group

Payment Terms drive due date calculation on every invoice posted for that vendor. Wrong payment terms produce wrong due dates, which means the Suggest Vendor Payments function does not pick up invoices when it should. This is also an obligation-to-pay control issue: incorrect payment terms age the liability incorrectly in the vendor ledger, distorting cash flow reporting.

Payment Method controls how the payment is generated: BACS, cheque, or other. A mismatch between the payment method on the vendor card and what the bank expects causes the payment journal to generate entries that the bank file does not recognise. In most cases, BC will flag an incorrect payment method before the payment can be posted, but in the case of custom bank integrations or manual file exports, errors will not emerge until the payment is processed by the bank.

Vendor Card

Currency Code is the default currency for vendors invoiced in a foreign currency. Leaving it blank means users must select the currency at invoice entry.

Gen. Bus. Posting Group is assigned to vendors to specify who you buy from, and combined with Gen. Product Posting Group in General Posting Setup, determines which income statement accounts transactions post to. It is not a Tax control account, though it can be linked to it. This last posting group is not important for AP purposes as it impacts the P&L for purchase transactions.

Purchase invoice approval and matching in Business Central

This is the obligation-to-pay control layer: before an invoice is posted, there must be evidence that goods or services were received and that the amount matches what was ordered.

In Business Central, this is enforced through the receipt-to-invoice link. BC does not have a dedicated invoice matching engine with two-way or three-way policy toggles. That framework exists in D365 Finance, not Business Central. In BC, matching happens when the user links the invoice to a posted receipt, and the system checks quantity and cost against what was received. Although this might sound like a limitation, BC is designed to make this step of the process faster.

In an enterprise-tier ERP like D365 Finance, AP must create a purchase draft invoice when the vendor sends a bill and then match it to a purchase order and receipt. In BC, creating a new draft invoice creates an additional obligation to pay, essentially doubling the payable amount. Instead, users can generate the invoice from the receipt using a dedicated feature called Get Receipt Lines.

Get Receipt Line

That creates the draft document and a link to the goods received. Essentially, reducing manual data entry

Payment journals and suggesting vendor payments

This is the payment control layer, where in some organisations the person who prepares the payment should not be the same person who authorises it, and the payment should only reach verified vendors for verified amounts.

This level of control in BC is not enforced by default, and it must be configured unless your organisation allows the same team or even users to prepare, approve and process payments.

In BC, the Suggest Vendor Payments function is the preparation step. It produces a payment journal with proposed lines based on open vendor ledger entries. Reviewing and posting the journal is the authorisation step. If the same person does both, the payment control is absent. BC’s purchase approval workflows can enforce the separation if configured; if they are not, the control relies entirely on manual procedure.

The Suggest Vendor Payments function filters open vendor ledger entries by due date, vendor, currency, and bank account. The field that ensures payment runs only for invoices due on or before a specific date is the Last Payment Date.

Suggest Vendor Payments

Only invoices with a due date on or before that date will be included in the payment run.

Common AP problems in Business Central and how to fix them

These two problems appear in nearly every post-go-live AP review, and it's a symptom of a specific control layer that was not configured.

Payment run not picking up opening balance invoices. This happens when the open payables are uploaded in BC, and the document date is set to be the posting date of the go-live opening balance. When uploading purchase opening balances using vendors, the document date must be the original invoice date taken from the legacy system. The correct document date, combined with payment terms, will result in the purchase ledger showing the correct due date so that future payment runs and the aged payables reports are correct.

AP balance not matching vendor ledger entries. This happens when users post directly to the payables account via a journal, bypassing the AP module entirely. This creates a G/L entry with no corresponding vendor ledger entry. The payables account balance and the sum of vendor ledger entries diverge, and the difference cannot be found in any vendor’s account. To fix this, filter G/L entries on the payables account and look for entries where the source document number is blank, or the source type is G/L Journal. Then, use Reverse Transaction to create a reversal entry.

General Ledger Entries

Next Steps

Business Central has the configuration tools to cover all three AP control categories.

Intentionally configuring them, instead of relying on default settings, distinguishes an effective AP setup from one that leads to the reconciliation issues mentioned above.

If you are setting up AP in Business Central for the first time or reviewing an existing configuration, get in touch.