A practical checklist for Shopify, ERP, and PIM integration planning

Shopify launches fast; the integrations decide whether it lasts

Shopify gets a storefront live in weeks, and that speed is the reason teams buy it. But the storefront is the easy part. The moment Shopify has to agree with ERP on inventory, with a PIM on product data, and with an OMS on fulfillment, the program stops being a Shopify project and becomes an integration project. That shift is where most of the cost, and most of the post-launch firefighting, actually lives.

The failures are rarely dramatic. Inventory drifts a few units and the store oversells a flash sale. A refund clears in Shopify but never posts to ERP, so finance reconciles by hand for a month. A product publishes with the wrong price because two systems both think they own it. None of these are missing-API problems. They are ownership and timing problems, and they are cheaper to settle on a whiteboard than in production.

This checklist is the architecture pass we run before a Shopify build commits to its integrations.

The decisions to settle first

• Name the source of truth per object, not per system. Shopify, ERP, and a PIM will all hold products, prices, and inventory. Decide which one wins for each field (price, cost, stock, descriptions, media, tax class) and block the write paths that violate it. "ERP owns price and stock; PIM owns enrichment; Shopify owns nothing it didn't originate" is a clearer contract than "they sync."
• Decide where inventory is authoritative and how lag is allowed. Real-time stock sync is expensive and often unnecessary. Pick a model per channel (buffer thresholds, safety stock, scheduled pushes) and state the oversell tolerance explicitly rather than discovering it on a promotion day.
• Separate checkout success from order finalization. A captured Shopify order is a customer promise, not a completed transaction. Treat the handoff to ERP/OMS as its own flow with its own retries, so a downstream outage delays fulfillment without ever blocking the buy button.
• Map refunds, cancellations, and partial reversals end to end. These are where Shopify, the payment gateway, ERP, and finance disagree most. Trace each one to a posted financial record and name who reconciles a mismatch.
• Treat Shopify webhooks as at-least-once. orders/create, refunds/create, and inventory webhooks can fire twice, arrive late, or get missed during an outage. Every consumer needs an idempotency key and a backfill path; assuming exactly-once delivery is the single most common Shopify integration bug.
• Make Markets, multi-store, and marketplace feeds explicit. Multiple Shopify stores or Markets mean multiple price lists, tax rules, and identifier spaces. If a feed influences assortment or availability, it is part of the contract, not a side channel.

What teams skip, and pay for later

Most plans design the happy path and defer the operating model: who fixes a stuck order, who corrects bad product data, who decides retry versus manual repair. So the first catalog reload or sale spike becomes an incident instead of a routine event, and the answers get improvised under pressure. The connector usually works on day one. The question this checklist forces is whether the team can operate it on day thirty.

Prove the path with one thin slice

Don't build every mapping before you build confidence. Run one vertical slice end to end: one representative product and one real order, through PIM and ERP, with one transformation, one negative test, one retry, one alert, and one support action. This proves the delivery path and, more usefully, reveals whether the people you named as owners can actually make a call during a failure.

Then broaden deliberately:

1. Realistic exceptions — missing attributes, stale inventory, duplicate SKUs, delayed payment capture, ERP-rejected orders, partial refunds. On a Shopify stack these are normal weekly events, not edge cases.
2. Release and rollback — which syncs can pause, which webhooks can replay, which data must be reconciled, and what the storefront still does during a degraded ERP. A launch plan without recovery evidence is just a deployment schedule.

Keep evidence that ties checks to business outcomes

Contract tests prove the payload is shaped right; they do not prove the flow can be run. For each critical flow keep a small evidence pack: sample payloads, mapping decisions, an alert example, runbook steps, and the expected business status after both success and failure. Crucially, write down the ownership answers: if a product fails validation, who corrects it? If an order is accepted by the connector but rejected by ERP, who decides retry versus repair? If a refund completes in the gateway but never posts to finance, who owns reconciliation? Answering these once is far cheaper than rediscovering accountability mid-incident.

After launch, review against real data

Run a short weekly review through the first month: failure counts, time to recovery, stale records, manual interventions, and unresolved ownership questions. Chair it with the people who actually decide, the merchandising lead, the commerce owner, and whoever runs ERP operations. If the dashboard shows failures but nobody can name the business effect, the monitoring is too technical. If the team can name the effect but cannot trace it to a webhook, sync, or payload, the observability is too shallow.

Where this fits

This checklist is the input to an architecture pass, not a substitute for one. Our integration and architecture services turn these decisions into a sequenced route map and risk register, and you can start a conversation with the specifics of your Shopify, ERP, and PIM stack. For adjacent depth, see the commerce integration error patterns playbook and why commerce cloud integrations fail.