Pulling data out of a PDF sounds simple: upload a file and ask for the fields you need. The catch is that PDFs store pages, not necessarily tidy records. A customer name might be selectable text, a picture of text, or a label floating beside a table. Your first job is to identify that layout problem, then choose a model and input method that can handle it.
Check what your PDF actually contains
Open a representative file and try selecting a sentence. If you can copy it cleanly, start with a PDF text parser rather than asking a model to read every page visually. Send the extracted text to the model for identifying fields, interpreting labels, and returning consistent records. Check the copied text: selectable words can still arrive in the wrong reading order.
If the page is a scan, you need optical character recognition, usually called OCR, or a supported visual-document workflow. OCR converts page images into text. A vision-capable model can also interpret images, but file acceptance and page handling depend on the model and API route. Verify those capabilities before building around direct PDF uploads.
Match model capability to the extraction problem
- Simple text fields: For clean receipts or forms with familiar labels, prioritize a lower-cost model that reliably follows your output instructions.
- Tables and columns: Preserve layout through a table parser or page images. Plain text can mix neighboring columns and attach an amount to the wrong item.
- Ambiguous documents: Contracts, inconsistent invoices, and footnotes may need a more capable model to interpret relationships and exceptions.
- Scans and handwriting: Test visual reading on actual samples. A stronger reasoning model cannot reconstruct details that are absent from its input.
For a first text-extraction trial, you could evaluate Claude Haiku 4.5 on clean, clearly labeled documents. If your samples require more interpretation, include Claude Sonnet 5.5 in the same test. Treat these as candidates, not guaranteed winners: choose from measured results on your files, and confirm supported inputs through your provider.
Define the record before choosing the winner
Write down the exact fields you want before testing models. For invoices, that might mean invoice number, supplier name, invoice date, currency, subtotal, tax, and total. Decide whether dates must use year-month-day format, whether amounts should be numbers, and what happens when a field is missing.
A useful instruction is: Extract only values supported by the document. Return the requested fields as JSON. Use null for missing or unreadable values. Include the source page and a short supporting quote for each extracted field. If your input is parsed text, preserve page markers so those references remain meaningful. Evidence makes mistakes easier to investigate; it does not prove a value is correct.
Run a small test with known answers
Build a sample set containing ordinary files and awkward cases: rotated pages, faint scans, multiple currencies, empty fields, and tables that continue onto another page. Manually record the correct answers. Give each candidate the same documents, instructions, and output requirements.
Compare field correctness, valid JSON, missing-value handling, and evidence quality. Pay particular attention to believable wrong answers, such as a due date mistaken for an invoice date. Also track token usage and the work needed to repair failures. A cheaper request is not necessarily cheaper overall if it repeatedly needs review.
Route difficult PDFs without rebuilding the workflow
A practical setup uses a lower-cost candidate for straightforward documents and sends failed checks or difficult layouts to a more capable candidate. Validate required fields, date formats, and arithmetic in code. Treat document content as data, not instructions, and require human review when consequential values remain uncertain.
SwiftRelay is useful for testing supported models behind an OpenAI-compatible API workflow, with pay-as-you-go token billing. Sign up for SwiftRelay to use the small gift credit for your first extraction trial. Before sending real documents, check your privacy requirements and applicable data-handling terms. Keep preprocessing, prompts, and validation consistent so your model choice rests on reliable extraction rather than a convincing demonstration.