When Every Location Makes Decisions Differently, the ERP Stops Being a Control System and Becomes Just a System of Record

TL;DR

• In an operation with 40 business units, multiple ERPs, and different commercial terms, the problem was not the local systems. It was the absence of a common set of rules above them.
• An ERP executes and records transactions. It does not necessarily govern pricing, credit, and product catalogs based on the customer, region, and timing of each deal.
• Replacing every system can increase risk without addressing the source of inconsistency. The alternative is to separate the system of record from the system of decision.
• Local autonomy can be preserved as long as each unit operates within centralized, explicit, and auditable rules.

Does Your ERP Control the Operation, or Does It Merely Record Decisions Made Elsewhere?

For the CEO of a multi-location B2B company, fragmentation rarely appears first as an architecture problem.

It shows up in margins that fluctuate without a clear explanation, credit limits interpreted differently across locations, product catalogs that vary by channel, and commercial terms that depend on who is available to approve them.

The most immediate diagnosis usually points to the systems: multiple ERPs, layers of accumulated integrations, and unique requirements at each business unit. The conclusion seems logical—standardize everything on a single platform.

But a public case identified as LI-042 suggests a different interpretation. The company had 40 business units, multiple ERPs, and different commercial terms at each location. According to the account, this was not a disorganized operation. What it lacked was a layer above the local systems to define what was allowed.

Each ERP fulfilled its execution role. None had been designed to govern the others.

That distinction changes the investment decision. If the problem is treated solely as technology fragmentation, the organization may begin a large-scale replacement project without answering the central question: Who consistently determines which price, credit terms, and product catalog apply to each transaction?

The Conflict Is Not Between Centralization and Autonomy

Pricing, credit, and product catalogs are not static data. In case LI-042, all three depended on who was buying, where they were buying, and when the transaction occurred.

That means a centralized pricing table alone does not solve the problem. The organization must connect context with commercial policy before a location executes the terms.

Without that capability, two extremes become common:

• Corporate headquarters attempts to centralize every exception, creating approval backlogs and dependencies.
• Local business units gain freedom without shared guardrails, increasing variation and reducing traceability.

Neither extreme produces effective governance. Centralizing every action slows down frontline teams. Decentralizing the rules makes outcomes unpredictable.

In case LI-042, the company implemented an orchestration layer above its existing ERPs. The local systems were neither replaced nor migrated. They continued to serve as each location’s system of record, while the orchestration layer centralized commercial and financial rules.

Before offering specific terms, each location consulted this layer. The response already reflected what was authorized for that customer, region, and point in time.

The reported result was greater consistency without eliminating local autonomy where it was needed.

Systems of Record and Systems of Decision Serve Different Purposes

The ERP records inventory, orders, and the other operational effects of a transaction. Commercial governance must act earlier, while the customer’s purchase intent is still being converted into a viable offer.

This is where the questions relevant to the board emerge:

• Is the price consistent with the policy for that customer and sales channel?
• Does the available credit support these terms?
• Does the offered product catalog match the region and purchasing context?
• Has the exception been authorized?
• Can the decision be reconstructed later?

The CWS Platform article “Your ERP Is Not the Problem” makes the same distinction: the ERP serves as the system of record, while a governance layer determines pricing, credit, and approvals before the order is confirmed.

The architecture, therefore, does not need to compete with installed systems. It needs to define what those systems are authorized to execute.

Slow Sales Cycles Can Also Be an Architecture Problem

The absence of formalized rules does more than create inconsistency. It turns every deal into a sequence of manual inquiries.

Another public case in the collection, identified as LI-038, describes an operation where responding to a quote request took five business days. The process required checking a price list, verifying inventory, requesting credit approval, and confirming lead time by email.

According to the case, once pricing, credit limits, and exceptions were formalized within a digital workflow, the cycle dropped from five days to minutes—without replacing the sales rep and without requiring human intervention in most situations.

The comparison makes the diagnosis more precise. The bottleneck was not a lack of effort from the team. The commercial logic existed, but it was distributed across people, spreadsheets, and informal approvals.

When a decision depends on who is available, the org chart becomes part of the technology infrastructure. To grow, the company must add people who can interpret, validate, and connect the rules. Revenue may increase, but complexity and operating costs increase with it.

The Cost of Inaction

Postponing the separation between systems of record and systems of decision does not leave the operation in a neutral state. It keeps material business decisions outside a common governance framework.

The effects tend to appear in fragmented ways:

• Different commercial terms for equivalent situations.
• Response times determined by the availability of sales reps and managers.
• Exceptions without a clear approval history.
• Expansion into new locations accompanied by more inquiries and approvals.
• Difficulty distinguishing legitimate autonomy from policy violations.
• ERP replacement projects used to address a gap that does not originate in transaction recording.

The financial risk is not limited to one incorrect set of terms. It lies in the repetition of small decisions made without a central reference point, making it difficult to measure their cumulative effect on margin, credit exposure, and productivity.

There is also an opportunity cost. While leadership debates a potential systems replacement, the business continues to negotiate every day through the same informal channels.

Principles for Reorganizing Commercial Decision-Making

• Diagnose before migrating: Determine whether the failure lies in the ERP or in the absence of a common policy layer above it.
• Separate rules from execution: Local systems can execute transactions without owning all commercial logic.
• Centralize policies, not every action: Frontline teams should act autonomously within predefined guardrails.
• Formalize what currently depends on individual experience: Pricing, credit, product catalogs, and exceptions must be translated into explicit rules.
• Preserve context: A centralized rule should not ignore the customer, region, channel, or timing of the transaction.
• Record the decision, not just the order: The organization must know which policy authorized each set of terms.
• Establish governance before automating: Accelerating a workflow without clear criteria only makes inconsistency happen faster.
• Prepare for responsible AI adoption: AI can expand analytical and response capacity, but it must operate on verifiable rules, permissions, and records.

FAQ

Do the ERPs at each location need to be replaced?

Not according to case LI-042. The existing ERPs were preserved as local systems of record. The change was the addition of a higher-level layer to govern commercial and financial rules.

Does centralized governance eliminate local autonomy?

Not necessarily. In the reported case, the organization gained consistency without giving up local autonomy. The difference was that each action occurred within the boundaries authorized for that specific context.

Does a single price list solve the problem?

Not when pricing, credit, and product catalogs depend on the customer, region, and timing. The organization needs rules capable of interpreting those factors before execution.

Is automating approvals enough?

No. Approval criteria, authority levels, and exceptions must be formalized first. Automation should execute defined governance, not substitute for policy definition.

From Those Already Facing This Challenge

On the public Capterra website, Rodrigo S., a Sales Manager, summarizes the relationship between commercial governance and existing infrastructure:

“The platform unified our sales channels and integrated with our ERP without replacing it.”

Source: Capterra