What Is Merchandise Planning Software?
Merchandise planning software is the system a brand or retailer uses to decide how much to invest in inventory, which products to carry, how deep to buy them by size and pack, and where to place them.
Merchandise planning software is the system a brand or retailer uses to decide how much to invest in inventory, which products to carry, how deep to buy them by size and pack, and where to place them, holding those decisions as one connected plan rather than as separate files. It is the system of record for the merchandise financial plan, the open-to-buy, the assortment, the buy plan and the allocation. Everything else a planning team touches, from the ERP that posts the receipts to the dashboard that reports the sell-through, either feeds that plan or reads from it.
This guide defines the category. It covers what the software replaces and why that stack breaks; the seven planning modules and the data layer they share, with the question each one answers; the grain and horizon each module works at; who uses it by role and what each role sees; how it differs from its neighbours, ERP, PLM, demand planning, space planning, business intelligence and the spreadsheet; the three architectures a buyer meets; what "AI-assisted" honestly means in this category; what the software has to handle natively in each of ten retail verticals; the signals that a brand has outgrown spreadsheets; and how to run an evaluation. It is the software companion to what is merchandise planning?, which defines the discipline the software serves as five stacked plans.
What the software is for
The discipline comes first. Merchandise planning is a stack of linked decisions about the money, the options, the depth, the timing and the placement of inventory, made before a season and remade during it. In a spreadsheet-run business those decisions exist, but they exist as files: a top-down budget in one workbook, a line list in another, an open-to-buy in a third, a size grid in a fourth, an allocation sheet in a fifth. Merchandise planning software exists because the decisions are linked and the files are not. Change the option count in the assortment and the open-to-buy should move; it does not until someone opens it and carries the change across. Slip a receipt a month and the stock-to-sales ratio in that month should change; it does not until the file is rebuilt.
So the simplest honest description of the category is this: a merchandise planning system holds every layer of the plan on one data model, so that a change made at one layer reaches the others as a matter of structure rather than as a matter of someone remembering. The glossary calls this connected planning. What a planner experiences is narrower and more useful: the number on the screen is the current number, there is one plan rather than several, and the week's review is spent on the decision rather than on agreeing which file is right.
Three things follow from that description, and they shape everything else in this guide. First, the software is only as good as the merchandise hierarchy and calendar underneath it, because every module plans against the same tree of departments, classes and styles and the same weeks. Second, the system is a system of record for decisions, not for transactions; it tells the ERP what to order and reads back what arrived, but it does not post the invoice. Third, the modules are not optional in the discipline even when they are optional in the product: a brand that buys an assortment tool without an open-to-buy still has an open-to-buy, it just lives in a spreadsheet, and the reconciliation problem lives with it.
What it replaces, and why that breaks
Most brands evaluating this category are not replacing another planning system. They are replacing a stack of workbooks that grew up around the business, one season at a time, each one owned by the person who built it. The replace spreadsheets page sets out the cost of that stack in detail, and this guide will not re-argue it. The short version matters for the category definition, though, because what the software replaces defines what it must do.
The spreadsheet stack breaks in four places, and each one maps to a module below. The open-to-buy is stale because receipts and sales are keyed in after the fact, so the buyer is spending against a position that is a week or a month old. The assortment and the buy drift apart because a style added to the line sheet does not appear in the buy plan until it is typed there, and a quantity cut in the buy does not flow back to the assortment's option count. The size breakdown is re-keyed between the plan, the purchase order and the allocation sheet, and each re-keying is a chance for the run to be flattened onto a default ratio. And the in-season reforecast is skipped, because rebuilding the model takes longer than the week it is meant to describe, so the plan of record is the pre-season plan until the season is over and it is too late to act.
The failure modes are structural, and the fix is structural: one model, one hierarchy, one calendar, every layer reading the same actuals. That is the category.
The modules, and what each one decides
The category is best understood as seven planning modules and a shared data layer. Products package them differently, a point taken up in the architecture section, but the decisions are the same in every product and in every spreadsheet stack, because they are the decisions the discipline requires. The table gives the one-line version; the subsections give what each module actually decides and what it hands to the next.
| Module | The question it answers | Denominated in | Hands downstream |
|---|---|---|---|
| Merchandise financial planning | How much will we sell, at what margin, holding how much stock? | Dollars (retail and cost) | Sales, margin and inventory targets by period |
| Open-to-buy | How much can we receive each period and still hit the stock target? | Dollars by month or week | A receipt budget per period |
| Assortment and range planning | Which options will we carry, in which channels and clusters? | Options and style-colors | A ranged line with planned depth |
| Item and buy planning | How many units of each option, at what cost, from whom, landing when? | Units and committed dollars | A buy plan ready to become purchase orders |
| Size and pack planning | How is each buy split by size, and how is it packed? | Units by size | Size breakdowns and pack configurations |
| Allocation and replenishment | Which doors and channels get which units, and how are they refilled? | Units by location | Allocations, replenishment orders, transfers |
| In-season reforecast and markdown | What has changed, and what do we do about it this week? | All of the above, re-planned | A revised plan of record and a markdown calendar |
Merchandise financial planning: the top-down layer
The financial plan sets the targets everything else has to add up to: sales by period, gross margin, the inventory needed to support the sales, and the turn that implies. It is planned top-down, from the company's budget to the division to the department, and reconciled against a bottom-up build from the categories. The output is not a buy; it is the frame the buy has to fit. The glossary entry on the merchandise financial plan covers the line items. What the software adds is that the frame is live: when the bottom-up build is edited, the top-down variance shows immediately, and when the season starts, the same plan becomes the reference the actuals are read against rather than a document filed in March.
Open-to-buy: the receipt budget
The open-to-buy converts the financial plan into money that can be spent on receipts in each period, by taking the planned end-of-period stock, adding planned sales and planned reductions, and subtracting the stock already on hand and on order. It is the control that stops a brand over-buying against a sales plan that has not materialised. In a workbook it is the file most often stale; in a planning system it is the module most often connected, because every buy committed in the item plan and every receipt posted from the ERP should relieve it in the week it happens. The open-to-buy entry gives the arithmetic; the OTB planning page describes it as a live workflow rather than a periodic reconciliation.
Assortment and range planning: the options
The assortment is the plan denominated in options: how many styles and style-colors in each class, at which price points, for which channels and store clusters, and with what planned depth and planned exit. It is where the brand's point of view meets the financial frame, because the option count is constrained by the open-to-buy and the minimum presentation a door needs, while the mix is a merchandising judgement about good-better-best, core and seasonal, carryover and new. Range planning is the same decision seen from the wholesale side, where the range is what accounts can book from. The software's job is to keep the option count and the financial frame in the same view, so that adding a colorway shows what it costs in depth or in another option, and to carry the ranged line forward into the buy without re-entry. The assortment planning page covers this module.
Item and buy planning: the commitment
The buy plan turns options into quantities, costs, vendors and delivery dates. It is the first layer that becomes a commitment outside the business, because it is what the purchase order is built from, and it is where landed cost, minimums, vendor splits and channel splits are applied. A planning system holds the buy against the open-to-buy continuously, so that a buy rounded up to a factory minimum shows as spend against the period it lands in, and it carries the buy's size breakdown and channel split through to whatever system owns the purchase order rather than leaving them to be re-keyed. The buy planning page describes this module as quantities by style, color, vendor and channel with the open-to-buy reconciled in real time.
Size and pack planning: depth by size
Size planning decides how a buy is split by size, usually from a size curve built on prior sell-through at the class or style level and adjusted for the door cluster. Pack planning decides how those units are packed for shipment and for allocation, whether as prepacks in a fixed ratio or as open stock picked by size. It is the module most often missing from a spreadsheet stack, where a single default ratio is applied to everything, and it matters because a style whose middle sizes sell out in week three is broken at full price while the unit count still reads healthy. The size and pack optimization guide covers the method; the point for the category is that the size breakdown has to survive every handoff intact, from the plan to the order to the allocation.
Allocation and replenishment: where the units go
Allocation decides which doors and channels receive which units of a buy, pre-season and as receipts land; replenishment decides how continuing items are refilled against a target stock or a rate of sale. Allocation reads the size curve by cluster, the door's capacity and the channel split decided at the buy; replenishment reads the sales rate, the lead time and the presentation minimum. In a connected system both read the same stock and sales actuals as the open-to-buy, so that an in-season transfer or a replenishment order is visible to the planner as spend and to the allocator as units. The allocation page covers the module; allocation and replenishment best practices covers how it is done well.
In-season reforecast and markdown: re-planning the open season
The seventh module is not a separate plan so much as all the others done again with actuals in them. The in-season reforecast re-plans sales, receipts and stock for the remaining weeks of a season from what has actually sold, decides whether to chase, cancel, transfer or mark down, and resets the open-to-buy for the periods still open. Markdown planning decides when, how deep and where to take reductions, and books them against the planned reductions line the financial plan assumed. The reason this is the module that separates a planning system from a planning workbook is that the reforecast is only possible if rebuilding the plan is cheap. When the plan lives on one model with live actuals, re-planning the season is a weekly task; when it lives in five workbooks, it is a project. The in-season chase and how often to reforecast cover the practice.
The data layer and the hierarchy they share
Underneath the seven modules sits what makes them one system rather than seven: the merchandise hierarchy, the calendar, the location hierarchy and the actuals. The merchandise hierarchy is the tree from division to department to class to style to style-color to SKU, and every module plans at some level of it and rolls up or spreads down through it. The calendar is the retail week structure the plan is phased on. The location hierarchy is channel, region, cluster and door. The actuals are sales, stock, receipts and on-order, read from the ERP and the sales channels and attached to the hierarchy at the lowest grain they exist at. A product record, usually mastered in a PLM or in the planning system's own product module, carries the attributes the hierarchy and the assortment need. The product data page describes that record as maintained once and used everywhere. A planning system with a weak hierarchy is a set of calculators; the data readiness guide covers what has to be true of the data before the modules can do their work.
Grain and horizon: where each module works
The modules differ not only in what they decide but in how fine and how far ahead they decide it, and the differences explain why one workbook could never hold them all. The financial plan is coarse and long; allocation is fine and short. A planning system holds all of them on one hierarchy and one calendar so that the coarse plan constrains the fine one and the fine actuals roll up into the coarse review. The table below is the planning grain each module typically works at. It describes how planning work is organised, not a specification any product must meet.
| Module | Typical product grain | Typical location grain | Typical time grain | Horizon |
|---|---|---|---|---|
| Merchandise financial planning | Department or class | Total company, channel | Month or season | A year or more ahead |
| Open-to-buy | Class or department | Channel | Month, sometimes week | The season plus the next |
| Assortment and range planning | Style and style-color | Channel and cluster | Season, with delivery drops | One to two seasons ahead |
| Item and buy planning | Style-color, SKU for sizing | Channel split | Delivery or drop | One season ahead, by lead time |
| Size and pack planning | SKU (size within style-color) | Cluster | Buy | With the buy |
| Allocation and replenishment | SKU | Door | Week | Weeks ahead, rolling |
| In-season reforecast and markdown | Style-color up to class | Door up to channel | Week | The remaining weeks of the season |
Two things in the table deserve a sentence each. The buy is planned at style-color but committed at SKU, because the factory needs a size breakdown, which is why size planning sits with the buy rather than with allocation. And the reforecast spans the whole grid, from the door-week where the sell-through is read to the class-month where the open-to-buy is reset, which is why it depends on the shared hierarchy more than any other module does.
Who uses it, by role
Merchandise planning software is used by six roles, and a good way to understand the category is to ask what each one sees when they open it. The role names move between businesses, and in a small brand two or three of them sit in one chair, but the views are stable.
The merchandise planner owns the financial plan, the open-to-buy and the in-season reforecast. The planner sees the plan against actuals at class and department by week and month, the receipt budget by period, the stock-to-sales position and the variance to the top-down frame. The planner's week is the reforecast: what moved, why, and what the open-to-buy for the remaining periods should now be.
The buyer owns the assortment and the buy. The buyer sees the line by class and price point, the option count against the frame, the planned depth and exit for each style-color, the vendor, cost and delivery for each buy, and the open-to-buy position the buy is spending against. In wholesale-led businesses the buyer also sees the range and the account bookings against it.
The allocator owns the distribution of units. The allocator sees stock and sales by door and SKU, the size curve by cluster, the receipts landing this week and where they should go, replenishment orders and transfers. The allocator's grain is the finest in the system and the horizon the shortest.
The merchandiser owns the shape of the range against the brand's story, which in some businesses is the buyer's job and in others sits between design and buying. The merchandiser sees the assortment as a line, by collection, fabrication and silhouette as well as by class, and reads the financial contribution of each part of it. The platform page describes planning by collection, category and fabrication group as well as by department.
Finance reads the plan as a commitment of cash and a forecast of margin. Finance sees the financial plan against the budget, the open-to-buy as planned spend by period, the committed buys as liabilities, and the markdown reserve. Finance does not plan options and should not have to open a line sheet to find the number.
Design and product development read the line plan the assortment is built from, the option slots it leaves open, the target costs the buy has to meet, and the carryover decisions that determine which styles continue. The product development page describes line sheets, colorways, costing and sample tracking sharing one product record with planning and buying.
The reason the roles matter to the category definition is that the handoffs between them are where spreadsheet stacks break: the planner's open-to-buy and the buyer's buy, the buyer's size breakdown and the allocator's curve, the merchandiser's line and design's slots. A planning system is one in which those handoffs are the same number seen from two chairs.
How it differs from its neighbours
A search for merchandise planning software returns its neighbours as often as itself, because every system in a retail business touches the plan somewhere. The table draws the lines; two of them are drawn in detail in companion guides. Supply chain software vs. merchandise planning software separates the plan from the systems that develop, make, move, store and record the product, and space planning vs. merchandise planning separates the plan from the store it has to fit into. This guide does not restate them.
| System | What it decides or records | What it does not own | Where it meets merchandise planning |
|---|---|---|---|
| Merchandise planning software | What the business will own: money, options, depth, timing, placement | Transactions, the product specification, the floor | It is the plan |
| ERP | Orders, receipts, invoices, stock on hand, the ledger value of inventory | What to buy next and how much | The purchase order going out and the receipt and sale coming back |
| PLM | How the product is made: tech pack, bill of materials, samples, cost versions | How many to buy, where to place them | The product record and the cost the buy is planned on |
| Demand planning / supply chain planning | How much of an existing item will sell, and how supply should meet it | What to carry in the first place, the season's option mix | Replenishment of continuing items; the forecast baseline |
| Space planning | Where merchandise physically goes and how much room each category and item gets | What to buy and how much money to put behind it | Fixture capacity as a constraint on option count and depth |
| Business intelligence | Reporting and analysis of what happened, across any data | A plan; BI reads, it does not hold a plan of record | Hindsight and in-season reads that feed the reforecast |
| Spreadsheets | Whatever the owner builds; often the whole plan, one layer per file | Connection between layers, a shared hierarchy, concurrency | Spreadsheets are the incumbent; the category replaces them |
Three distinctions get confused most often and are worth a paragraph each.
ERP and planning. An ERP can carry a budget and some carry a planning module, which is why an ERP vendor appears in a search for planning software. The test is what the system is the record of. The ERP is the record of what happened: the order placed, the goods received, the sale rung. Planning software is the record of what is intended: the receipt budget, the ranged line, the buy before it is an order. A business needs both, and the integration between them, the buy plan going out as purchase orders and the receipts and sales coming back as actuals, is the single most important interface in the category.
Demand planning and merchandise planning. Demand planning software forecasts how much of an existing item will sell, usually at item-location-week grain, to drive supply decisions. Merchandise planning software decides what to carry in the first place and how much money to put behind it, at the grain of a category, a season and an option, much of it before the item exists to be forecast. The two meet at replenishment of continuing items, where a forecast feeds the reorder, and they diverge at seasonal product, where the decision is made once, from a plan, before there is any sales history. Demand vs merchandise vs supply planning covers the three disciplines.
BI and planning. A reporting layer can show sell-through by style, door and week beautifully, and many brands that search for planning software already have one. What BI does not do is hold the plan the actuals are compared against, or let the planner change it. A dashboard that shows a style is behind plan is reading a plan that lives somewhere else, and in a spreadsheet-run business that somewhere is a file. Planning software holds the plan of record and shows the actuals against it in the same place, which is why the intelligence page describes in-season performance as built into where planning decisions happen rather than in a separate dashboard.
The three architectures buyers meet
Products in this category are packaged in three ways, and the packaging matters as much as the feature list because it decides who implements the system, who maintains it and what has to be integrated. The descriptions below are neutral: each architecture is the right answer for some businesses. The selection guide covers how to match them to a brand's size and market.
A suite module is a planning component inside a larger enterprise platform, usually one that also carries the ERP, the supply chain or the retail operations stack. Its strength is that it shares the suite's data model and governance, so the integration to the transaction record is already built, and the vendor relationship is one the business already has. Its cost is that planning is one module of many, the planning depth is sized for the suite's general customer rather than for a vertical's grain, and the implementation is usually a programme scoped and contracted separately from the licence, delivered with an integration partner. It suits a business that already runs the suite, has the team to configure it and values one vendor above planning depth.
A point solution does one module, most often assortment planning, size and pack, or allocation, and does it in depth, integrating with whatever holds the rest of the plan. Its strength is depth: a point solution for size curves will model sizing more finely than a suite ever will. Its cost is the reconciliation it leaves behind, because the open-to-buy, the buy or the financial plan still live somewhere else, and the handoff into and out of the point solution is one more place for the layers to drift. It suits a business whose other modules are already well served and whose pain is concentrated in one layer.
A connected platform holds the planning modules on one data model built for planning, sitting between the product record and the transaction record and integrating with both. Its strength is the connectedness this guide has been describing, from the financial frame to the allocation on one hierarchy, and a planning depth built for the vertical it serves. Its cost is that it must integrate on both sides, to the PLM or product source above and the ERP and sales channels below, and that it is a new system rather than a module of an existing one. It suits a business whose pain is the reconciliation between layers and whose product grain, size runs, shades, finishes, is not well served by a general model.
| Architecture | Strength | What it trades | Who implements | Fits when |
|---|---|---|---|---|
| Suite module | Shared data model and governance with the transaction record | Planning depth; vertical grain; a separately scoped rollout | Integration partner, with the business's IT | The business already runs the suite and has the team |
| Point solution | Depth in one module | Reconciliation with the other layers | Vendor, often light | Pain is concentrated in one layer and the rest is well served |
| Connected platform | All modules on one planning data model | Integration on both sides; a new system | Vendor-led or buyer-led, depending on the product | Pain is reconciliation between layers and the grain is vertical |
Two further observations. The implementation model, vendor-led, integrator-led or buyer-led, follows the architecture more often than it follows the vendor, and it decides who controls the cost of change for the life of the contract. And the architecture a brand needs is set by where its reconciliation pain is, not by its revenue: a large business with one broken layer is a point-solution buyer; a smaller one whose layers all drift is a platform buyer.
What "AI-assisted" honestly means here
Nearly every product in the category now describes itself as AI-assisted, and a buyer is entitled to ask what that means for the work. In merchandise planning it honestly means three things, and the questions to ask vendors guide has a question family for testing each.
Forecast baselines. The system builds a starting forecast from the brand's own history, seasonality and, where it exists, the item's own rate of sale, and offers it as the baseline the planner adjusts rather than a blank cell the planner keys from zero. For continuing items, a core program, a carryover model, a replenished shade, this is the most useful thing the software does, because the history is real and the adjustment is small. For a new seasonal style with no history, the baseline is an analogue, a like-item or class average, and it is a starting point for a product judgement, not a replacement for it.
Exception surfacing. The system reads the actuals every week and flags the styles, sizes, doors and weeks that have moved away from plan, so that a person looks there first. This is the practical form of the in-season reforecast: a planner cannot read every style-color-door-week, and does not need to, if the system surfaces the ones that matter. The intelligence page describes AI-assisted anomaly detection as automatic flagging of unusual patterns in sell-through, inventory and margin; the value is in where the planner's attention goes.
Scenario comparison. The system holds two or more versions of a plan, a deeper buy on a hero style against a broader range, a markdown now against a markdown in three weeks, and shows their financial consequences side by side on the same hierarchy. This is possible without any model at all; what the shared data model adds is that the scenarios are cheap to build and compare, which in a workbook they are not.
What it does not mean is as important to say. It does not mean the decision is taken for you. The option mix, the depth on a style nobody has sold before, the markdown on a style that is the brand's story, and the vendor split are judgements, and the software's job is to put the right numbers next to them. It does not replace the product judgement on a style with no history, because there is nothing for a model to learn from. It does not make a plan built on a bad hierarchy or late actuals good; a baseline computed from mis-attributed sales is a confident wrong number. And it does not change the arithmetic of the open-to-buy, which is the same with or without a model behind it. A buyer who is shown a recommendation should ask what history it was built from, what it does on a new style, and how the planner overrides it; the answers separate assistance from decoration.
What the software has to handle natively, by vertical
The seven modules are the same in every retail vertical. What differs is the grain the product is planned and committed at, the clock the season runs on and the constraint that binds the buy, and a planning system that does not carry a vertical's grain natively forces the planner to flatten it, usually in a spreadsheet beside the system, which recreates the problem the system was bought to solve. The subsections below are short on purpose; each vertical has its own planning guide.
Apparel
Apparel plans at style, commits at style-color and sizes at style-color-size, across two or more seasons a year with delivery drops inside each, and splits most buys across DTC, wholesale and stores. The software has to hold the style-color-size grain natively, carry a size curve by class and cluster, plan by collection and fabrication as well as by department, run a seasonal open-to-buy with carry-forward stock between seasons, and keep channel splits inside one buy. Fabric minimums bind the colorway count upstream of the buy, and the fabric minimums guide covers that constraint. The apparel brands page sets out the apparel case.
Footwear
Footwear multiplies the unit. A model-color is bought as a size run in sizes, half sizes and, where the model offers them, widths, so a men's run from 7 to 13 in half sizes is 13 sizes, and in two widths it is 26 SKUs per model-color, where an apparel style-color in a six-size range is six. The system has to plan pairs by size within width, keep the run intact through the order and the allocation, and hold the model year as a planning dimension beside the season, because carryover models continue across seasons and the changeover is a line decision. Factory minimums can apply per model-color or per size tier and have to be visible when the run is sized. Assortment planning for footwear brands covers the depth arithmetic; see also the footwear brands page.
Accessories and bags
Accessories plan on style-colors rather than size runs, so the multiplier is the colorway and the hardware finish, and much of the range is unsized or lightly sized. The system has to hold colorway and finish as attributes the assortment plans on, carry an evergreen core that replenishes on a rule beneath a seasonal layer bought once and exited, and read attach, the rate at which an accessory sells with a garment or a shoe, as a planning input rather than an afterthought. Material minimums at the tannery or component supplier bind the colorway count. Planning accessories lines covers the hero-color arithmetic; see also the accessories brands page.
Home and furniture
Home and furniture plan SKUs with long lead times, often committed a season or more ahead, shipped by ocean in containers whose minimum can set the order rather than the style's demand, and configured as options, a frame in several finishes, fabrics or sizes, that multiply the SKU count without multiplying the floor sample. The system has to carry option and finish as a planning grain, hold the container as a constraint on the buy, plan the floor set as the decision about which options are shown, and net dealer and trade program orders written at market against the buy. Landed cost moves with freight on bulky goods, so the cost the margin is planned on has to come from logistics actuals. Merchandise planning for home and furniture brands covers the mechanics; see also the home and furniture brands page.
Outdoor
Outdoor plans on the model year rather than the season alone, with a large wholesale channel that prebooks the line at a sales meeting months before delivery, so the production buy is sized from the dealer prebook and the at-once stock held back for fill-in is a decision rather than a residual. The system has to hold the prebook position against the buy, carry the model year as a dimension with carryover models continuing across it, and plan the DTC and wholesale demands for the same style on different clocks. Weather drives the in-season read more than the calendar does. Merchandise planning for outdoor brands covers the model-year rhythm; see also the outdoor brands page.
Sporting goods
Sporting goods run several seasons at once, one per sport, each with its own start, peak and end, so the open-to-buy has to be phased by sport rather than by a single retail calendar, and the assortment is a set of sport-specific ranges that share a store but not a season. The system has to carry seasonality by sport, hold prebook from team and institutional accounts alongside retail demand, plan hardgoods with sizes of their own, racquets, bats, boots, beside softgoods with apparel sizing, and read the in-season chase against a sport's window that does not move. Merchandise planning for sporting goods brands covers the multi-season structure; see also the sporting goods brands page.
Beauty
Beauty plans shade ranges, a foundation in dozens of shades, a lipstick in a dozen, where the range is bought and replenished as a set, because a missing shade reads to the customer as the product being unavailable. Much of the business is replenished rather than bought once, so the system has to run replenishment natively, and the depth a slow shade can be held is bounded by shelf-life dating that lives in the ERP or batch system rather than in the plan, so the planning system has to read it rather than own it, and it has to plan around the retailer's gondola resets and promotional calendar, which set when a range can change on shelf. Launches are planned as events with a pipeline fill. Merchandise planning for health and beauty brands covers shade-range planning; see also the health and beauty brands page.
Toys and games
Toys concentrate demand in a gifting peak at the end of the year, so the financial plan and the open-to-buy are shaped by a few weeks, and the buy is committed far ahead of them with little chance to chase. Licensed product runs in windows tied to a film or a franchise, with a start and an end the brand does not control and royalty terms that change the margin. The system has to phase the plan around the peak, hold the licensed window as a planning attribute with its own exit, and plan the post-peak markdown as part of the buy rather than as a surprise in January. Merchandise planning for toy and game brands covers the peak; see also the toys and games brands page.
Baby and juvenile
Baby and juvenile demand is driven by the registry and the due date, so a portion of demand is visible months ahead in a way no other vertical enjoys, and a portion is replenished on a steady rate because the product is consumed as the child grows. The system has to read registry demand as a planning input, run replenishment on core items natively, carry size as an age or stage range rather than a body measurement, and handle safety recalls, which can remove a SKU from sale in a day and require the plan, the allocation and the open-to-buy to absorb the hole at once. Merchandise planning for baby and juvenile brands covers registry demand; see also the baby and juvenile brands page.
Jewelry and watches
Jewelry and watches plan on a precious-metal cost base that moves between the buy and the sale, so the margin the plan is built on has to be re-read against the metal price, and the turn is slow, with pieces held across seasons and model years rather than cleared at the end of one. The system has to carry the metal and stone content as cost drivers, plan a model year with carryover as the default rather than the exception, hold low depth per SKU across many SKUs without treating slow turn as a markdown signal, and plan the gifting peaks that concentrate demand. Merchandise planning for jewelry and watch brands covers the cost base; see also the jewelry and watch brands page.
The pattern across the ten is the same: the vertical sets the grain, and the software either carries that grain natively or pushes it back into a spreadsheet. A buyer evaluating the category should test the system on their own grain, pairs by size within width, shades in a range, finishes on a frame, before anything else.
How a brand knows it has outgrown spreadsheets
The moment to move is not a revenue figure. It is a set of signals about reconciliation, and a brand that recognises most of them has outgrown the spreadsheet stack whatever its size.
- A change no longer reaches the other files. A style added to the assortment or a quantity cut in the buy does not appear in the open-to-buy until someone carries it there, and sometimes it never does.
- Two versions of the plan exist and a meeting is spent agreeing which is right before any decision is made.
- The size breakdown is re-keyed between the plan, the purchase order and the allocation sheet, and the run is flattened onto a default ratio somewhere along the way.
- One person is the only one who knows how the workbook works, and the plan stops when they are away.
- The in-season reforecast happens late or not at all, because rebuilding the model takes longer than the week it describes, so the pre-season plan is still the plan of record in the last month of the season.
- The open-to-buy is read a week or a month stale, because receipts and sales are keyed in after the fact, and the buyer is spending against a position that has already moved.
- The finance view and the merchandising view disagree about the same season, because they were built in different files from different extracts.
- Design, merchandising and buying hold three line lists, and the one that reaches the factory is not the one that was reviewed.
A brand with two or three of these has a process problem that better workbook discipline might fix. A brand with most of them has a structural problem, and the fix is structural. The mid-market page describes the brands that most often sit at this point: large enough that the layers have separated, not large enough for an enterprise programme.
How to evaluate it
Four companion guides cover the evaluation, and each is summarised in a paragraph here rather than repeated.
The selection guide sets out a six-step process: define the problem being solved before touching a demo, understand the three platform markets, mid-market, enterprise and PLM-led, and which one the brand belongs to, evaluate the vertical-specific capabilities the brand's grain needs, assess the implementation reality, evaluate total cost of ownership over the life of the contract rather than the licence, and evaluate how sell-through data gets in. Its central point is that most products are built for one of three markets, and knowing which the brand is in narrows the field before any feature is compared.
The vendor questions guide gives five question families that do most of the qualification work, data model, implementation model, workflow fit, AI and proof, with the questions written to be asked in a fifteen-minute conversation at a trade show or on a first call. Its central point is that the data model questions, whether open-to-buy, assortment and buy planning are one data model or modules that synchronise, what the open-to-buy view shows when a buyer revises the assortment mid-review, and how two versions of the plan are reconciled, separate a planning system from a synced set of modules faster than any feature demonstration.
The build vs. buy guide sets out when building an internal planning tool is right and when it is not, the cost of building that is left out of the first estimate, maintenance, iteration and opportunity cost, the middle path of a platform with customisation, and how to migrate off an internal tool once it has been outgrown. Its central point is that the question is rarely whether the team can build it but whether the business wants to own it for a decade.
The implementation model guide separates the three models, vendor-led, integrator-led and buyer-led, and gives five questions that price each, from who configures a hierarchy change a year after go-live to what leverage the buyer holds at renewal. Its central point is that the implementation model, more than the licence, decides who controls the system's cost of change for the life of the contract.
Three best-of pages round out the evaluation with category-level comparison: best merchandising software for apparel, best assortment planning tools and best apparel planning software.
Where RetailNorthstar fits
RetailNorthstar is a merchandise planning platform in the connected sense described above. The platform page describes six connected pillars, Canvas visual line boards, product development, merchandising planning, buying and vendor execution, intelligence and product data, and the merchandising planning page describes the planning core as open-to-buy, assortment planning, buy planning and allocation connected in a single platform, so that changes to the assortment update the buy plan and changes to the buy plan update the open-to-buy position, with no manual reconciliation between files. It describes apparel-specific capabilities, size curves, seasonal open-to-buy, collection structure and multi-channel buys, as native to the platform, and it is designed for mid-market and growing apparel brands that have outgrown spreadsheet-based merchandising planning.
The evaluation guides above apply to RetailNorthstar as much as to any other product in the category, and a brand should run them against it. Which modules a brand needs, at what grain, under which architecture and implementation model, are questions this guide is meant to help answer before any demonstration, this one included.
Related resources
- What Is Merchandise Planning? — the discipline the software serves, as five stacked plans
- Supply Chain Software vs Merchandise Planning Software and Space Planning vs Merchandise Planning — the boundaries on either side of the plan
- How to Choose Apparel Planning Software, Questions to Ask Planning Software Vendors, Build vs. Buy and How to Evaluate the Implementation Model — the evaluation
- Merchandise Financial Plan, Open-to-Buy, Merchandise Hierarchy and Connected Planning — the terms
- Replace Spreadsheet Planning — the stack the category replaces
See how RetailNorthstar connects OTB, assortment, buy planning and allocation on one data model — the planning layer between your product record and your transaction record.
Start Free Trial →No credit card. No commitments.
Common questions
What is merchandise planning software?
Merchandise planning software is the system a brand or retailer uses to decide how much to invest in inventory, which products to carry, how deep to buy them by size and pack, and where to place them, holding those decisions as one connected plan rather than as separate files. It is the system of record for the merchandise financial plan, the open-to-buy, the assortment, the buy plan and the allocation. It replaces the spreadsheet stack in which each of those decisions sits in its own workbook and every change has to be carried into the others by hand.
What modules does merchandise planning software include?
Seven planning modules and a shared data layer. Merchandise financial planning sets the top-down sales, margin and inventory targets; open-to-buy converts them into a receipt budget by period; assortment and range planning decides the options; item and buy planning turns options into quantities, costs and vendor commitments; size and pack planning decides depth by size and how it is packed; allocation and replenishment decides where units go and how they are refilled; in-season reforecast and markdown re-plans the open season and spends its reductions. The data layer holds the product hierarchy, the calendar, the location hierarchy and the actuals every module reads.
Who uses merchandise planning software?
Planners, buyers, allocators, merchandisers, finance and design each work in it at a different grain. The planner owns the financial plan, the open-to-buy and the in-season reforecast. The buyer owns the assortment and the buy, option by option. The allocator owns the distribution and replenishment of units across doors and channels. The merchandiser owns the shape of the range against the brand's story. Finance reads the plan as a cash and margin commitment and compares it with the budget. Design and product development read the line plan that the assortment is built from and the costing targets the buy has to meet.
How is merchandise planning software different from ERP and PLM?
Merchandise planning software decides what the business will own; the ERP records what it has bought, received, sold and still holds, and the PLM holds how each product is made. A planning system reads product records from the PLM and transactions from the ERP, holds the plan against them, and hands a buy plan back to be turned into purchase orders, but it does not post to the ledger and it does not hold the tech pack. If the pain is a decision not yet made well, it is a planning problem; if the pain is a decision already made that is not being carried out or recorded, it belongs to the ERP, the PLM or the systems between them.
What is the difference between merchandise planning software and demand planning software?
Demand planning software forecasts how much of an existing item will sell, usually at item-location-week grain, to drive supply decisions. Merchandise planning software decides what to carry in the first place and how much money to put behind it, at the grain of a category, a season and an option, much of it before the item exists to be forecast. The two meet at replenishment of continuing items, where a forecast feeds the reorder, and they diverge at seasonal product, where the decision is made once, from a plan, before there is any sales history.
What does AI-assisted mean in merchandise planning software?
In this category it honestly means three things: a forecast baseline built from the brand's own history that the planner adjusts rather than keys from zero; exception surfacing, where the system flags the styles, sizes, doors and weeks that have moved away from plan so a person looks there first; and scenario comparison, where two or more versions of a plan are held side by side with their financial consequences. It does not mean the decision is taken for you, it does not replace a product judgement on a style that has no history, and it does not make a plan built on bad product data good.
How do I know my brand has outgrown spreadsheets for merchandise planning?
The signals are about reconciliation rather than size. A change to the assortment no longer reaches the open-to-buy or the buy plan without someone carrying it there by hand. Two people hold two versions of the plan and a meeting is spent agreeing which is right. The size breakdown is re-keyed between the plan and the purchase order. One person is the only one who knows how the workbook works. The in-season reforecast happens late or not at all because rebuilding the file takes longer than the week it describes. When those are routine, the brand has outgrown the spreadsheet stack whatever its revenue.
What are the three architectures of merchandise planning software?
A suite module is a planning component inside a larger enterprise platform, sharing its data model and usually its implementation programme. A point solution does one module, such as assortment planning or allocation, very well and integrates with whatever holds the rest. A connected platform holds the modules on one data model purpose-built for planning, between the product record and the transaction record. Each trades something: breadth and governance against planning depth in the suite, depth against reconciliation in the point solution, and connectedness against the need to integrate on both sides in the platform.
Share this guide with your team
Copy a link or a pre-written message for Slack, Teams, or email.
// Know where your operation stands
Apply this to your planning operation.
The free Apparel Planning Maturity Assessment benchmarks your operation and tells you exactly which gaps to fix first.