Ask for a demo of almost any document automation software and you'll see an invoice. Usually a clean one, with the vendor name top left, the total bottom right and a tidy table of line items in between.
That's fair. Invoices are the most common document in most back offices, and we've covered how invoice extraction works in detail. But at a freight forwarder, an insurance agency or a wholesale distributor, invoices are only part of the pile.
The rest of the pile looks like this:
- Purchase orders from customers, each one in that customer's own format
- Claims and FNOL forms that mix typed fields, handwriting and phone photos
- Bills of lading from dozens of carriers, no two laid out the same way
- Paper forms filled in by hand, by people in a hurry
These are also the documents that tend to stay manual. That isn't because they matter less. A lot of software was designed around the invoice, and these documents break its assumptions: fields in fixed positions, one document per file, printed text only.
What document automation has to do on every page
Good document automation doesn't care what a document is called. On any page, it has to do three things:
- Read it, whether it's a clean PDF, a fax copy or a photo taken on a loading dock
- Find the fields you asked for, even when every sender puts them somewhere else
- Flag the values it isn't sure about, so a person checks those instead of the whole document
The third point is where AI document processing earns its place. Software has been able to read printed text for decades. What decides whether your team reviews five fields or five hundred is whether the system knows when its reading might be wrong. That's what confidence scoring is for.
The rest of this post takes four document types one at a time. For each one we cover what makes it hard, which fields matter, and where to go for more detail.
Purchase orders
What makes them hard
A purchase order looks simple: one header, one table, one total. The problem is that the PO your team has to type is usually someone else's. A customer sends it from their own system, in their own layout, with their own part numbers.
- Every customer has a different layout. Twenty customers means twenty PO designs, and any of them can change when a customer switches systems. A template built for last year's layout stops matching and nobody notices until an order goes missing.
- The value is in the table. What matters is in the line items: SKU, description, quantity, unit, price. Long orders run across pages and descriptions wrap onto a second line. A missed row is an order line that never ships.
- Their codes aren't your codes. The customer writes their part number, and orders in cases where you stock single units. Extraction should return what's printed on the page. Mapping it to your SKU belongs in your ERP or a lookup table.
- Fax hasn't gone away. In a 2024 survey of 329 order-receipt staff at Japanese manufacturers, purchase orders were among the paper documents most often exchanged. 73.3% of respondents who still worked with paper received some of it by fax, and 60.4% of those typed the fax contents into their order system by hand.
The fields that matter
| Field | Why it matters |
|---|---|
| PO number | Every later match depends on it. One wrong digit and the invoice won't match. |
| Buyer and supplier | Who ordered, who ships, and which customer record the order belongs to |
| Order date and delivery date | Drives scheduling. Is 03/04 the 3rd of April or March 4th? It depends on who sent it. |
| Line items: SKU, description, quantity, unit, unit price | This is the order itself |
| Total order value | A built-in check, because the line totals should add up to it |
| Payment terms and shipping instructions | Often free text at the bottom of the page. Easy to miss, and expensive to ignore. |
How to automate purchase order processing without templates
Start with your top customers by volume. Add one example PO per customer using Mastery, and every later PO from that customer comes back in the same field format. Occasional customers can run on Instinct: you describe the fields once in plain language and it works across layouts.
Every field gets a confidence score, so a PO with a smudged quantity goes to review with that quantity flagged, instead of going straight into your system. Add one free check of your own: the sum of the line totals should equal the PO total. If it doesn't, something was misread.
Purchase order automation doesn't end at extraction. The order still has to be matched against delivery notes and invoices, and that happens in your ERP or procurement tool. Our job is to get clean rows there: JSON, CSV or Excel files, or through the API and webhooks.
More on the fields and setup: purchase order extraction.
Claims and FNOL forms
What makes them hard
A first notice of loss is the insurer's first record that something went wrong, and it rarely arrives as one tidy form. The same car accident can come in as an online submission, an emailed report, a broker's own intake sheet or a handwritten description with a phone photo attached. Every version describes the event differently.
- Three kinds of input on one page. Standard insurance forms such as ACORD forms mix typed fields, handwriting and rows of checkboxes, often all on page one. A tick in the wrong box changes the coverage type, and a stray pen mark can look like a tick.
- One notice, several records. One accident can involve two vehicles, three parties and an injury. If extraction returns that as a paragraph, someone still has to split it apart by hand before the right claims can be opened.
- The answer is in the story. Cause of loss often isn't a field at all. It sits somewhere in the incident description, written by someone who had a bad day.
- Blank fields are normal. Policyholders skip questions. The goal isn't to guess what's missing. It's to flag the gap on day one so someone can chase it, instead of discovering it on day ten.
Speed matters because claims are slow enough already. In J.D. Power's 2025 U.S. Property Claims Satisfaction Study, the average time from first notice of loss to final payment passed 44 days, the longest since the study began in 2008. Much of that is repairs and catastrophe volume, not paperwork. But a clean intake record is the one part your team controls from the first hour.
The fields that matter
| Field | Why it matters |
|---|---|
| Policy number | Links the claim to coverage. A typo here stalls everything downstream. |
| Claimant and insured | Often two different people, and both need to be right |
| Date, time and location of loss | Decides whether the loss falls inside the policy period and territory |
| Cause and type of loss | Drives triage and which adjuster gets the file |
| Incident description | The free-text account, kept whole for the adjuster |
| Vehicles, property, parties and injuries | One row each, so each can become its own record |
| Coverage type (checkboxes) | Small boxes with big consequences |
| Police or incident report number, supporting documents | What the adjuster will ask for next |
Claims form data extraction that triage can trust
Describe the fields once, in plain language, and the same workflow reads the online form, the broker's sheet and the handwritten one. Vehicles, parties and injuries come back as table rows, one structured record each. Every value is traceable back to the page it came from, which helps when a claim is reopened months later.
If any field falls below your threshold, such as a smudged loss date or a checkbox that could go either way, the notice goes to Review Hub with that field and its score shown. Notices where every field clears the threshold export straight away by API, webhook, JSON, CSV or Excel. To be clear about where our job ends: Foxello builds the clean first record. Triage and assignment stay with your claims system and your team.
For a BPO handling claims for several carriers, each client gets its own workflow with its own forms and fields. A storm surge then means a longer review queue for the notices with uncertain fields, not a hiring round.
More detail: FNOL processing, claims processing, and our longer post on automating claims documents, including loss runs.
Bills of lading
What makes them hard
A bill of lading carries the same core facts on almost every shipment: who sent it, who receives it, where it's going, and what's in the box. Then every carrier prints those facts in its own layout. A freight forwarder working with twenty carriers ends up with twenty versions of one document.
- Several document families. Ocean bills, domestic straight bills, sea waybills, air waybills and telex releases all count as "a BOL" in day-to-day work. They share some fields and not others.
- The container table doesn't behave. One carrier lists containers in a neat table. Another writes them into a paragraph of shipping instructions. A long manifest breaks across pages, and the second page has no column headers.
- Small misreads, big consequences. A container number is four letters, six digits and a check digit, so a misread O or 0 sends a query to the wrong box. Weights arrive as gross or net, in kilos or pounds, sometimes both on the same page.
- Paper isn't leaving soon. In the 2024 FIT Alliance survey on electronic bills of lading, only 29.4% of freight forwarders had adopted them. Among all respondents, 41.7% used electronic bills alongside paper ones rather than instead of them. Domestic trucking bills sit outside that push entirely.
The fields that matter
| Field | Why it matters |
|---|---|
| BOL number | The reference every carrier, broker and customs query uses |
| Shipper, consignee, notify party | They swap positions between carriers, and "same as consignee" is a valid answer |
| Port of loading and port of discharge | Routing, and which customs office cares |
| Vessel and voyage number | Ties the paperwork to a physical sailing |
| Container and seal numbers | One row per container. The check digit makes errors catchable. |
| Commodity description and HS codes | The basis for customs filings and for freight class on commodity bills |
| Gross weight, volume, package count | Billing disputes start here |
| Freight terms and special instructions | Prepaid or collect, hazmat, temperature control |
What is the best way to parse bills of lading?
Don't build a template per carrier. Describe the fields you need once, in plain language, and let the extraction find each one by what it means, wherever it sits on the page. Define the container table's columns once too: container number, seal, commodity, weight, packages. Every row then comes back in that structure, whether the source printed a table or a paragraph.
If two document families differ too much for one field list, such as ocean bills and air waybills, give each its own workflow. If a value falls below the threshold, like a smudged container number or a weight that could be 1,800 or 1,300, the bill goes to review with that value flagged. Bills where every field clears the threshold export to your TMS, customs platform or spreadsheet by API, webhook or file.
One cheap safeguard on your side: run the container number check digit before data enters your system. It's a standard calculation, and it catches the misreads that matter most.
More detail: bill of lading data extraction, our longer post on automating BOL data extraction, and the pages for freight forwarders and customs brokers.
Handwritten forms
What makes them hard
Handwriting is where most automation quietly gives up. Printed text has been a solved problem for years. A form filled in by a nurse at the end of a shift, a driver on a loading dock or a customer at a counter isn't.
Paper forms also stay paper for a reason. In the manufacturing survey from the purchase order section, 30.3% of respondents who wanted to stop using fax said they couldn't, partly because so many of their documents are handwritten.
- People don't stay inside the boxes. Dates get written sideways, extra notes get squeezed into the margin, and a "No" goes into a box that was meant to be ticked or left blank.
- Every team has its own shorthand. Abbreviations, symbols, and codes nobody printed on the form, such as "1" for current user and "3" for never. A person who knows the team reads them instantly. Software has to be told.
- Blank is an answer. An empty field and an unreadable field are different results, and they need different handling.
- The worst failure is a confident guess. That's the finding to take seriously.
A 2026 research benchmark tested 17 AI models on 49 real handwritten medical forms. The best reached about 85% accuracy across all fields, dropping to under 80% once empty fields were left out. Checkbox-heavy sections scored highest, often above 90%, while free-text fields scored lowest. Even the best models invented a value for 6-8% of fields, and the most-invented field was a checkbox, where models reported a tick that wasn't there.
The authors also note that when a model can't read a field, it doesn't say so. It leaves the field blank, picks the nearest plausible answer, or makes one up. The forms are medical and the sample is small, but the pattern holds for any messy form: the hard part isn't reading. It's knowing which readings to doubt.
The fields that matter
| Field type | What to watch for |
|---|---|
| Names and ID numbers | Similar-looking characters (1 and 7, 0 and O, 5 and S) |
| Dates | Day-month order, two-digit years, dates written outside the box |
| Checkboxes and selections | Ticks, crosses, circles and stray marks that look like ticks |
| Numbers with units | Decimal comma or decimal point, and units written three different ways |
| Free-text answers | Lowest accuracy, highest value. These need a person most often. |
| Empty fields | Should come back as empty, not filled with a guess |
How to get handwritten forms through reliably
Describe each field in plain language, including any codes your team writes on the form. For example: "1 means current user, 3 means never", or "dates are written day first". For poor scans and heavy handwriting, use Deep mode, which costs two tokens per page instead of one.
Then lean on the confidence scores. If any field scores below your threshold, such as a smudged date or an ambiguous checkbox, the form goes to Review Hub. The reviewer sees the uncertain fields and their scores next to the document, and checks those. Forms where every field clears the threshold go straight through. On handwritten forms, expect free text to be what sends them to review most often.
If you design the form yourself, the cheapest accuracy gain happens before anyone picks up a pen:
- Print the date format next to the field (DD/MM/YYYY)
- Give each answer a box with enough room for it
- Make checkboxes large, and label every one
- Ask for photos taken flat, in good light, with all four corners in the frame
More detail: forms processing.
What all four have in common
Put the four side by side and a pattern shows up. Every one of them needs the same three jobs from the introduction: read the page, find the fields, flag the doubtful ones. What changes is which job is the hard one.
| Document | The hard part | Start with these fields | More detail |
|---|---|---|---|
| Purchase orders | The line-item table, and the customer's codes instead of yours | PO number, buyer, dates, line items, total | Purchase orders |
| Claims and FNOL forms | Mixed input on one page, and one notice that holds several records | Policy number, claimant, date and cause of loss, parties involved | FNOL processing |
| Bills of lading | A different layout from every carrier, and container tables that wander | BOL number, parties, ports, containers, weights | Bills of lading |
| Handwritten forms | The reading itself, and knowing when a reading is wrong | Names, dates, checkboxes, then free text | Forms processing |
That's also why one solution can handle all four. If a system needs a template per layout, every new document type is a new project. If it reads for meaning and scores its own confidence, a new document type is a new workflow with a new field list.
Where to start
Don't try to automate all four at once. Start with one document type and give it two weeks.
- Pick the document that costs the most typing. Multiply monthly volume by minutes per document. The answer is rarely the one people complain about loudest.
- Collect 20 real examples, including the ugly ones. Every pilot works on clean samples. Production is the faxed copy and the phone photo.
- List 5 to 8 fields, not 40. Start with the fields your next step actually needs: matching, triage, booking, billing. You can add more later.
- Run them and look at the review rate. If most documents need review, check the field descriptions and the scan quality before blaming volume. We explain how to read those numbers in our post on confidence scoring.
- Add the next document type as its own workflow. Separate field lists keep each type clean, and they're how a BPO keeps clients apart too.
When document processing software isn't worth it
Being straight about this saves everyone time.
- One format, one sender, high volume, never changes. A simple template tool will be cheaper, and it will work fine until that sender redesigns the form.
- A handful of documents a month. Typing them is fine. Automation pays off when volume outgrows the person doing the typing, not before.
- The output has to be an approved, posted transaction. Extraction gets clean data out of the document. Approvals, payments and posting to your ERP are separate tools, and extraction feeds them.
FAQ
What is document automation software?
Software that reads documents such as PDFs, scans and phone photos and turns them into structured data your other systems can use. Good document automation also scores how sure it is about each value, so people only check the uncertain ones.
Can document automation handle documents other than invoices?
Yes. Purchase orders, claims and FNOL forms, bills of lading and handwritten forms are covered above. The same approach works for receipts, bank statements, tax forms, IDs and most other documents with text on them. Each document type gets its own workflow and field list.
How do you automate purchase order processing?
List the fields you need, including the line-item table, and run your POs through one workflow. For your biggest customers, add one example PO each, so their orders always come back in the same format. A PO with any uncertain value goes to review, with that value flagged. Clean data then goes to your ERP or procurement system, where the matching against invoices and receipts happens.
What data can you extract from a claims form?
Typically the policy number, claimant and insured, date, time and location of loss, cause of loss, the incident description, the vehicles, property and people involved, coverage checkboxes, and references such as a police report number. Vehicles and parties come back as separate rows, so each can become its own record.
Can AI read handwritten forms?
Yes, with limits worth knowing. Checkboxes and short, neat entries read well. Long free-text answers and rushed handwriting are the hardest part, and research benchmarks show even strong models sometimes guess instead of admitting doubt. That's why every field should carry a confidence score, and any document with an uncertain field should go to a person.
Do I need a template for each document type?
No. You describe the fields once, in plain language, and the same workflow handles different layouts from different senders. You only need a separate workflow when two document types need different field lists, such as ocean bills of lading and air waybills.
How much does document automation software cost?
Pricing models vary: per page, per credit, flat monthly, or a quote after a sales call. Foxello publishes its prices in euros. Plans start at €12.49 a month billed annually, or €14.99 billed monthly, and one token processes one page. Harder documents in Deep mode use two tokens per page. Every account starts with a 30-day trial that includes 100 pages, with no card required. See pricing.
Is my data used to train AI models?
No. Documents are processed and stored in the EU, encrypted in transit and at rest, and never used to train models.
Try it on your ugliest document
Pick the purchase order, claim form, bill of lading or handwritten form your team dreads most. Describe the fields, run it through, and see which values come back flagged. It takes a few minutes and costs nothing.