Intelligent Order Processing for a Swiss Logistics Operator

TL&DR

‍
A mid-market Swiss logistics operator was losing time and margin to manual order entry - purchase orders arriving by email and PDF, each read and matched by hand against a product and pricing catalog. The software partner building the client's platform had already scoped the obvious fix: route every document through an AI model. Kynera was brought in to identify the cost problem the plan would create at scale, and to design and build the routing architecture that replaced it. The result was a confidence-based routing system that sends simple, familiar orders through a fast, low-cost extraction path and reserves higher-capability AI for the documents that actually need it — validated against strict data contracts before anything reaches the client's ERP, with anything the system can't resolve confidently routed to a person instead of guessed at. Tested across a structured set of real order formats, the system reached an 82% straight-through processing rate and freed roughly 14 hours of manual work per week.

‍

The order queue was the bottleneck

A mid-market logistics operator headquartered in Switzerland was receiving purchase and fulfillment orders the way most operations at this scale still do: by email. Some arrived as plain text, line items typed directly into the message body. Others as PDF order forms, each formatted differently depending on the system the customer's own organization used to generate them. A staff member read every line, matched it against the product and pricing catalog by hand, confirmed the correct volume-tier rate, and flagged anything that didn't resolve cleanly — an unrecognized SKU, an unmatched customer account, a line item that needed a custom quote instead of a listed price.

At this order volume — dozens of incoming orders a day, arriving continuously — that isn't a staffing problem. It's a margin and throughput problem. Every order that consumed fifteen minutes of manual matching instead of automated processing was capacity the team wasn't spending on the accounts and decisions that actually required judgment.

‍
‍

The ask

‍

The brief, as it reached Kynera through the client's software partner, was straightforward: automate order intake so the team stops re-keying data from email and PDF into the order system. The software partner had already scoped what looked like the answer — route every incoming document through an AI model, extract the order, done.

‍
‍

What was actually behind it

‍

That plan solved the accuracy problem and created a cost problem. Running every incoming document — including the large share that were simple, repetitive, and in formats the system had seen before — through a full-capability AI model would have been accurate, but expensive at the volume this operator processes, and slow enough to quietly erode the time savings the automation was meant to create. The cheaper alternative, fixed-pattern parsing with no AI involved, failed for the opposite reason: the moment a customer sent a PDF the parser hadn't seen before — which, across dozens of customer-side systems, is most PDFs — it simply couldn't read it.

Neither extreme was the right architecture. The real question wasn't whether to use AI. It was knowing, document by document, which processing path each one actually needed — and building a system that could tell the difference before committing resources to either path.

‍
‍

The approach: routing before processing

‍

Kynera designed the system around a classification step that runs before any heavy processing begins. Every incoming order is scored on layout familiarity and extraction confidence at ingestion. Standard, high-confidence documents — the majority of volume, orders in formats the system has seen before — are handled by a fast, low-cost extraction path built specifically for repetitive, known layouts. Complex or low-confidence documents — an unfamiliar PDF structure, inconsistent formatting, ambiguous line items — are routed instead to a higher-capability AI model, reserved for the cases that actually need it.

‍

‍

This single routing decision is what kept the system economically sound at the operator's scale. Extraction accuracy on the hardest fraction of documents didn't require paying premium AI cost on the majority that didn't need it — a distinction that compounds as order volume grows, not one that only matters at the margins.

‍
‍

Engineering the pipeline

‍

Confidence-based routing only pays off if everything downstream of it is fast and precise, so Kynera built the pipeline as a set of independent services — ingestion, extraction, and validation — rather than a single monolithic process. That separation had a practical payoff early in the engagement: the core extraction logic was validated against a structured set of real client order formats within the second week, well before the reviewer-facing interface existed. Testing the part of the system that determines accuracy before investing further in the part that determines usability kept the engagement from discovering extraction gaps late.
‍

Two engineering decisions carried most of the weight. A validation layer sits between extraction and the client's ERP, enforcing strict data contracts on quantities, units, and SKU formats before anything reaches downstream systems — extracted data doesn't pass through because the AI produced it, but because it's been checked against rules that don't bend. And a fuzzy-matching layer against the product and customer database closes the gap between how a customer describes an item in an email ( "SBB swap frame, 1200x800" ) and how that item is recorded in the catalog, resolving inconsistent, human-written descriptions to the exact SKU and account in milliseconds — tuned to the client's actual naming conventions, not generic string matching.

The components that touch every single order — ingestion, matching, validation — were engineered for raw throughput and a minimal server footprint, since these run continuously regardless of volume and are where inefficiency compounds fastest.

‍
‍

Confidence has a floor, and the system respects it

‍

Straight-through processing was never the goal on its own. A system that guesses confidently on the wrong SKU costs more than one that pauses to ask. Every order the pipeline can't resolve with confidence — an unmatched customer account, a product requiring a custom quote, a document layout the extractor genuinely can't parse — routes to a manager review queue instead of being pushed through regardless. The system is built to recognize the boundary of what it can decide on its own, and hand off the rest.

‍

‍

Results

‍

Processing.

The system reached an 82% straight-through processing rate — four in five incoming orders extracted, matched, and validated with no manual data entry. The remaining fraction wasn't a shortfall; it was orders correctly identified as needing a human decision and routed to the right person instead of sitting in a queue.

‍

Economics.

Because routing sent only the hardest documents through the more expensive extraction path, the system's AI cost scaled with document complexity, not with total order volume — the difference that made straight-through automation viable at this operator's scale in the first place, rather than a cost center that grew as fast as the business it was meant to serve.

‍

Team capacity.

The shift for the operator's sales and logistics team wasn't only speed. It was where their attention moved — roughly 14 hours a week freed from transcription and re-keying, redirected to the smaller set of orders and customer conversations that actually required judgment. Work a fifteen-minute manual match was never going to improve anyway.

‍

‍

The takeaway

The instinct to point AI at every document is usually right about accuracy and wrong about cost. The systems that hold up at scale aren't the ones that use the most capable model — they're the ones that know which document needs it.
‍

Self-check:

If your team is still re-keying order data from email or PDF into your ERP or order system by hand, the question worth asking isn't whether AI can read the document — most tools can, at some accuracy. It's whether your architecture is paying AI-scale cost on every document, including the simple ones that never needed it, and whether the system you have knows the difference between an order it processed and an order it processed correctly.