Why financial calculations should never touch a language model

One of the earliest decisions in FinReview was also the most important: AI would never be responsible for any financial calculation.

This sounds obvious once stated. In practice, it is a boundary that is easy to blur. LLMs are capable of performing arithmetic. They can be prompted to calculate percentage gains, annualised returns, and portfolio weights. They will usually get the right answer. The problem is "usually."

XIRR — the Extended Internal Rate of Return used for SIP-style investments with irregular cashflow dates — is computed iteratively using Newton-Raphson convergence. The correct result depends on the precision of the date arithmetic, the handling of edge cases like zero cashflows, and the convergence tolerance. A language model asked to compute XIRR will produce a plausible-looking number. It may even be correct. But it cannot tell you whether it is correct, and you cannot verify it from the output alone.

That is the wrong category of tool for the job.

The separation I built into FinReview is explicit and complete. The analytics service layer — XIRR, P&L, concentration score, allocation drift, tax-loss candidates — is a set of pure functions. They take typed inputs and return typed outputs. They have no knowledge of AI. They have unit tests that assert exact values. They run without any API key. They are deterministic: given the same inputs, they will always produce the same outputs.

The AI layer sits entirely above this. It receives the already-computed analytics results and generates explanatory text. It is an interpreter, not a calculator. If the XIRR is 14.3 percent, the AI explains what that means in the context of the user's portfolio — it does not compute 14.3 percent.

This distinction matters for three reasons that compound on each other.

Trust. A user can verify a deterministic output by checking the underlying transactions and recalculating. They cannot verify an LLM output by any means available to them. When the number a user sees affects their financial decisions, the provenance of that number matters. Deterministic calculations earn a different level of trust than generated text, and the UI should reflect that difference — which is why FinReview labels AI briefings as informational and never presents them alongside the analytics as equivalent outputs.

Testability. I can write a test that asserts the XIRR of a specific cashflow sequence is 14.3 percent. I cannot write a test that asserts an LLM will describe a concentrated portfolio in the same words across two runs. Unit tests for deterministic code are specifications. There is no equivalent for generated text. Keeping these separate means the application has a tested, reliable core that the AI layer cannot corrupt.

Availability. The analytics layer works without an internet connection and without any API key. The AI layer degrades gracefully — if no key is configured or if the provider is unavailable, the application shows a fallback message rather than failing. This means the core functionality of the application is independent of any third-party service.

There is a broader principle here that extends beyond this project.

AI is genuinely useful as an interpreter, a summariser, and an explainer. It is poorly suited to being a calculator, a decision-maker, or a source of ground truth. The engineering discipline is knowing which tasks belong in which category and refusing to blur that boundary for convenience.

In 13 years of working with enterprise document platforms and customer communication systems, I saw many integration decisions made by capability rather than suitability — "the tool can do this, so we will use it for this." The result was systems where responsibility was diffuse and failures were difficult to trace.

Keeping financial calculations deterministic and using AI only to explain them is the same discipline applied to a newer class of tool. It is not a limitation. It is a design decision about where responsibility lives.