Barcode, SKU and internal code: what each one is for

Ask three people in the same warehouse for a product's code and you may get three different answers. The storekeeper reads out the number printed on the carton, the accountant quotes the item code in 1C, and the online-shop manager gives the listing ID from the marketplace. All three are right, which is exactly why counts go wrong. Barcodes, SKUs and internal codes do different jobs, and a stock count is only accurate when each job stays separate.

Three codes, three jobs

A barcode is a pattern a scanner can read. Its job is physical: it identifies the thing in front of you, whether that is a single piece, a carton of 24 or a whole pallet. Manufacturers usually print their own, but a barcode is only a number on a label. It says nothing about colour, size or which of your listings it belongs to unless you make that link yourself.

A SKU is your own identity for something you sell. It lives in your books, your ERP and your marketplace listing, and it normally separates variants. The black phone case and the white one are two SKUs, even if the supplier gave both colours the same carton barcode.

An internal code is a number and label you assign yourself, for things that have no reliable barcode: bins, shelves, pallets, loose items and samples. It ties a place or an object to a record. Because you control it, it does not change when a supplier switches printers.

Where the three get mixed up

Many count gaps that look like missing stock are really code problems. The usual patterns are:

• One SKU, several barcodes. The same product arrives from two suppliers, or the single piece and the carton each carry their own barcode.
• One barcode, several SKUs. A supplier prints one barcode per model and uses it for every colour.
• One SKU, several spellings. A-1042 in 1C, A1042 on the marketplace and А-1042 in a supplier file, where the first letter is Cyrillic. On screen they look identical, and in a lookup they never match.

Packaging levels are another source. A single piece, an inner pack and an outer carton can each carry a different barcode, so the table must say how many pieces one scan of each represents. Otherwise the same stock is recorded 24 times too high, or 24 times too low.

A small example

Imagine a trader holding one phone-case model in four colours, 300 of each according to the books, 1,200 in total. The supplier's carton barcode is the same for every colour. The team scans 1,200 pieces and the total matches, so the count looks clean.

It is not. On the shelves there are 420 black, 300 white, 280 red and 200 blue, and nobody can see it, because the scanner only knows the model. Add a colour label and scan again, and the gaps appear: black 120 over, red 20 short, blue 100 short. They add up to zero, which is why checking only the total never finds them.

A mapping table fixes most of it

Build one table with one row per sellable unit and these columns:

• the SKU as written in your books
• the marketplace code, if it differs
• the 1C or ERP item code
• the supplier barcode or barcodes
• your internal label, if you print one
• the unit of measure and the number of pieces per carton

Three rules keep it honest. A barcode may point to only one SKU. A SKU may have many barcodes. And the unit of measure is always written down, so that 10 cartons of 24 are never mistaken for 10 pieces.

Give the table one owner

A mapping table starts to decay the moment a new product arrives. Name one person who adds new lines at receiving, put a date in the file name, and make everyone use the same copy. After each count, add the new spellings and barcodes you found, so the next count starts from a better table. If the table lives in five chats and three laptops, it is not a table.

InventoryHub starts every count by building this mapping with your operations and warehouse staff, labels the items and bins that have no code, and returns the counted results in a SKU-level table you can filter in Excel.