The product information side of the matrix: define size scales, two-dimensional sizing, color ranges and UPCs once on the style master, and every order, catalog, channel and document inherits the definition.
Before inventory can be counted by style, color and size, someone has to define what those are: the size scales, the color ranges, the second dimension when a category needs one, and the UPC behind every cell. In AIMS360 that definition happens once, on the style master, and every order, pick ticket, invoice, catalog and sales channel inherits it. This page is about that defining side. The counting side lives on our style, color, size inventory page.
The size matrix is where product information gets its structure. You define a style once, attach a color range and one or two size dimensions from reusable size scales, and AIMS360 generates every SKU in the grid and assigns each one its own UPC. From that single definition, order entry gets its grid, the warehouse gets its barcodes, EDI and retailer catalogs get their codes, and Shopify gets its variants. Define once, inherit everywhere, and never hand-key 42 products to launch one style.
Most data problems that show up later in the season, a mislabeled carton, a mismatched catalog, an invoice line a retailer rejects, trace back to product information that was keyed twice in two places. The size matrix exists so there is exactly one place, and everything else is a reader.
Three terms carry the whole setup model, and they nest inside each other.
A named, reusable list of sizes: S through 3XL, women's 0 to 16, waists 28 to 40, half sizes 5 to 13, ring sizes 4 to 12, fill sizes 30ml to 100ml. You define a scale once and attach it to every style that uses it, so "misses alpha" means exactly the same thing on every style, every season, every report.
An axis of the grid. Color is one dimension. Size is another. Some categories need a second size dimension, waist and inseam, chest and length, band and cup, size and width, and that is where a system either supports true two-dimensional sizing or forces you to fake it with mangled size names like 32X34 crammed into a flat list.
The grid those dimensions produce for one style: every color and size combination as its own SKU, each with its own UPC per GS1's GTIN rules. The matrix is generated from the definition, not keyed by hand, which is why one style with 42 variants is one setup task rather than 42.
Retail speaks in standardized color and size codes, the tables maintained for decades by the National Retail Federation and moved to GS1 US in 2020. AIMS360 carries those codes on the color range and size scale, so what a buyer's system calls color 001 in size 32X32 maps cleanly to what your team calls Black in a 32 waist, 32 inseam.
Plenty of products have a size. A meaningful share of consumer categories have two, and pretending otherwise is how flat systems corrupt product data.
| Category | Dimension 1 | Dimension 2 | What a cell looks like |
|---|---|---|---|
| Denim and pants | Waist, 28 to 40 | Inseam, 30 to 34 | 32x34 |
| Suits and tailored | Chest, 38 to 46 | Length, Short, Regular, Long | 42R |
| Dress shirts | Neck, 14.5 to 18 | Sleeve, 32/33 to 36/37 | 16 34/35 |
| Bras and intimates | Band, 32 to 40 | Cup, A to DD | 34C |
| Footwear | Size, half sizes 5 to 13 | Width, N, M, W | 9.5W |
In AIMS360 the second dimension is part of the size scale definition, so a 42R is genuinely a cell at the intersection of chest 42 and length Regular, not a string that happens to contain a 42. That distinction sounds academic until you need sell-through by length, a curve by inseam, or a retailer's EDI order that specifies both axes in standardized codes. If you want to see these grids populated with live quantities, the worked examples for every category, footwear, suits, swimwear, beauty and jewelry included, are on the style, color, size inventory page.
Style number, description, category, season, and the attributes your business reports on. This is the parent record everything else hangs from.
Your colorways, each carrying its standardized color code so retail documents and catalogs translate automatically. Adding a colorway later extends the matrix in one step.
Pick the reusable scale, or two dimensions where the category needs them. No re-typing S, M, L for the thousandth time, and no two styles quietly disagreeing about what the run is.
Every color and size combination becomes a SKU automatically. A style in 6 colors on a 7 size scale is 42 SKUs you did not key by hand.
Each variant gets its own UPC from your GS1 company prefix, satisfying the one GTIN per variant rule retailers and marketplaces enforce. The barcode on the ticket, the line on the EDI order and the catalog entry are all the same number.
The GXS OpenText catalog gets the UPCs and attributes, EDI documents read and write at the variant level, Shopify gets its variants, and order entry gets its grid. One definition, every consumer.
A seasonal line of 24 styles on shared scales is 24 definitions, not 1,008 hand-keyed products. The difference between those two numbers is someone's week, every season, plus every typo that week would have produced.
When every style on the "misses alpha" scale shares one definition, reports, curves and comparisons line up automatically. In flat systems, consistency depends on everyone typing size names identically forever. They do not.
Add a colorway and the matrix extends: new SKUs, new UPCs, catalog and channels updated from the same definition. Extend a scale for inclusive sizing and the styles that use it follow deliberately, not one by one.
Chargebacks for wrong tickets, catalog rejections, mismatched invoices and variant mapping errors are mostly product information failures. Defining the matrix once removes the second copy of the truth those failures grow from.
Same grid, two jobs. This page and the style, color, size inventory page split them deliberately.
| Size matrix and dimensions (this page) | Style, color, size inventory | |
|---|---|---|
| The question | What exists to sell? Which sizes, colors, dimensions, codes? | How many exist, where, and who can have them? |
| The objects | Style master, color ranges, size scales, UPCs, attributes | Stock levels, availability, allocations, picks, counts |
| When it happens | At line adoption and product setup, then rarely | Continuously, every order and every scan |
| Who owns it | Product, design and merchandising teams | Operations, warehouse, sales and planning |
| What failure looks like | Wrong codes, rejected catalogs, mislabeled tickets | Oversells, broken runs, chargebacks at the dock |
The grid a style's dimensions produce: colors on one axis, sizes on another, every cell a distinct SKU with its own UPC. In AIMS360 the matrix is generated from the style definition, so creating a style in 6 colors on a 7 size scale creates 42 sellable variants without keying them individually.
A named, reusable list of sizes, like S to 3XL, waists 28 to 40, or half sizes 5 to 13, defined once and attached to any style that uses it. Reusable scales are what keep size data consistent across a whole line, and they are also where size curves live, so buys and allocations inherit the ratio.
The axes of the grid. Color is a dimension, size is a dimension, and some categories need a second size dimension: waist and inseam for denim, chest and length for tailored clothing, band and cup for bras, size and width for footwear. AIMS360 supports the second dimension natively, so a 42R is a real cell, not a size name with a letter glued on.
Yes. That is exactly what two-dimensional sizing is for: waist by inseam, neck by sleeve, chest by length, band by cup, size by width. Both axes are part of the size scale definition, both carry their own codes, and reporting can slice by either, which is how you learn that your 34 inseam sells out while the 30 lingers.
From your GS1 company prefix, one UPC per variant, generated when the matrix is created. GS1's GTIN management rules require a distinct GTIN for every size and color variant, and retailer purchase orders arrive one line per UPC, so the assignment is not optional bookkeeping. It is the identity every downstream document runs on.
Through the standardized color and size code tables American retail uses in EDI and product catalogs, maintained historically by the National Retail Federation and by GS1 US since 2020. AIMS360 stores those codes on your color ranges and size scales and syncs them with UPCs and attributes to retailer catalogs like the GXS OpenText catalog, so buyers see your products in the codes their systems expect.
Yes, that is the point of scales being named objects rather than per-product lists. Every style on the same scale agrees about the run by construction, new seasons attach existing scales in one step, and a deliberate scale change, like extending into inclusive sizing, rolls out consciously instead of style by style.
The matrix extends from the same definition: the new color joins the range with its code, the new SKUs generate across the size run, UPCs assign, and catalogs and channels update from the one record. What does not happen is someone hand-creating a dozen products at 11pm and hoping they match the originals.
Yes. Shopify variants map to the matrix cells, so options and variants on the storefront correspond to real SKUs with real UPCs, and a size that sells out disappears from the site because the same record that defined it also counts it.
The size axis is optional, so bags, scarves and one-size accessories collapse to style and color without a fake size invented to satisfy the software. The matrix should describe the product, not the other way around.
Same matrix, different job. This page covers the product information side: defining scales, dimensions, colors, codes and UPCs on the style master. The inventory page covers the operational side: stock by cell, availability, allocation, picking and reporting against that definition. In AIMS360 they are one record, which is precisely why both work.
The honest way to say it: a 24 style line on shared scales is 24 definitions instead of 1,008 hand-keyed products, and each definition is minutes of work. The bigger saving is usually not the keystrokes. It is the absence of the cleanup project that follows a season of manual variant entry.
Last reviewed 8 August 2026 by the AIMS360 product team. The one GTIN per size and color variant rule is from GS1's GTIN Management Standard, and the standardized retail color and size code tables formerly maintained by the National Retail Federation transitioned to GS1 US in 2020. Setup and sizing examples are illustrations of how the size matrix works, not customer data. Statements about flat or generic tools describe typical single-list variant handling, not any specific product.
Bring a line sheet to a demo and watch a style go from definition to generated SKUs, assigned UPCs and synced channels in one sitting.
