How to Evaluate a Finance Agent: Build the Accuracy Scorecard Before You Trust the Numbers

A vendor walks into your conference room, types “what was our gross margin last quarter and why did it move?” into a polished chat box, and an answer appears in four seconds with a confident paragraph and a chart. The room nods. Someone says “ship it.”

That demo proved exactly one thing: the agent can produce a plausible-looking answer to a question the vendor chose, on data the vendor prepared, with no way for you to check whether the number is right. It is theater. And the gap between “looks right” and “is right” is where careers end.

The uncomfortable benchmark numbers back this up. On FinanceBench, a test suite of question-answer-evidence triplets drawn from real SEC filings, models answered only about 47% of realistic questions correctly, got 26% flat wrong, and failed or refused on the rest. One widely-cited configuration of GPT-4-Turbo with retrieval missed or punted on roughly 81% of questions. These are not toy tasks. They are the kind of “read the filing, find the figure, reason about it” work a finance team does every day.

So before any agent touches your reporting, you need your own test. Not the vendor’s. Yours.

Why one demo question is the wrong unit of measurement

The deeper problem is that a single right answer tells you nothing about the next one. Large language models are probabilistic. Ask the same question twice and you can get two different numbers, even with temperature pinned to zero, because of floating-point rounding, GPU kernel behavior, and batch-size effects you do not control. Published work on output drift in financial workflows has measured accuracy swings of up to 15% across identical runs, with best-versus-worst gaps far wider than that.

For a CFO, that is the whole ballgame. A tool that is right 90% of the time is not a tool that is wrong 10% of the time in a way you can plan around. It is a tool that is wrong on a different, unpredictable 10% every time you run it. You cannot sign a board deck on that. You cannot put it in front of an auditor.

An accuracy scorecard exists to convert “it felt right in the demo” into a number you can defend: a measured pass rate, against known-correct answers, that you can re-run on demand.

The three things the scorecard has to measure

Most evaluation efforts measure one thing (did it get the answer?) and stop. That is not enough for finance. You need three dimensions, because an agent can fail in three independent ways.

Field-level accuracy. Does the figure match the reconciled truth, to the cent or the correct rounding? Not “is the answer in the right neighborhood.” Revenue of $48.2M when the ledger says $48.7M is not a near miss. It is wrong. Score every figure as a hard pass or fail against a known value.

Answer consistency. Ask the same question five times, on five separate runs, ideally on different days. Do you get the same number every time? Inconsistency is its own failure mode, separate from accuracy. An agent that is correct on run one and silently drifts on run four is more dangerous than one that is reliably wrong, because the wrong one you would have caught.

Traceability. For every figure, can the agent show where it came from (which account, which period, which source record) so a human can replay the path? An answer you cannot trace is an answer you cannot audit. We covered why replayability is a hard requirement, not a feature, in Audit Trails That Record Decisions, Not Just Actions.

You cannot grade a test without an answer key

Here is the part everyone skips. To measure field-level accuracy, you need ground truth: a set of finance questions whose correct answers you already know and trust. And those answers have to come from somewhere that ties out to the ledger: not from a second AI, not from a controller’s memory, not from last quarter’s deck.

This is where most evaluation projects quietly collapse. Teams discover they do not actually have a clean source of truth to grade against. Their numbers live in three systems that disagree at the edges, a half-dozen spreadsheets, and a consolidation workbook only one person understands. If your “correct answer” is itself unreconciled, your scorecard is measuring an agent against a guess.

Building the answer key is therefore the real work. Pick 50 to 100 questions that cover the shapes that actually matter: point lookups (cash at period-end), calculations (gross margin, YoY change, a covenant ratio), cross-period comparisons, and at least a few multi-entity or consolidated questions where errors love to hide. For each, lock the correct answer against your reconciled model. That set is your golden dataset, and it is the most valuable thing the exercise produces. We go deeper on assembling one in How to Stress-Test an AI Finance Tool.

Running it: the scorecard in practice

Once the answer key exists, the harness is mechanical. Set a threshold up front (we would not put anything below 95% field-level accuracy near external reporting) and grade against it.

• Accuracy pass rate. Percentage of figures that match ground truth exactly. Report it per question type, not just in aggregate; an agent can ace lookups and fail every calculation, and a blended score hides that.
• Consistency rate. Percentage of questions that return an identical answer across all repeated runs. Anything below 100% on figures is a red flag worth understanding before you proceed.
• Traceability rate. Percentage of answers that include a source path a human can follow back to the ledger.
• Drift. Re-run the whole scorecard monthly. Models get silently updated. Your data changes. A tool that passed in March can fail in June, and only a standing test will tell you.

A blunt opinion: if a vendor resists running their tool against your golden dataset, or wants to “help you prepare the questions,” you have learned what you needed to know. The point of the scorecard is that they do not get to pick the test.

The constraint nobody markets

None of this works if the agent is doing the arithmetic itself. An LLM that recomputes a ratio on every run will drift on every run: that is not a tuning problem, it is what the architecture does. The agents that pass a consistency test are the ones that retrieve figures from one reconciled model and push every calculation through a deterministic engine, so identical inputs produce identical outputs by construction. The reasoning can stay probabilistic. The math cannot. That separation is the whole thesis of the agentic AI trust layer, and it is why we built Rexfin so that the numbers come from a single source of truth that ties out to the ledger, and the answer always traces back to it.

A scorecard is how you stop trusting demos and start trusting evidence. Build your golden dataset, set the threshold, and make every tool (including ours) earn its place against numbers you already know are right.

If you want to see what a finance agent looks like when every figure traces to a reconciled source and the math is deterministic rather than guessed, book a demo and bring your own questions.