Why Your AI Gets the Numbers Wrong

Ask a frontier model to multiply two large primes and watch what happens. Researchers found GPT-4’s accuracy on a multiplication task fell off a cliff as the numbers grew, dropping from near-perfect on small operands toward almost nothing on larger ones. Same model. Same prompt structure. The only thing that changed was the size of the digits.

That should bother any finance leader who has been told an AI assistant can “handle the numbers.” Because the failure isn’t random. It’s structural. And it has a name.

The model never sees your number

Large language models don’t process text the way you do. Before a single weight fires, your input gets chopped into tokens, the chunks the model actually reads. For words this is mostly fine. For numbers it’s a quiet disaster.

Depending on the tokenizer, “1,234,567” might split into “1”, ”,”, “234”, ”,”, “567”, or some other arbitrary grouping. The model doesn’t see one million two hundred thirty-four thousand. It sees a sequence of fragments with no inherent numeric value. There is no place-value column. There is no concept that the leftmost digit is worth a million times the rightmost. The arithmetic structure that a ten-year-old understands is simply absent from the representation.

So what does the model do when you ask it to add, multiply, or compute a margin? It predicts the next token. It pattern-matches against the billions of number sequences it saw in training. When your example resembles something common, the pattern holds and the answer looks right. When it doesn’t, the model produces a confident, plausible, wrong number.

This is the part that should keep you up at night. It isn’t a calculator that occasionally errs. It’s a text predictor doing an impression of a calculator.

”Plausible” is the whole problem

A broken calculator throws an error. An LLM does something worse: it returns a number that looks exactly like a correct one. Right order of magnitude. Right format. Right confidence. Wrong value.

Independent evaluations of LLMs on multi-step arithmetic and reconciliation-style tasks have repeatedly shown failure rates that land in the rough neighborhood of 40 to 50 percent on harder deterministic problems, depending on the benchmark and the size of the operands. The exact figure moves with the test. The direction does not. Push a model past the patterns it memorized and accuracy degrades, often sharply.

In finance, that degradation isn’t an academic curiosity. Your numbers are large. Your calculations chain, revenue feeds gross margin feeds EBITDA feeds a covenant ratio. One pattern-matched error early propagates through everything downstream, and because each intermediate value looks reasonable, nobody catches it until a board member does the arithmetic by hand.

Why “use a bigger model” won’t save you

The intuitive fix is to wait for the next, smarter model. It won’t solve this. The problem isn’t intelligence. It’s architecture. A more capable model is a better pattern-matcher, but it’s still pattern-matching. It still tokenizes “47,318,902” into meaningless fragments. Scaling makes the impression more convincing, not the arithmetic more correct.

Worse, the trend cuts the other way for some “reasoning” models, which can introduce more places for confident error to creep in across longer chains. More steps, more surface area for a wrong intermediate to look right.

If you want a number to be correct, the model has to stop guessing it.

The fix: stop asking the LLM to do math

The reliable architecture is almost boringly simple to state. Let the language model do what it’s genuinely good at, understanding your question, interpreting intent, explaining results, and hand the actual calculation to something that doesn’t guess.

That something is a deterministic engine. Real arithmetic, performed by code that computes the same answer every time, against verified figures. The LLM retrieves the right inputs and frames the result. It never touches the math itself.

This is the core of how Rexfin works. We connect your accounting and financial data, QuickBooks, Xero, NetSuite, Sage, a warehouse, or uploaded statements, and build one reconciled financial model that ties out to the ledger. When you or your AI asks a question, figures are retrieved from that model and computed by a deterministic calculation engine, not generated token by token. Every output traces back to its source line. You can click a number and see exactly where it came from and how it was derived.

Two things follow from that design:

• The arithmetic is correct because code did it, not because a probability distribution happened to land in the right place.
• The inputs are correct because they’re reconciled against your books before the AI ever sees them, so you’re not computing precisely on garbage.

The second point matters as much as the first. A perfect calculator on unreconciled data still gives you a wrong, well-formatted answer. Trust requires both halves: verified inputs and deterministic computation. That’s the argument running through this whole pillar on building a reliable financial-modeling layer for AI.

What this means in practice

Picture the difference. You ask, “What was our blended gross margin last quarter, and how does it move if COGS rises 6 percent?”

An ungrounded LLM retrieves some numbers from its context, attempts the percentages in its head, and hands you a margin. Maybe it’s right. You have no way to know without redoing it.

A grounded, deterministic system pulls the reconciled revenue and COGS figures, runs the margin calculation in code, applies the 6 percent shift as a real what-if scenario, and shows you the result with every input cited. You’re not trusting the AI’s arithmetic. You’re trusting your own ledger, with a calculator bolted on top and an audit trail attached.

That’s a different posture entirely. One asks you to believe. The other lets you verify.

The honest limits

None of this makes the language model itself a financial authority, and it shouldn’t pretend to be. The model can still misread an ambiguous question or frame a result poorly. What changes is that the numbers underneath stop being a guess. Interpretation can be reviewed. Arithmetic, when it’s deterministic and traceable, doesn’t need to be re-derived by hand.

If you only fix the math and leave the data messy, you’ve solved half the problem. That’s why the 95% problem in GenAI pilots so often traces back to data readiness, and why even a code interpreter isn’t enough on its own, a point worth understanding before you trust retrieval to ground your financial answers.

The takeaway is blunt: an LLM that gets your numbers wrong isn’t broken, it’s working as designed. The fix isn’t a smarter guesser. It’s a system that doesn’t have to guess.

Want to see deterministic calculation over your own reconciled figures? Book a demo and bring a number you’ve caught an AI getting wrong.