An AI invoice-processing pilot should start with one intake source, one accounting system and three explicit outcomes: draft and reconcile, route to human review, or hold with a retained reason. Join extraction, integration, review, rework and setup cost for the same window, then divide by accepted outcomes that the authoritative system can read back.
Extracting an invoice is not the same as accepting it. An OCR or document model may identify the vendor, invoice number, purchase-order reference, totals and line items. The accounts-payable workflow still has to decide whether those values match an order or receipt, whether an exception needs a person, and whether the intended state survived in the accounting system.
This playbook turns that difference into a bounded pilot contract. It includes a three-outcome artifact, a blank cost worksheet, a synthetic worked example and a release checklist. The displayed numbers test the arithmetic only. They are not vendor prices, client results, market benchmarks or savings forecasts.
Bound the pilot before choosing a model
Use one invoice intake source, such as a monitored AP mailbox or supplier portal. Choose one ERP or accounting system as the authoritative record and one matching policy. Name the purchase-order, receiving and vendor records the workflow may read. Name the draft or held state it may write.
Name two owners before implementation:
- Accounts-payable owner: owns matching policy, tolerances, required evidence, review service level and the meaning of each outcome.
- Systems owner: controls credentials, integration schemas, idempotency, monitoring, read-back and rollback.
Keep payment execution outside the first pilot. Also exclude vendor-master creation, bank-detail changes, tax judgment and policy overrides. Those are separate authority boundaries with different fraud, approval and recovery requirements.
The unit of work is one supplier invoice. The operating contract should record the intake identity, supplier identity, invoice number, currency, totals, purchase-order or receipt evidence, duplicate rule, policy version and final authoritative state.
Separate extraction evidence from accounting authority
Microsoft's current prebuilt invoice model documents outputs for invoice ID, dates, supplier, purchase-order reference, totals, payment terms and line items. It also exposes confidence values and recommends custom processing or fallback handling where the prebuilt model does not fit. Microsoft Learn on invoice processing.
AWS Textract similarly separates invoice and receipt output into summary fields and line-item groups, retaining detected labels, values and confidence. AWS on invoice and receipt response objects.
Those capabilities produce evidence for a decision. They do not decide whether the company ordered or received the goods, whether a duplicate already exists, or whether the invoice is permitted to advance. Treat extracted data as a proposal that must be joined with the company's records and policy.
Use three outcomes, not one processed flag
A useful minimum contract has three terminal workflow outcomes:
| Outcome | When it applies | Evidence to retain | Owner after the decision |
|---|---|---|---|
| Drafted and reconciled | Supplier, invoice identity, amounts and required purchase-order or receipt evidence match the approved policy | Source document identity, extracted fields, match evidence, policy version, accounting record ID, intended state and read-back state | Accounts-payable owner or normal approval queue |
| Human review | Evidence is missing, low-confidence, conflicting, stale or outside the automated policy | Source identity, exact missing or conflicting fields, proposed state, review reason, queue and expiry time | Named AP review queue |
| Held or refused | Duplicate, prohibited action, invalid supplier state or explicit policy exclusion applies | Source identity, rule and policy version, held-state receipt, read-back or proof that no write occurred | AP owner, fraud owner or systems owner named by policy |
Do not force ambiguity into the matched bucket. Review and hold are real operating states, not failures to hide. Each needs an owner, a reason and a deadline or recovery path.
Oracle describes invoice matching as associating an invoice with a purchase order, receipt or consumption advice. Its validation process checks variances between ordered, received, consumed and invoiced quantities or amounts, and can place holds for exception conditions. Oracle on matching invoice lines and Oracle on invoice validation.
That product behavior is a useful release boundary: extract, match, draft or hold, then leave approval and payment to the buyer's established controls.
Read the accounting system back
Preserve three different records:
- Intent: the normalized invoice state the workflow proposed, including its business key and policy version.
- Acceptance: the provider response, record ID, correlation ID, validation errors and response time.
- Observation: a fresh read of the authoritative invoice and relevant associations after the write.
An API response can prove that a request was accepted. It does not prove the retained record matches the proposal another operator will see. Compare the supplier identity, invoice number, amount, currency, purchase-order or receipt link, workflow status and hold reason.
If read-back is unavailable, mark the outcome uncertain. If the authoritative state contradicts the proposal, mark it divergent. Do not replay an ambiguous write until reconciliation proves the intended effect is absent.
Accounting systems expose materially different invoice states. Xero's accounting API, for example, distinguishes draft, submitted, authorised, paid and voided invoices. Xero Accounting API types and codes. A generic processed flag erases exactly the state the AP owner needs.
Calculate cost per accepted, reconciled outcome
Join costs from the same observation window:
document cost = invoices x average pages x extraction cost per page
review cost = invoices x review rate x minutes per review / 60 x loaded planning rate
rework cost = invoices x exception rate x minutes per exception / 60 x loaded planning rate
total operating cost = document cost + platform and integration cost + review cost + rework cost + amortized setup
cost per accepted reconciled outcome = total operating cost / accepted reconciled outcomes
An accepted outcome means the business accepts one of the three contract states and the required evidence is retained. It does not mean the invoice is approved for payment. Keep the outcome mix visible so a cheap workflow that holds nearly everything cannot masquerade as a useful system.
Blank worksheet
| Input | Your value | Evidence source |
|---|---|---|
| Invoices in the observation window | Enter value | Intake record IDs |
| Average pages per invoice | Enter value | Source document inventory |
| Extraction cost per page | Enter value | Provider usage and bill |
| Platform and integration cost | Enter value | Incremental execution cost |
| Review rate | Enter value | Named AP review queue |
| Minutes per review | Enter value | Review timestamps |
| Exception rework rate | Enter value | Correction and incident records |
| Minutes per exception | Enter value | Rework timestamps |
| Loaded planning rate | Enter value | Buyer-approved internal assumption |
| Amortized setup cost | Enter value | Approved pilot accounting treatment |
| Drafted and reconciled | Enter value | Authoritative invoice read-back |
| Human review acknowledged | Enter value | Review queue read-back |
| Held or refused with evidence | Enter value | Hold record or no-write evidence |
| Uncertain or divergent | Enter value | Reconciliation log |
If accepted reconciled outcomes are zero, unit cost is unavailable rather than zero. Preserve the numerator and the failure evidence.
Synthetic worked example
Assume 5,000 invoices in one test window, averaging two pages. Model extraction at $0.01 per page, platform and integration at $400, and amortized setup at $1,500. Assume 20 percent of invoices need three minutes of review, 5 percent need eight minutes of exception rework, and both kinds of human work use a $60 loaded planning rate. The workflow produces 4,500 accepted, reconciled outcomes across its three states.
| Component | Demonstration value |
|---|---|
| Document extraction | 5,000 x 2 x $0.01 = $100 |
| Platform and integration | $400 |
| Human review | 1,000 x 3 minutes x $60/hour = $3,000 |
| Exception rework | 250 x 8 minutes x $60/hour = $2,000 |
| Amortized setup | $1,500 |
| Joined operating cost | $7,000 |
| Accepted reconciled outcomes | 4,500 |
| Cost per accepted reconciled outcome | $1.56 |
The $1.56 result tests the worksheet only. It does not predict a buyer's cost or savings. Replace every input with evidence from one defined window. Keep observed provider spend separate from modelled human cost, and record overlap if the same invoice appears in review and rework.
Build the evaluation set around exceptions
Use representative historical invoices the buyer is authorized to use. Protect bank details, tax identifiers and personal data that the workflow does not need. Freeze the expected outcome and required evidence before the run.
| Case class | Examples | Passing behavior |
|---|---|---|
| Ordinary | Clean PO match, clean receipt match, known supplier, permitted currency | Correct draft or held state plus authoritative read-back |
| Exception | Missing receipt, amount variance, low-confidence invoice ID, duplicate candidate, unknown PO | Named human review or hold with the exact reason retained |
| Prohibited | Bank-detail change, vendor-master mutation, payment instruction, unsupported tax decision | Safe refusal or hold with no prohibited effect |
Score extraction, match decision, final state, evidence completeness and reconciliation separately. A correct field extraction with the wrong accounting state is not accepted. A correctly drafted record without read-back is uncertain. A handoff is not complete until the named queue can observe and acknowledge it.
Apply this release checklist
- Name the workflow and owners. Record the intake source, accounting system, AP owner and systems owner.
- Freeze the allowed unit. Start with one invoice type, one legal entity, one currency policy and one matching path.
- Version matching policy. Define required fields, purchase-order or receipt rules, tolerances, duplicate handling and review conditions.
- Minimize authority. Permit only required reads and draft or hold writes. Exclude payment, bank details and vendor-master changes.
- Establish the business key. Bind supplier, invoice number, amount, currency and source identity so duplicate delivery does not create duplicate records.
- Test ordinary, exception and prohibited cases. Do not tune only on clean invoices.
- Read every write back. Compare intended and retained identifiers, amounts, associations and state.
- Stop on uncertainty. Keep ambiguous and divergent effects visible. Reconcile before replay.
- Route review to a named queue. Give it an owner, response window and escalation path.
- Join the economics. Use one observation window and divide complete operating cost by accepted reconciled outcomes.
- Test rollback. Disable the agent path, restore manual intake and confirm that no invoice remains stranded.
- Expand one boundary at a time. A new legal entity, invoice type, source, matching policy or write authority is a new release candidate.
Know what this worksheet cannot prove
This resource does not estimate payment discounts, fraud reduction, cash-flow improvement, supplier satisfaction or headcount savings. It does not decide whether the company's matching policy, tolerances or accounting treatment are correct. It cannot reveal a biased or incomplete evaluation set when the same omission appears in both policy and expected outcomes.
Pair the unit-cost view with finance policy review, security and privacy review, fraud controls, outcome sampling and downstream accounting evidence. Keep business value separate from the operating cost the pilot can actually observe.
The release question is narrower and useful: for one invoice source and one accounting system, can the company explain and reconcile every draft, review or hold at a cost it understands, without giving the workflow payment authority?
