Coder and serializer stitched to the ERP — zero serial mix-ups
The coder and the DSCSA serialization system are the last physical piece before the customer and the auditor. iLEAN Connect stitches them bidirectionally to the ERP: batch, expiry date, serial range and aggregation travel automatically from the active work order. The serial mix-up from human typing disappears.
The coder has an API — but the batch is still typed by hand at every order change.
In a hormonal pharmaceutical plant packaging and serializing product for export, the coder and the serialization system are modern equipment: both expose APIs. The problem is that they are isolated from the ERP and the DSCSA hub: nobody has stitched them together, and the data that already lives in the work order is translated by hand at the panel:
- Manual typing at every order change — when a new work order enters, someone types the new batch and expiry date into the coder's panel, and reconciles the serial range and the aggregation by hand with the serialization system. One panel, several error opportunities, no cross-check with the ERP.
- One misplaced finger is half a production run compromised — a wrong batch digit or a badly entered serial range turns half a production run into badly aggregated serials: a mix-up at the customer and a Class-I recall in the USA, with a single impact above half a million euros and the suspension of the qualification as an exporting CMO. Estimate to be validated with your plant's data, but that is the order of magnitude.
The ERP knows which batch, which expiry, which serial range and which aggregation apply — but it does not tell the coder or the DSCSA hub. Someone has to translate by hand, with the line stopped waiting and the regulatory risk on the table.
Connect stitches two modern systems via API — a batch change is one tap in the ERP, not typing at the coder.
The order change needs no more screens or reconciliations: the data that already lives in the ERP needs to reach the coder, the serialization system and the DSCSA hub at the same time, without anyone rewriting it. That is what Connect is for.
When the ERP marks the order's startup, it automatically publishes batch, expiry date, serial range and case/pallet aggregation to the coder and the DSCSA hub. A batch change = one tap in the ERP, not typing at the coder.
How Connect operates on a hormonal plant's serialization line:
- Connect stitches the two systems via API — the coder and the serialization system already have modern interfaces; Connect connects to both and to the ERP without touching the line's PLC or replacing any equipment.
- The ERP publishes on order startup — batch, expiry date and serial range reach the coder the instant the work order starts, in a single transaction.
- The aggregation travels in the same package — the case/pallet hierarchy is published to the serialization system along with the serial range, and Connect reads back the real aggregation events to compare them with what was declared.
- The DSCSA hub receives the same source data — commissioning and aggregation are published to the hub in EPCIS format from the same transaction; the manual reconciliation between what was printed and what was declared disappears.
- Cross-confirmation before releasing the line — Connect checks that the coder and the serialization system have received and applied the same data before releasing the first carton; if one has fallen behind, it holds and notifies.
- The change's record for the auditor — what was published, at what time, to which systems and with what confirmation is archived, without anyone reconstructing it for the inspection.
An order change typed at the panel vs. an order change published from the ERP
| Aspect | Change typed at the panel | Change published from the ERP |
|---|---|---|
| The batch change at the coder | Typed by hand at the panel on every order | One tap in the ERP — published automatically |
| Typing errors or serial mix-ups | 2-3 a month, some with recall risk | Zero of human origin in coding/serialization |
| Serial range and case/pallet aggregation | Entered and reconciled by hand | Published by the ERP in the same transaction |
| Line ↔ DSCSA hub coherence | Manual reconciliation after the fact | The same source data, cross-confirmation |
| The Class-I recall risk from coding | Latent at every order change | The human-origin error triggering it eliminated |
| The change's record for the auditor | A posteriori reconstruction across systems | Automatic archiving: what, when and with what confirmation |
Impact estimate for your plant — to be validated with your own numbers.
The block below is an estimate to be validated against your plant's actual data. We put it forward so the committee has an order of magnitude; we refine it during the assessment.
- Hormonal pharmaceutical plant serializing for export to the USA as a CMO, with a coder and a DSCSA serialization system already equipped with APIs and several order changes per shift.
- Connect pilot on the order change — it stitches the two systems to the ERP and the DSCSA hub via API, replacing no equipment and touching no line PLC. First value expected within a few weeks.
- Fast payback estimated between 3 and 6 months, depending on the frequency of order changes per shift and the cost of stopped line time on each change. Estimate to be validated.
- The hard lever is the drastic reduction of the Class-I recall risk from serial mix-ups: a single event has a one-off impact above €500K plus the suspension of the qualification as an exporting CMO. One avoided recall pays for the pilot many times over. Estimate to be validated.
And the fair question from the serialization manager
"What if the AI invents a batch or a serial range?" — it cannot: in this case the AI does not generate data, it transports it anchored. The batch, the expiry, the serial range and the aggregation come straight from the ERP's active order; hallucination is a problem of free generation, not of anchored tasks, where the best models brought the error below 1.5% [1]. And even then, nothing critical is decided alone: Connect reads back what the coder and the serialization system confirm having applied, compares it against what was published and holds the startup if anything differs, notifying the person before the first carton leaves. The safety rings are there precisely for this.
[1] OpenAI paper "Why Language Models Hallucinate", 2025 — on the reliability of AI in anchored tasks.
What people ask about stitching the coder and the serializer to the ERP
Which protocols or APIs does the integration with the coder and the serialization system use?
Connect connects to the coder and the serialization system by REST API or OPC-UA, depending on what each machine exposes — most DSCSA serialization lines in operation already bring one of the two. On the ERP side, Connect integrates by REST API or webhook over the work orders module, without touching the database directly. Towards the DSCSA hub, events travel in EPCIS format, the traceability event standard the hub already consumes. There are no intermediate files or manual exports: it is event-by-event publication, the moment the order starts.
What happens if the coder loses connection in the middle of an order?
The line does not stop: the coder keeps printing with the batch and serial range it already has applied and confirmed, because the data was published complete at the order's startup. What Connect does is hold the next change: if on closing the order or starting the next one the connection is unavailable, it does not let a half-loaded data set start and notifies the line manager with a short phrase. As an emergency exit the usual manual mode exists — typing at the panel as today — but with the validated data printed from the ERP, not from memory. Connect adds no single point of failure: it steps aside without blocking the line.
How is the case/pallet aggregation synchronized?
The aggregation hierarchy — which carton serials go in which case and which cases on which pallet — is defined in the ERP alongside the order's serial range, and Connect publishes it to the serialization system in the same transaction as the batch and expiry, not in separate calls. As the line aggregates, the serialization system returns the real aggregation events and Connect reads them back and compares them against what was published: if a serial appears in a case that does not correspond to the declared hierarchy, it is flagged before the pallet closes, not when the customer scans it at destination.
How does Connect interact with the DSCSA hub?
Connect publishes to the DSCSA hub the same data package it publishes to the line: serial commissioning, case/pallet aggregation events and batch and expiry data, in EPCIS format. Coming out of the same transaction, the coder, the serialization system and the hub work on a single source data set — the ERP's active order — and the manual reconciliation between what the line printed and what the hub declared disappears. Before the order's closure, Connect verifies that what the line confirmed and what the hub accepted match; if they differ, it holds and notifies.
Does this replace the serialization line operator or free them?
It does not replace them: it takes away the typing of the batch, the expiry and the serial range at the panel on every order change, the mechanical, error-prone part of the job — and the one that can end in a Class-I recall. The batch change goes from typing at the coder to a confirmation tap in the ERP. The recovered time returns to what does require human judgment: the line clearance, the review of the first printed carton and the control of the line's real startup.
See the coder stitched bidirectionally to the ERP and the DSCSA hub — tell us your case and we will send within 48h the estimated ROI for your hormonal plant.
We work on your plant's real data, not ours. Assessment with no commitment.
Request estimated ROI within 48h ‹ See all 13 hormonal pharma cases See pharma