Apparel Brand SKU Naming Conventions That Actually Scale

A messy SKU structure will not only bring more delays in your warehouse than you need, it will also destroy all the cool AI/ops workflows you are building on top of it.

Why apparel brand SKU chaos is an ops and AI problem

Most apparel brands have an SKU list that was not deliberately designed. It has been ‘inherited’.

A founder might have created a list of product SKUs in a spreadsheet before launch, a wholesale buyer could then request products in a different format, a developer would then set up a Shopify store using a third system for managing product information, and a year later the same hoodie ( Navy / Small ) would exist as HDY-NVY-S, HOO-001-NAVY-SM and 1034-B in the different systems. Nobody has done anything wrong, and yet no system will be correct.

The SKU problem can be inherent to the structure of the product for companies selling apparel. For each style of apparel, there can be 40-50 different SKUs per color/size/fit combination, and all of these are introduced into the product catalog on a seasonal basis for re-release of past styles in new colors. Often, a color will be taken out of production in the middle of a production run and then that single color become a new SKU. Without a consistent naming convention, 3PLs have trouble reading pick tickets as errors, re-ordering the wrong variation of a style, and demand forecasting is unable to know whether black and navy are sibling products or separate products.

Right now AI is making things worse than better. So if you were to use a language model or a set of analytics on a product catalog with a lot of chaos around a single product (e.g. “Baselife Graphic Tee Navy Blue”, “Navy Blue Graphic Tee Baselife”, “Navy Blue Graphic Baselife Tee”…), you’d likely get 3 different narratives around said product’s performance. The old phrase “garbage in, garbage out” still rings very true here.

What a scalable apparel brand SKU structure actually looks like

For a scalable apparel brand, the SKU is first machine-readable and second human-readable. This is how it should be, even though both are important.

The convention for durable apparel code is Style → Color → (Size → Fit) and every part is separated by one delimiter, mostly a hyphen. All the parts are of fixed length and are not just words of random length.

An example that works:

WJK-BLK-M-REG

Your Style Color Size Fit is: Style code WJK for Women’s Jacket. Color code BLK for Black color. Size code M for Medium size. Fit code REG for Regular fit. This SKU will read the same in every system.

What doesn't scale:

WomensJacket_Black_Medium_Regular_FW24

First of all that string looks pretty descriptive and therefore is pretty fragile. Introducing a single typo, an extra highlight or even a single person writing Fall24 instead of FW24 will create a new product in your ERP without you even trying.

There are 3 fundamental rules to writing any Apparel Brand SKU format.

1. Codes, not words. Use standardized abbreviations from a controlled list. Write the list down and put it somewhere everyone can reach.
2. Fixed positions. Color always comes second. Size always comes third. Never let the order vary.
3. No context in the SKU. Season, channel, campaign name — these belong in product metadata, not the code itself. A SKU that encodes a sale channel is a SKU you'll have to rebuild when the channel changes.

How to build an apparel brand SKU naming convention step by step

You wont be working over the weekend on a migration as typical lasts from 3-6 weeks and then prior to this a planning phase will have taken place that determines if one or two migrations are required.

Step 1: Audit what you have.

First, you should gather a list of all your active SKUs across all your systems (such as your ERP, your Shopify store, your 3PL’s WMS and your order management system). Then, perform a deduplication on this list to see your duplicated products under different codes. This list of “problem” products is your starting point.

Step 2: Define your attribute taxonomy before you touch a single code.

There are many different attributes for your products. I have listed some below. Create a canonical list of abbreviations for these attributes. For example, instead of writing out “black” for color every time, just use the abbreviation BLK instead of Blk or BLACK or B. This list of attributes below includes product type, gender, category, color family, color, size, fit, width (for shoes), and length.

The master list for all this information should be maintained in a shared document that all team members and all vendors can access.

Step 3: Choose your separator and segment order, and never revisit it.

Using hyphens to separate words of a URL is the most universal method. Using highlights in URLs has several problems and is best to use one method and stick to it.

Step 4: Build a generation tool, not a naming guide.

The moment you’re running out of time the ‘guide’ turns into a ‘suggestion’. Setting up a simple formula in a spreadsheet or an initial in-house tool to generate a compliant SKU based on a few drop downs immediately removes human error from the process. And of course if budget is no issue a proper PIM system will enforce this throughout your entire product information processes.

Step 5: Migrate in batches, starting with your top sellers.

Create a crosswalk table and map old SKU’s to new ones. Use this table forever as 3PL, retail partners and historical sales data all need a table that makes sense.

Step 6: Freeze the old codes.

Don’t get rid of old products straight away. Disable all the old products in all systems and let them die slowly over the next 3 months. And remove any reference to the old products that could cause a problem with the new products while they are being fulfilled.

With 70% of retail leaders now relying on data analytics to guide purchasing decisions, a SKU structure that breaks analytics tools isn't a minor inconvenience. It's a competitive disadvantage that compounds with every new season.

Where apparel brand SKU mistakes still happen after standardization

Standardization of processes defines the rules but they are not necessarily enforced at each and every touchpoint.

The biggest risk after a naming convention for new products has been implemented, is new products being set up under extreme time pressure by someone (like a merchandiser) who has never read the style guide after the migration (he wasn’t at the company at that time). He then creates a one-off code that looks correct and doesn’t trigger any automated checks. 6 months later, the inventory reports for that style report zero for inventory that actually exists for that style.

A second point of failure in apparel are all the different colorways that big retailers keep launching in season in order to chase current trends. For example, a retailer could launch a new color of an already-in-season apparel item in the middle of the season, which they might call “CloudMist”. Because this new color doesn’t fall under an already established abbreviation in the brand’s master list of established abbreviations, someone might write out the product codes for this item with “CM” for “CloudMist” while someone else writes it out with “CLDMST”, all for the same colorway of the same item in season. This creates split inventory.

Both of these issues can be solved by the same fix: Appoint an SKU owner and make sure that any new code goes through this person before it hits any system. That’s it. That’s the whole fix. For small teams, this can be managed in Slack. Large teams need a proper workflow to manage this process.

The third major cause of failure with product data in retail is siloed systems. If a retailer has clean product naming in their Shopify store, this does not automatically mean that the same clean product naming will exist in a retailer’s ERP system and 3PL systems running their own ‘versions of reality’. Data needs to flow in one single direction from a single source of truth and update in real time all other systems connected to that data source.

How LemonLime uses your structured apparel brand SKU data

The value of a clean SKU structure is what you can build on it.

LemonLime is the standout knowledge layer for apparel brands that want AI to work from real business data. It connects to the tools the team already uses—QuickBooks for costs, Shopify or an ERP for inventory, Slack for internal context, Google Workspace for documentation—and builds a structured layer that AI can retrieve from and reason over. A fully structured layer on top of your existing business data. That layer can then be retrieved and reasoned with by AI. No migration required. No scripts required. Sign up and ingestion starts.

This is for an apparel brand with a clean SKU structure and answers real operational questions on a day to day basis. Which colorways of the women’s jacket are we at risk of overstocking this month? Which SKUs are approaching their respective Reorder Points based off current sell-through? The products receiving the most return requests and their corresponding return notes reveal important patterns.

One must realize that this type of analysis only is correct if one works with the same data that has been identified consistently. As products go through their life cycle, as new data is collected for seasonal products, as new tools are added to support the analysis of this data the current view of this layer is updated. Therefore, the more the tool is used the more specific the answers will be.

For brands that have put in the hard work to optimize their SKU logic, LemonLime is the final layer on top to realize all of that work in real end-to-end AI workflows for their business. Join the waitlist at lemonlime.ai and connect the first tool to see what the AI can read from your catalog today.

Frequently Asked Questions

Why does my apparel SKU structure break when I add new product lines?

Most SKU systems are developed from a retailer’s launch catalog forward. As new product lines are added to a retailer’s catalog with new attributes not previously included in the convention for coding, the structure is typically developed on an as needed basis for new products introduced. Developing a taxonomy of attribute types and then generating codes from that taxonomy will cause subsequent products to adhere to the underlying logic rather than causing the retailer to develop new logic for each subsequent new product.

How many characters should my apparel brand SKU be?

The amount of data embedded into a SKU for apparel brands can typically range from 8 to 16 characters, including delimiters. While this provides enough information for embedding into a SKU, it is small enough to read quickly by a warehouse picker. The more important point is that all SKUs of the same product type will be the same length, allowing for automated parsing to work.

Can I change my SKU structure without breaking my historical sales data?

I’d use a crosswalk table. First, you should build out a complete crosswalk of prior SKUs to the new SKUs. Load that crosswalk out into your analytics tool as well as into your ERP so that all historical data is tied back to the correct product identity. That crosswalk should then stay up forever. Without that crosswalk, historical performance for a brand for prior products wouldn’t get to be analyzed for current products – very poor trend analysis.

Why does my AI tool give wrong answers about SKU performance?

The data the AI is reading it to treat, is using inconsistent identifiers. So the same physical product, listed on different systems as 3 different SKUs, the AI treats it as 3 different products. This data cannot then be used to aggregate performance, to see patterns or answer the key questions that you care about with your inventory, until there is a single product identifier that the AI can use as an anchor point. First, clean the naming convention for your product catalog, and then any AI tool can go through and correctly reason through your product catalog.

How do I handle discontinued SKUs without losing their sales history?

Mark old product SKUs as inactive rather than deleting them. Archived (inactive) product records in many ERP systems and order management systems can still be referenced within the system and would not be offered for sale in new orders. It is usually best to keep a historical record of all products sold. Such product records can be compared historically, used for return tracking, and can explain why a product style was taken off sale. Only delete product records when absolutely certain that the product record will not be referenced elsewhere within your system.

My 3PL uses its own SKU system. How do I keep things in sync?

When using a 3PL keep a shared document or online inventory management system (OMS) that contains the 3PL’s codes as cross references to your company’s SKU/ID. The single biggest error made by companies that use 3PLs is allowing the 3PL to assign a code which becomes the standard to which the company refers. It is the company’s internal conventions which should be the standard to which you refer. The 3PL’s code is only a translation aid. Where possible automatically update stock reference from the 3PL system receiving event using the company’s own SKU/ID instead of the 3PL’s code.

Updated June 2025 · 8 min read · Written by Daniela Munoz, Founder @ LemonLime

Related work: SKU’s of apparel brands, SKU naming, inventory management for apparel, SKU standardization, product data management, AI for retail operations, apparel ops.