The encoder, stitched to the ERP, no typing

The problem

The same data typed twice, in the place where a mistake costs most.

double entry, sync risk between ERP and encoder on a last-minute change.

• The encoder prints batch, best-before date, product and the allergen declaration. It is modern, capable and has a documented interface — and it sits outside the real flow.
• Every format or formula change means somebody picks the right template by hand on its panel, retyping data that is already in the ERP two meters away, under time pressure and usually near the end of a shift.
• The changes are constant because the mix is high: sweet paprika in a jar in the morning, a functional blend in stick packs in the afternoon, bulk for an industrial customer at night.
• One wrong finger on that panel is a whole run printed with the previous product's allergen line. That is not scrap, it is a withdrawal, and if it has already shipped it is a customer non-conformity served on a plate along with the recall cost.

How it fits the IRIS system

Connect stitches the two systems through APIs, replacing neither.

Connect integrates ERP and encoder without replacing either; the ERP becomes the single source of truth.

What was actually printed comes back confirmed to the system: not what was asked to be printed, but what the encoder says it printed. That distinction is what turns the code on the pouch into evidence instead of an assumption, and it is the difference that matters when a customer sends you a photo of a bag and asks what happened.

See the full IRIS architecture →

Before and after

The isolated encoder versus the stitched encoder

Aspect	Today	With iLEAN Connect
Typing the same data	Twice per changeover	Once, in the ERP
Wrong allergen line printed	A permanent risk	Eliminated by construction
Changeover time on the encoder	Minutes on the critical path	A tap in the ERP
What was actually printed	Assumed	Confirmed back to the system
Best-before date	Recalculated by hand	Derived from the order
Either system	—	Neither is replaced

risky double entry → one source of truth reflected automatically.

Impact estimate

Estimated impact — to validate 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.

• No standalone payback figure is claimed here: the brief measures this case by the risk it removes, not by a month count, and inventing one would be dishonest.
• What disappears is incorrect labeling, the single most expensive failure mode in food and the one that ends in a withdrawal rather than in a rework order.
• On top of that, the double entry on every format changeover, which is minutes on the critical path of the shift and not idle time somebody had spare.
• With a high mix, the number of changeovers stops increasing your exposure: more changes, the same risk, which is none.

elimination of out-of-sync labeling risk, time saved on double entry. *Estimate to validate*.

And the fair question from the production manager

"Wouldn't a classic integration be cleaner?" — it would, on the day that project reaches the top of the list, and that is the problem: this is the textbook case of a modern machine still isolated because there was never time. On the extraction side it is an anchored task where the best models drop below 1.5% error [1], and the stitching replaces neither system and needs no shutdown window, so it does not compete in that queue.

^[1] OpenAI paper "Why Language Models Hallucinate", 2025 — on the reliability of AI in anchored tasks.