When finance and sales define revenue differently

In this article

• The recurring finance versus sales revenue disagreement
• Why forcing one definition often fails
• Multiple named definitions coexisting
• Definition provenance and ownership
• Which definition a given answer actually used
• Arbitration: when a single number is genuinely required
• What this looks like without a knowledge graph
• Where SIGNLD fits
• FAQ

The recurring finance versus sales revenue disagreement

"Revenue" is one of the most commonly redefined words in a mid-market company. Finance typically means recognized revenue: amounts booked according to accounting rules, often spread across the periods a service is actually delivered, regardless of when a deal was signed. Sales typically means booked or closed-won revenue: the value of a contract at the moment it was signed, whether or not any of it has been delivered or invoiced yet.

For the wider context, see our knowledge graph glossary of 40 terms.

Both definitions are legitimate. Finance needs recognized revenue because it is what goes on financial statements and what auditors check. Sales needs booked revenue because commissions, quota attainment, and pipeline forecasting are all built around the moment a deal closes, not the moment revenue is recognized months later. Neither team is wrong, and neither can simply adopt the other's definition without breaking something they actually depend on.

The friction shows up whenever the two numbers get compared without context: a board deck showing "revenue" from sales looks nothing like the "revenue" line in the finance package for the same quarter, and the mismatch gets read as an error rather than what it actually is, two correct answers to two different questions sharing one label.

Why forcing one definition often fails

The instinctive fix is governance: pick one definition, declare it official, and require everyone to use it. This works when the disagreement is actually a data quality problem, two teams calculating the same underlying concept slightly differently due to bugs or inconsistent logic. It does not work when the disagreement is structural, as with finance and sales revenue, because the two teams are not sloppily calculating the same thing, they are correctly calculating two different things that both need to keep existing.

Forcing a single official definition in a structural conflict like this produces one of two outcomes, both bad. Either the losing team keeps their own version anyway, off the books, in a spreadsheet nobody else can see, which recreates the original disagreement invisibly. Or the losing team adopts the mandated definition and loses the metric they actually needed to run their own function, which is a worse outcome than the disagreement was.

Multiple named definitions coexisting

The more durable approach is to stop trying to force one winner and instead give each definition its own name, its own explicit formula, and its own owner, stored as separate objects rather than as competing claims on one shared label. Instead of one ambiguous "Revenue" metric, a system can hold "Recognized Revenue (Finance)" and "Booked Revenue (Sales)" as two clearly labeled, independently defined metrics that both exist permanently.

This is not the same as giving up on consistency. Each named definition still has exactly one formula, one owner, and one authoritative source, so within its own scope it is fully governed. What changes is the assumption that there can only be one metric called "revenue" in the entire company. There can be several, as long as each is unambiguously named and nobody has to guess which one a report is using. A knowledge graph is well suited to this because metric definitions can be modeled as their own entities, each with defined properties, owners, and relationships to the source systems and calculations behind it, rather than as unlabeled numbers buried inside individual reports.

Definition provenance and ownership

Every named definition needs a recorded owner and a recorded origin, which together make up its provenance: who defined this metric, when, based on what source data and what formula, and who has authority to change it. Without recorded provenance, definitions drift silently, someone tweaks a formula in a shared spreadsheet, nobody notices, and six months later two reports that both claim to use the same definition are quietly producing different numbers because one of them was built before the tweak and one after.

Ownership does not need to sit with a dedicated governance function to work. For most mid-market companies, the practical pattern is that whoever depends on a metric for their own function owns its definition: finance owns recognized revenue, sales owns booked revenue, and each owner is the one who approves changes to their own definition. This distributes governance to the people who actually notice when a definition stops matching reality, rather than centralizing it with a team that has to be told about every edge case secondhand.

Which definition a given answer actually used

The most practical payoff of naming definitions explicitly is that any answer generated from the graph can cite which definition it used, not just which number it produced. A question like "what was our revenue last quarter" is genuinely ambiguous on its own, but an answer that states it used Recognized Revenue (Finance), owned by the controller, calculated from invoiced amounts recognized in the period, is not ambiguous at all, even though the underlying question was.

This citation is what prevents the classic failure mode of two people in the same meeting quoting different revenue figures with equal confidence, unaware they are answering different questions. If both numbers are traceable to a named, owned definition, the disagreement resolves in seconds: one is booked, one is recognized, and the meeting can proceed with both understood rather than one assumed to be wrong.

Arbitration: when a single number is genuinely required

Some situations do require exactly one number: a board needs one revenue figure for the headline slide, an external filing needs one number that satisfies auditors. This is where arbitration comes in, and it is a different problem from ongoing definition management. Arbitration is a one-time (or recurring, but deliberate) decision about which named definition applies for a specific external purpose, made by whoever has the authority to make that call, usually the CFO for anything touching financial statements.

The important distinction is that arbitration does not delete or override the other definitions, it selects one of them for a specific use and records that choice. Sales still has booked revenue for running their own function the next day. What changes is that, for this one board slide or this one filing, everyone agrees which named definition is the authoritative one, and that agreement is itself recorded rather than assumed.

What this looks like without a knowledge graph

Without a shared structure to hold multiple named definitions, the default state in most companies is a set of disconnected spreadsheets and BI dashboards, each built by a different team, each silently encoding its own definition of shared terms like revenue, active customer, or churn, with no record of whose definition is whose. Reconciling two reports means someone manually tracing formulas backward through spreadsheet cells to figure out what was actually being calculated, a process that is slow, error-prone, and has to be repeated every time the same disagreement resurfaces.

A knowledge graph does not eliminate the underlying disagreement, finance and sales will keep needing different revenue concepts for good reasons, but it removes the guesswork by making every definition an explicit, named, owned object that any answer can point back to, rather than an assumption baked invisibly into a formula.

Comparison: one forced definition vs. shadow spreadsheets vs. named coexisting definitions

Aspect	One forced official definition	Shadow spreadsheets (unofficial)	Named, owned coexisting definitions
Resolves structural disagreements (finance vs. sales)	No, suppresses one team's real need	No, recreates the conflict invisibly	Yes, both definitions remain valid and visible
Traceable to an owner	Yes, for the one definition kept	No, ownership is informal or unknown	Yes, each definition has a recorded owner
Answers cite which definition they used	Only one exists to cite	Rarely, unofficial numbers are unlabeled	Yes, by design
Supports a single authoritative number when required	Yes, but only one exists	No	Yes, through deliberate arbitration
Risk of silent drift	Low for the kept definition	High	Low, changes are tied to a named object

Where SIGNLD fits

SIGNLD's knowledge graph can hold multiple named metric definitions side by side rather than collapsing them into one assumed answer, and a Decision Brief states which definition it used alongside the finding, the evidence linked back to source records, a confidence score, and a recommended action. Because SIGNLD connects to systems read-only across 800+ integrations, including spreadsheets as first-class sources, it can surface where finance's and sales' revenue definitions actually diverge in the connected data rather than requiring that gap to be resolved before any question can be answered. More on the mechanism is at how it works, and related terms are covered in the knowledge graph glossary.

Related reading in this series: How a knowledge graph stores your business rules and How a knowledge graph supports audit and lineage.

Key takeaways

• \"Revenue\" is one of the most commonly redefined words in a mid-market company.
• The more durable approach is to stop trying to force one winner and instead give each definition its own name, its own explicit formula, and its own owner, stored as separate objects rather than as competing claims on one shared label.
• Some situations do require exactly one number: a board needs one revenue figure for the headline slide, an external filing needs one number that satisfies auditors.
• Whoever has authority over the external-facing number, typically the CFO for anything touching financial statements.
• The named definition's owner approves the change, and the update applies going forward from a recorded date.

FAQ

Isn't having two definitions of revenue just bad governance?

Not when the two definitions serve genuinely different, legitimate purposes, as with recognized versus booked revenue. Bad governance is when the two definitions exist without anyone knowing they differ. Good governance is naming both, owning both, and making clear which one any given report uses.

Who should decide which definition is used in a board deck?

Whoever has authority over the external-facing number, typically the CFO for anything touching financial statements. That decision is a one-time or recurring arbitration for a specific purpose, and it does not require deleting the other definition that other teams still need.

How does a knowledge graph prevent two teams from silently drifting apart?

By storing each definition as a named object with a recorded owner and formula, so a change to one definition is a visible edit to that object rather than an informal edit to a formula buried in a spreadsheet nobody else sees.

Does this apply to metrics other than revenue?

Yes. Active customer, churn, qualified lead, and margin are common examples where two functions legitimately need different definitions. The same pattern, naming and owning each version rather than forcing one, applies to any metric multiple teams depend on differently.

What happens when a definition needs to change?

The named definition's owner approves the change, and the update applies going forward from a recorded date. Past answers that cited the old definition remain traceable to what that definition was at the time, rather than silently inheriting the new formula.

Try SIGNLD free to see how your own metric definitions get named and traced, or see how it works.