Matching invoices against orders, and sending only the exceptions to a person
Most invoices are routine and a minority need judgment, but the routine ones are usually what consumes the team. Modeled as an orchestrated process, extraction and matching run unattended, the policy decides what may post on its own, and a person sees only what actually falls outside tolerance — with the reasoning already assembled.
A reference architecture: how RoboAgentix would model this process on UiPath. It is not a description of a delivered project, and no client, result or metric is implied.
What starts it
An invoice arrives from a supplier portal, a shared mailbox, or an inbound queue on the ERP.
Why it is orchestrated rather than scripted
- An invoice can sit waiting on an approver or a blocked period-end for longer than any single automation run.
- Tolerances and approval limits differ by entity and category, and should be one rule rather than branching logic in a robot.
- Matching is the step most often questioned later, so the comparison and its sources have to be reconstructable.
How it runs on UiPath Maestro
The process is defined in BPMN and Maestro runs it across agents, robots and people, holding its state for as long as the work takes — including while it waits on an approver.
Step by step
- 01
Invoice arrivesSystem
From a supplier portal, a shared mailbox, or an inbound queue on the ERP.
- 02
Read the documentRobot
The invoice is digitized and returns header fields, totals and line items, each with a confidence score.
- 03
Match against the orderAgent
Prices, quantities, tax treatment and contract terms are compared against the purchase order and the agreement, citing the records used.
- 04
Within tolerance?Maestro
The orchestrator routes on the match result, the tolerance for that category, and the approval limit for the amount.
- 05
Review the exceptionPerson
Anything outside tolerance reaches a named approver with the agent's comparison and the source documents attached.
- 06
Post to the ledgerRobot
The approved invoice is posted against the correct account and cost center under least-privilege credentials.
- 07
Posted and loggedSystem
The posting reference, the match evidence and any approval are written to the audit record.
What each agent is allowed to decide
An agent is only useful in a governed process if its authority is written down. Each one below has a defined input, a decision it may make on its own, and the condition that obliges it to hand over.
Matching Agent
Compares the invoice against what was ordered and what was agreed.
Reads
- Extracted invoice fields and line items
- The purchase order and goods receipt
- Contract pricing and payment terms
- Tax treatment rules for the entity
Decides on its own
Must escalate when
Coding Agent
Proposes the account and cost center for each line.
Reads
- Chart of accounts
- How comparable lines were coded historically
- The requesting department on the order
Decides on its own
Must escalate when
What the robots do
Deterministic steps stay with robots — the same action every time, including in systems that never exposed a usable API.
Extraction robot
Digitizes the invoice and normalizes supplier-specific layouts into one structure.
Runs in
Posting robot
Posts the approved invoice and writes back the reference.
Runs in
Within tolerance?
Every line matched within the category's tolerance, a valid order exists, and the total sits under the approval limit for that entity.
- Passes
- Posted without a person touching it.
- Does not pass
- Held for review, with the process kept open while it waits.
Modeled as a decision table, so the threshold can be changed by the people who own the policy without redeploying an automation.
The human step
Who
What they see
What they decide
People are in this process because judgment or authority belongs to them — not as a fallback for a step that failed.
What this design deliberately does not do
An automation is only trustworthy if its limits are written down as plainly as its capabilities.
- It does not amend a purchase order to make an invoice match. Where the order is wrong, the order is corrected by the buyer who owns it, and the instance waits for that rather than adjusting the comparison.
- It does not release payment. The design ends at a posted document; the payment run, its timing and its bank file stay under treasury control.
- It does not act on bank details taken from the invoice. A change of supplier bank account is a supplier master change with its own approval, and the posting robot reads account details from the master record, never from the document.
- It does not set tolerances, approval limits or the list of restricted accounts. Those are DMN entries owned by finance; the process reads the version in force at the moment it evaluates the gate.
Failure has a defined path
Systems go down, confidence drops, approvers go on leave. Each of these is a modeled branch rather than a stuck instance.
- The ERP, the purchase order system or the contract repository is unreachable when matching starts.
- The instance holds at that step instead of failing the invoice. Orchestrator retries the queue item on its schedule while Maestro keeps the state, and once a defined wait is exceeded the instance is marked blocked and appears on the accounts payable exception list with the system named. The received date captured at arrival is what payment terms are later calculated from, not the date the retry succeeded.
- A field comes back below its extraction threshold, or the Matching Agent cannot resolve the tax treatment from the contract.
- An unresolved comparison is treated as a failed check, not a pass. The instance routes to Action Center with the specific lines and fields it could not settle marked as unresolved, and the partial comparison is presented as partial rather than shown as a completed match.
- The named approver does not act on an exception.
- Nothing posts on a timeout. After the interval finance defines, the task is reassigned down the delegation chain configured for that entity, and the original assignee remains on the instance record so the delay is attributable rather than absorbed.
- The same invoice arrives twice — resubmitted by the supplier, or forwarded from a second mailbox.
- A duplicate check on supplier, invoice number, date and amount runs before matching. A suspected duplicate is attached to the existing open instance instead of opening a new one, and neither copy proceeds to posting until a person confirms which document is the invoice of record.
Data, rollout, and what to watch
Data it touches
- Supplier bank details and any personal contact data on the invoice are masked in the Action Center task and withheld from the agents' inputs. The approver sees enough to identify the supplier; the posting robot resolves the account from the supplier master under its own credentials.
- Inbound mail is parsed at the queue rather than carried whole into the process. The invoice and its supporting attachments are attached to the instance; the message body, unrelated attachments and the mailbox thread are not.
- Invoice images, extracted values and instance state stay in the region the deployment is configured for, and retention follows the finance record-keeping period the organization already applies to invoices rather than a separate automation retention clock.
- Context Grounding indexes the contract terms, tax rules and coding policy the agents cite — not the invoices themselves. Historical coding is read through a connector at the moment it is needed, so one supplier's invoice does not become reference data an agent recalls while reading another's.
How it goes live
- 01
Shadow
The process runs alongside the existing accounts payable route on live invoices. Extraction, matching and the coding proposal are produced and stored against each instance, but nothing posts and no task is assigned. The gate to the next phase is qualitative: the team walks through the cases where the agent's comparison differed from the conclusion they reached themselves, by category and by supplier, until each class of disagreement is explained rather than merely listed.
- 02
Supervised
Every instance is assigned in Action Center, including the ones that cleared the gate, and posting happens only on a person's decision. What approvers confirm, amend or reject is what tolerances, approval limits and restricted accounts are then written from. The gate is per entity and per category: finance sets the DMN values and names which categories may run without a person.
- 03
Unattended with exceptions
Invoices that clear the gate post without a person; everything outside it routes as designed. Scope stays an explicit list of the entities and categories finance approved, and widening it is a DMN change with a named owner and a dated record, not a redeployment.
Signals worth watching
- The share of invoices that reach a person, broken down by which check held them — tolerance, missing order, unresolved tax treatment, low-confidence coding — and whether that mix is shifting.
- How often an approver amends the Coding Agent's account or cost center proposal before posting, and whether the amendments cluster on particular suppliers, departments or account ranges.
- Extraction confidence per field grouped by supplier layout, which is where a supplier quietly changing its invoice template shows up first.
- How long an exception sits in Action Center before a decision, by approver group and by entity — an aging queue usually means the delegation chain names the wrong person rather than that the volume rose.
Named without target values. What good looks like depends on your volumes and your risk appetite, and is set with you rather than asserted here.
The UiPath components this design uses
UiPath Maestro
Runs the BPMN process and holds its state for as long as the work takes, including while it waits on a person or a system that is down.
UiPath Agent Builder
Where each agent is defined — its instructions, its tools, its inputs and outputs, and the escalation that sends work to a person.
UiPath Document Understanding
Classification and field extraction, returning a confidence score per field that the policy gate can route on.
Context Grounding
A retrieval index over your own policies and reference data, so an agent cites the rule it applied instead of recalling it.
UiPath Action Center
Where a human step actually lands. The approver gets a task with the agent's reasoning and sources attached, and the process resumes on their decision.
UiPath Orchestrator
Schedules the robots, holds queues and retries, and issues the least-privilege credentials each automation runs under.
UiPath Integration Service
Connectors to the systems of record, so the process talks to them through a maintained integration rather than a bespoke script.
Systems it touches
- ERP or finance system
- Purchase orders and goods receipts
- Contract repository
- Supplier portal or mailbox
What the run leaves behind
- The invoice as received and every field extracted from it
- The line-by-line comparison and the records it was compared against
- Who approved an exception, why, and when
- The posting reference written back to the ledger
Other representative workflows
Talk to us about a process like this.
The most useful first conversation is about a real process — where it stalls, who approves what, and which systems it touches.