One thesis: logistics marking is its own discipline, and the label is the first artifact where a generation error becomes physical — a bad check digit on a screen is a bug, but a bad check digit on ten thousand printed cases is a re-work order with a dumpster attached. The discipline has exactly three parts — which symbology goes where, how the SSCC is allocated, and how the label is verified before the run — and all three are mechanical once stated.
If a customer mandate has just asked your plant for "GS1-compliant case and pallet labeling," this is the whole of what that means, worked end to end on one shipment.
Which symbology goes where, and why
Three marks, three jobs, chosen by print physics and scan distance rather than preference:
- ITF-14 carries the case-level GTIN — 14 digits, nothing else — and exists because corrugate is a hostile printing surface. Its bars are wide and tolerant, it is specified with bearer bars (the heavy frame that guards against the bar-growth and plate-slip errors of direct corrugate printing), and it reads reliably when printed by the case supplier rather than applied as a label. If the mark is printed into the board, ITF-14 is the answer.
- GS1-128 carries AI syntax — the case GTIN plus the attributes that travel with logistics: lot (10), pack or expiry dates, weights, and above all the SSCC (00) on the pallet label. It is a label-printer symbology: crisper tolerances than ITF-14, in exchange for needing label stock. Anything variable — anything per-batch or per-unit — arrives by GS1-128 label, not by printed board.
- The retail point-of-sale symbol on the each is a different decision belonging to your brand-owner customer, not to the plant — the grain decision that drives it is the serial-versus-lot post's subject.
The SSCC: eighteen digits, four parts, one discipline
The pallet needs what no GTIN can provide: a name for this specific logistic unit — not "a pallet of product X" but "this pallet, the one built at 14:07." That is the SSCC, AI (00), and its 18 digits decompose exactly:
3 9506000 000000123 4
│ │ │ └─ check digit (mod-10, GenSpecs §7.9)
│ │ └─ serial reference (allocated by you)
│ └─ your GS1 company prefix
└─ extension digit (0–9, yours to assign — extra serial capacity)barcoding generate constructs it — extension digit plus prefix plus serial reference, check digit computed, rendered as GS1-128 under AI (00):
$ npx barcoding.dev generate --sscc --prefix 9506000 --ext 3 --serial-ref 123
sscc 395060000000001235 check: mod10 pass
element-string (00)395060000000001235
gs1-128 → pallet-label.svgThe construction is trivial. The allocation is not, and it is where plants get hurt: the serial reference space under your prefix is finite, shared across every line and site that allocates from it, and an SSCC must never be reissued while any system in the chain could still hold the old one — receiving systems key on it for years. That means allocation is a durable-state discipline — ranges assigned per line, allocations journaled, no-reuse windows enforced — and honesty requires saying that a stateless generator cannot promise it. Rendering and validation are free and local, forever; guaranteed-collision-free range management is the managed half of this property, because the promise is only as good as the state behind it.
The label ↔ ASN contract
Here is the part the mandate letter never spells out: the pallet label is one half of a contract whose other half is electronic. When your customer's systems receive the shipment, the despatch advice (the ASN — in X12 terms, an 856) announces each pallet by carrying the same SSCC in its marks-and-numbers reference; the receiving dock scans the physical label; and the join between paper-free receiving and your shipment is the string equality of those two values. The SSCC you print is the SSCC you send. If the label prints one serial reference and the ASN transmits another — the classic symptom of a label system and an ERP allocating independently — receiving falls back to manual check-in, and the mandate you spent this quarter satisfying reports as failed at the only gate that counts.
The plant-side law that follows: one allocator, both consumers. The SSCC is allocated once, and both the label print job and the ASN line item read the same allocation record. How the ASN side carries it — and how the whole despatch advice maps onto the event record — is transactions.dev's side of the family.
Verification before the print run
The label is where errors become physical, so the gates run before the printer does. The complete pre-run check, all local, all free:
$ npx barcoding.dev verify 395060000000001235 # SSCC: mod10 pass
$ npx barcoding.dev verify 10950600013436 # case GTIN: mod10 pass
$ npx barcoding.dev resolve "(00)395060000000001235(02)10950600013436(37)48(10)AB12"
→ sscc 395060000000001235 · contains: gtin 10950600013436 × 48 · lot AB12Check digits verified against pinned vectors — the same mod-10 of GenSpecs §7.9, tested against published test values rather than a routine someone typed in 2019. And the last line is the gate that matters most: the round-trip. Every label artwork the generator emits is resolved back before it ships to the printer, and the parsed result must equal the input — symbology quirks, FNC1 placement, human-readable interpretation line and all. A label that fails its own round-trip never reaches the plate. (The round-trip is not a QA habit but a law of the package, gated in CI — that story is its own post.)
That is the whole discipline: three symbologies placed by physics, one identifier allocated like the durable commitment it is, and a round-trip gate between generation and glue. Run the label you owe your customer through it today — generate and verify are pure, local, and free, and the printed result will scan at their dock because it scanned at yours first.
Keys open the network half of the verb set. Get an API key — say what arrives at your door, and the provisioning order follows the list.
We answer in writing. We take at most five conversations a month, only when you ask for one, and only after you already have the written read.