A system of record is the designated authority for a defined business fact at a defined point in its lifecycle. It is the place where an authorized change becomes official and where history, correction and evidence are governed. The phrase does not mean one database must contain every copy, that all reporting must query it directly, or that an application is authoritative for every field it displays.
These system of record basics help operations teams settle practical questions before integration or reporting. Continue with Edilec's system-of-record planning guide, record ownership guide and ERP, CRM and workflow integration guide when implementing the decisions across systems.
Key takeaways
- Define authority for a specific fact and lifecycle state, not an entire application by habit.
- Use durable business identifiers and explicit matching rules across local system keys.
- Control creation, change, correction, merge and retirement as distinct operations.
- Publish downstream contracts for freshness, history, deletion and conflict handling.
- Measure unresolved duplicates, stale consumers, unauthorized writes and reconciliation gaps.
What a system of record is and is not
Authority combines semantic, procedural and technical decisions. Semantic authority defines what a fact means. Procedural authority identifies who may approve a change. Technical authority identifies where the accepted state is committed and versioned. A CRM may be authoritative for a lead stage, an ERP for a financial posting, a human resources system for employment status and an identity service for authentication credentials. No single label resolves these boundaries.
A warehouse, search index, cache or dashboard can be a trusted source for a particular read decision without being the system of record for the underlying transaction. Derived systems should retain provenance, refresh time and transformation version. A workflow engine may be authoritative for approval history while the approved master attribute is stored elsewhere. State these roles separately: source of entry, record, reference, analysis and evidence.
| Role | Purpose | May accept changes? | Example evidence |
|---|---|---|---|
| System of entry | Capture proposed information | Yes, before validation | Submission and identity |
| System of record | Commit authoritative state | Only through governed path | Revision and audit history |
| System of reference | Serve optimized shared reads | Normally no | Source revision and freshness |
| Analytical store | Support trends and models | No operational correction | Lineage and transformation |
| Evidence archive | Preserve required record | Append or controlled disposition | Retention and integrity proof |
Define authority by fact and lifecycle
Create a record authority matrix. For each fact, document definition, entity, lifecycle states, authoritative store, permitted writers, validation, effective and recorded time, revision, correction, retention and consumers. Distinguish proposed, approved, active, suspended and historical values. An order quote can originate in CRM, become an order in ERP and receive fulfillment state from an operations system without any system owning the whole lifecycle.
Include legal and records-management obligations where they apply. The U.S. National Archives' Universal ERM Requirements organize electronic records needs across capture, maintenance, disposal, transfer, metadata and reporting. Most companies will follow different laws, but the lifecycle perspective is useful: an operational record remains governed after its active business state ends.
Choose durable identifiers and matching rules
Issue a stable identifier for each governed entity and do not infer identity from a mutable name, email or address. Keep local system keys as aliases. Define uniqueness, merge, split and reuse rules. Matching may use deterministic keys, probabilistic candidates or human stewardship, but uncertain matches should not silently combine records. Preserve redirect and lineage history when identifiers are consolidated.
The official GS1 System Architecture illustrates how identification keys connect master data, transactions and visibility events. The same principle applies beyond supply chains: durable identifiers let business documents refer to an entity while descriptive attributes evolve. Choose identifier governance before exchanging records between teams.
Control creation, update and correction
Expose intentional commands rather than unrestricted field updates. “Change billing address,” “approve supplier” and “close account” have different authorization, validation and effects. Check current state and revision to prevent lost updates. Require reason and approval for sensitive correction. Keep recorded time separate from effective business time, especially when entering a late correction. Preserve original postings and use adjusting entries where auditability matters.
Protect integrity against mistakes and destructive events. NIST's data integrity guidance emphasizes knowing and protecting enterprise assets from corruption, modification and destruction. Apply least privilege, immutable or append-oriented evidence where appropriate, backups, restore tests, change monitoring and independent reconciliation. Integrity is not just preventing attackers; a faulty integration can be equally destructive.
| Operation | Required decision | Control | Evidence |
|---|---|---|---|
| Create | Is this a new entity? | Uniqueness and identity checks | Creator and source |
| Update | Is this writer authoritative? | Authorization and revision check | Before/after and actor |
| Correct | Was prior state inaccurate? | Reason and approval | Correction lineage |
| Merge | Are records the same entity? | Steward review and alias preservation | Surviving identity map |
| Retire | May active use stop? | Dependency and retention review | Effective date and disposition |
Distribute authoritative facts with explicit contracts
Consumers need definition, schema, identifier, version, freshness promise, deletion behavior and correction semantics. Use APIs for current reads, events for change notification and extracts for bounded analytical transfer according to the decision. OData JSON is one formal representation for structured requests and responses; CloudEvents provides a common event envelope. Neither standard decides your business authority.
Make consumers idempotent and compatible with delayed or repeated events. Include source revision and occurred time. Do not let a downstream application write transformed values back into the authoritative record without an approved command. Track consumers so schema, retention and ownership changes can be coordinated. Use deprecation windows and contract tests rather than indefinite duplicate fields.
Reconcile copies and resolve conflicts
Reconciliation compares important facts across systems against the authority matrix. Measure missing entities, stale revisions, conflicting values, unmatched identifiers and unauthorized writers. Prioritize by consequence, not count alone. Preserve the discrepancy before repair and record which rule selected the correct state. Do not use latest timestamp as a universal winner when clocks, delayed imports and backdated effective changes exist.
Give operations a correction queue with entity context, source evidence, permitted actions, deadline and escalation. Resolve root causes such as ambiguous definitions, missing workflow state, weak identifiers or an undocumented writer. Review recurring conflicts as governance defects. A daily sync that repeatedly overwrites the same disagreement is not reconciliation.
Operate record authority as a service
Name a business data owner, technical service owner and stewards for quality and correction. Publish definitions, service levels and change process. Monitor availability, write failures, freshness, duplicate candidates, correction age, consumer lag and restore evidence. Review access and privileged changes. The National Archives' records management policy resources show the breadth of governance that formal records may require; tailor controls to applicable obligations.
Plan migration by preserving identifiers, history, provenance and consumer contracts. Run source and target in a controlled overlap, reconcile authoritative states and freeze ambiguous writes. The new product does not become the system of record merely because data was copied into it. Authority changes only after acceptance, cutover, communication and retirement of the former write path.
Define quality as part of the authority contract
For each critical fact, specify quality conditions that the write path can enforce and the business can interpret. These may include required provenance, valid domain, uniqueness, temporal order, approval or a reconciliation relationship. Distinguish a rejected proposal from an accepted record later found to be inaccurate. The former should return a clear validation response; the latter needs a governed correction that preserves prior state and downstream impact.
Measure quality by consequence and lifecycle. A missing phone number may be harmless for one process and block emergency contact in another. Monitor invalid writes, duplicate candidates, stale authoritative state, unresolved corrections and consumer disagreements by business use. Publish definitions and denominator with each measure. Avoid a single completeness score that rewards filling optional fields while concealing an unreliable identifier or financial status.
Consumers should report suspected defects through a stable route that includes entity, fact, observed value, expected evidence and urgency. They should not repair their copy and continue silently. The data steward investigates source and authority, coordinates correction and identifies affected consumers. For widely distributed facts, publish a correction event or new revision and verify that high-consequence consumers applied it.
Review quality rules whenever policy, product or regulation changes. A field that was optional may become required; a valid code set may be retired; a matching rule may disadvantage a group of customers. Test changes against historical and edge cases, version the rule and communicate effective dates. Quality governance protects meaning over time rather than forcing today's format onto every historical record.
System of record decision checklist
- Each critical fact and lifecycle state has one declared authority.
- Durable identifiers, aliases, matching, merge and split rules are documented.
- Create, update, correct, merge and retire operations have distinct controls.
- Consumers receive version, freshness, correction and deletion contracts.
- Reconciliation preserves evidence and routes owned repair.
- Migration, retention, restore and authority transfer are tested.
Frequently asked questions
Is a system of record the same as a single source of truth?
Not necessarily. A system of record is authoritative for defined facts. A “single source of truth” often describes a trusted consumption view assembled from several authorities and should be documented more precisely.
Can a data warehouse be a system of record?
It can be authoritative for governed analytical outputs, but usually not for the originating transactions. State which facts it owns and how corrections flow.
Does immutability make a system authoritative?
No. Immutability preserves entries but does not prove identity, correctness, authority or legal meaning. Governance and validation still determine whether a record is official.
Conclusion
System of record basics are ultimately decision-right basics. Define exactly which facts become official where, who may change them, how history and identifiers survive, and what consumers can expect. With explicit lifecycle, correction and reconciliation, operations teams can build integrations and reports that preserve business meaning instead of creating competing copies of truth.