The answer in brief
For each type of data, an ERP-shop integration requires a leading system, a direction of transfer, and clear error rules. Middleware is particularly worthwhile when there are multiple shops, marketplaces, or partners, as mapping, orchestration, and monitoring can be managed centrally.
An ERP-shop integration is a business process with clear data responsibilities
The technical connection of two APIs is only the visible part of an integration. It must first be clarified which system manages items, prices, stock, customers, and orders. Without this decision, feedback loops, manual overwrites, and hard-to-explain differences arise. Therefore, a data object needs a leading source, defined recipients, and a rule for corrections.
In productive operation, exceptions are particularly important. Partial cancellations, partial deliveries, rounding differences, invalid addresses, duplicates, or delayed payments must be processed in a traceable manner. For each case, there needs to be a status, accountability, and a secure repeat path. An integration that only transfers the ideal order is a demo – not yet a robust business process.
Additionally, regular reconciliation is recommended, independent of ongoing message transport. In this process, order numbers, totals, stock levels, and shipping statuses are compared between the systems. Such reconciliation runs identify lost or duplicate transactions and create a second layer of security. Monitoring thus becomes not just a technical add-on, but a prerequisite for reliable commerce operations.
Acceptance of an ERP-shop connection
- Leading system per data object
- Test catalog for special and error cases
- Logging with unique transaction reference
- Regular quantity and status reconciliation
Why an integration is more than data transport
Technically, many systems can be connected via API, webhook, or file. The more difficult question is what professional significance a data record has on both sides. An order can be paid in the shop, reserved in the ERP, split in the warehouse, and partially delivered by the carrier. Each status needs a unique translation.
A robust integration models events, rules, and responsibilities. It does not prevent every error, but ensures that errors are visible, categorisable, and repeatably solvable.
Define a leading system for each data object
Item master, marketing text, price, stock, customer, order, payment, and shipping status can arise in different systems. Without established guidance, systems overwrite each other or generate conflicting values.
A data responsibility matrix documents source, target, direction, trigger, frequency, mandatory fields, and conflict rules. It is jointly approved by the specialist department and IT.
- SKU, EAN, variants, and units
- Titles, descriptions, categories, and media
- Prices, customer groups, and promotions
- physical, reserved, and sellable stock
- Customers, orders, payments, and taxes
- Deliveries, tracking, cancellations, and returns
Keep product data and variants consistent
Variant models differ between ERP and shop. Colour and size can be standalone items, variants of a master, or free attributes. The mapping must use stable keys and handle new, changed, and deactivated products.
Images and marketing texts are often closer to the shop or PIM, while SKU, EAN, weight, and procurement data come from the ERP. The integration must not blur these responsibilities through a blanket full reconciliation.
Manageable representation of prices, taxes, and promotions
Prices depend on country, currency, customer group, tax, tier, validity, and channel. A field transfer is only sufficient for simple models. Complex rules must be calculated in the leading system or implemented as clearly defined logic in the integration layer.
Promotions, vouchers, rounding, and shipping costs are tested with real orders. The ERP must be able to trace how the total amount paid in the shop was generated, without silently reinventing the calculation.
Inventory is a calculation, not a number
Physical stock is not automatically sellable online. Reservations, quality checks, safety stock, open returns, dropshipping, and channel buffers affect the available quantity. The formula must be professionally documented.
Synchronization frequency is determined by sales and risk. Webhooks can quickly report changes; regular control reconciliations detect lost messages. Both mechanisms complement each other.
Import orders completely and idempotently
An order includes more than just items: shop ID, customer assignment, addresses, tax, currency, discounts, payment method, shipping service, and marketplace references. Mandatory fields and replacement rules are coordinated before go-live.
Idempotence prevents duplicate orders when a message is sent again. Stable external keys and defined update rules are essential. An already picked order must not be overwritten uncontrollably by a late shop change.
Shipping, cancellations, and returns as a feedback channel
After the import, the return flow begins. ERP or WMS report processing, partial quantities, packages, carriers, and tracking. In the case of partial deliveries, it must be clear which package contains which item.
Cancellations and returns require time limits and responsibilities. Before release in the warehouse, an order may be automatically stopped; afterwards, a controlled exception process is needed. Refunds, goods receipt, and reavailability are separate events.
API, standard connector, or middleware?
A standard connector fits common processes and a clearly defined system pair. Custom API integration offers freedom but increases development and maintenance responsibility. Middleware is worthwhile when multiple channels, common rules, transformations, and central monitoring come together.
The decision should not only compare the initial effort. Updates, new fields, API changes, support, observability, and expansion to additional partners determine the total costs.
Design monitoring and operations from the start
A green server indicator does not prove that all orders have arrived. Technical monitoring checks quantities, age, status, and plausibility. Critical deviations trigger understandable messages with the responsible person and the next step.
Logs require correlation across systems. Retry logic, dead-letter cases, manual correction and reprocessing are tested and documented.
- sent, received and erroneous records
- oldest unprocessed message
- reconciliation of shop and ERP orders
- inventory discrepancies for critical items
- alerting with priority and owner
- resending without duplicates
The test catalog for go-live
The standard order is just the beginning. A robust test catalogue includes variants, vouchers, guest customers, international addresses, zero stock, partial shipping, cancellations, returns, timeouts and duplicate messages.
Go-live criteria connect technical and functional acceptance. Additionally, a fallback plan, support times and controlled ramp-up are needed. A limited assortment can secure the first operational days.
In conclusion
Frequently asked questions on the topic
How often should inventories be synchronised?+
Depending on sales, buffer, channel specifications and interface. Event-based updates plus regular control reconciliation are often sensible.
What does an ERP-shop integration cost?+
The effort depends on data objects, process deviations, volume, system versions, test cases, and operational requirements.
When do I need middleware?+
Especially when dealing with multiple shops, marketplaces, logistics or EDI partners, and when mapping, rules, monitoring, and repetitions need to be centrally managed.
How do you prevent duplicate orders?+
By using stable external IDs, idempotent processing, documented update rules, and tests with repeatedly delivered messages.