Accounts Payable Automation for Business Central and Dynamics 365 F&O

Business Central and Dynamics 365 F&O accounts payable automation means putting an extraction-and-matching layer in front of the ERP that reads every supplier invoice, resolves it against the live purchase order, handles the SKU and unit-of-measure mismatches that are normal in real procurement, and hands staff a review screen where only genuine exceptions need a human -- while the ERP stays the untouched system of record for what gets posted.

Both ERPs give you purchase-order-to-invoice matching out of the box, and for a clean world -- one supplier SKU per PO line, one invoice per PO, matching units of measure -- it's fine. Real AP doesn't work that way. Suppliers issue one consolidated invoice covering fifty deliveries. They bill in cases when the PO ordered eaches. Partial shipments and backorders mean an invoice almost never maps one-to-one onto its PO. A single damaged-parts credit memo on four of those fifty lines can, under a strict three-way-match policy, block release of the entire payment -- teams on r/Accounting describe exactly this: a six-figure payment held up by a low-value discrepancy on one line of a much larger invoice. That's not a Business Central or D365 problem specifically; it's what happens when native ERP matching meets messy supplier data everywhere.

We've built this exact pattern in production -- AI extraction, deterministic PO/SKU/UOM matching with an AI fallback, and a hard reconciliation gate -- for a Canadian industrial safety distributor processing ~1,500 supplier invoices a month against purchase orders in Infor CloudSuite Distribution. The architecture doesn't care which ERP sits behind the API call. The rest of this guide is that pattern, and how it maps onto Business Central's OData/API surface and D365 F&O's Data Management Framework.

Same decision shape as any ERP-adjacent build: buy an add-on, buy a SaaS layer, or build on your own Azure tenant.

	ERP-native ISV add-ons	Generic AP SaaS	Custom platform on your Azure tenant
Examples	Continia Document Capture (BC), native D365 F&O vendor invoice matching policies	Yooz, Beanworks, Stampli, Medius	Built on Azure Functions/Container Apps + the ERP's own API
Fit with ERP data	Native	Via connector, invoice data copied out	Direct API calls, nothing copied or stored outside your tenant
Handles inconsistent supplier SKUs / UOM	Rarely, without custom rules	Rarely, generic matching logic	By design -- per-supplier rules plus an AI fallback
Data leaves your tenant	No	Yes	No
Cost shape	Per user/month forever	Per user/month forever, mid-market pricing from ~$400-800/mo	One-time build + minor Azure running costs
Time to live	Days-weeks	Weeks	Weeks

The honest rule of thumb is the same one we give for AR: if your suppliers bill cleanly and one-to-one against POs, an add-on or SMB SaaS tool will be live faster, and we'll say so in an assessment. The custom route earns its cost when the matching itself is the hard part -- inconsistent SKU codes per supplier, mixed units of measure, invoices that span multiple POs or partial shipments. That's most mid-market AP, not an edge case.

AP is not AR. Our AR builds keep the ERP strictly read-only because collections activity never needs to touch the ledger. AP is different: an approved, matched invoice genuinely needs to post. So the architecture has one deliberate write path instead of none:

• Extraction, decoupled from matching. A PDF processor converts each invoice to structured text in milliseconds; an LLM pulls out vendor, invoice number, dates, currency, totals and the full line-item array against a strict, schema-validated output -- so a malformed extraction fails loudly instead of posting silently.
• PO resolution against the live ERP, never against the invoice's own claim. The extracted PO reference is looked up through the ERP's API in real time -- Business Central's OData/API pages, or D365 F&O's Data Management Framework/OData endpoints -- which confirms the canonical vendor before the invoice is treated as genuine. Who the invoice says it's from is never trusted on its own.
• Deterministic matching first. SKU-containment and price logic, with explicit unit-of-measure conversion, pairs each invoice line to its PO line automatically wherever the pattern is predictable. This resolves the majority of lines without AI involved at all -- it's cheaper, faster and fully explainable to an auditor.
• AI fallback only for the leftovers. Lines the deterministic logic can't resolve go to an AI matcher that reports its own confidence. Low-confidence and unreconciled lines route to a review queue; everything else stays in the fast lane.
• One controlled write: the ERP-ready import. Approved, fully-matched invoices export as a clean import batch -- a purchase invoice in Business Central, a vendor invoice journal in D365 F&O. Nothing writes to the ERP until a human (or a high-confidence automated pass, if you choose to enable it) has signed off. That's the single write path, and it's the only one.

This is the failure mode that makes generic AP tools and strict native ERP matching break down at scale: one supplier sends a single consolidated invoice for fifty deliveries, one of those has a damaged-parts credit memo attached, and a rigid three-way-match policy holds the entire invoice -- and therefore the entire payment -- until every line clears. On a large enough invoice that's a six-figure sum stuck behind a low-value dispute.

The fix isn't looser matching, it's matching at the right granularity. The pipeline treats each invoice line as its own matching decision, not the invoice as one pass/fail unit:

• Clean lines settle independently. The 49 lines that match cleanly against their PO lines clear straight through, regardless of what's happening on line 50.
• Exceptions carry a recorded reason. The damaged-parts line routes to review with the specific mismatch attached -- quantity variance, price variance, unmatched SKU -- instead of a blanket "invoice failed matching."
• Partial approval, partial hold. Finance can release payment for the matched lines and hold only the disputed one, instead of choosing between paying everything unverified or holding everything hostage.

The same logic handles the other two common breakers: a supplier billing in cases when the PO ordered eaches (unit-of-measure conversion, applied per supplier), and an invoice that spans multiple partial shipments against one PO (line-level matching against remaining PO quantity, not a one-shot invoice-to-PO comparison).

Trusting AI extraction without verification is how automation projects lose finance teams' confidence. Every invoice passes a mathematical reconciliation gate before anything proceeds -- extracted line totals are summed and checked against the invoice's own printed subtotal. If they don't reconcile, the invoice routes to review automatically, no matter how confident the extraction looked.

In the first production run of the build described above, that gate caught the AI misreading an extended line total as a unit price -- a $23,908 error on a $4,391 invoice -- and routed it to review before it could touch a PO match, let alone a payment. Across the validation set, 12 of 13 real production invoices reconciled to the cent on the first pass; the thirteenth was exactly the case the gate exists for.

Self-improving matching compounds this over time: when the AI fallback successfully resolves a new supplier's SKU pattern -- "this vendor prefixes our part number with their own line code" -- that resolution is flagged as a candidate rule. Once confirmed, it becomes a deterministic match going forward. The AI's job shrinks to genuinely new patterns; everything it's already solved for a given supplier stops needing AI at all.

Ardent Partners' 2025 AP benchmarking puts the average cost to process an invoice at $9.40, against $2.78 for best-in-class touchless processing -- roughly a third. At volume -- the reference build processes ~1,500 invoices a month, each PDF converted to structured data in under a second -- that difference is the AP team's week back. More importantly, the job changes shape: from keying and chasing PO numbers to reviewing the exceptions the system couldn't resolve on its own, which is where an AP analyst's judgment actually adds value.

The platform runs on Azure -- Container Apps for the pipeline, Blob Storage for invoice PDFs, managed identities with no stored keys, staff signing in through Microsoft Entra ID. For a Business Central or D365 F&O deployment, that stack is unchanged; only the ERP-facing adapter swaps -- Business Central's API pages instead of Infor's API gateway, or D365 F&O's OData/Data Management endpoints. The matching engine, the accuracy gate, and the review UI don't know or care which ERP they're pointed at.

If your AP team is still opening PDFs and keying PO lookups by hand, the questions that determine build shape are: how consistent are your suppliers' SKU codes against your own, how often do units of measure differ between PO and invoice, and how often does one invoice span more than one PO or shipment? The messier the answers, the more a deterministic-plus-AI matching layer earns its keep over a generic tool.

Those questions are exactly what our AI readiness assessment establishes before any build starts. If you want the production detail behind the numbers in this guide: the AI invoice processing case study. For the broader pattern across AP, AR and job costing on Microsoft ERPs, see ERP finance automation.