ERP and ecommerce: the problem is not integration, it is deciding who is in charge when something breaks

An ecommerce business can sell smoothly for months and still quietly damage operations from the inside. The usual pattern is familiar: the catalog looks right, orders flow in, the ERP receives data, and everything seems under control until exceptions appear. Then come partial returns, mid-day price changes, reserved stock, invoices that should not be issued yet, or orders that should never have left the warehouse.

Most integrations do not fail because the technology is weak. They fail because nobody defined which system gets the final word when the process stops being standard.

My thesis is simple: an ERP-ecommerce integration should not be designed as a data bridge, but as an operational decision system. If you do not define who is in charge in each case, you end up with two systems that look consistent on screen and contradict each other in practice.

The usual symptom: everything syncs, but operations are still messy

Many teams assume the problem is the connector quality. Sometimes it is, but rarely that is the main issue. More often the business has accumulated implicit rules that were never documented:

• The ecommerce accepts orders even though stock is already committed elsewhere.
• The ERP corrects prices after the customer has already bought.
• Customer service edits orders without a clear event trail for finance.
• Logistics works with its own statuses that do not match the storefront.

The result is predictable: more internal tickets, more manual adjustments and more meetings just to explain why two screens show different truths.

A very clear signal that the integration is poorly designed is this: if you need to manually review “normal” cases every day, the architecture is no longer supporting the business. You do not need a major incident to notice it. Just count how many exceptions have become routine.

What must be decided before touching the integration

Before discussing APIs, queues or middleware, answer very specific questions. These are not purely technical questions; they are questions of operational governance.

1. Who is the source of truth for each critical data point?

   • Price: ERP, ecommerce or PIM?
   • Available stock: ERP, WMS or an intermediate reservation layer?
   • Order status: sales system or fulfilment system?
   • Customer master: CRM, ERP or ecommerce?

2. Which events are automatic and which need review?

   • A shipping address change may be automatic before dispatch.
   • A price change after payment may not be.
   • A partial order may need a human review queue.

3. What latency is acceptable?

   • Not everything needs real time.
   • Some processes work better with near real-time sync.
   • Others improve when updated in batches, with validation and traceability.

4. What happens when systems disagree?

   • Does the order get blocked?
   • Is it marked pending?
   • Does the ERP rule win and the storefront gets notified?
   • Or is the conflict simply made visible to operations?

The key is to write these decisions before development begins. If you solve them in production, they are no longer decisions: they are patches.

Mini-case: when the connector was not the real problem

In a very typical composite case, a B2B company with ecommerce and ERP thought it needed “a more robust integration”. The symptom was that some orders were confirmed with outdated prices and others were blocked without a clear explanation.

After reviewing the process, the real issue emerged: sales could publish promotional rates in the front end, while finance maintained different rules for customer-specific discounts. On top of that, stock and reservations were updated in different windows. Nobody had defined which system should win when a promotion expired during a shopping session.

The fix was not “sync faster”. Three more useful changes were made:

• A source of truth was defined per field, not per whole system.
• An exception queue was created for price and stock conflicts.
• The team accepted that certain orders should not be fully automated.

The operational outcome was far less flashy than “full automation”, but much more valuable: fewer manual corrections, fewer complaints and traceability that could explain why a given order was treated in a specific way.

The uncomfortable decision: not everything should be real time

Here is one of the most uncomfortable, and most sensible, decisions: some integrations improve when they stop being instant.

That clashes with the instinct of many teams. It feels like if a record takes more than a few seconds, the system is worse. But in real operations, real time can amplify errors:

• If a stock reservation arrives before validation, you can oversell.
• If a promotion propagates without control, you can invoice incorrectly.
• If a status changes automatically without review, you can trigger fulfilment for the wrong order.

Sometimes it is better to introduce an intermediate validation, a queue or a “pending confirmation” state. That is not a rejection of automation. It is a way to avoid turning a small exception into an expensive mistake.

There is also a less popular decision: not every process should be treated the same. A standard order does not need the same level of supervision as a negotiated account, a special condition or a multi-shipment order.

Signals that your integration needs redesign

There are very concrete operational signals:

• The team uses Excel to reconcile orders between systems.
• Support tickets repeat the same three root causes.
• Manual corrections rise exactly when volume rises.
• Finance and operations argue over “which data is correct”.
• Every commercial change requires a small technical intervention.

If this is happening, the problem is not just software. The operating model has fallen behind.

The most useful way to approach an ERP-ecommerce integration is to start with the critical flow, not the tool. Mapping exceptions, defining ownership by data element and accepting that some processes need human control is more effective than adding another automation layer without judgment.

At Codefuente, we usually begin with those business and operations decisions, because they are what determine whether the integration truly helps or just adds elegant complexity.