# Your dashboards disagree on revenue. Moving the data will not settle it. Finance has one revenue figure, the product dashboard has another, and the proposed fix is a new data platform. Most of the gap lives in definitions, not storage. How to find the forks, settle them, and know when a lakehouse earns its place. By Precision Code Studios. Published October 16, 2026. Category: Data. https://www.precisioncodestudios.com/insights/dashboards-disagree-on-revenue The third-quarter board pack goes out on Thursday. On Tuesday afternoon somebody puts the finance slide next to the product dashboard and notices that revenue for the quarter is not the same number on both. The gap is a few points: small enough to look like rounding, large enough for a board member to ask which one is true. Nobody wants to answer that question live. By Wednesday, two analysts have checked their queries and both are correct. By the following week, someone has proposed the fix that always gets proposed: put all the data in one place, on one modern platform, so the company finally has a single source of truth. Consolidating the data is half the answer, and usually the more expensive half. The two numbers disagree because they answer two different questions, and putting them on the same storage only lets them disagree faster. The cheaper half is deciding what the numbers mean. Do that first, and the platform decision gets smaller and much easier to get right, whoever ends up building it. ## Two honest numbers Revenue sounds like one fact. In the data it is a chain of small decisions, each with two defensible answers. Finance picks one answer at each fork, the product team picks the other, and neither sees the other's choices because they are buried in a query or a spreadsheet formula. These are the forks that turn up most often: - **When the money counts.** At the click, at the invoice, when the cash arrives, or spread over the months the service is delivered. Finance reports what was earned; a product dashboard usually counts the sale the moment it happens. - **Which clock.** An order placed at 11:40 pm on 30 September in New York happened on 1 October in UTC, the universal time most servers record. Every quarter boundary moves a slice of orders across the line. - **What gets taken away.** Refunds, chargebacks, discounts, credits, sales tax and payment fees. Some come off at the time of sale, some weeks later, and some never reach the dashboard at all. - **Whose money it is.** Test accounts, staff accounts, partner resales, trials that converted. Product counts activity; finance counts what was invoiced to a real customer. - **Which exchange rate.** The rate on the day of the sale, or the month-end rate the accountants use. Tiny per order, visible across a quarter. - **Which system.** The payment provider, the billing database and the CRM each hold their own version of the sale, with their own delays and their own manual corrections. None of these is a bug. Each is a reasonable rule that somebody chose and never wrote down. The trouble starts when two of them travel under the same name. ## Settle it with a bridge, not a meeting The usual response to a disputed number is a meeting where each side defends its query. It rarely ends well, because the meeting argues about which number is right, and the useful question is why they differ. Accountants solved this long ago with the bridge: start from one figure, walk to the other in named steps, and put a size on each step. It works just as well for data. Pick one metric and one closed period, say revenue for the quarter that just ended. Start from the dashboard figure. Remove test and staff accounts, and record the difference. Apply refunds and credits. Move the orders that fall on the wrong side of the quarter boundary. Apply the finance team's recognition timing. Convert at their rate. Each step is a short query that both sides can read, and each one settles a piece of the argument for good. *Figure: A waterfall chart starting from a dashboard revenue figure of 100, stepping down through test accounts, refunds, time zone cut-off and recognition timing, up for currency rate, then a small orange unexplained residual, ending at a finance figure of 95. An illustrative bridge. Every step but one is a rule. The orange step is a defect.* The step that matters most is the last one. When every known fork has been accounted for and the two numbers still do not meet, what remains is not a difference of opinion. It is a fault: an integration that stopped sending events for three days in August, a join that counts a customer twice because they have two billing addresses, a currency field left blank for one market. Residuals like these are small, which is why nobody chases them. They are also the only part of the gap that is actually wrong, and they are wrong in every other report that touches the same tables. > **Chase the residual:** Once every rule in the gap is explained, whatever is left is a fault in the data. It is small, it is easy to ignore, and it is quietly wrong everywhere else too. A first bridge for one metric is usually a matter of days, not months. It needs an analyst, an engineer who can read the pipelines, and an hour or two with someone in finance who knows the rules. For what it buys, it is one of the cheapest data projects a company can run, and one of the least often run. ## Name both numbers, then give each an owner Once the bridge exists, the forks turn into decisions, and they are business decisions. Engineers can tell you what each choice does to the figure. They should not be the ones deciding whether a converted trial counts as new revenue. Often the right outcome is two metrics with two names. The product team has a real need to know what was sold yesterday; finance has a real need to know what was earned this quarter. Call the first gross bookings and the second recognised revenue, put both in the board pack if you like, and stop letting either one be called plain revenue. A surprising share of the argument ends there. Then write each definition once, in code, in a semantic layer. That is a layer between the stored data and the tools that read it, holding the formula for each metric, so that dashboards, spreadsheets and anything else ask it for revenue instead of computing their own. Give every definition a named owner, usually the team whose decisions it describes. Give it a version number, so last year's figures can still be explained after a rule changes. And give it a change process lighter than a committee and heavier than someone editing a dashboard on a Friday afternoon. *Figure: Left: billing, events and CRM feed a warehouse or spreadsheets, and the board pack, dashboard and AI assistant each compute revenue differently. Right: the same sources feed a lakehouse, then a semantic layer, and all three tools read one definition. Consolidation fixes where data lives. Only the definition layer fixes what it means.* ## Why this cannot wait until next year For years, a disputed metric was an annoyance that a good analyst absorbed. They knew which table was stale and which dashboard still counted test accounts, and they added the footnote. AI assistants take that analyst out of the loop. Ask a chat assistant connected to your data what revenue was last quarter and it will write its own query, pick a table, make its own choice at every fork in the list above, and answer in one confident sentence with no footnote. Ask again next week in different words and it may choose differently. Now there are three numbers, and the newest is the one an executive can get without asking anybody. The data industry has noticed. In September 2025, Snowflake, Salesforce, dbt Labs, BlackRock and RelationalAI launched the Open Semantic Interchange, an open specification for describing metrics, dimensions and relationships so that different tools can share the same definitions. A few weeks later dbt Labs released its MetricFlow metrics engine under the Apache 2.0 open-source licence as part of that effort, and this year the project moved into the Apache Software Foundation's incubator as Apache Ossie. You do not need to adopt any of it to take the hint. The vendors are standardising definitions, not storage, because that is where the disagreement lives. The working rule follows directly: before an assistant answers questions about money, it should read governed metric definitions rather than raw tables. If your setup cannot do that yet, keep the assistant away from those questions until it can. ## So, do you need a lakehouse? Possibly not, and you can find out cheaply. If your data already lands in one warehouse and the bridge explains the gap, you have a definitions problem. A semantic layer and named owners can usually fix it in weeks, on the platform you already pay for. A lakehouse keeps raw data in open file formats on inexpensive storage and puts warehouse-style tables and queries on top. It earns its place when the bridge itself is hard to build, and the signs are recognisable: - **The forks cannot be traced.** Billing, product events and the CRM live in separate systems, and the only place they meet is somebody's spreadsheet. You cannot reconcile what you cannot join. - **History gets overwritten.** The CRM records today's plan, not the one the customer had in March. When finance changes a rule, you want to replay it over past quarters, and that needs the raw history kept untouched. - **Models need the same data as dashboards.** Forecasting, churn models and AI features want event streams, documents and long history next to the tidy tables. A separate copy for each one creates a fresh set of forks. - **Storage costs outgrow the questions.** Keeping years of raw events in a system priced for fast queries gets expensive. Open storage underneath changes that arithmetic. Even then, order matters. Agree the definitions of the handful of metrics the board actually reads before migration starts, and use the bridge as the acceptance test: the new platform is ready when it reproduces the agreed figures for a closed quarter, with any residual explained. A migration without that test moves the argument to new storage and adds a few months to it. Whoever you ask to build it, ask them where metric definitions will live and who can change them, whether raw history will be kept so a new rule can be replayed over old quarters, how they will prove the numbers are right before you switch over, and what the AI assistant will read. Vague answers to the first question are the ones to worry about, because a platform with definitions scattered across its dashboards will give you the same Tuesday afternoon, on better hardware. A platform decides where your numbers are kept. What they mean is decided by people, in writing, with a name next to each rule. Until that happens, every tool you connect, the assistant included, is one more way for two honest numbers to disagree. ## The short film: transcript Two revenue numbers, one missing decision: the short version (1:29). Most companies discover this the week before a board meeting, and the instinct is to buy a new data platform. That helps less than you'd hope, and here's why. Nobody made a mistake. One team counts a sale the moment the customer clicks buy, the other counts it as the service is delivered, and each has a good reason. A late-night order in New York lands in October on a server that keeps universal time, and in September on the finance ledger. Now multiply that by every order, refund and test account. Start from the dashboard figure, take out the test accounts, then the refunds, then the timing. Give every step a size. If a gap is still left at the end, that's the pipeline that quietly broke in August. Product genuinely needs to know what was sold yesterday, and finance needs to know what was earned. Write each rule down once, in code, and make one person responsible for changing it. Ask a chat assistant for last quarter's revenue and it writes its own query and answers with confidence and no footnote. The big data vendors are now standardising metric definitions for exactly that reason. Agree the definitions first. The platform question gets much smaller after that, and often much cheaper. Read the full article at Precision Code Studios.