E-commerce and ERP integration: keeping data in sync
A store and an ERP each hold a version of the catalogue, stock, orders and customer data, and they will disagree the moment one changes without the other. This page specifies the integration contract that prevents that: which system owns each field, how it synchronises, what happens when a sync fails, and how the two sides are reconciled.
Submit a project See the ERP workflow solutionReviewed by David Nguyen (CEO) · Updated 1 Oct 2026
Where the disagreement starts
A product's catalogue entry is edited in the ERP but the storefront keeps showing the previous version. An order is placed on the store and the warehouse never sees it because the sync job silently failed overnight. A customer's address is updated twice, once in each system, and nobody can say which version is current. None of these are integration bugs in the usual sense; they are the result of never deciding, in writing, which system is the source of truth for which field.
Source of truth per field
-
Product catalogue and descriptions
- Usual source of truth
- Storefront or a dedicated PIM
- Why
- Marketing and merchandising teams work there daily
-
Stock levels
- Usual source of truth
- ERP or warehouse system
- Why
- Physical counts and purchasing live there
-
Pricing and promotions
- Usual source of truth
- Depends on the business
- Why
- Either side can own it, but never both without a rule
-
Orders
- Usual source of truth
- Store creates, ERP fulfils
- Why
- The order is a one-way handoff once placed
-
Customer and account data
- Usual source of truth
- Depends on whether B2C or B2B
- Why
- A B2B account with ERP-side credit terms usually lives in the ERP
Writing this table out loud, for your own fields, is the first deliverable of the project, before any integration code exists.
The target workflow
-
Map the fields
List every field that exists on both sides and assign one source of truth per field, using the table above as a starting point.
-
Choose the sync method per data type
A webhook fires an update immediately when the record changes; a scheduled sync batches changes on an interval. Orders usually need the immediate route; a nightly catalogue refresh is often enough for descriptions.
-
Define the failure behaviour
A sync that cannot complete must be retried, queued or flagged, never silently dropped. Every failure needs an owner who is notified.
-
Build the reconciliation report
A scheduled comparison between store and ERP records surfaces drift before a customer or a warehouse finds it first.
-
Test the exceptions
A duplicate order, a cancelled order after fulfilment started, a stock level that goes negative, and a customer record edited on both sides in the same hour all need a defined resolution, not an assumption.
Where this differs from the back-office workflow page
ERP and back-office operations maps the back-office workflow itself, purchasing, stock and fulfilment, before an ERP is chosen. This page assumes a storefront and an ERP both already exist, or are both being chosen together, and specifies the contract between them: field ownership, sync method, failure handling and reconciliation. Use the back-office page first if the workflow itself is still undefined; use this page once a running store needs to agree with a running or planned ERP.
Data and integrations
Most storefront-to-ERP integrations run on webhook events for time-sensitive data such as orders and stock, with a scheduled sync as the fallback and the reconciliation check for everything else. Netbase's ERP consultancy and development experience covers e-commerce integration with ERP by API synchronisation of product catalogues, inventory, orders and customer data, alongside Odoo consultancy and customization, cloud ERP platform development, and a CRM-to-ERP upgrade path.
- Netbase's delivery lifecycle runs discovery and strategic alignment, team assembly and architecture planning, agile execution with outcome-based milestones, modular components, training and rollout, then ongoing support; for this integration, discovery closes only once the field-ownership table above is signed off by both the storefront and the ERP side.
- Most projects are agreed as fixed-scope contracts after discovery, with milestone-based arrangements also available.
- Working with a local Odoo implementation partner, Netbase has consulted on and customized Odoo in Vietnam for retail store chains, manufacturers, and trading and distribution companies among others.
Delivery modules
- Field-ownership map: a signed-off source of truth per field, reviewed with both the storefront and the ERP team.
- Sync layer: webhook listeners for time-sensitive data, a scheduled job for the rest, each with a defined retry rule.
- Failure handling: a queue for failed syncs, alerts to a named owner, and a manual replay path.
- Reconciliation reporting: a scheduled diff between store and ERP records, with drift surfaced before it reaches a customer.
- Cutover plan: a tested sequence for turning the integration on against real catalogue, stock and order data.
Rollout
Stage one agrees the field-ownership table and picks the sync method for each data type; skipping this step is why integrations ship with two systems quietly disagreeing about stock. Stage two builds the order and stock sync first, since those are where a failure costs money fastest. Stage three adds catalogue and customer sync, then the reconciliation report that proves the first two stages are holding.
Risks
-
A silent sync failure
An order that never reaches the ERP is worse than one that is visibly stuck, because nobody knows to look for it.
-
No agreed source of truth
Two systems editing the same field independently is a guaranteed future disagreement, not a risk to monitor.
-
Reconciliation treated as optional
Without a scheduled diff, drift is found by a customer complaint or a stock-out instead of a report.
-
Cutover tested only on sample data
Real catalogues carry edge cases, discontinued items and legacy codes that a small sample will not surface.
How success is measured
Track sync latency for orders and stock by data type; the rate of failed syncs and how quickly each is resolved; reconciliation drift found per cycle, trending toward zero; and the age of the field-ownership map against what the business actually sells. These are your numbers, on your two systems.
Who runs this integration
The workflow applies to any retailer, distributor or manufacturer running a storefront alongside an ERP that holds stock, purchasing, sales orders or accounting: a store built on Magento synchronising with an ERP, or an Odoo implementation feeding a separate storefront. It does not fit a single storefront with no back-office complexity, where the store's own stock and order tools are enough on their own.
Proof from delivery
Netbase's own ERP consultancy and development experience covers e-commerce integration with ERP by API synchronisation of product catalogues, inventory, orders and customer data, alongside Odoo consultancy and customization and cloud ERP platform development; these clients are not named. The Odoo implementations record is the published summary of the Odoo side of that work, delivered with a local Odoo implementation partner across retail store chains, manufacturers, and trading and distribution companies.
A related integration pattern appears in the loyalty and reward shop platform for a Dubai-based loyalty and rewards technology company, where Netbase built integrations with the client's points middleware, ordering service and product catalogue by webhook and scheduled sync, the same two sync methods this page scopes. The multi-tenant cloud ERP SaaS platform is the closest published example of the ERP side holding customer and workflow data at scale.
Since 2020, Netbase has worked as offshore development and managing partner on a multi-tenant cloud ERP that a US software company offers as SaaS to small and mid-sized businesses.
Keep Reading
Each of that company's client programmes gets its own branded reward shop, shoppers pay with a mix of points and cash, and orders route to the right supplier.
Keep Reading
This record is published because partner-assisted delivery is worth showing plainly.
Keep ReadingCommon questions
Usually the ERP or warehouse system, since that is where physical counts and purchasing already live; the storefront then displays a synced value rather than its own count.
Orders and stock usually need the immediate webhook route, because a delay costs money or oversells. Catalogue descriptions and other low-urgency data are often fine on a scheduled sync.
It should retry on a defined schedule, queue for manual review if retries are exhausted, and notify a named owner; it should never fail silently.
A scheduled reconciliation report compares store and ERP records on the fields each is supposed to own, and surfaces differences before a customer does.
Odoo work is delivered with a local Odoo implementation partner; other ERP integration and development work is Netbase's own, stated plainly wherever it is described.
Services behind this solution
Legacy application modernization, one bounded capability at a time
The code is assessed first, then one bounded capability moves at a time, with a way back.
Learn More
Scope this integration
Bring the storefront platform, the ERP (existing, chosen or still open), and a list of every field you suspect both systems touch. Legacy application modernization is the usual route when an existing store or ERP needs the integration added; B2B ordering portals covers the account-ordering layer this integration often feeds, and the ERP procurement and inventory guide covers the stock and purchasing decisions behind it, with legacy data migration planning for the cutover itself. Other workflows are listed under solutions. Submit a project with the two systems involved. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.