A serial number in your ERP is just a row in a database. By the time a pallet leaves the factory, that number needs to be on the right pack, readable, inside the right carton, and recorded as shipped-ready in the system that will answer questions about it later. How does it get from one to the other, at 120 packs a minute, without mistakes?
The connected product journey
- 1GS1Brand licenses a company prefix and assigns GTINs.
- 2ERPHolds the product master, batches and, often, serial numbers.
- 3Line gatewayEdge software that hands codes to the line and records results.
- 4CoderPrints the code onto the pack or label.
- 5ScannerCamera reads it back and rejects bad prints.
- 6CartonVerified units are packed and linked to a carton code.
- 7PalletCartons are linked to a pallet with its own SSCC.
- 8DistributorReceives and ships by scanning logistic units.
- 9RetailerSells the unit; POS reads the GTIN.
- 10ConsumerScans the same code for information or services.
This guide follows one perfume box through a packaging line, station by station, and explains what each step actually proves.
The line we will follow
Our example is a fictional fragrance house, Maison Ardent. Its Line 3 fills and boxes a 100 ml eau de parfum at 120 units a minute — two boxes every second, or one every half-second. Each individual box will carry a 2D code containing the product's GTIN, batch, expiry date and a unique serial number. Boxes are packed twelve to a shipping carton, and sixty cartons make a pallet.
Maison Ardent has chosen unit-level serialization because it runs a consumer authentication and loyalty programme. That is a business choice — not every product needs serialization — but once made, it changes what the line has to do.
The journey diagram at the top of this page shows the stations in order. Here is what happens at each one.
Station 1: the ERP issues serial numbers
The journey starts before any box moves. Maison Ardent's ERP (enterprise resource planning system) creates a production order for batch 25A117 and issues a block of serial numbers for it.
At this point, the serials are reserved data. Nothing physical carries them yet. The ERP is the authority for which serials exist and which product and batch they belong to.
What this step proves: these serial numbers are allocated to this product and batch, and nobody else should use them.
What it does not prove: that any of them will ever be printed. A production order can be cancelled, a line can stop early, and some serials will be spoiled. We look at this stage in more detail in what happens after an ERP creates a serial number.
Station 2: the line gateway takes a local pool
The line cannot ask the ERP for a fresh number every half-second. A network delay of even one second would mean two boxes passing the coder with nothing to print.
So line-side software — often called a line gateway or edge controller — retrieves the serials in advance and keeps them in a local pool on the factory floor. Think of it as a cashier's float: the till holds enough change to serve customers without walking to the bank for every sale.
The gateway stores each serial with a status (available, queued, printed, and so on) in local storage that survives a restart. It then feeds serials to the coder one at a time, in step with the line.
What this step proves: the line has enough identities, held safely on site, to keep running. Why this local layer matters is the subject of why edge software matters on a packaging line.
Station 3: the coder prints the code
As each box passes a sensor, the gateway sends the next serial to the coder — the industrial printer that marks variable data on packs. Depending on the line, that might be a thermal inkjet head, a laser or another technology. The coder builds the 2D code and the human-readable text and marks them on the box as it moves past.
Most coders acknowledge each message: "received", "queued" or "printed". These acknowledgements are useful, but they describe what the printer did, not what is on the box. An ink nozzle can be partly blocked, the box can be skewed, or the print can smudge. We explain the coder itself in what an industrial coder does.
What this step proves: the coder received this serial and reported attempting to print it.
What it does not prove: that the code on the box is readable, complete or correct.
Station 4: the camera reads it back
A short distance after the coder, a fixed camera or barcode reader images each box and decodes the code. The gateway then compares what was read with what it expected: the same GTIN, batch, expiry and — crucially — the serial it just sent for this box.
Three outcomes are possible:
- Match. The code was readable and carries the expected identity.
- Mismatch. A code was read, but it is the wrong serial — perhaps the queue slipped by one, or a box was removed by hand.
- No read. The camera could not decode anything: missing print, smear, or a box out of position.
Only a match lets the box continue as a good pack. This is verification of identity, not a print-quality grade — a distinction explained in why "printed" is not the same as "verified".
What this step proves: a code carrying the expected identity was readable on this pack, at this moment, by this camera.
Station 5: the reject station removes bad packs
When the camera reports a mismatch or no-read, the line must take that specific box out. A pusher or air jet diverts it into a reject bin, timed using the conveyor's position.
A careful line does not stop at "the reject command was sent". It also checks that the box actually left — for example with a sensor in the reject chute. Without that confirmation, a failed pusher could let an unverified box continue into a carton.
The rejected box's serial is marked as rejected and, in most programmes, is never issued again.
What this step proves: a pack that failed verification was physically removed — but only if the line confirms the reject, not just commands it.
Station 6: packing into cartons
Good boxes are packed twelve at a time into a shipping carton. At the packing station, each box is scanned again (or the gateway tracks the boxes it already verified), and the carton receives its own label — commonly carrying an SSCC, the GS1 identifier for a logistic unit.
The gateway now records a parent–child relationship: carton X contains these twelve serials. This is aggregation. Its value comes later: a warehouse that scans one carton label can know which twelve products are inside without opening the box.
A sensible rule here is that only serials with a confirmed camera match are eligible for packing. If a box with no verified status turns up at the packer, it should be flagged, not silently accepted.
What this step proves: these specific verified packs were placed in this carton. Aggregation is explained in depth in how individual products become cartons and pallets.
Station 7: building the pallet
Sixty cartons are stacked onto a pallet, which gets its own SSCC label. The gateway records another level of the hierarchy: pallet P contains these sixty cartons, and therefore 720 individual boxes.
Any change after this point — a carton pulled for quality sampling, a damaged carton replaced — must be recorded as a change to the hierarchy. Otherwise the pallet record describes contents that are no longer there.
What this step proves: these cartons, and by extension these serials, are on this logistic unit.
Station 8: registering back to the ERP
Finally, the results go back to the system of record. The gateway reports which serials were packed into which cartons and pallets, and which were rejected or voided. The ERP updates its stock and the serial status for batch 25A117.
This is where reliability matters most. The network may be down. The ERP may be busy. A message may be sent, the connection may drop, and the gateway may not know whether the ERP received it. Re-sending blindly risks registering a carton twice; giving up risks losing it.
Robust line software handles this with a persistent outbox: registrations are written to local storage first, then delivered, and if the outcome is uncertain the software checks the ERP's current state before trying again. We explain the principles in what exactly-once serialization means.
What this step proves: the enterprise system now knows which serials became real, packed products.
What each station proves — in one table
| Station | What it proves | What it does not prove |
|---|---|---|
| ERP issues serials | The serials are allocated to this product and batch | That they were printed |
| Gateway pool | Identities are held on site, ready for the line | That the line used them |
| Coder | The printer received the serial and reported printing | That the code is readable or correct |
| Camera read-back | A code with the expected identity was readable | Formal print quality grade, or authenticity |
| Reject station | A failed pack was removed (if confirmed) | Anything about the packs that passed |
| Carton packing | Verified packs are inside this carton | That the carton later reached its customer |
| Pallet build | These cartons are on this pallet | That nothing was removed after build |
| ERP registration | The enterprise record matches the line's results | What happens in distribution |
Read this table as a chain of evidence. Each link is small, specific and checkable. A traceability claim is only as strong as the weakest link.
Where events and standards come in
The line's records map naturally onto supply-chain events. In GS1's EPCIS standard and its Core Business Vocabulary, bringing a serialized item into existence is described as commissioning, and placing items into a carton or pallet is described by aggregation events with a business step such as packing. A business can share these events with trading partners.
The important practical point is which station should trigger which event. A commissioning record based only on "the printer said printed" is weaker than one based on a verified camera match. For how these records fit together across the supply chain, see what EPCIS is.
Common ways the journey breaks
Most serialization problems on real lines are not exotic. They come from a few predictable gaps:
- Queue drift. One box is removed by hand between coder and camera, and every following serial is compared against the wrong expectation. Good software detects this as a run of mismatches and stops rather than rejecting everything.
- Unconfirmed rejects. The reject command fires but the pusher misses. An unverified box reaches the carton.
- Reprints reusing serials. An operator reprints a box after a smudge using the same serial, while the first box is still somewhere on the line.
- Silent offline growth. The network drops, the line keeps running, and nobody notices the registration backlog until the end of the shift. See what happens when the internet or ERP goes down.
- Assumed compatibility. A new code format (say, switching from a GS1 element string to a phone-openable web address) is pushed to the coder without re-testing printer, camera and packing behaviour.
The short version
A serialized product's journey is a hand-off between systems, each proving one small fact. The ERP allocates. The gateway holds and sequences. The coder marks. The camera confirms. The reject station removes. Packing and palletising record what is inside what. Registration closes the loop.
If you are planning or reviewing a serialization project, ask of every station: what exactly does this prove, and what happens when it fails? The answers are where most of the engineering — and most of the risk — lives. For how the same identity continues beyond the factory gate, read the connected product journey from factory to consumer.
Discuss serialization on your packaging line