Plenty of businesses receive orders on paper. Not because nobody has offered them a web form, but because the people sending the orders have a working process, and a new portal asks them to change it for someone else’s benefit.
That is the situation at a US orthotic and prosthetic manufacturing lab we build the order-to-cash ERP for. Referring offices still submit paper work orders by hand, fax or email rather than digitally. The lab cannot reasonably require a distributed network of practices to adopt a new system, so the paper keeps arriving.
The question is what happens next.
The cost of re-keying
The default is a person reading each form and typing it into the order screen. On the face of it that is a data entry cost, and it is treated as the price of doing business.
The real costs are less visible. Transcription is where errors enter, and an error on an order for something made to one person’s measurements is not a tidy-up, it is a remake. Orders arrive in batches and get entered when somebody has time, so the system’s view of today’s work is always a little behind. And the knowledge of how to read an unusual form sits with whoever has done it longest.
None of that shows up as a line item, which is why it tends to persist.
What the pipeline does
On that ERP, scanned paper work orders are extracted directly into structured digital orders through an AI document pipeline. The Claude API turns a scanned work order into a structured order, and a separate integration resolves inconsistently written practice names on incoming orders to the correct physician record.
Those are two distinct problems and it is worth noticing that they were solved separately.
The first is extraction: given an image of a filled-in form, produce the fields. The second is resolution: given a name written three different ways across three offices, decide which record in the system it refers to. Treating them as one problem is how you get a pipeline that is confidently wrong about who sent the order.
Why a model rather than template OCR
Traditional OCR gives you characters and their positions. For a fixed form that never changes, that is enough: you know a value at a given position is the quantity.
Paper forms in practice are not that stable. They get revised, printed at different scales, filled in with handwriting that crosses the box, annotated in the margin, and faxed at a quality that loses detail. A position-based reader degrades badly under all of those.
Asking a model for a structured object instead changes the task from “read this region” to “what does this form say”. The useful output is JSON that maps onto your order fields, ready to populate the application that needed it, not a page of text somebody still has to interpret.
The trade-off is that a model will produce plausible output when it should produce no output, which is the next section.
Where a person still checks
Automating extraction does not mean automating acceptance, and the design question is which fields are safe to take unreviewed.
The useful split is by consequence rather than by confidence. A field that is easy to correct later and cheap to get wrong can be accepted and fixed if needed. A field that drives manufacturing, or that identifies who the order is for, deserves a human eye before it becomes a production instruction.
The honest-gap behaviour matters more than the accuracy rate. A pipeline that marks a field as unread, and puts the order in front of a person for that field, is one you can trust. A pipeline that fills every field because it was asked for every field is one where the failures are invisible until something is made wrong.
That is the same discipline as an exception queue in any document automation: the automation handles the clear cases, and the unclear ones are routed to someone rather than guessed at.
What makes the extraction usable afterwards
Getting a structured order out of a form is only useful if the order can actually be created. On that ERP every clinical field on the digital work order is driven by an admin-configurable option table rather than hardcoded, so the form can change without a code change.
That turns out to matter for the extraction too. When the set of valid values lives in a table, the pipeline has something to resolve against: an extracted value either matches a configured option or it does not, and “does not” is a clear signal to involve a person. If the valid values were hardcoded in the application, every change to the paper form would mean a release.
It is a general principle worth taking from this. The more your target structure is described as data, the easier it is to check extracted output against it.
Where to start
Start with the form rather than the model. How many variants are actually in circulation, which fields are mandatory, which drive production, and which can be corrected after the fact without cost. That answers both the scope and the review design.
Then decide what the pipeline should do when it is unsure, before you measure how often it is right. The behaviour on uncertainty is what determines whether people use the output or quietly go back to typing.
We build this as AI and OCR document automation feeding the system that holds the orders, as part of broader AI integration work. The lab’s full order-to-cash system is described in our orthotic and prosthetic manufacturing ERP case study. If paper is still arriving and being typed in, get in touch and tell us which field on the form you would least want a machine to guess at.
Common questions
Why use a language model rather than traditional OCR?
OCR reads characters; the harder job is deciding which field a value belongs to on a form whose layout varies. A model can return a structured object rather than a page of text, which is the part that saves the work.
What happens when the model is unsure?
It should return the order with the uncertain fields marked rather than its best guess presented as fact. An honest gap goes to a person; a confident wrong answer goes into the system.
Do the paper forms have to stop?
No, and that is the point. The people sending them keep working the way they already do, and the extraction happens on your side rather than being pushed onto them as a new portal to learn.