Accounts payable automation where a changed bank detail stops the payment run
Supplier invoices from arrival to a bill ready to pay: captured, matched to the supplier and any purchase order, routed to the right approver, posted to the ledger by API, with bank-detail changes verified separately and a person confirming anything irreversible.
Accounts payable automation is usually sold on capture: send the invoices in and watch the fields fill. The questions finance teams ask first are different. What happens when a supplier's bank details change? Who can approve what, and up to how much? What does the AI decide on its own? This page answers those first, because a system that reads invoices quickly and then pays a fraudster's account once has failed at the only part that mattered.
Two of our builds cover parts of AP. On a trading group's ERP, supplier invoices are photographed and read by a vision model, a person's confirmation creates the purchase invoice and moves the supplier balance, and invoices move from draft through approval to paid, with nothing counted as owed until it is approved. On a UK commercial solar installer's operating system, each person has a spend policy on purchase orders, over-limit orders route to finance, a director or operations, goods are received against order lines and invoices are matched against what was ordered and delivered. Neither build included bank-detail change controls or posting to Xero or QuickBooks Online, and no published case study of ours covers a named accounting package. Where this page describes those, it is the design we would build, and it says so.
Three of our pages touch supplier invoices, so to be clear about which is which. This one owns the whole payables process and its controls, from the invoice arriving to the bill being ready to pay. AI invoice processing covers the capture step on its own: a model reading the document and a person confirming it. Finance workflow automation covers approvals, reconciliation and chasing across finance generally, not only payables. If your only problem is that typing invoices is slow, the invoice page is the shorter read.
The AP process, stage by stage, and who decides at each one
Ten stages from an invoice arriving to a bill ready to pay. The two right-hand columns are the point: what stays with a person, and the control that holds whoever is at the keyboard.
| Stage | Runs on its own | A person decides | The control |
|---|---|---|---|
| Capture | Invoices collected from one AP inbox, uploads and photographs, and structured e-invoices where suppliers send them | Nothing at this stage | Every document stored once, with a hash, before anything reads it |
| Extraction | A model reads PDFs, scans and photographs. Structured e-invoices are parsed by code, not read by a model | Any field the checks flag | Output parsed against a schema, and line items must sum to the stated total |
| Supplier match | Matched to a supplier you already hold, on a stored identifier first and the name second | Near matches and anything that looks like a new supplier | A new supplier is never created from an invoice alone |
| Duplicate check | The same file, or the same supplier, invoice number and amount, is held | Whether a held item is a true duplicate | A held invoice cannot reach a payment run |
| PO matching | Where there is a purchase order, lines are matched to what was ordered (two-way) and received (three-way) within your tolerances | Anything outside tolerance | No PO means no automatic match: the invoice goes to its approver |
| Approval | Routed by amount, supplier and cost centre to the person whose limit covers it | The approval itself | Unapproved invoices are not counted as owed, and nobody approves their own request |
| Bank details | Nothing. A difference between the invoice and the supplier record raises an exception | Every change, verified out of band and approved by a second person | The supplier is held out of payment runs until the check is recorded |
| Posting | An approved bill is written to the ledger through its API with a stable key | Mapping decisions at set-up, and any write the ledger rejects | A retry cannot create a second bill |
| Payment run | A proposed run is prepared from approved, unheld bills due in the period | Releasing the payment, in your bank or your ledger | Nothing we build moves money without a person |
| Audit | Every step, change and decision recorded with who and when | Nothing | Append-only: the log cannot be edited through the application |
A changed bank detail stops the line until someone has checked it
The failure finance teams fear most is not a misread total. It is an email, apparently from a real supplier, asking you to pay a new account, and a process that quietly does. A schema cannot catch it, because an attacker's sort code and account number are perfectly valid fields. So the rule does not live in the extraction. It lives on the supplier record.
Three controls, all of them simple. Out-of-band verification: a change is confirmed by calling the supplier on a number already on file, never one given in the request. A hold: once the details change, that supplier is left out of payment runs until the verification is recorded. Four eyes: the person who enters the change cannot be the person who approves it, and the system enforces that rather than trusting someone to remember it.
The model never writes bank details. If an invoice carries payment details that differ from the supplier record, that is an exception for a person, not an update. To be straight about the evidence, neither case study built these controls. They are what we would build, and they follow the rule our article on securing AI agents gives for any system that reads invoices: a change of payment details always needs a person and a separate check.
Four ways invoices arrive, and which of them need a model
The channel decides whether a model is involved at all. One queue behind all four is what lets the controls see everything.
A dedicated AP inbox
Suppliers send to one address. Attachments are stored before anything reads them, the email body is kept as context but never treated as an instruction, and a message with no invoice in it goes to a person rather than being ignored. Anything that reads email is reading content outsiders can write, so the step that reads it has no way to pay, send or change a supplier.
PDFs, scans and photographs
This is where a model earns its place. On the trading ERP, staff photograph a supplier invoice, a vision model reads the line items and a person confirms before anything is written. Poor scans and handwriting are the hardest inputs, so test them on your own documents before relying on it. Our AI invoice processing page covers this step in detail.
Structured e-invoices
Some suppliers can send invoices as structured data, for example over the Peppol e-invoicing network in the countries that use it. There is nothing for a model to read: the file is parsed by code, which is cheaper and gives the same answer every time. Intake that can only read images is a design you will rebuild.
Paper that still comes by post
Someone scans or photographs it into the same intake, and from there it follows the same path as everything else. The aim is one queue, so nothing is processed in a side channel that the duplicate check, the approval routing and the bank-detail rule never see.
Matching to suppliers, to earlier invoices and to purchase orders
Matching is where most payables errors are caught, and none of it needs a model. It needs records you trust and rules you have written down.
- 01
Suppliers matched on an identifier first
Match on something stored, such as a tax number, a supplier code or an email domain you have confirmed, and fall back to the name only after that. A name that nearly matches offers the existing supplier rather than creating a new one. QuickBooks Online requires display names to be unique across customers, vendors and employees, so a flow that creates a vendor for every unfamiliar name collides with a customer of the same name or fills the list with near-duplicates.
- 02
Duplicates held, not deleted
The same file is caught by its hash before anything reads it. The same invoice sent again as a different file is caught on supplier, invoice number, date and amount, and near-misses such as a transposed digit or a dropped prefix go to a person rather than being guessed. A held invoice cannot reach a payment run until someone clears it. On the fleet-telematics order system a resent document updates the existing row instead of creating a second one, and bills deserve the same rule.
- 03
Two-way and three-way matching where there is a PO
Two-way matching compares the invoice with the purchase order. Three-way adds what was actually received. On the solar installer's system, goods are received against order lines with partial deliveries tracked, and an invoice is matched in one click against what was ordered and delivered. Price and quantity tolerances are yours to set, and anything outside them goes to a person.
- 04
No PO is a route, not an error
Plenty of legitimate spend has no purchase order: utilities, subscriptions, professional fees. Those invoices skip matching and go to the approver for that supplier or cost centre. Forcing a PO onto them produces purchase orders raised after the invoice, which is a control in name only.
- 05
Part payments and credits kept visible
On the trading ERP invoices move through unpaid, partial and paid, so a part-paid bill stays on the list until it is settled. We treat a credit note the same way, as a reduction of what is owed to that supplier, rather than a separate line someone has to remember to net off.
Approval routing with limits the system enforces
An approval that is only a button is a status. An approval that changes what is owed is a control. On the trading ERP, drafts and invoices under review are excluded from purchases and outstanding totals until they are approved, on the lists and on the dashboard. On the solar installer's system, each person has a spend policy, the order wizard shows before submission whether an order will auto-approve, and over-limit orders route to finance, a director or operations.
For payables, that becomes a small set of rules we write down with you before anything is built:
- Thresholds by amount, with a second approver above a level you set.
- Routing by supplier, cost centre or project, so the person approving knows what the spend was for.
- No self-approval. Whoever raised the purchase order, added the supplier or changed the bank details cannot approve the same item.
- Escalation when an approval sits too long. The fleet order system runs a business-day clock against a real public-holiday calendar and escalates on its own. We have not applied it to approvals, but it is the mechanism we would use.
- Who may approve is a permission enforced in the write layer and the database, not a hidden button. On the trading ERP a database trigger stops a non-administrator changing their own role or permissions.
Auto-approval is possible for narrow, low-risk cases, such as a matched invoice from a known supplier, inside tolerance and under a limit. We would switch that on only after measuring how often those cases needed a correction on your own invoices, and never for a supplier whose details have recently changed.
Posting to Xero, QuickBooks Online and other ledgers
The ledger stays the system of record for the accounts. What we build sits in front of it: intake, matching, approval and the controls, then one keyed write per approved bill. In Xero's accounting API a bill is an invoice of the payable type, and each invoice declares whether its line amounts include or exclude tax. A flow that assumes one basis while the source carries the other produces totals wrong by the tax, or a few pence out on rounding, so the basis travels with every amount and totals are checked before posting.
QuickBooks Online has its own rules. An update to an existing record must carry that record's current sync token or it is rejected as stale, which decides how you design any flow that edits a bill after it is created. Its refresh tokens rotate, and Intuit advises storing the newest one every time; a flow that keeps using an old one eventually loses the connection. QuickBooks Desktop uses a different integration model altogether, so it is a separate conversation.
- Idempotent writes: a stable key per bill, so a retry after a timeout cannot post it twice.
- The target organisation chosen explicitly. A Xero connection can reach more than one organisation, and a flow that assumes the first one posts to the wrong books.
- Connections watched. Accounting connections run on OAuth and can lapse when unused or when the person who connected them leaves. A failed post alerts a named person, and a daily check compares counts on both sides.
- Other ledgers, such as Sage, MYOB, FreeAgent or an ERP's own API, follow the same pattern, scoped against your specific product and plan, because features differ between them.
The exceptions queue, the audit trail and what we leave manual on purpose
A person confirms anything that could not be quietly reversed next week. Everything else can be automated, once it has been measured.
One exceptions queue
Every item the system will not decide (a flagged field, a near-duplicate, a price outside tolerance, a new supplier, a bank-detail mismatch) lands in one queue with the reason stated and the source document beside it. The queue is how you see the system working, and its size is a number worth watching.
Irreversible steps
Releasing a payment, changing supplier bank details, writing off a balance and deleting anything are confirmed by a person every time. The model proposes at most. Writes to the books happen on a confirmation, as on the trading ERP, where the confirmation is what creates the purchase invoice.
An audit trail that outlives the application
On the trading ERP every write stamps the acting user and appends a field-level diff to an append-only table that staff can read and insert into but never update or delete. Deleting sets a timestamp and the audit entry outlives the record. For payables that answers who approved this bill, who changed this supplier and what it was before.
Left manual at first
Supplier disputes, one-off foreign payments, anything your auditor has a view on, and the exception that comes up twice a year. Each could be automated later and none repays the build on day one. We also do not do the accounting: tax treatment and the judgement behind it stay with your accountant.
Accounts payable automation, invoice processing or finance workflow?
If the problem is the whole payables process and whether it can be trusted, you are on the right page. The other two are narrower or wider, and each links back here.
| If the problem is | Read | What it covers |
|---|---|---|
| Typing invoices in takes too long | AI invoice processing | Capture: a model reads the invoice, validation catches the bad reads, a person confirms |
| Payables end to end, and whether the controls hold | Accounts payable automation (this page) | Intake, matching, approval routing, bank-detail controls, posting, exceptions and audit |
| Approvals and reconciliation across finance generally | Finance workflow automation | Approvals that gate the totals, one ledger, chasing, and an honest note on month-end |
What moves the estimate for AP automation
Most of our projects land between $5,000 and $10,000 (US dollars). Larger systems cost more than $10,000. That is a typical range, not a quote: we quote after a discovery conversation, and neither case study states a price or a duration, so the range is not attributed to them. Model usage for reading documents is a running cost on top, estimated from a sample of your invoices. What moves the build estimate:
- How invoices arrive, and how many arrive as images rather than structured data.
- Whether purchase orders and goods received exist, and whether they are reliable enough to match against.
- How many ledgers, organisations or entities the bills have to land in.
- How many exceptions a normal month produces. Not what usually happens, but last month: what did somebody touch by hand, and why?
- Whether your approval limits and supplier-change procedure exist on paper, or have to be agreed first.
When to buy an AP product instead of having one built
Buy by default. If your accounting package's own bill capture and approvals, or an AP product built on top of it, handles your documents and your approval rules, use it; building next to it creates a reconciliation. Building is justified where payables has to work with something a product cannot reach: purchase orders and goods received in your own operations system, stock and cost prices that move on confirmation, approval rules that depend on project or site, or a ledger the product does not support.
It is also the wrong answer at low volume, where a person entering a few invoices a week costs less than maintaining the system, and wherever nobody will own the exceptions queue. A queue nobody reads is worse than no automation at all, because it looks like a control.
Related projects that were not this job
Here for the argument rather than as evidence of this exact work. Each one bears on a decision above, and the note says which.
- A fleet-telematics providerOrders that file themselves, and an SLA clock that never forgetsNot a payables build. It is here for two mechanisms an AP system needs: an inbound document parsed and matched against existing records so a resend updates the row instead of creating a second one, and a business-day clock that escalates on its own, which is how an approval nobody has actioned would be chased. We have not applied either to supplier invoices.Case study
- Skofi OutreachSkofi Outreach: deliverability rules the database refuses to breakNot a finance build. It is our argument for putting the rules that must never break into the database as constraints rather than into application code, which is where a rule such as no payment to a supplier with unverified bank details belongs.Case study
Related reading
Neighbouring solutions
Accounts payable automation, specifically
Software that takes a supplier invoice from arrival to a bill ready to pay with as little typing as possible: capture, extraction, matching to the supplier and any purchase order, approval routing, posting to the ledger and a proposed payment run. The part that decides whether it can be trusted is the controls around it. A person confirms anything irreversible, bank-detail changes are verified separately, and every step is logged.
With three controls that do not depend on the model. Any change is verified out of band, by calling the supplier on a number already on file and never one in the request. The supplier is held out of payment runs until that check is recorded. And the person who enters the change cannot approve it. An invoice that carries different payment details from the supplier record raises an exception and never updates the record.
Both have public APIs and posting an approved bill is a well-defined job, so it is feasible to scope. We have no published case study for either, so we prove the riskiest write against a test organisation or sandbox company first. The details that matter are Xero's tax-inclusive or tax-exclusive line amounts and the choice of organisation, and QuickBooks Online's sync tokens, unique display names and rotating refresh tokens.
Yes, three-way matching compares the invoice with the purchase order and with what was received, so it needs both. Without a PO the invoice goes to the approver for that supplier or cost centre instead, which is the right route for utilities, subscriptions and professional fees. On the solar installer's system we built, goods are received against order lines and invoices are matched in one click against what was ordered and delivered.
Two ways. The same file is caught by its hash before anything reads it. The same invoice sent again as a different file is caught on supplier, invoice number, date and amount, with near-misses flagged for a person rather than guessed. A held invoice cannot reach a payment run until someone clears it.
No. A model reads the documents that need reading and proposes; code checks the arithmetic and the matches; a person approves, and a person releases payment. Auto-approving narrow, low-risk cases, such as a matched invoice from a known supplier inside tolerance, can be considered once accuracy has been measured on your own invoices, and never for a supplier whose bank details have recently changed.
Buy first if a product handles your documents, your approval rules and your ledger. Build when payables has to work with something a product cannot reach, such as purchase orders and goods received in your own operations system, stock and cost prices that move on confirmation, or approval rules that depend on project or site. We will say which side you are on in the first conversation.
Most of our projects land between $5,000 and $10,000 (US dollars). Larger systems cost more than $10,000. That is a typical range, not a quote: we quote after a discovery conversation. What moves the number is how invoices arrive, whether purchase orders and receipts exist to match against, how many ledgers or entities are involved, and how many exceptions a normal month produces. Model usage for reading documents is a running cost on top.
Sources
Statements about what a platform, regulator or provider says come from their own pages. Rules and limits change, so check the current page before you rely on one.
- Invoices · Xero Developer
- 5010 - Stale Object Error · Intuit Developer
- 6240 - Duplicate Name Exists Error · Intuit Developer
- Handling OAuth token expiration with the QuickBooks Online API · Intuit Developer
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Tell us about the process that keeps costing you.
A 15-minute call is usually enough to say whether this is an automation, an integration, or something that should be built, and whether we are the right people for it.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no