A Shopify ERP integration connects the storefront to an enterprise resource planning system so agreed records can move between them. A reliable implementation defines who owns each field, how updates are identified, and how missing or failed changes are found and repaired.
Start with those rules before choosing a connector. A standard connector can be the right answer when its supported flows fit the business. Custom work becomes relevant when the required behaviour, data model or operational controls fall outside that fit.
This guide is for the ecommerce or operations lead responsible for orders, inventory and cross-system handoffs. It includes a proposed acceptance framework, not a claim that every ERP behaves the same way. Download the integration test worksheet and adapt it with the people who own your systems.
Define ownership at the field level
“The ERP is the source of truth” is too broad to resolve every disagreement. A warehouse may know what has physically shipped, Shopify may own the customer’s submitted order, and the accounting system may own the financial posting. The architecture must explain how those facts connect.
For each record, identify its stable identifiers, field owner, permitted writers and sync direction. If two systems can change the same field, define how conflicts are detected and resolved. Avoid accepting whichever update arrives last without checking whether it represents the newest business state.
| Record | Ownership decision | Integration rule to document |
|---|---|---|
| Product and variant | Who owns identifiers and descriptions? | Map identifiers and specify which fields Shopify may edit |
| Inventory | Who calculates stock available to sell at each location? | Define quantities, reservations and update direction |
| Order | Who can edit an order after export? | Define the export condition and allowed downstream changes |
| Fulfilment | Which system confirms shipment and tracking? | Connect shipment updates to the correct order and items |
| Financial record | Who owns posting and reconciliation? | Map transaction references and route disagreements to finance |
Make the mapping readable to the people who investigate failures. A diagram that shows systems connected by arrows is incomplete until the arrows have a record, a direction and an owner.
Assign ownership before connecting systems. For every shared field, name the responsible system, permitted writers and the rule for resolving conflicting updates.
Compare Shopify ERP connectors before custom work
Compare three approaches against the same set of required journeys:
- A supported connector: useful when its standard data model and workflows cover the requirement. Verify the precise ERP version, supported objects, monitoring, limitations and support responsibilities.
- An integration platform: useful when you need transformations, several systems or managed orchestration. Evaluate who will maintain the flows and how failures and usage costs are exposed.
- A custom integration: useful when material requirements cannot be met safely by the other approaches. Include ongoing API maintenance, observability, testing and operational ownership in the scope.
Ask for a demonstration of the awkward cases in your business, not just a new order appearing in another system. Examples include an order edited after export, split fulfilment, a refunded item, a missing product mapping and a temporarily unavailable destination.
The decision is about coverage and ownership. A connector that meets the requirements with clear support can be preferable to a larger custom project. A connector that requires daily manual repair needs that operating cost included in the comparison.
Define the quantities in your Shopify inventory sync
Two systems can show different inventory numbers while describing different states. Shopify distinguishes on-hand, available, committed, unavailable and incoming inventory. In Shopify’s model, available inventory is sellable stock; incoming units are not automatically available to sell.
Map the quantity definition as well as the field name. Identify the location, reservation policy, adjustment owner and whether an integration writes an absolute quantity or a change. Check what happens to commitments when an order is created, edited, cancelled or fulfilled.
Use a controlled example with a known starting state. Create the relevant order or adjustment, inspect each system, then compare the result with the agreed rule. If a discrepancy appears, first identify whether it comes from timing, mapping, quantity definitions or a failed update. Increasing sync frequency does not fix an incorrect rule.
Compare the same quantity at the same location. A warehouse’s physical stock and Shopify’s available-to-sell quantity can differ for a valid reason. Agree the state and reservation rules before calling the difference a sync failure.
Design for duplicate, delayed and missing updates
Shopify webhooks notify integrations about subscribed events. They help trigger work but do not replace the need to verify the resulting records.
Shopify documents that deliveries can be duplicated. It recommends idempotent processing and duplicate detection: receiving a delivery again should not create another business effect. A delivery identifier helps detect repetition, while stable business identifiers help prevent duplicate downstream records across wider retry and recovery paths.
In practice, separate receipt of a valid event from completion of the downstream work. Retain enough state to see what was accepted, attempted, completed or rejected. Check the current Shopify guidance for authentication, delivery timing and retry behaviour when implementing the receiver.
Also define how the integration handles an older update arriving after a newer one. The appropriate control may involve record versions, timestamps or reading current state before applying a change. Choose it for the specific operation and API behaviour; do not assume arrival order is business order.
Finally, schedule reconciliation between the systems for the records and time windows that matter. Shopify’s delivery guidance describes reconciliation jobs as a way to recover changes that may have been missed. Your implementation still needs a rule for recognising a discrepancy and a safe repair path.
Give exceptions an owner and a recovery path
A log entry is useful to a developer but may not tell an operator that an order needs attention. Define an exception view with the affected record, reason, first occurrence, latest attempt and responsible team. Avoid exposing unnecessary customer information in logs or notifications.
Separate temporary failures from invalid data. A temporary service outage might justify a controlled retry. An unmapped item usually needs its mapping corrected before another attempt. Set escalation conditions based on the operational consequence and expected processing time.
After a repair, verify the business result as well as the job status. “Retry succeeded” should lead to the correct order, stock state or fulfilment record. Document how to prevent the repair from creating a second record or reversing a more recent valid change.
Test complete journeys before go-live
The worksheet includes proposed scenarios and acceptance conditions. Run applicable scenarios in an appropriate test environment, using known starting data and an agreed expected result.
| Scenario | Acceptance condition to agree |
|---|---|
| New eligible order | One corresponding downstream record with matching identifiers and agreed values |
| Duplicate delivery | No additional order or repeated inventory effect |
| Destination outage | Work remains recoverable; the owner can see and resolve the exception |
| Order edit after export | Each system reflects the permitted change or exposes a clear exception |
| Partial fulfilment | Correct items and quantities are shipped; the remainder stays in the agreed state |
| Missed update | Reconciliation identifies the discrepancy and the repair preserves valid newer changes |
Record the input, expected result, actual result and evidence for each test. Retain the implementation version and relevant configuration so the result can be reproduced. An untested scenario should remain untested in the release record, rather than being counted as a pass.
At cutover, name the person monitoring exceptions, the escalation path and the point at which routine support takes over. Re-run affected tests when a connector, API version or business rule changes.
Retain the result, not just a green status. A passed test has an input, an expected outcome, the observed records and reproducible evidence. An untested scenario stays untested.
Do we need a custom Shopify ERP integration?
Only if the required workflows or controls fall outside the supported options. Test a connector against your ERP version, record types, order edits, fulfilment and recovery needs first. Compare the ongoing support and repair effort as well as the initial implementation scope.
How often should Shopify and the ERP sync?
Set a freshness requirement for each flow based on its business consequence. Inventory availability may need different timing from financial reconciliation. Measure the actual delay and behaviour under load, then choose the update mechanism. Faster syncing does not correct a wrong quantity definition or field mapping.
What should happen when an integration fails?
The affected record should remain traceable, with a reason and an accountable owner. Retry temporary failures under a controlled policy; correct invalid mappings before retrying them. After recovery, verify that the intended record exists once and preserves valid newer changes. Keep reconciliation to find missed updates.
Can a public website scan verify our ERP integration?
No. A public scan cannot inspect private ERP records, internal mappings or the results of downstream jobs. Verification requires appropriate access to the connected systems, agreed test cases and evidence from the actual records. Keep those checks in the integration implementation scope.
Turn the map into an implementation scope
Bring the ownership map, required journeys, known exceptions and test results into the scoping conversation. They reveal whether the immediate work is configuration, data cleanup, integration code or an operating-process decision.
If you are also changing commerce platforms, include these handoffs in your Shopify migration plan. Historic account and invoice requirements deserve separate treatment from ongoing order synchronisation; our existing B2B invoice migration guide outlines that distinction.
Autonomous helps teams design and implement Shopify integrations and custom apps. The starting point is the systems and behaviours you need to connect. A public storefront scan cannot verify private ERP records or integration logic.
