Accounts payable automation using RPA automates the interface rather than the process. A bot drives the same screens a clerk drove, so every vendor UI change breaks it and the exception queue survives intact. Document understanding, data-level matching and API write-back to the ERP replace it. RPA still earns its place bridging systems with no API.
What accounts payable automation using RPA actually does
Robotic process automation is software that operates other software the way a person does, through the user interface. An RPA tool records or is configured to click, type, tab, scroll and read from screens. In accounts payable that means a bot opens the shared mailbox, opens the PDF, reads the fields, opens the ERP transaction, types the header, types the lines, clicks post, and moves the email to a folder.
The vocabulary matters because it tells you where the automation lives. An attended bot runs on a person's desktop and waits for them to trigger it. An unattended bot runs on a server or a virtual desktop without a human present, scheduled and dispatched by an orchestrator. A selector is the addressing scheme the bot uses to find a control on a screen: a stored description of the button, the field, the grid cell. Screen scraping is reading values off rendered pixels or off the accessibility tree rather than from a data source. All four are UI automation. None of them touch the process.
That distinction is the whole argument of this article. Robotic process automation accounts payable projects are usually sold as process automation, and they are not. They are interface automation, and the interface is the least stable thing in your finance stack.
A second definition worth stating plainly, because vendors blur it: accounts payable invoice workflow automation means the routing, approval, matching and posting of an invoice as a series of data operations. A workflow engine moves records. A bot moves a mouse. Those are different products with different failure modes, and a lot of accounts payable automation technology sold in the last decade wrapped the second in the language of the first.
The architectural reason accounts payable automation using RPA breaks
The failure is not bad engineering. It is the addressing model.
UiPath's own product documentation describes a selector as an XML fragment that stores "the attributes of a graphical user interface element and its parents", and then states the constraint directly: "It is important to pick attributes with a constant value. If the value of an attribute changes each time the app is started, then the selector will not be able to correctly identify the element." The same page concedes that "some software programs have changing layouts and attribute nodes with volatile values, such as some web-apps" and that the studio "cannot predict these changes". That is the honest account of the category, published by the market leader, in UiPath's selectors documentation.
Read that constraint against your AP stack. Your ERP is on a quarterly cloud release cadence you do not control. Your supplier portals are web apps owned by your suppliers. Your bank portal changes when the bank's security team says so. Your invoice inbox is a Microsoft product that redesigns twice a year. Every one of those is a "changing layout with volatile attribute values", and every one of them sits on the critical path of an invoice.
So the bot holds a contract nobody signed. It depends on a screen staying the shape it was on the day someone recorded it, and no vendor in that chain has ever promised that. This is what brittle automation means in practice: not that the code is fragile, but that the dependency is unowned.
Why does a bot that worked on Friday fail at month-end close?
Because the load pattern changes and the bot's assumptions are timing assumptions. A selector that resolves in 400 milliseconds on a quiet Tuesday times out when the ERP is carrying a close workload and the screen paints in four seconds. A grid that showed twenty rows shows eighty and the bot clicks the wrong line. A modal that never appeared in testing appears because a period is locked. A session drops and the orchestrator restarts the job from the top, against an invoice that has already been half-posted.
The worst version is silent. The bot does not throw. It reads a blank field as an empty string, codes the invoice to a default cost centre, and posts. You find it in the accrual review, three weeks later, in a period you have already reported.
Note what the failure mode has in common with the success mode: both go through the screen. There is no version of this architecture where the bot knows what an invoice is. It knows where the number usually appears.
Where the maintenance burden actually lands
The cost that sinks these programmes is not the build. It is that every automation acquires a permanent maintenance liability on the day it goes live, and the liability does not amortise.
One bot against one screen is manageable. The arithmetic changes with the portfolio. If a bot touches six applications and each application changes materially twice a year, that bot faces roughly a dozen change events annually, most of them unannounced. Forty bots across the same estate share those applications, so a single ERP release can put a double-digit number of automations into a regression queue on the same morning. Bot maintenance stops being a task and becomes a rota.
This is why the centre of excellence model appeared. Organisations built one because the alternative was a citizen developer population shipping automations that nobody could support after the person left. The centre of excellence solved governance and created a queue. Every UI change now competes for the same small team, and the team is judged on new automations, not on the ones quietly failing in production.
There is a reporting problem underneath it. Bot uptime is easy to measure and nearly meaningless. The number that matters is invoices posted correctly without human touch, and almost no RPA programme reports that number, because the bot's own telemetry cannot see a wrong posting. It only sees whether the script finished.
The vendors have read the same evidence. SAP positioned SAP Build Process Automation as the successor to SAP Intelligent RPA and set end of maintenance for Intelligent RPA tenants at 30 June 2025, folding the bot into a workflow and business-rules product rather than keeping it as a standalone recording tool. When the platform owners themselves stop selling the recorder as the centre of the architecture, that is a signal about where the category went.
The exception queue does not shrink
Here is the test that settles most arguments in a boardroom. Before RPA, a clerk handled the invoices that did not match. After RPA, a clerk handles the invoices that did not match, plus the invoices the bot could not read, minus the keystrokes. The queue did not get smaller. It got a new inbox.
Straight-through processing is the only honest metric for this work: the share of invoices that arrive, match, code, approve and post without a person opening them. RPA improves the keystroke cost of the non-straight-through invoices. It does not convert them, because converting them requires judgement the bot does not have.
What is the difference between OCR and intelligent document processing?
Optical character recognition turns an image into characters. That is all it does. Template-based capture then tells the system where on the page to look: the invoice number lives in the box 80mm from the left and 40mm from the top, for this supplier's layout. Add a supplier, add a template. Change a layout, fix a template. It is the same brittleness as a selector, applied to paper.
Intelligent document processing extracts meaning instead of position. A model trained on invoice structure knows that a value labelled "Net 30" near a date is a payment term regardless of where it sits, that a column of numbers summing to a figure labelled total is a line-item block, and that a tax identifier has a national format. It generalises to a supplier it has never seen, which is precisely what template capture cannot do and what your long tail of non-PO spend demands.
That is the first real replacement: extraction that does not care about layout. It removes the largest single source of exceptions, which is not matching failure but capture failure on suppliers who invoice you four times a year.
Step by step: what RPA does, how it fails, and what replaces it
This is the teardown. Each row is one step in accounts payable invoice workflow automation, what a bot is typically configured to do there, the specific failure mode, and the mechanism that replaces it.
| Process step | What the RPA bot does | How it fails | What replaces it | Why the replacement holds |
|---|---|---|---|---|
| Invoice receipt | Polls a mailbox, saves attachments, renames files | Mailbox UI change, attachment type it was not built for, a supplier who switches to a portal | Channel-agnostic intake: email, portal, EDI and network e-invoice into one queue | Intake is a data contract, not a screen |
| Field capture | Reads fields by page coordinates or a per-supplier template | New supplier, new layout, a scanned page at a different skew | Intelligent document processing with a confidence score per field | The model reads structure, not position |
| Line-item extraction | Iterates a table by fixed row and column offsets | Multi-page line tables, wrapped descriptions, a freight line inserted mid-table | Model-based table parsing that returns typed line objects | Line semantics survive layout change |
| GL coding of non-PO spend | Applies a lookup table of supplier to cost centre | Anything the lookup has never seen goes to a default and posts wrong | A model that proposes coding from history and abstains below a confidence threshold | Abstention is a feature; a default is a silent error |
| Two- and three-way matching | Opens the PO screen, reads values, compares on screen | Partial receipts, tolerance rules the bot cannot express, unit-of-measure mismatch | Matching executed against PO and goods-receipt data through the ERP's API | Comparison happens on records the ERP already reconciles |
| Exception handling | Drops the invoice into a queue for a human | The queue is the same size it always was | An agent that holds the exception, drafts the supplier query, and applies the answer | Resolution is the work; routing is not |
| Approval routing | Clicks through a workflow UI on the approver's behalf | Delegation, out-of-office, a re-ordered approval matrix | Native workflow with policy as data and a full audit trail | Approvals are already a record in the system |
| ERP posting | Types the document into the transaction screen | A locked period, a duplicate created by a retry, a field made mandatory in a release | Posting through a documented API, for example SAP S/4HANA's supplier invoice service | The API is versioned and contractual; the screen is not |
| Duplicate and fraud control | Compares invoice number and amount against a recent list | Same invoice, different number; changed bank details on a genuine supplier | Supplier master validation with change detection on payment details | Payment-detail change is the attack, not the invoice |
| Month-end accrual | Runs a report, copies it into a spreadsheet | Every close, with a deadline attached | Open items queried directly, reconciled continuously | Nothing to copy |
The column that decides the architecture is the fourth one. Every replacement in it operates on data. Not one of them operates on a screen.
What replaces accounts payable automation technology built on bots
Four mechanisms, in the order they pay back.
Extraction that generalises. Intelligent document processing with per-field confidence, so the system knows what it is unsure about. The confidence score is the part teams skip and it is the part that makes everything downstream possible, because it lets you set a threshold below which nothing posts unreviewed. Without it you cannot tell a correct read from a lucky one.
Matching against data. PO matching and three-way matching are comparisons between an invoice, a purchase order and a goods receipt. Those three records already live in your ERP as structured data with a reconciliation relationship the vendor maintains. Doing the comparison by reading a screen is doing it twice, badly. SAP publishes a supplier invoice API for S/4HANA that creates, reads, releases and cancels invoice documents from an external system; Oracle, Microsoft and NetSuite publish equivalents. If your ERP has one of these, the screen is not the integration point and has not been for years. Our published three-way matching case study walks through the mechanics of doing the comparison this way.
An agent that can hold an exception. This is the piece RPA has no answer to. An exception is not a routing problem. It is an unanswered question: is this price variance approved, did the goods arrive short, is this a rebilled freight charge, has this supplier changed its remit-to. An agent that can read the PO history, draft a supplier query in the right language, wait days for the reply, interpret the reply and then complete or reject the invoice is doing the clerk's job rather than the clerk's typing. Our AI procurement agent is built around that hold-and-resolve loop, and in our implementations it is the difference between an exception rate and an exception backlog.
Write-back through an API. Posting a document is a transaction with idempotency requirements. An API gives you a request identifier, a deterministic response, a versioned contract and an error you can act on. A keyboard gives you a retry that might have already posted. Everything in the duplicate-invoice horror-story genre comes from the second one.
Those four together produce something a bot cannot: straight-through processing that rises as the model sees more of your suppliers, rather than a maintenance curve that rises as your bot count grows. We have written separately on the cycle-time and margin economics of procurement automation, and that piece carries the commercial case rather than the architectural one.
Does this mean buying a suite, or building?
Both are live options and the decision is not an architecture question, it is an integration and ownership question. Buyers researching Gartner accounts payable invoice automation coverage will find the Magic Quadrant for Accounts Payable Applications by Miles Onafowora and David Condon, published 18 June 2026, which assessed 12 vendors. A quadrant is a useful map of who sells a suite. It does not tell you whether a suite fits an ERP you have customised for a decade, or whether the long tail of your non-PO spend looks like anybody's reference customer. Our build, buy or extend analysis for procure-to-pay software sets out how to make that call properly, and this article deliberately stays out of it.
Is RPA ever still the right answer for accounts payable?
Yes, in three situations, and a teardown that pretends otherwise is not worth reading.
A system with genuinely no API. Some of them still exist: a regional banking portal, a government filing site, a customs system, an ERP so old that the integration layer was decommissioned before you arrived. If the only way in is a screen, a bot is the only tool and the honest framing is that you are paying maintenance rent for an access problem you did not create. Scope it that way, budget the rent, and revisit when the vendor ships an API.
A deliberate bridge during a migration. When you are moving from one ERP to another over eighteen months and two systems must both hold the truth for a while, a bot that copies postings across is a reasonable temporary joint. The condition is a decommission date written into the same document that approves the build. Bridges that outlive their migration are how estates end up with two hundred undocumented automations.
A low-volume process where integration cost exceeds maintenance cost. Forty invoices a month from a single supplier through a portal that will never have an API is not worth a six-figure integration. Automate the screen, accept the breakage, and put a human alert on the failure path rather than pretending it is straight-through.
What all three share: RPA is the answer when the constraint is access, and the wrong answer when the constraint is judgement. AP exceptions are a judgement problem. That is why the category stalled here specifically while continuing to earn its keep elsewhere in enterprise workflow automation.
Which bots you keep, and which you retire
Most finance teams starting this migration own somewhere between a dozen and a few hundred automations, and the first instinct is to rank them by how much they cost to maintain. That is the wrong axis. Rank them by the kind of constraint each one solves, and the sorting takes an afternoon rather than a consulting engagement.
The test is a single question asked of every bot. If this automation stopped tomorrow, would the work be blocked by a missing integration, or by a missing decision? An access constraint is a bot worth keeping. A judgement constraint is a bot worth retiring, because the bot was never making the judgement. It was deferring the judgement to a queue and charging you maintenance for the privilege.
Asking that question requires four facts per bot, and most estates have none of them written down: which systems it drives, whether each of those systems publishes a documented API covering the operation the bot performs, which process step it sits on, and how many times it broke in the last twelve months. The break count is the only one your orchestrator hands you directly. The API fact decides most cases, and it goes stale in the direction that favours retirement. A bot built in 2021 against a supplier portal that shipped an API in 2024 is a bot nobody re-examined, and there are more of those in a typical estate than anyone expects.
| What you find when you inventory a bot | Verdict | What to do about it this quarter |
|---|---|---|
| Drives a system with no API, covers an access step | Keep | Budget the maintenance as access rent and set an annual API review with the vendor |
| Drives a system whose API covers the same operation | Retire | Fold the step into whichever migration wave owns it |
| Covers a step that ends in a human decision | Retire | Replace with an agent that holds the exception rather than a router that moves it |
| One bot doing an access step and a judgement step | Split | Keep the access half running, schedule the judgement half |
| API exists but does not cover this specific operation | Keep, narrowed | Cut the bot back to the uncovered steps and delete the rest |
| Built as a bridge for a migration that has finished | Retire now | Decommission, after checking whether it is still writing anywhere |
| No named business owner, unknown consumers | Suspend | Disable for two weeks with invocation logging, then decommission |
What do you do with a bot that is half access and half judgement?
Split it, and accept that splitting bots is unglamorous work nobody gets promoted for. It is also where most of the safe savings sit.
A bot that logs into a carrier portal, downloads the freight invoice and then applies a coding rule is two automations sharing a name. The download half solves an access problem and keeps earning its place. The coding half solves nothing, because the rule it applies is a lookup that fails silently on anything it has not seen before. Separate them, leave the download running, and push the coding into the wave that replaces coding properly.
The second in-between case is a system with an API that does not cover the operation you need. This happens more often than vendor documentation implies: an ERP publishes a supplier invoice service with no endpoint for attaching the scanned original, or a tax portal exposes a submission API but demands a human session to collect the acknowledgement. Keep the bot and narrow it. Stop it doing anything the API already does. A bot performing ten steps when the API covers eight is carrying eight steps of unnecessary breakage, and each of those eight will eventually cost somebody a morning.
For anything in the split or narrowed column we apply a freeze: no new features, fix on break only, and a review date set against the vendor's published roadmap rather than a date chosen because it sounds reasonable. Freezes without review dates become permanent. That is the mechanism by which a 2019 automation is still in production in 2026 with nobody willing to touch it.
Then there is the category that never appears in a migration plan. Every estate has automations with no named business owner, usually built by a citizen developer who has since moved team or left. Forensic analysis of those is expensive and rarely conclusive. We turn them off instead: disabled for two weeks, with the orchestrator logging any attempted invocation, and decommissioned if nobody notices. That is an uncomfortable recommendation to put in writing, and it is still cheaper than the alternative, because any process that genuinely matters has someone who notices it stopped inside one working week.
The compliance deadlines that decide this for you
A structural argument can be deferred. A legal date cannot, and there is a run of them that dismantles the screen-scraping model from the outside, because they replace the PDF a bot was reading with structured data it never needed to read.
France moved first at scale. Since 1 September 2026, every business established in France must be able to receive electronic invoices through an approved platform, with large and mid-sized companies also obliged to issue electronically from the same date and SMEs and micro-enterprises following on 1 September 2027. The French tax administration's own practical guide to the 1 September 2026 start sets out the platform model and the formats, which follow the EN 16931 semantic standard. An invoice arriving as structured XML does not need OCR, does not need a template, and cannot be read by a bot any more usefully than by a parser.
Accounts payable automation UK programmes have a longer runway and a clearer direction. HMRC and the Department for Business and Trade published the outcome of their electronic invoicing consultation on 26 November 2025, drawing 342 responses, and confirmed that e-invoicing will be mandatory for all VAT invoices from 2029 using a decentralised four-corner model rather than a government clearance portal, with an implementation roadmap due at Budget 2026. The consultation outcome also confirmed the mandate will not require live transaction reporting to HMRC. PDFs will not qualify as compliant invoices under that regime.
Accounts payable automation Australia has the nearest public-sector milestones. The Australian Taxation Office, which runs the Australian Peppol Authority, set a target for non-corporate Commonwealth entities of at least 30% of received invoices exchanged via eInvoicing by 1 July 2026, and requires agencies to enable both automated processing of received invoices and the sending of Peppol e-invoices by December 2026. B2B remains voluntary, so Australian AP teams face a mixed estate for years: Peppol from government counterparties, PDFs from everyone else.
Accounts payable automation Canada sits at the other end of the spectrum, and it is worth saying plainly because vendors imply otherwise. Canada has no announced B2B e-invoicing mandate. Suppliers to the federal government have invoiced electronically since April 2022, and the Canada Revenue Agency's electronic invoicing guidance accepts any format that carries the required information and can be produced for audit. A Canadian AP team therefore has to solve the unstructured-invoice problem on its own timetable rather than a regulator's, which argues for extraction that generalises rather than a template library.
The United States has no federal mandate either, which means US teams inherit the hardest version of the problem: a permanent mix of structured and unstructured intake, with no date forcing suppliers to convert. That is an argument for the model-based path, not against it.
The pattern across all five markets is the same. The share of invoices that arrive as data rises every year and never falls. Automation that reads pictures of invoices is depreciating to zero on a published schedule.
Working through this now? If you are holding a bot estate and a mandate date, our AI and automation engineering team runs a two-week teardown that maps every automation to the step it covers and the replacement it needs. You leave with the sequencing, not a proposal.
A migration path that does not double-post invoices
Nobody switches this over in a weekend, and the migrations that fail do so in one of two ways: they start with the hardest step, or they run both systems live without deciding which one owns the posting.
Sequence by exception density, not by volume. The step generating the most human touches per hundred invoices is the step to replace first, regardless of how many invoices flow through it.
| Wave | What moves | What stays on the bot | Why this order |
|---|---|---|---|
| 1 | Capture and extraction, all suppliers | Posting, matching, routing | Biggest exception source, lowest blast radius, no write path |
| 2 | Coding of non-PO spend, with abstention below threshold | Posting, matching | Removes silent default-coding errors before anything else touches the ledger |
| 3 | PO and three-way matching via ERP API | Posting for the ERP screens that still lack an API | Matching is read-only against records you already trust |
| 4 | ERP write-back through the supplier invoice API | Only the systems with no API at all | Last because it is the only irreversible step |
| 5 | Exception hold-and-resolve by agent, with human approval thresholds | Nothing | Needs the four waves above to be reliable first |
| 6 | Decommission the bots that no longer have a step | Nothing, by definition | Write the date down in wave 1 |
Waves 1 to 3 are read-only or advisory. That is the point. You can run them in parallel with the existing bots indefinitely and compare outputs without any risk to the ledger, because neither path is posting anything new.
How do you run both in parallel without paying an invoice twice?
Three controls, and they are not optional.
First, single-writer. Exactly one system holds the write path to the ERP at any moment, per document type, and the switch is a configuration change with a named owner, not a feature flag two teams can both toggle. During waves 1 to 3 the writer is still the bot. In wave 4 it becomes the API, and the bot's posting activity is disabled at the orchestrator rather than commented out in a script.
Second, idempotency keys from intake. Every invoice gets a deterministic identifier at the moment it enters the queue, derived from supplier identifier, invoice number and total, before either path touches it. The ERP write carries that key. A retry with the same key is rejected by the integration layer, not by a duplicate check three steps later. This is the control that makes the whole parallel run safe, and it is the one most often added after the first double payment.
Third, shadow mode with a reconciliation report. For the parallel period, the new path produces a posting payload and does not send it. A daily report compares the payload it would have sent against what the bot actually posted, field by field. You are looking for three categories: agreement, new-path abstention, and disagreement. Disagreements are the only ones that need a human, and in our implementations the disagreement rate falls fast once supplier-specific coding history is loaded. Do not cut over until that report is boring.
A fourth control if you are in a mandate market: run the structured and unstructured intake paths against the same identifier scheme from day one. Otherwise the same invoice arriving once as a Peppol document and once as a courtesy PDF becomes two payables, and no amount of downstream duplicate checking catches it cleanly.
What happens to invoices already mid-approval when you switch?
You drain them. You do not migrate them.
At the moment you move the writer, a number of invoices will be sitting inside an approval chain: one approval collected and one outstanding, an approver on leave, a delegation in force, a budget holder who asked a question and is waiting for the answer. Every instinct says to lift that state into the new system so nothing is lost. Resist it. Approval state is evidence. Rebuilding it elsewhere produces an audit trail asserting that an approval happened in a place it did not happen, and the only honest way to represent that is a migration note nobody enjoys explaining to an auditor.
Use a receipt cut-off instead of an approval cut-off. Invoices received before a named date and time complete their entire journey on the old path, including posting, however long the chain takes. Invoices received after it enter the new path only. For a fortnight you are running two queues behind one entry point, and AP staff work both, which is the real cost of not corrupting the record. Then set a drain deadline, usually two weeks past the cut-off, and escalate anything still open on the old path as an individual item rather than letting a handful of stragglers justify keeping an entire pipeline alive. The old path stays available for exactly as long as your longest legitimate approval chain and not a day longer.
Reconciliation through the cutover has a specific shape, and the number most teams watch is the wrong one. Everybody counts postings. Count intake. Take a document count by channel, mailbox against portal against EDI against Peppol, for the day before cutover, the day of, and every day after, and reconcile it against documents that reached a terminal state in either path. The failure that hides is not the double post. A supplier tells you about a double payment quickly and loudly. It is the invoice that entered the new path, failed a validation nobody was watching and reached no state at all, which surfaces sixty days later as a dunning letter, after the early-payment discount has gone and sometimes after the relationship has. Reconcile the AP subledger to the general ledger control account daily through the cutover fortnight rather than waiting for month end. A daily break is a morning's work. A monthly break is an investigation.
One thing to decide before wave 1, because it is expensive to reverse: whether supplier master data moves with the programme. Payment-detail changes are the primary attack surface in this whole process, and the 2026 AFP Payments Fraud and Control Survey, published 14 April 2026 from 465 US treasury practitioners surveyed that January, found 76% of organisations experienced attempted or actual payments fraud in 2025 and 74% were hit by business email compromise, while just 17% use AI to combat payments fraud. Bank-detail validation belongs in the same system that posts the invoice, not in a bot that reads a supplier portal. Our note on supplier risk in 2026 covers the wider control set.
How to measure the switch without flattering it
A migration off bots is easy to declare successful and hard to prove successful, because the two things being compared are usually not the same thing measured the same way.
Take the baseline before wave 1 touches anything, and take it across a full quarter containing at least two month-end closes. Invoice volume is not flat. It has a quarter-end shape, a holiday shape and an audit shape, and a two-week baseline captured during a quiet fortnight sets a bar the new path clears on its first morning while telling you nothing worth reporting.
Six measurements matter on both sides of the change, and each one needs defining before anybody collects it.
Straight-through rate, defined as the share of invoices reaching posted status with no human opening the document. Not "no human keyed it". Opening counts, because opening the document is where the minute goes.
Touches per invoice, counted as distinct human interactions rather than distinct people. That is the version of the metric that moves when an exception gets resolved once instead of passed twice.
Exceptions by reason code, with capture failures separated from matching failures and both separated from policy stops. An aggregate exception rate hides the only useful signal, which is which category actually moved.
Time from receipt to posted, not receipt to approved. The gap between those two dates is where the old architecture concealed most of its cost.
Rework, measured as documents posted and then reversed, amended or re-coded within ninety days. This catches the failure mode specific to bots, the confident wrong posting, and almost nobody baselines it, because finding it means querying the ledger rather than reading a dashboard.
Maintenance load, in engineering hours per month across both the bot estate and the new path, with break events per month next to it. A programme that halves exceptions and doubles engineering hours has not paid for itself yet. Make that visible while it is still a choice rather than at renewal.
The trap that ruins more of these reports than anything else is comparing a clean pilot against a messy production baseline. A pilot runs on a chosen cohort: the best twenty suppliers, PO-backed, tidy master data, somebody senior watching the queue. The baseline was everything, including the handwritten delivery note, the credit note referencing three originals and the supplier whose currency your ERP rounds differently. Set those two side by side and the improvement figure you publish is mostly cohort selection.
Shadow mode is the fix, and this is the second reason to run it. The new path sees every invoice, including the ones a pilot would never have been handed, and it produces a payload for all of them without posting any. Score the shadow period on the whole population. If a steering committee insists on a pilot number, publish both figures in the same table, the cohort result and the all-invoice result, and treat the gap between them as a finding rather than a footnote. The same discipline applies to vendor selection, which is why we recommend running one invoice file across every shortlisted product instead of accepting demo data.
Hold the first formal comparison until the second full close after wave 3. Extraction quality stabilises within weeks. Coding accuracy does not, because it keeps improving as supplier-specific history loads, and a number published in week three is a number somebody will have to walk back in front of the people who approved the budget.
What happens to the people who maintained the bots?
A teardown of an RPA estate is also a teardown of the team that built it, and a migration plan that leaves this unsaid stalls in a steering committee rather than in production. This part is political rather than technical, and skipping it does not make it go away.
Start with the maintenance engineers, whose position is stronger than they usually believe. What made someone good at keeping bots alive was never fluency in a recorder. It was knowing that this supplier bills freight on a separate line, that the tolerance on this spend category differs from the standard, that the period locks at 16:00 on the second working day. That knowledge is exactly what the replacement architecture needs in order to be configured correctly: the confidence thresholds, the tolerance rules, the abstention policy, the evaluation set of genuinely hard invoices. Move those people onto integration and evaluation work, and say so at the start rather than after wave 1, because the alternative is that the people who understand the process best spend the programme defending the thing being replaced.
The centre of excellence is the harder conversation, and it is a scorecard problem rather than a skills problem. A CoE measured on automations delivered will defend the automation count, because the count is the job. Change the measure before you change the architecture: from automations shipped to straight-through rate, exceptions closed without a human touch, and integration uptime. A team that owns data contracts, API versioning, evaluation sets and the thresholds at which a model abstains holds more real authority than a team that owns a bot inventory, and that argument needs making in the room where the budget sits rather than after the first wave ships.
Citizen developers are where honesty costs something. Somebody spent a fortnight earning a certification on a platform you are retiring, and there is no gentle way to say that the certification is worth less than it was. What replaces it is not "learn to write integration code", which most of them neither want nor need. It is configuration and adjudication: owning tolerance policy for a spend category, reviewing low-confidence extractions, maintaining the coding rules their own department depends on. That is a real job with a path in it. Some people will still decline it, and a migration plan should carry a number for the ones who leave instead of an assumption that nobody will.
AP clerks change too, and business cases routinely lie about this. A programme cannot promise labour savings and no headcount impact in the same document. What happens is that the keying disappears and the adjudication remains, so a smaller team does harder work: supplier queries, price disputes, credit note reconciliation, the judgement calls the bot was routing to them anyway. Decide which of those two claims you are making and write it down. The team will work out the answer well before the steering committee does.
What we would not do
We would not start a migration at the posting step, however satisfying it is to kill the bot that types into the ERP. It is the only irreversible action in the chain and it belongs in wave 4.
We would not accept an accounts payable automation case study as evidence without three specifics: the ERP and its version, the share of invoices that were non-PO, and the straight-through rate measured after go-live rather than in the pilot. A case study missing any of those is describing a demo. We hold our own published work to the same test, and we tell prospects to apply it to us.
We would not rip out a working bot that bridges a system with no API. Replace the steps that need judgement. Leave the steps that need access, and put a review date on them.
We would not describe any of this as finished. Model-based extraction still misreads handwriting, still struggles with credit notes that reference three original invoices, and still needs a confidence threshold set by someone who understands the cost of a wrong posting in your business. What changed is the direction of the maintenance curve. Bots get more expensive as your estate grows. Models get cheaper as they see more of your suppliers. Over a five-year horizon that difference is the whole decision.
If you are weighing this now, the useful first artefact is not a business case. It is a map: every automation you own, the step it covers, the system it drives, and whether that system has an API. Most teams have never written it down, and writing it down settles the argument. Our agentic AI engineering practice builds that map with clients in a fixed two-week engagement, or book a working session and bring the bot inventory you already have.
