What Happens After an ERP Creates a Serial Number?

Your ERP has just created ten thousand serial numbers for tomorrow's production run. Where do they go next, and how do you know, at the end of the day, which of them are now on real products?

This guide follows the life of a serial number from the moment it is created to the moment the ERP records it as a packed product.

A serial number is born as a reservation

When an ERP (enterprise resource planning system) or a dedicated serialization system creates a serial number, it links that number to a product — usually its GTIN — and often to a batch. In GS1 terms, the serial only identifies an individual item together with the GTIN: the same serial under two different GTINs refers to two different things. We explain that pairing in GTIN + serial: how an individual product gets its identity.

At this moment, nothing physical exists. A good analogy is a theatre booking: the seat is reserved in the system, but no one is sitting in it yet. The reservation can still be used, cancelled or left empty.

So the first status of a serial is something like allocated or reserved.

Step 1: serials are sent to the line in blocks

A packaging line producing 120 packs a minute needs a new serial every half-second. It cannot afford a round trip to the ERP for each one — a single slow network response would stall the line.

Instead, line-side software (a line gateway or edge controller) requests a block of serials for the production order and stores them locally. This block is often called a pool or buffer. Its size is a design decision: big enough to cover the run, rejects and any agreed period without connectivity, but not so big that a cancelled order leaves thousands of serials stranded on a factory PC.

Status now: at the line (available locally, not yet used).

Step 2: a serial is assigned to a specific pack

As each pack reaches the coder, the line software takes the next available serial and sends it to the printer. This is the moment a serial is tied to a physical object — or at least, an intended one.

Status now: sent to printer or queued.

This is a delicate state. The printer may print it perfectly, print it badly, or not print it at all (if, say, the pack was knocked off the conveyor). From here on, the safe assumption is that the serial might exist on a physical pack. That is why it should never be handed out again, even if something goes wrong.

Step 3: the printed code is read back

A camera after the coder reads the code and the software compares it with the serial it sent. If they match, the serial is verified on pack. If the camera reads nothing or reads the wrong serial, the pack is rejected and the serial is marked rejected or void.

This step matters because a printer's "printed" message is not evidence of a readable code. We cover the difference in why "printed" is not the same as "verified".

Step 4: the pack goes into a carton and pallet

Verified packs are packed into cartons and then onto pallets. The line software records which serials went into which carton, and which cartons onto which pallet. The serial's status becomes packed (or aggregated), with a link to its parent carton.

Step 5: results go back to the ERP

Finally, the line reports back. A typical end-of-order report says:

• these serials were packed, in these cartons and pallets;
• these serials were rejected or voided;
• these serials were never used and are being returned or closed.

The ERP updates its records. Only now does its view of the batch match what physically left the line. In traceability vocabulary, the moment a serialized item comes into existence is called commissioning; it is usually safer to record it at verified print or at packing rather than at allocation, because that is when the item demonstrably exists.

The serial's life as a simple state machine

Engineers often describe this as a state machine — a list of allowed states and the allowed moves between them.

The table's value lies in what it forbids. There is no path from "sent to printer" back to "at line". There is no path from "rejected" to "packed". Rules like these are what stop a serial being printed twice or registered twice — the core of exactly-once serialization.

A worked example

Maison Ardent, a fictional perfume house, plans to fill 10,000 bottles of batch 25A117. The ERP allocates 10,400 serials — 4% headroom for rejects.

• The line gateway pulls all 10,400 into its local pool before the shift starts.
• During the run, the camera rejects 85 packs for smudged or unreadable codes. Each replacement pack gets a new serial, so 10,085 serials reach the coder in total, and the 85 rejected serials are voided.
• One verified pack is removed by hand for a quality sample, and the supervisor voids its serial too.
• At the end of the run, 9,999 verified packs are recorded in 834 cartons (the last one part-full) and 14 pallets.
• The gateway reports: 9,999 packed, 86 voided, 315 never used.

Add those up: 9,999 + 86 + 315 = 10,400. Every serial is accounted for. That closing sum — sometimes called reconciliation — is the simplest test of a healthy serialization process.

Who is responsible for what

A common source of confusion is which system "owns" a serial. A useful split:

• The ERP (or serialization system) owns serial values: which numbers exist, for which product and batch.
• The line software owns physical facts: which serial went to which pack, whether it was read back, which carton it went into.
• Neither should overwrite the other. The line should not invent serials outside its allocated range, and the ERP should not mark a serial "packed" without the line's evidence.

We set out the full division of responsibility in how ERP, printer, scanner and line work together, and the whole station-by-station journey in the journey of a serialized product through a packaging line.

Conclusion

A serial number's journey from ERP to pallet is a series of status changes, each backed by a specific piece of evidence. Design the states, decide which station moves a serial from one to the next, and make sure every serial ends in a clear final state. Then the question "which of tomorrow's ten thousand serials are on real products?" has a reliable answer.