A sales dashboard says a customer bought $420,000 this quarter. Finance reports $390,000. The account manager’s spreadsheet shows $450,000. Before deciding which system is wrong, ask what each number means. One may count accepted orders, another recognized revenue and the third a forecast that includes unsigned work.
Agreement requires more than putting the numbers in the same database. The organization must decide which business fact it is discussing, who is authorized to establish it, when that fact applies and how corrections are communicated. Without those decisions, a central repository can become a more convenient place to disagree.
The strongest case for a single source of truth is therefore a case for explicit authority. Each consequential fact needs a trusted source and a governed interpretation. That arrangement can span several systems while still giving users a dependable answer to a precise question.
Terms such as customer, order, revenue and inventory appear universal until people use them. A customer may mean a legal entity, billing account, delivery location or corporate group. Inventory may include stock physically present, stock available to sell, goods owned but held elsewhere or items awaiting inspection.
Start with decisions that depend on those distinctions. A credit decision needs a particular view of legal and commercial exposure. A marketing campaign may need a group-level relationship. A warehouse picker needs an operational quantity in a particular location. Forcing all three into an undifferentiated master record can create errors rather than consistency.
Define the object, relevant attributes and business rules. Record which identities may be related without being merged. Include units, currencies, status meanings and time boundaries. A glossary becomes useful when it resolves a concrete decision or prevents an incorrect action; a long catalog of loosely agreed definitions has less value.
The UK government’s Data Quality Framework treats quality as fitness for a particular purpose and recognizes that different users can have different needs. That principle supports a precise formulation: a trusted source is trusted for a defined use, not automatically for every question the company might ask.
An application can own some attributes without owning the entire business object. A commercial system may establish an account’s sales relationship, while finance controls credit terms and an identity service controls employee access. The architecture must make those boundaries explicit.
For each important attribute, identify the system permitted to create or amend it, the business owner accountable for its correctness and the consumers that rely on it. Define the approval needed for changes and the treatment of conflicting updates. If two applications can independently change the same field, specify how the conflict is resolved before it occurs.
Ownership also requires service expectations. How quickly must a change become available downstream? What should users see if the feed is late? Who investigates a disagreement? A named owner without an operational response is an organizational label rather than a dependable service.
Avoid placing authority wherever the latest copy happens to be easiest to query. An analytical warehouse may be the best place to consume a combined view, but it may not be the proper place to originate operational changes. Distinguish the source of a fact, its transformed representation and the product through which a user sees it.
Many apparent contradictions are time differences. A payment arrived this morning, but a reporting extract was produced last night. A customer moved to a new group this month, while historical reporting uses the group membership that applied when the sale occurred. Both views can be legitimate if their time basis is clear.
At minimum, distinguish when an event happened from when a system learned about it. For consequential records, preserve the information needed to explain what was believed at the time of a decision and what was later corrected. The exact design depends on the use case; not every table requires a sophisticated temporal model.
Reports should state their refresh time and relevant cutoff. Users also need to know whether historical results can change after corrections. A restated figure should not quietly overwrite a prior published result when that distinction matters for accountability.
Define correction propagation deliberately. A changed product unit, account relationship or transaction status may affect downstream calculations. Decide which consumers must recompute, which must preserve an earlier approved view and how the difference is communicated.
Consider a fictional distributor with 1,000 units of a product physically present in its warehouse. Its warehouse screen shows 1,000, its sales screen shows 650 available and finance reports a different inventory value. Staff assume the systems are inconsistent.
A review finds that 200 units are reserved for accepted orders and 150 are in a quality hold. For this simplified example, the selling rule is physical stock minus valid reservations minus held stock. The sales figure of 650 is therefore correct for the stated definition. No duplicate or overlapping reservation and hold quantities are assumed.
Finance’s value is not expected to equal a quantity. It depends on the applicable valuation basis, ownership and accounting treatment. The team avoids treating “inventory” as one universal field and defines three related facts: physical quantity, sellable quantity and financial value.
The warehouse system owns physical movements. The order-management process owns reservations. Quality staff own release from inspection. Finance owns the valuation rules. A shared view calculates available-to-promise quantity using those governed inputs and displays the latest update time for each.
Now introduce a failure. The quality team releases 50 units, but the availability feed is delayed. The sales view still shows 650 while the current source facts would support 700. The problem is now identifiable as a freshness failure rather than a disagreement about definition. The view can display a delayed-update warning, and the responsible team can reconcile the missing release event.
Suppose instead that an order cancellation arrives after its replacement order. A naive update could release stock incorrectly. The integration needs to preserve the identity and applicable state of each reservation, reject invalid transitions and reconcile uncertain outcomes. Shared definitions must be supported by reliable change handling.
The company has not created one database that owns every fact. It has created an explainable chain from authoritative inputs to a decision-ready quantity. That is the practical value the single-source ambition should deliver.
Trust improves when users can investigate a result without reconstructing it from informal messages. Record where data originated, which transformations were applied and which version of the rules produced the output. The level of detail should reflect the consequence of an incorrect answer.
The World Wide Web Consortium’s 2013 PROV Overview describes provenance as information about the entities, activities and people involved in producing data, supporting assessments of quality and trustworthiness. An enterprise need not adopt the full PROV model to benefit from that idea. It should nevertheless preserve enough lineage to explain an important number.
For a management metric, keep the source datasets, calculation, exclusions, refresh schedule and accountable owner together. For an operational decision, also retain the relevant state and approval evidence. Traceability should help someone answer a question, not merely satisfy a metadata completion target.
When a metric changes, version its definition. A revised definition of an active customer can create apparent growth or decline without any underlying commercial change. Reporting should distinguish a definition change from a performance change, especially when incentives or external commitments depend on the result.
A compact working tool can cover one important domain at a time. For each fact, record:
This is a practical heuristic, not a complete data-governance standard. Start with a small set of facts that cause real operational friction. Prove that the map helps resolve an actual disagreement before extending it across hundreds of fields.
Pair the map with a quality contract. Define checks that matter for the consuming decision, such as uniqueness of an order identifier, permitted status transitions or reconciliation to an approved total. Set thresholds based on business consequences. A field can be populated and still be wrong for its purpose.
Give consumers a visible way to challenge a result. Challenges should become owned issues with evidence and resolution history. If the response to every disagreement is “the central system is correct,” people will recreate private sources they trust more.
There are good reasons to maintain several versions of information. Planning scenarios are intentionally different from actuals. Local operations may need faster provisional figures than finance can approve. Historical views may preserve the organization as it existed at a past date.
The objective is to label and govern those differences. A provisional forecast should not be mistaken for an approved commitment. A local metric should disclose how it differs from a group measure. Access controls should also prevent a broad shared view from exposing data to people who do not need it.
Centralization carries risks of its own. A central data service can become a bottleneck, a common point of failure or a source of slow decisions if every change requires distant approval. Federated ownership can work when domains have clear authority and reliable contracts between them. It fails when federation means nobody is accountable for cross-domain consistency.
A useful first milestone is modest: choose one recurring disagreement, define the facts involved, assign authority and demonstrate an answer that can be traced and corrected. Expand from there. The enterprise earns trust through dependable decisions, not through declaring that a single source has been established.
