The short answer

You connect Shopify to an ERP by using an integration layer that already speaks to both systems, so orders, inventory and purchase-order data move between them without someone re-keying records or maintaining a script. Shopify holds the storefront and the customer; the ERP holds inventory, purchasing and finance. The integration decides which system is authoritative for each piece of data, then keeps them agreeing.

The part worth thinking about is not the initial build. It is who owns the connection twelve months later, when Shopify deprecates a field or your ERP changes a behaviour. Most integrations do not fail at launch. They fail quietly afterward, and the failure surfaces as a customer asking where their order is.

What moves between them

Six flows, and a direction for each

Most integration projects are scoped as "connect Shopify and the ERP". The useful version names each flow and which system wins when they disagree.

Orders

Shopify → ERP

Every paid order becomes a record the ERP can fulfill and invoice against. This is the flow most often done by hand, and the one where re-keying shows up as shipping errors rather than as typing time.

Inventory

ERP → Shopify

Available quantities flow back so the storefront stops selling what you cannot ship. The ERP is authoritative here; when the two disagree, Shopify is the copy that is wrong.

Purchase orders

ERP → Shopify → customer

Incoming stock carries an expected date. Shopify has no field for it, which is why "when will this ship?" is answered by a person reading a PO rather than by the store.

Customers

Both ways

Accounts, addresses and terms, especially for B2B where the same buyer exists in both systems under different ids. Deciding which side wins is the hard part, not moving the record.

Fulfillment and tracking

ERP or 3PL → Shopify

Shipments and tracking numbers post back so the customer sees the order close. When this is manual, orders sit "unfulfilled" long after they shipped.

Financials

Shopify → ERP

Payouts, refunds and fees reconciled against orders. Usually the last flow built and the first one finance asks for.

Four ways to do it

Which approach fits your operation

All four of these are legitimate and we have seen each of them work. The question is not which is best in the abstract, but which matches how specific your process is and who will own the result.

Native connectors

An app from the Shopify App Store, or one your ERP vendor publishes.

Where it fits
A standard catalog, one storefront, one warehouse, and a process that matches how the connector assumes you work.
Where it breaks
The first time your process differs from its assumptions. There is usually no way to express "except when the item is a dropship line" in a settings screen, and the gap comes back to your team as manual work.
Who maintains it
The vendor, for the connector. Nobody, for the gap between it and your process.

Middleware (Celigo, Boomi and similar)

A platform you build flows in, with pre-built templates for common system pairs.

Where it fits
Teams with someone in-house who will own the flows. Genuinely capable, and the templates are a real head start.
Where it breaks
It is a tool, not an outcome. Licence plus implementation is rarely small, and the flows still have to be built, tested and maintained by someone who understands both systems.
Who maintains it
You do, or an agency you retain. The platform maintains the platform.

Custom scripts

A developer or agency writes integration code against both APIs.

Where it fits
Exactly your process, because it was written for it. The fit is better than anything off the shelf.
Where it breaks
After handoff. The APIs change, the person who wrote it moves on, and nobody owns the thing that breaks at 3am. This is the most common state we find during an Assessment, and the one teams describe as "it mostly works".
Who maintains it
In principle you. In practice, whoever is available when it breaks.

An embedded engineer

An engineer who builds the integration on your systems and then runs it as part of your operations.

Where it fits
Processes too specific to buy, where the cost of it silently breaking is higher than the cost of building it. Works with any system that has an API, including one no vendor has built a connector for.
Where it breaks
It is not the cheapest option if a native connector genuinely fits your process. If it does, use it — that is the honest answer, and we will say so in the Assessment.
Who maintains it
We do. We built it, we run it, and we report every month on what it produced.

What this looks like in practice

A distributor who stopped answering the same question

Yota Xpedition sells vehicle equipment on Shopify, with stock arriving against supplier purchase orders. Shopify could tell a customer an item was out of stock. It could not tell them when more was coming, because that date lived on a purchase order in another system. Support answered it by hand, one order at a time.

Their embedded engineer connected the systems so the expected date reaches the customer before they ask. Between May and August 2026 that addressed 1,493 orders, representing $510,323.61 in order value.

Addressed means those orders received a proactive answer that a person would otherwise have written. We report what the automation did, not what we estimate it saved.

FAQ

Shopify and ERP, answered

How do you connect Shopify to an ERP without custom development?

You connect Shopify to an ERP by using an integration layer that already speaks to both systems, so order, inventory and purchase-order data moves between them without a developer writing and maintaining the plumbing. The work customers usually describe as "custom development" is not the initial build — it is the part nobody maintains afterward. Clarissi connects the systems and keeps the connection working as either side changes.

Which ERP systems can Clarissi connect Shopify to?

Any system with an API. Clarissi does not ship a fixed list of pre-built ERP connectors — an embedded engineer builds the integration against your ERP, including one no vendor offers a connector for. That is the practical difference from native connectors and middleware templates, which support a published list and leave you to solve anything outside it.

How long does a Shopify to ERP integration take?

It depends on whether an integration for your system already exists and how many data flows you need on day one. Rather than quote a number that cannot be accurate before anyone has seen your stack, the Assessment scopes it against your actual systems and volumes and tells you what the sequence looks like.

What does a Shopify ERP integration cost?

Clarissi engagements are priced by outcomes rather than by hours or seats, starting with a paid Assessment that prices your specific stack before you commit to building anything. Compared with middleware, there is no separate platform licence; compared with a custom build, the ongoing operation is included rather than being a cost you absorb after handoff.

What happens when Shopify or the ERP changes their API?

That is the scenario the embedded-engineer model exists for. APIs deprecate fields and change behaviour on their own schedule, and an integration nobody owns fails quietly — usually discovered when a customer complains. Your embedded engineer monitors the integrations they build and fixes them as part of the engagement.

Can you tell customers when a backordered item will ship?

Yes, and it is one of the most common reasons distributors connect the two systems. Shopify knows an item is out of stock; it does not know when more is arriving. That date lives on a purchase order in the ERP or a supplier feed. For Yota Xpedition, reading it and sending it automatically addressed 1,493 orders representing $510,323.61 in order value between May and August 2026.

Find out what your stack actually needs

The Assessment is a paid diagnostic, not a sales call. We map your systems, tell you which flows are worth connecting first, and say so plainly if a native connector would serve you better than an engagement would.