What is autonomous accounting? A practical framework for what AI can run and what still needs a human

Autonomous accounting is an operating model in which routine accounting work is executed end to end by software, and people supervise by exception instead of operating each step. The system captures the documents, codes them, matches them to bank activity and prepares the records. A person sets the policy, handles what falls outside it, signs off on anything that moves money or carries legal liability, and remains accountable for the result.

That last clause matters, because most definitions you will find skip it. Vendors in this space describe autonomous accounting as accounting tasks performed "without direct human intervention", or as a state where AI "minimizes human intervention in routine processes" while the accountant "provides the high-level judgment". Both are written for enterprise finance teams, and neither tells a founder with one bookkeeper and a Xero subscription which parts of their month can actually run on their own today, which parts should not, and why.

This article gives you a framework for that. It defines the levels of autonomy, applies them to each step of the accounting workflow, and is explicit about where the human stays in the loop. It is written for owners, but if you are the accountant or bookkeeper for owners, the same framework tells you what your job is turning into.

Automation, assistance, agents and autonomy are not the same thing

The word "autonomous" gets attached to anything with AI in it. For the framework to be useful, four terms need to stay separate.

Automation means a predefined task happens with less manual effort. A bank rule that proposes "Software subscriptions" every time a transaction says "Google Workspace" is automation. It does exactly what it was told, on the pattern it was told to watch for, and nothing else.

AI-assisted work means software helps a person do the work, but the person is still the operator. Invoice data extraction is the clearest example: the system reads the supplier, dates, totals and line items, and a person reviews and posts. The AI shortens the task. It does not own it.

Agentic workflows go further. The software can plan and execute several steps toward a goal, use other tools, and check its own results along the way. Finding the missing invoice for a card payment by searching the inbox, matching it, and queuing it for export is agentic. We covered how this is showing up in accounts payable in Agentic AI in accounts payable.

Autonomous accounting is the operating model that results when enough of those agentic workflows are reliable enough, and controlled well enough, that the default is execution without a person, and the person's job becomes supervision.

The distinction that does the most work is the one between the first two and the last two. In the first two, a person operates and the software helps. In the last two, the software operates and a person supervises. The automotive industry draws exactly this line in its SAE J3016 levels of driving automation: levels 0 to 2 are "driver support features" where the human is driving even when the car steers, and levels 3 to 5 are "automated driving features" where the system drives and the human is, at most, a fallback. Accounting software is crossing the same line now, one workflow step at a time.

The five levels of accounting autonomy

The framework below rates a single accounting step, not a whole product and not a whole finance function. A business can be at level 3 for invoice capture and level 1 for payments at the same time, and that is normal. The columns that matter for an owner are the last two: where responsibility sits and which controls are required before you should trust the level.

Two things to notice.

First, responsibility never leaves the person. It moves from "per transaction" to "per policy", and that is the whole productivity gain, but it does not disappear. If you file in the UK, HMRC's own guidance on using an agent says the figures on your return remain your responsibility even when someone else prepared them. No tax authority that we know of treats software any differently.

Second, the jump that changes how you work is from level 2 to level 3. Below it, a person still looks at every item, even if only to click OK. Above it, a person looks only at what the system could not resolve. Xero's own community makes the cost of staying at level 2 very concrete: there is a long-running request to apply bank rules automatically precisely because rules suggest the coding but a person still confirms each line, and users describe clicking OK hundreds of times in a session. That is supervised automation. It is useful, and it is not autonomy.

Applying the levels to each accounting step

The accounting workflow for a small business runs through five steps: capture the source documents, code them, match them to bank activity, pay what is owed, and close the period. Each step has a different ceiling today, for different reasons.

Capture: the step closest to autonomy

Capture means getting every supplier invoice, receipt and credit note out of wherever it arrived (inboxes, messaging apps, portals, a photo on someone's phone) and into one place, with the data extracted, duplicates identified and the original document kept.

This is the step where level 3 is realistic now. The decisions are narrow: is this an invoice, which entity is it for, have we seen it before, what are the fields. The exceptions are well defined: a document the system cannot read, a supplier never seen before, a total that does not add up, two documents that look like the same invoice. Each of those can go to a queue without blocking everything else.

The reason capture lags in practice is not the AI. It is coverage. A system can only be autonomous over the documents it can see, and in most small businesses the invoices are spread across a founder's personal inbox, a shared mailbox nobody owns, a WhatsApp thread with a contractor and three vendor portals. Autonomy at this step starts with connecting the sources, not with a smarter model. If a document never reaches the system, no level of autonomy applies to it, and the gap surfaces weeks later as an unreconciled bank line.

What stays human: the policy on which sources are in scope, and the decision on anything the system flags as a possible duplicate or a possible fraud. Invoice fraud increasingly arrives as a legitimate-looking document with changed bank details, and the control there is a callback to a known number, not a model. We cover the patterns in how to detect and prevent fake invoices.

Coding: autonomous for the known, human for the new

Coding (categorization, in most software) assigns each document to an account, a tax treatment and, where relevant, a class, project or entity. It is the step where "AI" claims are most common and most overstated.

For a supplier you have paid twenty times before, coding is a level 3 problem. The system has your history, the supplier's history and your chart of accounts, and the right answer is the one you gave last time unless something changed. The useful behavior is the system learning from your own past decisions and corrections, not from a generic model of what "Google" usually means. We described how that works in practice for Xero account coding.

For a supplier you have never paid, coding is a judgment call and should route to a person. Is a 2,000 euro purchase from a new vendor an expense or an asset? Does this contractor's invoice carry reverse-charge VAT? Is this software subscription for the business or for a specific client project you will bill back? Those are policy decisions. Once you make one, the system can apply it next time, which is exactly how level 3 is supposed to work: every exception you resolve should shrink the queue.

What stays human: new suppliers, ambiguous tax treatment, capitalize-versus-expense decisions, and any coding the system cannot explain. "Explain" is the control to look for. An autonomous coding step should show you why it chose an account, in terms you can check against your own history.

Reconciliation: autonomous matching, human gaps

Bank reconciliation is where documents, books and bank activity meet. The matching part (this bank transaction corresponds to that invoice) is mechanical when both sides exist, and level 3 is reasonable: amounts, dates, supplier names and references either line up or they do not, and partial payments, split payments and bank fees are known patterns.

The part that is not mechanical is what to do when one side is missing. A bank line with no invoice behind it is not a matching problem. It is a capture problem that reconciliation discovered late. The system's job at this step is to tell you, as early as possible and as specifically as possible, which supplier is missing which month, so that the search is narrow. Then a person, or an agentic capture step, goes and finds the document.

There is also a class of reconciliation decision that should stay at level 2 for most small businesses: write-offs, unexplained differences, and anything that would be resolved by creating a transaction the system has no document for. Those are the moments where "the system reconciled it" quietly becomes "the system invented an entry", and that is the opposite of control.

What stays human: every unmatched line that would require creating a record without evidence, and the sign-off that the period's bank activity is fully explained. Faster closes are mostly a function of how few of those lines are left when close week arrives, which is why we argue for weekly reconciliation in how to close your books faster.

Payments: deliberately not autonomous

Paying suppliers is the one step where the framework says: stop at level 2, on purpose, regardless of how good the software gets.

The reason is not capability. Preparing a payment run is easy to automate: select approved invoices that are due, group them by supplier, generate the bank file. The reason is that payments are irreversible, they are the target of most financial fraud, and the control that stops that fraud is a human one. In the AFP's 2026 Payments Fraud and Control Survey, 76% of US organizations reported attempted or actual payments fraud in 2025 and 74% were hit by business email compromise, the attack where someone impersonates a supplier or an executive to redirect a payment. A system that pays autonomously is a system that pays the attacker autonomously if the upstream data was manipulated.

So the realistic model for payments is: the system prepares the run, flags anything unusual (a new bank account for an existing supplier, an amount outside the supplier's normal range, a duplicate, an invoice that skipped approval), and a named person releases it. The approval is the product, not an obstacle to it.

What stays human: release of funds, approval of supplier bank-detail changes through an out-of-band check, and the separation between whoever approves an invoice and whoever releases the payment. If one person does both and the software does not stop them, no amount of AI makes that process safe.

Close: the last step to get there

The period close is where everything above is checked, accruals and adjustments are booked, and someone signs that the numbers are right. It is the step most often promised as autonomous and the one furthest from it, because it is not one task. It is a verification of all the other tasks plus judgment on timing, materiality and presentation.

Parts of the close are already automatable at level 2: recurring journals, accruals for known monthly costs, flags for invoices dated in the period but received after cutoff. The decision that the period is complete, and that the books can go to the accountant or the tax return, is a level 3 or 4 responsibility that stays with a person for the foreseeable future, because that is where legal accountability attaches.

What autonomy changes about the close is its shape. Today the close is a batch event: everything gets reconciled in the first week of the next month because that is when someone has time. When capture, coding and matching run continuously at level 3, the close becomes a short confirmation of work that already happened, and the person's time goes to the exceptions and the judgment calls rather than the data entry.

What stays human: materiality calls, accruals that depend on knowledge the system does not have (a dispute with a supplier, a service delivered but not yet invoiced), and the sign-off itself.

Where the levels stand today

Putting the five steps together gives a realistic picture of autonomous accounting for a small business as of now, rather than as a vision.

This is why "autonomous accounting" as a product claim should make you ask a narrower question: autonomous at which step, under what policy, with what route for exceptions? A vendor that can answer that per step is describing a real system. A vendor that answers "all of it" is describing a demo.

What this means for owners, and for the people who do their books

For an owner, the practical shift is from operating software to owning policy. The questions you answer change. Instead of "did we post the Google invoice", you answer "which suppliers are in scope, what counts as an exception, who releases payments, and how often do I sample what the system did". Those are better questions, and they take less time, but they do not go away. The failure mode to watch for is treating level 3 as level 0 in reverse: ignoring the exception queue because "the AI handles it". The queue is where your judgment is now needed, and an unworked queue is simply a backlog with better branding.

For accountants and bookkeepers, the credible version of this story does not write you out of it. It moves your work up the table. Data entry, matching and routine coding are the levels 0 to 2 that software is absorbing. Policy design, exception resolution, controls, review and advice are the level 3 and 4 work that remains, and it is work that clients will pay more for than they paid for typing. The firms that will struggle are the ones whose pricing still depends on the typing.

Which rows of the table Gennai works on today

Gennai is building toward autonomous accounting for small businesses, and the framework above is the one we use to describe what that means. It is not a claim that any row is finished.

Today the product works on capture, coding and the matching half of reconciliation: it captures supplier invoices from connected inboxes, forwarding, uploads and messaging channels, extracts the accounting-relevant data including line items, flags duplicates, categorizes invoices based on your own accounting history, reconciles uploaded bank statements against the captured invoices to update payment status and surface missing documents, and prepares or exports the records to Xero, QuickBooks Online and Holded. Review and correction stay with you and your accountant. Gennai does not connect to your bank, move money or close your books, which is to say it does not touch the two rows the framework keeps with a person.

If you want to see what that looks like step by step, how Gennai works is the current walkthrough. And if you are deciding where to begin, begin at capture. It is the step where autonomy is most realistic today, and every step below it depends on the documents being there.