Accounts payable software: design an approval workflow that works

Separate capture, matching, approval and payment

An invoice arriving in a mailbox is not yet a payable instruction. Someone or something must identify the supplier, extract the document, check for duplication and establish what the business received. Approval then records an authorised decision. Payment is a further operation, often in another system or under separate controls.

Keep those stages visible in the brief. If a supplier demonstrates automatic processing, ask which stages are actually included and which depend on your accounting system, purchasing data or payment provider. A document marked approved is not proof that a payment has been sent, and a successful upload is not proof that the underlying purchase is valid.

Choose the evidence needed for the purchase

A purchase order records an agreed request; a receipt records what arrived. Microsoft’s Dynamics 365 Finance matching overview distinguishes two-way checks against purchase-order prices from three-way checks that also compare received quantities. It also describes configurable tolerances for differences. These are distinct checks rather than interchangeable names for automation.

Not every expense has a purchase order. A recurring software subscription, a delivered pallet and a consultant’s milestone invoice may need different evidence. Decide which route applies to each common purchase type, including who can confirm receipt of a service. Avoid forcing every invoice through a goods-receipt model simply because the demonstration uses inventory.

Work through a short-delivery example

Suppose a fictional team orders 100 display stands at £8 each. The supplier delivers 90 but invoices for all 100. The unit price matches, yet the quantity needs attention. A process that checks only the £8 price can miss the unresolved delivery question.

The useful result is a visible exception assigned to the person who can explain the missing ten units. That person might confirm a second delivery, obtain a corrected invoice or agree another authorised resolution. The software should retain the original document and decision history. This example illustrates a requirement to test; it is not an observed result from a product trial.

Design an exception queue people can operate

Define the few exception types that genuinely need different owners: an unknown supplier, duplicate document, price difference, missing receipt or coding question. Each needs a clear reason, age, next owner and route back into the main process. A long generic queue labelled pending gives colleagues little help.

Add absence cover and escalation. If the budget owner is away, who can decide, and what authority do they inherit? If an invoice remains unresolved, when does it receive attention? Keep notifications focused on decisions rather than copying every participant into every update. The goal is an actionable handover, not a busy inbox.

Ask what automation does after a failed check

Microsoft’s automated invoice-submission guidance describes background matching and workflow processes, including conditions that exclude an invoice from further automated handling. That is a useful buying question for any system: which records stop moving, how are they shown and who restarts them?

Use a small authorised trial to follow a normal invoice, a duplicate and a quantity mismatch. Then correct the mismatch and inspect the new status. Record whether the tool reruns a check, requires a person to resubmit or creates another record. Repeated processing must not quietly create repeated postings or payment instructions.

Connect the workflow to purchasing and finance ownership

An AP tool depends on the quality and availability of supplier, order, receipt and ledger data. Ask for the exact integration route and the owner of field mapping, permissions and failures. If a purchase-order number is optional at intake, decide who resolves it before the invoice reaches the wrong approver.

Compare the cost of the selected workflow, including entities, document volume, implementation, payment services and support. Browse the procurement and spend category and the Tipalti profile alongside your existing accounting system. Keep the named Dynamics 365 Finance example separate from other Microsoft products: a shared vendor does not establish identical matching features or licences.

Frequently asked questions