CRM and ERP Integration: Data Ownership, Sync and Failure Recovery
On this page
CRM and ERP integration is useful when both systems support their teams, but staff still copy orders, customer details or payment updates between them. The first decision is which system may change each field. The next is how people detect and resolve an exchange that did not finish.
Start with one business outcome: an accepted CRM order appears once in ERP, its progress returns to CRM, and an unresolved exchange has a visible owner. If the underlying workflow is already broken inside either application, a connection alone will not repair it. Use the build, configure or connect guide to decide where the change belongs.
Agree ownership at field level
For a proposed order workflow, the division might be:
- CRM: customer contact details, sales assignment and accepted order quantity before the agreed handoff.
- ERP: stock allocation, dispatch status and the fulfilment reference.
- Accounting: posted invoice and payment status, whether accounting is inside ERP or a separate product.
Record the shared customer and order identifiers, allowed transitions and the moment when an amendment needs approval. Do not let both systems update the same quantity simply because both expose an editable field. A correction after dispatch may require a return or adjustment, rather than overwriting the original order.
Assign one authoritative system to each field, even when data flows both ways. For example, ERP reports dispatch status to CRM; CRM displays that status but cannot create or amend the dispatch record.
Choose the exchange method around the source API
Proposed system boundary. The event table below tests only the small receiver model; it does not implement these connected services.
- CRM · accepted order
Owns the agreed customer fields and order quantity before handoff. Sends a stable event ID, order ID and source version.
Accepted snapshot → - Integration receiver · validate and record
Checks the authenticated caller, permitted fields, event identity and version. A deployed receiver needs a coordinated durable write for the order change and receipt.
Accepted change → - ERP · operational order
Owns stock allocation and dispatch. A received order is not proof that stock is reserved, goods are shipped or payment is received.
- ERP → CRM: fulfilment status
- Returns the operational reference and status. CRM displays the outcome; it does not rewrite the dispatch record.
- Unresolved exchange → assigned operator
- Conflicting data or an exhausted retry enters a visible exception process. Repair or replay requires an authorised decision.
- Accounting → agreed payment view
- Posted payments keep their accounting owner. Reconciliation compares orders, shipments and payments at the same stated cut-off.
Webhooks can notify a receiver of changes; polling can retrieve changes on a schedule. The choice depends on the actual API, available history, rate limits and acceptable delay. Define freshness as a business requirement, then test whether the chosen interface can meet it.
Plan for the delivery behaviour documented by each API. Stripe, for example, documents duplicate webhook delivery and no guarantee of event ordering. Check the CRM and ERP interfaces for equivalent retry and ordering rules.
Separate a complete record snapshot from an incremental action. A newer snapshot can replace older state under a version rule. An action such as “ship four units” cannot simply be skipped because a later event arrived first; it needs its own processing and reconciliation rules.
Follow one order through eight message deliveries
The example below runs a small, deterministic in-memory model on fictional order ORD-1042. CRM owns the quantity. Each event carries a stable ID and a complete snapshot with a source-controlled version. Quantity must be a positive integer; cancellation is a separate workflow outside this model.
The receiver remembers an event's payload. The same ID and payload cause no second change. Reusing an ID with different data creates a conflict. Older versions are ignored; the same version with a different quantity also creates a conflict.
Scroll the table horizontally to compare all columns.
| Input event | Expected result | Computed result | Stored order: version / quantity / count |
|---|---|---|---|
| Create; response is loste1 · CRM · v1 · 4 | Applied; acknowledgement lost | Applied; acknowledgement lost | v1 / 4 / 1 |
| Retry the same evente1 · CRM · v1 · 4 | Duplicate; no second change | Duplicate; no second change | v1 / 4 / 1 |
| Receive a newer snapshote3 · CRM · v3 · 6 | Applied | Applied | v3 / 6 / 1 |
| Receive an older snapshote2 · CRM · v2 · 5 | Older version ignored | Older version ignored | v3 / 6 / 1 |
| Same version, different quantitye4 · CRM · v3 · 9 | Conflict; review required | Conflict; review required | v3 / 6 / 1 |
| A non-owner attempts a changee5 · ERP · v4 · 9 | Rejected; no change | Rejected; no change | v3 / 6 / 1 |
| Quantity fails validatione6 · CRM · v4 · 0 | Rejected; no change | Rejected; no change | v3 / 6 / 1 |
| An event ID is reused with different datae1 · CRM · v4 · 8 | Conflict; review required | Conflict; review required | v3 / 6 / 1 |
Read the final column as stored version / quantity / number of orders. After all eight steps, the receiver has one order at version 3 with quantity 6. The table is computed from this model. Automated tests cover the sequence, repeated delivery, invalid inputs and conflicting IDs.
The lost acknowledgement is simulated after the first write. Retrying confirms the existing outcome instead of creating a second order. Version 3 contains a full snapshot, so version 2 arriving later cannot reduce its quantity.
What a production implementation still needs
This example has no network, persistent database, parallel workers, authentication or stock side effects. Its source label represents an already verified caller. A production receiver must authenticate the sender and enforce field permissions; trusting a source value in an incoming payload is insufficient.
The order update and processing receipt need a durable, coordinated write, with uniqueness and concurrency controls. Otherwise a crash between those writes can undo the protection demonstrated by the sequential model. If the change must also publish a message, a transactional outbox is one pattern for coordinating the database change with later delivery; consumers still need duplicate handling. See AWS guidance on the transactional outbox.
Specify receipt retention, replay windows, schema changes and recovery after a restart. Verify request signatures or the API's authentication mechanism, restrict credentials to the required operations and avoid copying sensitive customer payloads into routine logs. Test the actual connector before committing to a latency or delivery guarantee.
Give failed exchanges an owner and reconcile the records
A retry policy needs limits, delay and an escalation owner. A temporary outage may be retryable; a missing customer mapping or conflicting version needs a decision. An exception queue should show the business record, reason, last attempt and responsible team, with an authorised action to repair or replay it.
Reconciliation asks a different question from “was the request successful?” Compare source and destination order identifiers and versions at an agreed cutoff. Investigate missing records and incompatible states. Equal record counts alone do not establish that quantities, customers and financial references agree.
For our example, the proposed reconciliation record is: ORD-1042, source version 3, expected quantity 6, destination version 3, actual quantity 6. Record the cutoff and excluded pending events. A report of delayed exchanges should use those definitions; the reporting guide explains how to agree sources and measures.
Scope a pilot before a wider rollout
If an AI assistant will propose or trigger changes across these systems, add current permissions and approval checks to the integration boundary. The AI agents guide shows a task-creation example with revoked access, stale records and retries.
Choose one customer group or operating team and one complete exchange. Prepare API access, sample records, field ownership, maximum acceptable delay, exception owners and expected results for normal work, duplicate delivery, stale updates, outages and permission failures.
Budget the source-specific mapping, error handling, observability, reconciliation and support. Include historical migration only where it is needed, and plan how new changes are captured while history moves. Our modernization approach covers that transition; the data pipeline article provides related architectural context.
Share the systems, interfaces and one problematic handoff to discuss a CRM–ERP integration. We can help define the exchange and its acceptance checks before estimating the implementation.
Related project experience.
Global Business Assistant
Orders, inventory and multi-currency accounting in a connected ERP and CRM.
Explore