Picture a finance lead uploading a scanned invoice to your SaaS product. The extraction comes back as valid JSON with every field spelled correctly, but the line-item table is one long string with the columns interleaved. Nothing throws an error, so nobody notices. If you're planning AI document processing, that failure is the one to design against, and the first action is cheap: pull about fifty real documents from your own users, including the ugly ones, and label what you want out of them.
How Should a SaaS Product Turn PDFs Into Structured Data?
Convert the PDF into clean text and layout first, then have a language model map that content to your schema, then validate the result in code. Most accuracy problems start in the first step, not the model.
Text accuracy and structure accuracy are different measurements. A parser can read most of the words on a page and still lose which cell each value belonged to. For invoices and ledgers the table structure carries the meaning, so a row that loses its column alignment is not partly right. It is wrong in a way that looks tidy. I'd score them separately in your own tests: exact match for scalar fields, and something structure-aware for tables.
Dedicated parsers treat layout as their own task. The Docling project lists advanced PDF understanding including page layout, reading order and table structure, OCR support for scanned PDFs and images, and export to Markdown or lossless JSON. It is MIT licensed and its README highlights local execution for sensitive data and air-gapped environments.
Frontier APIs take a different route. Anthropic's PDF support docs explain that each page is processed as both text and an image, that a page typically uses 1,500 to 3,000 text tokens depending on density, and that the limits are 32 MB and 600 pages per request (100 when the request's context window is under 1M tokens). OpenAI's PDF file input guide says vision-capable models receive extracted text and page images together, with a 50 MB limit per file. Neither vendor publishes an accuracy figure for tables, so test that yourself.
For the last step, both vendors can constrain output to a JSON schema. OpenAI's Structured Outputs guarantees schema adherence, unlike plain JSON mode. Anthropic's structured outputs return valid JSON matching your schema, with documented exceptions: a refusal, or output cut off at the token limit, may not match. It also doesn't support numeric constraints such as minimum and maximum in the schema, so range checks stay in your code. A valid shape doesn't mean a correct value, so validate totals against line items before you save anything.
One design worth testing is a two-path pipeline. Parse with a layout tool, send the Markdown to a text-only call, and fall back to sending the page image only when validation fails. OpenAI's guide notes that PDF parsing puts both extracted text and page images in context, which can increase token usage, and it offers a detail setting to control image cost. Sending images only when you need them keeps the common case cheap.
Can a Local Model Replace OpenAI for Document Extraction?
For predictable fields such as dates, totals and policy numbers, a small local model can be good enough, and for fields that need interpretation of prose you may still want a larger model. Only a test on your documents can settle it.
I don't have a verified public benchmark to quote for this comparison, and I'd distrust any single number that claims to answer it, because results depend on the document types, languages, prompts and schema. What I can say is how I'd structure the test. Hold everything constant except the model: the same parser, the same prompt, the same schema. Then score field by field.
The output will probably split your fields into two groups, and that is my expectation, not a measured result. Structurally predictable fields (dates, totals, VAT numbers, addresses) are candidates for a cheaper model. Fields that need intent read out of prose are candidates for a stronger one. That turns the question from "which model" into "which field goes to which model", and routing by field beats upgrading everything at once.
Weigh mistakes by what they cost. A wrong date on an internal note is not the same as a wrong total on an invoice. Set stricter thresholds and more human review on fields where an error moves money or triggers a legal duty, and looser ones elsewhere. That policy is a product decision, and the eval rig gives you the numbers to make it.
Note that the parser and the model are separate decisions. Docling can run on your own machine whether the language model is local or hosted. Keeping the parser local is often the easy win when documents are sensitive, and it doesn't force you to run a language model yourself.
What Does Self-Hosting a Document Model Really Cost?
Self-hosting costs the GPU rate for every hour it is provisioned, whether documents arrive or not, plus the engineering time to run it. That is why spiky document traffic often favours hosted APIs or serverless GPUs.
Start from published rates. Modal bills GPUs per second with no charge for idle resources and lists an H100 at $0.001097 per second, about $3.95 per hour. At that rate a GPU kept running for a 30-day month costs about $2,800 before any engineering time, and I calculated that from the listed rate. Serverless billing avoids paying for idle time, but you still take on the work of packaging and operating a model.
Compare that with a hosted API on a hypothetical workload of 50,000 pages a month, at about 3,000 input tokens and 500 output tokens per page. That is 150 million input tokens and 25 million output tokens. OpenAI's pricing page lists gpt-6-luna at $0.10 per million input tokens and $0.50 per million output tokens, which works out to $15 plus $12.50, or $27.50 a month, and model quality on your documents still has to be tested. Prices change, so re-run this arithmetic against the current page before deciding.
| Workload shape | Cheapest option to test first | Why (my reasoning) |
|---|---|---|
| Low volume, mixed fields | Hosted API | Per-page cost is small next to one engineer-week |
| Spiky batches | Serverless GPU | You pay for the burst, not the calendar |
| Sustained volume, uniform fields | Reserved GPU with an open-weight model | Utilization is high enough to matter |
| Data cannot leave your jurisdiction | Local or in-region hosting | Compliance decides before cost does |
The table is a recommendation, not a measured comparison. The last row is the only one where cost stops being the deciding input.
When Does Local Actually Win?
Local wins when the data can't leave your control, or when sustained volume is high enough that a per-page gap compounds. Cost arguments expire as prices change, while compliance constraints don't.
If you process health records or legal material, the deciding question is who touches the file. Article 28(2) of the GDPR says a processor shall not engage another processor without prior specific or general written authorisation from the controller (GDPR Art. 28). Every hosted model provider in your pipeline is a sub-processor question your customers' counsel may ask you to answer in a contract. I'm not giving legal advice, and you should check your own obligations.
My Callidus case study describes a multi-tenant SaaS for UK aesthetic clinics whose features include patient records and consent forms, with six roles and different access to clinical and financial data. It doesn't describe AI document extraction. I mention it as the kind of product where the processor question comes before the model question, not as a result.
Build the eval rig before you choose
You can't pick a model for a workload you haven't measured, and building the measurement takes about a day.
- Collect about fifty real documents from production, including scans at an angle and phone photos.
- Label the ground truth by hand: the exact JSON you want from each one.
- Score structure separately from text, with exact match for scalar fields and a table-aware check for line items.
- Run the cheapest viable configuration first, a layout parser plus a small model, and treat it as your floor.
- When a field fails, route that field to a stronger model instead of upgrading the whole document.
- Re-run the same fifty documents monthly, because prices, models and your document mix all move.
If you're choosing infrastructure from scratch, my SaaS MVP stack covers what pairs well with what, and which AI features are worth adding to a business product is worth settling before you build extraction. For the build side, my AI-augmented development workflow covers the day-to-day version.
Show confidence and keep the corrections
Every pipeline gets some fields wrong, so the interface should show which fields to check and let a person fix them quickly. Store what they changed. That correction log is the best evaluation data you will own, and your users produce it for free.
Be careful with confidence scores. A model's own stated confidence is not calibrated, so I'd derive signals from checks you can compute: totals that match line items, dates that parse, identifiers that fit their format, and disagreement between two runs of the same document. Treat these as a recommendation and compare them with your corrections before trusting them.
Your next step is the fifty documents. Pull them this week, label them, and count how many fields were predictable enough that a small model would have handled them.