What is an apparel and footwear solution?

Ten places a flat item list fails an apparel business

A general-purpose ERP was designed around a financial item and a stock location: one item number, one cost, one quantity on hand, one unit of measure. That is a sound model for a bolt, a pallet of paper or a case of a beverage. An apparel product is not an item. It is a style that exists as a grid of colorways and sizes, sold in a season, delivered in drops, ordered months ahead by accounts that will deduct money if the cartons arrive labelled wrong. Every one of those facts can be forced onto a flat item list, and every brand that has done so has paid for it in scripts, spreadsheets and the people who maintain them. The ten below are where the forcing happens.

1. The matrix item against a flat item list

The first and deepest difference is the shape of the product record. In a flat list, a style with six colorways on an eight-size scale is 48 items, each created, costed, priced and assigned to a season separately, with a naming convention carrying the relationship between them. Change the cost on the style and 48 records change — if someone remembers all 48. Add a colorway and eight new items are born by hand. A matrix item holds the style once and the colorway and size as dimensions, so the 48 cells inherit what is common and carry only what differs, and an order for the style-color can be entered as a row of sizes rather than as eight lines.

Definition — Matrix item (style-color-size)

A matrix item is a product record held as one style crossed with a set of colorways and a size scale, so that each sellable unit — the style-color-size, carrying its own UPC or GTIN — is a cell in a grid rather than a separate item set up by hand. The style carries what is common to every cell: name, category, fabric, cost, season and price list. The colorway and the size add only what differs. Orders, receipts, inventory and sales are written and read at the cell and rolled up to the colorway and the style without a mapping table, which is what a flat item list cannot do.

Used by: Merchandising, product data, wholesale operations and inventory teams at apparel and footwear brands

Related: Style, colorway, size scale, SKU, UPC, GTIN, prepack, apparel and footwear solution, apparel data model

2. Size scales and conversion

Sizes are not a list of values. They are an ordered scale with a name — alpha from XS to XXL, numeric waist from 28 to 40, a children’s age scale, a footwear run in half sizes — attached to the style once and inherited by every colorway. The order matters, because a line sheet, a purchase order and a pick ticket all print sizes in scale order and a sort that puts L before M is read as a mistake by everyone who sees it. The same physical garment may also carry a different size name in a different market or at a different partner, and the factory may cut to a third. A conversion between two scales is a table that someone has to hold; in a flat item list it is held in a person’s head or in a spreadsheet beside the system, and the first sign that it is wrong is a size curve that makes no sense.

Definition — Size scale (apparel ERP)

A size scale is a named, ordered list of the sizes a style is offered in — XS to XXL, 28 to 40 by waist, 7 to 13 in half sizes by width — attached to the style once rather than typed per item, so that every colorway of the style inherits the same sizes in the same order. It fixes the order sizes print in on a line sheet, a purchase order and a pick ticket; it is the frame a size curve is expressed against; and where a factory, a partner or a market names sizes differently, a conversion between two scales is held as data rather than remembered by a person.

Used by: Product data, merchandising, planning, sourcing and wholesale operations teams

Related: Matrix item, size curve, size conversion, prepack, line sheet, UPC, apparel and footwear solution

3. Colorways

A colorway is a dimension of the style, not a variant of an item. It has its own code and its own name, often a partner-facing name that differs from the internal one, and it may be introduced, carried over or dropped independently of the style. A style can gain a colorway in a second delivery, and the new colorway inherits the size scale, the cost and the price list without anyone re-keying them. Where the colorway is a separately created item, none of that inheritance exists, and the question “how did this style do” needs a query that knows which 48 items are the style.

4. Seasons and deliveries

Apparel is sold in a season and shipped in deliveries within it, each with a ship window — a ship-not-before date and a cancel date — that the wholesale order book is dated against. A flat item list has no season: an item is active or inactive. So a style that belongs to a season, is carried over into the next one at a new price, and ships in two drops has nowhere to record any of that except in attributes bolted onto the item or in the order date. Season and delivery are keys that every apparel report groups by, and a system that does not hold them as records cannot answer how a delivery performed, which price list applied, or which receipt week a purchase order was expected in.

5. Prepacks and case packs

A prepack is a sealed assortment of sizes that is ordered, received, picked and shipped as one unit with its own identifier — an illustrative 12-unit pack in a 1-3-4-3-1 ratio from small to double extra-large — while the consumer buys and the partner reports single sizes. A case pack is the same idea for a single size. A flat item list has one unit of measure per item, so the pack becomes either an item of its own, with inventory that cannot be sold open, or a kit that is exploded on receipt and loses its identity. An AFS holds the pack as a configuration of the matrix: ordered in packs, held in units, exploded by the system, so fifty of the illustrative pack is 600 units — 50 small, 150 medium, 200 large, 150 extra-large and 50 double extra-large — in inventory and 50 packs on the order.

6. The UPC and GTIN explosion

Every sellable cell needs its own barcode: a 12-digit UPC in North America, a 13-digit GTIN across much of the rest of the world, assigned from the brand’s company prefix. The arithmetic is unforgiving. One style, six colorways, eight sizes: 48 codes. A hundred styles in a season at that shape: 4,800. A footwear style in four colorways on a 13-size run in three widths: 156 codes for one model, which is 13 × 3 × 4. Each code has to be assigned once, never reused, and sent to every partner before the first order on a catalog document that a flat item list cannot generate from a style. An AFS assigns the code at the cell from the prefix, holds it with the cell through a carryover, and explodes the matrix into the catalog without a spreadsheet in between.

7. Cut-and-sold and make-to-order

Two apparel order models have no counterpart in a distribution ERP. In a cut-and-sold business the brand books wholesale orders first and cuts against the order book, so production is driven by sales orders rather than by a stock forecast, and the question at the cut is how much to add above what is booked for at-once sales. In make-to-order — private label, uniform, team dealer — the sales order is the trigger for the work order itself. Both need a link between a sales order and the purchase or work order that will fill it, held on the record and not in a person’s memory. The illustrative arithmetic is simple and the systems rarely hold it: prebooks for a style-color come to 840 units — 120 small, 280 medium, 280 large and 160 extra-large — and the brand cuts 1,000, as 140, 330, 340 and 190, so 160 units are left for at-once orders, as 20, 50, 60 and 30 by size. The cut is a decision the plan makes; the link between the 840 and the 1,000 is a record the AFS keeps.

8. Wholesale prebooks, bulk orders and at-once

The wholesale order book holds three kinds of order that look alike and behave differently. A prebook is placed at market months ahead of the season against a ship window; a bulk order is a partner’s commitment to a quantity that will be broken into store-level orders later; an at-once order is placed against stock in season. Each has to be distinguished by a field on the order, dated to a delivery, and held with ordered, confirmed, allocated, picked, shipped, cancelled and open quantities by size. A flat sales order with one quantity and one date cannot tell a forward commitment from a replenishment signal, and overwrites the booked quantity every time the partner changes its mind. Fill rate, one of the most closely watched wholesale measures, is unreadable without the booked quantity kept beside the shipped one.

9. Allocation against available to sell

Because the order book is written months before the goods exist, an apparel business sells the same physical unit to several channels against a figure that nets open orders and allocations out of on hand and inbound — available to sell, by style-color-size and date. The order has to be allocated to stock, or to an inbound purchase order, and released to pick only when the window opens. A distribution ERP reserves against on hand. It has no natural record for a unit promised against a receipt that has not happened, no reserve by channel, and no way to stop counting an inbound order when its date slips past the promise. The full calculation and why every system’s figure disagrees is worked through in available to sell in apparel.

10. Chargebacks and deductions

A retail partner that receives goods late, in the wrong cartons, with the wrong label or outside its window deducts the penalty from its payment, and the deduction arrives on a remittance weeks after the shipment. A general ledger records it as a short payment. An apparel business needs it posted to the invoice, the order, the shipment and a reason code, so the account’s margin can be read net of it and the recurring cause can be given an owner. That record does not exist in a finance system, and a brand that has never been able to answer what chargebacks cost it by account is usually a brand whose deductions live in a receivables ageing report.

Apparel ERP, fashion ERP, apparel management software: the same category under several names

The category travels under more names than most, and the names are not quite interchangeable. Apparel and footwear solution is used here as the broadest term: it names the system of record for the transaction in a business whose product is a matrix, whatever shape the system takes. The others lean toward one shape or one part of the job, and a brand that searches for one term reads descriptions written for another. The table sets them side by side, and the point of it is not vocabulary but scope — what each term usually includes, and what it quietly leaves out.

Two of the rows deserve a sentence each. “Apparel management software” usually describes an AFS for a brand that is not yet large enough to need subsidiaries, intercompany or a full ledger: the order book, the matrix, inventory, purchasing and invoicing, with accounting exported to a general-purpose finance tool. It is the same record set with the finance seam drawn closer in, and it is the shape most brands start in. “Wholesale order management” and “apparel PO software” each describe one record set lifted out of the ten — the sales order with its allocations and compliance, or the purchase order with its confirmations and milestones — which is the best-of-breed shape seen from one layer. Each is a legitimate purchase; neither is the whole, and a brand that buys one of them still has to decide where the other nine records live.

The last row is the one this site exists to draw. A merchandising operating system is not a shape of the AFS and does not compete with it for any record. It owns the plan and the transitions between stages, upstream of the transaction, and hands the committed buy down to whichever shape of AFS the brand runs. The category boundary, and why the two are not alternatives, is set out in the apparel operating system definition.

Ten records an apparel and footwear solution owns

A system is defined by the records it is authoritative for — the objects for which it is the one place a value is written and from which every other system takes a copy. The rule, and the full assignment of every apparel data object to an owner, is in the system of record matrix. Applied to an AFS, the list is ten records long. Each is held at style-color-size grain or keyed to something that is, and each is read by a process somewhere else in the business, which is what makes the AFS the hub the rest of the stack hands off to and from.

Two records are deliberately absent from the list. The style’s bill of material, tech pack, sample history and development calendar belong to PLM, which authors the style the AFS receives. And the plan — open-to-buy, the assortment, the buy before it is a commitment — belongs upstream, in the plan of record, for reasons the later section on planning sets out. An AFS that is asked to hold either of them holds a copy, and a copy with two writers is the start of a reconciliation.

The processes it runs, the ones it touches and the ones it does not do

The clearest way to bound an AFS is by process. Two run inside it end to end. Order-to-cash: the wholesale or direct order is entered or received, credit-checked, dated, allocated against available to sell, released to pick, shipped, invoiced, collected, and reconciled against deductions and returns. Procure-to-pay: the purchase order is cut to the factory by style-color-size and delivery, confirmed, amended, received against, matched to the supplier invoice and the receipt, and paid, with the landed cost carried onto the unit. Every record in the set above exists to serve one of those two loops.

Around them sits a ring of processes the AFS participates in without owning. It holds the committed purchase order but not the critical path that gets it made on time; it generates the ship notice but not the carton-level pick path on the warehouse floor; it holds the catalog the storefront publishes but not the storefront; it posts the invoice but does not close the books. The planning processes sit outside the ring altogether: open-to-buy, assortment, the buy plan and the in-season reforecast are decided before a commitment exists and in a versioned record the AFS does not keep. The table draws the line process by process.

The three rows marked “owns the figure” and “touches” are where most arguments about an AFS start, because the same word covers different depths. An AFS owns the available-to-sell figure in the sense that it is the one place the netting should be done; it does not own each channel’s decision about how much of that figure to show. It owns the company inventory position — units by style-color-size, location and status, valued — while the warehouse system owns where in the building each unit physically is. The two should agree at the end of every day, and a brand that cannot say which one is right when they do not has not assigned the object. Allocation on this page means allocating a sales order to stock, which the AFS does; deciding how units are split across a retailer’s doors is retail allocation, which it does not.

Six seams, and the fields that cross each one

An AFS is the system the rest of the stack hands off to and from, which means its boundaries are where the stack succeeds or fails. A seam is defined by the fields that cross it, the direction they cross and the event that sends them, and the honest description of any AFS deployment is a list of those three things for each neighbour. The six below are the ones every apparel brand has, whether or not the neighbour is a separate product.

PLM into the AFS

The style is authored in product lifecycle management and born in the AFS when it is adopted into the line. What crosses: the style number and name, division and category, the colorways with their codes and names, the size scale, the fabric and content, the country of origin and classification, the vendor and the quoted or landed cost, and the season. What does not cross: the tech pack, the bill of material, sample rounds and fit comments, which stay in PLM. The failure at this seam is a cost or a colorway that changes in PLM after adoption and does not reach the AFS, so the purchase order is cut at the old cost. Why the style-color-size hierarchy itself is the hard part of sharing a record is the subject of the apparel data model.

Planning into the AFS, and actuals back

The buy plan — units by style-color-size by delivery, authorised against open-to-buy — becomes purchase orders in the AFS. What crosses down: the style-color, the size split, the quantity, the delivery and its in-DC date, the vendor and the cost. What crosses back up: the confirmed quantity and date, every amendment with its reason, receipts by size and date, on order net of receipts, and the sales, inventory and open order book the reforecast reads. This is the seam that decides whether the plan can still see its own commitments after they are amended, and it is the one most often crossed by export, edit and re-key. The purchase order’s full path across it, stage by stage, is followed in the apparel purchase order lifecycle.

The AFS and the warehouse

Down to the warehouse management system go the expected receipt — the purchase order by style-color-size and the ship notice against it — the pick release for each allocated order with its ship-to, carton and label requirements, and the return authorisation. Back come the receipt by size and date, with discrepancies against the ship notice; the shipment confirmation by carton, which generates the outbound ship notice and the invoice; the on-hand count and adjustments; and the returned unit with its inspection result. The direction of each field is fixed: the AFS tells the warehouse what to expect and what to ship; the warehouse tells the AFS what actually arrived and left. A stack where either side writes the other’s field has two inventory positions by the end of the first week.

The AFS and EDI

The translator turns each wholesale document into the AFS record it represents and generates documents from AFS events. An inbound purchase order becomes a sales order on the order book; a change becomes an amendment to it, which should be versioned rather than overwritten; the AFS generates the acknowledgment from the order as accepted, the ship notice from the shipment and the invoice from the invoice; the inventory advice is drawn from available to sell; the catalog is built from the style master; and the partner’s store list arrives the other way, as a document the AFS holds against the customer record so that a location code on a later document resolves to a door. One document has no record to become: the partner’s product activity report, which carries its sell-through and belongs to the plan rather than to the AFS. Which document should feed which planning decision, and why that one stops, is set out in apparel EDI in the connected stack.

The AFS and the storefront

To the ecommerce platform go the catalog — style, colorway, size, UPC, price — usually by way of PIM, and the availability feed drawn from available to sell with the direct channel’s reserve applied. Back come the consumer order, which becomes a sales order; the payment reference; and the return request. Shipment status and tracking go out again once the warehouse confirms. The failure at this seam is the feed generated from raw on-hand rather than from available to sell, which promises units the wholesale order book has already claimed.

The AFS and finance

Where finance is a separate system or a separate module, the AFS posts the invoice and the credit memo to receivables, the matched supplier invoice to payables, inventory receipts and relief at cost to the stock account, and deductions to the account they belong to. Back come payment application, which closes the receivable, and the period close, which freezes the inventory valuation. The planning content of this seam is small but sharp: the landed cost that finance accepts is the cost every margin read uses, and a receipt valued at standard while the landed cost arrives later is a margin that will be restated.

Read down the middle column and the pattern is plain: the AFS takes in the product from PLM, the commitment from planning and the events from the warehouse and the partners; read down the right column and it sends out instructions and the financial consequence. Why the seams rather than the systems are where apparel workflows fail is the argument of the handoff problem.

Industry ERP, generic ERP plus an apparel layer, or best-of-breed around a finance core

The same ten records and six seams are delivered in three shapes, and each is a legitimate choice for a different brand. No shape is named here by product, because the shape decides more about how a brand will live with the system than any feature list does, and the trade-offs are structural rather than commercial.

Shape one — the industry ERP

A single system designed around the matrix item from the first line of code, with finance, the order book, purchasing, inventory and wholesale compliance inside one data model. The matrix, the size scale, the season, the prepack and the chargeback are native, so the ten records live in one place and the seams inside the system are not seams at all. The cost of that depth is breadth: the finance module is built for an apparel company and may be thinner than a general-purpose ledger, reporting outside the apparel grain can be awkward, and a brand that adds a non-apparel line — accessories without sizes, a hard-goods category, a licensed food item — finds the matrix in the way. The implementation partner pool is smaller and more specialised, which is both the point and a constraint.

Shape two — a generic ERP with an apparel layer

A horizontal finance and distribution system — chosen for its ledger, its reach across subsidiaries and currencies, or because the group already runs it — extended with an apparel layer that adds the matrix item, the size scale, the season, the pack and the wholesale order book. The layer may come from the ERP’s own maker, from a partner that builds on the platform, or from the brand’s own team. The strength is a shared platform: one finance core, one security model, one upgrade cycle for the base. The strain is at the join between the layer and the base: a matrix implemented above a flat item list still generates the flat items underneath, every base upgrade has to be tested against the layer, and the layer’s depth varies from a full apparel data model to a size grid on an order screen. The evaluation question for this shape is always which of the ten records the layer owns natively and which it emulates.

Shape three — best-of-breed around a finance core

A general-purpose ledger kept for finance, with the order book, purchasing, inventory and wholesale compliance bought as one or more separate systems and joined by integration. Each layer can be the strongest available for its job, and a layer can be replaced without touching the others. The price is that the seams inside the AFS boundary — order book to inventory, inventory to finance, purchasing to receiving — become integrations with their own owners, their own timing and their own failure modes, and the ten records are spread across systems that each hold a copy of the style master. This shape suits a brand with the technical capacity to own integrations as products rather than as projects, and it is the one most likely to produce two inventory positions when it is under-resourced.

Whatever the shape, the test is the same and it is not a feature test. Take one style in six colorways on an eight-size scale, with a prepack, a prebook from one account and an at-once order from another, a factory purchase order with a partial shipment, and one chargeback. Ask to see it created, ordered, cut, received, allocated, shipped, invoiced and deducted against — and then ask to see the plan that authorised the buy read the amended order back. The shape that does that without a spreadsheet is the right shape for that brand.

An illustrative example: one style-color from set-up to deduction

The figures below are illustrative, chosen to be easy to follow rather than to describe any brand. They walk a single style-color through the ten records in order, which is the demonstration the previous section recommends and the test that separates a system that holds the matrix from one that displays it.

Set-up: 30 cells, 36 identifiers

A crew sweatshirt is adopted from PLM into the AFS as one style with six colorways on a five-size scale from small to double extra-large: 30 style-color-size cells, 30 UPCs assigned from the company prefix, one season, one delivery with a ship window, one wholesale price list and one suggested retail. One account buys the style in a 12-unit prepack with a 1-3-4-3-1 ratio across the five sizes, so each colorway also has a pack identifier: 36 identifiers in all, created by the system from one style record. In a flat item list the same set-up is 30 items created by hand, plus six kits, plus a convention that says which belong together.

The order book: 900 units booked for navy

Two prebooks arrive at market for the navy colorway. Account A orders 50 prepacks, which the system explodes to 600 units: 50 small, 150 medium, 200 large, 150 extra-large and 50 double extra-large. Account B orders open sizes: 50, 75, 100, 50 and 25, which is 300 units. The order book for navy reads 900 units booked by size — 100 small, 225 medium, 300 large, 200 extra-large and 75 double extra-large — each line typed as a prebook, dated to the delivery, and carrying its ordered, confirmed, allocated, picked, shipped, cancelled and open quantities. A flat sales order holds 50 of something and 300 of something else and cannot add them.

The cut: 1,080 units, linked to the 900

The plan decides to cut above the booked quantity to leave stock for at-once orders, and commits 1,080 units of navy: 120 small, 270 medium, 360 large, 240 extra-large and 90 double extra-large. The AFS cuts the factory purchase order as 50 prepacks — the 600 units Account A will receive packed — and 480 open units: 70, 120, 160, 90 and 40 by size. The 180 units above the order book are the at-once stock, 20, 45, 60, 40 and 15 by size, and the record that matters is the link: the two sales orders are tied to the purchase order that will fill them, so a factory slip is visible on the accounts it will hurt before the ship window opens.

Receipt: 1,040 units land, 40 stay on order

The factory ships the 50 prepacks complete and the open sizes short in large: 120 large arrive against 160 ordered. The warehouse receives 1,040 units by size and reports the discrepancy against the ship notice; the AFS writes 1,040 to inventory as available — 120 small, 270 medium, 320 large, 240 extra-large and 90 double extra-large — and leaves 40 large on order against the same purchase order, with its revised date. The plan’s on-order moves from 1,080 to 40 in the same event, if the seam is connected, and stays at 1,080 until someone notices, if it is not.

Allocation and availability: 140 units free, by size

When the ship window opens, the AFS allocates Account A’s 600 and Account B’s 300 against the 1,040 on hand and releases both to pick. Available to sell for navy is what remains, by size: 20 small, 45 medium, 20 large, 40 extra-large and 15 double extra-large — 140 units — with a further 40 large counting toward availability from the date the balance of the order is due. That is the figure the direct site and any drop-ship partner should be fed, each with its own reserve, and the reading a planner takes from it is immediate: large is the tight size, 20 free against 300 booked, and the 40 still at the factory are the only relief.

Ship, invoice, deduct

The warehouse confirms both shipments by carton; the AFS generates Account A’s ship notice and invoice for 600 units and Account B’s for 300, at the season’s wholesale price list, and posts both to receivables. Six weeks later Account A’s remittance arrives short, with a compliance deduction coded to a carton-label fault on the navy shipment. The AFS posts the deduction against the invoice, the order and the shipment with its reason code, so the account’s margin for the season is read net of it and the label fault has an owner. Every number in this walk-through was written once and read many times; the plan upstream read the on order, the receipt, the booked quantity and the availability by size without anyone rebuilding them. That is what the ten records are for.

The plan of record is upstream; the AFS executes it

The most consequential boundary around an AFS is the one with planning, and it is the one most often drawn wrong. An AFS holds the committed state of the business: the order placed, the unit received, the unit sold, the invoice raised. A plan is a decision about a commitment that does not exist yet — how many options, at what depth, in which sizes, for which delivery, against how much open-to-buy — and it changes several times before it becomes an order and several more times after. It needs to be versioned, approved and compared against itself. A transaction record is current; it has no natural state for a buy that is not yet a commitment, which the systems landscape names as the one thing an ERP has no record for.

So the plan of record sits upstream. It holds the line plan, the assortment, the buy by style-color-size and delivery, and the in-season position as one versioned set of numbers that every function reads and changes through one controlled path, and it hands the committed buy to the AFS to cut as purchase orders. The AFS executes: it holds the order, receives against it, allocates and ships, and reports the actuals the next version of the plan is built on. The relationship is a loop, not a hierarchy: the plan commits, the AFS executes and records, the plan reads the record and revises. What the plan of record holds at each stage, and who holds the pen, is set out in the plan of record; the categorical comparison between a transaction system and the decision layer above it is in Apparel OS versus ERP.

Three consequences follow for anyone choosing or running an AFS. First, the AFS should not be asked to hold open-to-buy, the assortment or the buy plan, because it will hold a copy and the working version will migrate to a spreadsheet beside it. Second, the AFS should be asked, hard, how an amended purchase order, a receipt by size and an open order book get back to the plan, at the plan’s grain and on the plan’s clock, because that return path is where most stacks are integrated and not connected. Third, the actuals the AFS keeps — sales by style-color-size by channel by week, inventory by status, on order by delivery — are the plan’s raw material, and their grain in the AFS sets a ceiling on the grain the plan can be revised at. Which level each merchandising decision belongs at is the subject of the planning grain.

None of this is an argument against the AFS. It is an argument for asking it to do the job it is built for, completely, and for putting the plan somewhere that is built for the plan. Why apparel specifically needs that second place is argued in why apparel needs its own operating system.

How footwear and the adjacent verticals change the record set

The category is named for apparel and footwear because the two share the matrix, but the matrix is not the same in each, and the verticals next door change the record set further. The pattern follows the connected stack by vertical: each vertical adds a dimension to the item, a record to the set, or a clock to the order book that the apparel version does not have, and an AFS deployed for that vertical is judged on whether it holds the addition as data or asks a person to remember it.

The per-vertical treatment of the full stack, beyond the AFS, is on RetailNorthstar’s industry pages.

An evaluation checklist: questions, not scores

A scored feature matrix rewards the system that says yes most often, and every AFS says yes to the matrix item. The questions below are built to be answered with a demonstration on the brand’s own data rather than with a checkbox, and the useful answer to most of them is a screen, not a sentence. They follow the structure of this page: the matrix, the pack, the order book, inventory and availability, compliance, the seams, the plan and the implementation. The broader method for evaluating any category of apparel software — native ownership, data flow, apparel fit, time to value and total cost — is in the apparel software buyer’s guide.

The last group matters more than its position suggests. An AFS is a system that will be lived in for years by wholesale operations, customer service, sourcing, the warehouse and finance, and the implementation decides which of the ten records it ends up owning in practice. A record that is kept somewhere else after go-live is a record the AFS does not own, whatever the contract says — and the list of those is the honest description of what was bought.

What an apparel and footwear solution does not fix

A well-chosen, well-implemented AFS gives an apparel business one place where the transaction is true: one style master, one order book, one inventory position, one invoice. That is a great deal, and a brand without it should get it before it does anything else. It does not make the buy right. The decisions that set the season’s margin — how many options, how deep, in which sizes, phased how, against how much open-to-buy — are made before the first purchase order exists, in a record the AFS does not keep, and a perfect record of a wrong commitment is still a wrong commitment.

Nor does it connect the stack by itself. The seams described above are crossed by integrations, and an integration moves a field from one system to another on an event; it does not decide whether the plan upstream can read what came back at the grain it plans at. That is the difference between an integrated stack and a connected one, and it is the reason this site exists. What an AFS does, completely, is give the plan something true to be revised against. That is its job, and done well it is enough to be worth getting right.

Frequently asked questions

What is an apparel and footwear solution?

An apparel and footwear solution is an enterprise resource planning system, or an extension to one, built for businesses whose products exist as a style in many colors and sizes. It carries the matrix item — the style with its colorways and its size scale — the season and delivery, the customer and ship-to, the price list by channel and season, the purchase order and work order, the sales order and its allocation, inventory by location and status, the invoice, the credit and the chargeback as first-class records rather than as workarounds on a flat item list, and it runs order-to-cash and procure-to-pay at style-color-size grain. It is the system of record for the apparel transaction. It is not the plan, the product record, the warehouse floor or the storefront.

How is an apparel and footwear solution different from a generic ERP?

A generic ERP holds a flat list of items, each with one number, one cost and one stock figure. An apparel brand’s product is a style that exists in several colorways and a run of sizes, so one style with six colorways on an eight-size scale is 48 sellable units — and in a generic ERP, 48 items to create, price, cost and keep in step by hand or by script. An apparel and footwear solution holds the style once, with its colorways and its size scale as dimensions, and writes and reads orders, receipts, inventory and sales at the cell while rolling them up to the colorway and the style without a mapping table. It also carries the season and delivery, the prepack, the wholesale order book with prebooks and ship windows, inventory by status, and the chargeback, none of which a generic item list has a record for.

What is a matrix item?

A matrix item is a product record held as one style crossed with a set of colorways and a size scale, so that each sellable unit — the style-color-size, carrying its own UPC or GTIN — is a cell in a grid rather than a separate item set up by hand. The style carries what is common to every cell: name, category, fabric, cost, season and price list. The colorway and the size add only what differs. Orders, receipts, inventory and sales are written and read at the cell and rolled up to the colorway and the style without a mapping table, which is what a flat item list cannot do.

Does an apparel and footwear solution do merchandise planning?

Not as its own work. An apparel and footwear solution holds the committed state of the business — the order placed, the unit received, the unit sold, the invoice raised — and it reports on that state well. Open-to-buy, the assortment, the buy plan by style-color-size and delivery, and the reforecast are decisions made before a commitment exists, and they need a versioned record with approvals, which a transaction system does not keep. The plan of record sits upstream of the AFS; the AFS executes what the plan committed and reports what happened to it. A brand that asks the AFS to hold the plan ends up holding it in spreadsheets beside the AFS instead.

What are the three ways an apparel and footwear solution is deployed?

Three shapes are common, and each is a legitimate choice. An industry ERP is a single system designed around the matrix item from the start, with finance inside it. A generic ERP with an apparel layer is a horizontal finance and distribution system extended — by its maker, by a partner or in-house — with the matrix item, the size scale, the season and the wholesale order book. A best-of-breed stack around a finance core keeps a general-purpose ledger and buys the order book, inventory and wholesale compliance as separate systems joined by integration. The first trades flexibility outside apparel for depth inside it, the second trades depth for a shared platform, and the third trades a single record for choice at each layer and puts the burden on the seams.

How does footwear change the record set?

Footwear sells pairs, and the size scale gains a second dimension: a run of sizes crossed with a width fitting, so a men’s run from 7 to 13 in half sizes is 13 sizes and three widths makes 39 cells per colorway. The style record is usually a model with a model year, and a carryover model keeps its record across model years while its colorways change. Prebook orders are placed against the next model year months ahead, so the order book has to tell a prebook from an at-once order, and inventory at the width level decides whether a run is broken even where the style-color looks healthy.

Where does an apparel and footwear solution sit in the connected stack?

It takes the style, its colorways, its cost and its vendor from PLM; it takes the buy plan by style-color-size and delivery from planning and turns it into purchase orders; it sends expected receipts and pick releases to the warehouse and takes receipts, shipments and on-hand back; it exchanges the wholesale documents through EDI, where an inbound order becomes a sales order and an outbound ship notice and invoice are generated from a shipment; it publishes the catalog and an available-to-sell feed to the storefront and takes direct orders back; and it posts invoices, credits, deductions and inventory valuation to finance. Each of those is a seam with named fields crossing it, and the connected question is whether the plan upstream can still read what the AFS did with its commitments.

• ✓An apparel and footwear solution is an ERP, or an ERP extension, built for businesses whose products exist as a style in many colors and sizes: it holds the matrix item, the season and delivery, and the size scale as first-class records rather than as workarounds on a flat item list.
• ✓A generic ERP breaks on apparel in ten places: the matrix item, size scales and conversion, colorways, seasons and deliveries, prepacks and case packs, the UPC and GTIN explosion, cut-and-sold and make-to-order, prebooks and bulk orders, allocation against available to sell, and chargebacks.
• ✓It owns ten records: the style master, color and size scales, season and delivery, customer and ship-to, price lists by channel and season, purchase and work orders, sales orders and allocations, inventory by location and status, invoices and credits, and chargebacks.
• ✓It runs order-to-cash and procure-to-pay end to end; it touches EDI translation, the warehouse, the storefront, product development and the financial close; it does not do open-to-buy, the assortment, the buy plan, store allocation and replenishment by door or the in-season reforecast.
• ✓Six seams surround it — PLM, planning, WMS, EDI, ecommerce and finance — each defined by the fields that cross it, the direction and the event.
• ✓It is deployed in three shapes: an industry ERP, a generic ERP with an apparel layer, or best-of-breed systems around a finance core. Each is legitimate; each strains somewhere different.
• ✓The plan of record sits upstream. The AFS executes what the plan committed and reports the actuals the next version is built on; asking it to hold the plan produces a copy and a spreadsheet.
• ✓Footwear adds width and model year; accessories drop the size and add the component; home and furniture configure the item and consolidate by container; beauty adds shade, lot and expiry; sporting goods season by sport; toys add the licence window; jewelry adds cost at a date and serials.

• See the AFS as one of the ten apparel software categories, and where each one stops →
• See which system owns each apparel data object — the system of record matrix →
• Read why the style-color-size hierarchy is the hard part of the data model →
• Follow one purchase order from open-to-buy approval to close →
• Read which EDI documents become which records, and which one does not →
• Read how available to sell is computed and why every channel’s figure disagrees →
• Read what the plan of record holds and who holds the pen →
• Compare the Apparel OS with ERP — the decision versus the transaction →
• See how the stack and its seams read across ten verticals →
• Read why workflows break at handoffs rather than inside functions →
• Use the apparel software buyer’s guide to structure an evaluation →