A Shopify store without integrations creates manual work: orders get retyped into the ERP, stock levels are updated by hand, invoices are entered twice. At ten orders a week that is bearable. At fifty a day it becomes half a full-time job that does nothing but move data from one system to another – making mistakes a program would not make. The good news: Shopify is unusually easy to connect, thanks to its Admin API and webhooks. The less good news: the connection itself is rarely the problem. The data is.

What an integration actually synchronizes

Behind the word “integration” sit several separate data flows, each of which needs its own plan. In one direction: an order in the shop should land in the ERP as a sales order, complete with customer, line items, payment method, and shipping address. In the other: stock levels, prices, and product master data from the ERP should keep the shop current. Then there is accounting, which wants paid orders turned into invoices or journal entries – in Austria that often means BMD or RZL, in Germany DATEV. This starting position is the norm, not a big-retailer specialty: according to Eurostat (2025), 46 percent of EU enterprises use ERP software, 89 percent among large enterprises and still 41 percent among small ones.

Each flow raises the question of data ownership: which system wins when two disagree? The usual answer is that the ERP is the master for products, prices, and stock, while the shop is the master for orders and customers. Skip that decision at the start and you will later find prices that differ between the shop and the invoice.

Three routes: ready-made app, iPaaS, or custom integration

For widespread systems there are ready-made connector apps in the Shopify App Store – for JTL, weclapp, Xentral, or Microsoft Dynamics 365 Business Central, among others. They are quick to set up and the right choice for standard cases. Their limit: they model the process the app vendor designed for. Edge cases like batch numbers, serial numbers, customer-specific prices, or a second warehouse often need workarounds, or don’t work at all.

Integration platforms like Make or n8n sit in between: you assemble data flows yourself without programming in the strict sense. That works well for simple, single-lane processes. With high order volumes, error handling, and recovery after outages, visual tools hit limits you only notice in production.

The third option is your own middleware: a small service that receives Shopify webhooks, translates the data into the ERP’s format, and logs both directions properly. It costs the most to build, but afterwards it is yours, it models exactly your process, and there is no monthly fee to an app vendor. Beyond a certain order volume, or from the second edge case onward, it is the more economical route.

	Ready-made app	iPaaS (Make, n8n)	Custom middleware
Effort until go-live	low	medium	highest
Running costs	monthly app fee	platform subscription	maintenance, no licence fee
Edge cases (batches, B2B prices, second warehouse)	often workarounds only	simple flows yes, complex ones barely	modelled freely
Error handling and retries	as the vendor designed it	the limit of visual tools	in your own hands
Who owns the process	the app vendor	the platform	you

The real work: data mapping

Technically transporting an order is built in a few days. What costs weeks are the questions behind it: do the SKUs in shop and ERP match, including every variant? How are discounts and voucher codes booked? Which revenue account do shipping costs go to? What happens with a partial shipment, a partial refund, a cancelled order whose invoice already exists?

VAT deserves particular attention. An Austrian shop selling to Germany deals with the EU distance-selling rules (OSS) and different tax rates per destination country – and accounting has to be able to report those orders separately. This is not a Shopify weakness; Shopify calculates the rates correctly. But the integration has to carry the full tax information across, or someone sorts it out by hand at the end of every month.

Where integrations fail in production

The typical failures happen in month three, not on day one. A webhook arrives twice and creates the same order twice, because the integration never checks whether it already knows this order. The ERP is unreachable overnight and the orders from those hours are simply missing, because nobody built a retry mechanism. Or a product gets renamed in the ERP and the mapping silently breaks.

A good integration expects all of this: it processes every order idempotently (received twice means created once), it remembers failed transfers and retries them, and it raises an alert when something is stuck – instead of quietly losing data. Ask any vendor how they handle these three cases. The answer tells you whether they have run something like this in production before.

Test with real orders, not slides

Before go-live, the full cycle should be walked through with test orders: a normal order, one with a voucher, one with two variants of the same product, a cancellation, a refund, an order to another EU country. Every one of them has to arrive in the ERP, in accounting, and in the shipping system the way your tax advisor and your warehouse expect.

Plan that time with the people who work with these systems daily. The bookkeeper spots a wrong revenue account in five minutes. The warehouse worker immediately notices when the shelf number is missing from the delivery note. Those five minutes before launch save weeks of cleanup afterwards.

What this means in practice

If your ERP is widespread and your process is standard: take the ready-made connector and spend the money on clean master data instead. If your business has edge cases – B2B pricing, multiple warehouses, in-house production, an older ERP without a ready-made app – price out a custom integration before you build the third workaround around a standard app. We build these integrations for Shopify stores in Austria, including the mapping sessions with your tax advisor and ERP consultant, because that is where the project is won or lost.