Accounting Automation That Survives Contact With a Real Firm
Deepak Anchala
Co-Founder and CEO, Adopt AI1 July 2026
Most firms have already automated accounting. That is the part the category discussion misses. There are macros in the close workbook, a rule set in the bank feed, a workflow tool tracking the checklist, a script somebody in IT wrote in 2019, and possibly a bot that logs into a portal at 6am and breaks every time the vendor ships a UI change.
And the close still takes weeks. Preparation still eats the senior capacity. The offshore team still hand-keys statements into Excel.
That gap is the actual subject of this guide. Not whether accounting can be automated, which is settled, but why a decade of automation spend has left the largest block of manual hours untouched, and what has to be true of a tool before it reaches that block.
The short version: each generation of accounting automation solved a different layer of the work, and the layer where the hours concentrate, getting data out of systems nobody controls and assembling it into something a person will sign, was the layer none of them could reach. That has changed recently, for specific technical reasons, and it has introduced a fresh set of failure modes worth understanding before you buy anything.
Scope note: this is written for firm-side practitioners doing accounting and tax work for clients. If you are automating a single company's own books, the layer model below still holds, but the client-variability problem that dominates firm-side work is much smaller for you, and you should discount that section accordingly.
What accounting automation actually means
Accounting automation is the use of software to perform accounting work that a person would otherwise do by hand: retrieving source documents, extracting and classifying data, posting entries, reconciling accounts, building workpapers and statements, populating forms, and flagging what does not tie.
The definition is uncontroversial. The useful question is narrower, and it is the one to ask any vendor in the first ten minutes: which layer of the work does this actually perform, and which layer does it merely organize?
Six layers, in the order a piece of work moves through them:
| Layer | What happens | Typical share of preparation hours |
|---|---|---|
| 1. Retrieval | Getting documents and data out of client portals, banks, ERPs, email, and shared drives | High, and almost entirely manual in most firms |
| 2. Extraction | Pulling figures off statements, invoices, registers, and PDFs into structured form | High |
| 3. Assembly | Building the workpaper, reconciliation, statement set, or form from extracted data | Highest single block |
| 4. Decision | Choosing the position, the treatment, the method, the estimate | Low in hours, high in value |
| 5. Review and sign-off | Checking the artifact, resolving exceptions, taking legal responsibility | Moderate, and it does not go to zero |
| 6. Communication | Chasing the client, setting expectations, explaining the result | High, and structurally not automatable |
Layers 1 through 3 are where the manual hours sit. Layers 4 through 6 are where the professional value sits. Almost every automation disappointment in accounting is a tool that promised layer 3 and delivered layer 5 tracking, or one that could do layers 2 and 3 beautifully as long as somebody else handled layer 1.
We put rough proportions on this in a separate piece, based on live engagements inside a top-30 US firm: roughly 40% of staff time was calculation and assembly, roughly 40% was client communication, site visits, and document management, and the rest was coordination and review. See Will AI Replace Accountants? for how that split was measured and what it implies for staffing.
Four generations, and the layer each one reached
This is the history that explains your current stack. It is worth being precise about it, because each generation is still on the market and still being sold as though it addresses everything.
Spreadsheet logic and scripts. Macros, linked workbooks, VBA, later Python. Reaches layer 3 for a single well-defined calculation, on data somebody already gathered. Cheap, fast, and it becomes an unowned dependency the moment its author leaves. Still, correctly, the most-used automation in the profession.
Rules-based workflow and close management. BlackLine, FloQast, Trintech, and practice management tools with automation layered on. These reach layer 5 and parts of layer 3: they orchestrate the checklist, enforce the sequence, hold the sign-offs, match transactions against rules, and give a controller visibility. What they mostly do not do is produce the artifact. A person still prepares the reconciliation the platform is tracking. This is the single most common source of the feeling that a firm bought automation and got a project tracker, and it is not a defect in the products, it is a mismatch between what they do and what was expected.
RPA. UiPath, Automation Anywhere, and the scripted-bot generation. RPA was the first serious attempt at layer 1, and the insight was right: drive the interface, because the interface is the only integration surface that always exists. The execution was brittle. Bots were coordinate-and-selector scripts with no understanding of what they were looking at, so a relocated button broke them, and each broken bot needed an engineer. Firms ended up maintaining automation as though it were infrastructure, which for a mid-sized firm it cannot be. There is a second problem worth naming: when the vendor owns the bots, capability is not portable, and you are one acquisition or repricing away from starting over.
LLM-era agents. Software that operates applications the way a person does, reading the screen and deciding what to do next rather than replaying recorded coordinates, and that can write the transformation logic for an unfamiliar document format instead of requiring a template per layout. This is the first generation whose reach genuinely covers layers 1 through 3, including systems with no API and portals nobody will ever build an integration for.
It also introduced a problem the previous three did not have: a language model can produce a confident, well-formatted, wrong number, with no traceable origin. Everything in the next section follows from that.
Why accounting automation fails inside real firms
Nine failure modes. They are ordered by how often they are the actual cause, based on what firms describe when they say they have already tried this.
1. The data is behind an interface with no API. This is the first and largest one. Client payroll registers live in portals. Bank statements live behind 2FA. Half the client base is on a system whose vendor has no public API, or has one that does not expose the detail you need. A tool that assumes clean API access cannot reach the work at all, which means the pilot quietly narrows to the two clients on modern systems and the result does not generalize.
2. The process was never documented, and it varies per client. Firm-side work is not one process run 300 times. It is 300 variants of a process, and the variation lives in senior people's heads. Automation forces that tacit knowledge into the open, which is genuinely valuable and also the reason projects stall: the first honest attempt at a spec surfaces disagreements about how the work is actually done.
3. The tool automates the tracking rather than the doing. See the second generation above. Diagnostic question: after this is live, who builds the reconciliation? If the answer is still a person, you have bought visibility, not capacity.
4. Output has no provenance, so review costs more than preparation saved. If a reviewer cannot see where a figure came from, they will re-derive it. Re-derivation is preparation with extra steps. This is how a tool with a real accuracy advantage produces a net loss in hours, and it is why the only metric that matters is net hours saved after review and rework. One firm lead put the standard plainly: automation that creates rework negates time savings.
5. Client data cannot leave the environment, and nobody checked that first. This kills more evaluations than price does. If your engagement letters or your clients' consent posture do not permit sending client financial data to a third-party service, then a cloud-only tool is not a cheaper option, it is not an option. One firm we worked with had previously needed explicit consent from 4,000 clients to move data offshore and had no intention of running that project again. Ask about deployment location in the first conversation, not the fifth.
6. The first workflow chosen was the wrong one. Firms tend to start with the workflow that hurts most, which is usually the one that is most exception-heavy, least standardized, and hardest to automate. It is the worst possible pilot. Pick the workflow with the highest volume and the lowest variance, prove the mechanism, then move to the painful one with a working system and internal credibility behind you.
7. The tuning cost was underestimated, by everyone. Getting an agent to finish work to a standard a manager will sign takes real iteration against real client files, with your subject matter experts putting hours into the design rather than reviewing at the end. Anyone selling a two-week transformation is selling a demo. Budget the internal hours explicitly, and treat a vendor who wants your experts involved as a signal of seriousness rather than of an unfinished product.
8. The review process was not redesigned. Reviewing machine-produced work is a different skill from reviewing a junior's work. You are not checking whether someone understood the assignment, you are checking a completed artifact for the characteristic failure modes of the thing that produced it. Firms that assume the existing review checklist transfers unchanged find out the expensive way.
9. Nobody owned it after go-live. Automation is not a project with an end date. Client systems change, statement formats change, staff turn over. Every durable deployment has a named person whose job includes it. Every abandoned one does not.
Notice how few of these are about model quality. Eight of the nine are about data access, process discipline, review design, and ownership. That ratio is the single most useful thing to take from this guide.
Choosing the first workflow
Score candidate workflows on five factors before committing. This is worth doing on paper with the people who actually run the work, and it takes about an hour.
| Factor | Score high when | Why it matters |
|---|---|---|
| Volume | The same work runs across many clients or many periods | Fixed setup cost amortizes over repetitions. A once-a-year task for one client will never pay back the tuning |
| Standardization | The steps are the same regardless of client | Variance is the cost driver, not complexity |
| Data accessibility | Sources are reachable, even if only through a portal login | Reachable through an interface is fine. Genuinely unavailable is fatal |
| Client stability | Multi-year clients with prior-year positions to anchor against | Completion rates on stable clients are materially better than on first-year or restructured ones |
| Review cost today | A senior person currently rebuilds rather than checks | This is where the recovered capacity actually comes from |
Workflows that score well on all five, in roughly the order firms succeed with them:
- Bank statement retrieval, extraction, and categorization
- Account reconciliation and bank-rec-to-GL posting
- Trial balance and consolidated statement assembly.
- Workpaper population for recurring, calculation-heavy engagements
- Prior-year rollforward and tie-out on recurring tax forms. See Form 5471
- Flux and variance analysis drafting
- Intercompany balance extraction and segmented financials. See transfer pricing
Workflows that make bad first projects, regardless of how much they hurt: anything gated on a client decision, anything where the position changes annually, anything with fewer than about twenty repetitions a year, and anything whose current owner is the only person who knows how it works.
For the step-by-step version of sequencing a workflow end to end, see Automating the Accounting Process, Step by Step.
What to measure
Most automation reporting measures activity. Measure these instead, and baseline them before you start, because reconstructing a baseline afterward is not credible to anyone.
Net hours saved, after review and rework. The only number that survives scrutiny. Gross time saved on preparation, minus review hours on agent output, minus time spent correcting what came back wrong. If a vendor quotes gross savings, ask for the net figure and watch what happens.
Completion rate, split by client stability. The share of the workflow finished to a reviewable standard without human intervention, reported separately for stable multi-year clients, first-year clients, and clients with a structural change. The blended average hides the number that determines your staffing plan.
Exception rate and exception mix. How often a human is pulled in, and whether it is for genuine judgment or for the same format problem forty times. The second kind is fixable and should trend down every month.
Review time per engagement. Should fall substantially and should not reach zero. If it reaches zero, nobody is reviewing.
Cycle time. Days from client documents in hand to reviewable artifact. This is what the client experiences and what the partner cares about.
Coverage. The share of your client base the automation actually works on. A 90% completion rate on 15% of clients is a pilot result, not a firm result.
Two numbers to distrust, including from us. Headline accuracy quoted without an attached tuning cost, and any before-and-after ratio without a stated baseline, workflow, and measurer. This profession audits things for a living. Hold vendors to the standard you apply to a client's estimates.
Designing a pilot that produces a real answer
The point of a pilot is not to see the software work. It is to produce a defensible number you can decide on. Five conditions:
- One workflow, one client segment. Chosen with the scoring table above, not by whichever partner complained loudest.
- Your environment, your files, your systems. A vendor demo on a clean dataset tells you nothing about the client whose statements arrive as photographs of paper.
- A baseline measured before the start. Hours per engagement, cycle time, current review time. Someone has to actually collect this.
- Written exit criteria. The net-hours threshold, the completion rate by client stability, and the exception mix that constitute success, agreed in advance, in writing.
- Your experts in the build, not at the end. The tacit knowledge from failure mode 2 has to get into the system somehow, and there is no path that does not involve your people. The upside is that the capability stays with your team rather than with a vendor. That is a reason to insist on co-building rather than a cost to accept.
If a vendor resists any of the five, that is the finding.
What agents do with that work
This is what Adopt builds, and the design choices are specific to the failure modes above rather than to a feature list.
Agents operate the systems the source data lives in, including legacy accounting systems and banking or client portals with no API, because they navigate interfaces the way a person does rather than requiring an integration project. That addresses failure mode 1 directly, and it is the reason coverage extends past the two clients on modern systems.
The model does not touch the numbers. Rather than having a language model read a figure out of a document, it writes the format-conversion logic that a person reviews, and that logic moves the value. The plausible-number-with-no-provenance problem behind failure mode 4 is removed structurally rather than mitigated with a confidence score.
Every populated cell traces to its source. Workpaper cells carry formulas back to the source tab, agent-populated cells are marked, and a checker agent runs a validation pass with audit sampling in a maker-checker loop before anything reaches a reviewer. The reviewer reviews exceptions instead of rebuilding the artifact.
It runs where your client data already is. Cloud, private cloud, or on-prem inside your own infrastructure, on your choice of model, which is what makes failure mode 5 a configuration decision rather than a consent project.
The agents are yours. All agents, skills, and decision logic developed remain your intellectual property, and they are built alongside your team rather than delivered as a finished box. That is the answer to the vendor-owned-automation problem that made the RPA generation expensive to leave.
Nothing here removes the reviewer, and no serious design in this space should claim to. Human approval stays at every step. What changes is that your senior people stop producing the artifact and start signing it.
Running this across a client base? Book a pilot and we will build against your workpapers, your client systems, and your prior-year files, with exit criteria agreed up front.
Smaller firm, want to see it on your own work? Start free and run one live engagement through it.
A practitioner's checklist
Run the first half before you evaluate anything, and the second half before you sign.
Before you evaluate
- Preparation hours mapped to the six layers, for at least two real engagements
- Candidate workflows scored on volume, standardization, data accessibility, client stability, and current review cost
- First workflow chosen for repetition and low variance, not for how much it hurts
- Baseline captured: hours per engagement, cycle time, current review time
- Source systems inventoried, with API availability noted per system and per client
- Client data constraints checked against engagement letters and consent posture, in writing
- The person who will own this after go-live named
- Internal expert hours for the build budgeted explicitly
Before you sign
- Demonstrated on your own files, in your own environment, not a demo dataset
- Every layer the tool performs distinguished from every layer it only tracks
- Provenance verified by clicking a populated cell and following it to source
- Completion rates provided split by client stability, not blended
- Net hours saved defined to include review and rework
- Deployment location confirmed against your data constraints
- Validation and checking mechanism described specifically, not as "human in the loop"
- IP ownership of agents, skills, and logic stated in the contract
- Exit criteria for the pilot agreed in writing before it starts
- Review process redesigned for machine-produced output, with the checklist rewritten
- A plan for how junior staff build judgment once they stop assembling workpapers
This guide describes patterns observed across accounting and tax engagements at firms of varying size and process maturity. Results depend heavily on workflow, client mix, and process discipline, and the failure modes above are more predictive of outcome than any tool choice.
