For retailers and wholesalers whose integrations keep failing to match products

SKU and Barcode Structure: The Join Key Every Integration Depends On

When an order flows from your website to your ERP, from the ERP to your 3PL, and from a marketplace back into stock, the only thing holding those records together is the SKU. The product name, description and supplier code do not do that job. If the SKU is ambiguous, duplicated, reformatted or quietly changed, every integration built on top of it inherits the problem, and the symptoms show up as phantom stock, rejected orders and dispatch errors nobody can trace.

This page is about the identifiers themselves: what makes a SKU safe to integrate on, how barcodes and GTINs fit alongside it, how to handle variants and pack levels, what to do about the duplicates you already have, and how to rename codes without breaking history. It is deliberately practical, and it says plainly when your existing codes are good enough to leave alone.

Book a SKU Structure Review (03) 9003 0111

Identifiers in Numbers

4 to 7 systems

Can share one SKU in a multichannel retailer

POS, ecommerce, ERP or inventory, 3PL, one or more marketplaces and often the accounting system, and the count varies by business

1 key

Should identify one sellable thing, forever

A SKU that is reused, shared or redefined breaks every system that remembered the old meaning

2 identifiers

Per sellable unit: your SKU and its barcode

They do different jobs, and conflating them is a common structural mistake

Weeks, not days

For a duplicate cleanup on a large range

Rough guide, it depends on range size and how much history hangs off each duplicate

Four Reasons SKU Structure Decides Whether Integrations Work

Integrations match records by key. Everything else, from stock levels to settlement lines, hangs off that match.

The SKU is the join key across the whole stack

Your POS, ecommerce platform, ERP, 3PL and marketplaces each hold their own product record with their own internal ID. The SKU is usually the only value they all share, so it is what an integration uses to say this line on this order is that item in that warehouse. If two products share a SKU, the integration cannot tell them apart. If one product has two SKUs, stock and sales split across both. Neither failure produces an error message, but both produce wrong numbers.

Systems disagree about what a valid code looks like

One system treats ab-100 and AB-100 as the same code and another treats them as different. One allows spaces and slashes, another rejects them, and a third accepts them but breaks when the code appears in a web address or a file name. One caps the field at 20 characters and another at 40. A spreadsheet in the middle strips leading zeros. A SKU that is valid in the system where it was created can be silently altered or rejected two hops downstream.

Barcodes are a separate identifier with separate rules

A barcode, usually a GTIN printed as EAN-13 for retail goods in Australia, identifies the product to scanners, retailers and marketplaces. Your SKU identifies it to your own systems. They can coexist on the same record and often should, but they follow different rules about who issues them, when a new one is required and whether they can ever be reused. Treating the barcode number as your SKU, or the SKU as a barcode, mixes two sets of rules that conflict.

Codes outlive the people who created them

A SKU created today will be referenced by orders, invoices, stock movements, returns and reports for years. Whoever invents codes on the fly to get a product live this afternoon is making a decision that every integration and every future system migration will have to live with. That is why structure and governance matter more here than in almost any other part of product data.

The Rules That Make a SKU Safe to Integrate On

Six design rules. None are complicated, and many identifier problems trace back to breaking one of them years ago.

One code, one thing

Unique and never reused

Each SKU identifies exactly one sellable item for its entire life and after it. When a product is discontinued, its SKU retires with it. Reusing a retired code for a new product looks tidy in the catalogue and corrupts history everywhere else: last year’s sales report now shows the new item, a returned old unit is booked into stock as the new one, and the 3PL may still hold a pick face labelled with the old meaning. Some platforms enforce uniqueness and some do not (Shopify, for example, will let two variants share a SKU), so do not rely on the software to stop you.

No forced renames

Stable when attributes change

Price, supplier, description, category and even packaging artwork change over a product’s life. The SKU should not have to. Codes that encode things likely to change, such as the supplier, the season, the price band or the current colour name, eventually become wrong, and then you face a choice between a misleading code and a rename that every integration has to absorb. Encode only attributes that define the item and will never change while it is the same product.

Survives every hop

System-safe characters

A practical safe set: uppercase letters A to Z, digits, and a single separator such as a hyphen. Avoid spaces, slashes, ampersands, full stops, commas, quotes and accented characters, which break URLs, CSV files, file names and some APIs. Never start a code with a zero, because spreadsheets drop it. Avoid all-numeric codes of 12 or more digits, which spreadsheets may convert to scientific notation and which are easily mistaken for barcodes. Check the shortest SKU length limit across every system in the chain, marketplaces included, and design to that.

A deliberate trade-off

Intelligent or non-intelligent

An intelligent SKU encodes meaning, for example TSH-ORG-NVY-M for an organic navy tee in medium. Staff can read it on a pick slip and spot errors. A non-intelligent SKU is just a sequence, for example 100482, which never becomes wrong but tells a picker nothing. The common middle path is a short, stable style prefix plus variant suffixes for size and colour only, with everything else held in proper attribute fields. Whichever you choose, write the rule down so the next person follows it.

Style vs sellable unit

Parent and variant structure

Most platforms model a parent product, often called a style, and its variants. Only the variant is sellable, stocked and scanned, so only the variant SKU should travel through order, stock and fulfilment integrations. The style code is useful for grouping and reporting and should be held as a separate field. A common failure is a single-variant product where the parent and variant share one code, which then collides when a second size is added later. Give the variant its own code from day one.

Their code, your code

Supplier codes kept separate

Using the supplier part number as your SKU is tempting and almost always regretted. Suppliers change their numbering, two suppliers use the same number for different things, and the day you switch supplier for the same product your SKU becomes a lie. Hold the supplier code in a dedicated supplier item field, one per supplier where you dual source, and map to it on purchase orders. Your SKU stays yours.

Common SKU and Barcode Situations and How to Handle Them

Task	Traditional	Done Properly	Notes
New product being set up	Code invented by whoever is adding it	Issued from one owner using a written rule	A short convention document and a single creating system prevents most future duplicates.
Selling on a marketplace	Barcode made up or borrowed	GS1 issued GTIN on each variant	Marketplaces commonly require GS1 issued barcodes. Check each marketplace’s current rules and any exemption process.
House-made or weighed goods sold only in store	No barcode, keyed at the till	In-store barcode for internal use	Fine for items that never leave your own stores. Not acceptable for goods supplied to other retailers or marketplaces.
Same product sold singly and by the carton	One barcode for both	A distinct barcode per pack level	Each sellable or shippable pack level needs its own identifier. The conversion maths belongs on the unit of measure page.
Supplier changes their part number	Your SKU renamed to match	Supplier code field updated, SKU unchanged	Purchase order mapping changes. Sales history, stock and channel listings do not.
Two SKUs found for one product	One deleted, stock adjusted by hand	Survivor chosen, retired code mapped to it	History and open orders exist on both. Merge deliberately, never by bulk delete.
Old codes no longer fit the convention	Whole range renamed over a weekend	Left alone, or renamed with a crosswalk	Renaming is only worth it if the old codes are actively causing failures.
Integration rejects a SKU	Code tweaked in one system to get it through	Rejection queued, rule fixed at the source	Editing the code in one system creates the exact mismatch the integration was meant to prevent.

Where SKU and Barcode Structures Break Integrations

Reusing a SKU or a barcode

A retired SKU given to a new product contaminates every report, return and stock record that remembers the old one. Barcodes are stricter still: since 1 January 2019 GS1 rules say a GTIN assigned to one trade item must not be reassigned to another, with only narrow exceptions such as a number for an item that was never produced. A reused barcode can scan as the wrong product at a retailer or be matched to the old listing on a marketplace. Treat both as never reused.

Barcodes from an unofficial source

Cheap barcode numbers resold outside the GS1 membership system may scan perfectly well at your own till and still fail marketplace or retailer checks, because the company prefix is not registered to your business. Barcodes issued through GS1 Australia membership are licensed to you and traceable to you. If you supply other retailers or plan to list on marketplaces, this is not the place to save a membership fee.

Spreadsheets rewriting codes in transit

A product export opened and saved in a spreadsheet can drop leading zeros, turn long numeric codes into scientific notation, auto-format codes that look like dates, and trim trailing spaces. The file then imports cleanly and creates mismatches. Import code columns as text, keep a validation step that compares codes before and after any manual file handling, and prefer direct system to system flows for product data where you can.

Case and whitespace differences between systems

If one system matches case sensitively and another does not, ab-100 and AB-100 can be two products in one place and one in the other. Invisible trailing spaces do the same thing. Standardise on uppercase with no leading or trailing spaces, normalise at the integration layer as a safety net, and report any code that needed normalising rather than fixing it silently, so the source gets corrected.

Renaming SKUs without a migration plan

Changing codes in the master system while connected systems still hold the old ones breaks order import, stock sync and 3PL receipts at once, and marketplaces may treat the renamed item as a new listing and lose its reviews and ranking. A rename needs a crosswalk table, a cutover sequence for every connected system, a period where both codes are recognised, and a check that open orders and in-transit stock resolve correctly.

Anyone can create a SKU anywhere

When products can be created in the POS, the website and the ERP independently, duplicates are close to certain. Pick one creating system, restrict creation rights to a small group of named people, and make other systems receive products rather than invent them. The aim is to make sure the same product cannot be created twice.

How Yes AI Approaches SKU and Barcode Structure

An audit before any opinion

We extract SKUs and barcodes from every connected system and compare them: duplicates, near-duplicates differing only by case or spacing, codes present in one system and missing from another, illegal characters, length breaches, shared barcodes and supplier codes masquerading as SKUs. You get a list ranked by how much damage each issue is actually doing.

A written convention you can follow

A short document covering the character set, length, structure for styles and variants, how pack levels are identified, where supplier codes live, who issues GTINs and who may create a SKU. Written so a new staff member can apply it without asking.

Cleanup and crosswalks done carefully

Duplicate resolution, survivor selection and any necessary renames, staged so connected systems are updated in a safe order with both old and new codes recognised during the transition. The crosswalk table is kept permanently, because old codes will keep turning up on returns and in reports.

Enforcement in the integration layer

Integrations we run on a managed cloud automation layer validate codes on the way through: unknown SKUs, invalid characters and barcode check digit failures are queued with a reason rather than forced through or dropped. And if your existing codes are workable, we will say so and build around them rather than sell you a rename.

From Messy Codes to a Structure Integrations Can Trust

Five steps. For many businesses the honest outcome of step two is that most existing codes stay as they are.

Extract and compare

Pull product identifiers from the POS, ecommerce platform, ERP, 3PL and marketplaces, and line them up to find duplicates, gaps, invalid codes and barcode conflicts across the stack.

Decide what to leave alone

Separate codes that are merely untidy from codes that are causing failures. Untidy but unique and stable codes usually stay. Only the harmful ones go into the cleanup scope.

Write the convention and governance

Agree the rules for new codes, the parent and variant structure, pack level identification, supplier code fields, GTIN sourcing and the named people who can create products.

Clean up with a crosswalk

Resolve duplicates, retire and map bad codes, and update each connected system in a planned order, with the crosswalk recognised by integrations during the transition and kept afterwards.

Validate continuously

Integrations check every code they touch, queue anything unknown or malformed for a named owner, and a periodic comparison across systems catches drift before it becomes a stock problem.

FAQ

What is a good SKU naming convention?

A good SKU is unique, never reused, short enough for the most restrictive system in your stack, built from uppercase letters, digits and a single separator such as a hyphen, and stable for the life of the product. If it carries meaning, limit that meaning to attributes that define the item and will not change, typically a style prefix plus size and colour for variants. Anything that might change, such as supplier, season or price band, belongs in attribute fields rather than in the code. Write the rule down and give one small group the right to apply it.

Should we use intelligent or non-intelligent SKUs?

Both work if applied consistently. Intelligent SKUs are readable on the warehouse floor and make picking errors easier to spot, but they tempt people to encode attributes that later change. Non-intelligent sequential codes never become wrong but give staff no clues. For most Australian retailers and wholesalers with apparel, footwear or variant-heavy ranges, a short meaningful style prefix with size and colour suffixes is the practical middle path. For ranges without variants, a simple sequence with good attribute data is often the cleaner choice.

Do we need GS1 barcodes in Australia?

If you only sell through your own stores and website, you can operate with internally generated barcodes, although a GS1 issued GTIN is still the cleaner long term choice. If you supply other retailers, sell on marketplaces or plan to, you will commonly need GTINs issued through GS1 Australia membership, because major retailers and marketplaces generally check that the barcode is registered to the brand owner. Requirements differ and change, so check each marketplace and retailer’s current rules, including any exemption process for products that lack a barcode.

Can we use our barcode as our SKU?

You can, but it is usually a poor idea. Barcodes follow GS1 rules about when a new number is required, for example when the product or pack changes in certain ways, and those rules do not line up with when your internal code should change. Many items also have no barcode, several pack levels have different barcodes, and long numeric codes are vulnerable to spreadsheet corruption. Keep the SKU as your internal key and the GTIN in its own barcode field on the same record, and let integrations match on either where appropriate.

How do we rename SKUs without breaking our integrations?

Build a crosswalk table first, listing each old code, its new code, the effective date and the status. Then update connected systems in a deliberate order, usually the master system and the integration layer first, followed by the 3PL, channels and marketplaces, with the integration recognising both codes during the transition. Check open orders, in-transit purchase orders and stock on hand resolve correctly before retiring the old code. Keep the crosswalk permanently, because returns, old invoices and historical reports will keep referencing the old codes for years.

How should we clean up duplicate SKUs before an integration project?

Find them across every system, not just one, including near-duplicates that differ only by case, spacing or a stray character. For each set, pick a survivor based on which code carries the most history and the cleanest data, map the retired codes to it in the crosswalk, consolidate stock deliberately with a documented adjustment, and update channel listings. Do this before the new integration goes live. Connecting systems on top of duplicates simply automates the confusion and makes it harder to unpick afterwards.

Our existing SKUs are inconsistent. Do we have to change them?

Often not. Codes that are unique, stable and use characters every system in your stack accepts are safe to integrate on, even if they follow three different historical patterns. Renaming carries real cost and risk, particularly on marketplaces where a changed code can mean a new listing. We usually recommend leaving workable codes alone, fixing only the ones that are duplicated, invalid or actively causing failures, and applying a clean convention to new products from now on. The range tidies itself gradually as old lines are discontinued.

Make Your SKUs Something Integrations Can Rely On

Book a call. We compare the codes across your systems, show you which issues are actually costing you, and give you a convention and a cleanup plan scoped to what matters. If your codes are fine as they are, we will tell you.