Certified Reports: Which of the Eleven Revenue Numbers Is the Answer
Eleven reports have "revenue" in the name and four of them disagree. Certification is the mechanism that marks which one is the answer — plus the quieter problem it exists to contain, which is a saved report drifting away from the data underneath it.
Give a capable finance team a report builder and eighteen months. What you will have at the end is roughly eleven reports with the word revenue in the title, three of which are somebody's abandoned experiment, two of which were correct in the year they were made, and four of which produce genuinely different totals for the same month for reasons that would take an afternoon to establish. The team is not careless. This is simply what happens when the ability to create a report is not paired with a way to mark one as the answer.
The failure mode is specific and expensive: a meeting where two people quote different numbers from the same system and the discussion becomes about the reports rather than the business. What follows is how certification addresses that, and — more interestingly — the second problem it quietly guards against.
The four states a report can be in
How much weight a report should be allowed to carry
Draft, private
Owned by one person, visible to them. The right home for an experiment, and the right place for most reports to stay. Nothing wrong with a private draft; the problem is only ever a private draft that gets quoted.
Shared, uncertified
Visible to a team or shared with named people, with no claim about accuracy attached. This is where the eleven revenue reports live, and where the ambiguity comes from — sharing looks like endorsement and is not.
Certification requested
Somebody has put a report forward as authoritative and it is awaiting review. The state that makes the whole thing work, because it creates a moment where a person has to actually check the definition rather than assume it.
Certified, with a named owner
Reviewed, marked, and attributed — the report carries an owner, review notes, who requested it, who reviewed it and when. This is the one you quote in a board meeting.
The point of a scale rather than a switch is that most reports should never be certified, and pretending otherwise defeats the purpose. If everything is certified, certification means nothing — the same way a spreadsheet folder where every file is called FINAL contains no final version. Aim to certify very few and to be slightly reluctant about each one.
What certification actually records
A certified report is not simply flagged. It carries a named certification owner, review notes, the person who requested certification with a timestamp, and the person who reviewed it with a timestamp. That combination is what makes it a control rather than a badge: there is somebody to ask, a record of what was checked, and evidence that a second pair of eyes was involved.
The review notes field is the one people skip and the one that earns its keep two years later. "Excludes internal transfers and credit notes; matches the ledger revenue account to the shilling for FY25" is the sentence that stops the same question being re-litigated by somebody new, and it is worth writing even when the answer feels obvious at the time.
The second problem: a report can drift without changing
Here is the failure that certification exists to contain, and it is subtler than duplicate reports.
A saved report holds a list of chosen columns against a dataset. Datasets are versioned, because they change — a field is renamed, a column is retired, a module is reworked. When that happens, a saved definition can end up referencing a field that no longer means what it did, or no longer exists. The report itself was not edited by anybody. It simply stopped being the report you certified.
There is a diagnostic for exactly this: an inspection that identifies saved reports whose fields have become broken or orphaned, and a cleanup path for them. Which is a good tool and also a hint about how to behave — the existence of a broken-field detector is an admission that field drift happens, and the correct response is to re-verify a certified report periodically rather than to assume certification is permanent.
How a correct report becomes a wrong one with nobody touching it
A filter written against a list of values is the most common way this happens, and the reason it goes unnoticed is that nothing breaks. An error would be a gift. What you get instead is a plausible number that is slightly too low, in a report carrying an official marking, which is a worse combination than an obviously broken report has ever been.
Deciding what to certify
Certify
Reports that leave the organisation or drive a decision with money attached
Anything in the monthly board pack, anything going to a lender, funder or auditor, and the handful of operational numbers people act on without checking. Realistically between five and fifteen reports in a mid-sized business. Each one gets an owner, notes and a review date.
Share, do not certify
Working reports a team uses daily and understands
A stock movement listing, an open-tickets view, a project time breakdown. Genuinely useful, correctly shared, and nobody is going to quote them in a bank meeting. Certifying these dilutes the marking without adding anything.
Leave private
Experiments, one-off questions, half-built ideas
The natural state of most reports. Private drafts cost nothing and clutter nobody. The discipline is not to avoid making them — it is to avoid sharing them casually, because a shared report reads as an endorsed one whatever you intended.
Archive or clean up
Reports nobody has run in a year, and reports with broken fields
Run the field inspection, deal with what it finds, and be willing to retire definitions with no recent runs. A report library that has never had anything removed from it is a library nobody trusts, because finding the right report becomes a research task.
Where certification does not reach
What AWRA OpsHub does today
- A certification status per report, with a named certification owner and free-text review notes.
- Requested-by and reviewed-by recorded with timestamps, so certification is attributable on both sides.
- Visibility handled separately from certification — a report can be widely shared and explicitly uncertified.
- Datasets and saved definitions both versioned, so drift between them is detectable rather than invisible.
- A field inspection that identifies saved reports referencing broken or orphaned fields, with a cleanup path.
- Run history per definition with row counts and durations, which is how you tell a live report from an abandoned one.
- Certification and sharing changes written to the audit trail with actor, IP and route — see who ran what.
What it does not do
- No automatic revocation when a dataset version changes. A certified report stays certified through a change that alters its meaning. Nothing re-opens the question for you.
- No scheduled re-certification or expiry date. Certification does not lapse, so a marking from two years ago looks exactly like one from last week.
- No enforced approval workflow — certification is a recorded review, not a gate that blocks the report until somebody signs.
- No numeric reconciliation between a certified report and the ledger; matching them is a human check you perform and describe in the notes.
- No duplicate detection, so nothing tells you that eleven reports have similar names and overlapping definitions.
- No warning when an uncertified report is used in a scheduled delivery to external recipients.
The absence of expiry is the one to compensate for deliberately, because it interacts badly with the drift problem above. Put a review date in the notes field yourself — "certified March 2026, re-verify each March" — and add certified-report review to whatever annual routine you already have. It is a thirty-second habit that prevents the specific failure of an official number that quietly stopped being true.
The real value is arbitration, not accuracy
Certification does not make a report correct. A carefully reviewed report can still be built on a misunderstanding, and no marking changes that. What it does is settle which report is the one the organisation stands behind — so that when two figures conflict, there is a rule for which one wins and a named person to ask about the difference. Most reporting arguments are not really about arithmetic. They are about authority, and that is the thing a certification marking supplies.
Our take
Certify sparingly — five to fifteen reports, the ones that leave the building or move money — and treat everything else as shared or private, because a library where everything is certified carries no information at all. Write the review notes even when the definition feels obvious, since that sentence is what stops the question being reopened by somebody new. Then compensate for the two real limits yourself: certification never expires and nothing revokes it when a dataset version changes underneath a saved report, so put a re-verify date in the notes and run the broken-field inspection as part of the same annual pass. The failure worth designing against is not a report that errors. It is a certified report that runs cleanly and returns a number slightly too low.
One report the organisation stands behind
Per-report certification with a named owner, review notes and both requester and reviewer recorded; visibility handled separately; versioned datasets and definitions with a broken-field inspection for drift.
See plans & pricingFrequently asked questions
What does certifying a report actually do?
It marks the report as the one the organisation stands behind, and records who is responsible for it: a named certification owner, free-text review notes, and both the person who requested certification and the person who reviewed it, each with a timestamp. It does not make the report correct — it settles which report wins when two figures conflict, and gives you somebody to ask about the difference.
How many reports should be certified?
Few. Realistically five to fifteen in a mid-sized business: the board pack, anything going to a lender, funder or auditor, and the handful of operational numbers people act on without checking. If everything is certified, the marking carries no information, in exactly the way a folder where every file is named FINAL contains no final version.
Can a certified report become wrong without anyone editing it?
Yes, and this is the failure worth understanding. Datasets are versioned because they change — a status value is added, a field is retired. A filter written last March against a list of values will silently exclude a new one, so the report runs cleanly, looks right, returns fewer rows than reality, and is still marked certified. An error would be easier to catch than a plausible number that is slightly too low.
Does certification expire or get revoked automatically?
No. There is no expiry and nothing revokes certification when a dataset version changes underneath the report, so a marking from two years ago is indistinguishable from one made last week. Compensate manually: write a re-verify date into the notes field and add certified-report review to an existing annual routine.
How do we find reports that have quietly broken?
There is a field inspection that identifies saved reports referencing broken or orphaned fields, with a path to clean them up. Its existence is itself the useful signal — field drift is a real phenomenon, so run the inspection periodically rather than assuming a saved report means what it did when it was saved. Run history with row counts also helps distinguish live reports from abandoned ones.
Is certification an approval workflow that blocks the report?
No. It is a recorded review rather than a gate — nothing stops a report being run, shared or scheduled while uncertified, and nothing warns you when an uncertified report is being delivered to external recipients. Treat certification as the label that resolves disputes, and handle who may see what through visibility and sharing, which are configured separately.
