Agree which revenue the question means
“Which revenue is this?” is a question I have heard from CFOs during finance AI demonstrations. Bookings, invoiced revenue and recognized revenue can each be defensible, but they support different decisions. Once that question comes up, the model comparison has to wait. I want finance and the report owners to work through a concrete example together and agree which figure the workflow should use.
I learned to take those differences seriously while leading banking data programs. Reports could be individually defensible and still fail to answer the question the reviewer thought they answered. Working through the rule, its owner and a sample calculation was how we made the disagreement tractable. I would do that work before connecting an assistant to finance data, while the people who understand the definitions are available to make the decision.
Start with a real disagreement, not a glossary
Open the workshop with a recent dispute. Bring the reports that disagreed, the question that triggered the argument and the decision someone was trying to make. Ask each report owner to walk through filters, timing and adjustments. The goal is not to crown one report correct. It is to make the legitimate differences visible.
Keep the scope narrow. One metric used in a recurring decision is enough for a first session. I have watched organizations try to standardize the entire finance vocabulary before a pilot, and the pilot never starts. Resolve the definition the chosen workflow needs, log the dependencies, and move.
Write the definition as a decision aid
A usable definition states the business meaning, included and excluded records, reporting period, currency treatment and accountable owner. It also says when the metric should not be used. A precise formula without those conditions still produces misleading answers.
Take overdue receivables. Which due date applies? How are credits treated? Do disputed balances stay in? Which snapshot sets the cutoff? Each choice changes the list a collections manager receives. Those choices belong to the metric owner, approved in writing, not inferred from a field name by an engineer during implementation.
Add a worked example with a handful of sanitized records, showing the expected result and why each record is in or out. Examples expose ambiguity that prose hides, and they become your first evaluation set.
Preserve legitimate differences instead of forcing one number
Finance may need a closed-period view while operations needs the latest state. Forcing one definition on both creates a number neither team trusts. Name each view clearly, and design the assistant to ask which one the user means when the distinction matters. A system that silently picks the convenient interpretation produces answers that are consistently wrong for the decision at hand.
Record the owner and effective date of every definition. When policy changes, reviewers need to know whether history uses the old or new treatment, or a methodology change will look like a performance change. In banking, that confusion tends to surface in front of the audit committee, which is the worst possible place to find it. Include at least one such transition in your evaluation.
This is why a governed semantic layer matters for enterprise AI. Whether you build one or buy one, revenue has to mean the same thing in the board deck, the close package and the answer an assistant gives a regional sales leader at nine at night.
Turn agreement into evaluation evidence
Before the workshop ends, select several questions that use the definition differently: a routine calculation, a period comparison, an exception and a deliberately ambiguous request. Have the business owner approve the expected behavior, including when the assistant should ask a clarifying question or decline to calculate.
Capture the words people actually use. Approved aliases keep questions natural without blurring similar measures. Then give the definition, worked example and approved questions to both the implementation team and the reviewers, with a clear route for proposing changes and rerunning the evaluation before anyone relies on new behavior.
Leave the workshop with an approved definition, a worked example and an owner who can resolve questions about it. Where several entities use different rules, preserve those distinctions explicitly. Share the example with the people building and reviewing the assistant, then have them calculate the result independently. That small check catches misunderstandings while the finance team can still explain the intended treatment.