AI for finance
In a financial report a figure without a source is not data: it is exposure. We build systems where every number can be traced back to the row that produced it, and where the model does not do arithmetic on its own.
Key takeaways
There is one rule in this domain: the model does not calculate. The numbers come from the system — a query, a sheet or a calculation engine — and the model explains and writes them up.
A language model gets sums wrong silently and presents the result with the same confidence as a correct one. All arithmetic lives outside the model, and that is an architectural decision.
Every figure in the report carries its source: which query, over which period, with which filter. Without that, nobody in the team can defend the number in a committee.
What pays best is not forecasting but consolidation: pulling together what today lives in five systems and three spreadsheets, which is where month-end hours go.
The five jams in a finance team
None of them is about analysis: all five are about collecting, reconciling and presenting, which is where the month goes.
- The variance surfaces once it has already happened, and by then the decision that would have prevented it is no longer available.
- Copy, paste, reconcile, format. The most mechanical part of the month and the one that occupies the most people.
- ERP, bank, billing, payroll and spreadsheets, and none of them ties out exactly to the others.
- The forecast model lives in a sheet one person understands, and that person takes holiday.
- By the time the figure is ready and validated, the window to act on it has closed.
The model does not calculate: it queries, explains and writes
This is the decision that separates a usable financial system from a dangerous one. A language model can get a sum wrong and present the result with exactly the same confidence as a correct one, with no signal that anything failed. So arithmetic leaves the model: the numbers come from a database query, the ERP or a calculation engine, and what the model does is interpret what they mean, write the analysis and answer questions about them.
The second rule is traceability. Every figure in a report carries where it came from — which query, which period, which filter — visible to whoever reads it. That is what lets someone on the team defend the number in a committee, and what makes the system auditable rather than a box that emits PDFs.
And a warning about forecasting: predicting cash flow is a statistical problem, not a language one. When the case calls for it, the forecast comes from a statistical model with its confidence interval stated, and the language model only explains the result. A forecast presented as a single confident figure, with no range, is a sign that nobody modelled anything.
What gets verified before a report ships on its own
| What is measured | What it means | How it gets fixed |
|---|---|---|
| Figure traceability | That every number in the report carries its query, period and source filter, all verifiable. | Structured output with the source mandatory on every row; anything without one does not publish. |
| Zero model arithmetic | On a sample: that no number in the report was calculated by the model rather than queried. | The calculation moves into the query or the engine and the model is left with the writing. |
| Consistency across sources | When two systems disagree about the same period, the report declares it instead of picking one. | An explicit reconciliation rule and an alert when the gap exceeds the agreed threshold. |
| Correct refusal | When the data is unavailable or the period is incomplete, it says so. | A financial report with a declared gap is useful; one that fills the gap is a problem. |
We do not build systems that make investment decisions, approve credit or authorise payments on their own. Responsibility for a financial decision has a name on the org chart, and automating it does not transfer that responsibility: it blurs it.
And if financial information lives scattered across sheets with no single source, the right project is that consolidation, not the assistant. An analysis system over data that does not tie out produces analysis that does not tie out, with better prose.
Related services
Integrations and APIs
MCP servers against the systems already in operation.
View serviceAI automation
Applied where there is volume and stable rules, not where there is expectation.
View serviceRAG systems
Chunking, reranking and hybrid search, evaluated with recall@k and NDCG.
View serviceAI consulting
Architecture, evaluation criteria and cost per query before writing code.
View serviceMore from the blog
RAG vs fine-tuning: which one you need
The question usually arrives framed wrong, as if these were two routes to the same place.
Keep readingLangGraph vs CrewAI vs AutoGen
All three build multi-agent systems and all three have a demo running in twenty minutes.
Keep readingn8n vs Zapier vs Make
All three connect systems without writing code and all three hit a ceiling.
Keep readingFrequently asked questions
How do you stop the system getting a number wrong?
By taking arithmetic out of the model, which is the only approach that works. Numbers come from a database query, the ERP or a calculation engine; the model interprets, writes and answers questions about them, but does not add up. On top of that, every figure carries its source visibly — query, period, filter — and on a sample we verify that no number in the report was calculated by the model. A language model that adds up wrong presents it with the same confidence as if it were right, and that is the reason for the rule.
Does it connect to our ERP?
Yes, over API or an MCP server against SAP, Dynamics or whatever you run, and directly against the database when that makes more sense. The part that usually takes the most work is not the connection but agreeing which system is the source of truth when two disagree about the same period. That decision belongs to the finance team, not to us, and it has to be made before building.
Can it forecast cash flow?
It can, on one condition: the forecast comes from a statistical model with its confidence interval stated, and the language model only explains the result. Predicting is a statistical problem, not a language one. Be wary of any forecast presented as a single confident figure with no range: it is a sign nobody modelled anything and the number came out of generated text.
Does our financial data leave our infrastructure?
Only if you accept that, and in this function the answer is usually no. We deploy on Azure OpenAI or Amazon Bedrock inside your own subscription, so the data never leaves your cloud. In any configuration we use enterprise plans where data sent through the API is not used for training, and we can work on aggregates rather than individual records where the case allows.
What should we do first?
Almost always consolidation and recurring reporting, not predictive analysis. Month-end is where the hours are, the work is mechanical, and the output can be checked against what the team already produces by hand — which makes it easy to demonstrate that it works. Analysis and forecasting come later, over data that already ties out.
How long does it take and how is it priced?
Four to eight weeks to production for a consolidation and reporting scope, with something running from week one. It is quoted with fixed scope, price and date in a proposal 48 hours after the first call, and the price is driven by how many sources have to be connected and how clean they are.
Book 15 minutes
Tell us what you are building, or what stopped working. You leave the call with a concrete answer: it can be fixed, it can be built, or it isn't worth it.