Supply Chain Software vs. Merchandise Planning Software

Supply chain management software and merchandise planning software are two different classes of system: merchandise planning software decides what an apparel or footwear brand will own — the money by month, the options, the depth by size and the week each receipt should land — while supply chain software develops, sources, makes, moves, stores and records that decision once it has been taken. The two meet at the purchase order. That shared object is why a search for one can return the other, and why a brand can correctly diagnose a problem and still buy the wrong class of system to solve it.

This guide is the category map: the eight system classes an apparel or footwear brand runs between a line plan and a sale, what each is the system of record for, and what it does not own. It traces the handoffs between them, from the buy plan to the receipt that flows back into the open-to-buy, with a worked example; gives a decision table for working out which class you are actually shopping for; and covers footwear, accessories & bags and home & furniture. It is a companion to demand vs merchandise vs supply planning: that guide separates the planning disciplines; this one separates the systems that hold their decisions.

Why the two categories blur

"Supply chain" has become an umbrella label. Depending on who is selling, it can cover product lifecycle management, sourcing portals, production tracking, freight visibility, warehouse management, forecasting and planning. "Merchandising software" is stretched almost as far, to cover product information, line sheets and e-commerce merchandising as well as planning. Stretched across the same stack, the two labels can return the same products for "apparel supply chain management software" and "apparel management software", and neither tells a buyer which problem a product solves.

The way through is to stop classifying by label and classify by system of record. For every decision that matters to a brand — how much money the season can commit, which options exist, how a style is made, what was ordered from whom, where the goods are, what they cost, what is on the shelf — exactly one system should hold the authoritative version. Every other system reads that version, and when two systems disagree, the system of record wins. The question to ask of any product, including ours, is which decisions does this become the system of record for, and which does it only read?

The second test is the unit. Planning works in dollars first and units second. PLM works in specifications, materials, colorways and cost versions. Sourcing and production tools work in purchase orders and milestones; logistics in shipments and containers; a warehouse management system in cartons and locations; the ERP in transactions and the ledger value of inventory. A system built around one unit handles another unit badly, and much of the pain in this guide comes from forcing a decision into a system built for a different unit: an open-to-buy kept in an ERP export, a size curve kept in a PLM line sheet, a delivery slip tracked in a spreadsheet nobody updates from the factory.

The category map

Product boundaries do not line up neatly with these rows — one product can span two or three, and the edges move from product to product — but the decisions do. Use the rows to work out which decision you need a system to own, then check which product owns it.

Read the last column first. Every class is defined as much by what it does not own as by what it does, and the expensive confusions come from assuming a system owns a decision because it displays the data that decision needs.

The planning layer: deciding what the business will own

The planning layer decides, ahead of time and under a budget, what the business will own. It works forward from a financial target rather than backward from a transaction, which is why "should we" questions get answered here.

Merchandise financial planning and open-to-buy

The merchandise financial plan sets sales, margin, inventory and receipts by month, by class and by channel. Open-to-buy falls out of it: for any month, the receipts the plan allows, less what is already on order for that month. This class is the system of record for the season's money and for the receipt plan — the month-by-month schedule of what is expected to arrive, at cost, against which budget.

It plans in aggregates no supply chain system holds — no purchase order says "knit tops, March, wholesale, at cost." The receipt plan is a planning object with no execution twin, which is why it drifts: every other system can be correct while the receipt plan is wrong, because it is where the individual commitments are added up against the money. The merchandise financial planning guide covers the build, and the OTB planning page covers how RetailNorthstar handles the budget side.

Assortment, line and buy planning

Line and assortment planning resolve the money into options: style-colors per class, price architecture, depth, delivery window and channel. The buy plan then resolves options into units — by size, by delivery, by vendor split — and is the last planning artifact before a commitment is made to a vendor. This class is the system of record for which options are bought and how deep each one goes, which is a different thing from which styles exist in development. A style can be fully developed, costed and sampled in PLM and never bought; the buy plan is where that is decided.

Its output is not yet a purchase order. It is a buy — style-color, size breakdown, delivery window, target cost, vendor — and which system owns the order it becomes is the subject of the handoff section below.

Allocation and replenishment

Allocation and replenishment decide where received stock goes and when core stock is re-ordered: units by door, DC, e-commerce node and week, read against sell-through and the size curve. This class is the system of record for the distribution decision — which door gets which sizes of which style-color — and, for a core program, for the trigger that re-orders. It reads inventory from the WMS and the ERP; it does not move a single carton. Its characteristic failure is allocating stock that cannot actually ship yet, which is why it should allocate from stock that has been received, put away and not already committed to wholesale orders or reserves — not from raw on-hand, and not from available to sell, which also counts confirmed on-order.

The product layer: PLM

Product lifecycle management is the system of record for how a product is made: the tech pack, the specification and measurement chart, the bill of materials (fabric, trims, labels and packaging in apparel; upper materials, lining, outsole and last in footwear), the colorway and material library, the sample and approval history, and the cost as it moves from target to quote to confirmed. Its unit is the style in development rather than the style as a commercial commitment.

PLM touches the planning layer in two places. Upstream, the line plan names the options development has to produce, so the option count in the plan and the style count in PLM should reconcile at line review — and can drift apart after it, as styles are added in development but not in the plan, or dropped from the plan but not from development. Downstream, cost: the plan's margin assumed a cost, and PLM holds the cost as it evolves through quoting. A cost version that moves after the price was set changes the initial markup of the buy, and unless that change reaches the plan, the plan's margin no longer describes the goods.

What PLM does not own is volume or timing. It can tell you that a jacket has a confirmed cost and an approved fit; it cannot tell you whether the class can afford 3,000 units of it in October. Brands sometimes try to plan in PLM line sheets because the styles are already there. A line sheet is a list of products, not a plan: it carries no receipt month, no open-to-buy and no inventory target, so the plan ends up rebuilt in a spreadsheet beside it. The product development page describes how RetailNorthstar approaches line sheets and costing, and says plainly that it is not a full PLM.

The record layer: ERP

The ERP is the system of record for transactions and their value: sales orders and wholesale orders, purchase orders once placed (unless a sourcing platform has been named the order's system of record), receipts, invoices, payables, and the ledger value of inventory. In a wholesale business it also holds the customer order book, directly or through an order management system attached to it, and with it the available-to-sell position that order entry promises against.

The ERP's boundary with the planning layer is a clean one, and the best merchandising software for apparel page draws it the same way: the ERP records what was ordered, invoiced and moved; merchandising software decides what should be ordered. The ERP holds actuals at the grain the plan needs — receipts by PO line, sales by SKU, inventory by location — but it holds no future the business has not already committed to. It can tell you what the March receipt was. It cannot tell you what the March receipt should have been.

Planning inside the ERP is a tempting workaround because the actuals are already there. The trap is the unit. The ERP's natural units are transactions and accounting periods, while the plan's are classes, options, delivery windows and receipt months. The open-to-buy ends up computed in an export, the export in a spreadsheet, and the spreadsheet becomes the real plan, one step removed from the actuals it was meant to sit next to. The ERP should feed the plan; it should not host it.

The execution layer: sourcing, production, logistics and the warehouse

The execution layer carries the commitment from vendor to shelf. It is the layer the phrase "supply chain execution" refers to, and it is three jobs with three units.

Sourcing and purchase order management

Sourcing tools hold vendor and factory selection, cost negotiation, sample requests, and the purchase order as a working document between brand and supplier: confirmations, changes, splits, cancellations and the size-by-color breakdown the factory will cut against. Supplier collaboration — the vendor confirming quantities and dates, uploading documents, flagging problems — belongs here, as does the buy execution step where a finalized buy is submitted to the vendor.

The boundary between this class and the planning layer is unsettled, for a structural reason: both sides need the purchase order to do their job. Some planning platforms carry the buy through to a purchase order and track it afterwards; some sourcing platforms carry a buy plan of their own. The test is not which screen the purchase order is typed into but which system wins when two of them disagree about the quantity, the cost or the delivery date. Name that system in writing, and make every other system read from it.

Production tracking: WIP and the T&A calendar

Production tracking holds the purchase order's progress through the factory: material booked, lab dips and fit samples approved, production started, finished, packed, ex-factory. The time-and-action calendar back-schedules those milestones from the delivery date; the WIP report says where each order actually is against them. Where a brand works through a sourcing agent, this record may live in the agent's order book — see how sourcing agents keep production visible.

This class is the system of record for when the goods will actually leave the factory — a fact the planning layer depends on and does not own. The plan assumes a receipt week; the T&A calendar knows whether it still holds.

Logistics, freight and the warehouse

Logistics systems hold the shipment: the booking, the container or air waybill, in-transit status, customs documents, duty and freight cost. A warehouse management system holds the physical stock once it lands: receiving against the advance shipping notice, put-away, location, pick, pack and ship. Both carry out a decision and record that it happened; neither decides what should be in the container or which store gets the cartons. Each returns a number the plan needs. Logistics returns the arrival date, and the freight and duty that turn first cost into landed cost. The WMS returns what was actually received — which is not always what was ordered — and the date it became available to ship, which can be later than the date it reached the dock. The plan should count stock from the date it can be sold, not the date it was unloaded.

The handoffs, and what goes wrong at each

The systems are not the hard part. The handoffs between them are, because a handoff is where one system's output becomes another system's input and nobody owns the translation. Four of them carry money.

Buy plan to purchase order

Three things can leak when the buy plan becomes purchase orders. The size breakdown: if the order is keyed by hand from a spreadsheet, the curve is re-typed — or replaced with the factory's default ratio — without anyone deciding to change it. Minimum-order rounding: a vendor's minimum order quantity rounds a line up on the order, and if that rounding never returns to the plan, the open-to-buy is overstated by exactly the cost of the extra units (planning against fabric minimums covers the upstream version). And dates. The plan's delivery window is when goods should be sellable; the order's date may be ex-factory, port or in-DC. A date without its definition is a different date in every system that reads it.

Purchase order to T&A calendar to receipt flow

Once the order is placed, the T&A calendar drives receipt flow: milestone by milestone, it sets the week goods arrive and so the month the receipt plan counts them in. When a milestone slips and the slip does not reach the plan, money moves between months without the plan noticing — visible in production, invisible in the budget. The receipt week on the calendar and the receipt month in the plan have to be one field read from one place, or one of them is always out of date.

Shipment to receipt

What arrives is not always what was ordered: short shipments, over-shipments inside tolerance, substituted colors and split shipments all change the units the plan is counting on. The receipt also has two dates — dock and sellable — and allocation needs the second. A plan that allocates or promises against the dock date ships short — to stores, and on wholesale orders as a fill rate shortfall — which looks like a supply problem and is a timing one.

Receipt back into open-to-buy

The loop closes when the receipt is booked, the matching on-order is relieved, and the month's open-to-buy is recomputed on actuals. If on-order is not relieved when the goods arrive, the same units are counted twice — once as received, once as still on order — and the open-to-buy reads smaller than it is. If cancelled lines stay in on-order, money is held against orders that no longer exist. Stale on-order mis-sizes the next buy directly, because on-order is the number open-to-buy subtracts. The PO coverage formula is the check that the open orders will actually deliver the units the plan needs.

An illustrative worked example: one slip, two wrong months

The figures below are illustrative round numbers chosen to show the arithmetic, not benchmarks. Take one class with a monthly receipt plan at cost, and one purchase order inside it.

• →The order: 2,400 units of one style-color at a landed cost of $22 a unit, so $52,800 at cost, due to be received in March.
• →March: planned receipts $400,000; on order before the slip $380,000; open-to-buy $20,000.
• →April: planned receipts $350,000; on order before the slip $340,000; open-to-buy $10,000.

Open-to-buy here is the receipt form of the calculation, at cost: planned receipts for the month less what is already on order for it. The open-to-buy formula shows the full form, at retail.

Now the fit sample comes back with a second round of comments, production starts late, and the T&A calendar moves the receipt into April. The order's total is unchanged. The months are not.

The arithmetic: 2,400 × $22 = $52,800. March on order falls to $380,000 − $52,800 = $327,200, so March open-to-buy is $400,000 − $327,200 = $72,800. April on order rises to $340,000 + $52,800 = $392,800, so April open-to-buy is $350,000 − $392,800 = −$42,800. Combined, $72,800 − $42,800 = $30,000, the same as before the slip.

Two things follow. First, a season-level open-to-buy report shows nothing, because the season total did not move. Second, if the slip reaches the T&A calendar but not the plan, the plan keeps counting the $52,800 in March: it still shows March with $20,000 of open-to-buy and April with $10,000, while the goods will actually put April $42,800 over. A buyer who spends April's apparent $10,000 on a chase takes April's real position to −$52,800 ($350,000 − $392,800 − $10,000), March receives $52,800 less than the plan expects, and the over-commitment surfaces weeks later as excess inventory with no visible cause. If the slip reaches the plan in the week it is known, the same buyer sees March at $72,800 and April at −$42,800 — $52,800 of March's headroom belongs to an order now landing in April — and decides deliberately what to do with it. The T&A calendar was right; the plan was right about its own inputs. The failure was a fact known in one system and not in the other — which is the argument for connecting the systems rather than replacing them.

Which class are you actually shopping for?

The table starts from the symptom rather than the category, because the symptom is what a brand actually knows when it starts looking. It maps each symptom to the decision behind it, to the class of system that owns that decision and, in the last column, to the class it is easy to buy by mistake.

Three questions that settle it

1. →Is it a decision not yet made, or one already made that is not being carried out? A buy that was wrong is a planning problem. A buy that was right and arrived late is an execution problem. A buy that arrived on time and was booked at the wrong cost is a record problem. The same season can have all three, and they need different systems.
2. →Which unit is the problem denominated in? Dollars and options point to planning, specifications and cost versions to PLM, orders and milestones to sourcing and production, shipments and cartons to logistics and the WMS, invoices and ledger value to the ERP.
3. →Who feels it first? Planners feel planning problems, developers feel PLM problems, production feels execution problems, finance feels record problems. If the person describing the pain would not use the system being evaluated, check that the diagnosis has not jumped a layer.

There is a fourth case the table does not hold: two correct systems that disagree. The T&A calendar says April and the plan says March; the order says one cost and the plan another. That is not a missing system. It is a missing integration, and buying another system to fix it adds a third version of the same fact. To test integration claims, see questions to ask planning software vendors and the software selection guide; for what has to be clean on your side, data readiness for merchandise planning.

Not every brand runs all eight

A given brand may run four of the eight. Each row can be absent for a legitimate reason:

• →A brand that uses a third-party warehouse runs no WMS; its partner does, and the brand's job is getting receipts and on-hand back on a dependable cadence.
• →A brand with a small, stable line may develop in spreadsheets and email with no PLM, provided the costs that reach the plan come from one agreed version.
• →A brand that sells mainly through its own site may have no wholesale order book, so available to sell nets only open web orders against on-hand and confirmed on-order.

What cannot be absent is the decision. Every row is a decision someone is making whether or not a system holds it. Without a system it lives in a spreadsheet, an inbox or a person's head — which can be the right call at a given size, as long as the brand knows which decisions live there and who owns them.

Footwear: where the category boundary moves

Footwear runs through the same eight classes but changes two things that move the boundaries: the unit every system carries, and where the first irreversible commitment is made.

Size runs and width fits multiply the SKU count

A footwear model-color is bought as a size run: the sizes, the half sizes between them and, where the model offers them, the widths. The SKU count per model is the product of sizes, widths and colorways. As an illustrative count, a men's run from 7 to 13 in half sizes is 13 sizes; in two widths it is 26 SKUs per model-color (13 × 2); in six colorways it is 156 SKUs for one model (26 × 6). An apparel style-color in a six-size range is six SKUs.

Every system in the chain has to carry that grain intact. The buy plan sizes pairs by size within width; the purchase order has to carry the same breakdown to the factory; the WMS has to receive and locate it; allocation has to send complete runs to doors, because a run with its middle sizes missing is unsellable at full price long before the pair count says anything is wrong. A system that flattens size-within-width anywhere in the chain breaks the run before a shoe is made. The purchase order is a likely place: a breakdown carried in the plan is re-keyed as pairs per model-color and spread on a default ratio.

Lasts, molds and tooling move the commitment upstream

A footwear model is built on a last, and its outsole comes from a mold. Both are tooling, with real cost and long lead times, committed before the first purchase order — so the first irreversible decision sits upstream of the buy. The tooling is a development object that sits with the model record in PLM, but the decision to cut it is a line decision about which models the brand will carry and for how many model years, and that belongs in the plan. The tooling cost has to reach the margin the plan is built on, either amortized into the model's cost or carried as a line-level investment, or a new model looks cheaper than the carryover it displaces.

Factory minimums compound it. A footwear factory may quote a minimum order quantity per model-color, per material or per size tier. A per-model-color minimum binds how many colorways the line can afford; a per-size-tier minimum binds the run itself, forcing depth onto fringe sizes the curve would not have bought. Either way the minimum is a sourcing fact that sets a planning quantity, and it has to be visible in the open-to-buy when the buy is sized, not discovered in the factory's order confirmation. The footwear assortment guide covers the depth arithmetic.

Model-year carryover, prebook and the long lead time

Footwear lines turn over by model year as well as by season. A carryover model continues unchanged — no new tooling, a known curve — and is the cheapest decision in the line; a new model carries the tooling cost and the forecast risk. The carryover-or-new call is made at line review, held in the plan, and recorded against the model in PLM. In wholesale-led footwear, the dealer prebook sizes and schedules the production run: the ERP holds the prebook orders, the production buy placed with the factory is built from them, and the plan holds the prebook position against the buy, so that the at-once pairs held back for fill-in are a decision rather than a residual. The changeover itself is covered in planning a model-year changeover.

Long factory lead times make every handoff above more expensive: the buy is committed further from the selling season, the receipt plan carries more months of on-order, and a slip moves money committed long before. A search for "footwear supply chain software" can be describing exactly this — the order, the T&A calendar and the plan disagreeing about a receipt month. Before evaluating anything, decide which of the eight decisions is actually unowned. The footwear brands page covers how RetailNorthstar approaches the planning side.

Accessories & bags and home & furniture

Accessories & bags

Accessories and bags plan on style-colors rather than size runs, so the SKU multiplier is the colorway and the hardware finish rather than the size. The supply constraint sits upstream in the material: a leather article, a hardware finish or a lining color can carry its own minimum at the tannery or the component supplier, and those minimums bind the colorway count in the plan. That makes the PLM bill of materials a direct input to the assortment, because two colorways that share a leather article share a minimum, while two that do not each have to clear their own. An evergreen core beneath seasonal colorways splits the plan as in apparel: core replenishes on a rule, seasonal is bought once and exited. Planning accessories lines covers the hero-color and minimum arithmetic; see also the accessories brands page.

Home & furniture

Home and furniture move the boundary toward logistics. SKUs carry long lead times, and where goods ship by ocean in full containers, a container minimum rather than a style minimum can set the order: the buy is built to fill cube, and a SKU whose demand does not justify its share of a container waits for the next one. The container booking and its consolidation belong to logistics; the buy decision the container minimum constrains belongs to the plan, and the two have to meet before the purchase order is placed rather than after. Ocean freight on bulky goods is priced on cube rather than value, so freight can move landed cost more than a first-cost negotiation does — the cost the plan uses has to come from logistics actuals, not from the first cost on the quote. On the selling side, the floor set is a planning decision about which finishes and frames are shown, and dealer prebooks are orders in the ERP that the plan has to net against the buy. Merchandise planning for home and furniture brands and OTB planning for home goods cover the planning mechanics; see also the home and furniture brands page.

Where RetailNorthstar fits

RetailNorthstar is a merchandise planning platform. OTB planning, merchandising and assortment planning and allocation sit on a shared data model — the planning layer in the map above. It is not an ERP, a warehouse management system or a freight system — its inventory allocation page describes it as the planning context, not the warehouse system — and its product development page says plainly that it is not a full PLM. As the demand vs merchandise vs supply planning guide puts it, a merchandise planning platform stops where the question becomes factory capacity, raw material commitment, production scheduling, container consolidation or landed cost by freight mode.

Planning software does not replace the systems that develop, make, move, store and record the product, and a brand evaluating one should not be told that it does. The integration is the point. The product data page describes connecting to existing ERP and PLM systems via API or structured import; the purpose of any such connection, whichever systems are involved, is that a cost change, a slipped delivery or a posted receipt reaches the open-to-buy in the week it happens, rather than as a variance discovered a month later.

Related resources

• →Demand vs Merchandise vs Supply Planning — the three planning disciplines and where each stops
• →Assortment Planning for Footwear Brands — size runs, minimums and run integrity
• →Receipt Plan, On Order, Lead Time and Supply Planning — the terms behind the handoffs