There are three ways to get structured data out of a PDF. Text parsing reads an existing text layer and is fast, free and exact — but only works on digitally generated PDFs. OCR recognises characters in scanned images and is necessary whenever there is no text layer. Schema-driven AI extraction identifies fields by meaning rather than position, and is the only approach that handles documents whose layout varies.
Which you need depends on one question: does the document have a text layer, and does its layout change between documents?
Which approach should I use?
| Approach | Works on | Handles layout variation | Relative cost | Accuracy |
|---|---|---|---|---|
| Text parsing | Digital PDFs only | No | Lowest | Exact — it reads what is there |
| OCR | Scans and images | No | Moderate | High on clean scans, degrades with quality |
| Template matching | Either, fixed layout | No | Low | Exact when layout matches, fails when it does not |
| AI extraction | Either | Yes | Highest | High, but requires validation |
How do I tell whether a PDF has a text layer?
Run a text extraction. If a document that visibly contains paragraphs returns almost nothing, it is scanned.
curl -X POST https://www.ashdocs.com/api/v1/tools/pdf-to-text \
-H "X-API-Key: ash_live_..." \
-F "file=@document.pdf"
A page of text should return hundreds of characters. Twenty characters from a full page means you are looking at images and need OCR.
A mixed document is common — a digitally generated contract with a scanned signature page. Handle per page, not per document.
When is simple text parsing enough?
More often than people expect.
If your PDFs are generated by software — invoices from an accounting system, statements from a bank, reports from a BI tool — they have a text layer, and if the layout is consistent, position-based parsing is exact, instant and free.
The limitation is brittleness. When the vendor changes their invoice template, position-based extraction breaks silently and starts returning wrong values rather than errors. Always validate extracted values against expectations — a total that does not match the sum of line items should raise an error, not flow into your ledger.
When do I need OCR?
Whenever there is no text layer: scans, photographs, faxes, and PDFs produced by printing to paper and scanning back.
curl -X POST https://www.ashdocs.com/api/v1/tools/ocr \
-H "X-API-Key: ash_live_..." \
-F "file=@scanned-invoice.pdf"
Input quality determines output quality more than the engine does. 300 DPI scans, straight rather than skewed, good contrast, no shadows. A phone photograph at an angle in poor light will produce poor results regardless of which OCR service processes it.
If you control the capture process, fixing it is far cheaper than compensating downstream.
When is AI extraction worth the cost?
When layout varies and meaning is stable.
The clearest case is invoices from many different suppliers. Every one has a total, a date, an invoice number and line items — in completely different places, under different labels, in different formats. Position-based rules need one template per supplier and break constantly. AI extraction finds the total because it understands what a total is.
curl -X POST https://www.ashdocs.com/api/v1/tools/pdf-to-data \
-H "X-API-Key: ash_live_..." \
-F "file=@invoice.pdf" \
-F 'schema={
"invoice_number": "string",
"issue_date": "date",
"supplier_name": "string",
"total": "number",
"currency": "string",
"line_items": [{"description":"string","quantity":"number","amount":"number"}]
}'
Always request confidence scores and act on them. A field returned at 60% confidence should go to human review, not straight into a database. The value of AI extraction is not that it is always right — it is that it tells you when it is unsure.
What usually goes wrong
Numbers arrive as strings with symbols. $1,250.00 needs parsing to 1250.00. Currency symbol, thousands separator, and decimal convention all vary — and in some locales the comma is the decimal separator.
Dates are ambiguous. 03/04/2026 is March 4th or April 3rd depending on origin. Request ISO format explicitly, and if the source is ambiguous, capture the raw string alongside the parsed value.
Multi-page tables split. Line items spanning three pages must be reassembled. Check that your extracted item count matches the document's stated count where one exists.
Rotated pages return gibberish. OCR on a sideways page produces nonsense. Detect and correct orientation before processing.
Confidence scores get ignored. The most expensive failure mode. A wrong value that flows silently into a ledger costs far more than a flagged one that a person checks.
Handwriting mostly does not work. Modern OCR handles print well and handwriting poorly. Do not build a workflow that depends on it.
How should I validate extracted data?
Non-negotiable for anything financial.
- Arithmetic checks. Line items must sum to the subtotal; subtotal plus tax must equal the total. A mismatch is an extraction error.
- Format checks. Dates parse, currencies are valid codes, numbers are within plausible ranges.
- Confidence thresholds. Below your threshold routes to human review.
- Duplicate detection. The same invoice number from the same supplier is likely a re-send.
Design the human review step from the start. Every extraction pipeline needs one, and retrofitting it is harder than building it in.
Frequently asked questions
How do I extract data from a PDF automatically?
For digital PDFs with consistent layout, parse the text layer directly. For scans, run OCR first. For documents whose layout varies between sources, use schema-driven AI extraction, which identifies fields by meaning rather than position.
What is the difference between OCR and data extraction?
OCR converts images of text into machine-readable characters. Data extraction identifies which of those characters constitute the invoice number, the total, or the date. OCR is often a prerequisite for extraction, not a substitute for it.
Can I extract data from a scanned PDF?
Yes, but OCR must run first to create a text layer. Extraction quality then depends heavily on scan quality — 300 DPI, straight, well-lit.
How accurate is AI PDF data extraction?
High on clean documents, and it degrades with scan quality and layout complexity. The important practice is requesting per-field confidence scores and routing low-confidence values to human review rather than treating any output as automatically correct.
How do I extract tables from a PDF?
Simple tables with clear ruling lines extract reliably with dedicated table extraction. Complex tables with merged cells or nested headers need AI extraction with an explicit schema, and still warrant validation.
In short
Check for a text layer first. Digital plus consistent layout means simple parsing. Scanned means OCR. Varying layout means AI extraction with a schema.
Whatever you choose, validate arithmetically, act on confidence scores, and build the human review step before you need it.