ERP and ecommerce integration: how to prevent inventory mismatches, duplicate orders, and manual work

An ERP-to-ecommerce project is often summarized as a two-way connector: products and inventory go to the storefront, while orders return to the business system. That description hides the decisions that make the difference between a reliable operation and a growing list of exceptions.

The hard part is not simply calling an API. It is deciding which system owns each piece of data, how records are identified across platforms, how failures are recovered, and how the team can prove that an operation was processed correctly.

A weak integration may appear healthy for weeks while accumulating silent issues: available inventory no longer matches physical stock, a promotional price is overwritten, a retry creates a second order, payment is confirmed but fulfillment never starts, or a queue stops processing without an alert.

This guide explains the technical and operational decisions that should be made before connecting an ERP to an ecommerce platform. It is platform-independent by design: the same principles apply to B2C, B2B, marketplace, PIM, WMS, payment, and fulfillment environments.

1. Map the operation before mapping API endpoints

Start with the commercial flow from end to end:

Where is a product created?
Which system controls base price, promotions, and customer-specific price lists?
Where is sellable inventory calculated?
When does a cart or order reserve inventory?
At what stage should an order reach the ERP?
Which event authorizes invoicing, picking, and shipment?
How do failed payments, expirations, cancellations, and returns release inventory?
Which system produces tax documents, tracking details, and post-purchase status?

If those rules are unclear, automation will circulate the ambiguity faster. A technical connector cannot compensate for an undefined operational decision.

Warning signs that the current integration no longer fits

teams maintain side spreadsheets to correct stock or pricing;
staff re-enter web orders in the ERP;
support needs multiple systems to determine the real order status;
replaying a job can create duplicate products or orders;
no one can identify the last successfully processed record;
customers report failures before monitoring does;
a small commercial change requires manual edits in several channels.

At that point, integration architecture is not an IT detail. It is a constraint on growth, service quality, and margin.

2. Define a system of record for every entity

Saying “the ERP is the source of truth” is useful but incomplete. An ERP may own fiscal data, stock, and invoicing while the ecommerce platform owns merchandising copy, imagery, and SEO content. Ownership should be defined per entity and, when necessary, per field.

Once ownership is established, writes from consumer systems must be restricted or explicitly reconciled. If the ERP owns price, a manual storefront edit should not survive indefinitely without a documented override rule.

Document direction, trigger, and service level

For every data flow, record:

source and destination;
trigger event;
real-time, scheduled, or batch behavior;
maximum acceptable delay;
required fields and validation rules;
handling of invalid records;
operational owner;
replay and correction procedure.

This is the operational contract of the integration, not just a diagram for the development team.

3. Solve identity before synchronizing data

Internal IDs are local. Product 1842 in the ERP may be product 9631 in the storefront and have another identifier in every marketplace. The integration needs a durable mapping between those records.

Products and variants

Use SKU as a commercial identifier when it is unique, stable, and governed. Every sellable variant should have its own identifier. GTIN can support cross-channel matching, but it does not always replace a company-specific SKU.

Do not match by product name, description, or attribute position. Those values change and produce fragile associations.

A mapping record commonly includes:

tenant or business operation;
source system and source ID;
destination system and destination ID;
SKU and optional GTIN;
mapping status;
last synchronized version or timestamp;
error or review state.

Customers and orders

Email and local tax identifiers may help match customers, but they are not universally stable and they introduce privacy requirements. A shopper may change email, buy as a guest, or use different business and personal identities. Preserve the external identifier issued by each platform.

For orders, retain at least:

internal integration ID;
channel order number;
ERP order ID;
payment transaction ID;
idempotency key;
log and trace correlation ID.

These links are what allow support and engineering to follow one business event across multiple systems.

4. Inventory is a business rule, not a single integer

Physical on-hand stock is not necessarily what a sales channel may offer. A common model is:

available inventory = on-hand stock − reservations − safety stock

The operation may also need to account for inbound stock, blocked lots, multiple warehouses, bundles, components, made-to-order items, backorders, and channel-specific allocations.

Decisions that must be explicit

Does reservation happen at add-to-cart, order creation, or payment confirmation?
How long does a pending bank payment or transfer keep a reservation?
Does a failed authorization release inventory immediately?
Which warehouse serves each region or channel?
Does a bundle decrement the finished SKU or its components?
What happens when two customers attempt to buy the last unit?
Are backorders permitted?
Is safety stock shared or channel-specific?

Prevent feedback loops

A common failure appears when ERP and ecommerce send the same change back to each other. The ERP publishes inventory; the storefront applies it; a webhook interprets that application as a new change and returns it to the ERP.

Track the origin of each update, use reliable versions or timestamps, and ignore events that merely confirm an already-applied state. Ownership rules should make circular writes exceptional rather than normal.

5. Model the order lifecycle explicitly

Do not force every external platform into one flat status list. Each system expresses the lifecycle differently. Build a canonical internal model and map external states to it.

A practical lifecycle may include:

order received;
awaiting payment;
payment confirmed;
queued for ERP;
accepted by ERP;
invoiced;
picking or fulfillment;
shipped;
delivered;
canceled, partially refunded, or returned.

The key distinction is between event received and processing completed. Receiving a payment webhook does not prove that an ERP order exists. Sending an API request does not prove that the ERP accepted and committed it.

Keep transitions, not only current status

Store transition history with timestamp, source, relevant payload data, and result. This provides answers to operational questions:

When was payment confirmed?
How long did the order remain in the queue?
Which attempt created it in the ERP?
Why was the reservation released?
Who canceled or changed the order?
Which status was communicated to the customer?

6. Design for idempotency

Networks fail in ambiguous ways. A caller may send a request, receive no response, and retry even though the first request succeeded. Without idempotency, a retry can create a second order, charge twice, or decrement inventory again.

An idempotent operation has the same effect when repeated with the same identity. A robust implementation should:

generate or accept a unique operation key;
persist that key atomically with the state change;
return the previous result or reject duplicate attempts;
use a unique database constraint when possible;
avoid using only timestamps or full payload hashes as business identity.

For ERP order creation, a useful key may combine tenant, channel, and original order ID. Apply the same principle to payment confirmation, cancellation, refund, shipment, and inventory movement.

Idempotency does not replace database transactions. It protects the boundary between systems; local consistency still needs transactional guarantees.

7. Use asynchronous processing where the customer journey allows it

The storefront should not necessarily wait for every downstream system. After an order is safely accepted, ERP creation can be processed through a queue as long as the status is visible and monitored.

Queues can:

absorb traffic spikes;
protect external APIs from bursts;
isolate checkout from temporary ERP outages;
support retries;
scale workers independently;
preserve evidence of processing.

Retries need classification and limits

Transient failures — timeouts, temporary unavailability, rate limits — may be retried with increasing delays. Permanent failures — unknown SKU, invalid tax data, missing mandatory field — should fail fast and be routed for review.

Use:

a defined maximum number of attempts;
exponential backoff with jitter;
a dead-letter or failed-message queue;
alerts for queue depth and oldest-message age;
controlled, idempotent replay.

Infinite retry is not resilience. It consumes resources and hides invalid data.

8. Validate contracts and normalize formats

Two APIs can exchange JSON while disagreeing about the meaning of every important field. Define explicit contracts for:

currency and rounding;
price and quantity precision;
time zones and date formats;
address and country/region codes;
local tax identifiers;
line-level and order-level discounts;
shipping, tax, duties, and grand total;
simple products, variants, bundles, subscriptions, and services;
nullable fields and defaults.

Keep regional rules at a clear boundary. A Brazilian implementation may need CPF/CNPJ, Pix, boleto, state tax information, and fiscal documents. Other countries may require VAT/GST identifiers, state sales tax, local invoice formats, bank transfer references, or customs data. The core integration should support localization without mixing every regional rule into every workflow.

Version contracts. Adding an optional field is usually safe; changing a status meaning, unit of measure, or monetary total can break consumers silently.

9. Build observability around business identifiers

An integration is not operationally ready if support must query the database to find an order.

Structured logs

Every relevant event should contain searchable fields:

tenant or business account;
source and destination system;
entity type;
external identifiers;
idempotency key;
trace_id or correlation ID;
attempt number;
duration;
outcome and error code.

Do not log credentials, full payment details, or unnecessary personal data.

Operational and business metrics

events received and completed;
error rate by connector;
average, p95, and p99 processing time;
oldest-message age;
retry count;
dead-letter queue size;
reconciliation mismatches;
paid orders not yet accepted by the ERP.

Distributed tracing

When a request moves through an API, queue, worker, and external ERP, correlation IDs allow the same operation to be followed across boundaries. Connecting logs and traces reduces the time required to identify exactly where a flow stopped.

10. Reconcile systems periodically

Delivered messages are not the same as verified business outcomes. Webhooks can be lost, APIs can be unavailable, and users can make manual changes. Real-time integration should be complemented by scheduled reconciliation.

Useful checks include:

paid storefront orders missing from the ERP;
invoiced orders without tracking in ecommerce;
price or inventory differences;
cancellations applied in only one system;
duplicate external order IDs;
events waiting beyond their service-level limit.

Reconciliation may automatically repair unambiguous cases and create a review task for uncertain ones. Reports should show count, business impact, affected records, and action taken.

11. Test failure paths, not only successful orders

A single successful order is not an integration test. Build a scenario matrix:

Also test concurrency, volume, credential expiration, permission changes, worker restarts, and recovery after external downtime.

12. Roll out in stages and keep a rollback plan

A safe migration can begin in read-and-compare mode, with no automated writes. Then enable a limited product group or a small order subset, observe the results, and expand only after reconciliation is stable.

A staged plan may be:

clean and map identifiers;
run initial synchronization;
compare systems without automated correction;
enable catalog and inventory for a controlled subset;
process test orders;
monitor alerts and reconciliation;
increase scope gradually;
retire the previous process only after stability is demonstrated.

The rollback plan must explain how to pause consumers, preserve unprocessed events, restore configuration, and prevent old and new flows from writing simultaneously.

Technical and commercial checklist

Before developing or buying an integration, confirm:

A system of record is defined for every entity.
Products and variants use governed identifiers.
Sellable inventory has a documented formula.
Order states are mapped in both directions.
Critical writes are idempotent.
Retry policy separates transient and permanent errors.
Failed messages can be inspected and replayed safely.
Logs allow support to locate an order without database access.
Metrics and alerts cover delay, error, and divergence.
Reconciliation compares business outcomes.
Staging represents real operational scenarios.
Credentials, permissions, and personal data are protected.
Deployment and rollback are documented.

Reliable integration is an operational capability

A strong integration does more than move data when every dependency is available. It prevents duplicates, survives temporary outages, exposes failures, and supports recovery without improvisation.

AGTI designs and evolves sales platforms, ERP integrations, and automation for B2C and B2B operations. If inventory differences, order exceptions, or manual work are limiting your ecommerce operation, we can map the current flow and turn business requirements into an executable architecture.

CTA: Talk to AGTI about your integration

Technical references

AWS — Retry with backoff pattern: https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html
Stripe — Idempotency in API requests: https://docs.stripe.com/api-v2-overview
OpenTelemetry — Log correlation: https://opentelemetry.io/docs/specs/otel/logs/
Google Analytics — Ecommerce measurement: https://developers.google.com/analytics/devguides/collection/ga4/ecommerce