Back office automation is the use of software to run the internal work of a business that customers never see: paying suppliers, applying customer payments, reconciling accounts, closing the month, checking payroll, onboarding employees and entering orders. The case for it has been made for a decade and the evidence on where it fits has been public for as long. The McKinsey Global Institute's 2017 study found that fewer than 5 percent of occupations could be fully automated but about half of all paid activities could be, with data collection and data processing near the top of the list, which is a fair description of most back-office work. The record of automation projects is less encouraging. EY reported in its 2016 paper "Get ready for robots" that it had seen as many as thirty to fifty percent of initial robotic process automation projects fail. The two findings are compatible, and the gap between them is what a company deciding where to start needs to understand.
What back office automation covers
The back office is the set of processes that keep the business running without touching the customer directly. Finance holds the largest share: procure to pay, order to cash, the close, treasury and tax. Human resources administration holds another, from onboarding paperwork to payroll changes and benefits enrollment. Operations administration covers purchasing, order entry, shipping documents and supplier follow-up. In a mid-market company, these processes run on an accounting system or an older ERP, a CRM, email and spreadsheets, and on the people who move information between them.
That last part is the target. Most back-office roles combine a small amount of judgment with a large amount of transfer: reading a document and keying it into a system, copying a figure from one screen to another, checking that two records agree, chasing someone for a missing approval. Transfer also produces rework. Gartner found that avoidable rework can take up to 30 percent of an accounting employee's time, and the cost gap between the best finance teams and the rest is large: The Hackett Group's top-quartile finance organizations operate at 45 percent lower cost as a share of revenue and need up to 42 percent fewer full-time staff across key finance functions. Transfer is what automation removes. The judgment stays with the person, who then has more time for it.
How to pick the first process
Four tests pick the first process well. The first is volume: a process that runs thousands of times a month repays the work of automating it, and one that runs a dozen times doesn't. The second is rules the team can already state, with an exception rate someone can measure, because the exceptions will set the cost of the automation. The third is a system of record where the result gets written, since an automation that produces an answer someone then has to key is half an automation. The fourth is a person doing the work by hand today, which means there is a current cost to measure and a person who knows where the process breaks.
Finance processes usually pass all four. Invoice processing is the standard first candidate, and the market agrees: The Hackett Group's 2026 finance study found accounts payable to be the most mature finance process for AI, with 33 percent of organizations already scaling AI solutions there. We set out the full buying-side process in procure to pay, step by step. Cash application and collections on the selling side come next, in order to cash, followed by account reconciliations and the rest of the close. Processes that fail the tests tend to be rare, judgment-heavy or unmeasured, and a painful process that fails them is still a poor first project.
Why projects stall at the integration
The first place projects stall is the connection to the systems. A mid-market back office runs on software that was never built to be automated: an ERP with no usable interface, a portal that only a browser can reach, a spreadsheet that one person maintains. The first generation of back-office automation handled this by scripting the screen, and scripts broke when the screen changed. In Deloitte's 2017 global RPA survey, sixty-three percent of the respondents who had implemented robotic process automation said it took longer than they expected. The integration problem has not gone away, and writing results back into systems with no interface remains real engineering, which we treat in writing back into a system with no usable API.
Why projects stall at the exceptions
The second place is the exception queue. Every back-office process has a clean path and a tail of cases that don't fit it: the invoice with no purchase order, the payment with no remittance, the new hire whose documents don't match. Early automation handled the clean path and routed the tail to a person, often with less context than the person had before, since the automation had stripped the case out of the flow in which someone understood it. In accounts payable the tail is large and well measured. Ardent Partners' State of ePayables 2025 put the average invoice exception rate at 18.4 percent and called exceptions typically the biggest single reason the function's costs and cycle times are not lower. Gartner described the same pattern across finance in 2022: automation had handled many simple, repetitive tasks and left behind the ones that need a person to keep the process running. An automation that clears the clean cases and leaves the exceptions harder to resolve can cost more than the process it replaced, which is the arithmetic in the unit economics of the exception tail.
The newer approach aims at the tail directly. An agent that reads documents in any format, gathers the context for each exception and proposes a resolution changes the cost of the tail, and the tail is where the cost of the process sits.
Why projects stall without a baseline or an owner
The third and fourth places are organizational. A project that starts without measuring the process it replaces can't show a saving, and a project that can't show a saving loses its budget at the first review. The baseline needs four numbers, taken before anything changes: hours per month, cost per transaction, the exception rate and the cycle time. Taking them is a small job, and skipping them makes every later argument about value an argument about opinions. Gartner's advice to CFOs points the same way: in a 2026 survey, 63 percent of finance organizations said AI implementation was slower than expected in 2025, and Gartner's advice was to measure AI by the value realized rather than by the number of deployments.
The owner is the other missing piece. An automation in a back office runs against documents, suppliers, customers and systems that change every month, and it needs someone accountable for keeping it working and for the result it produces. Projects built by a team that then moves on decay the way the documentation of a manual process decays. Gartner predicted in June 2025 that over forty percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls, which are the symptoms of a project without a baseline and without an owner.
A reasonable counter, answered
A reasonable counter is that the market already sells back office automation software for every function, an AP tool, an expense tool, a close tool, a payroll add-on, and that buying the right tool for each process is simpler than any of the above. For processes with clean inputs and a team willing to change how it works around the tool, buying the tool is often right. The difficulty is that the four stalls above don't depend on the tool. The AP tool still has to read the supplier invoices that arrive as PDFs, still leaves the exceptions to someone, still needs a baseline to justify it and still needs an owner after the implementation team leaves. Buying five tools means five integrations, five exception queues and five owners. The work that decides whether back office automation pays is the same whichever software carries it, and a company should buy on the basis of who does that work.
Common questions
- What is back office automation?
- Back office automation is the use of software to run the internal administrative work of a business, the work customers never see: accounts payable and receivable, the month-end close, payroll checks, employee onboarding, purchasing and order administration. It ranges from matching rules inside an accounting system to agents that read documents, work across several systems and route the cases they can't decide to a person. The common thread is replacing manual steps that move information between documents, inboxes and systems. The decisions that need judgment or authority stay with people.
- Which back office processes should be automated first?
- The best first candidates share four traits: high volume, rules the team can already state, a system of record where the result is written, and a person doing the work by hand today. Invoice processing, cash application, account reconciliations and order entry usually qualify. A process that runs a few times a year, or that depends on judgment in most cases, makes a poor first candidate however painful it feels. The first project should also be one where the current cost can be measured before anything changes.
- Why do back office automation projects fail?
- Most stall in one of four places. The automation can't read from or write to the systems the process runs on, so it breaks at the integration. It handles the clean cases and leaves the exceptions in a queue that costs as much as the old process. Nobody measured the process before the project, so nobody can show the saving. Or nobody owns the automation after it goes live, and it decays as documents, suppliers and systems change around it.