Shopify and ERP: when integration stops being a connector and becomes an operating decision

A business is selling well on Shopify. The ERP already exists, finance trusts its numbers, and operations runs on its own rhythm. Then comes the “simple” request: connect everything so orders flow automatically, stock updates in real time, and invoicing no longer depends on manual work.

The problem is usually not integrating Shopify with the ERP. The problem is discovering too late that each team had its own definition of order, stock and return.

My thesis is straightforward: a Shopify-ERP integration should not be designed as a data pipe, but as a decision about operational governance. If you do not decide upfront which system owns each event, the integration will only move the chaos faster.

The usual failure: automating rules that are still being debated

In many projects, the technical discussion starts before the operational one. People talk about plugins, webhooks, middleware, queues, custom fields and sync frequency. All of that matters. But there is a much more expensive prior question: what does “available stock” mean for your business?

It may mean several things:

• physical stock in the warehouse
• stock reserved but not shipped
• stock committed to external channels
• stock available for preorder
• stock that can be sold even if accounting has not been reconciled yet

If Shopify shows one number and the ERP shows another, you do not have an integration problem. You have an ambiguous definition.

The same applies to orders. For ecommerce, an order “exists” when payment is captured. For operations, it may exist when availability is confirmed. For finance, when the invoice is issued. If you do not choose a clear sequence, you will end up with duplicated orders, mishandled returns or invoices issued too early.

What the company should decide before connecting systems

Before touching the technology, five operational decisions should be closed:

1. System of record by data type. Who owns customer, product, price, stock, order and invoice?
2. Source event. Which system creates the record and which only replicates it?
3. Exception handling. What happens if stock is missing, a payment fails or an order arrives incomplete?
4. Acceptable latency. Do you need real time, every 5 minutes or batch sync several times a day?
5. Correction owner. Who reviews and fixes mismatches between systems?

This is often uncomfortable because it forces a choice. And choice means giving up some flexibility. But an integration without an operational owner becomes an incident generator.

A practical rule: if a decision affects money, stock or fiscal compliance, it should not depend on best-effort synchronization. It needs explicit failure behavior.

Mini-case: when Shopify stock was correct… until it wasn’t

Composite, very realistic scenario: an industrial spare parts company sells through Shopify and through an internal sales channel. The ERP was the reference for purchasing and accounting, but Shopify displayed nearly real-time stock.

At first everything looked fine. The problem emerged in three situations:

• manual reservations for large customers
• returns with delayed inspection
• items split across multiple warehouses

The integration still “worked”, but the business did not. Sales saw units available that operations had already committed. Customer support promised replenishment before purchasing confirmed it. Finance received late corrections.

The solution was not “more integration”. It was redesigning the process:

• the ERP became the source of truth for committed stock
• Shopify showed only sellable stock using conservative rules
• returns were classified by status before inventory re-entry
• an exception queue was created for orders that could not be reconciled

Practical result: less apparent automation, but far fewer incidents and much less invisible manual work.

The uncomfortable decision: not everything should be real time

This is the most controversial point. Many teams ask for real time because it sounds like control and modernity. In practice, real time can be a bad decision if:

• the data changes frequently and creates noise
• the business process is not yet stable
• there are multiple warehouses or channels with different rules
• manual correction after the fact is common

In those cases, a well-designed batch sync can be better than an instant integration. Not because it is prettier, but because it slows the spread of errors.

Another common mistake is pushing everything into middleware. Middleware should not define business policy; it should execute agreed rules. If it becomes the place where decisions are improvised, it turns into another parallel ERP.

Signs your integration needs redesign

You do not need to wait for a major outage. The early signs are usually clear:

• the team checks manual exports just to confirm what was already integrated
• stock exceptions increase without major catalog changes
• support sees orders that finance does not, or vice versa
• someone says “we usually fix that later”
• every incident ends in a handcrafted explanation

When several of these appear, the problem is no longer system connectivity. It is deciding which process you want to survive the integration.

Closing

Integrating Shopify and ERP can absolutely be the right move. But only when the company accepts that the main question is not technical, but operational: which data wins, which exceptions are tolerated, and who responds when reality does not match the ideal flow. In projects like this, Codefuente usually starts with those decisions before building the technical layer.