In purchase orders, AI belongs in the exception
By Equipo Quantum Developers
Summarize:
The easiest invoice to automate is also the least appropriate place for a probabilistic decision. The thesis is testable: an invoice should not reach AI until deterministic rules have validated identity, references, tolerances, and receipt; the model should assist ambiguity rather than replace controls. When an exact comparison can decide, AI adds variability without adding judgment.
This does not reduce the agent to document reading. It gives the agent the work where interpretation helps: ambiguous descriptions, evidence gathering, proposed reason codes, and clarification drafts. Payment, approval, and posting remain behind independent policy gates.
Matching is a sequence of controls
Oracle documents two-way matching as purchase-order-to-invoice comparisons for quantity and price. Three-way matching adds receipt quantity, and four-way matching adds acceptance (Oracle Payables). It also describes tolerances and holds when values do not match. The lesson is not to copy one product configuration. Each “way” answers a different control question.
Peppol BIS Billing treats invoice verification as part of the buyer’s internal controls and expects sufficient references to find purchase order, contract, receipt, delivery, and responsible approver (Peppol BIS Billing). A reference is not clerical decoration; it is the join that makes a defensible comparison possible.
NIST SP 800-53 Rev. 5 provides a flexible catalog of security and privacy controls. Its AC-5 control calls for identifying and documenting duties that must remain separated (NIST SP 800-53 Rev. 5). It is not an accounting standard, but the design lesson applies here: recommendation, authorization, and posting should not collapse into one technical identity.
Policy gates for an invoice
The following flow is a design pattern:
Gate 0 — input integrity
Validate format, duplicate identity, issuer, currency, invoice number, and a buyer or order reference. An exact duplicate does not require AI; it requires idempotency. A missing reference produces MISSING_PO_REFERENCE.
Gate 1 — authority and state
Confirm that supplier, order, and cost center exist and are enabled. Verify that the order is not closed or cancelled. A persuasive description must never override a forbidden state.
Gate 2 — deterministic matching
Compare lines by identifier, quantity, and price under policy. Tolerances belong to category, contract, or supplier rules—not the prompt. Record the observed value, applied limit, and policy version.
Gate 3 — receipt and acceptance
For goods, link the receipt. For services, require defined acceptance evidence. A partial receipt is not automatically a total rejection; it should produce a specific exception.
Gate 4 — AI-assisted ambiguity
Only here should an agent classify text, suggest line correspondence, summarize documents, or prioritize the exception. Its output is a proposal with evidence and uncertainty, never a payment instruction.
Gate 5 — approval and posting
A person or independent rule approves according to value, risk, and segregation policy. The identity that proposed the action must not be the same logical authority that approves and posts it.
Stable reason codes
Avoid a queue filled with “does not match.” Use a governed vocabulary:
| Code | Meaning | Next evidence |
|---|---|---|
| MISSING_PO_REFERENCE | no valid reference | order or buyer reference |
| DUPLICATE_INVOICE | identity already processed | history and original document |
| PRICE_OUT_OF_TOLERANCE | price breaches policy | contract or approval |
| QUANTITY_OVER_RECEIPT | billed exceeds received | receipt or correction |
| RECEIPT_MISSING | no delivery evidence | receipt advice |
| LINE_AMBIGUOUS | description has no unique mapping | catalog or review |
| SUPPLIER_MISMATCH | issuer and order differ | supplier master |
| POLICY_BLOCK | state or rule forbids progress | policy-owner decision |
Codes make exception inventory comparable and enable closure analysis by cause. The agent may propose a code; a rule checks whether required evidence exists.
Illustrative invoice
Assume an invoice has three lines. Two reference exact order lines, fall within configured policy, and have receipt evidence. The third says “additional service,” points to a broad order line, and has no acceptance record.
The gates release the first two only if partial processing is authorized. The third receives LINE_AMBIGUOUS and RECEIPT_MISSING. The agent searches approved contract material, prepares a summary, and asks the service owner to confirm scope. It does not alter price, invent receipt, or approve. When evidence arrives, a new run reevaluates the same line under the current policy. This is a qualitative illustration; each organization must set its own tolerances.
Evidence and segregation
For every decision, preserve the invoice and hash, order version, receipt, line comparison, tolerance used, reason codes, agent proposal, approver, time, and posting result. A narrative explanation is not enough; the deterministic gate should be reproducible.
Separate proposal, approval, and accounting entry. A service account may prepare a posting draft but should not grant itself authority. Permissions and visible human approval need to reflect that boundary.
Representing the flow in Quantum
In Quantum Automation Center, the workflow can appear in the catalog and each invoice can remain a business object. The timeline exposes gates, retries, and approval. Artifacts preserve comparisons and evidence. Logs support debugging. Analytics group exceptions by reason without equating processed volume with control quality.
The AI-agent documentation can support the ambiguous step. The payment reconciliation overview demonstrates why explainable queues matter in financial control. Quantum should not replace the ERP or procurement policy; it should expose execution, exception, and decision.
The counterargument: why not one end-to-end agent?
Where documents are highly inconsistent, one agent can accelerate extraction and reduce early integration work. That flexibility is useful for discovery or drafting. A “document to posting” demonstration, however, often hides supplier state, receipt, tolerance, and segregation. The more material the action, the less acceptable it is for one inference to interpret, decide, and execute.
The alternative is not to ban AI. It is to surround it with gates that fail explicitly.
When not to use AI
Do not use it when invoice, order, and receipt already share identifiers and stable rules; deterministic automation will be easier to test. Do not use it when supplier identity, tolerance policy, or exception ownership is missing. Repair identity and authority first.
The durable rule is: compare what is exact, propose what is ambiguous, and approve what is irreversible through a separate authority. That sequence protects control without giving up AI’s useful work.
Sources
Article topics
