Inventory · 6 min read

Retail Planning and Allocation Software: What the Category Covers

Merchandise planning, assortment, allocation and replenishment are four jobs sold under one heading. Which one your problem actually is, where the handoffs break, and what to test before you shortlist.

Brian Chiou Co-founder, Ward

Sep 25, 2026

See how Ward detects allocations that were right on paper and wrong on the shelf

Get a demo → Take the 3-minute assessment

Contents

Four jobs under one heading
Allocation and replenishment are different problems
The handoffs are where it breaks
Evaluate with a backtest, not a demo
Why good software still makes bad allocations
Five questions for a shortlist

Four jobs under one heading

Retail planning and allocation software decides what to buy, how much, and which store each unit goes to. In practice that heading covers four connected jobs, and vendors cover different subsets of them.

Job	Decides	When
Merchandise financial planning	The money. Sales, margin and open-to-buy by category	Before the season
Assortment planning	Which items each store or cluster carries	Before the buy
Allocation	How a fixed buy is split across stores	At receipt
Replenishment	How much to send next, repeatedly	After demand is observed

A lot of failed selections come from buying a tool built for one of the four when the pain is actually in another. Before you shortlist, write down which of the four rows is costing you money.

Allocation and replenishment are different problems

These two get conflated constantly and they behave nothing alike.

Allocation is a bet. You have a fixed quantity, no demand observed yet, and one chance to place it across stores using forecast, size curve and store grade. Get it wrong and the correction is a transfer or a markdown.

Replenishment is a control loop. Demand has been observed. You have current on-hand, a sales rate and a lead time, and you decide how much to send next. Get it wrong and you correct it next cycle.

Systems designed for one are usually mediocre at the other. A fashion retailer buying a replenishment-first system will find allocation weak, and a grocer buying an allocation-first system will find the replenishment loop crude.

See how Ward detects allocations that were right on paper and wrong on the shelf

Get a demo →

The handoffs are where it breaks

The most common operational failure in this category is not a bad decision inside one module. It is a plan built in one place that the next place cannot execute.

An assortment plan built on 11 store clusters, handed to an allocation system configured for 4.
A size curve maintained in the planning tool and a different one hard-coded in allocation.
Open-to-buy in the financial plan at category level, and buying decisions made at subclass level, with no reconciliation between them.

Whether you solve that with one suite or two integrated tools matters far less than whether you can trace a single item from the financial plan through to what actually shipped to store 118, without anyone rekeying it.

Ask every vendor to walk that trace. Not a demo of each module. One item, end to end.

Evaluate with a backtest, not a demo

Every vendor in this category demos well, because a demo runs on clean sample data where the size curves are tidy and every store is a normal store.

Take one real past season whose outcome you already know. Give each vendor the same buy quantity, the same store list and the same history that was available at the time. Ask what their allocation would have sent.

Then compare three things against what actually happened:

Units that ended up in stores that sold them at full price
Units that needed a transfer
Units that ended up marked down

That test uses your size curves, your clusters and your genuinely weird stores. It is more work than a demo and it is the only thing that separates two vendors who both present well.

Why good software still makes bad allocations

Almost always inputs, not logic.

Store-level on-hand accuracy. An allocation engine given correct rules and stale inventory will confidently ship product to a store that already has it. If your on-hand accuracy is 90 percent at SKU level, that is the project, not the software selection.

Stale size curves. Inherited from three seasons ago, never revisited, and quietly wrong for half the store base.

Cluster definitions nobody reviews. Stores drift. A cluster set built two years ago is allocating on a pattern that no longer holds.

Capacity constraints that exist in the store and not in the system. The bay holds 40 units. The allocation sends 68. The back room absorbs the difference and the shelf looks the same as if you had sent 40.

Fix the on-hand question first. It is the one that makes every other decision in the stack unreliable, and it is not solved by any vendor in this category.

Five questions for a shortlist

Which of the four jobs do you do, and which do you integrate to?
Show me one item traced from financial plan to store shipment.
How do you allocate an item with no sales history?
What happens when a planner overrides you, and what do you do with that override afterwards?
Give me a reference at my store count and format, and let me ask them when they got their first trustworthy number.

See how Ward detects allocations that were right on paper and wrong on the shelf

Ward monitors your stores 24/7 and delivers insight cards, not dashboards. First cards in 48 hours.

Get a demo → More articles

allocation merchandise planning replenishment inventory vendor evaluation

Not sure where AI fits in your operation? Ten questions, about three minutes. Your score out of 100 appears on screen when you finish, with no email required.

Take the 3-minute assessment

Frequently asked

Questions about allocations that were right on paper and wrong on the shelf.

It is the software that decides what to buy, how much, and which store each unit goes to. In practice the heading covers four connected jobs: merchandise financial planning sets the money and the open-to-buy, assortment planning decides which items each store carries, allocation distributes an initial buy across stores, and replenishment keeps the shelf filled afterwards. Some vendors sell all four, some sell one well, and a lot of failed selections come from buying a tool for the wrong one of the four.

Allocation is a one-time distribution decision made before demand is observed, typically for a seasonal or fashion buy where you have a fixed quantity and must place it across stores using forecast and size curve. Replenishment is a repeating decision made after demand is observed, using current on-hand, sales rate and lead time to decide how much to send next. Allocation is a bet, replenishment is a control loop, and systems designed for one are usually mediocre at the other.

Not necessarily, but you do need the handoff to work. The common failure is an assortment plan built in one system that allocation cannot execute, because the cluster definitions or the size curves do not carry across. Whether that is solved by one suite or two integrated tools matters less than whether you can trace a single item from the financial plan through to what shipped to store 118 without rekeying anything.

Take one real past season you already know the outcome of. Give the vendor the same buy quantity, the same store list and the same history, and compare what their allocation would have sent against what you actually sent and what actually sold. That backtest is the only test that uses your size curves, your store clusters and your genuinely weird stores. It is more work than a demo and it is the only thing that separates two vendors who both demo well.

Almost always because of inputs rather than logic. Inaccurate store-level on-hand, a size curve inherited from three seasons ago, cluster definitions nobody has reviewed, and capacity constraints that exist in the store but not in the system. An allocation engine given correct rules and stale inventory will confidently ship product to a store that already has it. Fix the on-hand accuracy question before you blame the engine.

Go deeper on Ward