Skip to content
All blog
AI Accounting Technology

What language models changed in accounting — and what they didn't

Masni 8 min read

Finance teams were automating before 2023. Bank feeds, recurring journals, template-based invoice capture, matching engines — all long-established. It is worth being precise about what language models actually added, because the marketing has made it sound like everything and the reality is three specific things.

Change one: documents stopped needing templates

The old way to read a supplier invoice was to configure a template per supplier: the invoice number sits here, the total sits there. It worked, at a cost — someone had to build a template for every supplier, and it broke whenever a supplier redesigned their stationery.

For a business with forty suppliers that was tolerable. For one with four hundred, most of which invoice occasionally, it never got done, so those invoices stayed manual.

Language models read documents the way a person does — from context and meaning rather than fixed positions. A supplier the system has never seen produces usable data on the first document.

Why it matters: this is what made document automation viable for the long tail. Not the top twenty suppliers, which were always manageable, but the several hundred that generate most of the annoyance.

Change two: the system can be asked things

Before, getting an answer out of an accounting system meant knowing where to look — which report, which filter, which date range. That is a skill, and it gated access to the numbers. If the person who knew the reports was on leave, the business went blind.

Now the question can be asked in words. "What did we spend with this supplier last quarter compared with the one before?" That is a request most systems could always answer; what was missing was a way to ask without learning the report structure.

Why it matters: less that it saves the accountant time, more that it removes the accountant as a bottleneck for routine questions. The operations manager stops queuing for figures.

The condition: every answer has to be traceable to the underlying records. An answer you cannot click into is not an answer, it is a claim.

Change three: describing a process became a way of building one

The oldest constraint in business software: the person who understands the process cannot change the system, and the person who can change the system does not understand the process. Everything went through a translation layer of specifications, developers and delay.

Language models collapse that. A finance manager describes the approval flow they need and the system builds it. This is the shift we have written about in natural language replaced the ERP consultant.

Why it matters: the cost of a change falls far enough that processes get improved rather than endured. Most finance teams carry several workarounds that exist purely because changing the system was too expensive to justify.

What did not change: arithmetic

Here is the part the excitement obscures.

A language model is not a calculation engine. It produces plausible sequences, and a number that reads correctly is not the same as a number that was computed. Asked to total a column it may produce something close to right, stated with complete confidence.

In finance, close to right is wrong.

So the architecture that works keeps them apart:

  • The system computes. Balances, totals, matches, variances — deterministic arithmetic over records, exactly as before.
  • The model reads, proposes and explains. It turns documents into structured data, suggests treatment, and puts computed figures into a sentence.

Every figure in an answer should be one the system calculated and can show you the workings for. If a product cannot demonstrate that separation, it is exposed to a failure mode that is genuinely dangerous — see AI hallucinations in financial data.

What also did not change: the boring parts still decide it

A language model does not clean your chart of accounts, chase the supplier who has not sent the invoice, or resolve that two departments have been coding the same cost differently for years.

Implementations still succeed or fail on data hygiene, process clarity and whether people actually use the thing. Those were the deciding factors in 1995 and they are the deciding factors now. The technology got dramatically better; the preparation did not get any less necessary.

The honest summary

Language models removed the configuration barrier that kept document automation and system change expensive. That is a large, real change, and it is why automation that was previously only economic for big companies now works for small ones.

They did not make software good at arithmetic, and they did not remove the need to know what you are doing. Anyone selling you the second claim is selling you a disappointment.

Common questions

Did AI in accounting start with ChatGPT?

No. Accounting automation — bank feeds, recurring journals, matching engines, template-based document capture — long predates language models. What changed is that reading documents no longer requires a template per supplier, systems can be queried in plain language, and processes can be built by describing them, all of which removed configuration cost rather than inventing automation.

Can a language model do my bookkeeping arithmetic?

It should not be asked to. Language models generate plausible text rather than compute, so a figure they produce may read correctly without ever having been calculated from your records. In a well-built system the arithmetic is done deterministically by the software and the model's role is to read documents, propose treatment and present computed figures in readable language.

What is retrieval in this context?

Retrieval means the system fetches actual records and computed figures from your data and gives them to the model to present, rather than letting the model produce numbers from its own reasoning. It is the main architectural defence against confident wrong answers, and it is why every figure in a good system can be clicked through to the transactions behind it.

Does this mean older accounting automation was worthless?

Not at all — rule-based automation remains the right approach for anything that must never vary, such as approval limits and mandated treatments. What changed is that rules alone could only cover cases someone had anticipated, so the long tail stayed manual; language models and machine learning extend automation to the cases nobody configured.


Related: rules versus machine learning in accounting · AI in accounting · explainability in accounting automation


See what you could build

Start a free trial and describe what your business needs in plain language — SmartB Studio builds the module for you.

Start free trial
Get started

No credit card · Cancel anytime · Your data stays yours