How to audit a revenue dashboard before executives use it
A revenue dashboard gets one first impression. If an executive finds a number in the first week that doesn’t match the board deck, every number after that is suspect, and the trust takes months to earn back. So before anything goes in front of leadership, I run the same audit. Here is the checklist, with the reasoning behind each item, because the reasoning is what tells you how hard to look.
Tie it out to the ledger
Start with the total. Whatever the dashboard calls revenue should tie to what finance recognized for the same period, or you should be able to explain every dollar of the gap. Pull the period total from the dashboard’s own query, pull the same period from the ledger, and reconcile them line by line. Timing differences, refunds, and credits are acceptable reasons to differ. “We’re not sure” is not.
Do this for more than one period. A single month can tie by accident.
Check the date boundaries and time zones
A large share of revenue disputes come down to what day something happened. The source system stamps events in UTC, the warehouse truncates to a date, the BI tool applies the viewer’s local time zone, and the month closes at a different moment in each layer. Pick one reporting time zone, write it down, and make sure every layer agrees. Then test the edges: the last hour of the month, the first hour of the next, and the weekend daylight saving changes.
While you’re there, confirm which date the dashboard keys on. Order date, invoice date, payment date, and recognition date are all defensible. Mixing them on one page is not.
Follow the currency and the fees
If revenue arrives in more than one currency, find out where the conversion happens, which rate it uses, and whether that rate matches what finance uses to close. Then find out whether the dashboard shows gross or net. Processor fees, discounts, taxes, and refunds each move the number, and each has a camp that considers its version the real one. The dashboard has to pick one, label it, and use it everywhere. A tile that says “Revenue” with no qualifier is a question waiting to be asked in a meeting.
Look for duplicates and late arrivals
Count distinct identifiers against raw row counts at every step of the pipeline. Joins duplicate rows quietly, and a retry in the source system can land the same record twice. Then look in the other direction: records that arrive after the period they belong to. A dashboard that shows last month as final on the first and then revises it for a week teaches readers to wait before believing anything. Decide how long a period stays open, show that status on the tile, and build the dedupe into the query instead of trusting the source to be clean.
Find the filters that silently exclude
Every dashboard carries filters that someone added for a good reason and then forgot. A status filter that drops a new order type. A date filter hard-coded to a fiscal year that has since ended. A segment filter meant for one tab that leaked into the shared dataset. Read every WHERE clause and every filter the BI tool applies, and for each one ask what it excludes and whether the readers know. The dangerous ones make the number smaller in a way that still looks plausible.
Freshness, and a name on the sign-off
Put a “data as of” timestamp on the page, computed from the data itself rather than from when the page loaded. Decide how stale is too stale, and make the dashboard say so when it crosses that line.
Finally, someone has to sign off, and it shouldn’t be the person who built it. The owner of the number, usually in finance or the business, reviews the reconciliation, the definitions, and the list of known gaps, and agrees in writing that this is the version executives see. Signing off doesn’t mean the dashboard is perfect. It means someone besides the builder has looked and is willing to defend it.
An audit like this always takes longer than anyone wants. It is still cheaper than relaunching a dashboard that was wrong on day one.