What to automate in the AP cycle, and where to keep a human in the loop
Copied! A step by step breakdown of the AP cycle: what automation fully handles, what needs exception handling, and what should always stay with a named person.
Automation can capture the invoice, read it, code it, match it to a purchase order and route it for approval without anyone touching a keyboard.
It cannot decide that a partial delivery justifies paying seventy percent of an invoice, verify that a change to a supplier's bank details is real, or take responsibility for releasing money that turns out to be wrong.
Below is the AP cycle broken into nine steps, with a plain answer for each: fully automatable, partly automatable with exception handling, or stays with a person.
TL;DR
- Fully automatable: invoice receipt and capture, and approval routing.
- Largely automatable with exception handling: extraction and coding, purchase order and receipt matching, reconciliation, and month end accruals.
- Stays with a person: the approval decision itself, exception judgement, supplier conversations, and the payment release.
- Extraction breaks on a new supplier's first invoice, handwritten adjustments, angled scans and unfamiliar currency formats.
- Verify any change to a supplier's bank details through a second channel, never by replying to the email that requested it.
- Sequence adoption from capture through to payment execution last, so each step earns the next.
See how Round connects accounts payable and treasury
Is receipt and capture fully automatable?
Getting an invoice into a system, whatever format it arrives in and whatever channel it arrives through, is close to a solved problem.
Email forwarding, a dedicated inbox, supplier portals and scanned paper can all land in one place without a person doing the filing.
This step used to eat real time (chasing a missing invoice, retyping a paper one) and now mostly does not.
There is little judgement involved, which is exactly why it automates cleanly.
Can extraction and coding be automated?
Reading the supplier name, invoice number, amount, VAT and line items off a document is largely automatable now, and coding to the right cost centre and nominal code gets close when the supplier and pattern are already known.
Unfortunately though, it can break when:
- Onboarding a new supplier with an unfamiliar invoice layout
- Processing a handwritten note on a delivery invoice - a line item that could plausibly sit under two different cost centres
- A currency and VAT treatment that does not match the usual pattern.
Extraction confidence needs a threshold; below it, a person checks the read before it goes anywhere near a ledger.
PO and receipt matching: partly automatable, exception handling required
A clean three way match, where the purchase order, the goods receipt and the invoice all agree on quantity and price, is genuinely automatable and one of the highest value steps to get right, because it is also where the most silent errors used to slip through.
It breaks on partial deliveries, part credit notes, price changes agreed verbally after the PO was raised, and invoices that arrive before goods do. None of those are edge cases in most businesses; they are standard.
Someone has to decide what the correct number is when the three documents disagree, and that decision should sit with a person, not a tolerance rule nobody remembers setting.
Approval routing: fully automatable
Getting the right invoice in front of the right approver, in the right order, with a reminder if it sits too long, is a routing problem and automates well. What does not automate is the approval itself.
Exception handling: stays with a person, automation should surface it clearly
An exception is, by definition, the case the rules did not anticipate. Automation's job here is to flag it fast and with enough context that the person deciding does not have to go digging: what mismatched, by how much, against which document.
The decision itself, on whether to accept, query or reject, belongs to a named person who understands the supplier relationship and the operational reason things might not match.
Can payment execution be fully automated?
Building and sequencing the payment run is mechanical once the invoices reaching this step are accurate. Releasing it is the exception: money that has left the account is much harder to unwind than an invoice sitting in a queue, which is why the release step usually keeps a human sign off even after the mechanics are automated.
For the fuller case on why that one step stays with a person, see can an AI agent actually execute a payment, or does it only prepare one?
Reconciliation: partly automatable, exception handling required
Matching bank transactions to paid invoices is largely automatable when references are clean. It breaks on part payments, foreign currency timing differences, and a supplier who applies a payment against a different invoice than the one it was meant for. Someone still has to close out the mismatches.
Supplier queries: stays with a person
"Why haven't we been paid" is a relationship conversation as much as a data lookup. Automation can surface the answer fast (where the invoice is, what stage it is at, when the next payment run goes), which genuinely shortens the call. It cannot have the conversation, and a supplier chasing money wants to speak to someone who can actually resolve it, not a status page.
Month end accrual: partly automatable, exception handling required
Automation can flag goods and services received but not yet invoiced, based on POs and delivery records, and draft the accrual entry. Whether the estimate is right, and whether an unusual accrual needs a judgement call rather than a formula, is for the person closing the books.
Where extraction and matching fail
It is worth being specific about this, because vague reassurance is what makes AP automation sound like every other automation pitch.
Extraction struggles with documents it has not seen a pattern for:
- A new supplier's first invoice
- A handwritten adjustment
- A scan taken at an angle
- A currency symbol the system has not been configured for.
Matching struggles at the boundary of "close enough":
- A delivery three units short
- A credit note applied to the wrong invoice number
- A price that changed in a phone call nobody logged.
These are not rare failure modes in a growing business with dozens of suppliers and several entities. A system that pretends they do not happen is not more advanced, it is just less clear about where the join is between the machine and the person checking it.
Fraud and control: what actually reduces risk
None of this removes the need for basic financial control, and no automation should be sold as if it does. Good practice that holds regardless of which tools a business uses:
- Verify any change to a supplier's bank details through a second channel, such as a phone call to a known number, never by replying to the email that requested the change.
- Keep segregation of duties: the person who codes an invoice should not also be the person who releases the payment.
- Require dual approval above a set threshold, and make sure that threshold is reviewed, not left at whatever number was set on day one.
- Review the exception queue regularly. An exception that sits unresolved for weeks is not a productivity problem, it is a control gap.
Automation can enforce these consistently, which matters, because a manual process only works as well as the least careful person on the busiest day.
What it cannot do is replace judgement. A convincing fake invoice from a name that looks right, or a bank detail change that arrives from a compromised but genuine-looking supplier email, still needs a person who knows to be suspicious and is prepared to make the call.
Records: what the rules actually require
For any UK business, VAT records including invoices issued and received, credit and debit notes and general business records must be kept for at least six years, and VAT registered businesses must keep certain records digitally and file returns using compatible software under Making Tax Digital (gov.uk, Keeping VAT records; gov.uk, VAT Notice 700/22).
Whatever a finance team automates, the underlying record trail still needs to satisfy that, which is one more reason exception handling should leave a clear log rather than a silent override.
How to sequence adoption without a big rollout
The teams that get burned are the ones that automate payment execution before extraction is reliable. Get the order right instead:
- Start with capture and extraction on one supplier category, ideally your highest volume, lowest complexity suppliers. Watch the confidence scores, not just the output.
- Once coding accuracy is solid, add matching for suppliers with a clean PO process. Leave the messy ones (part deliveries, verbal price changes) in manual review deliberately.
- Add approval routing once the invoices reaching approvers are accurate enough that approvers trust what they are looking at. Trust, once lost here, is slow to rebuild.
- Automate payment execution last, and keep a human release step for anything above a threshold or to a payee the system has not paid before.
- Bring reconciliation and accrual automation in once the upstream steps are producing clean, well-referenced data for them to work with.
Each step should earn the next one, not because the technology needs time, but because the people relying on it need evidence before they hand over the next decision.
Where does Round Treasury fit, and where does it not?
Round Treasury connects treasury, accounts payable and related finance work as one operating layer, and the automation described here (capture, extraction, matching, routing, execution) is the kind of work it is built to prepare, read and surface exceptions on.
Named humans retain consequential approval throughout: coding confirmations, exception decisions and payment release all sit with a person, by design, not as a gap still being closed.
If a finance team's current pain is scattered tools that do not talk to each other, that fit is real. If the actual problem is a headcount decision, or a supplier relationship that needs rebuilding, no AP tool changes that on its own, and it is worth being clear about which problem is in front of you before choosing a system.
For the mechanics of how the extraction and matching layer works underneath these steps, see how AP automation actually works under the hood. For a comparison of current tools in this space, see the current AP and spend management software landscape in the UK.
Sources
Frequently Asked Questions
No. Capture, data extraction, matching and payment execution can run with very little human input once the setup is right. Judgement calls, such as approving an exception, verifying a change to a supplier's bank details, and owning the final release of a payment, need a named person. The mix shifts over time; the need for a person on consequential decisions does not go away.
Matching. A three way match between purchase order, goods receipt and invoice works cleanly when the delivery, the paperwork and the order all line up. Partial deliveries, part credit notes, price amendments after the PO was raised and invoices that arrive before the goods do all break a clean match, and someone has to decide what the correct number actually is.
Automation can enforce a process consistently, such as requiring dual approval above a threshold or flagging a change to supplier bank details before a payment goes out. It does not prevent fraud on its own. Verifying a genuine change of bank details, or catching a convincing fake invoice, still needs a person who knows the supplier and is prepared to pick up the phone.
At least six years, under HMRC's VAT record keeping rules, which cover invoices issued and received, credit and debit notes, and general business records. Records can be kept digitally, and VAT registered businesses must keep certain records in digital form under Making Tax Digital, using software that connects to HMRC (gov.uk, Keeping VAT records).
Start with capture and extraction on one supplier category, get coding accuracy solid, then add matching, then routing, then payment execution. Each step should earn trust before the next one goes live. A team that automates payment execution before extraction is reliable is building the fastest possible route to paying the wrong amount to the wrong supplier.
