When You Run on Several ERPs, Which One Is Right?

The price a B2B customer sees isn't a number. It's the result of a calculation that depends on the store, the brand, the ERP serving that branch, the customer group, the state, the specific commercial contract. In an operation with several brands and several ERPs, the same part can carry legitimately different prices in different contexts — all of them correct.

The problem appears when those contexts have to coexist in a single portal. The customer doesn't want to know that store A runs on one ERP and store B on another. They want the right price, the right stock, the right credit. And that's where the question that breaks everything surfaces: when the systems disagree, which one is right?

Integration isn't wiring systems — it's deciding who's right

The common read treats integration as a plumbing problem: connect the ERP to the e-commerce, map the fields, sync the tables. That's the easy part. The part that breaks comes earlier and isn't technical: defining, rule by rule, which system is the authority over each decision.

Who owns the price when the customer has three different contracts across three brands? Which ERP sets the credit limit for a customer who buys from more than one brand? Is the stock the portal shows the nearest warehouse's or the consolidated figure? These are commercial-governance decisions, not API ones. Until they're made explicitly, each new integration only multiplies the conflicting sources of truth.

This is worth going deeper on — it's the thesis of our anchor piece on ERP and B2B e-commerce integration: integration fails not from badly written code, but from a governance decision that was never made. With multiple ERPs, that effect multiplies.

The cost of not deciding the source of truth

When the source of truth isn't defined, the conflict doesn't disappear — it migrates into the operation. The salesperson confirms prices by phone because they don't trust what the portal shows. The customer gets one price on the site and another on the invoice. Stock says it's there, but it changed between order and picking. Each discrepancy becomes rework, and each rework becomes cost that doesn't show up on the dashboard.

The most expensive symptom is the pricing error. In a multi-brand operation, deriving the wrong price isn't rare — it's the natural state when the rules live scattered, each ERP with its own table and each brand with its own policy. That error rarely shows up in a report: it leaks order by order, as a discount that shouldn't exist or margin undercharged. It's the quietest way for margin to evaporate.

Scale makes the problem invisible — and inevitable

What in a small operation would be coordinated by eye becomes impossible to control by hand at scale. When there are thousands of products, dozens of brands, and hundreds of distinct commercial contracts, "what's the price?" stops having a single answer. Each contract is a rule. Each brand, a policy. Each ERP, a potential source of divergence.

At that volume, the question is no longer "how do I get this price right," but "how do I guarantee the rule runs identically across every context, every time." Manual coordination doesn't scale; a single rule does. It's the difference between firefighting order by order and deciding, once, who has authority over what.

The source of truth isn't the ERP — it's the rule

The shift that unlocks it is to stop asking "which ERP rules?" and start asking "which rule rules?". The ERP stops being the engine of the experience and goes back to what it was always good at being: a data provider. The price, credit, and stock decision is derived by a single, contextual rule that consumes data from the various ERPs without letting any of them dictate the customer's experience.

That's what makes the price coherent across brands, the stock synchronized across warehouses, the credit consistent for a customer who buys from more than one brand. Not because the ERPs were unified — they stay distinct — but because the authority over the decision moved out of them and into a rule layer that applies to all.

When that happens, adding the next brand or the next ERP stops being a rebuild project. It becomes configuration: one more data source wired to the same rule, without rewriting the portal.

What this means for whoever owns the architecture

For a CTO or an operations director, the read is direct: the risk in a multi-ERP operation isn't the technical integration — it's the undecided governance that the integration exposes. Connecting the systems without defining the source of truth doesn't resolve the conflict; it gives it a bigger stage. And each new ERP or brand, without that decision, is one more vector of divergence.

Diagnosis before prescription: before integrating the next system, it's worth mapping, rule by rule, who has authority over price, stock, and credit when two ERPs disagree — because it's in that unresolved disagreement that margin leaks.

Frequently asked questions

Why is integrating several ERPs into a single portal so hard? Because the difficulty isn't technical, it's governance. Each ERP carries its own truth about price, stock, and credit. Without deciding which has authority in each rule, the portal just inherits and amplifies the conflict instead of resolving it.

What does "source of truth" mean in a multi-ERP operation? It's the explicit definition of which system — or which rule — has authority over each decision (price, credit, stock) when the sources disagree. Without it, every new integration multiplies the divergences.

Does adding a new brand or ERP require rebuilding the portal? It doesn't have to, if the source of truth is a single rule rather than each ERP. In that model, the ERP is a data provider, and the next source comes in by configuration — without rewriting the customer experience.

The Cost of Selling is a CWS Platform publication.