What Business Central's Native AP Tools Do Well, and Where Growing Teams Still Hit Friction

Ask a controller running Dynamics 365 Business Central what changed in their accounts payable process this year and you will probably hear about the Payables Agent. It monitors a mailbox, reads vendor invoice PDFs, matches vendors and G/L accounts, and hands a draft purchase invoice to a human for review. For teams that were keying invoices by hand at ten or fifteen minutes apiece, that is a real change in the shape of the workday.

What you hear less about is what happens after the invoice is approved.

Business Central's disbursement side — deciding what to pay, assembling batches, routing approvals, validating vendor banking details, executing across multiple checkbooks and legal entities — has not been reshaped by the same wave of automation. 

The native tooling there is solid and long-established, but it is largely the same tooling it was before the agents arrived. The result is an asymmetry: intake got faster, disbursement did not, and the queue moved downstream.

This is worth naming clearly, because it changes how partners and finance leaders should be scoping AP projects right now.

What Business Central actually gives you natively

It is worth being precise about the native footprint, because vendor marketing in this category has a habit of understating it.

• Suggest Vendor Payments builds a payment proposal from vendor balances, due dates, available discounts, and payment priority. For a single-entity organization paying a few dozen vendors on a predictable cycle, this is often the whole job.

• Payment Journal is where those proposals become posted payments, with support for checks and electronic payment file export.

• Job Queue Entries schedules recurring background processes, including the codeunits behind payment suggestion.

• Vendor records hold the master data — remit-to addresses, payment method, bank account details — that everything downstream depends on.

• Payables Agent, generally available since the 2026 Wave 1 release, sits upstream of all of it, converting inbound invoice email into draft purchase documents under human supervision.

That is a genuinely capable foundation, and a meaningful share of Business Central customers will never need more than it. The honest framing for any AP conversation is not "Business Central can't do this." It is "at what level of complexity does doing this natively start costing more than it saves?"

The four variables that move that threshold

In practice, four things determine whether a team outgrows the native disbursement workflow, and none of them is simply transaction volume.

• Batch construction rules. Suggest Vendor Payments answers what is due. It does not answer how your organization decides what to release, which vendors are paid from which checkbook, which invoices are held pending a signature, which payment types get split into separate runs. That logic tends to live in a spreadsheet and in one person's head, and it gets reconstructed manually every payment cycle.

• Approval thresholds. Native approval workflows handle document approval well. Threshold-based control over the payment itself — dollar-tier signature requirements, dual authorization above a limit, segregation between the person who builds the batch and the person who releases it — is where teams with real audit exposure start writing custom code or manual procedure.

• Vendor data integrity. The Payables Agent has increased the rate at which new vendor records get created, because the friction of adding one has dropped. That is a good outcome for throughput and a risk multiplier for payment fraud. Verifying TIN, address, and OFAC status before funds move is not a native Business Central function.

• Multiple companies. A shared-services AP team supporting six Business Central companies is doing the same payment run six times, in six contexts, reconciling six sets of results. Native cross-company payment processing is not part of the base product.

• Notice that three of these four are control problems, not throughput problems. That matters, because the ROI case for AP automation is usually written as time saved, and time saved is the least interesting thing on this list to an auditor or a CFO who has read one too many stories about business email compromise.

Extending rather than replacing

The architectural question that follows is whether to solve these gaps by customizing Business Central, bolting on an external payment platform, or extending the native workflow in place.

External payment platforms solve the disbursement problem by moving it outside the ERP. That works, but it introduces a second source of truth for payment status, a reconciliation surface between the two systems, and a training burden for a team that already knows Business Central. It also tends to break the connection between the intake automation Microsoft is investing in and the disbursement process sitting downstream of it.

The alternative is to extend the native objects, i.e. build batch logic on top of Suggest Vendor Payments rather than beside it, layer threshold control onto the Payment Journal rather than exporting out of it, use Job Queue Entries as the scheduling engine for recurring payment runs rather than introducing a second scheduler. 

Business Central remains the system of record. The AP team keeps working in screens it already knows. And the extension inherits Microsoft's release cadence rather than fighting it.

A worked example

Take a common scenario: a new vendor submits a first invoice.

Natively, with the Payables Agent in play, the invoice arrives by email, the agent drafts the purchase invoice and flags that it cannot match the vendor, a supervisor creates the vendor record and approves the draft, and the invoice enters the payable ledger. So far, largely automated.

Then: someone remembers to run Suggest Vendor Payments before Thursday's check run. Someone confirms the new vendor's banking details are real. Someone checks whether the amount crosses an approval threshold. Someone decides which checkbook it comes from. Someone builds the batch, someone else reviews it, and the payment posts.

Six manual coordination points, after the automated part is finished. That gap between an efficient intake process and a manual release process is where most of the remaining AP labor now sits, and it is the part of the process that is easiest to leave out of a project scope, precisely because the agent demo looked so good.

How to scope this

For partners and finance leaders evaluating AP automation over the next two release waves, the useful diagnostic is not "how many invoices do you process." It is:

• How many distinct rules govern which invoices get released, and where do those rules currently live?
• Who is authorized to release payment, at what dollar level, and can you evidence that separation to an auditor?
• What verifies a vendor's banking details between record creation and first payment?
• How many companies does one AP person move between in a normal week?

If the answers are "one rule, one person, we call them, one company," Business Central's native tooling is sufficient and adding to it is premature. If the answers run in the other direction, the gap is real, and it has gotten more visible, not less, as the intake side of AP has gotten faster.