A company can sell more and still operate worse.
The usual problem is not a lack of integrations, but an integration that has taken over decisions that should live in the process.
This pattern is common in SMEs that have grown in layers: first an online store, then an ERP, then a marketplace, a CRM, a logistics tool, and finally a web of automations that nobody fully controls. From the outside it looks tidy because “everything is connected”. Inside, the team lives in a chain of exceptions: blocked orders, inventory mismatches, late invoices, misallocated returns, and customers being promised something the back office can no longer support.
My thesis is straightforward: once ecommerce and ERP start shaping the daily operation, the right question is not how to sync more data, but which system should own each decision. If that is not answered, integration stops being an advantage and becomes friction.
The usual symptom: the integration works, but the operation does not
The most common mistake is to measure success by the technical status of the connector. “Orders flow”, “stock decreases”, “invoices are created”. But operations are not judged by whether data moves; they are judged by whether the team can work without constantly slowing sales or creating emergencies.
There are very specific signs that the architecture is wrong:
- Sales promises lead times that logistics later corrects.
- Manual orders are created to bypass system rules.
- The same product has different prices, units, or taxes depending on the channel.
- Available stock depends on batch synchronizations instead of a clear source of truth.
- Every exception requires someone “who knows where to click”.
When that happens, the integration is no longer removing friction. It is hiding it.
What should live in the front end, and what should govern the back office
Not every decision needs the same level of control. A common mistake is giving too much authority to ecommerce because “that is where sales happen”. That works early, but becomes risky as operations scale.
A practical split is often this:
- Ecommerce front end: visible catalog, buying experience, channel promotions, commercial content, and presentation rules.
- ERP back office: committed stock, cost, taxes, picking, invoicing, traceability, credit rules, and operational states.
The issue is not technical. It is governance. If ecommerce decides stock, pricing, and picking priority, the ERP stops being a control system and becomes a delayed mirror. If the ERP imposes too many rules on the front end, the store becomes rigid and commercial agility suffers.
The key is to define who owns each data point and each state. For example:
- Commercial price may originate in ecommerce, but the effective price should be validated in ERP when there are lists, discounts, or channel margins.
- Visible availability may come from an intermediate layer, but committed stock should live in one system only.
- The customer-facing order status can be simplified, but internal workflow must preserve clear operational milestones.
Mini-case: when “sync everything” made distribution worse
A mid-sized distribution company with direct sales and an online channel came in with a classic request: they wanted the ecommerce store to show real-time stock and the ERP to receive every order instantly. The theory was reasonable. The practice was not.
Every stock adjustment triggered a chain reaction: incomplete reservations, partially confirmed orders, and customer service answering questions about orders that had not yet passed operational review. The team had gained apparent speed but lost control.
The fix was not “better synchronization”, but a business rule change. Instead of publishing raw stock, they exposed salable stock with a safety margin by channel. Some high-risk orders also stopped going automatically into picking until a simple validation checked margin, credit, or prior incidents. That reduced impulsive sales in some cases, but it also reduced errors, cancellations, and internal firefighting.
The uncomfortable lesson: sometimes the best integration is the one that accepts a bit of latency or a functional limit in order to protect operations.
The uncomfortable decision: sacrificing immediacy to gain control
This is where many teams hesitate. Better separation between front end and back office usually means giving up something: total immediacy, apparent simplicity, or absolute commercial autonomy.
It is not a popular decision. Sales wants speed. Operations wants certainty. Finance wants traceability. Technology wants a clean architecture. You cannot always maximize all four at once.
The useful question is not “can we sync this in real time?”, but:
- Which error costs us more money: overselling or selling with a small restriction?
- Which data must be exact right now, and which can update in seconds or minutes?
- Which exceptions justify human intervention, and which should be automated?
- Which system is accountable when a discrepancy appears?
If that discussion never happens, the project gets solved with more connectors, more rules, and more operational debt.
What to review before redesigning the integration
Before changing the architecture, review four things:
- Data authority: one system for each critical data point.
- Operational states: define what “confirmed”, “reserved”, “picked”, or “invoiced” actually mean.
- Frequent exceptions: returns, mixed orders, stockouts, price changes, and credit blocks.
- Operational metrics: not only orders created, but the percentage requiring manual intervention, incident resolution time, real stock turnover, and cancellation rate due to integration errors.
When those pieces are clear, integration stops being a patch and becomes a design decision.
The conclusion is simple: in ecommerce and ERP, integrating does not always mean joining more systems; sometimes it means separating better so each system does what it is good at without overrunning the other. That kind of decision is less flashy than a “perfect” connector, but far more valuable operationally. At Codefuente, we usually start with that decision map before proposing technology.