SKU Coding and Batch Traceability: The Warehouse Decisions You Make Once

Some things in a warehouse system can be changed any afternoon: report layouts, user permissions, reorder points, screen design. Four decisions cannot. How items are numbered, what you track with each unit, how inventory cost is calculated, and where quantity is held at the moment of sale. Change any of those a year into production and you are looking at a data migration, a relabelling exercise, rebuilt reports, and usually a stretch where two systems run side by side.

This guide covers those four decisions and the coding choices underneath them, not the feature list of a warehouse management system. It is written for the owner of a distribution business, a small factory, a multi-branch retailer, a pharmacy or a cosmetics importer in Egypt, Saudi Arabia or the Gulf, who is about to sign off on a specification and would rather not discover a year later that the numbering is wrong.

Product, location, shipment: three different numbers

The most expensive confusion in warehouse projects is using one number for three different things. The global standard separates them cleanly: GS1 defines twelve identification keys, each with a job. Three matter most here.

The practical difference: a GTIN stays identical across millions of units of the same item, while an SSCC is issued once for one specific shipment and never repeats. Your bin code is a fourth thing entirely, an internal reference nobody outside your company reads, unless your sector falls under a government traceability scheme, which we come to below.

Inside the barcode there is another layer. GS1's own GTIN summary puts it in one sentence: the GTIN identifies a product type at any packaging level, groups produced under similar conditions are further identified by batch or lot number and expiry date, and an individual unit is identified by the GTIN plus a serial number. Those extra attributes travel in the barcode through what GS1 calls Application Identifiers, and the published reference fixes the format of each:

Take one decision from that table. A batch number can contain letters and can run to 20 characters. If your team designs an 8-digit numeric field because your current supplier's batches look that way, the first foreign supplier will break the system.

Do you need a GS1 number, or is your own coding enough?

The answer depends on where the product is sold, not on how big your company is.

If the item will be scanned at a retail till or listed on a marketplace, you need a GS1 number. Building any GS1 key requires membership and a GS1 Company Prefix, and GS1 states plainly that it does not allow the transfer or resale of GTINs, and that only a licensed GS1 Member Organisation can issue them and guarantee their uniqueness. Numbers sold by third-party sites are either outside the GS1 system altogether, or numbers originally licensed to somebody else, which will surface against that company's data rather than yours.

GS1 offices do exist across the region. The contact directory on gs1.org lists Egypt, Saudi Arabia, the United Arab Emirates, Kuwait, Qatar, Oman, Bahrain and Jordan. The regional prefixes in the official prefix table are 622 for Egypt, 628 for Saudi Arabia, 629 for the Emirates, 627 for Kuwait, 630 for Qatar, 607 for Oman and 608 for Bahrain. GS1 Saudi Arabia describes itself as the sole authorised body issuing Saudi barcodes under prefix 628.

One correction worth making, because the opposite claim appears in a lot of marketing material: the prefix does not indicate country of origin. GS1 says so directly — the number begins with the prefix of the Member Organisation that allocated it, and the product may have been made anywhere in the world. So do not build a "locally made products" report on the first three digits of a barcode.

If the item never leaves your company, such as raw materials, spare parts, or goods sold wholesale against an invoice rather than a scan, your internal coding is enough. The global system reserves prefixes for exactly this: the GS1 table sets aside 0000000 and 040 to 049 for restricted circulation numbers within a company, and 020 to 029 and 200 to 299 for restricted circulation within a geographic region.

In Egypt, the authority you might expect to be strictest accepts both. The coding file published on the Egyptian Tax Authority's coding page asks taxpayers for a statement of the codes they use for goods and services, "whether based on a global coding system such as GS1, or an internal coding system linked to the Global Product Classification (GPC), or both" (accessed September 2026). In other words, you are not obliged to buy a barcode for every item in order to issue an e-invoice, but every item does need a stable code tied to an approved classification. The integration itself is covered in our guide to Egyptian e-invoicing, and for Saudi Arabia in phase two of ZATCA e-invoicing.

Item code structure: what belongs inside it and what sits beside it

The first rule comes from GS1: every product and every variation of it, meaning every size and every colour, needs its own number, and one number is only ever assigned to one product. A shirt in four sizes and three colours is twelve items in your system, not one item with attributes. Collapse it into one and the first stocktake will tell you that nobody knows how many medium blues are left.

Then comes storage, which is a separate decision from printing. GS1 recommends that a GTIN always be stored in databases as 14 digits, with shorter formats padded with leading zeroes. The reason is practical: the four common formats are GTIN-8, GTIN-12 (known as UPC), GTIN-13 (known as EAN) and GTIN-14 for cases, and if you store them at their native lengths, matching a supplier file against your database will fail on roughly one item in ten, with a leading zero as the only difference.

The hardest of these to argue for is the third: keep changeable information out of the code. "Intelligent" numbering that encodes a supplier letter, a warehouse number and the year of first receipt feels tidy for a month, then becomes a liability the first time you switch supplier or move an item between branches, because you are left with two bad options: a code that lies about reality, or a new code that cuts the item's history in half. Supplier, branch and year are separate fields linked to the code, not characters inside it. Keep the code stable and meaningless, and let fields and reports carry the meaning.

In practice, hold two separate fields per item: your internal code, which never changes, and the GTIN, which may be empty and may legitimately be more than one if you source the same item from more than one place. Saudi Arabia's RSD system acknowledges this explicitly; its FAQ allows more than one GTIN against a single drug registration number.

Batch, serial and expiry: when they become an obligation

In certain sectors this question is settled by a published regulation, and you are held to it.

Food in Saudi Arabia. The Saudi Food and Drug Authority's Implementing Regulation of the Food Law requires, in its Article 51, that a food business maintain a traceability manual, apply traceability "one step forward and one step back", and keep a supplier register holding the supplier's name and address, the receipt date, the nature and quantities of goods received and their transport and storage data, plus a matching customer register. Paragraph 5 of the same article lists what must be known about every food item in circulation: the barcode, production date, expiry date and batch number. Article 52 then supplies the figure that matters to whoever designs the database: traceability records must be kept for at least 180 days after the expiry date, with the Authority free to set different periods for particular foods. The regulation also defines a batch as "a specific quantity of food produced essentially under the same conditions", which settles when you open a new lot.

Because a recall is the real test of any traceability design, Article 58 requires the business to begin withdrawal immediately on knowing or suspecting non-conformity, to notify the Authority immediately, and to complete the withdrawal within a period the Authority sets. If your warehouse knows quantities but not which batch went to which customer, you are facing a full product recall instead of a single-batch withdrawal.

Cosmetics in Saudi Arabia. The Implementing Regulation of the Cosmetic Products Law requires every cosmetic product to carry its shelf life and "the production date and the batch number, or one of them", and obliges the listed party to document wholesale sales and to notify the Authority when the product is recalled in any country. That last obligation means your system has to answer, in minutes, where a batch recalled abroad sits in your stock and who received it.

Medicines. Saudi Arabia moved first here. The Authority publishes the circulars and guidelines of the RSD drug traceability system, covering submission of the GTIN, migration from linear to two-dimensional barcodes, and encoding a serial number on every pack inside the barcode, a circular issued on 1 February 2018 and still marked active. The system's FAQ settles three design points: a serial number cannot be repeated on a drug carrying the same GTIN, every licensed warehouse must have its own Global Location Number, and every send and receive operation must be reported for every pack, inside the organisation as well as outside it. That second point alone rules out the "one warehouse with sub-locations" shortcut.

Egypt. For medical devices, supplies and laboratory reagents there is a published obligation: the Egyptian Drug Authority issued Decree 499 of 2021 on the use of the international barcode (GTIN) for all medical devices, supplies and laboratory reagents circulating in Egypt. It was published in the Official Gazette, issue 257, on 16 November 2021, and gave companies a maximum of one year to obtain the numbers.

Food traceability in Egypt is a different matter. We could not find a published Egyptian regulation setting out detailed traceability requirements comparable to the Saudi one. The National Food Safety Authority was created by Law 1 of 2017, published in the Official Gazette on 10 January 2017, and supervises the circulation of food, but we did not reach a published regulation specifying record contents or retention periods. If you run a food business in Egypt, ask the Authority directly before you freeze the design, and do not assume the requirement is absent simply because you could not find it published.

What all of this means for your schema is one thing: quantity is not held at item level. It is held at (item, batch, location). That is the difference between a system that can enforce first-expired-first-out and one that prints a total with no meaning behind it.

Inventory valuation: an accounting decision your system executes

"FIFO or weighted average?" usually reaches the developer. It is an accounting decision governed by a standard.

In Egypt, the Egyptian Accounting Standards were issued by Minister of Investment Decree 110 of 2015 and took effect on 1 January 2016; the Financial Regulatory Authority describes them as largely aligned with international standards. The inventory standard's text sets out three cases: items that are not ordinarily interchangeable are costed by specific identification; everything else uses first-in-first-out or weighted average; and an entity must apply the same cost formula to all inventories of the same nature and use. The standard also requires disclosure in the financial statements of the accounting policies used to measure inventory, including the cost formula.

In Saudi Arabia, IFRS Accounting Standards as endorsed by SOCPA are required for publicly accountable entities, and other entities may use full IFRS or the IFRS for SMEs Standard. IAS 2 follows the same logic: specific identification for non-interchangeable items, FIFO or weighted average cost for the rest.

Three consequences for the system. Cost formula is fixed per group of similar items, so the software should not offer the user a choice at transaction time. Cost of goods sold has to be computed at issue, not at month end, or you lose per-item margin. And changing the formula later runs through your accountant and through disclosure in the financial statements, so do not treat it as a settings toggle. Agree it before the technical team starts, not after.

Note: the above summarises published texts. It is not accounting or tax advice. Confirm your valuation policy with your auditor.

Stocktaking: periodic, perpetual, and what to do with variances

An annual count that shuts the business for a day gives you one accurate picture a year, and the picture starts drifting the next morning. The alternative is cycle counting: each week you count a small set of locations or items so that the whole warehouse is covered over a full cycle, which surfaces drift while it is still small and tells you roughly when it started.

The counting screen looks much the same in every system. The difference shows up after the count: every adjustment should be recorded against a classified reason rather than a free-text note. Shopify's inventory states documentation illustrates the idea with a ready-made list of reasons, including cycle_count_available for a discrepancy between the physical count and the recorded quantity, shrinkage where stock is lower because of theft or loss, plus damaged, restock and received. The gap between an adjustment caused by a keying error and one caused by loss is the gap between a report that fixes a process and a report that closes a case.

Three conditions make cycle counting worth doing: the counter works a specific location rather than chasing an item across the warehouse, approving a variance is a separate permission from recording the count, and the adjustment log cannot be deleted. Without all three, stocktaking becomes a way to bury variances rather than expose them.

Overselling: a states problem, not an alerts problem

The best known failure in a warehouse wired to an online store is selling an item that is out of stock. The usual explanation is that "stock updates late". The more accurate one is that the system holds a single number for quantity where reality needs several.

Shopify's documentation lays the model out: on-hand stock at a location equals the sum of available, committed to open orders, reserved for a specific purpose, damaged, safety stock, and quality control. The committed state is managed by the platform itself when an order is created and fulfilled, and cannot be adjusted through the API. In other words, quantity leaves "available" the moment the order is placed, not the moment it ships. In the same list of reasons, safety_stock is described as setting units aside to help guard against overselling.

Even with the right model there is a concurrency problem: two orders arriving in the same instant for the last unit. That is settled in the database, not in the interface. PostgreSQL's documentation explains that SELECT ... FOR UPDATE locks the rows it retrieves, preventing other transactions from modifying or locking them until the current transaction ends. In warehouse terms: read the item's balance and lock it, check the quantity, deduct, then commit. The second order waits, reads the balance after the deduction, and is refused rather than accepted. Ask about this specific point in any technical proposal you receive.

A fourth condition remains: one source of truth. If the till deducts from one table and the online store from another, and they sync every five minutes, you own two balances, and every alert you add will reach you after the customer has paid. Linking the till to the warehouse is covered in our POS integration guide, linking the warehouse to delivery in e-commerce shipping solutions, and the same idea applied to a multi-branch restaurant in the restaurant technology stack.

Decisions to settle before the first line of code

1. Decide whether you need GS1 numbers based on your sales channel, and if you do, deal only with the GS1 office in your country.
2. Fix a stable internal code per item, store the GTIN in a separate 14-digit field, and allow more than one GTIN per item.
3. Define every variation (size, colour, pack size) as its own item from day one.
4. Decide now whether you need batch, serial, both or neither, and check what your sector requires by regulation before you answer.
5. Hold quantity at (item, batch, location), and give every warehouse its own location code.
6. Settle the valuation formula with your accountant and fix it per group of similar items.
7. Require a classified reason list for every stock adjustment, an undeletable log, and a split between who counts and who approves.
8. Require quantity to be committed when the order is created, with row-level locking, and a single balance shared across all channels.
9. Set the retention period for traceability records from your sector's rules, and design archiving around that rather than around disk space.

These decisions separate a warehouse system that grows with the company from one that gets replaced after two years. Most of them cost nothing extra at design time and a great deal afterwards. If you are weighing an off-the-shelf package against a custom build, the nine questions above make a better comparison than any feature matrix; the wider comparison is in off-the-shelf versus custom software, the cost drivers in our ERP cost guide, and the split of responsibilities in ERP versus CRM.

If you are building a warehouse system or replacing one you already run, start from our custom systems page and tell us what you sell, how many items you carry, which channels you sell through, and whether your sector requires batch traceability. The Snaabble team will reply with a proposed scope, an expected duration and a budget range, at no charge and with nothing to commit to.

Sources

• GS1: identification keys, company prefix and prefix table, Application Identifier reference, GTIN executive summary, storing GTINs as 14 digits. Accessed 21 September 2026.
• Saudi Food and Drug Authority: Implementing Regulation of the Food Law, Implementing Regulation of the Cosmetic Products Law, RSD circulars and guidelines.
• Egyptian Drug Authority: Decree 499 of 2021 on the international barcode.
• Egyptian Tax Authority: coding page and the coding file published on it.
• Financial Regulatory Authority (Egypt): Egyptian Accounting Standards and the published text.
• IFRS Foundation: IAS 2 Inventories and the Saudi Arabia jurisdiction profile.
• Shopify: manage inventory quantities and states.
• PostgreSQL: explicit locking.