Let the Model Draft, Let the Structure Compute, Keep the Signature

Finance teams aren't refusing AI because it can't write. They're refusing it because they can't check what it wrote. Tracing each number to its source is the start; the figures also have to be computed rather than guessed, validated against the rules finance already applies, signed by someone who can see what they're signing, and kept as a record an auditor can follow.

If you lead a finance team, adopting AI shouldn't mean taking on a new worry. Wrightery is designed to make that easier: it shows where a report's numbers came from, runs the checks your team already relies on, and keeps a person's approval in front of anything that matters. It won't replace your judgment, and it isn't meant to. It's meant to make that judgment quicker to exercise and easier to stand behind.

A recent survey of 353 CFOs makes the adoption picture clear. Finance leaders are already putting AI to work on the financial close (66%), forecasting and planning (62%), compliance (54%), and reporting (45%). Their wishlist is practical: reconciliations, variance analysis, board narratives, cash forecasting, invoice processing, anomaly detection.

The same survey makes the objection just as clear, and it isn't about capability:

• 75% say a lack of auditability is why they won't trust AI with mission-critical work.
• 65% name their top frustration as confident answers built on the wrong data.
• 56% have received materially different outputs from the same prompt and the same data.
• Only 5% trust AI to produce a board-ready report without human review, and only 4% trust it with month-end close.
• Finance teams now spend 26% of their workday checking AI outputs.

That last number is the one to sit with. AI was supposed to take work off the finance team. Instead it handed them a second job: verification. When checking an answer takes as long as producing it, the time saved disappears, and the risk stays.

One fractional-CFO guide put the way out in a single line: "Let the model draft. Let a structure compute. Keep the signature." That line is close to a product specification, and it is how Wrightery approaches finance work.

Why "review it carefully" doesn't scale

The usual answer to AI risk in finance is a human reviewer. That is correct, and it is also why the verification burden exists. A reviewer handed a 12-page variance report has no way to know which of its 140 numbers were copied from the ledger, which were calculated, and which the model produced because they looked plausible. So they check all of them.

A fluent report is the hardest kind to review. Prose that reads well lowers the reader's guard, and a wrong figure inside a confident paragraph looks exactly like a right one. Software has a compiler and a test suite to catch this. A report has nothing, unless the system that produced it builds the checks in.

So the question isn't whether a human signs off. They must. The question is what the system hands the signer: a document to re-derive from scratch, or a document whose numbers have already been tied to their sources, with the exceptions flagged.

Step one: keep the evidence

You can't verify a figure against a source nobody kept. In most AI tools, the data a model read during a task — the rows it pulled, the file it parsed, the search results it skimmed — exists only for the length of that conversation and is then thrown away. A month later, nobody can show what a recommendation was based on.

The fix is simple to state: keep everything a run reads, unchanged, and make it findable. Without that, every later check has nothing to check against.

How Wrightery helps — available today. Every input a run touches, every uploaded spreadsheet, every query result and API response, is kept as an immutable piece of evidence with its own address and a content hash. A later step can read the actual numbers behind an earlier step's summary, not just the summary, and a reviewer can open the same material from the run. Everything else on this page builds on it.

Step two: tie out every number

With the evidence kept, the figures in a report can be checked for you. Nobody has to compute anything or look anything up. The check runs by code rather than by another model, once the draft is finished and before it reaches the reviewer:

1. Every figure is pulled out of the draft: amounts, percentages, counts, dates.
2. Each one is looked up in the evidence the run actually read, or tested as a simple derivation from figures that are there (a sum, a difference, a ratio).
3. Each figure is marked:
   • Traced: found in a source, linked to the row it came from.
   • Derived: computed from traced figures, with the formula shown.
   • Unconfirmed: not found, or matched too loosely to call.

What the reviewer receives is the report with a short ledger beside it: "138 figures traced, 1 derived, 1 unconfirmed." The reviewer's job shrinks from re-checking 140 numbers by hand to looking first at one. And because the check is deterministic code, it adds no model cost and no new source of model error.

An unconfirmed figure isn't automatically wrong. It might be a target the CFO set in the instructions, or a number from a document nobody attached. But it is exactly the figure a reviewer should look at first, and now the system points to it instead of leaving them to find it.

How Wrightery helps — available today. Wrightery runs this tie-out on the evidence it already keeps, as soon as a report is drafted. In the ledger, clicking a traced figure opens the exact row or field it came from, and unconfirmed figures are highlighted in the report itself. When a match is ambiguous, Wrightery says so rather than counting it as checked.

Step three: let a structure compute

Tie-out catches numbers that don't match the data. The stronger move is to stop asking the model to produce the numbers at all.

Language models are good at reading, summarizing and explaining. They are not calculators, and asking one to total a column is asking for the "materially different outputs from the same prompt" that 56% of CFOs have seen. So the arithmetic belongs somewhere else:

• A compute step runs the real totals, variances and reconciliations: a query against the ledger, formulas over the uploaded workbook. Its results are stored as evidence like everything else.
• The writing step receives those results as fixed inputs, and only writes the explanation around them: why revenue moved, what drove the variance, what the board should take from it.

Run the same report twice on the same data and the numbers come out the same; only the wording may vary. Every figure in the narrative traces to a computation by construction.

How Wrightery helps — available today. In a Wrightery workflow, one step queries the data through a database connection or reads the uploaded workbook, and its results become named figures, each with its source and formula. The writing step cites those figures rather than typing numbers, and Wrightery recomputes each one, so a number that doesn't match its figure is flagged before review.

Step four: validate with the checks finance already does

Every finance team carries a mental checklist: debits equal credits, the sections sum to the reported total, variance equals actual minus forecast, the period on the cover matches the period in the data. These are rules. A team writes each one down once, in plain terms, when it sets up the workflow; from then on the rules run on every report, with no one redoing the arithmetic.

When a check fails, the reviewer sees it before they sign, in plain terms: "Q3 total 1,204,330 doesn't equal the sum of its lines, 1,198,330." The report waits until someone fixes it or explicitly accepts the difference, with a reason that goes on the record.

How Wrightery helps — available today. Rules are written once on the workflow, as a plain-language label with a short formula, and Wrightery runs them on every report before the approval step. They aren't limited to finance: "passed plus failed equals total tests" is the same kind of rule as "debits equal credits".

Step five: keep the signature, and the record behind it

None of this removes the human. It changes what the human is approving.

The signature only means something if the signer can see what they're signing. With checked figures, the approval carries the full picture: the report, the tie-out ledger, the rules that passed and any that failed. And once signed, the run can be frozen into a single audit package:

• the report as approved;
• every source file, with its content hash;
• the tie-out results and the rule checks;
• the model and instructions that produced the draft;
• who approved it, when, and any exception they accepted.

That package is what an auditor, a controller or a board can be handed. It answers the 75% who cite auditability, not with a promise that the AI is accurate, but with a record that shows its work.

How Wrightery helps — available today. Any workflow can stop at an approval step before anything consequential goes out. The person responsible gets the report by email with a signed link, needs no platform account to decide, and sees the figure ledger and rule results beside it. The decision is recorded with who made it and when, and the approved run exports as an audit package.

One mechanism, any calculation

None of this is specific to finance. It works for any report with numbers in it: operations, sales, research, engineering. And two strengths of check fit two kinds of work:

• Verified (exact): when figures come from a compute step and the writing step cites them, each number is confirmed against its figure, and each figure against its source. This is the path for work that has to be right.
• Traced (best effort): when a report is written free-form, its numbers are searched for in the evidence. Most will be found and linked; the rest are flagged for a person rather than guessed at.

The rules and the approval step work the same way on top of either.

Where this stands

All of it is available in Wrightery today: the evidence trail, the number tie-out, computed figures, declared rules, and the approval step with its audit package. The checks are deliberately the deterministic parts: no extra model calls, nothing new that could hallucinate. They narrow what a reviewer has to look at; they don't make review unnecessary, and a figure the system can't confirm is shown as unconfirmed rather than hidden.

The survey also says what finance leaders need before they buy: one focused use case first, outputs traceable to source transactions, evidence of a return, and a fit with existing systems. The month-end variance report is a good first case. It's recurring, rule-heavy, and the cost of checking it by hand is easy to measure, which makes the 26% verification burden something you can watch come down.

The point

Finance teams aren't asking AI to be trusted. They're asking it to be checkable. The model drafts. A structure computes the figures and ties each one to its source. The rules your team already applies validate the result. A person signs, knowing exactly what they're signing. And the whole record, from source data to signature, is kept for whoever has to audit it later.

That isn't automation of the finance function. It's the verification finance teams already do by hand, done by the system that produced the work, so the people responsible can spend their time on judgment rather than re-arithmetic.