Why ERP integration is the hard part of running a serious store
For a growing Swiss merchant, an ERP such as Abacus, Bexio or Microsoft Dynamics often holds key financial and operational records. The moment Shopify and the ERP both believe they own customers, products, prices, stock and orders, the systems can disagree about reality. Those disagreements may show up as an incorrect invoice, an oversold product or an order that never reaches the warehouse.
A Shopify ERP integration is not a connector you switch on. It is a contract between two systems about who decides what, what happens when one of them is unavailable, and how disagreements get reconciled. This article covers what each integration actually involves, the question that decides the whole architecture, what breaks in production, and how to scope the work honestly.
The system-of-record question decides everything
Before any code, answer one question for each kind of data: which system is the source of truth? This is the single decision that determines whether your integration is calm or chaotic.
- Products and prices — usually mastered in the ERP or a PIM, pushed to Shopify. The storefront should rarely be allowed to overwrite a price the ERP owns.
- Stock levels — almost always mastered in the ERP or WMS, with Shopify as a downstream mirror. Letting Shopify and the ERP both adjust stock independently is the fastest route to overselling.
- Orders — created in Shopify, pushed to the ERP for fulfilment and invoicing. The ERP becomes the source of truth for the order's financial state after that hand-off.
- Customers — this is where it gets genuinely hard, because both systems want to own the customer record. Decide deliberately, and accept that one side becomes a mirror.
Write this down as a table before scoping anything. We cover why this matters in painful detail in what breaks in a Shopify ERP integration.
What each integration actually involves
Abacus
Abacus is used by established Swiss merchants for finance and operational processes. The available integration route depends on the installed products, enabled interface and existing Abacus partner setup. Scope the mapping from Shopify orders, tax details and refunds to the finance-approved accounting fields, and check whether the business process expects immediate events, scheduled exchange or both.
Bexio
Bexio is a cloud business platform used by Swiss SMEs. Confirm the current API permissions, required objects and limits for the account and workflow before estimating a direct connection. A narrow contact, order or invoice flow may be a small scope; B2B pricing, warehouse rules and financial recovery can add complexity. Retries, duplicate protection and reconciliation still need an explicit owner.
Microsoft Dynamics
"Dynamics" can mean Business Central or Finance & Operations, with different data models, environments and integration approaches. Confirm the product, version, extensions, approved interface and environment access first. Complexity is organisational as much as technical: entity mappings, deployment approvals and finance or operations ownership are part of the scope.
| System | Typical fit | Confirm before estimating | Where it gets hard |
|---|---|---|---|
| Abacus | Established Swiss merchants | Installed products, enabled interface, partner setup | Accounting model mapping, scheduled vs event flows |
| Bexio | Swiss SMEs | Account permissions, required objects, current limits | B2B or warehouse rules, duplicate and failure handling |
| Dynamics | Enterprise / larger orgs | Business Central vs Finance & Operations, extensions and environments | Deep entity mappings, governance, deployment approvals |
Odoo and SAP: assess the deployed system first
Odoo and SAP cover a wide range of editions, modules, hosting models and existing customizations. The product name is not enough to promise a connector or estimate effort. Confirm the exact version and modules, available API or middleware access, existing extensions, and which team owns credentials and change approvals. Then compare a supported connector or middleware route against a custom bridge using the same data-flow and failure requirements. This article does not imply a ready-made Forgify connector for every Odoo or SAP deployment.
Map the flows before choosing a connector
List the entities and the direction of travel before comparing tools. Typical decisions include:
| Entity | Common direction | Decisions to settle |
|---|---|---|
| Products and variants | ERP/PIM → Shopify | SKU identity, option mapping, drafts, bundles and product ownership |
| Prices | ERP → Shopify | Currency, customer-specific pricing, promotions and who may edit prices |
| Stock | ERP/WMS → Shopify | Location mapping, reservations, safety stock and acceptable update delay |
| Orders and changes | Shopify → ERP | Paid/unpaid state, edits, cancellations, refunds and duplicate protection |
| Customers and companies | Often both, with one master per field | Matching keys, consent, company accounts and conflict handling |
| Invoices and credit notes | ERP → Shopify or customer communications | Trigger, tax/accounting mapping, numbering, refunds and reissue rules |
| Fulfilment and tracking | ERP/WMS/3PL → Shopify | Partial fulfilments, split shipments and tracking updates |
The correct direction depends on the merchant's operating model. It should be documented for fields, not just whole records: an ERP might own a product's SKU and price while Shopify owns its merchandising copy. If Shopify Plus B2B is in scope, include company and location relationships, customer-specific pricing and the ERP's matching account identifiers in the mapping review.
What breaks in production
Every ERP integration works in the demo. The cost lives in the failures, and they are predictable:
- Stock sync drift. Shopify and the ERP slowly disagree about quantities because an update was dropped, retried twice, or applied out of order. The symptom is overselling or phantom out-of-stocks.
- Duplicate orders or invoices. A webhook is delivered more than once (Shopify guarantees at-least-once, not exactly-once), and without idempotency you create the same invoice twice.
- Price desync. A price changes in the ERP but the push fails silently, so the storefront sells at the old price — or worse, a storefront edit overwrites the ERP's price.
- Lost orders. The ERP is down for maintenance, the webhook fires, nothing catches the failure, and the order is simply gone from the ERP's view until a customer complains.
- Out-of-order events. An "order updated" arrives before "order created" because they took different network paths. Naive handlers crash or corrupt state.
- Invoice and refund mismatch. An order is invoiced twice, a refund is not represented as a credit note, or an invoice is created before the business considers the order financially ready.
- Customer duplication. Different identifiers or email changes create multiple contacts, which then split debtor history and support context.
None of these are exotic. They are the normal weather of distributed systems, and an integration that doesn't plan for them is not finished — it is just untested.
The patterns that make it reliable
The controls depend on each ERP interface and the flow's timing and failure cost. Common options include:
- Webhooks + asynchronous work for event-driven flows. When an event needs fast acknowledgement but the ERP may be slow, verify the webhook, accept it quickly and hand work to a durable queue. A scheduled import/export may be a better fit for slower data. The mechanics are explained in Shopify GraphQL, webhooks and dashboards explained.
- Idempotency everywhere. Every operation that writes to the ERP must be safe to run twice. Use the Shopify order ID or a derived idempotency key so a re-delivered webhook updates rather than duplicates.
- Retries with backoff. Transient failures — the ERP is busy, a rate limit hit — should retry automatically with exponential backoff and a dead-letter queue for the ones that keep failing.
- Reconciliation. Even with all of the above, drift happens. A scheduled reconciliation job that compares Shopify and the ERP and flags or fixes mismatches is the difference between catching a problem in hours versus discovering it at month-end close.
- Observability. If a sync fails, someone gets paged. Silent failure is the worst failure, because it compounds.
Building this well is closer to a custom Shopify app than to flipping on a connector, which is why honest scoping matters more here than almost anywhere else.
It does not always require custom code. Prefer an existing connector when it supports the required objects, direction rules, error visibility and recovery process. Middleware can be appropriate when several systems share transformations or monitoring. A custom integration makes sense when the required rules, data ownership or failure controls are not met by available options. Avoid putting a second synchronization layer around a connector unless there is a clear owner for each flow.
How to scope it honestly
Most ERP integration overruns come from scoping the happy path and discovering the failure handling later. Scope it the other way around:
- Map the system of record for every data type, in writing.
- List the events that must flow each way (order created, order cancelled, refund, stock change, price change, product created) and the direction of each.
- Define the failure behaviour for each: retry, alert, reconcile, ignore.
- Agree the reconciliation cadence and who owns the mismatches it surfaces.
- Decide what's explicitly out of scope — because "while we're at it" is how integrations double in cost.
- Test representative records and exceptions — include edits, cancellations, refunds, duplicates and temporary ERP unavailability; compare the mapped result before live writes expand.
- Agree cutover and recovery — define who can pause writes, how failed events are replayed, what is reconciled, and when the previous process is restored or retired.
If the integration's main job is moving work off people's plates rather than financial accuracy, you may find that lighter Shopify automation covers most of the value at a fraction of the cost — see what to automate in a growing store before committing to a full ERP build.
Abacus Marketplace lists a third-party Shopify Connector by DevQon. The listing describes Q910 API scopes for customers, products, prices and stock, while its technical-check date is 10 July 2024. Verify current support and confirm order, invoice and exception flows with the provider before deciding whether it covers your requirements.
If you're weighing an ERP integration, describe your Shopify and ERP stack. We use the Shopify plan, ERP and version, current apps or connectors, problem, approximate order volume and desired outcome to scope the first conversation. No admin credentials are needed in the enquiry.