The problem is not the shop and not the ledger
The typical picture: a storefront on a hosted platform, a marketplace listing, accounting software and a spreadsheet for stock. Every part works. What does not work is the joins between them.
In practice that looks like this: web orders are re-keyed by hand, stock levels are pushed to the marketplace once a day as a file, and the warehouse lives its own life. At ten orders a day this is almost convenient. At fifty you start selling what you do not have, and the cancellations damage your marketplace rating.
The thing to understand first: integration is not a technical exercise in exchanging files. It is a decision about where the truth about your stock lives. Everything else follows from that.
The question that decides everything: who owns stock
One system must be the source of truth for quantity. Not two, not "we reconcile in the evening" — one. This is the most consequential decision in the whole project and it should be made before anyone writes a line of code.
Option one: the ERP owns stock. The storefront and marketplaces receive quantities from it and never change them independently. This is the right answer for most companies, because the physical goods sit in a warehouse rather than on a website, and every receipt, return and write-off happens in the ledger.
Option two: the storefront owns stock. This makes sense only when you trade exclusively online, hold no warehouse of your own, and goods ship from a supplier directly to the buyer.
The worst option is both systems maintaining stock with periodic reconciliation. That guarantees a data conflict; the only question is how quickly it surfaces.
What to synchronise, and what not to
The temptation to synchronise everything produces an expensive and fragile solution. Four flows are actually needed.
| Flow | Direction | Why |
|---|---|---|
| Products and prices | ERP → storefront | One item master, one price, no manual duplication |
| Stock levels | ERP → storefront | So you stop selling what is not there |
| Orders | Storefront → ERP | So nobody re-keys them |
| Statuses | ERP → storefront | The customer sees that the order is picked and despatched |
What not to synchronise: product descriptions, photographs, SEO copy and reviews. That is storefront content and it has no business in an accounting system. Trying to maintain rich product cards with images inside an ERP is a classic mistake that doubles the size of the project and returns nothing.
Marketplaces change the picture
If you sell on marketplaces as well as your own site, a complication appears that people rarely plan for.
One product, several listings. Each marketplace has its own listing with its own identifier. The mapping between your SKU and each platform's product code has to live somewhere, and that somewhere should be a system rather than a lookup table on somebody's laptop.
Allocation across channels. With 100 units in stock and three channels, showing 100 in each is an invitation to oversell. In practice you either show every channel the same real figure with frequent updates, or you allocate quotas per channel. The first is simpler and usually works better; the second matters when a platform penalises you in the rankings for a failed order.
Returns. Marketplace return rates are markedly higher than on your own site, and the goods come back with a delay. If returns are not documented as they arrive, stock will drift — it is one of the standard causes of discrepancies.
How often to update
A common mistake is to synchronise everything in real time. That is expensive, loads both systems and is almost never necessary.
- Stock — most frequently of all, from a few minutes to half an hour. This is the flow where delay costs money.
- Orders — real time or close to it. Customers expect fast confirmation.
- Prices — a few times a day is enough unless you run dynamic pricing.
- New products and descriptions — daily. This data does not change by the minute.
Think separately about what happens when the connection drops. The correct behaviour is that the storefront keeps trading on the last known stock figures, then receives current data when the link returns, with any conflicts flagged in a report. The wrong behaviour is that it shows zeros and you sell nothing.
A checklist before you start
Questions worth answering before any conversation about technical implementation.
- Which system owns stock — one, without exceptions?
- Is the item master clean, with no duplicates under different names?
- How do your SKUs map to each marketplace's product codes?
- What happens to an order cancelled after stock was reserved?
- Who documents returns, and within what timeframe?
- What does the storefront do when the ERP is unavailable?
- Who maintains the integration after launch, when a platform changes its API?
The last point is the most underestimated. Marketplaces change their interfaces without consulting you, so an integration needs ongoing support — it is not a project with a completion date. Cleaning the item master before you start is covered in the data preparation checklist.
Frequently asked questions
Can any storefront platform be integrated with an ERP?
Practically any that has an API or file-based exchange. The difference is cost: popular platforms have ready-made connectors, while a bespoke site needs the integration built. Worth establishing before choosing the ERP rather than afterwards.
Should online-only products be kept in a separate item list?
No. Keep them in the same master data with a channel attribute. A separate catalogue for online is the road to duplicates and discrepancies that later have to be reconciled by hand.
How do we avoid selling the same item twice across channels?
Frequent stock updates from a single source cover most cases — an interval of a few minutes is usually enough. Per-channel quotas are only needed at high turnover, where even a short delay causes overselling.
How long does an integration take?
Two to four weeks for a mainstream platform with an existing connector, and most of that time goes into tidying the item master rather than the technical work. A bespoke site or unusual reservation logic extends it.
Should product descriptions and photos live in the ERP?
No. That is storefront content and belongs in the storefront. Maintaining rich product cards inside an accounting system inflates the project and returns nothing in exchange.