Retail ERP vs a decision layer: what each does

Every retailer past a certain size runs on an ERP. It holds the stock numbers, the purchase orders, the supplier terms, the financials — the operational truth of the business. So when the stock decisions aren't working — too many stockouts, too much markdown — the instinct is to ask what's wrong with the ERP. Or which ERP to move to next.

Usually, that's the wrong question. A retail ERP is doing exactly what it's built to do; the gap is in a layer most stacks don't have. This article draws the line between what a retail ERP is for, where it stops, and what a decision layer adds on top. That way you can tell which problem you actually have.

What a retail ERP is

A retail ERP (enterprise resource planning) is the system of record that runs a retailer's core operations on one data model. It typically covers inventory and stock movements, purchasing and supplier management, order management, finance and accounting, and often merchandising and store operations. Its job is to hold the authoritative version of what is true — how much stock exists, what's on order, what was sold. And to execute the transactions that change it.

That's an enormous, essential job. Before ERPs, this data was scattered across disconnected systems that disagreed with each other. The ERP's core value is one source of truth: everyone reads the same numbers, and the transactions are recorded consistently. Everything downstream — reporting, planning, execution — depends on that record existing and being reliable.

So a retail ERP is transactional and record-keeping by design. It answers "what is true, and record this change." It is not built to answer "what should we do next."

What a retail ERP does well

Used for what it's for, a retail ERP is indispensable, and the strengths are real.

One source of truth. A single, consistent record of stock, orders, and finance that every function reads. This alone justifies the ERP — inconsistent data is a tax on every decision.

Transaction execution. When a decision is made — order this, receive that, transfer these — the ERP is what actually executes and records it. It's the rails the business runs on.

Process automation. Standardized workflows for procurement, receiving, invoicing, and returns, so routine operations run consistently at scale without reinvention each time.

Compliance and control. Auditable records, financial controls, and governance — the unglamorous backbone that keeps a large retailer legal and accountable.

If your problem is "our data is fragmented and our processes are inconsistent," a retail ERP is the answer, and a good implementation pays for itself.

Where a retail ERP stops

The limits aren't defects — they're the edge of what a system of record is for. Three matter when your problem is stock performance rather than data consistency.

It records the number; it doesn't decide the move. An ERP knows a store has 4 units and 30 on order. It does not decide whether to reorder, transfer from another store, or mark down. Those are arbitrations against demand, supplier minimums, store roles, and markdown calendars that the ERP holds no logic for. This is the same reason retail data stays useless without a decision layer on top of it.

The decision logic lives outside it. Because the ERP doesn't decide, the deciding happens in exported spreadsheets, bolt-on planning tools, and planners' heads. The ERP shows the state; a human turns state into action, SKU by SKU. That works until the volume — tens of thousands of SKU/store pairs — outgrows what humans can touch.

It executes what it's told, correctly, even when the instruction is wrong. An ERP will faithfully place a reorder that violates a rule nobody encoded, because enforcing that rule was never its job. The correctness is transactional, not decisional. Getting the transaction right is not the same as getting the decision right.

None of this is a knock on the ERP. It's the definition of a system of record — and it's exactly why the decision layer is a separate question.

Retail ERP vs a decision layer

The clearest way to see it is side by side. A retail ERP is a system of record; a decision layer is a system of decision. They answer different questions and, in a healthy stack, they complement each other.

The ERP holds the state and executes transactions. The decision layer reads that state and decides the SKU/store moves — reorder, transfer, allocate, mark down — against your business rules. It hands the executable action back to the ERP to run.

One is the source of truth; the other is the source of the next action. This is the same architecture as WMS vs a decision platform and the broader data stack vs decision stack distinction. The operational systems record and execute; the decision layer decides between them.

Crucially, a decision layer does not replace the ERP. It sits on top, consumes its data, and makes the ERP's execution smarter by feeding it better instructions. Replacing your ERP to fix a decision problem is solving the wrong layer — often at enormous cost.

How to tell which you need

The useful diagnostic is to name the problem precisely.

If your pain is fragmented data, inconsistent processes, or manual transaction handling — different systems disagreeing, no single stock truth, procurement run on email — that's an ERP problem. A retail ERP (or a better-implemented one) is the right investment.

If your pain is decisions, the ERP won't fix it. The signs: your data is fine and the numbers agree, but planners override the reorder suggestions and stockouts and markdowns persist. The "right" move is obvious in hindsight, yet never made in time. That's the gap a decision layer fills, and it's the same reframe behind inventory planning as a chain of decisions rather than a record to maintain. Most retailers at scale have a solid ERP and an empty decision layer — which is why the numbers are clean and the performance still leaks.

The Solya angle

Solya is the decision layer, not another ERP. It's built to sit on top of the system of record you already run and do the one thing the ERP was never designed to: decide.

Solya connects to your ERP, POS, and supply chain systems and rebuilds a live SKU/store view of the network on the data layer. The intelligence layer reads that state continuously and frames the real decisions — reorder, transfer, allocate, mark down. Your business rules are embedded, so the output isn't a number to interpret but a move that's ready to execute. The orchestration layer then writes the cleared decision back into the ERP and downstream systems, so a decision becomes a purchase order or a transfer without a planner re-keying it. That's continuous replenishment running on top of your ERP, not instead of it.

The point is complementarity. Your ERP keeps doing what it's great at — recording and executing. Solya adds the layer that decides what to execute, closing the gap between a correct record and a good decision. For the integration questions this raises, see how IT directors integrate decision engines.

The bottom line

A retail ERP and a decision layer aren't competitors — they're different jobs. The ERP is your system of record: it holds the truth and runs the transactions, and no serious retailer operates without one. But it doesn't decide, and a system of record can't be blamed for a decision gap it was never meant to fill.

So before you blame the ERP or shop for a new one, ask which problem you have. If the data's a mess, fix the ERP. If the data's clean and the decisions still don't happen, no ERP will save you — you're missing the layer that decides on top of it.

---

Is your gap the ERP, or the decisions on top of it?

At Solya, we offer retail supply chain and IT leaders a 30-minute diagnostic. It places your problem correctly — system of record or system of decision — on your own stack. You'll walk away with:

• A clear read on whether your gap is data/process (ERP) or decisions (decision layer)
• Where SKU/store decisions are leaking value outside your ERP today
• The first decision loops worth closing on top of your existing system of record