Merchandise Hierarchy

What is a merchandise hierarchy?

A merchandise hierarchy is the tree that classifies every product a brand sells, from the broadest grouping down to the sellable unit, and to which every plan, target, and report is attached. It is what makes "outerwear is over-bought" a computable statement rather than an opinion: the hierarchy defines which styles roll up to outerwear, which colorways roll up to those styles, and which units roll up to those colorways.

A common apparel hierarchy runs:

Division → Department → Class → Subclass → Style → Style-Color → Style-Color-Size (the SKU)

Level names and depth are conventions, not standards. Footwear carries size runs and widths at the bottom and often splits gender and age near the top. Accessories and bags hang colorways off an evergreen core rather than a seasonal line. Home and furniture classifies by collection, configuration, and finish, with model year as its own dimension. The shape of the tree is a business decision, and it is expensive to change once plans, history, and reporting are attached to it.

Why a merchandise hierarchy matters

The hierarchy is the coordinate system every planning number is expressed in, and three things depend on getting it right.

• →A variance is only visible at the level you planned at. A department that finishes down tells you something missed without telling you what to do about it.
• →A decision is only executable at the level you buy at. Nobody writes a purchase order for a department, so the miss has to be translated into styles and colors — and if that happens in a side conversation, the plan is a scoreboard rather than a control system.
• →History is only comparable if the tree holds still. Hindsight and next season's forecast both read last year through the current structure.

Every layer of merchandising planning is written at some level of this tree, which is why hierarchy design is a planning question rather than a data-modeling one.

Reporting hierarchy vs planning hierarchy

Two hierarchies tend to coexist whether or not anyone has named them, because the reporting structure is usually the one built first, by finance, and merchants then group their decisions differently. The test that separates them is direction of travel: reporting rolls facts upward, planning pushes intent downward. A level that only ever answers "what happened" is a reporting level; a level someone has to fill in before the season starts is a planning level. Attributes that have nothing to do with the buy — fabric content, country of origin, sustainability flag, price band — belong in reporting, and reporting is better for having them.

Trouble starts when the two are assumed to be the same tree. A plan built on merchant logic cannot be reconciled to a P&L built on finance logic without a mapping, and when that mapping lives in a spreadsheet it gets rebuilt by hand every season and quietly diverges from both. The fix is not to force one hierarchy on both audiences, but to define the mapping once, in the data model. For the level-by-level split across ten verticals, see Merchandise Hierarchy by Vertical.

In practice

A planner sets a receipt target at class level, because that is the finest level with enough history to forecast against. The hierarchy resolves it down to the subclasses and style-colors beneath, and a size curve distributes each style-color into units — nothing below the class was forecast, it was distributed. Actuals roll back up the same tree, so the class-level variance and the style-color detail behind it are one number seen at two altitudes.

Common mistakes

• →Encoding attributes as levels. Color, price tier, sustainability flags, and lifecycle role are attributes. They are useful for slicing a level and for reporting; promoting them to hierarchy nodes multiplies the tree and makes every rollup ambiguous.
• →Reorganizing mid-season. Moving a class breaks comparability with history, which is the input to hindsight and to next season's plan.
• →Building a hierarchy no merchant uses. If planners keep a private grouping in a side file because the official tree does not match how they buy, the official tree is decoration.

For how the hierarchy sits inside the wider schema of products, locations, and plans, see retail data model.