The lab spreadsheet stops living in a world apart from the ERP

The problem

The migration data lives in one world and the ERP in another.

Two parallel worlds: the real spreadsheet, holding live migration and adhesion data, and the official ERP, with data retyped weeks late by someone spending half a day a month copy-pasting — and making mistakes in data a BRC auditor may request per run.

• Every run, the quality lead fills a spreadsheet with varnish test parameters: migration and adhesion results, cure checks, the BPA-NI status of the interior varnish.
• That spreadsheet lives in a shared folder the ERP never sees. The official system holds a copy retyped weeks late.
• Somebody spends half a day a month copying and pasting, and makes mistakes in exactly the data a BRCGS Packaging auditor may request per run.
• When a packer client asks for the migration result of a specific run, the answer is in the spreadsheet, not in the system that should hold it. And whoever answers has to trust that the version they open is the latest one.

How it fits the IRIS system

Connect in inward-listening mode — it reads the shared folder, not the person.

Connect inward-listening mode: reads the shared folder (not the person), parses each cell with an anchored LLM as soon as the file is saved, and validates on screen before pushing to the ERP via API.

The lab keeps working in its spreadsheet and the ERP stops being weeks behind it. The migration result of each run is in the system on the day the technician saves it. That is what turns a packer client's question or an auditor's request into a query instead of a search through versions.

See the full IRIS architecture →

Before and after

The lab spreadsheet in its own world versus the spreadsheet linked to the ERP

Aspect	Today	With iLEAN Connect
Migration result in the ERP	Weeks behind the spreadsheet	Instant, after validation
Copy and paste by the lab	Half a day a month	None
Adhesion and cure results per run	Retyped with errors	Parsed cell by cell
BRCGS auditor asking per run	Data never cross-checked	Cross-checked automatically by run
Spreadsheet layout	Must not be touched	Read as the lab keeps it
Lab people logging into the ERP	Five, just to enter data	One, the validator

Weeks of lag → instant. Half a day/month retyping → zero. BRC auditor facing uncross-checked data → automatic per-run cross-checking.

Impact estimate

Impact estimate — to be validated with 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.

• Estimated payback 4-9 months.
• 💰 CFO angle: if five lab people log into the ERP just to enter data, that is five licenses; with Connect only the validator needs one — a typical 50-80% reduction in quality and lab module licenses.
• Half a day a month of retyping goes to zero, and the lag between spreadsheet and ERP goes from weeks to instant.
• And the auditor gets migration data already cross-checked per run instead of a spreadsheet and a printout that disagree.

CFO angle: if 5 lab people log into the ERP just to enter data today, that's 5 licenses; with Connect, only the validator needs one. Typical reduction of 50 to 80% in quality/lab module licenses. Estimated payback of 4 to 9 months. Estimate to validate.

And the fair question from the production manager

“That spreadsheet has been changed by several people for years — will it read it?” — that is the expected case. Parsing does not rely on fixed positions: it interprets columns, units and margin notes as they are. It is an anchored task where the best models drop below 1.5% error [1], and the validator checks the result on screen before anything is pushed to the ERP. And when the layout changes, the first parse of the new version is flagged for review instead of trusted blindly.

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