Lo SKU è un codice interno usato per identificare e gestire in modo univoco un prodotto o, più spesso, una sua specifica variante all’interno di un catalogo. L’acronimo significa Stock Keeping Unit e diventa particolarmente utile quando devi controllare scorte, ordini, resi, report e sincronizzazioni tra ecommerce, magazzino e altri sistemi.
Un esempio chiarisce subito il concetto. Se vendi la stessa maglietta in tre taglie e quattro colori, dal punto di vista dell’inventario non hai semplicemente “una maglietta”: hai dodici combinazioni differenti da riconoscere. Assegnare un codice diverso a ogni variante permette al sistema e alle persone che lo utilizzano di sapere esattamente quale articolo stanno movimentando.
La distinzione più importante è però un’altra: SKU, codice a barre e GTIN non sono sinonimi. Lo SKU nasce per l’organizzazione interna dell’azienda; un GTIN appartiene invece a un sistema di identificazione globale. Capire questa differenza evita parecchi errori quando il catalogo deve passare da un semplice negozio online a feed prodotto, marketplace, ERP, WMS o più sedi.
SKU: significato e definizione pratica
SKU significa Stock Keeping Unit, espressione che possiamo rendere come “unità di gestione delle scorte”. In pratica, è un identificatore assegnato dall’azienda per distinguere gli articoli che deve gestire.
Non esiste un’autorità internazionale che assegna questi codici e non esiste un formato universale obbligatorio. L’azienda può quindi definire la propria convenzione, purché i codici rimangano coerenti, univoci e compatibili con i sistemi nei quali verranno utilizzati.
Shopify li descrive come codici interni per tracciare inventario e vendite, mentre WooCommerce li tratta come identificatori univoci per cercare e monitorare prodotti e variazioni. La documentazione Shopify sulla gestione dell’inventario tramite codici prodotto e le impostazioni inventario dell’editor prodotti WooCommerce convergono quindi sullo stesso principio di fondo.
Cosa identifica davvero uno SKU
Il codice identifica normalmente una specifica unità logica del catalogo, non il singolo esemplare fisico uscito dalla fabbrica.
Prendiamo una felpa modello Urban disponibile in nero e grigio, nelle taglie S, M e L. Dal punto di vista commerciale puoi avere un solo “prodotto Felpa Urban”, ma dal punto di vista dell’inventario hai sei varianti differenti.
La felpa nera M e la felpa nera L devono essere distinguibili perché possono avere disponibilità, vendite e riordini diversi. È esattamente qui che il codice interno diventa utile.
Prodotto e variante: quando serve uno SKU diverso
La regola pratica è semplice: se due varianti devono essere monitorate separatamente, devono poter essere identificate separatamente.
Cambiare colore, taglia, capacità, finitura o un’altra caratteristica che determina una distinta voce di inventario richiede normalmente un codice differente. Shopify raccomanda un identificatore univoco per ogni variante; anche WooCommerce permette di assegnare SKU specifici alle variazioni.
Questo non significa che ogni attributo del catalogo debba entrare materialmente nel codice. Il colore può determinare la necessità di un identificatore diverso senza obbligarti a scriverlo per esteso nel codice stesso.
A cosa serve un codice SKU in magazzino e nell’ecommerce
Un codice ben progettato serve prima di tutto a ridurre l’ambiguità. Nome e descrizione del prodotto sono pensati per essere letti dalle persone e possono cambiare; il codice interno deve invece fornire al sistema un riferimento affidabile.
In un ecommerce può collegare la variante venduta alla relativa quantità disponibile. In magazzino aiuta a identificare cosa prelevare. Nei report consente di aggregare vendite e movimentazioni dello stesso articolo. Nei resi permette di risalire con maggiore precisione alla variante interessata.
Se utilizzi WooCommerce, questo identificatore entra quindi in un sistema più ampio di quantità, stato delle scorte e variazioni: nella nostra guida alla gestione dell’inventario WooCommerce trovi la parte operativa dedicata al controllo delle disponibilità.
Inventario e controllo delle scorte
Supponiamo che nel catalogo siano presenti:
| Articolo | Variante | SKU | Disponibilità |
|---|---|---|---|
| Felpa Urban | Nero / M | URB-BLK-M | 18 |
| Felpa Urban | Nero / L | URB-BLK-L | 7 |
| Felpa Urban | Grigio / M | URB-GRY-M | 12 |
Il nome commerciale rimane “Felpa Urban”, ma il codice permette di associare ogni movimento alla variante corretta.
Quando viene venduta URB-BLK-L, il sistema non deve interpretare descrizioni o cercare di capire quale “Felpa Urban nera” sia stata ordinata: dispone già di un riferimento preciso.
Picking, ordini, resi e assistenza clienti
La stessa identificazione può seguire il prodotto lungo diverse fasi operative. L’addetto al magazzino può utilizzare il codice durante il picking; l’ordine può conservarlo nella riga prodotto; l’assistenza può cercarlo durante un cambio; un’integrazione può usarlo per associare due record provenienti da sistemi diversi.
L’identificatore non elimina da solo gli errori. Se i codici sono duplicati, incoerenti o vengono modificati senza controllo, può diventare esso stesso una fonte di problemi.
Report, integrazioni e vendita multicanale
Il vantaggio diventa ancora più evidente quando il catalogo non vive in un solo software.
Un caso concreto è la sincronizzazione tra uno shop e Danea Easyfatt: se ecommerce e gestionale devono riconoscere la stessa variante, uno SKU coerente può diventare la chiave con cui associare prodotto, disponibilità e movimento di magazzino senza affidarsi soltanto al nome commerciale.
Quando il problema non è più soltanto identificare la variante, ma decidere quale sistema debba governare stock, prezzi, ordini e catalogo, entra in gioco l’architettura del gestionale per e-commerce: lo SKU resta la chiave di associazione, mentre il gestionale, l’ERP o un altro sistema devono avere responsabilità chiare sui dati.
Immagina ecommerce, gestionale, WMS, marketplace e software di spedizione che devono riconoscere la stessa variante. Un identificatore interno coerente diventa una chiave di associazione fra sistemi differenti. Quando questi sistemi devono anche restare coordinati su più canali, il problema passa dall’identificazione all’orchestrazione: nella nostra analisi di un gestionale multicanale come Poleepo puoi vedere come catalogo, marketplace, ordini e spedizioni vengono ricondotti a un flusso centrale.
Immagina di avere ecommerce, gestionale, WMS, marketplace e software di spedizione. Il nome dello stesso prodotto potrebbe essere scritto in modi diversi nei vari sistemi. Un identificatore interno coerente può invece diventare una chiave di associazione.
È anche il motivo per cui i duplicati sono pericolosi: Shopify avverte che codici duplicati possono creare problemi nel monitoraggio dell’inventario e nelle integrazioni con applicazioni di terze parti.
Esempio di codice SKU: come si legge
Non esiste un unico modo corretto di costruire il codice. Un possibile schema per un negozio di abbigliamento potrebbe essere:
TSH-042-BLK-M
Il codice potrebbe essere interpretato così:
| Segmento | Significato | Esempio |
|---|---|---|
TSH | Famiglia prodotto | T-shirt |
042 | Modello | Modello 42 |
BLK | Colore | Black / nero |
M | Taglia | Medium |
Una variante blu in taglia L dello stesso modello potrebbe diventare TSH-042-BLU-L.
Questo è un esempio di convenzione interna, non uno standard. Un’altra azienda potrebbe usare codici numerici completamente opachi come 483721, purché riesca a garantirne l’univocità e a gestirli correttamente.
La scelta tra codice “parlante” e codice opaco dipende soprattutto da come viene utilizzato. Se gli operatori devono riconoscere frequentemente gli articoli leggendo l’identificatore, una struttura moderatamente interpretabile può essere utile. Se tutta la gestione avviene tramite scanner e software, comprimere troppe informazioni nel codice offre meno vantaggi.
Come creare un codice SKU efficace
Un buon sistema non nasce cercando di infilare nel codice ogni informazione disponibile. Nasce decidendo quali elementi devono identificare stabilmente la voce di catalogo e quali devono invece rimanere normali attributi del database.
Un metodo pratico è questo:
- Definisci cosa rappresenta il codice. Decidi se verrà assegnato a ogni prodotto, variante o unità logica gestita separatamente.
- Scegli pochi attributi stabili. Modello, colore o taglia possono essere utili quando distinguono realmente le varianti; prezzo, quantità disponibile e posizione di magazzino normalmente non lo sono.
- Crea un dizionario delle abbreviazioni. Se
BLKsignifica nero, dovrebbe mantenere lo stesso significato in tutto il catalogo. - Garantisci l’univocità. Due record differenti non dovrebbero ricevere accidentalmente lo stesso codice.
- Progetta per la crescita. Lo schema deve poter accogliere nuovi prodotti e varianti senza essere riscritto dopo pochi mesi.
- Provalo nei sistemi reali. Verifica ricerca, importazione, esportazione, etichette e integrazioni prima di ricodificare l’intero catalogo.
Scegli gli attributi che devono distinguere il prodotto
Il criterio più utile è chiedersi: questa informazione descrive l’identità della variante o soltanto il suo stato attuale?
La taglia di una scarpa distingue una variante dalla successiva. La quantità disponibile cambia continuamente e non dovrebbe essere incorporata nell’identificatore.
Lo stesso vale per il prezzo: una promozione non deve costringerti a rinominare il prodotto nel gestionale. Anche la posizione fisica di magazzino può cambiare senza modificare l’identità dell’articolo.
Definisci una struttura coerente e scalabile
Uno schema funziona quando non richiede interpretazioni diverse a seconda di chi lo utilizza.
Se una categoria viene codificata con tre lettere, una con sei e un’altra con abbreviazioni improvvisate, il vantaggio del codice “parlante” si perde rapidamente. Meglio una convenzione più semplice ma documentata.
Conviene inoltre lasciare abbastanza spazio logico per nuovi modelli e varianti. Un sistema progettato su cinquanta articoli può diventare ingestibile quando il catalogo passa a migliaia di record.
Quanto deve essere lungo uno SKU?
Non esiste una lunghezza universale dello SKU. Le indicazioni che trovi online sono best practice di piattaforme o aziende, non uno standard internazionale.
Shopify, per esempio, suggerisce di mantenere i codici il più brevi possibile e indica come riferimento operativo una lunghezza non superiore a 16 caratteri, con schemi anche più corti quando il catalogo lo consente. È una raccomandazione della piattaforma, non una regola valida per qualsiasi ERP, WMS o ecommerce.
Il criterio migliore resta la lunghezza minima che conserva univocità, leggibilità e spazio di crescita.
Caratteri, separatori e convenzioni da usare
Per massimizzare la compatibilità, un formato alfanumerico semplice è spesso la scelta più prudente.
Trattini e underscore possono aiutare a separare i blocchi. È invece utile evitare combinazioni visivamente ambigue quando i codici vengono letti manualmente, per esempio 0 e O oppure 1 e I.
Shopify suggerisce inoltre di evitare spazi e caratteri speciali che possono creare problemi di ricerca. Anche in questo caso conviene verificare i vincoli effettivi dello stack che utilizzi prima di adottare una convenzione.
Verifica lo schema prima di applicarlo a tutto il catalogo
Il momento peggiore per scoprire che la convenzione non funziona è dopo aver assegnato migliaia di codici.
Prima della migrazione, prova un campione che includa prodotti semplici, varianti numerose, articoli simili, importazioni CSV, ricerche amministrative e sistemi esterni.
Se devi caricare o migrare un catalogo WooCommerce, può essere utile partire dalla nostra guida su come importare prodotti in WooCommerce e verificare in anticipo la corrispondenza dei campi.
SKU e codice a barre non sono la stessa cosa
È uno dei fraintendimenti più comuni: lo SKU è un identificatore interno, mentre il codice a barre è una rappresentazione grafica di dati leggibile da uno scanner.
Un’azienda può stampare il proprio codice interno in forma di barcode. Ma quando parliamo dei classici codici commerciali EAN o UPC presenti sui prodotti, normalmente entriamo nel sistema degli identificatori GTIN gestiti secondo gli standard GS1.
La documentazione GS1 sulla differenza tra GTIN, barcode, EAN e UPC chiarisce che il GTIN è l’identificatore globale del prodotto e che può assumere formati diversi: GTIN-8, GTIN-12, GTIN-13 e GTIN-14. GTIN-12 è comunemente associato all’UPC, mentre GTIN-13 è comunemente associato all’EAN.
Questo porta a una distinzione fondamentale:
SKU = come la tua azienda identifica internamente la voce di catalogo.
GTIN = come una specifica unità commerciale viene identificata globalmente secondo il sistema GS1.
SKU vs GTIN, EAN e UPC
Il GTIN non è semplicemente “uno SKU più ufficiale”. Ha un’altra funzione e segue regole differenti.
Un GTIN nasce per identificare un’unità commerciale in modo riconoscibile a livello globale. EAN e UPC sono termini che incontri spesso nell’operatività quotidiana, ma è più preciso ricondurli alla famiglia GTIN: GTIN-13 è comunemente associato a EAN-13, mentre GTIN-12 è comunemente associato a UPC.
SKU vs MPN
L’MPN, Manufacturer Part Number, è un codice assegnato dal produttore.
A differenza del codice del rivenditore, quindi, non nasce semplicemente dall’organizzazione interna del singolo negozio. La guida di Google Merchant Center sugli identificatori di prodotto distingue GTIN, MPN e marca dai codici interni del negozio e raccomanda di fornire gli identificatori reali quando esistono.
SKU vs ASIN
L’ASIN, Amazon Standard Identification Number, è un codice alfanumerico di 10 caratteri assegnato ai prodotti nel catalogo Amazon. La guida ufficiale Sell on Amazon dedicata agli ASIN spiega che Amazon usa questo identificatore per distinguere i prodotti nel proprio catalogo.
Il codice del tuo catalogo resta invece una chiave della gestione interna. Se vendi su Amazon, potresti quindi avere contemporaneamente questo identificatore e l’ASIN associato al prodotto sul marketplace.
SKU vs numero di serie
Un numero di serie scende a un livello ancora più specifico: può identificare il singolo esemplare fisico.
Dieci smartphone dello stesso modello, colore e capacità potrebbero condividere la stessa voce di inventario, ma ogni dispositivo può avere un seriale diverso.
Il codice interno risponde quindi a “quale articolo o variante è?”, mentre il seriale può rispondere a “quale specifico esemplare è?”.
SKU vs lotto o batch
Il lotto raggruppa più unità prodotte o gestite insieme, spesso perché condividono produzione, data, materia prima o altre condizioni operative.
Più unità dello stesso articolo identificato internamente possono quindi appartenere a lotti differenti.
Confondere i due livelli impedirebbe di distinguere correttamente l’identità commerciale dell’articolo dalla sua tracciabilità produttiva.
Confronto rapido tra i principali identificatori
| Identificatore | Chi lo assegna | Ambito | Cosa identifica | Globale? | Può convivere con SKU? |
|---|---|---|---|---|---|
| SKU | Azienda / venditore | Interno | Prodotto o variante gestita | No | — |
| GTIN | Brand owner secondo regole GS1 | Commerciale | Unità commerciale | Sì | Sì |
| EAN / UPC | Sistema GS1 | Commerciale | Formati collegati alla famiglia GTIN | Sì | Sì |
| MPN | Produttore | Produttore | Parte o prodotto del produttore | Non è uno SKU del negozio | Sì |
| ASIN | Amazon | Amazon | Voce del catalogo Amazon | No, platform-specific | Sì |
| Seriale | Produttore / sistema | Singola unità | Singolo esemplare | Dipende dal sistema | Sì |
| Lotto / batch | Produttore / supply chain | Gruppo di unità | Lotto di produzione o gestione | Dipende dal sistema | Sì |
Il punto operativo è che questi campi non si sostituiscono automaticamente tra loro. Un prodotto può legittimamente avere SKU, GTIN, MPN, ASIN e numero di serie nello stesso ecosistema, perché ciascun identificatore risponde a una domanda diversa.
Dove si trova il codice SKU e chi lo assegna
Il codice viene normalmente creato dall’azienda che gestisce il catalogo. Non devi richiederlo a GS1 e non esiste un registro internazionale nel quale “ottenerlo”.
Può trovarsi nel gestionale, nel pannello ecommerce, sulle etichette interne, nei documenti di picking, nei file CSV o nei dati scambiati tra sistemi. La sua visibilità al cliente dipende dalla piattaforma e dalla configurazione adottata.
Un rivenditore può inoltre conservare separatamente il proprio codice interno e il codice del produttore. Usare un unico campo per entrambi può sembrare più semplice all’inizio, ma diventa limitante quando devi gestire fornitori diversi, sostituzioni o più canali.
Lo stesso prodotto in più magazzini deve avere SKU diversi?
In generale no: spostare lo stesso articolo tra due sedi non ne cambia l’identità. Se la variante è la stessa, conviene mantenere lo stesso identificatore e gestire separatamente ubicazione e quantità disponibile.
Shopify esplicita questo modello per la gestione multi-location: raccomanda di utilizzare lo stesso codice per la stessa variante in tutte le sedi e di mantenere separati i livelli di inventario di ciascuna location.
È un principio utile anche oltre Shopify: SKU e ubicazione rispondono a due domande differenti.
Il codice dice che cosa è l’articolo.
La location dice dove si trova.
Inserire sistematicamente il magazzino nel codice crea invece un problema quando la merce viene trasferita: rischieresti di cambiare identità al prodotto solo perché ha cambiato scaffale o sede.
Un WMS o un ERP può naturalmente avere requisiti specifici, ma è preferibile verificare quei requisiti piuttosto che codificare la posizione nell’identificatore per abitudine.
SKU in WooCommerce, Shopify e nei sistemi multicanale
La logica dell’identificatore è generale, ma l’implementazione concreta cambia da piattaforma a piattaforma.
SKU in WooCommerce: prodotti semplici e variazioni
In WooCommerce il campo dedicato è facoltativo, ma quando viene utilizzato deve essere univoco all’interno del negozio. La documentazione ufficiale lo definisce come identificatore utilizzabile per cercare e tracciare un prodotto o una variazione.
WooCommerce mantiene inoltre un campo dedicato al Global Unique ID, utilizzato per GTIN e identificatori equivalenti. La documentazione WooCommerce dedicata al GTIN mostra perché conviene mantenere distinta questa informazione dal codice interno.
SKU in Shopify: varianti, inventario e integrazioni
Shopify raccomanda codici univoci per le varianti, coerenza nelle abbreviazioni e uno schema capace di crescere insieme al catalogo.
La piattaforma avverte inoltre che i duplicati possono influire sul tracking dell’inventario e sulle integrazioni. Per più sedi, come abbiamo visto, la stessa variante dovrebbe mantenere lo stesso identificatore, mentre la quantità viene registrata separatamente per location.
Marketplace e feed prodotto: quando serve anche un GTIN
Un errore frequente è pensare: “Ho già un codice interno, quindi posso usare quello ovunque venga richiesto un codice prodotto”.
Non funziona così.
Google Merchant Center distingue gli identificatori globali — come GTIN, MPN e marca — dai codici interni del negozio. Se un prodotto dispone di un GTIN assegnato, va fornito nel relativo campo invece di inventare un valore alternativo.
Allo stesso tempo, per l’attributo tecnico id del prodotto, Google indica come best practice l’uso dello SKU quando possibile e richiede di mantenere l’ID stabile nel tempo. La specifica Merchant Center dell’attributo ID mostra quindi un caso concreto in cui SKU e GTIN convivono senza svolgere la stessa funzione.
Errori nella gestione degli SKU che diventano problemi quando il catalogo cresce
Uno schema mediocre può funzionare con venti prodotti e collassare con duemila. Gli errori più costosi sono quelli che non si notano all’inizio perché sembrano innocui.
Duplicare lo stesso SKU su prodotti diversi
Due varianti diverse con lo stesso identificatore creano ambiguità proprio nel punto in cui il codice dovrebbe eliminarla.
Il problema può emergere durante una ricerca, una sincronizzazione, un aggiornamento stock o un’importazione. Shopify segnala esplicitamente il rischio dei duplicati per integrazioni e inventario.
Inserire nel codice informazioni destinate a cambiare
Prezzo, quantità, magazzino, scaffale o nome del fornitore sono esempi di dati che possono cambiare senza modificare l’identità del prodotto.
Se li trasformi in parti strutturali del codice, ogni modifica operativa rischia di obbligarti a rinominare il record.
L’identificatore dovrebbe essere abbastanza stabile da accompagnare l’articolo nel tempo.
Creare codici troppo lunghi o difficili da interpretare
Un codice come ABB-UOMO-COTONE-NERO-MEDIUM-FORNITORE02-PRIMAVERA contiene molte informazioni, ma è difficile da leggere, digitare e mantenere.
Un codice più corto come TSH-042-BLK-M può svolgere meglio la funzione identificativa lasciando gli altri dati nei rispettivi campi del database.
Il codice non deve diventare una scheda prodotto compressa.
Cambiare convenzione senza una migrazione controllata
Quando viene introdotto un ERP, un nuovo ecommerce o un WMS, può emergere la necessità di riprogettare gli identificatori.
Cambiare i codici direttamente nel catalogo senza mantenere una corrispondenza tra vecchio e nuovo valore può però rompere integrazioni, storico degli ordini, automazioni e report.
La migrazione dovrebbe quindi prevedere almeno una tabella di mapping SKU precedente → SKU nuovo, l’identificazione dei sistemi che utilizzano il codice come chiave e un test prima del passaggio completo.
Confondere SKU, barcode e identificatori globali
È probabilmente l’errore concettuale più importante.
Se il sistema richiede un GTIN, inventare un valore che assomiglia a un EAN non trasforma un codice interno in GTIN. Gli identificatori ufficiali devono rimanere nei campi destinati a quella funzione.
Quando conviene cambiare o riprogettare il sistema SKU
Non ha senso sostituire un sistema che funziona soltanto perché un altro schema sembra più elegante. La migrazione ha un costo e può coinvolgere inventario, ordini, feed, automazioni, contabilità e sistemi esterni.
Una riprogettazione diventa invece ragionevole quando il sistema attuale produce problemi misurabili: duplicati, codici non interpretabili, impossibilità di aggiungere nuove varianti, conflitti tra canali o difficoltà di sincronizzazione.
| Scenario | Segnale | Azione consigliata |
|---|---|---|
| Catalogo cresciuto senza convenzione | Codici manuali incoerenti | Definire schema e mapping |
| Migrazione ecommerce | SKU differenti tra vecchio e nuovo sistema | Mappare prima dell’importazione |
| Introduzione ERP/WMS | Identificatori non compatibili | Verificare requisiti e chiavi |
| Vendita multicanale | Stesso articolo con codici scollegati | Creare una corrispondenza stabile |
| Duplicati | Più varianti condividono lo stesso codice | Correggere prima delle integrazioni |
| Codici pieni di dati variabili | Lo SKU cambia con informazioni operative | Separare identità e attributi |
La priorità non è quindi costruire il codice più sofisticato possibile. È avere un identificatore stabile che permetta ai sistemi di parlare dello stesso articolo senza ambiguità.
Conclusione
Un codice SKU sembra un dettaglio amministrativo finché il catalogo è piccolo. Quando aumentano varianti, ordini, sedi e integrazioni, diventa invece uno dei riferimenti che tengono insieme l’intera gestione del prodotto.
La regola da ricordare è questa: lo SKU identifica internamente ciò che devi gestire; non sostituisce GTIN, EAN, UPC, MPN, ASIN, seriali o lotti, perché questi codici possono avere proprietari, ambiti e funzioni differenti.
Per un catalogo semplice puoi partire con una convenzione corta e coerente. Per un ecommerce destinato a crescere conviene progettare lo schema pensando già a varianti, importazioni e integrazioni, evitando di inserire nel codice informazioni destinate a cambiare.
E se stai progettando o rifacendo lo shop, la struttura dei codici dovrebbe essere affrontata insieme alla modellazione del catalogo, non dopo: nella realizzazione di siti web ed ecommerce mettere ordine nei dati prodotto all’inizio evita di trasferire nel nuovo sistema i problemi del vecchio.