Enterprise finance intelligence
Designing a conversational interface for complex enterprise financial data, without outsourcing calculation and trust to a language model.
- Type of work
- Internal prototype
- Context
- Enterprise finance · Internal project
- Disciplines
- Conversational analytics, Tool orchestration, Structured data, Product architecture
Problem
The financial data existed, but answering a straightforward business question often meant finding the right file, then filtering and interpreting it by hand.
Context
The product concept was designed around the financial and operational data that informs business decisions. It was available mainly as structured datasets, such as spreadsheets, updated on a regular cycle.
Every answer depended on knowledge that sat outside the data itself: which source to use, which dimensions and measures were relevant, which filters to apply, how to compare periods, how the business was structured and what financial context to read the result in. The questions were often straightforward. Getting to the answer was not.
The product question
Could a conversational layer make this data easier to interrogate, while keeping data access, calculations and reasoning reliable and traceable?
The shortcut is to hand a language model the spreadsheet and let it answer. It demos well and fails quietly: the model can misread a table, total the wrong rows or state a plausible figure that no calculation supports. With financial data, a fluent wrong answer is worse than no answer. The model could not be the source of the numbers.
Approach
Separate the concerns, and give each part the work it does reliably:
- Question understanding: the language model interprets what is being asked (the measure, the period, the comparison and the part of the business).
- Tool selection: an orchestrator decides which tools the question needs, and in what order.
- Data access: structured queries run against the data through a semantic layer.
- Computation: calculations run deterministically, outside the model.
- Reasoning: the model interprets the results and explains them in plain language.
- Presentation: the answer arrives with its evidence.
Because the parts are separate, they compose. A simple lookup needs one query. Comparing a quarter with the year before needs a query and a calculation. Asking what a measure includes needs its definition retrieved. The orchestrator chooses the path; the numbers come from the tools, not from the model.
System model
-
Business question
“How do this quarter’s costs compare with the same quarter last year?”
Plain language. No need to know the file, the filters or the measures.
-
Language model
AI orchestrator
Works out what is being asked and selects the tools that can answer it.
-
Tools, selected and combined per question
-
Data query
Returns the figures for the right measures, filters and periods.
-
Calculation
Totals, variances and period comparisons, computed deterministically.
-
Retrieval
Definitions and context, such as what a measure includes.
Where the numbers come fromStructured data & semantic layer
Measures, dimensions, business structures and periods, defined outside the model.
-
-
Language model
Reasoning & explanation
Interprets the results and explains them in plain language.
-
Evidence-backed answer
The result explained, with its sources and calculation.
Decisions
-
Calculate, don’t generate
A language model can explain a variance convincingly and still get it wrong. Totals, variances and period comparisons come from deterministic queries and calculations, so a figure can be reproduced and checked.
-
Separate data logic from AI reasoning
Measures, dimensions, business structures and period definitions live in a semantic layer, not in prompts. The financial logic can be reviewed and changed without depending on how a model reads its instructions.
-
Compose tools per question
Different questions need different tools, queries and calculations. Selecting and combining them per question avoids forcing every question through one fixed pipeline.
-
Extend with tools, not rewrites
A new dataset, calculation or knowledge source is added as another tool the orchestrator can choose, without rebuilding what already works.
-
Keep the model replaceable
Models, and their pricing, change quickly. The model sits behind an abstraction, decoupled from the interface and the data layer, so the product does not depend on a single provider.
-
Show the evidence
An answer about money has to be checkable. Each answer shows the data, filters and calculation behind it, so it can be verified rather than taken on trust.
Prototype and architecture
An extensible product and architecture model for conversational analysis of enterprise financial data.
- An MVP architecture designed and prototyped for AI-assisted analysis over structured enterprise data
- A clear division of work, with deterministic tools for data and calculation and the language model for understanding and explanation
- A composable, model-agnostic design that new data, calculations and models can extend
What I learned
With financial data, the model should be the interpreter, not the calculator. Trust comes from the evidence behind the answer.
An internal project, presented without the organisation’s data, figures or internal names. The architecture is shown at the level of principle, not implementation.