Style BOM and the Size-Colour Matrix in Pixel ERP

A generic ERP thinks in single part numbers. Apparel does not. One style — say a men’s polo — explodes into a grid: five sizes across four colours is twenty variants, each with its own order quantity, stock, WIP and cost. Multiply that by a season’s worth of styles and you have thousands of combinations. Try to manage that as a flat SKU list and merchandising retreats to spreadsheets, which is exactly where most apparel factories still live.

A real garment ERP solves this with two building blocks working together: a style BOM that defines what a garment is made of, and a size-colour matrix that captures quantities across the size-and-colour grid everywhere at once. Pixel ERP is a ready, AI-native product built around both — adapted to your product through no-code, never rebuilt from scratch.

In Pixel ERP everything hangs off the style. A style is created once and carries its size set, its colourways, its images, its fabric and trim BOM and its target cost. Merchandising, procurement, cutting, packing and finance all read from the same style, so there is one version of the truth instead of five copies drifting apart in different files.

What a Pixel ERP style holds

• The size set (for example S–XXL, or numeric 28–42) that defines the columns of its matrix.
• The colourways — the fabric colours the style is offered in — that define the rows.
• A fabric and trim BOM with consumption per piece, wastage and shrinkage.
• Reference images and tech-pack details so the shop floor makes the right thing.
• A target cost to measure the real, actual cost against later.

Because styles are reusable, next season is a revision, not a rebuild — you clone and tweak rather than rekey.

The style bill of materials is where apparel costing and material planning either work or fall apart. In Pixel ERP the style BOM lists every fabric and trim the garment needs, with a defined consumption per piece — metres of shell fabric, metres of lining, number of buttons, labels, thread, polybags, cartons — plus wastage and shrinkage allowances that reflect reality rather than theory.

Because consumption is stored per piece, the moment an order is placed the BOM explodes against the ordered quantity to produce a precise material requirement. Roll that across all open orders and you get a clean buy plan: exactly how much greige, dyed fabric and each trim a season needs — no more, no less. This is what turns fabric from your biggest leakage into a controlled cost.

What a good style BOM prevents

• Over-buying fabric because nobody netted requirements across orders.
• Under-buying trims and stalling a line two days before ship.
• Costings done by hand, late, and never quite matching the invoice.

The size-colour matrix is the grid where a style’s sizes meet its colours. Instead of typing twenty variant lines, a merchandiser enters a buyer’s size ratio once — say 1:2:2:2:1 across S to XL — and Pixel ERP breaks the order into the full grid automatically. That same grid then follows the order everywhere: stock, work-in-progress, cutting, quality, packing and dispatch are all captured across the matrix, not one SKU at a time.

This is the single biggest relief a garment ERP delivers. Cut pieces are recorded by size and colour, stitched pieces come back by size and colour, packing assorts by the same ratio, and dispatch ships against it. At any moment you can see, for one order, how many pieces are cut, stitched, packed and pending — for every cell of the grid.

The power comes from the two working together. The size-colour matrix gives you the quantities; the style BOM gives you the per-piece consumption and cost. Multiply them and you get everything downstream: material requirements for procurement, expected fabric for the cutting room, and a live style costing that rolls fabric, trims, CMT, job-work and overhead up per style and per order.

Because that costing compares planned versus actual as production happens, you know your real margin before you confirm a price rather than after the season closes. To see this drive an entire order end to end, read our walkthrough on how Pixel ERP runs a garment factory from PO to dispatch, and for the outsourced legs of production, our post on job-work and subcontracting.

No two apparel houses use the same size sets, colour codes, ratios or buyer formats. Pixel ERP absorbs that through no-code configuration — size sets, colour libraries, ratio templates, packing formats and buyer-specific documents are all settings, not development. A new buyer’s odd size break or an extra trim on a style is a configuration change, so the product fits your merchandising instead of forcing you to change it. And because delivery is phased, you pay on milestones we meet rather than a large upfront lock-in. Explore the wider product on the Pixel ERP page and the sector fit on the textiles & apparel page, or dig into the pillar garment ERP overview.

The size-colour matrix is not an abstract idea — it is what your cutting master and packing team actually work with every day. In the cutting room, the lay plan and cut quantities are entered against the grid, so you can see at a glance that you have cut, for example, more mediums in navy than the order needs and fewer smalls in white. That imbalance shows up immediately, not after garments are stitched and it is too late to fix cheaply.

In packing, the same matrix drives assortment and ratio packing. Because Pixel ERP already knows the buyer’s ratio, it can build assorted cartons that match the order exactly, generate the packing list, and check that what you are shipping equals what was ordered — cell by cell. Barcode-ready cartons carry that assortment forward, so the warehouse and the buyer see the same numbers you do.

Where the matrix earns its keep

• Cutting: spot over- and under-cutting by size and colour before stitching.
• WIP: see pending pieces per cell, in-house or at a job-worker.
• Packing: assorted and ratio cartons built automatically from the order.
• Dispatch: ship-quantity reconciled against ordered quantity, per variant.