As AI moves from drafting emails to touching the numbers in a transaction, the word “verified” is being used loosely, and the looseness is dangerous. A vendor says their tool produces verified output. A team says they verified the AI’s work. But verified against what, to what standard, checkable by whom? In a context where a wrong number is a credibility event and a real liability, “the AI generated it and it looks right” is not verification. It’s hope with a confident interface.
Finance deserves a precise bar. This is an attempt to define one — what “verified” should actually mean when AI output enters a deal, stated concretely enough that you can hold a tool to it.
The standard has three parts: traceable to source, arithmetically checked, and auditable end to end. A number that can’t clear all three isn’t verified, regardless of how polished it looks.
Part 1: Traceable to source
The first and most important property: every figure must be traceable to the exact place it came from. Not “extracted from the data room” in general — this number came from this document, this page, this line.
This matters because the most dangerous AI error in finance isn’t a fabricated number. It’s a real number read from the wrong place: the forecast figure mistaken for the actual, the pre-adjustment EBITDA grabbed instead of the adjusted, the FY23 figure pulled into the FY24 row. These errors are invisible on the page — a wrong number looks exactly like a right one — and the only way to catch them is to walk each figure back to its source and confirm it.
Source-traceability turns verification from an act of faith into an act of checking. When a partner asks “where does this €4.2m come from?”, a traceable system answers in a click. A system that can only say “the model extracted it” has failed the first test, because there is no way to confirm the number short of redoing the work by hand — which defeats the purpose of the tool.
The bar: no figure exists in the output that can’t be pointed back to its specific source.
Part 2: Arithmetically checked
The second property: the numbers must satisfy the arithmetic identities they’re supposed to satisfy, and the tool must actually check them rather than assume them.
Financial statements are a web of constraints. The P&L ties to the cash flow ties to the balance sheet. Subtotals are the sum of their parts. A normalized EBITDA equals reported EBITDA plus the sum of the adjustments. Margins are the ratio of two lines that both exist elsewhere in the model. These identities are not decorative; they are how errors surface. A figure that breaks an identity is wrong, by definition.
A language model has no native respect for these constraints. It produces numbers that look plausible line by line, with no guarantee that they foot, cross-foot, or reconcile. “Verified” has to mean that the arithmetic identities are explicitly tested — that the balance sheet balances, the subtotals sum, the bridge ties — and that violations are surfaced, not smoothed over.
The bar: every arithmetic relationship the numbers should obey is checked, and any that fails is flagged.
Part 3: Auditable end to end
The third property: a human should be able to reconstruct how any output number came to be, without reverse-engineering it or asking the person who ran the tool.
This is what separates a tool that produces a number from a tool that produces a defensible number. Auditability means the chain is visible: this output figure is computed from these inputs, which were read from these sources, with these adjustments applied for these stated reasons. A reviewer can start at any figure in the final deliverable and walk the chain back to source without leaving the system.
Auditability is what makes the output survive contact with a buyer’s diligence team — whose entire function is to pick a number and demand its provenance. It’s also what makes the output survive the analyst leaving the firm: the audit trail lives in the system, not in one person’s memory of how they built it.
The bar: any figure in the final output can be reconstructed from source by someone who didn’t produce it.
Why this bar, and why now
These three properties aren’t an arbitrary wish list. They mirror how regulated and financial environments have always thought about trustworthy numbers — provenance, reconciliation, and audit trail are the foundations of every credible financial process, long predating AI. What’s new is that AI makes it cheap to produce numbers that look finished without any of those foundations underneath. The fluent, confident, well-formatted output is exactly the thing that lulls a team into skipping the checks.
So the standard has to be stated explicitly, because the tooling will not enforce it by default. A general-purpose model optimizes for plausible output, which is the opposite of what this bar demands. (This is the same asymmetry that makes reading a number reliably harder than generating fluent prose — fluency is forgiving, figures are not.) Meeting the bar requires building for it: provenance captured at extraction, identities checked at computation, the audit trail maintained end to end.
Using the standard
For anyone bringing AI into deal work, the three parts double as an evaluation test. Point a tool at real documents and ask:
- Traceable? Can it show the exact source — document, page, line — behind every figure, or only assert that it extracted them?
- Checked? Does it test the arithmetic identities and surface violations, or does it produce numbers that merely look consistent?
- Auditable? Can someone who didn’t run it reconstruct any output figure back to source?
A tool that passes all three has earned the word “verified.” A tool that passes none of them is producing plausible numbers, which is precisely the thing a deal cannot afford to trust. The gap between those two is not a matter of model quality or polish. It’s a matter of whether the tool was built to a standard that finance should have insisted on from the start.
“The AI generated it” was never going to be good enough. “Here is the number, here is its source, here is the check that confirms it, and here is the trail you can audit” is the bar. It’s worth holding every tool — and every team — to it.
NaS_OS is built to this standard: every figure traced to its source document, arithmetic identities checked, and an audit trail a buyer’s diligence team can follow end to end. If you want to test it against the bar on your own documents, apply for access.