Why Two Departments Get Different Numbers — and How a Single Source of Truth Ends the Argument

The Monday meeting problem

Consider a hypothetical Tulsa service company. Sales reports $420,000 of new business for the month. Finance reports $365,000 of revenue. Operations has a third figure. The meeting becomes an argument about whose spreadsheet is right, rather than a discussion about whether the company has enough capacity to deliver the work.

All three figures might be correct for different purposes. Sales may be counting signed contracts. Finance may be counting work invoiced this month. Operations may be counting completed jobs. The trouble begins when every report labels its result simply “Revenue.” A single source of truth is an agreed way to define, obtain, and calculate important business information so people can explain and reproduce the answer.

It is not a promise that every report will always show the same number. A useful reporting system can show booked sales, billed revenue, and cash collected side by side. The agreement is about meaning, not about hiding legitimate differences.

Begin with definitions

Pick one disputed measure and ask each department to describe it without referring to a spreadsheet cell. What event makes a sale count? Does the total include canceled orders? Are taxes included? Does a returned item reduce this month or the original sale month? These questions expose policy differences that software alone cannot settle.

A KPI, or key performance indicator, is a measure chosen to track progress toward a business goal. Its definition should identify the business event, calculation, reporting period, and owner. “Monthly revenue” is not enough. “Net posted invoice revenue, excluding sales tax, using invoice posting date” is much closer to a rule someone can implement and test.

Record legitimate alternatives rather than deleting them. A sales forecast and an accounting revenue report answer different questions. Give each a precise name. That small change can remove an argument even before any data systems change.

Check dates and timing

A transaction can have an order date, shipping date, invoice date, posting date, and payment date. A sale made on Friday may not appear in the accounting system until Monday. Two reports using different dates will disagree around every month-end, even if both use the same source.

Time zones also matter. A system may record a timestamp in UTC, the common global time reference, while a manager expects Oklahoma local time. UTC midnight is not local midnight. Define which time zone applies before grouping daily results. Also agree how to handle a financial period that closes several days after the calendar month ends.

Show a visible “data through” time on the dashboard. A refreshed sales view and yesterday's finance export should not be presented as though they were synchronized. If finance closes late, label preliminary and final numbers clearly. Accurate freshness labels are more useful than pretending every measure is current to the same minute.

Compare the underlying records

Once definitions and dates match, compare the transaction lists behind the totals. Use an identifier, meaning a value that distinguishes one invoice, order, or customer from another. A name alone is a weak identifier: “ABC Services” and “A.B.C. Services LLC” may be the same customer, while two people named James Smith may be different customers.

Look for records included on only one side. Then compare amounts for records present on both sides. This separates missing data from inconsistent calculation. A short reconciliation report, meaning a report that explains how two totals differ, can categorize the gap into late records, returns, duplicate rows, and unmatched customers.

Do not share unnecessary customer or employee details during this exercise. The people investigating revenue may need invoice identifiers and amounts without needing home addresses or medical information. A controlled sample often reveals the issue without distributing a full production export.

Find duplicates and accidental multiplication

Combining tables can inflate totals if the relationship is misunderstood. A join is the process of matching records from one table with related records in another. If one invoice matches three shipment records and the report repeats the full invoice value on each, revenue becomes three times too large.

This is different from a source system containing duplicate invoices. One problem is the calculation; the other is the stored records. Fixing the wrong layer may conceal the symptom while leaving the cause intact. Ask whether the total changes immediately after a particular combination step.

Agree on the grain, meaning what one row represents. An invoice row, invoice-line row, and shipment row are not interchangeable. Document that distinction next to the data. Before summing money, confirm whether amounts belong to the invoice or to individual lines.

Decide which source owns each fact

A company does not need one system to own everything. The accounting system may own posted invoice amounts, the customer relationship management system may own opportunities, and the dispatch system may own delivery completion. A CRM is software that tracks sales activity and customer relationships.

Create a simple source ownership list. For each important field, identify the system of record: the system treated as authoritative for that fact. Also identify who can correct it. If a branch code is wrong in dispatch, repeatedly patching it in a dashboard creates a hidden second version of the record.

Sometimes a correction cannot be made in the source immediately. Keep an approved correction table with a reason, owner, and effective dates. That is safer than changing an exported spreadsheet without a record of why. Temporary exceptions should be reviewed and removed when the source is fixed.

Make agreed rules reusable

Data engineering is the work of moving and preparing data reliably for use. It can apply the same customer matching, date rules, and revenue definitions before reports are built. A data warehouse is an organized reporting store that brings business records together and preserves useful history. It can help, but the warehouse is not itself the agreement.

A semantic model is a shared set of reporting tables and calculations. In Power BI, a shared model can support several departmental reports without rewriting the revenue calculation in each. Tableau can also use shared data sources. The aim is to let departments create relevant views while keeping core definitions controlled.

Write tests for the rules people care about. A canceled order should not count as booked revenue if the agreed policy excludes it. A returned item should reduce the correct period. A known invoice should match the accounting amount. Tests turn a definition from a document into an observable behavior.

Give the agreement an owner

Someone must decide when the rule changes. If finance changes revenue recognition policy, the data team should not silently leave old calculations in place. Keep a short change record showing the old rule, new rule, reason, approval, and date.

Separate data problems from business disagreements. A broken refresh is a technical incident. A dispute over whether intercompany sales belong in a management KPI is a policy question. Routing each issue to the right owner reduces time wasted in meetings.

Schedule a limited review after the first shared report goes live. Ask users to bring specific examples that seem wrong, not general claims that “the numbers are off.” Trace those examples together. Trust grows when someone can explain an exception, not when a dashboard designer insists the report must be correct.

Start with one disputed number

You do not have to replace every spreadsheet at once. Choose one measure with visible business consequences, such as net revenue or overdue receivables. Match definitions, reconcile one period, approve the rules, and automate that result. Keep the old calculation briefly for comparison, then retire it when the new one has an accountable owner.

For Oklahoma organizations, data analytics support can connect measures to decisions, while data engineering support makes preparation repeatable. The Tulsa service page explains our local coverage. Bring the two conflicting reports, one sample period, and the people who own their definitions. The first useful deliverable is an explained difference, not another chart with an unexplained total.