Accounts-payable automation should reconcile invoice, purchase-order and receipt evidence before preparing a payable. Finance retains authority over exceptions, bank changes and payment release. The workflow needs both a correct approval record and confirmation of the final payment state.
Composite reference architecture. A reference AP control design; no savings, processing-time or fraud outcome is claimed.
The operating problem
Invoices, purchase orders, receipts, tax rules and bank details can each be valid while the combined payment request is wrong.
How the workflow works
Extract invoice fields with page provenance and compare them with the purchase order, receipt and vendor master. Apply the declared tolerance and tax rules, and flag suspected duplicates across entities and document variants. A three-way match establishes consistency within those records; it does not independently prove that bank details or an approval request are authentic.
Where review and controls matter
Bank changes need out-of-band verification through an approved channel. Split orders, tolerance exceptions and approval anomalies go to the finance owner with the supporting records. Payment release is separate from extraction and matching. If the destination response is uncertain, reconcile the payable and payment ledger before repeating the request. Tax treatment and payment policy must come from the responsible finance and legal owners.
Retry reference: Stripe idempotent requests. Destination support and reconciliation still need verification.
What to measure
Use a fixed cohort and measurement window. Count numerator events only within the denominator's eligible cohort; sampled measures use the same audit sample for both terms. Record the source, exclusions and owner, and keep missing data visible. These definitions are proposed measurement contracts, not observed results.
| Measure | Definition and unit |
|---|---|
| Touchless preparation rate | Invoices reaching a matched payable candidate without manual data repair divided by eligible invoices; percent. Report authorised payment release separately. |
| Duplicate detection recall | Known duplicate invoices correctly blocked divided by known duplicates in a labelled test or audit set; percent. Report false blocks alongside it. |
| Exception age | Time since exception creation for open invoice cases; median and p90 days at a stated cutoff. |
| Days payable outstanding | Average accounts payable divided by cost of goods sold for the period, multiplied by days in the period; days, where this accounting measure fits the business. |
| Post-payment defect | Paid invoices with a confirmed processing defect divided by audited paid invoices; percent, with financial impact reported separately. |
A useful first pilot
Use a closed invoice cohort and a test payment ledger. Trace normal matches, duplicate invoices, changed bank details and a timeout after release through to a reconciled terminal state.
Bring the workflow, its source records and the decision that needs an owner to a BergLabs pilot discussion.
