Product Serialisation: Printing, Scanning and Aggregation
Serialisation means every individual unit carries a unique identity, not just a product code. Where regulation requires it, that changes printing, scanning and record-keeping in ways a product-level barcode system does not prepare you for.
Serialised is not the same as barcoded
The distinction that catches operations out.
A conventional product barcode says what something is. Every box of the same product carries the same code.
A serialised code says which one it is. Every unit carries a different code, which means every label is unique and no two prints are the same.
Three consequences follow immediately.
Pre-printed labels stop working. You cannot order a batch of identical labels, because each needs different data. Printing moves in-house and on-demand.
Print failures become data problems. A misprinted serialised label is not a wasted label — it is a serial number that must be accounted for, since the system expects it to exist somewhere.
Verification matters more. An unreadable code on a product-level label can be identified by what the product is. An unreadable serialised code cannot, because the identity was the only thing distinguishing it.
What the codes usually carry
Serialised schemes typically encode several fields together rather than one number.
A product identifier, a serial number unique to the unit, and frequently a batch or lot and an expiry date — structured using application identifiers, which mark where each field begins and what it means. Our symbologies guide covers GS1 structures.
Two practical points.
The structure is specified, not chosen. Where a regulator or trading partner mandates a format, that is the requirement, and getting the structure wrong produces rejected goods rather than unreadable codes. Our compliance guide covers obtaining the specification before designing anything.
More data means a denser code. Encoding product, serial, batch and expiry produces a substantially larger code than a product number alone — which drives the printing requirement below.
Print resolution becomes the constraint
Where serialisation projects most often hit hardware limits.
Dense 2D codes on small packaging need 300 dpi or higher. A 203 dpi printer cannot render fine elements accurately at that size, and the failure is intermittent rather than absolute — some codes scan, some do not, which is considerably harder to diagnose than an outright failure. Our label design guide covers matching code size to resolution.
Quiet zones matter particularly here, because serialised labels are usually small and crowded with data. A code pushed against the label edge will not decode however well it is printed.
And because every label is unique, a degrading printhead affects real units continuously rather than producing an obviously bad batch. Our printhead guide covers spotting element failure early.
Verification rather than scanning
The practice that separates operations that pass audits from those that do not.
Scanning tells you a code decoded on your reader today. Verification measures it against a graded standard, which is what tells you whether it will still decode on someone else’s reader, further down the supply chain, after handling.
Where codes are graded by customers or regulators, that grade is measurable and it will be measured. Our verification guide covers the distinction and why declining grades over weeks are an early warning.
Two habits: verify after any change of media, ribbon or printhead, and treat a downward trend as a maintenance signal rather than waiting for failures.
Aggregation multiplies the scanning
The part that adds most operational work.
Serialisation frequently requires aggregation — recording which units are in which case, which cases are on which pallet. That builds a hierarchy so a pallet can be scanned and its contents known.
Three consequences.
Scanning happens at every packing level, not just at dispatch. That is real time per unit, and it has to be designed into the line rather than added at the end.
Errors compound. A unit recorded into the wrong case is wrong at case, pallet and shipment level.
Rework is expensive. Opening a case to correct an aggregation means re-scanning everything in it.
Where many items are packed together, this is a genuine RFID case — reading a full case at once rather than each unit. The usual caveats apply, particularly stray reads, which in an aggregation context means recording a unit into the wrong case.
Scanning requirements
Three specifications that follow from the above.
High-density optics. Dense small codes need optics that resolve them first time. This is fixed at manufacture, not configurable. Our scanner guide covers optics classes.
Data Matrix enabled. It is frequently disabled by default, and it is the format serialised schemes most commonly use. If square codes are not reading while linear ones work, check the symbology before suspecting optics — our configuration guide covers this.
Curved and small surfaces where units are vials, bottles or small cartons, which affects reading angle and argues for 2D codes with error correction.
Specifying for serialisation
What format is mandated, and by whom. What is the smallest code and on what surface. Is your printer resolution adequate for that code size. Is aggregation required, and at how many levels. Is verification to a grade required. And what happens to a misprinted serial — because that process needs designing rather than improvising.
The first answer governs everything, and it should come from the specification document rather than from an example label.
Common questions
How does serialisation differ from ordinary barcoding?
A product barcode says what something is and is identical across units; a serialised code says which one it is, so every label is unique. That rules out pre-printed labels and moves printing in-house and on-demand.
Why does print resolution matter more here?
Because encoding product, serial, batch and expiry produces a much denser code, and dense 2D codes on small packaging need 300 dpi or higher. At 203 dpi the failure is intermittent rather than absolute, which is harder to diagnose.
What happens to a misprinted serialised label?
It becomes a data problem rather than a wasted label, because the system expects that serial to exist somewhere. The process for accounting for misprinted serials needs designing rather than improvising.
What is aggregation and why does it cost time?
Recording which units are in which case and which cases on which pallet, so a pallet scan reveals its contents. It means scanning at every packing level rather than only at dispatch, and errors compound through the hierarchy.
Is scanning the code enough to prove quality?
No. Scanning tells you it decoded on your reader today; verification measures it against a graded standard, which tells you whether it will decode further down the supply chain after handling. Where grades are specified, they get measured.
Get the mandated format from the specification document rather than an example label — that answer governs the printer, the media and the scanner.
