倉庫裡放著兩百款商品，一旦把顏色、尺寸都算進去，實際品項膨脹到八百多筆；出貨單上只寫著「粉色 M」，揀貨的人得把整排箱子翻過一遍才找得到那一件。客服電話另一頭問著同一款外套還有沒有現貨，系統裡卻只查得到商品名稱，查不到眼前這一件實際還剩幾件。這種混亂，多半不是商品太多，而是每一件商品從來沒有一組屬於自己、能被機器與人同時讀懂的代碼。
那組代碼就是 SKU（Stock Keeping Unit，最小存貨單位）。它跟商品外包裝上那組國際條碼常被搞混，但兩者要解決的問題完全不同：條碼負責讓全世界的機器認出「這是哪一件商品」，SKU 負責讓賣家自己的倉庫、系統與客服人員認出「這是我店裡要出貨的哪一件」。分不清這兩者，最常見的下場就是拿供應商給的料號或條碼直接套用，結果庫存數字對不起來、揀貨找錯貨，跨平台上架時系統還跳出格式錯誤。
賣家SKU 是只在自己店裡通行的編碼，供應商的料號與條碼都無法直接頂替，這套規則得由賣家自己從頭訂。
SKU 是什麼？
SKU 與條碼的差別，不在於哪一個比較重要，而在於誰在用、誰核發、誰能改。SKU 是賣家自己店內管理庫存用的內部代碼，怎麼編、要不要改，全由賣家自己決定，顧客通常也看不到這組編碼；條碼，一般口語常直接說成 GTIN，比較常見的規格是 EAN 或 UPC，則是由 GS1（制定全球商品識別碼標準的國際組織）統一核發、全球獨一無二的商品識別碼，任何一家企業都不能自己隨意編一組蓋在商品上。
同一件實體商品，換一個賣家上架就可能對到不同的 SKU，但條碼從產線印出來的那一刻起就只會有一組，不會因為換了通路或換了賣家就不一樣。換句話說，條碼回答的是「這是全世界哪一件商品」，SKU 回答的是「這是我店裡要出貨的哪一件」，兩者處理的層次原本就不同。
台灣負責核發與管理這套國際條碼的機構是 GS1 Taiwan，正式名稱是財團法人中華民國商品條碼策進會，是 GS1 在台灣唯一的專責機構。GTIN 依印製空間與用途分成 14 碼、13 碼、12 碼、8 碼四種，零售商品最常見的是 GTIN-13，由「GS1 國家代號」、「廠商代號」、「商品代號」與「檢核碼」四段組成，也就是常見的 13 位數字條碼。
小於一般包裝、印不下 GTIN-13 的商品，才會用到縮短版的 GTIN-8，它只有「GS1 國家代號」、「商品代號」與「檢核碼」三段，少了廠商代號這一段，也因此不能像 GTIN-13 那樣由廠商自行分配，而是必須逐筆向 GS1 Taiwan 申請核發。至於整箱、整盒的外箱包裝，用的是 GTIN-14，由「配銷識別碼」、「GS1 國家代號」、「廠商代號」、「商品代號」與「檢核碼」組成，配銷識別碼負責標示箱內數量規格，方便倉儲與物流不用拆箱就能辨識裡面裝了多少件。
要合法使用 GTIN，廠商得先向 GS1 Taiwan 申請成為登記廠商，取得專屬的「公司前置碼」，之後才能自行對旗下商品分配 GTIN 編號，這也是為什麼條碼是申請制、不能自己隨意編，跟賣家自己想編一組 SKU 就能直接拿去用完全是兩套邏輯。根據 GS1 公布的數據，這套條碼從 1974 年第一次被掃描至今已超過 50 年，全球有超過 200 萬家企業採用 GS1 標準，每天的條碼掃描次數超過 100 億次；規模這麼大的系統，靠的正是核發制把每一組編號的唯一性鎖死，賣家自己的 SKU 則剛好相反，追求的是彈性與好讀，兩套邏輯本來就不該混為一談。
把這兩者的分工釐清之後，很自然會冒出一個問題：條碼都已經是全球唯一了，為什麼賣家還要多花力氣自己編一套 SKU？
沿用供應商料號或條碼，會在庫存管理留下漏洞
條碼與供應商料號能解決的，是賣家跟外部世界溝通的問題，解決不了賣家自己內部要面對的揀貨、盤點與跨通路管理。把供應商的料號原封不動搬進自己的系統，看起來省了一道工，長期卻會在幾個地方留下漏洞。
第一個漏洞出在供應商之間的料號規則彼此不通。甲供應商用三碼英文加流水號，乙供應商用產品線代號加西元年份，賣家如果同時跟好幾家供應商進貨，把這些各自為政的料號直接混進同一個商品清單，很容易發生同一組號碼被兩件完全不同的商品共用，或是同一件商品因為換了供應商而換了一組看起來毫不相干的號碼，庫存系統裡的歷史紀錄也就跟著斷成好幾截。
第二個漏洞在於條碼本身不是設計給人眼判讀的。條碼是給掃描器辨識用的一串數字，肉眼看到一長串數字完全猜不出這是哪個顏色、哪個尺寸的商品；揀貨、盤點這類仍然要靠人工作業的環節，需要的是一組好讀、能表達規格的內部代碼，光有條碼沒辦法解決人工作業的判讀問題。
第三個漏洞出現在上架多個銷售通路的時候。電商平台的商品編號欄位通常交給賣家自己填寫，這組編號在同一個賣家帳號底下要彼此不重複，系統才分得清是哪一件商品，一來供應商料號不見得符合各平台的格式與長度限制，二來好幾家供應商的料號混在同一個帳號裡，很容易撞號。這也是為什麼即使商品早就有條碼、也有供應商料號，賣家還是得自己建一套 SKU，讓內部管理跟外部溝通這兩件事分開處理，互不牽動。
想清楚了為什麼要自己建，剩下的問題就是怎麼編才好用。
SKU 編碼結構的分段設計原則
一組好用的 SKU，通常不是隨手把商品名稱轉寫一遍，而是切成幾個固定意義的段落，例如類別、款式、規格，讓系統跟人眼都能用固定位置判讀出這串代碼在講什麼商品。設計這套結構時，除了決定切哪幾段，更重要的是想清楚哪些資訊適合編進代碼、哪些絕對不該編進去，以及要幫流水號留多少成長空間。
分段式結構的常見做法，是把類別、款式或系列、規格屬性各自切成固定位數的區塊，用固定的分隔符號連接起來，同一類商品的代碼長度也要維持一致，這樣系統才能用固定的字元位置去切出每一段的意義，進而排序、篩選。段落順序定下來之後，哪些資訊不該一起編進去、流水號又該留多寬，反而是設計階段最容易失手的地方。
類別、款式與規格碼要各自固定位數
以龐果設計的自有品牌飾品線為例，一組 SKU 可以先決定要不要放類別代碼，再決定款式或系列要怎麼縮寫，最後才是顏色、尺寸這類規格屬性。例如：
ACC-RING-SLV-16Code language: plaintext (plaintext)這組代碼裡，ACC 代表配件類別，RING 代表款式（戒指），SLV 代表銀色，16 代表尺寸，四段各自負責一種資訊，長度也在同一類商品裡維持一致，系統要抓出所有銀色戒指，只需要比對固定位置的那一段字元，不必逐筆查商品名稱。
每一段的字元數在同一類商品裡要維持一致，這件事比看起來重要。如果類別段有時候是三個字元、有時候是四個字元，系統就沒辦法用固定的切割位置去解讀這串代碼，篩選跟排序功能等於形同虛設，最後還是得靠人工一筆一筆對照，分段設計原本要解決的問題又繞回原點。
價格、庫存與檔期不編進 SKU 代碼本身
售價會調整、庫存會搬倉、促銷檔期會過期，這些會變動的資訊如果寫進 SKU 本身，商品一旦有任何異動就得連帶修改代碼，舊訂單與舊報表原本記錄的那組代碼就對不上新的代碼，歷史資料的對應關係就此斷裂。
比較穩妥的做法，是把 SKU 只當成識別這一件事的代碼，價格、庫存位置、促銷檔期這類會變動的資訊，改放進商品資料裡獨立的欄位管理，例如價格表、庫存位置欄位、促銷活動的關聯設定。舉例來說，龐果設計把一款「ACC-RING-SLV-16」戒指從原價調整到特價，代碼本身完全不動，只更動價格欄位裡的數字，過去所有用這組代碼記錄的訂單與報表依然查得到、對得上。
流水號位數留寬以因應品項數量成長
剛開店的時候品項少，很容易只給流水號留 2 位數，從 01 編到 99 就覺得綽綽有餘。品項一旦成長到 3 位數，這套只留 2 位數的編碼就會被打回原形，得整套重新設計，過去已經上架的商品也得跟著改代碼，牽動的範圍遠比一開始想像得大。
位數留寬一點的成本很低，多留一位數字，頂多讓代碼看起來長一點；事後補救的成本卻很高，代表要重新規劃整套命名邏輯，還得把舊代碼一一轉換成新代碼，同時通知所有跟這組代碼串接的系統與通路。與其等到品項爆量才發現不夠用，不如一開始就把流水號留到 3 位數甚至 4 位數，讓代碼有足夠的成長空間。
SKU 字元只用英數，避開 0、1 與 O、I 這類易混淆符號
代碼建議只用英文字母與數字組成，避免中文與特殊符號夾雜在代碼裡，因為系統在匯出、匯入資料時，中文字元跟特殊符號很容易因為編碼格式不同而變成亂碼，讓整批資料對不起來。
肉眼經常需要人工輸入或核對代碼的場合，也建議避開字母 O 跟數字 0、字母 I 跟數字 1 這類看起來很像的字元組合。倉管人員手動輸入一長串代碼時，這類字元最容易看錯、打錯，一旦打錯又不容易在螢幕上發現，等到系統找不到對應商品才會發現哪裡出了問題。設計代碼規則的時候，直接把這幾個容易混淆的字元排除在外，比事後訓練員工小心辨認更有效。
顏色、尺寸等變體商品的 SKU 分配原則
多數賣家真正容易出錯的地方，不是編碼規則本身，而是商品、變體與 SKU 這三個層次該怎麼對應。商品是消費者認知裡的那一款東西，例如一件襯衫；變體是它底下可以選的規格組合，例如顏色與尺寸的搭配；SKU 則是最小的、可以獨立盤點與出貨的單位。原則上，每一個會被分開盤點、分開販售的變體，就該對應一組獨立的 SKU，庫存數字記在變體這一層，而不是記在商品這個抽象層級。
把不同顏色、不同尺寸塞進同一組 SKU，庫存就會變成一個無法拆分的總數，客服跟倉管都沒辦法確認客人實際要的是哪一件，缺貨判斷也會失準。顏色、尺寸這類規格組合怎麼判斷還算直覺，真正容易讓人猶豫不決的，反而是組合包、贈品套組這類不單獨存在的品項，還有商品改版到什麼程度才該換一組全新代碼。
分開盤點與販售的規格組合各自需要一組 SKU
判斷一款商品的規格組合該不該獨立成一組 SKU，可以問自己 2 個問題：倉庫要不要分開計算這兩個規格的庫存，顧客下單時要不要分開選這兩個規格。只要有一個答案是要，這個規格組合就該有自己的 SKU；如果答案都是不要，就不必為了它另外開一組代碼。
以龐果設計的一款帆布托特包為例，黑色跟卡其色是顧客下單時要分開選的規格，庫存也要分開計算，這兩色就該各自對應一組 SKU；但同一款黑色，如果只是不同批次印刷時出現些微色差，不影響顧客選購也不影響倉管盤點的判斷，就不必為了這種批次差異另外開一組代碼，維持原本的 SKU 即可。
組合包與贈品套組的庫存記在底層 SKU 上
組合包，例如「主商品加贈品」或「三入優惠組」，應該有自己一組對外販售用的 SKU，方便在後台上架跟結帳時對應到一筆訂單。但這組組合包 SKU 不該獨立持有庫存，它的可售數量要由底下組成的單品 SKU 動態計算出來，賣出一組就自動從底層各單品的 SKU 扣除對應的數量。
如果把組合包當成一支獨立商品另外進貨、另外盤點，同一批實體庫存就會被單品跟組合包各自算一次，帳面庫存跟實際庫存很快就會對不上。舉例來說，龐果設計把一款筆記本跟一款便條紙包成「開工組合」對外銷售，組合包本身有自己的 SKU 方便上架，但賣出一組開工組合，系統要同時從筆記本跟便條紙各自的單品 SKU 各扣一件庫存，而不是幫開工組合另外開一筆進貨紀錄。
影響實體辨識的規格改版才需要換發新 SKU
商品改版之後，SKU 要不要跟著換，判準只看這次改動會不會影響顧客實際選購或倉庫實際盤點的那個東西本身。配方、材質、容量、尺寸這類實體差異變了，就代表這已經是不一樣的商品，該換發一組全新的 SKU，讓舊的那組走停產流程，資料保留在主檔供歷史查詢即可。
純粹更換包裝設計、更換文案說法、更換主圖，不影響顧客實際拿到的東西，也不影響倉庫盤點時認得出來的那件實體商品，這種改版維持原本的 SKU、直接更新商品資料就好，不必為了外觀調整另外換一組代碼，否則舊訂單跟新資料又會對不起來。
單一商品內部的分配原則抓穩之後，賣家一旦同時經營多個銷售通路，還會遇到另一層問題：同一件商品在不同通路各有一組不同編號，該怎麼串起來。
多通路共用 SKU，靠一張對照表串起來
賣家一旦同時在自架官網、社群與電商平台上架，最容易出現的狀況，就是同一件商品在不同通路各自輸入一次資料，各有一組不同的編號，彼此之間沒有任何對應關係，想看這款商品全通路一共賣了多少，就只能靠人工對帳，一個通路一個通路慢慢核對。
不同銷售通路對商品編號欄位的規則不盡相同，有的限制字元數，有的不接受特殊符號，賣家與其硬要讓所有通路的編號長得一模一樣，不如把力氣放在維護好一張對照表。這張對照表把賣家自己的內部主 SKU 當成單一真實來源，橫向對應到各通路各自的商品編號，以及該商品的條碼。這張表怎麼建立、庫存跨通路同步又是靠什麼機制在背後運作，牽動的正是賣家會不會遇到超賣的風險。
內部主 SKU 是單一對照依據，各通路碼都連回它
建立對照表的第一步，是先確立一支實體商品只對應一組內部主 SKU，這組主 SKU 不因為上架到哪個通路而改變。接著逐一把自架官網的商品編號、各電商平台各自的商品編號，以及這件商品的條碼都填進對照表，全部對應到同一組主 SKU 上。
商品資料一旦有異動，流程是先改內部主 SKU 對應的那筆資料，再回頭確認各通路的編號是否也需要跟著更新。日後新增銷售通路，也是先確認這支商品原本的主 SKU 是哪一組，再把新通路的編號補進對照表，而不是讓每個通路各自獨立建號，否則對照表很快就會失去單一真實來源的作用。
跨通路庫存同步靠 SKU 精確比對而非模糊比對
多通路庫存同步系統之所以能運作，靠的是系統拿 SKU 這組固定代碼去比對各通路講的是不是同一件商品，而不是拿商品名稱這種容易打法不一的文字去猜測。代碼只要有一點點不一致，例如大小寫不同、多了一個空格、縮寫方式不同，就會配對失敗。
配對一旦失敗，某個通路賣出商品之後，其他通路的庫存數字沒有跟著扣減，就會發生同一件商品被不同通路重複賣出，也就是超賣的狀況。這也是為什麼 SKU 這組代碼一旦定案就不該再隨意更動，任何一次更動都得同步通知所有串接的通路，否則精確比對就會出現破口。
SKU 系統最常出現的幾個管理疏漏
前面幾節談的是怎麼把 SKU 從零建好，商品清單實際經營一段時間之後，也會慢慢累積出幾種常見的管理疏漏，而且往往要等到品項數量變多才會爆發出來。常見的疏漏不外乎三種：命名風格中西夾雜、變體拆分過猶不及，以及停產品項留著沒清理。這幾個疏漏各自對應前面提過的分段設計、變體分配跟命名規則，回頭看反而更容易理解為什麼那些規則一開始就該抓住。
同一個資料庫裡，命名風格中西夾雜、規則不一
品項少的時候，同一份商品清單裡有些代碼是中文品名直接轉寫、有些是供應商原始料號、有些是隨手用日期加流水號拼出來的，這種風格混雜的命名方式看起來還能應付，判讀跟查找都還能靠記憶完成。
只要負責編碼的人離職，或是品項數量一多，這套全靠口耳相傳的規則就會斷掉，新進人員只能一筆一筆用系統查，效率大幅下降。解法是回到前面編碼結構的分段設計原則那套邏輯，把類別、款式、規格各自固定位數的規則寫成一份明文的命名規範，讓新進人員也能照規則建碼，不必等前輩口頭交代。
顏色或款式塞進同一組 SKU，庫存就成了無法拆分的總數
這個疏漏呼應前面變體商品的 SKU 分配原則提到的分寸，把該拆沒拆這個最常見的錯誤單獨拉出來看。多款顏色共用同一組 SKU，庫存就只剩一個總數，客服跟倉管都無法確認客人實際要的是哪個顏色，缺貨判斷也會跟著失準。
也有相反的失守，同一件實體商品只因為包裝設計或贈品不同，就硬拆成好幾組 SKU，明明庫存總量夠，系統卻各自顯示不足，逼著賣家逐一追查是哪一組代碼出了問題。這兩種相反的失守都會讓庫存數字失真，判斷準則還是回到前面提過的那句話：問自己這兩個規格組合，倉庫要不要分開算，顧客要不要分開選。
停產品項留在主檔會讓新人分不出在售或已停售
商品下架或停產之後，如果主檔裡沒有明確的狀態欄位標記在售、停售或已停產，只是把商品留著不管，商品清單就會被這些殭屍品項越拖越肥。新進人員光是分辨哪些還在賣、哪些早就下架，就得花掉不少時間，也拖慢日常的搜尋、報表與盤點效率。
正確的做法是幫每個商品狀態建立獨立欄位，商品一旦停產就改成對應狀態、退出對外通路與購物用的資料匯出範圍，資料本身則保留在主檔裡供歷史訂單查詢，而不是直接刪除。這樣一來，主檔看起來乾淨，歷史資料也不會因為刪除而找不到，兩件事都不必犧牲。
SKU 從來不是一組隨便湊出來的編號，它是賣家自己的商品要被系統、倉庫跟客服同時讀懂的那把鑰匙。分段設計把結構定好、變體分配把顆粒度抓對、多通路對照表把一致性維持住，這三件事做到位，品項數量再怎麼成長，庫存數字都還能對得起來。
反過來說，只要命名規則混雜、變體拆分失衡，或是停產品項沒有清理，這些疏漏不會馬上出現在營收數字上，卻會在品項變多之後一次全部冒出來。與其等到那個時候才回頭重編一整套 SKU，不如趁品項還不多的現在，把這套規則寫清楚、用到位。