ERP Integration for E-commerce: What It Actually Costs
Shakewell ·
Ask three agencies to quote an e-commerce build and the storefront numbers will be broadly comparable. The integration numbers will not. One will be a third of another, and the gap is almost never about who is cheaper — it is about what each of them assumed when nobody specified it.
ERP integration is where commerce projects go over budget. Not because it is unusually difficult, but because it is unusually easy to scope badly.
The four questions that set the price
Everything else is detail.
1. How many objects, and in which direction? Products, prices, stock, customers, orders, invoices, credits. Each is a separate piece of work. Each direction is a separate piece of work again. “Sync the ERP” can mean a one-way nightly product feed or eleven bidirectional object mappings, and the difference between those two is an order of magnitude.
2. How fresh does each object have to be? Not the system — each object. Prices might be fine overnight while stock needs to be minutes old. Treating freshness as one global setting is how projects end up paying real-time prices for data nobody needed in real time.
3. Does the ERP already have a usable API? This is the question with the widest cost variance. A modern ERP with a documented REST API is straightforward. An older on-premise system where the supported integration route is a nightly file drop onto an SFTP server is a different project — still perfectly workable, but the architecture, and the price, are decided by that constraint rather than by anything on the commerce side.
4. Who owns the ERP? If changing a field requires a ticket to a third party with a two-week turnaround, that is not an administrative detail. It is the critical path.
Real-time is usually not the requirement
Almost every brief asks for real-time. Almost none need it.
Real-time integration means the storefront calls the ERP while rendering a page. That makes every page view dependent on a system designed to answer a few hundred queries from staff, not thousands from the internet. It is slower, it is more fragile, and it makes an ERP outage into a shop outage.
The genuine cases are narrow and identifiable: stock that sells out within minutes of going live, or negotiated pricing that can change during the trading day. Trade businesses hit the second one more often than retailers do — when pricing lives in the ERP and a contract is renegotiated, the website showing yesterday’s rate is a commercial problem, not a cosmetic one.
For everyone else, the useful question is: what actually goes wrong if this data is four hours old? If the answer is nothing, you have just removed the most expensive requirement on the list.
A middle path covers most businesses well: scheduled sync for the bulk of the data, event-driven updates for the handful of things that genuinely cannot wait, and a cached last-known-good value the storefront can always fall back to.
What nobody scopes, and everybody needs
Failure behaviour. If the ERP is unreachable, does the shop keep trading? A good integration caches, degrades gracefully and queues writes for replay. A bad one returns an error to a customer holding a full basket. This is a genuine cost line and it is the first thing cut when a quote needs to look competitive.
Reconciliation. Two systems holding the same numbers will disagree eventually — a failed job, a timeout, a manual edit someone made directly in the ERP. What matters is whether you find out from a report or from a customer. A daily reconciliation job that flags divergence is unglamorous and repeatedly earns its cost.
Idempotency. If the same order is sent twice because a job retried, does the ERP create two orders? Getting this wrong produces duplicate financial records, which is the most expensive class of bug to unpick because it is discovered in accounting rather than in engineering.
The data quality you already have. Integration does not clean your catalogue. If product data is inconsistent, an integration faithfully replicates the inconsistency into a second system, at speed. This is why we push product information work ahead of integration work rather than after it.
Where it lands in practice
Two shapes we work on illustrate the range.
Duty free retail is the demanding end: prices and tax that vary by location and traveller, inventory that must be accurate in real time across multiple physical stores, and sales exported into SAP. The Aelia Duty Free platform does this across seven airports in two countries. The hard part there is not the export — it is that inventory has to be trustworthy across locations, because a traveller buying against a boarding call has no tolerance for a stock error.
Trade supply is the other shape. When contract pricing lives in an ERP, the website is not the source of truth for the most commercially sensitive field on the page. That constrains the architecture in a way retail rarely does, and it is one of the reasons B2B commerce is a different discipline rather than retail with a login on top.
What to do before you ask for a quote
- List the objects and directions. Literally a table: object, direction, source of truth.
- Put a freshness requirement against each row — and justify anything you mark real-time.
- Find out what the ERP’s integration surface actually is. API, middleware, file drop. Ask the vendor, not the sales deck.
- Name who can change things in the ERP, and how long that takes.
An hour on that table will change the quotes you receive more than any other hour you spend on the brief — and it lets you compare agencies on the same assumptions instead of discovering three months in that everyone assumed something different.
If you want a second opinion on an integration already being scoped, that is a conversation we are happy to have.
Common questions
How much does ERP integration cost for an e-commerce site?
It varies more than any other line item on a commerce project, and the honest range is wide enough that quoting it blind is meaningless. What moves the number is not the ERP brand — it is how many objects sync, in which direction, how fresh they must be, and whether the ERP already has a usable API. A one-way nightly product and price feed is a fraction of the cost of bidirectional real-time inventory and order sync. Scope those four things before asking anyone for a price.
Do we need real-time ERP integration or is nightly sync enough?
Most businesses that ask for real time need same-day. Real-time calls at page view are slower, more fragile and considerably more expensive, because every page load becomes dependent on a system that was never designed to answer thousands of web requests. The genuine cases are narrow: stock that sells out within minutes, or contract pricing that changes intraday. A useful test is to ask what actually goes wrong if the data is four hours old — if the answer is nothing, you have your answer.
What happens if the ERP goes down?
This is the question that separates a robust integration from a fragile one, and it is rarely asked during scoping. If your storefront calls the ERP synchronously to render a page, an ERP outage takes the shop down with it. A well-built integration caches the last known good values, degrades to those when the ERP is unreachable, and queues writes rather than dropping them. That resilience is a real cost line, and it is worth paying.
Can you integrate with SAP?
Yes. The duty free platform we run for Aelia Duty Free exports sales into SAP across seven airport stores in two countries. SAP integrations are not harder than others in principle, but they are usually governed by more people — access, middleware and change control tend to sit with a separate team, and that coordination is a real part of the timeline rather than an administrative footnote.