Sort incoming mail
Incoming mail is recognised, categorised and forwarded to the right person. Order confirmations enter the checking process.
Client project · Commercial door manufacturer, St. Pölten district
20 millimetres that nobody has to catch by hand anymore.
A manufacturer of commercial doors orders from its suppliers by e‑mail and receives the order confirmations by e‑mail. Three clerks check whether the supplier understood what was ordered. From autumn 2026 the mailbox does the groundwork. Version 1 is finished and awaiting the IT provider’s sign-off.
- Business
- Commercial doorsdoor leaves, frames, hardware for building projects
- Clerks
- 3check order confirmations
- Purchase orders
- 4–8per week, each with its own confirmation
- Scope
- Fixed priceabout two months of implementation
Starting point
It almost always matches. And sometimes it doesn’t.
Purchase orders go to suppliers by e‑mail. Days later the order confirmation comes back, also by e‑mail. A clerk searches for it in the mailbox, opens the purchase order next to it and compares line by line: dimensions, quantities, variants. Did the supplier understand what was ordered?
Every supplier writes its confirmation differently. Different order, own abbreviations, missing fields. The comparison takes expertise but is dull work that makes you blind over time. A 20 millimetre deviation in the door leaf width slips through easily in the third document of the day. The consequences range from rework to a door that does not fit: material, time, weeks of delay.
Before
- Purchase order by e‑mail
- days later
- Confirmation from the supplier
- search
- Mailbox search it
- by hand
- Comparison line by line
- forward
- Release to production
What was built
No new system. The mailbox thinks along.
The business keeps working as before: ordering by e‑mail, confirmations arriving by e‑mail. In between there is now a service that reads the mailbox.
Find the purchase order
For every confirmation the matching purchase order is found in the order folder, whether as PDF or as an Excel file.
Read both documents
Purchase order and confirmation are read in a structured way: items, dimensions, quantities, variants. Even when the supplier formats differently, abbreviates or omits fields.
Compare and report
Line by line. The result goes to the clerk as an e‑mail with a short PDF. They decide, the system prepares.
Keep running without us
A fixed lookup table is not enough for this many document variants. The system learns new variants itself. New suppliers are added without JMK having to step in.
- Input
- The business’s existing e‑mail mailbox
- Documents
- Purchase orders as PDF or Excel, order confirmations as PDF, structured differently per supplier
- Output
- E‑mail to the clerk with comparison and PDF
- Operation
- Runs in operation without JMK, learns new document variants itself
The historical material was not prepared for machine learning. There was no table saying which supplier, document type, layout version and fields each document contained. The system first had to derive the structure from the history itself.
Under the hood
Ten years of documents. No training dataset.
It groups related documents by layout and content, determines supplier and document variant in several passes, derives shared field structures from that and applies the right extraction per group. A different method for each step: fixed rules where the layout is stable, statistics and models where it is not. And the schema is not generated once during development. The system keeps maintaining its learned knowledge as new variants appear.
The chain behind one result e‑mail
Historical material
About ten years of purchase orders and confirmations, unlabelled, in changing formats.
Document analysis
Layout and content of every document are captured before anything is classified.
Grouping
Similar documents come together by layout and content. Suppliers and their versions emerge from the data, not from a list.
Supplier and variant
In several passes the system determines who a document comes from and which version it is.
Learning the schema
From the groups a shared field structure emerges, one that grows with new variants.
Extraction per group
Rules where the layout is stable. Models where it is not. Items, dimensions, quantities, variants.
Fixed checks
Whatever was extracted is checked against fixed rules: plausibility, completeness, units.
Matching
The confirmation finds its purchase order, even when the reference only sits in the e‑mail thread.
Comparison
Line by line, with the value from both documents.
Decision
The clerk decides. The system prepares.
What the product codes contained
The suppliers’ codes carry expertise that was documented nowhere: which positions stand for material, climate class and fire rating is something an experienced clerk knows, but no table does. The system reconstructed that structure from the correlations in the data.
Differently per supplier: one distinguishes tubular chipboard from solid chipboard, another does not carry tubular chipboard at all, a third encodes the same property somewhere else. From these vocabularies a shared representation emerges, and only that makes the comparison possible.
Why the mailbox stays
The cleanest solution would have been to reorganise communication: every supplier replies to the clerk who placed the order, with a consistent reference. That is an organisational project, not a software project. So the shared mailbox stays, and the system itself recognises what kind of e‑mail it is and who is responsible.
The clerk opens one e‑mail instead of two documents. What matches is ticked off. What deviates is highlighted at the top, with the value from the purchase order and the value from the confirmation.
After
Built for minutes instead of hours, with the mismatch at the top.
With JMK
- Mailbox is read
- automatic
- Matching order found
- structured
- Comparison line by line
- minutes
- Report e‑mail with PDF
- checked
- Decision by the clerk
| Item | Order | Confirmation | Status |
|---|---|---|---|
| Door leaf, height | 2,110 mm | 2,110 mm | match |
| Door leaf, width | 880 mm | 860 mm | mismatch |
| Frame, wall thickness | 125 mm | 125 mm | match |
| Quantity | 4 | 4 | match |
Scope and status
What we can prove is here. The rest follows.
- Scope
- Fixed price for the agreed scope, about two months of implementation from the first conversation to the first version. The budget is not yet used up.
- Status
- Version 1 is finished and waiting for approval by the client’s IT provider. It goes live in autumn 2026.
- Results
- We publish operating figures and a quote from the client only once they exist. We only write here what we can prove.
- Client
- Anonymised at the client’s request: a manufacturer of commercial doors from the St. Pölten district, on the market for about twenty years.
Transferable
Same workflow, different documents.
Two documents that have to match, and a person who checks them: that exists in almost every business.
- Delivery notes against purchase orders
- Incoming invoices against order confirmations
- Supplier quotes against requests
- Field service feedback against work orders