Many businesses still have people retyping information from documents into systems: supplier invoices into accounting, delivery notes into stock, application forms into a CRM, receipts into expense reports. It is slow, repetitive and error-prone, and it is one of the tasks where modern AI models are genuinely useful today.
Document extraction is a better first AI project than most, because the task is narrow, the output is structured, and mistakes can be checked. This post explains how a reliable extraction pipeline works, and where the real effort goes.
What has changed
Traditional OCR turns an image into text, but leaves you to figure out which number is the total and which is the invoice number. Template-based tools work well for one layout and break when a supplier changes theirs.
Current language models that accept images and documents can read a page and return the fields you ask for, across many layouts, in several languages, including Arabic and English on the same page. They are not perfect, but they handle variety far better than templates did.
The pipeline
A production extraction system has more parts than "send the PDF to the model":
- Intake. Documents arrive by upload, email or a mobile photo. Store the original file permanently.
- Pre-processing. Convert to images or text as needed, fix rotation, split multi-page files, reject unreadable photos early and ask for a better one.
- Classification. Identify the document type: invoice, receipt, delivery note, form. Each type has its own schema.
- Extraction. Ask the model for the fields in that schema, as structured output.
- Validation. Check the result with rules in code.
- Review. Send uncertain or failed documents to a person.
- Export. Push approved data into the target system.
- Feedback. Record corrections to improve prompts and measure accuracy.
Define the schema carefully
The schema is the contract between the document and your system. For an invoice, it might include supplier name, tax number, invoice number, date, currency, line items with description, quantity, unit price and total, tax amounts and grand total.
Tips:
- Be explicit about formats: dates as year-month-day, amounts as numbers without separators, currency as a code.
- Allow empty values. Tell the model to return null when a field is not on the document, rather than guessing. Guessing is the most dangerous failure.
- Keep the raw text of key fields alongside the normalized value, for review.
- Use structured output features of the model provider so the response always matches the schema. See choosing an LLM API.
Validate with rules, not trust
Models make plausible-looking mistakes. Code catches many of them:
- Line items should add up to the subtotal; subtotal plus tax should equal the total.
- Dates should be in a plausible range.
- Tax numbers should match the expected format.
- The supplier should exist in your records, or be flagged as new.
- The same invoice number from the same supplier should not be processed twice.
Any failed check sends the document to review. These rules are simple to write and catch a large share of errors.
Confidence and human review
Design the system so a person reviews what needs reviewing, not everything:
- Validation failures always go to review.
- New suppliers or unusual layouts go to review the first few times.
- High-value documents can always require a check, by policy.
- Everything else can be approved automatically, once you have measured accuracy on enough documents.
The review screen matters as much as the model. Show the document image next to the extracted fields, highlight the uncertain ones, and let the reviewer correct and approve with the keyboard. A good review screen turns a minute of typing into a few seconds of checking.
Measure accuracy properly
Before going live, build an evaluation set: real documents from your business, with the correct values entered by hand. Measure accuracy per field, not just per document, because the total might always be right while the tax number is often wrong. Re-run the set whenever you change the prompt or the model. See how to evaluate LLM output.
After launch, corrections made in review are your best data. Track the correction rate per field and per supplier, and focus improvements where corrections cluster.
Languages and mixed documents
Documents in the Middle East often mix Arabic and English, with Arabic or Latin numerals, sometimes on the same line. Test these specifically. Normalize numerals in code after extraction, and make sure the review screen displays right-to-left text correctly. See building bilingual Arabic and English apps.
Privacy and security
Invoices and forms contain personal and commercial data. Before sending them to a provider:
- Check the provider's data retention and training terms for API use.
- Send only the pages needed.
- Store originals and extracted data securely, with access limited by role.
- Treat document content as untrusted input. Text inside a document can try to manipulate the model, especially if the model can take actions. Keep extraction separate from any step that acts on the data. See prompt injection risks.
Costs
Costs depend on page count, image resolution and the model. Estimate from a sample of real documents using the provider's current prices, and compare with the time currently spent on manual entry. Smaller models often handle simple, clean documents well; reserve larger ones for difficult cases, for example by retrying with a stronger model when validation fails.
Where it goes wrong
- Poor photos: blurry, angled or cropped. Guide users in the capture screen and reject bad images early.
- Handwriting: improving, but still less reliable. Expect more review.
- Long tables across pages: process page by page and merge carefully.
- Ambiguous fields: several dates or several totals on one document. Describe exactly which one you want.
- Silent guesses: the model fills a missing field with something plausible. Ask for null, and validate.
Rolling it out gradually
Start with one document type and one team. Run the extraction in parallel with manual entry for a couple of weeks and compare the results field by field. When accuracy is good enough, switch the team to reviewing instead of typing, and keep measuring. Add the next document type only when the first one runs smoothly. This avoids the common trap of launching many document types at once and drowning the reviewers in corrections.
Build or buy?
There are ready-made extraction services for common documents such as invoices and receipts. If your documents are standard and the service integrates with your systems, start there. A custom pipeline makes sense when documents are specific to your business, when you need extraction inside your own app, or when you need control over where data goes.
Where it fits in a product
Extraction rarely stands alone. It usually feeds an existing workflow: a field technician photographs a delivery note in the app, an admin uploads supplier invoices, a customer sends a form. Building it into the product you already use avoids yet another tool. For the broader approach, see adding an AI feature to your product and AI agents for a small business.
Summary
AI extraction works well when it is treated as a pipeline: clear schemas, rules that validate, confidence-based review, measured accuracy and careful data handling. The model does the reading; your system makes sure the result can be trusted.
If your team spends hours retyping documents, read about me, see my work, and get in touch.