Invoice exception handling, end to end

The shape of the problem

A finance team receives invoices in every format a supplier can invent. A rules-based pipeline handles the ones that match a known template and rejects the rest into a queue that a person works through by hand. The rejected pile is small by count and large by time.

How the pattern applies

An agent sits behind the existing pipeline rather than replacing it. Anything the rules already handle stays with the rules, because they are cheaper and completely predictable. The agent only sees what was rejected.

For each rejected document it extracts the fields, reconciles them against the purchase order, and takes one of three actions inside a defined boundary: post it when everything matches, hold it with a specific reason when a value is outside tolerance, or escalate to a person with its reasoning attached when it cannot resolve the discrepancy at all.

What the boundary looks like

• Alone: extraction, reconciliation, posting where the match is exact and the amount is under an agreed threshold.
• Escalate: any mismatch against the purchase order, any supplier not seen before, any amount over the threshold.
• Never: modifying the purchase order, creating a supplier record, approving outside the tolerance.

How it would be verified

Shadow mode against the live rejection queue while the team continues to work it manually, comparing the agent’s decision against the human decision on every document. Authority is granted only for the categories where they agree, starting with the narrowest.