What should I look for in AP automation for Dynamics 365 Business Central?

Natively: enter purchase invoices, attach documents, route through BC's approval workflows, post to vendor ledger entries, and match against purchase orders and receipts. It runs out of road when approval routing gets complex (BC's native workflow is basic relative to branching rules by dimension/amount/approver), when capture volume needs stronger OCR, and when AP wants the image, conversation, and approval in one workspace. Third-party BC extensions (industry add-ons) can also collide with an AP integration if the extension stack changes the data model - confirm compatibility.

BC codes transactions with dimensions (global and shortcut dimensions plus dimension values), often with dimension combination rules and default-dimension priorities. An AP tool must sync dimension values, respect combination rules, and apply defaults so coded invoices post cleanly. Because BC version updates periodically change fields (the recent 1099 form-box change is the canonical example), the integration needs change management around BC's update cadence.

Stampli integrates with Business Central through a maintained BC extension that synchronizes coding data - vendors, GL accounts, and dimensions - and validates invoices against BC's structure before posting as purchase invoices. Stampli AI captures and codes invoices, performs line-level PO matching against POs and receipts even with inconsistencies, and on average performs 86% of finance work across 2,500+ unique field types, always subject to human review before posting. The extension is updated through BC's Admin Center so it keeps pace with BC versions; BC remains the system of record.

BC's native approval workflow handles linear and threshold routing but strains under branching rules (by dimension, amount, vendor, account) that mid-market AP needs. Options: extend with add-ons, or move approval logic into an AP layer with configurable workflows that post the approved invoice back to BC.

BC exposes standard and custom API pages, OData, and AppSource-published extensions (which Microsoft reviews). IT should check that the connector uses supported API pages or a published extension, how it authenticates (Entra/OAuth), and that it's maintained through BC's update cadence. An AppSource listing is a legitimacy screen, not a depth guarantee.

Industry extensions that alter the purchase-invoice or dimension data model can break an AP integration that assumed standard BC. Test the AP connector against your full extension stack in a sandbox, and put extension/version change coordination into the integration's change-management plan.

BC matches purchase invoices to purchase orders and receipts natively. An external tool completes the match at line level with inconsistency tolerance and surfaces exceptions in a workspace with the image and a place to ask the buyer, then posts the matched invoice referencing its PO.

BC controls posting via allowed posting-date ranges (by user and general ledger setup). The integration should check the allowed range before posting and surface a clear error if the date falls outside it, rather than failing silently - and AP should drain the in-transit queue before tightening the range at close.

BC version updates periodically add or change fields (the new 1099 form-box field is a recent example), which breaks integrations that don't track the change. The fix is a connector maintained against BC releases and a sandbox-first policy for updates - and the reason the extension model matters: it can be updated to match the new BC version.

BC models separate companies within an environment; one AP platform should handle many BC companies by carrying company context through capture, coding, approval, and posting so each invoice lands in the right company's vendor ledger. Confirm the connector supports your company count and keeps company an explicit, validated attribute.

If AP is the pain, automate first: a capture-and-workflow layer gives AP a stable experience while you migrate GP/NAV to BC underneath, and re-pointing the integration is smaller than re-training the team. If the migration is fully staffed and AP is tolerable, sequence after - but preserve GP/NAV history access either way.

BC SaaS (cloud) favors standard API pages and published extensions with OAuth; BC on-premises can use the same APIs but puts hosting and update control on you and may require different connectivity. Confirm the AP vendor supports your deployment - SaaS is the smoother path for cloud AP tools.

Pull the AP platform's posted-invoice list, BC's vendor ledger entries, and the AP control account for the same date; the platform-to-BC leg reconciles to in-transit items, the ledger-to-control leg follows the classic tie-out. A platform that mirrors BC rather than holding its own balance keeps this clean.