Accounting is not an LLM problem anymore
We don't need a better frontier model to automate accounting. The missing piece is the operational system that gives models facts, context, rules and controlled execution.

Give the best model in the world your bank statement and a folder of invoices. It will understand every line.
It still can't close your books.
Accounting is not an LLM problem anymore. It's a harness and tooling problem. For most day-to-day accounting workflows, model intelligence is no longer the main bottleneck. What's missing is the software around the model: the facts it can trust, the rules that constrain it, and the tools through which it acts.
The bottleneck has moved
Ask a frontier model to explain accrual accounting, reconcile a tricky payment, or pick the right account for an odd invoice. It will do fine.
So why isn't accounting automated yet?
Because the hard part of accounting was never the reasoning. It's everything around it. Which invoice is this? Has it already been booked? Which customer paid, for which order, at which VAT rate? Is the bank feed from this morning or from last week? Did someone already fix that entry by hand?
A smarter model doesn't answer any of that, without a reliable environment. It just guesses more fluently.
Accounting punishes guessing
Most tasks tolerate a bit of creativity. Accounting doesn't.
The books have to balance. Every entry has to trace back to a document. The same input has to produce the same output, today and during the audit three years from now.
A probabilistic model writing directly into your ledger is the wrong shape for that job, however clever it gets. You don't want a ledger that is right 99% of the time. You want one that is right, and can prove it.
Accounting starts before the invoice
Traditional accounting software starts when the financial document appears. We think accounting should start one step earlier: with the business event that created it.
An invoice is not just an invoice. It came from an order, an event, a delivery, a contract or a purchase. A payment settles a quote that a customer accepted. A supplier expense belongs to a project. Eighteen bottles were bought for a specific event.
When those objects already live in the same system, much of the accounting context doesn't need to be inferred by AI. It is already known.
What accounting actually needs
Closing the books without someone re-checking every line takes four layers:
- Facts. One system of record where invoices, payments, orders, customers and entries live, linked to each other. Not a pile of exports.
- Context. What those facts mean for this business. A sale belongs to a contract. An expense report is tied to a client, a trip or a project. The business around the number is what makes the number meaningful.
- Rules. Versioned policies for matching, posting, VAT and closing. They express what should happen, for which jurisdiction and from which date.
- Controlled execution. Scoped permissions, deterministic code, validation, approvals, idempotency, audit logs and reversible actions. The system applies a decision safely and escalates uncertainty instead of hiding it.
The model can work across all four layers without becoming the source of truth for any of them.
The rules move too
Reliable facts aren't only about your own transactions. The rules change as well.
January. A deduction cap changes. Your agent asks the web. It finds a 2023 blog post, a forum thread, and a page about Belgium. It picks one.
In Europe, this isn't an edge case. Twenty-seven member states share a common VAT framework, but each sets its own rates, deduction rules and reporting obligations, and updates them on its own calendar. E-invoicing mandates arrive country by country.
Web search is the wrong source of truth for this. Accounting needs a reliable, maintained source of rules: versioned, dated, and tied to the jurisdiction it applies to. When a rule changes, every flow that depends on it must apply the right version from the right date.
Where the model fits
The model still does the work. It just doesn't work alone.
It reads invoices and receipts, sorts expenses, answers everyday questions and drafts entries. It also helps build the tooling: writing a new matching rule, turning an accountant's practice into a flow, or explaining why an account doesn't reconcile.
What changes is what it can decide alone. The model proposes and interprets. The policy engine constrains. Deterministic code executes. A person resolves uncertainty and approves high-risk cases.
The model reads and reasons. The rules decide what gets booked.
That split is what makes automation trustworthy. A deterministic rule can still be wrong, but it can be reviewed, tested, versioned and reversed. When something goes wrong, you don't ask a model why it felt like booking that entry. You inspect the rule, the evidence and the approval trail, then fix the system.
Where the accountant fits
Every business needs an accounting tool. Not every question needs an accountant.
"Did the client pay?" is a fact. "Which VAT rule applies here?" may be a policy lookup. "Does this unusual contract require a provision?" may need judgment. A trustworthy system knows the difference.
The accountant's time goes where it counts: complex treatments, risky decisions, changing regulation, review, and the cases the rules do not cover. Every recurring correction becomes a candidate for a rule, so human judgment compounds instead of being spent repeatedly on the same operational work. Less data entry. More judgment.
Where this goes
Today, a tax audit comes years after the fact. Someone samples your books and hopes to find what went wrong.
Now imagine the tax authority approves the harness itself: the rules, the flows, the system of record, and the limits on what the model can do. The check then happens the moment an invoice goes out or an expense hits the books. If the software says it's good, it's good. No surprises three years later.
This isn't science fiction. France already requires certified cash register software, and invoices now flow through state-approved platforms. Italy has routed every invoice through a central system since 2019. Spain sets requirements every invoicing software must meet. The next step is approving the whole chain.
For governments, it's a massive saving: every company checked, continuously, instead of a few sampled by hand. For businesses, the audit stops being a threat. It's already done.
The work ahead
None of this waits on the next model release. The ingredients are here. What's left is engineering: modeling the business, connecting reliable data, maintaining the rules, and building the controlled execution layer around them.
That's exactly what Enobase is built for. Each trade we model gets its own system of record and its own context: the business records that accounting entries refer back to. Accounting is the next layer on top of it.
The model is ready. The tooling isn't. That's the part we're building.
Want to see your accounting run on a real system of record? Book a call with us.
