LLMs Belong in the Narrative Layer, Not in the Financial Truth Layer

I like speed. I like fewer manual steps. I like any tool that removes pointless work from a close cycle.

But I do not like ambiguity in financial truth.

Large language models are inherently probabilistic. Financial reporting is supposed to be deterministic, traceable, and repeatable. Those two worlds can coexist, but only if we put a hard architectural boundary between them.

My opinion is simple: LLMs belong in the narrative layer, not in the financial truth layer. They can draft variance commentary, assemble disclosure text, and help you communicate what already happened. They should never generate, transform, “correct,” or reconcile numbers. They should never be the place where controls live. And they should never be the system that silently changes what is considered true.

I learned this mindset long before generative AI. As a former QA and test manager across hardware and software, and later running R&D organizations, I lived by one rule: if you cannot trace it, you cannot ship it. Reporting is the same discipline with higher consequences. If you cannot trace it, you cannot report it.

The two-layer model: truth versus narrative

Most teams mix these layers without noticing. A spreadsheet gets copied. A number gets reclassified “just for the deck.” Someone edits an explanation after the fact. The story starts driving the numbers.

With LLMs, that risk multiplies, because the tool is designed to produce a plausible answer. It is not designed to preserve a chain of custody.

So I separate the system into two explicit layers:

• Financial truth layer: ledgers, subledgers, data warehouse, deterministic calculations, versioned accounting rules, approvals, and sign-offs. Everything here is reproducible and auditable.
• Narrative layer: management commentary, disclosure drafting, variance explanation, and Q&A for internal stakeholders. Everything here is derived, never authoritative.

The boundary matters because it sets the governance stance. In the truth layer, you assume every change must be explainable and attributable. In the narrative layer, you assume every sentence must be supported by evidence, but you accept that writing is iterative.

If you want a mental model from industrial tech: treat the ledger like the sensor, and the LLM like the dashboard annotation. You can change the annotation all day. You do not “improve” the sensor reading with creative writing.

An auditable design: data-to-text, not text-to-data

The only design I trust in regulated contexts is a data-to-text pipeline. Not text-to-data. Not “chat with the numbers and let it update the spreadsheet.”

Here is the blueprint I would put in front of an audit committee.

1. Locked source of truth: general ledger and governed warehouse tables. Immutable where it matters, access-controlled everywhere.
2. Deterministic calculation layer: aggregations, mappings, eliminations, FX logic, allocation rules. Versioned rules and reproducible runs. No hidden steps.
3. Immutable evidence pack: the exact queries executed, parameter values, snapshots of result sets, links to source tables, timestamps, and the identity of the run. Think of it as a “build artifact” for reporting.
4. LLM constrained to the pack: the model only sees the evidence pack and a fixed reporting template. It drafts commentary and disclosure text, and it must cite which artifact supported which statement.
5. Change logs and approvals: edits to the narrative are tracked. Final sign-off remains human, and it references the evidence pack ID that was used.

This is the same operating principle I used when I ran international R&D teams. We did not accept “it works on my machine.” We accepted build artifacts, versioned dependencies, and test evidence. Reporting deserves the same standard of proof.

If you want to go deeper on operational guardrails for AI, the same philosophy shows up in my piece on why the stop button is the real AI value. Reporting needs a stop button too. It is called “no evidence, no sentence.”

What LLMs are excellent at (and what they are not)

Used correctly, LLMs can remove the lowest-value work in finance and ESG reporting. The work that burns senior time and creates errors through fatigue.

These are good uses:

• Drafting variance commentary from a predefined variance tree (price, volume, mix, one-offs), using only the evidence pack.
• Assembling disclosure text by stitching approved boilerplate with period-specific facts, again cited to evidence.
• Retrieving supporting evidence for internal questions, as long as retrieval is from governed repositories, not from the open web.
• Consistency checks on language: do the explanations contradict each other, do definitions drift across sections, do we use the same term for the same concept.

These are bad uses, even if they look efficient in a demo:

• Generating numbers (“estimate missing data,” “fill gaps,” “smooth anomalies”). That is modeling, not reporting.
• Transforming numbers inside a prompt (“convert this table into reported revenue by region”). That transformation needs a deterministic layer with versioned logic.
• Correcting data (“this looks wrong, adjust it”). The tool cannot own the control. Humans must investigate upstream, then re-run the deterministic pipeline.
• Auto-approving drafts or sign-offs. A signature must be attached to accountability, not convenience.

In my own ventures, including IBHQ and Shopeno, I think about AI the same way: let it accelerate decisions, not replace the system of record. The moment the model becomes the record, you lose both trust and debuggability.

Controls you can implement this quarter

If you are a CFO, controller, head of reporting, or a board member asking “what do we do now,” I would start with a short checklist. These are operator moves, not theory.

1) Write the boundary policy in one page

• LLM output is never a financial record.
• LLM can only draft text and must reference evidence artifacts.
• No LLM tool gets write access to the ledger, warehouse, or consolidation engine.

This policy prevents “helpful” shortcuts that later become invisible process debt.

2) Build an evidence pack like a software release artifact

• Store the queries and parameters that produced each reported table.
• Store snapshots of results, not just links.
• Assign a unique ID to the pack and make it the anchor for every narrative draft.

As a former quality leader in power electronics, I saw how quickly teams get disciplined when every failure can be traced back to a specific build. Reporting quality improves the same way when every claim maps to a specific artifact.

3) Force citations inside the narrative

Do not accept free-form commentary with no references. Require the draft to include internal citations such as “EvidencePack:2026-05 CloseRun:14 Query:RevenueByRegion_v3.” If the model cannot cite it, it should say “insufficient evidence.”

4) Make variance commentary a governed template

• Define the variance tree once.
• Define what counts as a one-off.
• Define thresholds for when the model can propose a narrative and when it must escalate to an owner.

This reduces the risk of narrative drift and makes commentary comparable quarter to quarter.

5) Separate “drafting” from “approval” in tooling

The LLM can live in a drafting environment. Approval must happen in a controlled workflow with identity, timestamps, and explicit sign-off. This is the same separation that industrial teams use between a test bench and production line.

The board-level question: what are we optimizing for?

Most debates about AI in reporting get stuck on labor savings. That is not the right objective function.

The real objective is: reduce cycle time without increasing audit risk.

When I ran a multi-country business unit with full P&L responsibility, the close was not just a finance activity. It was an operating rhythm. Forecast conversations, inventory decisions, and commercial prioritization all depend on whether the numbers are trusted. The moment trust drops, everything slows down. People start re-checking. Meetings become debates about data instead of decisions.

So I do not want “AI reporting.” I want auditable acceleration. Faster drafting, faster review, faster consistency checks. Same truth layer. Same control ownership.

This is also why I am careful about model size and deployment patterns in operational environments. The discipline of shipping reliable AI is about constraints, not ambition. The same theme appears in why small models are often the only sane way to ship. In reporting, the equivalent is a constrained model with a constrained context.

My takeaway: keep the machine honest by keeping it out of the truth

LLMs can absolutely make reporting better. They can remove repetitive drafting, improve clarity, and shorten cycles. They can even raise the quality bar by forcing consistent language and structure.

But only if you are strict about where they are allowed to operate.

Put them in the narrative layer. Feed them an immutable evidence pack. Require citations. Log every change. Keep the calculations deterministic and versioned. Keep approvals human and accountable.

That is how you get the upside without trading away the one thing reporting cannot survive without: financial truth.