AI Document Processing

Most document automation projects succeed or fail on small decisions made long before anyone picks a model: which document type goes first, which fields are mandatory, which rule stops an entry and who looks at the review screen. This guide walks through those decisions in the order a business owner faces them when planning AI document processing.

It is a working checklist, not a brochure: criteria to put to any vendor, preparation you can do with your own files, and the cases where automation is not worth it. Technical terms are explained the first time they appear.

01Measure fit with a document inventory

Whether automation suits you becomes clear only when you count the documents that actually arrived over the last three months; gut feeling tends to produce needless or half finished projects. Go through shared folders, inboxes and scanner output for a week and fill in a simple sheet.

• Type and source: Supplier invoice, expense receipt, delivery note, contract or application form, and which channel and sender each one comes from.
• Monthly volume and timing: Whether documents arrive evenly through the month or pile up in closing week.
• Layout variety: How many different suppliers or templates exist for the same type; one large supplier or hundreds of small senders.
• Manual time: How many minutes it takes on average to open, check and key in one document.
• Cost of an error: When a wrong amount gets noticed, by whom, and what fixing it takes.

The sheet argues against automation in three cases: volume is low, most documents already arrive as structured electronic invoices, or each document type shows up only a few times a year. Then the import feature of your accounting software plus a tidy folder structure gives the same relief for less effort. If one document type with shifting layouts holds up every close, you have found your first workflow.

02The first workflow by type of company

Start with the document type that eats the most staff time and whose mistakes cost the most; automating everything at once makes measurement impossible. Typical candidates:

• Wholesaler or distributor: Purchase invoices and delivery notes from many suppliers; the first goal is matching them to purchase order lines.
• Logistics or freight company: Proof of delivery forms, photos of signed delivery notes and customs paperwork; the first goal is linking each document to the right shipment and customer.
• Accounting or bookkeeping firm: Receipts, bills and bank statements that clients send in a jumble; the first goal is sorting them by client and period.
• Insurance broker or claims handler: Adjuster reports, registration papers and repair invoices attached to a claim; the first goal is a list of what is still missing.
• Project or services business: Customer and vendor contracts; the first goal is a register of parties, term, renewal and notice dates.

An accounting firm that collects paperwork from clients should get documents arriving through one channel before adding AI document processing; a secure upload area on a website for accounting firms is a sensible place to start. The first type you choose becomes the template: the same review screen, audit trail and measurement sheet are reused for the second.

03Plain language architecture in seven layers

A robust document workflow consists of separate layers that can each be tested on their own. Ask any vendor to walk you through them; "the AI reads it and posts it" describes a system where errors cannot be traced.

• Intake: An inbox, shared folder, scanner or upload form is watched; each file gets a unique ID and its original is copied to storage nobody can edit.
• Preprocessing: Multipage scans are split into documents, skewed images straightened and blank pages removed.
• Classification: The document type is identified, because invoices, delivery notes and contracts follow different field schemas.
• Extraction: OCR (optical character recognition, turning the letters in an image into text) and the model on top name the fields and give each a confidence score.
• Validation: Rules run on totals, formats, duplicates and order matching.
• Review: A document that fails a rule or scores below threshold lands on a person's screen.
• Posting: The approved entry is written to the target system and stored with a link to its source file.

The payoff is replaceability: when the reading service changes, only extraction is measured again.

04Do not read structured invoices as images

Sending structured documents through an AI model adds cost and risk for no gain. Formats such as Peppol UBL, XRechnung, ZUGFeRD and other invoices following the European standard EN 16931 already carry amounts, tax and line items as separate fields that your accounting software can import directly.

Confusion starts when a supplier emails a PDF rendering while the structured file sits elsewhere. Germany's Federal Ministry of Finance, for instance, states that domestic businesses must be able to receive electronic invoices since 1 January 2025 and that a plain PDF does not count as one. A workflow should handle every incoming PDF in this order:

• Look for the structured file first: If the same invoice number exists as XML in your electronic invoicing inbox, the PDF is treated as a visual copy and not read.
• Then link the two: When PDF and XML belong to the same invoice, the entry is built from the XML and the PDF is attached to the archive.
• Only then send it to the model: Paper, scans, photos and plain PDFs with no structured counterpart go to the reading layer.

This split does two things at once. The model reads fewer documents, so usage fees drop, and the same invoice can no longer be posted twice, once from XML and once from PDF.

05Field schema and cross check rules

A field schema is the written list of what gets extracted from each document type and in which format; it is the contract of the workflow. Without one, output drifts and the target system quietly accepts it. For every field, write down the name, data type, whether it is mandatory and its standard format: dates in one format, one decimal separator, currency as the three letter international code.

Next, list the cross check rules for each type. A typical starting set for invoices:

• Arithmetic: Line amounts add up to the net total, net total times rate gives the tax, and both together give the gross total.
• Tax ID format: A US employer identification number has nine digits, while EU VAT numbers carry a country prefix and can be checked against the European Commission's VIES service; an ID that fails is not considered read.
• Date logic: An invoice date cannot lie in the future, and a due date cannot precede the invoice date.
• Duplicates: If the same sender, invoice number and amount were already posted, the document stops.
• Three way match: Quantity and price are compared with the purchase order and delivery note; any gap beyond your tolerance goes to review.

To catch the same file uploaded twice under another name, compare content hashes, fixed length fingerprints computed from each file; try it with our hash generator.

06Intake channels and target system connections

Entry and exit points matter as much as the reading layer; if the target system cannot accept entries, even an accurate model is of little use. On the intake side, write down for each channel who may send documents, which file types are accepted and the size limit.

On the output side, the first question is how the target system takes in records. Accounting packages, ERP and CRM software are usually fed in one of three ways:

• Documented API: The entry is created at once, and errors flow back into the queue.
• Import file: Approved entries are exported as a file at set intervals; slower, but often the safest route with older accounting software.
• Staging table: The workflow writes to its own database and the target system reads it; a last resort for closed legacy systems.

Whichever route you choose, two rules hold. First, resending an entry must never create a second one; a retry after a network outage should not produce a duplicate bill. Second, the workflow may suggest a general ledger account but should not finalize it in the first months; the suggestion appears on the review screen and the accountant decides. If the target system has no connection point, a small middleware service is planned separately as custom software development.

07Choosing and hosting the reading model

There are three main options for the reading layer, and your own test set should decide between them, not a vendor's landing page. Prebuilt document services offer a fast start on common types such as invoices and receipts; general purpose models that read image and text together cope better with changing layouts and free text; open models running on your own server keep data in house.

Compare them on the same test set using these criteria:

• Character accuracy: Whether accented names, umlauts and special characters in supplier names and addresses come out right.
• Tables across pages: Whether a line item table split by a page break is merged back into one table.
• Meaningful confidence: Whether high scoring fields really contain fewer errors; if score and error rate are unrelated, a threshold is pointless.
• Version pinning: Whether you can lock a specific model version and how much notice you get before it is retired.
• Data terms: Whether submitted documents are used for training, how long they are kept and in which region they are processed.

For companies handling medical reports or identity documents, a local LLM setup is a serious option, though hardware, updates and security become your responsibility. Many businesses settle on a hybrid: sensitive types local, everything else on a reviewed cloud service.

08Review screen, thresholds and audit trail

The review screen is where people spend most of their time in AI document processing, and a poorly designed one gives back the hours that automation saved. A good screen shows the document image and the extracted fields side by side, highlights the region where each value was read and colors only the doubtful fields. The reviewer checks the flagged fields, not the whole page.

Set thresholds per field rather than as one number. A small misreading of a supplier name usually corrects itself when matched against master data, while one wrong digit in the gross total is money lost. So amounts and tax IDs get strict thresholds and description fields looser ones. Above a certain invoice amount you can require a second approver regardless of the score.

The audit trail for each document should hold at least:

• Arrival time, channel and content hash of the file.
• The service or model used for reading, with its version.
• Each field's first value, confidence score and corrected value, if any.
• Who approved or rejected it, when, and for what reason.
• The entry number created in the target system and any reversal.

Review corrections weekly and add recurring ones to the test set.

09GDPR, special categories and transfers

Documents often carry personal data: a sole trader's name on an invoice, an ID number on an application, a diagnosis on a medical certificate. Before building, draw a data flow map: which personal data each type contains, where it travels and how long it is kept.

• Special categories: Article 9 of the GDPR covers health, genetic and biometric data, and Article 10 covers criminal convictions. Documents containing them run in a separate workflow with narrower access and, where possible, masking.
• Processors and transfers: The reading service signs a processing agreement under Article 28. If it sits outside the EU or EEA, Chapter V requires an adequacy decision or safeguards such as standard contractual clauses.
• Automated decisions: Article 22 gives people the right not to be subject to decisions based solely on automated processing that significantly affect them. The workflow reads a file and lists what is missing; it does not reject the application.
• Health records in the US: A HIPAA covered entity needs a business associate agreement with any vendor handling protected health information for it.

The EU AI Act lists AI used in recruitment and creditworthiness assessment as high risk in Annex III, so a workflow that screens CVs or scores loan files carries a very different set of obligations from simple invoice capture. Your legal adviser makes the assessment; the technical team documents the data flow and settings.

10Rolling out from pilot to full use

A workflow goes live in stages, each based on the measurements of the one before. This skeleton suits a single document type in most businesses.

1. Collect the sample set: Set aside anonymized documents of the chosen type from recent months, including different senders and bad scans.
2. Write the correct answers: Key in the true value of every field for each sample; this sheet is the reference for every later measurement.
3. Measure the prototype: Run reading and rules on this set only and produce an error list per field.
4. Run in shadow mode: The workflow reads live documents but posts nothing; staff work as usual and both results are compared daily.
5. Go live narrowly: First only one group of senders, or documents below a set amount, may pass without review; the rest stay on the review screen.
6. Widen the scope: As long as the error list stays acceptable, add more senders, then a second document type.

Shadow mode is the stage most often cut short, yet it is the only place to see behavior on real documents. Keep it running through at least one month end close; hastily scanned paper in closing week reveals errors quiet days never show.

11Measuring time saved and accuracy

Value shows up in several measures that balance each other, not in a single rate; if the straight through share rises while corrections rise too, the workflow got faster and worse. Record the starting point before anything changes: tracking time per document for a few weeks with our working hours calculator is the only solid basis for a later comparison.

• Error per field: In a weekly random sample, the share of each field that was correct, corrected or left empty.
• Time in the review queue: From the moment a document lands in the queue to approval; if the queue piles up, change the staffing plan rather than the threshold.
• Close calendar: On which working day the month end close is finished, compared with the months before automation.
• Errors found later: Mistakes caught after posting by a supplier, a customer or an auditor.
• Usage fee per document: The model and reading service bill divided by documents processed, tracked monthly.

Read the numbers with seasonality in mind; year end or holiday peaks can make AI document processing look better or worse than it is.

12Limits and overlooked risks

AI document processing reduces reading errors but does not remove them, and some risks did not exist with classic OCR at all. Write down a countermeasure for each limit before the build.

• Invented values: Language models may fill an unreadable field with a plausible value instead of leaving it blank. Instructions must require empty output for unreadable fields, and rules must catch those gaps.
• Instructions hidden in documents: Someone can embed text invisible to the human eye in a PDF to steer the model. The reading layer should only have permission to extract fields; no document content can issue commands to the workflow.
• Silent version changes: When a provider updates its model, the same document may be read differently. Pin the version and rerun the test set on every change.
• Stamps, signatures and handwritten notes: A stamp over the total or a correction in the margin leaves the model unsure which value to pick; such documents go to review under a strict threshold.
• Long documents: In contracts running to dozens of pages the model can miss the relevant clause; require every extracted item to cite its page and clause number.

These measures make risk manageable, not zero, so the review queue is never switched off; it only gets narrower.

13Common mistakes in document automation

Most problems come from preparation and rollout order, not from the model.

• Deciding on a demo invoice: Extraction that looks flawless on a vendor's clean sample behaves differently on your blurry receipt photos; decide with your own sample set.
• Sending structured invoices to the model: Reading the PDF rendering when the XML exists creates fees and duplicate entries; separate structured data first.
• One global threshold: The same confidence threshold for all fields produces either needless review work or dangerous pass throughs; set it by field and amount.
• Leaving the review screen for later: Treating it as a plain table while polishing extraction burns the saved time in the queue; design it alongside the first prototype.
• Skipping shadow mode: Connecting a workflow straight to the books because it did well on the test set carries real world errors into accounting; run in parallel for at least one close.
• Losing corrections: If fixes on the review screen are not recorded, the workflow repeats the same mistakes; tie every correction to the audit trail and the test set.

One more turns up often: involving the accounting team late. People who will use the review screen should see the field schema and rules from day one.

14Choosing a partner and next step

A good partner asks about your samples, target system and closing calendar before showing a demo. When requesting quotes for AI document processing, ask for written answers on these points:

• On which sample set will accuracy be measured, and per field or per document?
• How will structured electronic invoices be kept out of the reading layer?
• If the reading service is replaced, do the rules, review screen and integration have to be rebuilt?
• In whose name are model, reading service and automation accounts opened, and who receives the field schema and rules at handover?
• Are the data flow map and a vendor contract checklist part of the scope?

We deliver this as part of our AI automation services. We have no live client project in AI document processing to show as a reference yet, so we describe our method rather than promise results; our automation, software and web work is on the references page.

Cost depends on the number of document types, volume, connected systems and the scope of upkeep; fixed price options for discovery and the first workflow are on our pricing page. Send the most time consuming document type, rough monthly volume and target system via the contact form, and we will define the field schema, review rules and a written quote with you.