Merchandise Allocation and Replenishment Software: Getting Units to the Right Stores When Packs and Size Curves Fight Back

Why allocation quietly strands a third of a buy

A 12,000 unit buy lands at the distribution centre. The vendor ships assorted prepacks in a one two two one ratio across small, medium, large and extra large. Your allocator has 340 stores, a presentation minimum of two units per size per store, a store grading spreadsheet from last season, and a chain average size curve that was calculated in 2021. The allocation goes out. Six weeks later, sell through looks acceptable at chain level and is a disaster underneath: extra large sold out in the four stores that always sell extra large, small is sitting in 180 stores, and the medium units that would have sold are in the wrong half of the estate. Markdown fixes it, expensively, and the season review records it as a buying error.

It was not a buying error. The buy was probably fine. The units went to the wrong doors because three mechanical problems were handled by approximation: the size curve was chain level rather than store level, pack rounding was resolved by whoever was doing the spreadsheet, and presentation minimums fought need based demand with no rule to arbitrate. Allocation is the least glamorous link in merchandising and it decides where a season's inventory physically sits.

The vendors here are real. Oracle Retail Allocation is capable and proven. Blue Yonder covers allocation within a wider suite. RELEX Solutions is genuinely strong in grocery replenishment. Impact Analytics comes at it with more modern forecasting. What sends retailers toward a build is usually one of two things: a size and pack structure that the packaged model handles awkwardly, or the fact that allocators still spend their week on data entry inside a system that was meant to remove it.

Problem 1: the size curve is a store level fact and everyone uses a chain average

Size demand varies by store far more than most retailers assume, and it varies for reasons that persist: local demographics, whether a store serves a commuter or family trade, climate driving layering, and the simple fact that a store which has been out of extra large for two years has taught its extra large customers to shop elsewhere. That last point is why raw sales history lies: a store's history shows what it sold, not what it could have sold, and a size that was never in stock looks like a size nobody wants.

What a real build does: estimate size curves per store per category using a statistical approach that borrows strength across similar stores where a single store's data is thin, and correct for lost sales during out of stock periods rather than treating stock outs as demand signals. This is a well understood problem in statistics and it is exactly the kind of work worth paying for, because the alternative is a chain average that is wrong in most stores by construction. The output should be reviewable, with an allocator able to see why a store's curve differs and to override it with a recorded reason.

Problem 2: pack rounding is where the maths meets a cardboard box

You cannot ship 3.7 units. Vendor prepacks arrive in fixed ratios, case packs have inner packs, and some categories ship solid packs by size while others ship assorted. The allocation engine must decide, per store, which whole packs to send such that the resulting size mix is as close as possible to that store's need, while respecting minimums and not exceeding available units.

What a real build does: treat this as the constrained optimisation problem it actually is, minimising deviation from the target size profile across the estate subject to pack integrity and inventory availability. The naive approach, allocating ideal units then rounding to packs store by store, accumulates error and typically leaves units unallocated at the end of the run or over ships the largest stores. It is also worth modelling the pack decision before the buy, because a prepack ratio that fits no cluster is a purchasing decision that guarantees stranded inventory before a single unit ships. That feedback loop from allocation back into buying rarely exists and is one of the more valuable things a build can add.

Problem 3: presentation minimums and need based allocation are in permanent conflict

A store must display an item credibly or it may as well not carry it, which argues for minimums. But minimums applied uniformly across 340 stores consume a large share of a buy on stores that will never sell through, which is need based allocation's objection, and it is correct too.

What a real build does: make the arbitration explicit rather than accidental. Minimums per store grade and per fixture type, a rule for what happens when the buy cannot fund minimums everywhere, and a documented preference for whether the chain protects presentation or protects sell through in that category. Fashion and basics deserve different answers. The important part is that the rule is visible and can be changed once, rather than being resolved differently by each allocator each week.

Problem 4: replenishment is a different algorithm and gets bolted onto the same spreadsheet

Initial allocation distributes a finite buy. Replenishment maintains a position against ongoing demand with lead times, review cycles and a distribution centre that periodically holds less than the sum of what stores need. Those are different problems, and running the second with the first's logic is why stores that sold well get starved after week four.

What a real build does: proper replenishment with per store per item target stock derived from forecast demand, lead time and a service level you choose, plus fair share rationing when distribution centre inventory cannot satisfy total need. Fair share is the part most spreadsheets get wrong: they fill store requests in sequence until stock runs out, so the last stores in the list get nothing regardless of how well they sell. Rationing proportionally to need, with a floor that keeps a presentation minimum intact, changes the outcome materially in exactly the weeks when a product is working.

Problem 5: allocators rekey all week and review nothing

The most common finding when we sit with an allocation team is that the skilled part of their job, judgement about which stores deserve a push, occupies perhaps a fifth of their week. The rest is exporting, pasting, formatting and re importing.

What a real build does: run the allocation automatically and present exceptions, meaning the stores and items where the engine's answer is unusual, where a constraint was violated, where a store has been out of stock repeatedly, or where an allocator's override last week produced a worse result. The allocator reviews perhaps 60 decisions instead of building 340 rows. This is also the only route to a smaller team handling a larger estate, which is usually the business case that funds the project.

The output then needs to become purchase orders and distribution centre work. Allocation that produces a spreadsheet for the warehouse to interpret introduces a second point of failure, so wave picking and store fulfilment integration belong in scope rather than in a later phase.

Where AI helps and where it is decoration

The statistical work is genuine and worth paying for: store level size curve estimation with shrinkage across similar stores, lost sales correction during stock outs, and demand forecasting that feeds replenishment targets. These are established techniques with measurable outcomes, and they are what actually stops units stranding.

What does not earn its place is a conversational layer over allocation. Allocators do not want to chat with a system, they want to see 60 exceptions with reasons and act on them. Be sceptical of any vendor whose allocation demonstration is a chat window rather than a size curve per store.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this category prices as follows. A focused first release covering store level size curves, pack aware allocation optimisation, presentation minimums and exception based review runs $80,000 to $180,000 and ships in 14 to 20 weeks. A full platform adding replenishment with forecasting and fair share rationing, in season store transfers, purchase order generation and distribution centre wave integration runs $220,000 to $550,000 phased over 8 to 14 months.

What drives cost up specifically in allocation: multiple distribution centres with cross docking, since sourcing decisions multiply the optimisation. Categories with genuinely different logic, because grocery replenishment and fashion size allocation share almost no rules. Warehouse system integration, where wave picking, carton building and store fulfilment need real work rather than a file drop. And history quality, since size level sales history with reliable stock out flags is the input everything depends on, and many retailers discover theirs is incomplete.

What keeps cost down: one distribution centre, one category group and initial allocation only for release one, with replenishment following once the size curves are trusted.

Build versus buy, and when the vendors win

Buy, and mean it. If you are a grocery or high frequency replenishment business, RELEX Solutions does forecasting and replenishment at a level that would take years to reproduce, and building instead would be a serious mistake. If your structure is conventional and you already run Oracle Retail, Oracle Retail Allocation integrates natively and that integration is worth a great deal. Blue Yonder is credible where allocation sits inside a broader supply chain programme. Impact Analytics is worth a look where forecasting quality is the primary complaint.

The fair limitation of packaged allocation is fit around packs, sizes and your particular constraint set. These systems express the constraints they were designed to express, and if your vendor pack structures, store grading model or presentation rules sit outside that, you end up exporting to a spreadsheet to finish the job, which reproduces the original problem inside a more expensive system.

Build when two or more of these are true. Your size and pack structure is complex enough that packaged tools require regular manual finishing. You already have clean sales history in a data platform, which removes the largest cost. Your categories differ enough that no single vendor model fits both halves of the business. Allocation headcount is growing faster than store count. Or you have implemented a packaged allocation system and your team still exports to Excel every week, which tells you the fit failed regardless of what the contract says.

How to choose a developer for allocation and replenishment software

Ask how they would estimate a size curve for a store with thin history and known stock outs. If the answer is average the last two years of sales, they will encode your existing errors and call it a system. The right answer mentions borrowing strength across similar stores and correcting for lost sales.

Ask how pack rounding is solved. If they describe allocating ideal units and then rounding store by store, expect unallocated remainders and over shipped flagships. The correct framing is a constrained optimisation across the estate.

Ask what an allocator's Monday looks like after go live. If the answer does not include a specific number of exceptions to review, the team will keep exporting to Excel and you will have bought a report.

Ask who owns the code and get it in writing before kickoff, including the repository, the cloud accounts and the forecasting models trained on your sales history. At Digital Heroes the client owns all of it from the first commit. Models built on your own demand data are among the most valuable assets a retailer creates, and they should never sit in a vendor's account.