Anatomy of a receipt

Take the sample number from our site: Active clients, October: 128. Every number on an Every Number dashboard has a receipt behind it. The data here is sample data, but the 6 parts are the same on every number we build.

This note walks through that receipt one part at a time: what each part says, why it's there, and which mistake it prevents. Then we cover how the product we're building will produce receipts, and why a receipt has to lead to rows.

The receipt at a glance

Part by part

Definition

Clients with a paid invoice in the last 90 days. One sentence in plain English, approved by you before anything is built. It exists because "active clients" means different things to different people. Finance might count paying clients, and sales might count anyone with an open deal. Without a written definition, 2 honest reports can disagree and nobody can say why. Our metrics dictionary template shows how to write these.

Filters

Status is not Test. Filters set which rows are in scope. This one keeps test invoices out of a count of real clients, so test records and demo data can't quietly inflate it. In this sample, the 14 left-out rows are all subtotals, blanks, and duplicates, so no row was dropped for being a test this month. It stays on the receipt anyway, because it's part of the rule, and it will matter the month someone logs a test invoice.

Rows used

1,270 of 1,284 rows. This is the denominator, and it's the fastest check on the whole receipt. If you expect about 1,300 invoices and a receipt says 640 of 640, the number probably came from a partial export or an old copy. You find out before the meeting, not after.

Left out

3 subtotals, 9 blank amounts, 2 duplicates. That's 14 rows, each listed with its reason. This part guards against 2 quiet errors: silent drops and double counts. A subtotal row, if it ends up in a sum, adds its whole group a second time. A duplicate adds an invoice twice. A blank amount could mean $0 or a number nobody has entered yet, and someone has to decide which. Listing the rows shows the arithmetic (1,270 plus 14 is 1,284), and it lets you disagree. If one of those duplicates is really 2 invoices that share a number, you can say so.

Source

invoices.xlsx, Invoices sheet. The file and the tab. Workbooks have many tabs, and files get copied, renamed, and emailed. This part prevents the argument about whose file is right, and the number quietly built from last month's copy.

Data through

Oct 15. The last date the data covers. "October" in the title doesn't mean all of October. It means the 90 days ending October 15, the last date the data covers. This part prevents reading old data as current, and comparing a count that stops mid-month with one that runs to month end. Our guide to data freshness on dashboards goes further.

When the definition changes

The definition behind this number changed once. Version 1 counted clients with any invoice in the last 90 days. Version 2, since October 9, counts only paid invoices. On the same data, v1 gives 146 and v2 gives 128, so the number is 18 clients lower.

The sample receipt on our site adds a version line (v2, since Oct 9). In the product we're building, every definition will carry its version and the date it changed. That matters because a definition change can look exactly like a real change. Without the date, a drop of 18 reads as 18 lost clients. With it, it reads as what it is: a stricter count. A metrics dictionary with versions, which shows the effect of each change, is part of what we're building.

How the product will make receipts

In the product we're building, a receipt isn't written after the fact. It's created in the same step that produces the number, from the same query and the same snapshot of your data. The calculation that counts 128 also records the 1,270 rows it used, so the receipt can't drift away from the number.

Each receipt will be stored with a content hash of the input snapshot and the query. A content hash is a short fingerprint computed from the exact bytes. NIST's Secure Hash Standard describes these digests as a way to detect whether data has changed since the digest was made. Change one cell in the snapshot, or one word in the query, and the fingerprint changes.

That's what will make last week's number reproducible. Run the stored query on the stored snapshot and you get the same number, and matching hashes show you're looking at the same inputs. No language model is involved at that point, which is why the result doesn't wobble. LLMs shouldn't write your numbers explains that design.

In the pilot today, a person builds each receipt by hand, following the same rules. Hashing and replay are part of what we're building.

A receipt you can open, not a badge

It's tempting to show provenance as a small "sourced" badge, or a footnote that says Source: Finance. Badges look like evidence, and research on AI answers suggests the look alone raises trust. In a study accepted to AAAI 2025, people trusted chatbot answers more when citations were present, even random ones, and trusted them less when they actually checked the citations. A 2023 audit of 4 generative search engines found that, on average, only 51.5% of generated sentences were fully supported by their citations, and only 74.5% of citations supported the sentence they were attached to.

So a receipt has to be checkable, or it's decoration. In our design, each part opens what it describes: the 1,270 rows used, and each of the 14 rows left out with its reason. In the pilot today, every left-out row is listed with its reason. If a receipt can't take you to rows, treat it like a badge.

You can see the 6 parts on how it works, and receipts in use on the sample dashboards. For the idea behind receipts, read What is data provenance?