What this covers
- Three-way matching is a rule set, which is why an agent can apply it consistently and a person cannot, at volume.
- Coding is the step that eats the most time and is most often treated as tribal knowledge rather than a rule.
- Duplicate detection and approval routing are controls that get stronger under automation, not weaker.
- The agent prepares the payment decision. It should not make it, and the separation should be visible in the log.
Accounts payable has a reputation as a back-office cost center, which undersells what it actually is: the last checkpoint before the company parts with money. Every step in it exists because somebody once paid for something twice, or paid a price that was never agreed, or paid for goods that never arrived.
That is the reason it automates well. A workflow built entirely out of checks is a workflow where correctness is defined. The agent is not being asked to exercise judgment; it is being asked to apply rules that already exist, to every invoice, without getting tired at four in the afternoon on the last day of the month.
Where the time actually goes
Ask a finance team what takes the longest and the answer is rarely the matching. It is the chasing and the coding.
| Step | Why it takes time | Automatable |
|---|---|---|
| Capture | Invoices arrive in a shared mailbox, as attachments, sometimes on paper | Fully |
| Extraction | Every supplier has a different layout, and totals sit in different places | Fully |
| Matching | Finding the purchase order and the receipt, then comparing line by line | Fully, where the PO and receipt exist |
| Coding | Deciding the account, cost center and tax treatment, often from memory | Largely, once the rules are written down |
| Chasing approval | Finding who should approve and reminding them | Fully, and this is often the largest saving |
| Resolving a mismatch | Establishing what actually happened between three documents and two departments | Partly: the agent prepares it, a person decides |
Three-way matching, done consistently
The principle is simple: the invoice should agree with the purchase order on price and with the goods receipt on quantity. In practice it is a set of comparisons with tolerances, and it breaks in a small number of recognizable ways.
- A price difference within tolerance, which posts with the variance recorded.
- A price difference outside tolerance, which stops with both figures and the purchase order line shown.
- A quantity short-delivered against an open purchase order, which is a partial receipt rather than an error.
- A freight or surcharge line that never existed on the purchase order, which is the single most common mismatch.
- An invoice with no purchase order at all, which is a policy question rather than a matching problem.
Each of those has a correct handling that finance can state. Writing them down converts a stream of exceptions into a stream of routine cases with a small held queue, which is what the automation is actually for.
Coding, and the knowledge nobody wrote down
General ledger coding is where the tribal knowledge lives. The person who has done AP for eleven years knows that invoices from this supplier go to that cost center unless the reference starts with a project code, in which case they go somewhere else. None of that is documented, and it walks out of the building when they retire.
An agent codes by combining the same signals that person uses: the supplier, the purchase order and its requisitioner, the line descriptions, the cost center on the receipt, and how invoices from this supplier were coded historically. Where the signals agree, it codes. Where they conflict, it proposes with the evidence and lets a person confirm.
Automating the coding forces the rule to be written down. That is worth something on its own, whatever happens to the automation.
The controls that get stronger
This is the part of the argument finance teams usually have not heard, and it is the part that matters most to them.
- 01Duplicate detection
A person catches a duplicate when they remember seeing it. An agent compares every incoming invoice against the full history on supplier, number, amount and date, including near-matches where a digit differs or the same invoice arrived as a scan and a PDF.
- 02Approval routing
Routing by amount, cost center and category is applied the same way every time, rather than depending on who picked the invoice up. Delegations and absences are handled by rule rather than by forwarding.
- 03Segregation of duties
The agent prepares and codes. It does not approve its own work and it does not release payment. That separation is enforced structurally rather than by policy.
- 04The audit trail
Every invoice carries the source document, what was extracted, which purchase order and receipt it matched, which tolerance applied, who approved it and when. Reconstructing a transaction stops being an exercise in interviewing people.
What the agent must not do
Being explicit about this is what makes the rest credible.
- It does not release payment. It prepares invoices for the payment run your process already uses.
- It does not approve invoices above the thresholds you set, however confident it is.
- It does not create or modify supplier master data, which is where payment fraud lives.
- It does not delete or reverse a posted transaction. Corrections go through your normal process.
- It does not pay an invoice with no purchase order where your policy requires one. That is a policy exception and it goes to a person.
The third item deserves emphasis. Supplier bank detail changes are the highest-value fraud target in the entire finance function, and they should never be inside an automation's write surface. The security review checklist covers how to scope that.
Measuring it
Cost per invoice is the traditional metric and it is a poor one on its own, because it hides where the time went. Four numbers are more useful.
- 01Straight-through rate: invoices matched, coded, approved and posted with no human touch.
- 02Days from receipt to posting, measured from the email timestamp, which is what determines whether you capture early payment terms.
- 03Held-case reasons, grouped. A single supplier generating a quarter of your exceptions is a supplier conversation, not an automation problem.
- 04Duplicates and mismatches caught, which is the control value rather than the efficiency value.
The third is the one that tends to surprise people. Grouping held cases by reason usually reveals that a small number of suppliers, or a single missing rule, account for most of the manual work. That finding is often worth more than the automation.
The Finance Agent sets out what is built before a project starts and what is configured against your chart of accounts, tolerances and approval matrix.