Automating order entry from inbox to ERP

QuantSpark built a generative AI pipeline that automates half of customer orders end to end for a private-equity-backed European manufacturer of engineered wood products, turning inbox PDFs into structured ERP records. A four-week feasibility study hit 50% end-to-end automation while beating both of its accuracy targets, and a mid-project model swap to GPT-4o cut inference costs by roughly half.

The problem

Customers ordered by emailing PDF attachments, and no two looked alike. Layouts varied by customer, languages varied by market, and product descriptions were written in the customer's own words rather than the manufacturer's official SKUs. A dedicated team had to read every order, work out what was actually being requested, and rekey it into SAP by hand.

That approach could not survive its own success. It was slow by design, since every order needed a human pass. It was error-prone, since manual rekeying let typos and missed fields through, and those errors surfaced downstream as fulfilment problems rather than being caught at entry. And it had a hard ceiling: headcount would need to grow in step with order volume, in a process that added no value beyond faithfully copying what the customer had already written.

The variability that defeated straightforward automation, multiple languages, inconsistent layouts and customer-specific product terminology rather than official SKUs, is exactly the kind of unstructured-document problem that rules-based extraction and template-matching handle poorly, but that multi-modal generative AI models are suited to reading around.

The approach

QuantSpark started with ideation workshops to prioritise which use case to tackle first, then ran a focused four-week feasibility study on order management specifically, before moving into a proof-of-concept and then an MVP under its standard proof-of-concept-to-MVP delivery model. That staged path meant accuracy could be proven against explicit targets before any production commitment: 40% for order-detail extraction and 30% for product-detail extraction.

Mid-study, GPT-4o was released. The team integrated it within 24 hours, cutting inference costs by roughly half.

Inside the pipeline

The solution is a three-step pipeline. A multi-modal generative AI model reads each PDF and extracts order and line-item detail regardless of layout or language. Classification algorithms, trained on the manufacturer's own historic order descriptions, then predict the single correct SKU for each line, bridging the gap between what a customer writes and what the official product catalogue calls it. Finally, historic purchase data fills any remaining fields the document itself does not specify.

The MVP runs in a production-state Azure environment with automated SAP ingestion. Output is EDI-ready XML, and each order is routed either to fully automatic processing or to manual review, depending on the pipeline's own confidence in its extraction.

Reading the numbers

The feasibility study's headline is that it automated 50% of customer orders end to end, from PDF to product identification, while exceeding both accuracy targets: 50% order-detail accuracy against a 40% target, and 40% product-detail accuracy against a 30% target. At MVP stage, field-level accuracy on the core order fields was strong: split order 92%, delivery plant 90%, quantity 91%, material 83%. Delivery date was the remaining weaker field at 55%.

None of this is expressed in the source as a monetised saving, and the honest way to read it is as an automation-rate and accuracy result, not a pound figure. A real business case for a pipeline like this is normally built by multiplying the automated share of order volume by the manual handling time and labour cost it replaces, then netting off the cost of manual review for lower-confidence orders and the ongoing cost of running the AI pipeline itself. Order volumes, handling times and labour costs are not disclosed here, so that calculation is described as a method rather than performed as a number.

What the case study shows clearly is the shape of a well-run generative AI delivery: a staged path from workshop to feasibility to MVP, targets set and beaten rather than asserted after the fact, a live model swap absorbed within a day when a better one became available, and a production system that routes by its own confidence rather than treating every output as equally trustworthy.