E-shop ERP integration: how to plan data, ownership, and workflows

5 September 2026 | Neuronidis Manos | Blog

E-shop ERP integration succeeds when the business decides, before development, which system owns each piece of information. The ERP often owns stock, purchasing, accounting, and operational records. The e-shop owns the online buying experience, product presentation, and checkout context. That division is common, but it is not automatic. It must be agreed, documented, and tested.

Many integration projects go wrong because the first question is, “Which API do we connect?” The better question is, “Which system has the final say?” Once that answer is clear, teams can define what moves, when it moves, how values change, and what happens when the two systems disagree.

The first decision is not technical: define what each system owns

A source of truth in business systems is the place whose value should be accepted when two records conflict. It does not have to be the same system for every data type.

For example, an ERP may own product SKUs, supplier information, purchasing costs, warehouse quantities, invoices, and accounting status. The e-shop may own product descriptions written for shoppers, images, category presentation, search settings, cart contents, and checkout data. A marketing platform might own newsletter consent, while a payment provider owns the result of a payment attempt.

Write this down in an ownership matrix. For every entity, identify the owner, the systems that receive a copy, the permitted editors, and the action taken when an update fails. Avoid vague decisions such as “the ERP manages products.” A product name, product description, tax class, and stock figure may all have different owners.

This early analysis is often more valuable than starting development immediately. Saikō’s article on why proper analysis costs less than endless fixes makes the same practical point: unclear decisions tend to reappear later as expensive exceptions.

Which data needs to move between the e-shop and ERP?

The data that needs to move depends on the operating model, but most ERP and e-shop integration projects must address products, prices, customers, orders, stock, fulfilment, payments, and returns. The important decision is not only what to synchronize. It is also the direction and purpose of each update.

Data area	Typical ownership decision	Questions to settle before development
Products and variants	ERP or product information system publishes core data; e-shop controls presentation fields where needed	Are SKUs, barcodes, sizes, colours, bundles, and discontinued items identified consistently?
Prices	ERP or pricing system publishes standard and customer-group prices	How are tax rules, promotions, rounding, currencies, and scheduled price changes handled?
Customers	Shared record with defined ownership for account and commercial information	How are guest checkouts, duplicate customers, consent, VAT details, and account merges handled?
Orders	E-shop creates the order; ERP receives it for fulfilment, invoicing, and operational processing	Which statuses, payment results, cancellations, discounts, and delivery details must be transferred?
Inventory	ERP or warehouse system publishes sellable availability	Does available stock exclude reservations, safety buffers, damaged goods, or pending orders?
Shipments and returns	Warehouse or ERP records physical movement; e-shop displays customer-facing status	How are partial shipments, returned quantities, exchanges, refunds, and inspection outcomes represented?

Not every field needs two-way synchronization. A product description may flow from the ERP to the e-shop, while the e-shop sends only the published product URL or visibility state back. An order may be created in the e-shop and updated by the ERP with picking, dispatch, and invoice information. Some payment details should remain with the payment provider and be represented only by safe references or statuses.

Customer data needs extra care. Define the lawful purpose for storing and transferring personal information, the consent fields required for marketing, and the retention rules. The customer account is not the same thing as the order record. Historical orders need to preserve the address, tax treatment, prices, and product details used at purchase time, even if the customer later edits their account.

Products, prices, and stock need separate rules

Catalogue data should not be treated as one large block. Product identity, sales presentation, commercial pricing, and availability have different risks and update patterns.

Start with a stable identifier. The SKU should have one agreed format, while barcodes, internal item codes, variant IDs, and supplier codes should be mapped explicitly. Decide whether a variation is a separate sellable item. This matters for size-level stock, bundles, replacements, and returns.

Then define field-level ownership:

• Core fields such as SKU, barcode, weight, tax class, and purchasing status often come from the ERP.
• Descriptions, images, category placement, filters, and search text may be maintained in the e-shop or a product information workflow.
• Standard prices, customer-group prices, and promotional prices need a clear precedence rule.
• Visibility should reflect business conditions, not only whether a product record exists.

Product and inventory synchronization also needs a precise stock formula. “Quantity in ERP” may not equal “quantity available online.” The sellable figure could subtract reserved units, unconfirmed orders, safety stock, damaged goods, or stock held at locations that cannot fulfil e-shop orders.

Warehouse location rules matter when more than one site exists. Decide whether the e-shop displays total available stock, stock from a selected warehouse, or a promise based on fulfilment priority.

Do not let supplier spreadsheets become an unverified source for live availability. A spreadsheet can support imports, but it needs validation, an owner, an update schedule, and checks for duplicate SKUs or unexpected zero quantities. Saikō has also written about how supplier Excel files can make an e-shop sell products it cannot actually deliver.

Orders, customers, and returns require a clear event flow

Order integration should describe the complete operational sequence, not just the moment an order is copied from one system to another. A typical flow is checkout, payment result, order creation, ERP acceptance, picking, packing, shipment, invoicing, and customer notification.

Each status needs a shared meaning. “Processing” in the e-shop might mean payment confirmed, while the ERP might use it for an order waiting for warehouse action. Create a status-mapping table instead of assuming that identical words mean identical events.

Define what happens when:

• A payment is authorised, declined, pending, or later reversed.
• A customer cancels before picking, after picking, or after dispatch.
• Only part of an order is available for shipment.
• A warehouse employee changes a quantity or replaces an item manually.
• A guest customer later creates an account with the same email address.
• A return contains only some units from a line, or the returned item fails inspection.

Returns are especially easy to simplify incorrectly. The e-shop may collect the request, reason, photos, and customer communication. The ERP or warehouse system may confirm receipt, inspect the goods, restore stock, record a replacement, and trigger the refund. The integration must distinguish a requested return from an approved return, a physically received item, and a completed refund.

For e-shop returns management, define whether returned goods go back to sellable stock, quarantine stock, repair stock, or write-off status. An automatic stock increase before inspection can create another availability problem.

Choose the right synchronization frequency and conflict policy

Synchronization frequency should follow business impact, not fashion. Real-time updates may suit stock and order events where overselling or delayed fulfilment creates immediate risk. Scheduled synchronization may be sufficient for descriptions, images, and category changes.

Event-based processing can send an update when something happens, while scheduled jobs can collect changes at defined intervals. The choice depends on system limits, operational hours, order volume, and the cost of stale data. A “real-time” design is not useful if failures are invisible or a downstream system cannot process the volume.

Set a written conflict policy. It should state:

• Which system wins for each field.
• Whether the latest valid timestamp matters.
• Which changes are rejected by validation.
• How failed messages are retried and when they stop retrying.
• Where each change is recorded for audit purposes.
• Who receives an alert and who resolves the exception manually.

Never silently overwrite a conflicting value. A price changed in the ERP and an e-shop promotion changed at the same time may require a business decision, not a technical guess. Keep the original message, the error reason, and the attempted resolution so support staff can explain what happened.

Turn the decisions into an integration brief before development

Before requesting estimates, convert the business decisions into a short integration brief. It should be specific enough that different developers or vendors would understand the same expected result.

• An ownership matrix for products, prices, customers, orders, stock, shipments, payments, and returns.
• A field-mapping table with source, destination, format, required status, and transformation rule.
• A status-mapping table for payment, order, shipment, cancellation, refund, and return events.
• Frequency rules for real-time, event-based, and scheduled updates.
• Rules for taxes, currencies, rounding, discounts, identifiers, stock buffers, and warehouse locations.
• Exception scenarios, retry limits, alerts, audit records, and manual resolution steps.
• Sample records, including variants, guest customers, partial shipments, and returned quantities.
• Permissions and data protection requirements for every system involved.
• Acceptance tests for ordinary orders and failure cases.

Test more than a successful checkout. Test an out-of-stock item, a price change during checkout, a duplicate customer, a failed message, a cancellation after picking, a refund, and a partial return. Check the final stock, order status, invoice data, customer notification, and audit trail in each system.

This is the practical work that makes development predictable. It also makes vendor discussions more precise. If the integration is part of a wider automation programme, Saikō’s intelligent automation service page provides relevant context on connecting business systems. The main lesson remains simple: decide ownership and exceptions first, then build the connection around those decisions.