How to Define a System of Record Across ERP, CRM, and E-Commerce

When the CRM, ERP, e-commerce platform, and warehouse all contain a customer or product record, teams often ask which system is “the source of truth.” The useful answer is rarely one system for the whole object.

Authority should be defined by business attribute and lifecycle state. The CRM may own lead qualification, the ERP credit status and invoice balance, and the commerce platform the customer's active storefront session. Integration should distribute authoritative changes without letting every copy overwrite every other copy.

Begin With Business Objects

List shared objects such as customer, contact, product, price, inventory position, order, shipment, invoice, payment, supplier, and employee.

For each object, map:

• Business identifier and technical identifiers.
• Lifecycle states.
• Fields created and changed in each system.
• Teams accountable for accuracy.
• Consumers and required freshness.
• Privacy, security, and retention classification.

Do not begin with a giant field-export spreadsheet. First understand why the record exists and how it changes.

Assign Authority at Field Level

Create an authority matrix. For every important attribute, name:

• Authoritative system.
• Business owner.
• Allowed creators and editors.
• Validation rules.
• Systems receiving a copy.
• Direction and latency.
• Conflict and exception rule.

For example, the CRM may own sales territory, the ERP legal billing name, the identity platform login email, and the customer self-service profile communication preference.

One field should not have two uncontrolled writers.

Separate Identity from Attributes

Systems use different keys. Establish a durable enterprise identifier or controlled cross-reference rather than matching indefinitely on name, email, or phone.

Define duplicate detection, merge approval, survivorship, and unmerge. Preserve source identifiers for traceability. A merge is a business event with downstream consequences, not only a database cleanup.

Model Lifecycle Ownership

Authority can change by state.

A quote may begin in CRM, become an order in e-commerce or ERP, and later produce shipment and invoice records. Rather than forcing one mutable object through every system, define commands and events:

• Quote accepted.
• Order created.
• Payment authorised.
• Fulfilment allocated.
• Shipment dispatched.
• Invoice posted.

Each domain owns its state and publishes facts others need.

Choose a Conflict Policy

“Last write wins” is simple and often wrong. Clock differences and delayed messages can cause an older or lower-authority value to overwrite the correct one.

Use policies such as:

• Authoritative source always wins.
• Reject non-authoritative changes.
• Route material conflicts to a steward.
• Merge only explicitly compatible attributes.
• Apply an effective date or version.

Record the rejected value, source, time, reason, and resolution.

Design Synchronisation

Use an API for immediate queries or commands, events for state changes, and batch pipelines for large consolidation or reconciliation. Include source ID, enterprise ID, event ID, version, and timestamp.

Make consumers idempotent. A duplicated customer-update event should not create a second customer. Use sequence or version controls where ordering matters.

Reconcile the Copies

Reliable delivery does not guarantee correct business state. Run scheduled reconciliation for critical objects:

• Missing identifiers.
• Orphaned references.
• Different authoritative values.
• Records stuck in a lifecycle state.
• Unexpected duplicate counts.
• Totals that do not balance.

Give every exception an owner and resolution path.

Govern Change

When a new application or field is introduced, update the authority matrix and data contract before connecting it. Review ownership when processes, regulations, products, or teams change.

Track metrics such as duplicate rate, unowned fields, reconciliation exceptions, correction time, and percentage of changes originating from the authorised source.

What a Good Result Looks Like

Employees do not need to debate which screen is correct. Systems can explain where an attribute came from, who owns it, when it changed, and how conflicts are resolved.

DualByte's system integration service can help map ownership, identifiers, data contracts, events, and reconciliation across business platforms.

Sources

• AWS: Enterprise Applications and System-of-Record Integration
• Microsoft Purview: Master Data Management Architecture