ERP and ecommerce: when to split systems

There is a scene that repeats itself in many SMEs: the operations team sees an order marked “confirmed” in the online store, but the warehouse cannot pick it, finance does not yet treat it as billable, and customer support is already answering the customer with a promise nobody has validated. At that point the sales channel is not failing; the operating model is.

The problem is rarely that ERP and ecommerce do not “talk.” The problem is that they talk too much about things they should not decide on their own.

The usual debate is framed badly: integrate or split. That sounds technical, but it is really a governance decision. When a company binds ERP, ecommerce, logistics and support too tightly together, it gains speed at first and loses clarity as soon as exceptions appear: partial allocations, returns, substitutions, special pricing, B2B orders with different terms, or products with real stock spread across multiple locations.

The signal that integration is hiding the problem

You do not need an outage to see that the design is not holding up. There are better signals:

• The team keeps saying “we can see it in the ERP” or “commerce will fix it.”
• One order needs three manual checks before it can be closed.
• The same data gets corrected in two systems depending on who calls first.
• Support handles issues that are really inventory, pricing or status decisions.
• Reports reconcile at month end, but not during the week.

When those signs appear, integration is no longer improving the flow; it is masking it. The common mistake is asking for more automation or more connectors when what is missing is a clear definition of which system owns each order state, stock state and invoice state.

When splitting systems genuinely improves operations

Splitting does not mean returning to duplicated data chaos. It means accepting that not every layer should move at the same pace or carry the same authority.

Splitting the front from the back office makes sense when:

• ecommerce changes often because of campaigns, UX or catalog updates;
• the ERP needs accounting stability, traceability and exception control;
• there are multiple sales channels with different rules;
• incident handling needs autonomy from commercial promises.

A very typical composite case: a company sells spare parts and technical supplies online, while also serving distribution orders with negotiated pricing. For years it tried to force everything through the ERP. The result was a rigid system: every storefront change had to touch internal rules that also affected invoicing, returns and availability.

After separating responsibilities more cleanly, the team kept catalog and commercial experience in the front end, while the back office retained control over committed stock, shipping and invoicing. They did not eliminate issues, but they reduced the number of ambiguous decisions. The improvement came not from integrating more, but from deciding better what had to stay independent.

The uncomfortable choice: less automation, more useful friction

Here is the part that makes many teams uncomfortable: sometimes the right answer is not more automation, but a bit of friction.

That can mean:

• manual approval for high-risk orders;
• intermediate states that are visible instead of a too-optimistic “confirmed” label;
• different rules for available stock, committed stock and publishable stock;
• an exception path for returns instead of treating them as just another order type.

From the outside this looks less efficient. In practice, it stops the company from making promises it cannot keep. Automation only pays off when exceptions are tightly bounded. Otherwise speed simply multiplies mistakes.

The useful question is not “can we automate this?” The real question is: “what becomes irreversible if this flow fails?” That is where the architectural criterion appears.

How to decide with discipline, not technology impulse

Before changing the integration, answer four questions:

1. Which system should be the source of truth for each data point: price, stock, order, invoice, return?
2. Where is the highest cost when something fails: sales, warehouse, finance or support?
3. Which exceptions are frequent, and which are genuinely rare?
4. Which team needs autonomy to operate without blocking the rest?

If a company cannot answer those questions, it is probably buying a future argument. The problem will not be “the integration.” It will be disagreement about who had the authority to decide.

A good sign of maturity is that the system absorbs predictable errors without creating artificial urgency. Not everything needs to be unified; every part needs clear limits and exceptions need to be handled where they make sense.

At Codefuente, we usually find that the best architecture is not the most integrated one, but the one that leaves the fewest implicit decisions. In ecommerce, that often makes the difference between operating with control and spending the day correcting orders by hand.