Running a Shopify ERP integration more often can leave stock figures less accurate, not more. When Shopify and the ERP both write the same available quantity, a faster schedule only lets each system overwrite the other sooner. What keeps inventory and orders aligned is a named system of record for every field, event-driven updates backed by a scheduled reconciliation, and a defined way to catch and replay failed messages. With those three settled, an app, middleware or a custom connector can each do the job. Without them, overselling, cancelled orders and manual corrections tend to return whatever the tooling costs.
That shifts the first conversation away from software. Before anyone compares connectors, the operations, finance and ecommerce teams need to agree which system is allowed to change stock, price, order status and customer terms, and what happens when an update fails at two in the morning. Those decisions sit at the centre of any ecommerce ERP integration project, and they are cheaper to make on paper than to discover after go-live.
Why Stock Drifts Even When the Connector Reports Success
A sync log full of green ticks shows that messages were delivered, not that the numbers mean the same thing on both sides. Most drift comes from structural causes rather than a broken connection, which is why replacing the connector without changing the rules often brings the same symptoms back.
Two systems writing the same field
The most common cause is shared ownership. A warehouse team corrects a count in the ERP, a merchandiser adjusts the same variant in the Shopify admin to cover a promotion, and the next scheduled push quietly erases one of those changes. Neither team made a mistake; the integration simply had no rule for who wins, and staff soon start keeping private spreadsheets as a safety net.
Different definitions of “available”
Shopify does not hold a single stock number per location. Its developer documentation describes several inventory states, including available, committed, reserved, damaged, safety stock and quality control, which together make up the on-hand quantity. The committed state is managed by Shopify itself as orders are created and fulfilled, and the GraphQL Admin API does not allow apps to adjust it directly. An ERP that calculates its own available figure, subtracting allocations for orders it has already received, and then pushes that figure into Shopify’s available state can double-count orders that are committed in Shopify but not yet imported. The result is stock that looks lower than reality, or, after a correction, higher.
Unit and variant mapping adds a second layer. Microsoft’s documentation for the Business Central Shopify Connector gives a worked example: an item stocked as six pieces and also sold as a box of six appears in Shopify as available in both variants, so a second buyer may see stock that has already gone. Shopify corrects itself only at the next inventory sync. With any ERP, if the two systems model a product differently, the integration has to translate the model, not just copy a quantity.
Timing gaps, lost events and inaccurate source data
Every integration has a window between a change in one system and its arrival in the other, and during a flash sale that window may matter more than the average delay suggests. Events can also arrive out of order or not at all.
Finally, an integration copies whatever the ERP believes. The RFID Lab at Auburn University, in a study run with GS1 US, measured average inventory accuracy of around 63% across the retailers it sampled before item-level RFID was introduced. That study looked at physical store records rather than online integrations, but a perfect inventory sync of an inaccurate count still produces an inaccurate store, so cycle counts and receiving discipline belong in the same conversation as API design.
The commercial stakes are broad. IHL Group’s 2025 inventory distortion research puts the worldwide cost of out-of-stocks and overstocks at roughly $1.7 trillion a year. That figure covers all of retail, including causes such as theft and supplier problems that an integration cannot address, so it indicates the scale of the stock problem rather than the share caused by poor system connections.
Deciding the System of Record for Each Shopify ERP Integration Field
The system of record is the one place where a piece of data may be created or changed; every other system receives a copy. Microsoft’s Business Central documentation advises deciding this for product data before configuring synchronisation, because conflicts after go-live are harder to unwind. The same principle extends to stock, prices, orders and customers, and the answer is rarely the same system for every field.
| Data | Usual system of record | Direction | Typical trigger |
|---|---|---|---|
| SKU, product master, cost | ERP | ERP to Shopify | On change, plus nightly check |
| Marketing content, images, SEO fields | Shopify (or a PIM) | Stays in Shopify | Not synced to the ERP |
| On-hand stock per location | ERP or warehouse system | ERP to Shopify | Event on stock movement, plus reconciliation |
| Orders and payment status | Shopify | Shopify to ERP | Order webhook, plus polling for missed orders |
| Fulfilment, tracking, shipped quantities | ERP, WMS or 3PL | Back to Shopify | On dispatch |
| Refunds and returns | Shopify for the refund, ERP for the stock receipt | Both, as separate events | On refund and on goods received |
| B2B price lists and payment terms | ERP | ERP to Shopify | On change |
The table is a common starting point, not a rule. A brand that manages its catalogue and pricing entirely in Shopify and uses the ERP mainly for accounting may reasonably reverse the product rows. What matters is that each row has one written-down system of record, and that the other system is configured so staff cannot quietly edit the copy. That may mean removing Shopify admin permissions for fields the ERP controls, an organisational change as much as a technical one.
Stock deserves particular care. Where the ERP owns on-hand quantities, the cleaner pattern is often to send physical stock movements, such as goods received, adjustments and transfers, and let Shopify continue to manage committed quantities for orders it has taken. That keeps each system responsible for the part of the calculation it actually knows. Where a warehouse or 3PL is the true physical source, the ERP may itself be a copy, and the integration design should reflect that chain rather than pretend the ERP is authoritative.
How Inventory Sync Should Run: Events, Schedules and Reconciliation
Most reliable designs for inventory sync combine three mechanisms, each covering a weakness in the others.
Events for speed
Webhooks let Shopify notify the integration when an order is created, paid, edited, cancelled or refunded, and many ERPs offer equivalent events for stock movements. Events keep the delay short, but their limits are documented. Shopify’s webhook best practices state that delivery order is not guaranteed within a topic or across topics for the same resource, that delivery is not always guaranteed, and that apps should run reconciliation jobs to stay consistent with Shopify’s data. Shopify also retries a failed delivery up to eight times over four hours, treats a response slower than five seconds as a failure, and may remove the subscription if failures persist.
Two design consequences follow. The receiving endpoint should acknowledge the message immediately and place it on a queue, so slow ERP processing does not cause Shopify to count deliveries as failed. And every handler should be safe to run twice, because the same event may arrive more than once. Shopify’s inventory mutations support this directly: an idempotency key protects against duplicate adjustments, and a compare-and-swap value can reject an update if the quantity has changed since it was last read.
Scheduled deltas for volume
Price list updates, nightly cost changes and bulk catalogue edits are often better sent as scheduled jobs that process only what changed since the previous run. Shopify’s GraphQL Admin API meters usage by calculated query cost, with higher allowances on higher plans, so a batch design that respects those limits tends to finish predictably rather than stalling midway.
Reconciliation for truth
Reconciliation is the step teams most often skip. It is a scheduled comparison of the two systems, usually stock per SKU and location plus a list of recent orders, that reports or corrects any difference. Without it, a single missed event can leave a variant wrong until a customer complains; with it, the next run catches the gap. How often to reconcile depends on sales velocity: hourly may suit a busy catalogue, while a slower B2B range may need only a nightly pass.
Key takeaway: real-time inventory sync is a target, not a guarantee. Treat events as the fast path, reconciliation as the safety net, and the system of record as the referee that decides which number is correct when the two disagree.
Keeping Orders Aligned From Checkout to Dispatch
Order errors tend to surface later than stock errors, in finance reports, customer service queues and picking lists. The core rule is that each Shopify order should create exactly one ERP sales order, keyed on the Shopify order ID, so a repeated webhook updates the existing record instead of creating a duplicate. Beyond creation, the integration needs a mapped response to each event that changes an order after it has been exported:
- Order edits. Shopify allows staff to add or remove items after checkout. If the ERP has already released the order to the warehouse, the integration needs a rule to apply, hold or reject the edit.
- Cancellations. A cancelled order should release committed stock in Shopify and cancel or credit the ERP order, often after a status check in case picking has started.
- Partial fulfilment and split shipments. When an order ships from two locations or in two parcels, the ERP or warehouse system should report each shipment back to Shopify with its own tracking, so customers receive accurate notifications.
- Refunds and returns. A refund and the physical return are separate events. Treating them as one can restock goods that never came back, or delay a refund until the warehouse processes a parcel.
- Tax, discounts and shipping lines. These rarely map one-to-one onto ERP line structures. Agreeing how a discounted bundle or a free-shipping promotion is posted avoids month-end reconciliation work in finance.
App, Middleware or Custom Connector: Matching the Tool to the Rules
Once ownership and sync behaviour are defined, the choice of tooling becomes clearer. A ready-made connector may be sufficient when the ERP is a widely supported system, the store uses one warehouse or a few, and the business can adopt the connector’s data model. Microsoft’s Shopify Connector for Business Central is an example of this category: it maps items, prices and stock using configurable options and runs synchronisation through the ERP’s job queue.
Middleware becomes more appropriate when several systems share the same data, for example an ERP, a 3PL and a marketplace feed, and the business needs one place to monitor queues and errors. A custom connector tends to make sense when pricing, allocation or fulfilment rules are specific enough that a generic model would force workarounds. An app is quicker to start and cheaper to maintain while it fits; custom work costs more up front but can follow the business’s actual rules. Neither option, on its own, resolves undefined ownership in a Shopify ERP integration.
A 7-Step Process for a Shopify ERP Integration That Stays in Sync
- Map the current data flows. List every system that touches stock, orders, prices and customers, including spreadsheets and manual exports. Hidden manual steps are often where drift starts.
- Assign a system of record per field. Record the owner, the direction and the trigger for each data type, and get sign-off from operations, finance and ecommerce, since each team gives up some editing rights.
- Define the stock calculation. Agree which inventory states the ERP sends, how safety stock is handled, and how units of measure and bundles translate into Shopify variants.
- Design order rules and B2B terms. Document edits, cancellations, split shipments and refunds. Where trade customers are involved, decide how company accounts, price lists and payment terms flow from the ERP; B2B ecommerce development work often starts at this step because wholesale pricing is where generic connectors are most likely to fall short.
- Build with queues, idempotency and logging. Acknowledge events quickly, process them from a queue, make every handler safe to repeat, and log each message with enough detail to replay it.
- Test against real scenarios. Run a sale-day volume test, simulate the ERP being offline, send duplicate and out-of-order events, and confirm that reconciliation finds and fixes the differences created on purpose.
- Monitor and reconcile after launch. Set alerts for queue backlogs, repeated failures and reconciliation differences above an agreed threshold, and name the person who responds to each alert.
Steps two and three usually take longer than teams expect, and that time is well spent: most of the stock problems described earlier trace back to decisions skipped at this stage rather than to badly written code.
What a Working Stock and Order Integration Looks Like in Practice
The same principles apply beyond Shopify. In WD Market’s Saules Aptieka pharmacy rebuild and ERP integration, the store was rebuilt on Magento and connected to the client’s custom internal ERP. The case study describes the starting point as stock and orders handled manually, with “no seamless integration with internal systems for stock and order management”, and the outcome as “100% automated stock & order integration with internal ERP”. The platform differs, but the shift from staff re-keying data to one system feeding the other on defined rules is the one a Shopify ERP integration should aim for.
Internal expert input required: add a verified Shopify-specific example of an inventory or order synchronisation issue, its cause, and how it was resolved, with client approval.
Mistakes That Undo a Working Integration
- Fixing drift by increasing sync frequency. If two systems own the same field, faster syncing only speeds up the overwrites. The ownership rule has to change first.
- Running without reconciliation. Missed or out-of-order events are documented platform behaviour. Without a scheduled comparison, each one becomes a lasting error.
- No owner for failures. A retry queue without an assigned owner may hide problems for days. Alerts are only useful when someone is responsible for acting on them.
- Treating go-live as the finish line. New warehouses, sales channels, ERP upgrades and Shopify API versions can all change the integration’s assumptions, so it needs periodic review like any other operational system.
Keeping Stock and Orders Aligned Is a Design Decision
Inventory and orders stay synchronised when ownership is explicit and the integration is built to expect failure. That means one system of record per field, events for speed, scheduled reconciliation to catch what events miss, and order rules agreed with operations and finance before mapping begins. The tooling choice, whether an app, middleware or a custom connector, follows from those decisions rather than replacing them. A sensible next step is to compare how each data type currently moves between Shopify and the ERP against that standard, and to note where two systems are still editing the same number.
From Mismatched Stock Counts to One Reliable Record
If stock corrections, duplicate orders or manual exports are still part of the weekly routine, an integration assessment is usually the quickest way to see whether the current connector can be fixed or needs replacing. You can explore WD Market’s ecommerce ERP integration services to see how the work is scoped, from data flow mapping and sync rules to error handling with retries and logging, with integrations running outside the storefront so checkout performance is not affected. The review also identifies where a ready-made connector remains the better fit.
To discuss your own setup, contact our engineering team with a short outline of the ERP, warehouses and sales channels involved. For ongoing notes on integrations, operations and platform changes, follow WD Market on LinkedIn.
Shopify ERP Integration: Questions Buyers Ask
Can a Shopify ERP integration be truly real-time?
Event-driven updates can bring the delay down to seconds or minutes, but no design can promise zero delay in every case. Shopify documents that webhook delivery order and delivery itself are not guaranteed, and ERPs may queue or batch their own updates. A dependable setup therefore pairs events with scheduled reconciliation. For SKUs with very low stock during busy periods, safety stock in Shopify can absorb the remaining gap between systems.
Should Shopify or the ERP be the system of record for inventory?
For physical stock, the ERP or warehouse system is usually the better owner, since it records goods received, transfers and counts. Shopify should continue to manage committed quantities for its own orders, because its API does not let apps adjust that state. A store with no warehouse system and a simple catalogue may keep Shopify as the stock owner, provided only one system is allowed to change the number.
How do we know whether our current connector is the real problem?
Compare the symptoms with the causes. If differences cluster around manual edits, bundles or units of measure, the rules need changing before the connector does. If messages fail silently, there is no retry visibility, or the connector cannot model your pricing and warehouse structure, replacement may be justified. An integration assessment for Shopify and ERP data flows can separate the two before money is spent on new tooling.
What does an integration like this typically cost?
Cost depends on the number of systems, data types and custom rules. A supported app may cost a monthly subscription plus configuration time, while custom work is usually quoted per project. WD Market’s service page lists fixed-price implementations from €3,000 to €15,000+ for clearly defined ERP integration projects, so the scope document produced during discovery has a direct effect on the final figure.