ERP and Adobe Commerce Integration: Getting Fulfilment and Inventory Right

Most ERP-to-Adobe-Commerce projects are scoped as a connection problem and turn out to be an agreement problem. The technology for moving an order into an ERP has been solved for years. What has not been solved, in your business specifically, is which system is allowed to be right.

This guide covers the decisions in the order you have to make them: what the integration is actually for, which pattern to build it on, how the data should flow for order fulfilment and inventory, and what has to exist afterwards for it to keep working. For the specific ways these integrations fail in production — stock drift, price flapping, duplicate sales orders — the companion piece is Magento-to-SAP Integration: What Actually Breaks.

Start with the outcome, not the object list

The usual first artefact is a list of things to sync: products, customers, orders, stock, invoices. It is the wrong starting point, because it produces an integration that moves everything and improves nothing in particular.

Start instead with the operational problems you are paying to remove. In practice they are almost always drawn from this set:

• Orders are re-keyed into the ERP by hand, which costs staff time and introduces errors.
• The website promises stock the warehouse does not have, producing cancellations and refunds.
• Customers cannot see order status without contacting support.
• Finance reconciles two systems manually at month end.
• Pricing changes reach the storefront late, or reach it twice.

Each of those maps to a specific data flow, a specific direction, and a specific latency requirement. Write down the current cost of each — hours per week, cancellation rate, support ticket volume — before the build. That baseline is what tells you afterwards whether the integration worked, and it is the single most common thing nobody captures.

Then agree the acceptance criteria in the same terms. "Orders appear in the ERP within five minutes with no manual entry" is testable. "Systems are integrated" is not.

Choosing an integration pattern

There are three broad approaches, and the honest answer is that all three work — the failure is choosing on preference rather than on fit.

Two questions decide it more reliably than any feature comparison.

How customised is the ERP? A system that has been extended for ten years rarely matches a connector's assumptions. At that point you are writing transformation logic regardless, and the decision becomes where that logic should live rather than whether to write it.

How many systems will there be in three years? If the answer is "the ERP and the storefront", direct integration is proportionate. If it is "ERP, POS, a warehouse system, and three marketplaces", a hub is worth its cost, because point-to-point connections grow faster than the systems do.

That second case is common in Malaysian multi-channel retail, and it is why we built WOW Sync — Bridzia's marketplace synchronisation technology. For Thunder Match Technology it connected ERP/SAP, the webstore, physical stores, and the major marketplaces so product, price, inventory, and order updates happened once rather than channel by channel, with smart order routing and pooled inventory across warehouse and store locations. TMT reported up to a 3× reduction in the manpower cost of multi-channel order management.

Designing the data flows

Cadence is not one decision for the whole integration. It is a decision per object, and getting it wrong in either direction is expensive — event-driven bulk loads flood the ERP, and batched orders make customers wait.

Three rows in that table carry most of the risk.

Sellable stock is a formula, not a number. What the ERP holds as unrestricted stock is not what a storefront may promise: allocations against open deliveries, blocked and quality-inspection stock, goods in transit, and a safety buffer all sit between the two. Define the formula explicitly with the supply chain team, calculate it on the ERP side, and let the storefront receive one number and do no arithmetic of its own.

Orders must be idempotent. The dangerous failure is not a clean error, it is an ambiguous timeout where the ERP created the document and the storefront never found out. Send a stable reference with every order and have the ERP check for an existing document before creating anything. That is what makes retrying safe, and safe retries are what let you retry aggressively.

Content ownership must be enforced, not assumed. A nightly ERP push that silently overwrites hand-written product copy and meta descriptions destroys real work quietly, and it is usually found weeks later by whoever notices the traffic. Decide ownership per field and make the integration incapable of writing to the fields it does not own.

One further design rule that applies to all of it: keep the ERP off the request path. Nothing in add-to-cart, checkout, or order placement should wait on a system you do not control. Write the order to an outbox in the same transaction that commits it and let a worker transmit it. Checkout stops depending on ERP availability, and every order gains a state you can query.

What tends to go wrong, and the design response

The failure modes are covered in depth in the SAP-specific piece; this is the short form with the structural fix beside each.

• Stock drift between the storefront and the warehouse. Deltas plus a slower full snapshot, timestamped messages, and out-of-order messages discarded rather than applied.
• Prices flapping between two values. One writer per field. The ERP owns base price; the storefront's rule engine computes promotions on top and never writes back.
• Duplicate sales orders after a retry. Idempotency keyed on a stable reference, checked ERP-side before document creation.
• Retry storms making an outage worse. Classify failures into retryable and terminal. Exponential backoff with jitter and an attempt cap for the first; a dead-letter queue and an alert for the second.
• Master data mismatches. A material not extended to a sales organisation, a unit-of-measure difference, a customer with no account. Decide whether a record existing on one side only is skipped, flagged, or blocked from sale — and keep an explicit mapping table keyed on a stable identifier rather than string-matching on SKU.
• Totals a cent apart. Fix decimal precision, rounding direction, and tax base — per line against per document — during architecture, then test with a percentage cart discount across mixed tax rates and a discounted shipping line.

For Malaysian operations, add SST treatment to that last point explicitly: where the tax is applied and how it is represented on both sides has to match, or finance will reject documents for reasons that look like rounding bugs.

Running it after go-live

An integration is not a deliverable, it is a service. The parts that keep it working:

Reconciliation from day one. A nightly comparison of sellable stock and base price across the active catalogue, auto-correcting inside an agreed tolerance and alerting outside it, plus a daily order-level check listing storefront orders with no ERP document and the reverse. The output should be a short report a named person reads. Reports that are usually empty get noticed when they are not.

Monitoring that answers operational questions. Queue depth, message age, failure counts by type, and dead-letter volume — surfaced where support and operations can see them, not only in an engineering dashboard.

A named owner on both sides. Most prolonged integration incidents are organisational: the commerce team and the ERP team each believe the other is investigating.

Change discipline. ERP upgrades, new sales organisations, new product types, and new marketplaces all touch the integration. It belongs in the ERP team's change process, not discovered afterwards.

Load testing before campaign peaks. These integrations behave differently when queue depth grows faster than workers drain it. Decide in advance what degrades when capacity runs short — stock refresh frequency usually loses to order transmission.

Downstream systems inherit whatever the integration produces. Segmentation and lifecycle campaigns built through EC Intelligence are only as good as the order and customer data reaching them, so a half-synced order does not stay an integration problem — it becomes a badly aimed campaign.

Common questions

Should we use middleware or integrate directly with the ERP?

Direct integration is proportionate for two systems with a stable mapping and a team that will own the code. Middleware earns its licence cost once several systems are involved or the mapping changes often. The deciding questions are how heavily customised the ERP is and how many systems you expect in three years.

How long does an ERP integration with Adobe Commerce take?

It is usually the critical path of the overall build rather than a task within it. The variance comes from how customised the ERP is and how quickly per-field ownership decisions get made — not from development speed. Proving one thin end-to-end slice early is the most reliable way to find out what you are dealing with.

Real-time or batch?

Both, chosen per object. Orders, cancellations, shipment updates, and stock movements on fast-moving lines are event-driven. Full product master, stock snapshots, price loads, invoices, and credit memos are scheduled. Treating bulk operations as events produces message volumes the ERP was never sized for.

Who should own product content — the ERP or Adobe Commerce?

The ERP owns identifiers, base price, stock, units, and the customer's financial record. Adobe Commerce owns descriptions, imagery, categories, SEO metadata, and merchandising. Enforce it in the integration rather than trusting a convention.

How do we keep marketplace stock accurate at the same time?

Marketplaces hold their own view of stock and orders, so they are a second synchronisation layer rather than an extension of the first. Solving it centrally — one source of sellable stock feeding every channel — is what stops Shopee, Lazada, and TikTok Shop from drifting independently.

What should we measure to know it worked?

The baseline you captured before the build: manual re-keying hours, cancellation rate from oversells, order-status support tickets, and month-end reconciliation time. Those four moving is what the integration was bought to do.

The short version

Define the outcome before the object list. Choose the pattern on how customised your ERP is and how many systems are coming, not on preference. Decide ownership per field, make sellable stock an explicit formula, make orders idempotent, and keep the ERP off the request path. Then build reconciliation on day one, because every integration drifts and the only question is whether you find out before your customers do.

Bridzia has spent 14 years on Adobe Commerce (Magento), building ERP integrations across Finance, Inventory, and Warehouse modules for retail and FMCG brands across Asia. If you are planning an integration or trying to work out why an existing one keeps drifting, tell us about the project.