Marking stops depending on somebody typing
Marking is the last physical thing that happens to the product before it stops being yours: the coder prints batch and expiry on every container and the print-and-apply labeler sticks the GS1-128 label on every pallet. Both machines are modern, both have an API, and in most plants both still receive their information by hand. Connect stitches them to the ERP: what gets printed is exactly what the active order publishes.
One wrong finger at sixty thousand containers an hour.
Somebody types the new batch into the coder panel at every changeover. One wrong finger at sixty thousand containers an hour means tens of thousands of units with the wrong batch before anyone notices, at the point of greatest consequence in the whole plant. On the pallet side, if the label code does not match what the warehouse believes it has, the imbalance carries through to the distribution center. And the keying continues for a perfectly reasonable reason that repeats every year: integrating them properly takes time and requires stopping the line to test it.
- Somebody types the new batch on the coder panel at every changeover, at the point of greatest consequence in the whole plant.
- Tens of thousands of units with the wrong batch before anyone notices, because at that cadence the error multiplies faster than it is detected.
- On the pallet side, if the label code does not match what the warehouse believes it has, the imbalance carries through to the distribution center.
- And the keying continues for a reasonable reason that repeats every year: integrating them properly takes time and requires stopping the line to test it.
Connect stitching two modern systems through the API, replacing neither and without touching the PLC.
Connect stitching two modern systems through the API, without replacing either and without touching the line PLC. Step by step: (1) the ERP or MES marks the order start; (2) Connect publishes brand, batch, expiry and destination market to the container coder and the pallet print-and-apply labeler; (3) both print; (4) Connect returns to the ERP confirmation of what was actually printed. It is bidirectional, not just push: the system knows what was printed, not only what was ordered to print. Changing batch becomes a change in the ERP, not a keystroke on a panel.
Changing batch becomes a change in the ERP, not a keystroke on a panel. And it is bidirectional: the system knows what was printed, not only what was ordered to print.
- The ERP or MES marks the order start — that is where the truth about which brand, batch and expiry are due lives.
- Connect publishes brand, batch, expiry and destination market to the container coder and the pallet print-and-apply labeler.
- Both print what they received, without anyone typing anything on any panel.
- Connect returns to the ERP confirmation of what was actually printed, which is the part almost nobody implements and the one that turns this into real traceability.
- Both machines are modern and already have an API: nothing needs replacing, only using what is already paid for.
Keyed marking vs. marking published from the ERP
| Aspect | Current marking | With iLEAN Connect |
|---|---|---|
| Source of the batch | Typed on the panel at each changeover | Published by the ERP through the API |
| Human error at source | Possible at every changeover | None: there is no keying |
| Scale of the failure | Tens of thousands of containers | Never happens |
| Pallet label | May not match the warehouse | Same source as the container |
| Confirmation of what was printed | Does not exist | Returned to the ERP |
| Batch change | A keystroke on a panel | A change in the ERP |
Coding keying errors several times a year, some with mass rework or product hold, to zero human-origin marking errors. Pallet labels that do not match the warehouse to zero.
Impact estimate for your plant — to validate against your 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.
- High-cadence packaging lines with a container coder and a pallet print-and-apply labeler, both with an available API.
- Indicative payback between 3 and 6 months, through avoided mass rework and product holds.
- A single wrong-batch incident per year is enough to justify it: at that cadence, the cost of one alone exceeds the project.
- It is also the technical prerequisite for the flagship batch release case: without reliable marking there is no possible verification at the dock.
Estimated payback 3-6 months through avoided mass rework and product holds. It is also the technical prerequisite for the flagship batch release case. *Estimate to validate*.
And the fair question from the production manager
“What if the system publishes the wrong batch to the coder?” — there is no interpretation involved: Connect does not read or compose the batch, it carries it from the active ERP order, which is the source of truth. This is not an AI task with a margin of error, it is an API integration. The risk being removed — human keying under pressure at every changeover — is of a different order of magnitude.
[1] OpenAI paper "Why Language Models Hallucinate", 2025 — on the reliability of AI in anchored tasks.
What people ask about stitching marking to the ERP
Does the coder or the labeler have to be replaced?
No. These two machines are usually among the most modern in the plant and almost always already have an open API: what is missing is not technical capability, it is the integration project that never reaches the top of the priority list. Connect uses that API. If your coder is from an earlier generation with no interface, that shows up in the assessment, but it is the less frequent case.
Does the line have to be stopped to integrate it?
That is precisely why this has been pending for years in many plants, and it is why it matters: publishing is first tested against the machine during a planned stop or an already scheduled changeover, not by asking for a dedicated downtime window. The line PLC and the machine logic are not touched: it is sent through its own interface what a person types into it today.
What does the plant gain from confirmation of what was printed?
It is the difference between knowing what you ordered printed and knowing what was printed. Without that return, if somebody changes something on the panel or the machine fails, the system still believes everything came out as planned. With it, the ERP has a record of what was actually marked on each container and each pallet, which is what makes it possible later to block a pallet whose marking does not match.
Does this eliminate marking errors completely?
It eliminates the human-origin error, which is the one that produces mass incidents: the batch mistyped on the panel. What remains is physical machine failure — dirty print head, illegible printing, badly applied label — which is of a different nature and is covered by the inline vision case, where the camera reads what the coder just printed.
Why is it a prerequisite for the release case?
Because the flagship system cross-references, at the dock, each pallet's marking against the batch release status. If the marking comes from manual keying, that cross-reference compares the system against itself with an unreliable link in the middle. When marking is published from the ERP and confirmed back, the dock verification means something.
Check whether your coder and pallet labeler already have an open API and we will tell you within 48h what it would take.
We work on your plant's real data, not ours. Assessment with no commitment.
Request estimated ROI within 48h ‹ See all cases of industrial brewery See food industry