Three correct numbers and one bad quarterly review

The worst quarterly review I have sat through had three revenue figures on three slides, and every one of them was right. The sales director's slide came from Sales Cloud and showed closed-won amount by close date. The finance controller's Power BI page showed recognised revenue by posting period, net of credit notes. The operations lead's page, built over Dataverse order and fulfilment tables, showed the value of what had actually shipped. The gap between highest and lowest was a little over eleven percent, and the first forty minutes went on which figure the board would see.

Nobody in that room had made an error. Each figure answered the question that team gets asked. Sales is asked what was booked. Finance is asked what can be recognised. Operations is asked what went out the door. The trouble started when all three answers got the same label in the same pack, because a reader who sees the word revenue three times expects it to mean one thing.

A semantic model picks a winner without telling anyone

The usual response is to build a semantic layer. A certified Power BI semantic model with one measure called Revenue, or a Data Cloud data model object with a calculated insight on top. I have built both and I still recommend them. What I no longer say is that the model resolves the disagreement. It ends the disagreement by making one definition the default and hiding the others, and that only works if somebody chose the default deliberately and told the people whose definition lost.

In practice the default gets chosen by whoever wrote the DAX. The Revenue measure in one model I reviewed summed opportunity amount where the stage was closed won, sliced by close date. That is the sales definition, picked because the opportunity table was the first one loaded. Finance opened the certified model, saw a figure that did not tie to the ledger, and quietly stopped using certified models at all. Two months later there were four semantic models with a Revenue measure, one per department, and the certification badge meant nothing.

Data Cloud has the same failure in a different place. When ingestion maps Sales Cloud opportunity lines and the billing system's invoice lines into the same harmonised object, the mapping decides whether a renewal counts once or twice and whether a credit note is negative revenue or a separate event. That decision lives in a mapping screen most report authors never open. The number they see downstream from Data Cloud looks authoritative, and nobody can say which rule produced it.

One contract, three timelines

The disagreement is mostly about time, and the fastest way to show that in a meeting is to walk one contract through all three definitions. Take a three-year services agreement signed in March for 360,000. Sales records 360,000 in March, because that is when the commission is earned. Finance recognises 10,000 a month for thirty-six months, because that is how the auditors expect it reported. Operations counts each milestone as the customer accepts it, which is lumpy and often late.

Put those three lines on one chart and March looks like the best month in company history for one team and an ordinary month for the other two. Then add the credit note issued in June when the customer disputes a milestone. Sales never sees it. Finance books a negative in June. Operations reopens the milestone. Three systems, three correct answers, one word.

A semantic model that sits over all three has to say, in writing, which timeline it follows and what it does with the events the other timelines record. That is the same line we drew where a lake meets a ledger, and it gets crossed just as quietly here.

The steward owns the sentence, the change, and the list

What fixes this is a named person, and I mean a name in a field rather than a team on a slide. The steward for revenue owns three things. The definition itself, written in one or two sentences a non-technical reader can check against a report. The change process, so that when someone needs the definition to move there is a person who says yes, a notice period, and a date. And the list of every report, model, and downstream feed that uses the measure, so the people about to be surprised get told first.

In Power BI most of that has a home already. The measure description field holds the sentence. The lineage view shows which reports hang off the certified model. Neither feature supplies the person, and I have seen tenants with immaculate lineage and nobody who would answer the phone when the number changed. On the Dataverse side the exposure is the option set. Someone adds a status reason for a pilot sales team, the DAX filter does not know about it, and revenue drops for that team with no error anywhere. The steward's list is what turns that into a ticket instead of a surprise in a board pack.

The steward is never the workspace admin. For revenue it is almost always someone in finance, because finance has to sign the number and defend it a year later. Holding the pen does not mean finance wins every argument. The sales and operations definitions get written down by the same person, under their own names, so they stop competing for the same word.

Rename the losing definitions instead of deleting them

The mistake I see after a steward is appointed is that the other definitions get removed. The sales dashboard loses its number, the sales director builds a private report from a Sales Cloud export, and within a quarter you are back where you started with less oversight. The number sales cares about is real. It just should not be called revenue.

So the semantic model carries three measures. Revenue, which follows the finance definition and is the only measure allowed to use that word. Bookings, which is closed-won amount at close date. Delivered value, which is accepted milestones at acceptance date. Each has a description, an owner, and a note on why it will never reconcile to the other two. The board pack shows all three side by side with a two-line explanation of the gap. Most of the arguing stops there, because nobody is being told their number is wrong any more.

Naming discipline is where governance earns its keep. A rule that only the certified model may publish a measure called Revenue, enforced in the review that certifies it, does more than any catalogue. It belongs next to the decisions about which tiles survive a dashboard review, because both settle who is accountable for what a page says. The wider governance conversation tends to open with permissions. Open it with names instead.

Put the definitions side by side in one meeting

The practical start costs one afternoon. Pull the ten most-opened reports across Power BI and Salesforce, and for each one list every measure called revenue, margin, or active customer. For each measure write down the source table, the filter, the date field it is sliced by, and the person who built it. You will usually find between three and six versions of revenue, and at least one where the builder has left and nobody can say what the filter does. Reading each filter out loud is the most useful thing that happens in the room.

Then get the owners of those ten reports in front of that table. The sentence I open with is this. Today we choose which number gets the name, who owns it, and what the other numbers will be called. Which number is right can wait. That framing keeps the sales director in the room, because their number survives, and it keeps finance in the room, because the word is going to them.

Book that meeting before the next semantic model gets certified. If one already is, open it, find the measure called Revenue, and read the filter. If you cannot say whose question it answers, you have found your first agenda item.