How common is this shape?

It is the most common invoice export shape in the wild, and it reaches a page whenever someone sums the column whose name says total.

Do two independent reads catch it?

They do not, because both reads sum the same rows and agree perfectly on the same wrong number; only the file's own stated total sees it.

What if the file states no grand total?

Then the grain-aware figure is published labelled unverified, with the reason stated, rather than presented as proven.

Failure catalogue · The number is plausible, and wrong · 3 of 51

OBSERVED FAILURE MODE

The total that repeats on every line.

Many CRM and invoice exports carry the deal total on every line item, so the same money is written once per line. Sum the obvious column and revenue lands at a multiple of the truth. The column name says total, every value in it is real, and the grain is the only thing that is wrong.

What we saw

At Meridian Journal Group an advertising invoice export repeated the invoice total on every line of the invoice. Summing the column that any downstream tool would sum put revenue at nine times the truth, and nothing in the file objected: each value genuinely was that invoice's total, written once for every line the invoice contained. The correct figure needed the invoice as its unit, not the row. The export's own stated grand total was the one number that disagreed with the naive sum, and it was the only reason anybody looked.

Why it passes a glance

The column is named total, and every value in it is a true total of something. A glance at a sample of rows shows correct money. Two independent reads sum the same rows and agree to the cent on the same wrong figure, so a dual-read badge goes green. Only a total the file asserts about itself disagrees with the sum.

What addresses it

The hostile-exports skill names the total that hides in a column, and requires the landing report to print the naive sum, the plain statement that it is wrong, and the grain-aware figure beside it. Doctrine principle 1, an AI never authors a number, supplies the catch: every computed figure reconciles against the source file's own stated total, never against your recomputation of one.

Check your own file in two minutes

Pick a repeated key in your export, such as invoice or deal id, and count how many rows share each one.
Sum your money column twice: once across all rows, once across one row per key. A gap means the column is a repeated total.
Compare both figures against the grand total the file prints for itself, and publish the one that matches.

What this does not catch

This finds money repeated across a shared key. It does not find a file whose grain is wrong in a way the file itself agrees with, such as an export already aggregated by a dimension nobody asked for, and it needs a stated total to settle which of the two figures is right.

Quick answers

How common is this shape?: It is the most common invoice export shape in the wild, and it reaches a page whenever someone sums the column whose name says total.
Do two independent reads catch it?: They do not, because both reads sum the same rows and agree perfectly on the same wrong number; only the file's own stated total sees it.
What if the file states no grand total?: Then the grain-aware figure is published labelled unverified, with the reason stated, rather than presented as proven.

Nearby failures

The Total row that is also dataThe number is plausible, and wrong The wrong column that reconcilesThe number is plausible, and wrong The 100x slip that ties perfectlyThe number is plausible, and wrong

Last updated 2026-09-02 · Dylan, founder · one of 51 observed failure modes, every one seen in a real build or in our own audits, none invented.

Get the free skill → The doctrine All 51 failure modes