The dashboard nobody trusted: one number, three definitions

This is a pattern, not a single client story. Across 600+ workflows built for small teams, we have hit it often enough that we can describe the meeting before we walk into it. The names change. The argument does not.

The situation

The setup is almost always the same. A company of ten to forty people. Deals live in HubSpot or Pipedrive. Invoices live in QuickBooks. Someone built a revenue dashboard, in the CRM, in Google Sheets, or in a BI tool that arrived with a free trial. And every Monday there is a meeting where the dashboard is on the screen and nobody in the room believes it.

Here is the moment that repeats. The founder asks how revenue is doing. Sales reads the number off the dashboard. Finance looks up from a laptop and says that is not what the books show. The founder, who has a third number in their head, asks the question that names the whole problem:

"Which revenue?"

Three people, three honest answers.

• Sales means closed-won deal amounts this month, straight from the CRM.
• Finance means invoices issued, or sometimes payments received, straight from QuickBooks.
• The founder means something like "money I can count on", which is usually cash collected plus signed contracts that have not been invoiced yet.

The gap between these numbers moves every week, which is worse than a fixed gap. A fixed gap you can explain once. A moving gap looks like someone is hiding something. The mechanics behind it are mundane. A rep types the deal amount when the deal is created and never updates it after the final negotiation. The discount gets applied on the invoice, not the deal. An annual contract closes in March but invoices monthly, so sales counts twelve months while finance counts one. A deposit comes in at half. A refund goes through QuickBooks and nothing in the CRM changes. One contract is in US dollars and the books are in Canadian dollars.

None of that is an error. Each system answers its own question correctly. The dashboard takes one of those answers, labels it "Revenue", and presents it to a room where two of the three people are certain it is wrong. The constraint is also always the same: no budget and no appetite for a data warehouse. The fix has to live in the tools the team already pays for.

What we tried first

Our first instinct, early on, was to treat it as a data problem. Sync QuickBooks invoices onto HubSpot deals. Clean up old deal amounts. Add a property for final contract value. Rebuild the dashboard with better charts. It helps a little, and then it fails the only test that matters, the next Monday meeting. Someone still says "that is not the number I have", because the systems now agree with each other but the people still do not agree on the question being asked.

The second thing we tried was declaring a single source of truth. Pick the CRM and force every revenue conversation through it. Finance refuses, and finance is right to refuse. Your taxes are filed from QuickBooks. The books have to reconcile to the bank account. The CRM does not have to reconcile to anything, which is exactly why sales prefers it.

The third thing, which teams often try before they call anyone, is a new tool. The BI demo looks great. Then the disagreement survives the migration intact, and you have paid money to move an argument from one screen to another. Most reporting problems are process problems that look like tooling problems. We wrote about how to spot that in our operations leak audit notes, and this is the cleanest example we know.

The thing that mattered most

The insight, once we finally said it out loud, is small: "revenue" was three different metrics sharing one name. Nobody was wrong. The label was. Which means the fix is a writing exercise before it is an engineering one. Three parts.

Give each number its own name

Stop publishing a chart called "Revenue". Publish three charts with names that say what they count.

Name	Plain definition	Source	Question it answers
Bookings	Closed-won deal amounts this month	HubSpot	How much did sales sell?
Invoiced	Invoices issued this month, in CAD, excluding credit notes	QuickBooks	How much have we billed?
Collected	Payments received this month	QuickBooks	How much cash came in?
Committed	Collected plus signed contracts not yet invoiced	Both, per the written definition	What can the founder count on?

The founder's number usually turns out to be that fourth row, and it deserves a chart of its own rather than a place in someone's head. The instinct to collapse everything into one number is the thing to resist. Three honest numbers beat one contested one, every time.

Write the data dictionary

A data dictionary is lighter than it sounds: one short paragraph per chart, written in plain language, kept next to the chart rather than in a separate wiki, because the chart is where the argument happens. Each entry has six parts: the name, a one-sentence definition, the source system with the exact field and filter, what it excludes, who owns it, and when it refreshes. Here is the shape:

Invoiced (CAD). Total of invoices issued in QuickBooks in the calendar month, converted to CAD at the invoice date, excluding credit notes. Source: QuickBooks invoice report, status Sent or Paid. Owner: finance. Refreshes nightly.

That paragraph takes five minutes to write and it ends a disagreement that has been running for a year. When someone says the number is wrong, the conversation changes from "your dashboard is broken" to "I disagree with the definition". The second conversation is useful. Definitions can be debated, amended, and signed off. A feeling cannot.

Reconcile against the system of record

Accounting wins ties. Not because finance outranks sales, but because the accounting system is the only one in the building with an outside referee. It has to match the bank account, and your taxes are filed from it. So once a month, for thirty minutes, finance and whoever owns the dashboard sit down and compare. Dashboard Invoiced against the QuickBooks invoice report. Dashboard Collected against payments received. Every variance gets a written cause: a refund, a currency conversion, a deal edited after close. Then each cause gets fixed at the source so it does not appear again.

The first month, the variance list is long and a little embarrassing. It gets shorter. And this is the part we want to say plainly: that ritual is the product. A dashboard does not earn trust by being attractive. It earns trust by surviving a public comparison against the books, every month, with the differences explained in writing. A plain dashboard nobody distrusts beats a beautiful one nobody believes.

What shipped

In its smallest form, what ships is low-tech on purpose. Three named charts instead of one. A definitions block under each chart. A recurring thirty-minute calendar event called "revenue reconciliation". You can build all of that yourselves this week without hiring anyone, and if your operation is small, you should. If your whole month of invoices fits on one screen of QuickBooks, you do not need a dashboard at all. Read the invoice list. We mean that. Not every reporting itch needs a consultant.

Where it becomes a build is the integration work that stops the numbers drifting apart in the first place. This is RevOps work. The deepest version we have shipped was a GTM operating system where HubSpot deal stages triggered QuickBooks invoicing directly, and payment reconciliation flowed back against the deal. When the invoice is generated from the deal record, Bookings and Invoiced can no longer drift apart through a typo or a stale field. They can only differ for real business reasons: a discount, a refund, an invoicing schedule. Those reasons then show up on the monthly variance list with names attached, instead of as a mystery gap. That same build carried behavioural, intent, and demographic lead scoring, multi-touch attribution, and 300+ permits tracked across connected pipelines, and the revenue reporting still rested on the same three boring legs: named metrics, written definitions, monthly reconciliation to the books.

The dictionary itself has shipped in different containers depending on the stack: a definitions tab in the reporting spreadsheet, text blocks inside HubSpot dashboards, a footnote row under each chart in Google Sheets. The rule is placement, not format. The definition lives where the number is read.

On cost shape, since people ask: the definitions meeting is an hour and you do not need us in the room for it. The build itself, deal-to-invoice automation, sync jobs, the reconciliation report, is the billable part. Like everything we do, it gets a written scope before any work starts, at a flat $150 per hour CAD, and the hours never expire. If you are deciding whether any of this is worth doing at your size, our notes on RevOps for small teams cover that question directly.

What we would do differently

Hold the definitions meeting first. We used to build the pipes and then negotiate definitions under pressure, with a half-finished dashboard on the screen and everyone defending their own number. Wrong order. One hour, sales lead, finance, founder, whiteboard. Every metric gets a name, a sentence, and an owner before it gets a chart. The build goes faster afterwards because the spec already exists.

Ship fewer metrics. Every number without a written definition and a named owner is a future argument with a render time. Four well-defined charts beat fourteen pretty ones. When someone asks for a new metric, the price of admission is a dictionary entry. If nobody will write the paragraph, nobody needed the chart.

Stop trying to crown one number. We spent real hours in early engagements trying to engineer a single true revenue figure. It does not exist. Bookings, Invoiced, and Collected answer different questions, and a founder running a real business needs all three. The goal was never one number. It was zero surprises between numbers.

Push back harder on tool migrations. When a team mid-argument asks us whether a new BI platform would help, the honest answer is usually no, not yet, and we now say it earlier. Definitions travel. Arguments travel too. Settle the argument in the cheap tools first, then decide if you have a volume problem worth new software.

FAQ

What is a data dictionary and where should it live?

It is one short written definition per metric: the name, a one-sentence plain-language definition, the source system and exact filter, what it excludes, who owns it, and when it refreshes. It should live next to the chart it describes, not in a separate wiki, because the argument about the number happens while people are looking at the chart.

Which system should be the system of record for revenue?

Your accounting system. QuickBooks, or whatever you file taxes from, is the only system that has to reconcile to the bank account and stand up to outside review. The CRM is the system of record for deals and activity, not for money. When the dashboard and the books disagree, the books win and the dashboard gets corrected.

Do we need a BI tool or a data warehouse to fix this?

Usually not at small-team scale. The disagreement is about definitions, and a definition dispute survives any migration, so a new tool moves the argument without settling it. Fix the names, the written definitions, and the monthly reconciliation first, inside the tools you already pay for. Consider heavier tooling only when the volume of data, not the trust in it, becomes the problem.

How long does this take to fix?

The definitions part is a one-hour meeting with sales, finance, and the founder, and you can run it yourselves this week. The integration work that keeps numbers from drifting, such as generating invoices from deal stages and syncing payments back, depends on your stack, so we scope it in writing before any work starts, at a flat $150 per hour CAD.