Two reports show different revenue

Guide, October 2026. Applies to Power BI and Fabric. Examples use revenue, but the same pattern applies to headcount, active customers, tickets closed and every other number two teams both report.

Why the numbers differ

Open both PBIX files and compare the measure called Revenue. One sums net amount; the other sums gross and subtracts discounts in a second measure that the visual does not use. One uses order date; the other uses ship date, so a quarter boundary moves. One filters out refunds through a relationship to a status table; the other includes them because the relationship is missing. None of these is a bug in isolation. Together they guarantee disagreement, and the disagreement will come back after every fix because the definitions still live in two places.

The fix: one semantic model, one measure per number

1. Build the shared model

Take the better of the two models, or build a new one as a star schema (one fact, clean dimensions, single-direction relationships) over the gold tables. Publish it to the service as the semantic model for this subject. It holds the data, the relationships, the measures and the security roles. It holds no report pages.

2. Write the definitions down, inside the model

Every number gets one measure, with a description that the finance team has agreed, written in the measure's description field so it travels with the model and shows in tooltips.

Revenue =
SUM ( Sales[NetAmount] )
-- Description: Net of discounts and refunds, by order date. Agreed with Finance, 2026-10.

Revenue (gross) =
SUM ( Sales[GrossAmount] )
-- Description: Before discounts. For margin analysis only; never on the exec page.

Where two definitions are both legitimate, both exist with different names. The problem was never that gross revenue is wrong; it was that two things were both called Revenue.

3. Point every report at the model

Rebuild the two reports as thin reports connected live to the shared model (Get data, then Power BI semantic models). They contain visuals and nothing else. Any new report starts the same way. If a report needs a number the model does not have, the number is added to the model with a definition, not computed inside the report.

4. Endorse it and lock the alternatives

Mark the shared model as certified in the service so it shows first when people search, and set who may certify. Retire the old models, or at least remove their refresh schedules so they stop looking alive. Row-level security roles belong in the shared model too, defined once.

What changes afterwards

• The monthly meeting starts on the second slide, because both reports show the same Revenue and the tooltip says what it means.
• A definition change is one edit in one place, with a date in the description, and every report picks it up at the next refresh.
• A new analyst can build a report in an afternoon without reconstructing the business logic, because the logic is in the model they connect to.

Two cautions

• Do not let the shared model become everything. One model per subject area (sales, support, finance) stays understandable. A single model for the whole company grows relationships nobody can reason about and becomes slow for the reasons in the five fixes walkthrough.
• Agree the definitions before building. The technical work is a few days. The agreement between finance and sales about what Revenue means can take longer, and it is the part that makes the rest stick. Put it in writing, with a date.

When to ask for help

If more than two reports disagree, or if the models were built by people who have left, a short engagement to inventory the measures across all of them, propose the single set of definitions and build the shared model is usually a matter of weeks. The deliverable your finance lead cares about is the one-page list of definitions; the model is how it is enforced.

Related: why two reports show different numbers in the FAQ, semantic model in the glossary.