Dudley Gould argues that the growing temptation to solve data problems in accountancy with bigger AI models is misguided. Most accounting work is deterministic "calculator work" that needs certainty, not probability. The real solution isn't larger context windows — it's better infrastructure: standards and ontologies that let meaning travel with the numbers.
At a recent conference, I had a conversation that stuck with me. A fellow attendee asked: "How do I put my entire general ledger into an LLM? Context windows are a million tokens now - that's enough for a small company."
The question concerned me, and I think reflects a growing instinct to throw Large Language Models (LLMs) at every accounting problem, without first stepping back to ask what we’re actually trying to achieve, and what kind of tool is best suited to the task.
What's a context window?
A context window is how much information an LLM can 'see' at once — the text you give it plus its response. Bigger context windows mean you can feed in more data. But more data doesn't always mean better answers.
Most accounting is calculator work
The growing instinct to reach for an LLM is understandable. LLMs are powerful tools. They excel at tasks that involve judgement, language, and ambiguity such as reading long contracts, summarising board minutes, or drafting emails.
But just because you can, doesn’t necessarily mean you should. If you’re working with a general ledger data set there are very clear rules around how this data is expected to function – debits should equal credits, revenue transactions are usually negative, everything should tie to the trial balance, and so on. This sort of work is algorithmic and can best be performed with a calculator, Excel formula, or standard computer program. An LLM will probably get it right, but a calculator definitely will.
This distinction between deterministic systems and probabilistic systems is important. The former gives the same output every time for a given input — like a calculator. The latter – like an LLM - predicts the most likely answer based on patterns, so it’s powerful, but not guaranteed.
Of course, reality is more nuanced. You can technically force an LLM to be more deterministic by reducing its ‘temperature’ (its output randomness) or instruct an LLM to use a calculator – but the risk of hallucinations and inaccuracies is still there. And certainly, ‘dumping’ a GL into an LLM is risky. It might process and analyse it with 99.9% accuracy, but when you need certainty, that's not good enough. 99.9% on a dataset with 10,000 records is still 10 records reviewed incorrectly, and because LLM errors are essentially random, those 10 records could be critical.
I think most accountants, would agree with me that most of what we do needs certainty:
- Opening trial balance + movements = closing trial balance
- Cash flow statement ties to balance sheet cash
- Journals are complete and balanced
- Totals equal the sum of parts
Faster horses
So why are people reaching for LLMs to do calculator work?
I believe it is because most accounting work still lives in manual spreadsheets. Which is also why there is so much excitement about using LLMs to update Excel spreadsheets.
LLMs often do a decent job in Excel, as highlighted in this recent ICAEW Insights article. But they are far from infallible. And usually, the LLM isn't actually solving the core problem, it's masking a gap that better infrastructure and data governance would close.
| Task | What happens now | What it should be |
| Mapping/tagging data eg, a chart of accounts | LLM guesses that "AR" maps to "Current Assets" | With a standard schema, no guessing needed — it's deterministic |
| Extracting data, eg, bank statement data | OCR + LLM to interpret PDF statements | With Open Banking, structured data comes direct from the bank |
| Extracting and standardising data, eg, Reading audit confirmation responses | LLM extracts figures from PDFs, emails, and Spreadsheets in varying formats | With a shared platform and ontology, every dataset is structured and interpreted in the same way. |
And then there are many tasks that shouldn't exist as separate steps at all.
Take disclosure checklists. Auditors and accountants work through them manually — or increasingly, ask an LLM to help. But why does the checklist exist as a separate process? If the system knows you have cash on the balance sheet, it should know you need a cash note. If you have a lease liability, you need a lease disclosure. That logic should be embedded in the accounts production process, not checked afterwards.
The big picture
I think we're in the middle of an infrastructure shift, and it's happening on two fronts.
Connectivity — how data flows. Open Banking showed what's possible: standardise how financial data moves between systems and institutions, and you unlock an ecosystem. Open Finance is expanding this further.
Meaning — what data represents. We've had basic data standards for years (date formats, file structures). But increasingly we're moving toward ontologies — shared definitions of what things actually are. XBRL is an example that is making financial information machine-readable, with a new UK iXBRL digital reporting viewer launched by the FRC last year ahead of mandatory software only filings with increased tagging requirements.
What do we mean by an “Ontology”?
An ontology defines not just accounting concepts, but the relationships between them. Most systems know what a balance or a transaction is. They don’t know how figures relate. When those relationships are defined upfront, the calculations and checks can run automatically.
When both mature, we're not just able to share data. The industry will be able to share information (data in context). And that's when the industry will be able to properly automate much of the calculator work we do.
This is the concept of infrastructure inversion – a need to focus more on the ‘hidden’ elements of the system in order to drive more fundamental improvements to everything that is built on top. In the world of audit data analytics, the benefits of such an approach are clear. Instead of taking each client’s GL data and performing bespoke testing against it – in potentially dozens or even hundreds of different formats – focusing on the process of how the data is first obtained and standardised, allows the development of a set of tests against a single ‘common’ data model, which can be leveraged across all clients.
Or, with confirmation processes – instead of manually sending hundreds of requests and allowing them to be returned in any format (and probably every format imaginable), having a shared pipeline and ontology for how confirmation responses are provided allows all stakeholders to work to a common structure. Suddenly, downstream automation becomes possible — not because LLMs got smarter, but because the end-to-end process became automated in a deterministic way that doesn’t need an LLM.
LLMs will then be used for what they're genuinely good at: explaining findings, drafting narratives, brainstorming follow up procedures, helping you navigate complexity.
Closing thought
Most accounting data work is deterministic. What’s missing isn’t generative AI — it’s better foundations. The data pipelines and shared definitions needed to automate that calculator work end to end.
Until those foundations exist, LLMs will keep being used as a shortcut to true automation.
Next time you're tempted to throw all your data at an LLM, pause. Ask what the problem actually needs.
And if you're not sure which tool to use? Ask your LLM. That's something it is good at!
About the author
Dudley Gould is VP of Business Development at Circit and an active member of the ICAEW Data Analytics Community. His previous articles include I built my first AI Agent – using AI and From Dummy Data to Deepfakes.
