Somewhere in your company there's a person whose job never made it into the job description. They open the PDF, read the invoice number, and type it into the system. Then the date. Then the total. Then they do the same with the next one.
If that's you, or the person you manage, this guide is for you. It isn't for developers.
So what is document processing?
Document processing is how information gets from a document into a system you can use. A supplier sends an invoice. A driver hands over a bill of lading. A customer fills in a claim form by hand. Someone or something has to read it, pull out the details that matter, check them, and put them in your accounting tool, ERP, or spreadsheet.
That's all it is. The real question is who does the typing.
Most teams already do document processing. They just call it data entry.
When people do it, the work looks like this: open the file, read the field, type it in, check it, repeat. When software does it, the steps stay the same. The difference is that a person reviews the result instead of producing it.
That difference costs money. Ardent Partners' State of ePayables 2025 puts the average cost of processing one supplier invoice at $9.84. The top 20% of AP teams pay $2.65 for the same invoice, while everyone else averages $12.42.
| Cost to process one supplier invoice | |
|---|---|
| Best-in-class AP teams | $2.65 |
| Average across all teams | $9.84 |
| Everyone else | $12.42 |
Source: Ardent Partners, State of ePayables 2025
The gap isn't about people typing faster. The teams at the low end let software do the reading and keep their people for the parts that need judgment.
Typing is where errors start
Even careful people make typos. The figure most often cited for manual entry is about 1% of fields, and it's a rule of thumb rather than a hard benchmark. Real rates climb with fatigue and messy source files. Even 1% adds up: with ten fields per invoice, roughly 1 in 10 invoices ends up with a mistake somewhere.
Nobody is being sloppy. People just aren't built to copy numbers off a screen all day.
In the rest of this guide we'll go through what document processing covers step by step, explain the terms vendors use, and show what changes for your team when the typing stops.
The four stages: capture, extraction, review, export
However the work gets done, by hand or by software, every document goes through the same four steps. Learn these and most vendor pitches get easier to follow, because they're just describing one or more of these stages.
1. Capture: getting the document in the door
Capture is everything that happens before anyone reads the document. The invoice lands in a shared inbox. A scan shows up in a folder. Someone takes a photo of a delivery note on their phone.
This step looks trivial, and it's where a lot of the mess starts. Ardent Partners' State of ePayables 2025 found that only about 51% of invoices reach AP teams electronically. Everything else arrives on paper, gets scanned, or comes in some other awkward way.
At this stage, the person doing it by hand has to:
- Check the inbox and download the attachments
- Rename files so they can find them later
- Work out what each document is (an invoice, a credit note, a statement?)
- Move it to the right folder or hand it to the right person
When software handles capture, you skip all of that sorting. Documents come in from wherever they already land, such as a dedicated email address, a Google Drive folder, an FTP server, or an API call from your own system. You stop forwarding PDFs to yourself.
2. Extraction: reading the document and pulling out the details
Extraction is the part people picture when they hear "document processing." The software reads the page and pulls out the specific details you care about, such as vendor name, invoice number, due date, total, and line items.
It helps to split this into two jobs:
- Reading the text. This is OCR (optical character recognition): turning an image of a page into text a computer can work with. It's been around for decades.
- Understanding what the text means. Knowing that "€4,120.00" is the total and not the tax, or that the date in the top right is the invoice date and not the delivery date.
The first job has been solved for years. The second is where older tools struggled. They depended on templates, meaning someone had to draw boxes on a sample document and tell the system "the total is always here." That works fine until a supplier changes their layout, and then someone has to rebuild the template.
Newer tools, Foxello included, skip the templates. You describe each field in plain language, like "the total amount due, including tax," and the software finds it however the document is laid out. That matters most for ops teams that deal with hundreds of suppliers, each with their own invoice design.
3. Review: a person checks what the software isn't sure about
This is the stage most guides skip over, and it decides whether automation actually saves time.
Extraction is never perfect, and any vendor promising 100% is stretching the truth. The useful question is how the software handles the fields it isn't sure about. A good system gives every field a confidence score, a number showing how sure it is that it got the value right.
- High confidence: the field is confirmed automatically and nobody touches it.
- Low confidence: the field goes to a review queue, where a person compares it to the original document and fixes it if needed.
Exceptions are a known pain point. In Ardent's 2025 research, 48% of AP professionals named a high percentage of exceptions as a top challenge. Review that only surfaces the uncertain fields is how you keep that queue small.
Reviewing an invoice and typing an invoice are very different jobs. Checking one flagged field against the page takes a few seconds. Typing twenty fields from scratch takes minutes and leaves twenty chances to make a typo.
4. Export: getting the data where it needs to go
Extracted data is only useful once it reaches the system you actually work in. Export is that final step.
| Export route | What it looks like | Good for |
|---|---|---|
| File download | Excel, CSV, or JSON from the dashboard | Small teams, spreadsheets, one-off batches |
| Cloud folder | Results land in a shared Google Drive folder | Teams that live in shared drives |
| Webhook / API | Data is sent straight to your own system | Higher volumes, in-house tools, BPOs |
When people do this by hand, export is often the second round of typing: copying from a spreadsheet into the accounting system, field by field. When software does it, the data arrives already structured, so nobody has to type it in again.
The short version
Doing it by hand, one person handles all four stages for every document. With software, people only step in at review, and only for the fields the software flags. That's the whole change, and the next section covers the vocabulary that comes with it.
Glossary: the terms vendors throw at you
Spend ten minutes on a document automation website and you'll run into a pile of acronyms. Most of them describe simple ideas. Here they are in plain English, grouped by the stage they belong to, with a question for each that's worth asking on a sales call.
Reading the page
OCR (Optical Character Recognition) Turns a picture of a page into text a computer can read. It transcribes the page but doesn't understand it. OCR can tell you a page contains "4,120.00." It can't tell you whether that's the total or the tax. Ask: "What do I get back besides text?"
ICR (Intelligent Character Recognition) OCR for handwriting. Classic ICR works best on neat block capitals written in separate boxes, like on a customs form, and struggles with normal handwriting. Ask: "Can I test it on our worst handwritten forms, not your sample ones?"
IDP (Intelligent Document Processing) The umbrella term for software that does the whole job: it reads the document, works out what kind of document it is, pulls out the fields you need, and hands them over in a structured format. OCR is one piece of IDP. If a vendor calls itself IDP, it should be covering all four stages from the previous section. We wrote a separate guide to IDP if you want to go deeper.
Types of documents
Vendors sort documents into three groups by how predictable their layout is, and it helps to know which group your paperwork falls into.
| Type | What it means | Examples |
|---|---|---|
| Structured | Same layout every time | Tax forms, passports, time sheets, application forms |
| Semi-structured | Same information, different layout per sender | Invoices, receipts, purchase orders, bank statements, bills of lading |
| Unstructured | Free-flowing text, no fixed layout | Contracts, leases, letters, reports |
Most back-office work sits in the middle row. Every supplier puts the same information in a different place on the page, and that's exactly where template-based tools tend to fail.
Getting the fields out
Field One piece of information you want out of the document, like invoice number, due date, or policy number. Your list of fields is effectively your spec. Write it down before you look at any software.
Line items (table extraction) The rows in the middle of an invoice or PO, with product, quantity, unit price, and amount. They're harder to extract than single fields because the number of rows changes from one document to the next. If your team keys line items today, test this specifically.
Template A map that tells software where each field sits on a particular layout. You need one per layout, so a new supplier means a new template, and so does a supplier who redesigns their invoice. Ask: "What happens when a supplier changes their layout?" If the answer involves anyone drawing boxes, you'll be paying for that work forever.
Template-free extraction Instead of drawing boxes, you describe each field ("the total amount due, including tax") and the software finds it wherever it is on the page. This is how Foxello works, and it's the main reason setup takes minutes instead of weeks.
Classification Working out what a document is before extracting anything: invoice, credit note, or remittance advice. It matters when one inbox receives a mix of document types.
Checking the results
Confidence score A number attached to each extracted field that shows how sure the software is that it got the value right. It's what makes selective review possible. Ask: "Do I get a confidence score per field or one for the whole document?" Per field is much more useful, because it shows the reviewer exactly where to look.
Human-in-the-loop Vendor jargon for "a person reviews the uncertain bits." Every serious system has it. The real questions are how much of the work ends up with the human, and how fast the review screen lets them get through it.
Exception A document the software can't finish on its own, because of a missing field, a value that fails a check, or an unreadable scan. Your exception rate is the number to watch after go-live.
Validation rule An automatic check on the extracted data. Do the line items add up to the total? Is the due date after the invoice date? Rules like these catch mistakes that a confident extraction can still make.
The goal
Straight-through processing (STP), also called touchless processing A document that goes from capture to export without anyone touching it. Vendors love quoting STP rates. Treat any number you see as a result on their test documents until you've seen it on yours.
The plumbing
API A way for two systems to send data to each other directly. Your IT team or integration partner cares about this. You mostly need to know that one exists.
Webhook An automatic notification. When a document is finished, the system "calls" another app and sends the data along, so nobody has to check a dashboard or download a file.
RPA (Robotic Process Automation) Software bots that copy what a person does on screen, such as clicking, copying, and pasting between apps. RPA gets confused with IDP all the time. The difference: RPA moves data around, while IDP reads documents. A bot can paste a total into your ERP, but it needs something else to read the total off the invoice first. Plenty of teams use both.
One more test for any vendor
If a sales rep can't explain their product without using five of these terms in one sentence, ask them to walk through a single invoice from inbox to ERP. Good tools are easy to explain.
What changes when software does the typing
The four stages stay the same. Documents still come in, someone or something still reads them, the data still gets checked and sent on. What changes is who does each part and what your team's day looks like.
The same job, split differently
| Stage | When people do the typing | When software does the typing |
|---|---|---|
| Capture | Someone checks the inbox, downloads, renames, and files | Documents arrive automatically from email, folders, or apps |
| Extraction | Someone reads each document and types every field | Software reads every document and fills in every field |
| Review | Self-checking, or a second person re-checks a sample | A person checks only the fields the software flagged |
| Export | Someone copies from a spreadsheet into the system, again | Structured data goes straight to the file, folder, or app |
| The team's main job | Typing | Checking and fixing |
That last row matters most. Your team goes from producing data to checking it, and those two jobs feel very different to do.
Your people stop being typists
Typing is the part of the job nobody misses. In a July 2025 survey of 500 US office workers commissioned by Parseur, respondents spent more than 9 hours a week moving data from emails, PDFs, and scans into other systems. 56% said repetitive work like this left them burned out.
Parseur sells document automation, so read those numbers with that in mind. Still, anyone who's spent a month-end keying invoices will recognise the picture.
When software does the typing, the same people spend their time on what needs a human:
- Fixing the few fields the software was unsure about
- Chasing the supplier whose invoice doesn't match the PO
- Catching the duplicate invoice before it gets paid twice
- Finding out why one vendor's totals keep failing the checks
Your team still has to think about the documents. They just don't have to copy them out first.
Speed changes in two places
The first is obvious: reading a page. Foxello averages about 24 seconds per page in our internal testing, and it doesn't slow down at 4pm on a Friday.
The second matters more: how long documents sit waiting. A pile of invoices waiting for someone to free up isn't a typing problem, it's a queue. In Ardent Partners' State of ePayables 2025, best-in-class teams process an invoice in 2.9 days, while everyone else takes 13.5 days.
Faster typing isn't what closes that gap. Best-in-class teams have taken the waiting out of the process. Once data entry stops being the bottleneck, invoices get to approvers sooner, early-payment discounts stop expiring, and month-end stops being a scramble.
Volume stops tracking headcount
This is the change BPO and shared-services leaders care about most. When people do the typing, more documents means more people, more or less one for one. Volume doubles, and you hire, train, and manage twice the staff.
When software does the typing, reviewers only handle the uncertain fields, so the same team can get through much more paperwork. It's the line we use with BPO teams: same reviewers, several times the volume. How many times depends on your documents. Clean digital PDFs get flagged much less often than faded scans of handwritten forms, so test on your own files before you promise a client a number.
Run the math on your own numbers
Skip the vendor ROI calculator. You only need three numbers from your own team:
- Documents per month (for example, invoices received)
- Minutes per document to type it in today. Time a few real ones, and include the opening, renaming, and checking.
- What an hour of that person's time costs you, fully loaded
Multiply the three, divide by 60, and that's your monthly cost of typing. Then ask a straight question: if that time went into review and exceptions instead, what would your team do with it?
For most ops teams the honest answer is "work we've been putting off for a year," which says a lot about where that time goes now.
What doesn't change
Software doesn't decide whether an invoice should be paid, whether a claim is valid, or what to do about a supplier who keeps getting it wrong. That's still your team's call, and the next section covers where people still matter and which vendor promises to be skeptical of.
What doesn't change: where people still matter
Software can read faster than your team and it never gets tired. It still doesn't know your business. A lot of the job stays exactly where it is, and it's better to hear that now than three months after go-live.
Software reads. People decide.
| Software handles | Your team still owns |
|---|---|
| Reading every document | Deciding whether an invoice should be paid |
| Filling in every field | Approving spend and signing off exceptions |
| Flagging uncertain fields | Fixing them, and spotting patterns in what gets flagged |
| Running checks you've defined (totals, dates, required fields) | Deciding which checks matter in the first place |
| Sending data to your systems | Owning what happens to it once it's there |
Notice what the right-hand column has in common: judgment, context, and accountability. Software doesn't remove any of that. It removes the typing that used to bury it.
Software reads what's on the page, including the lies
Extraction is faithful. If a fraudster sends an invoice with new bank details, good software will read those bank details perfectly and pass them along.
That risk is real. In the AFP's 2025 Payments Fraud and Control Survey, 79% of organisations reported attempted or actual payments fraud in 2024. Business email compromise was the most common route, cited by 63%, and vendor impersonation jumped to 45%, up 11 points from the year before.
Reading a document and trusting it are two separate steps. Keep the controls you already have, like a callback to a known number before any bank detail change and a second approver on new vendors. Automation can make those checks easier, for example by flagging when an IBAN doesn't match last month's, but your process has to say what happens next.
Bad scans are still bad scans
Modern extraction copes well with crooked photos, coffee stains, and messy handwriting. It still can't read a smudge that a person couldn't read either.
If one branch keeps sending faxes of photocopies of carbon copies, fix that at the source. Your exception queue will tell you where the bad inputs come from. Treat it as a map of where to go have a conversation.
Treat accuracy numbers with suspicion
Every vendor has a big accuracy number on their homepage. Before you trust one, ask three questions:
- Accuracy of what? A single field, or a whole document? They're very different. Remember the math from earlier: at 99% accuracy per field, a ten-field invoice comes through fully correct only about 90% of the time. Both claims are honest, and they describe very different amounts of work for your team.
- Measured on whose documents? Clean digital PDFs from big suppliers are easy. Faded scans from small suppliers are not. The vendor's demo set is almost always the first kind.
- What happens to the misses? This matters more than the accuracy number itself. A system that's 95% accurate and flags its uncertain fields is safer than one that's 98% accurate and silently gets the rest wrong.
The only accuracy number that counts is the one you measure on your own worst 50 documents. That's why Foxello gives every field its own confidence score and sends anything uncertain or missing to review instead of guessing quietly. We'd rather show you exactly where to look than promise you'll never need to.
A broken process just breaks faster
If invoices currently wait two weeks for one manager's approval, automating data entry won't change that. The invoice gets to the manager's desk faster and then waits the same two weeks.
Before you automate, sketch out your current process on one page. Circle every point where a document waits on someone. Software removes typing, but it can't remove waiting it has no control over.
Someone still has to own it
Automation isn't something you set up once and forget. Someone on your team needs to own it, usually the same person who owned the paperwork before. Their job changes to:
- Keeping the field list current when the business changes ("we now need the cost centre too")
- Watching the exception rate and asking why it's moving
- Deciding where the review bar sits. Is a slightly uncertain date okay to send through, or should it always go to review?
- Being the first person who notices when a supplier changes their invoice layout, and confirming nothing broke
That's a better job than typing. It's still a job, though, and teams that skip naming an owner tend to drift back to doing things by hand.
The bottom line
Software takes over the reading and the copying. Your team keeps the thinking, the checking, and the decisions about money. Set it up that way and both do the work they're best at.
How to start without turning it into a project
You don't need an IT project, a steering committee, or a six-month rollout to try this. You need one document type, a stack of real files, and an afternoon. Here's how to test it properly without kicking off a formal project.
Step 1: Pick one document type, the one everyone complains about
Don't start with "all our paperwork." Start with the single document type that eats the most hours, usually supplier invoices, purchase orders, or a form your team keys in every day.
A good first candidate has:
- High volume - enough of them that the time savings show up quickly
- Repetitive fields - the same 8-15 details every time
- Variety in layout - lots of different senders. This is where template-free extraction proves itself.
Leave the weird one-offs for later.
Step 2: Collect 30-50 real documents, including the ugly ones
Go through last month's pile and pull 30 to 50 documents. Don't pick only the clean ones. Mix in:
- A few crooked phone photos
- Your worst scan
- Something with handwriting on it
- The supplier whose invoice layout everyone hates
- A multi-page document with a long line-item table
If a tool only works on your best documents, it doesn't really work. The ugly ones show you what your review queue will actually look like.
Step 3: Write down your current numbers before you change anything
This takes 30 minutes and keeps the whole test honest. Time a few documents end to end, and write down:
| Baseline metric | How to measure it |
|---|---|
| Minutes per document | Time 5-10 real ones, including opening, typing, and checking |
| Documents per month | Count from your system or inbox |
| Errors found later | Ask the team how often a corrected entry turns up at month-end |
| Wait time | How many days from "document arrives" to "data is in the system" |
Without these numbers you'll end up arguing over gut feelings. With them, you can see clearly whether the test worked.
Step 4: Write your field list in plain English
List every field your team keys in today, and describe each one the way you'd explain it to a new hire:
- "Invoice number - the supplier's reference, usually near the top"
- "Total due - the final amount including VAT, not the subtotal"
- "Due date - if missing, leave blank, don't guess"
That list is your whole setup. In Foxello, you create a workflow, paste in those descriptions, and you're done. Creating a workflow takes about a minute. For common documents like invoices, you can skip the list and pick a ready-made Instant model instead. If you want every document to come out in exactly the same format, Mastery lets you add one example to follow.
Step 5: Run the documents and check every field
For the test, review everything, not only the flagged fields. You want to see three things:
- What it got right without help - most of it, hopefully
- What it flagged - is it uncertain about the right things?
- What it got wrong without flagging it - the number that matters most. Write these down.
If one field keeps causing trouble, improve its description and run the batch again. Most problems in a first test come down to a vague field description, not the software failing to read the page.
Step 6: Set your review rules
Now decide how much checking you want once the test is over. Most teams start strict and loosen up:
- Week 1-2: Review every document. Build trust.
- Week 3-4: Review only flagged fields. Spot-check a sample of the rest.
- After that: Fully confident documents go straight through. Uncertain ones go to the queue.
Strict review isn't failure. It's how your team learns where the software is reliable on your documents.
Step 7: Connect the plumbing last
Only once the extraction is working, connect it to the rest of your stack. Point your supplier inbox at a dedicated import email, or have it watch a Google Drive folder or an FTP server. Send the results as Excel, CSV, or JSON, or through the API or a webhook into your accounting tool.
Plumbing is easy to change later. Data that's extracted wrong isn't. Get the extraction right first.
What a realistic first month looks like
| When | What happens |
|---|---|
| Days 1-3 | Write down your baseline numbers, run the test batch |
| Days 4-5 | Improve field descriptions, run the batch again |
| Weeks 2-3 | Live on one document type, reviewing everything |
| Week 4 | Review flagged fields only, spot-check the rest |
| End of month | Compare against your baseline numbers |
At the end of the month, compare against the numbers from Step 3. If minutes per document, wait time, and errors found later have all dropped, add your second document type. If they haven't, you've lost an afternoon and a few test pages, not a budget.
It costs nothing to find out
That's how we built Foxello's free start. You get 100 pages free with no card required, which covers a full test batch with room left over to re-run it after tuning your fields. Your documents are processed and stored in the EU and never used for AI training, so you can test on real paperwork instead of cleaned-up samples.
FAQ
Is document processing the same as data entry?
Data entry is one way of doing document processing: the manual way. Document processing covers the whole journey of getting information off a document and into a system, including capture, extraction, review, and export. When software takes over the extraction, data entry mostly disappears, and what's left for your team is checking.
What is automated data processing?
It's a broad term for any data work a computer does instead of a person: sorting, calculating, moving records between systems. Automated document processing is the slice of it that starts with a document. It gets the data off the page so everything else downstream can be automated too. If your "automated" process still starts with someone typing from a PDF, it isn't fully automated yet.
Do I need a developer or IT team to set it up?
Not to get started. With template-free tools you describe the fields in plain language, upload documents, and download the results as Excel or CSV. You only need technical help when you want data flowing straight into another system through an API or webhook.
What kinds of documents can it handle?
If it has text on it, modern tools can usually read it: invoices, purchase orders, bills of lading, receipts, claims forms, tax forms, IDs, and handwritten forms. Clean digital PDFs give the best results. Phone photos, faded scans, and messy handwriting still work, but expect more fields to be flagged for review.
Will my team lose their jobs?
The typing goes away. The judgment doesn't. Someone still has to review flagged fields, chase suppliers, approve payments, and own the process. In practice, the person who did the data entry usually becomes the person who runs the automation, and growing volume stops automatically meaning hiring more people.
How do I know if it's working?
Track four numbers from before and after: minutes per document, wait time from arrival to "data in system," errors found later, and how many documents end up in the review queue. If the first three fall and the fourth is steady or shrinking, it's working. If not, the problem is usually unclear field descriptions or bad input scans, and both can be fixed.
What does it cost?
Pricing models vary: per page, per document, or per seat. Foxello charges per page through monthly plans priced in euros, starting at €14.99 a month. One token processes one page, and harder documents in Deep mode use two. You can try it on 100 pages free with no card.
The short version
Document processing isn't a new technology you have to adopt. Your team is already doing it, one keystroke at a time. The real question is who does the typing.
When software takes over the reading, the four stages stay the same, but your team's day changes. Capture happens on its own, extraction takes seconds, review is limited to the fields that need a human, and export doesn't need any retyping. What's left for your team is judgment: checking, chasing, deciding.
You don't have to take anyone's word for it, including ours. Pick your most annoying document type, pull 30 real examples, write down your current numbers, and test.
Stop paying people to type. Start paying them to think. Start free - no card
Sources
- Ardent Partners, The State of ePayables 2025 - cost per invoice, processing time, electronic invoice share, exceptions as a top challenge
- AFP, 2025 Payments Fraud and Control Survey
- Parseur, Manual Data Entry Report (vendor-commissioned survey, July 2025)
- Hyperscience, Acronyms Explained: IDP vs OCR vs ICR
- UiPath, Document Understanding - Document Types
- Quality Magazine, Manual Data Entry and Its Effects on Quality - on the commonly cited ~1% error rate
Foxello figures (~24s per page, ~1 min to create a workflow) are from internal testing. The 1% manual error rate is a widely used rule of thumb, not a measured benchmark.