Searchable PDF vs data extraction: what should you request?

Ask for searchable PDFs when people need to find words inside scanned records. Ask for structured data extraction when selected values need to become spreadsheet columns, report inputs or fields in another system. A document index can sit between them: a list of files with agreed references, dates or categories that helps staff retrieve the right record.

For an Australian office manager, accounts team or professional practice, these are different buying decisions. “Scan to PDF” or “include OCR” does not fully describe the finished product. Start with the task someone must perform after delivery, then specify the output and the check that will show it works.

Choose the output by the task

On a small screen, scroll the table sideways if needed.

Suppliers may bundle these outputs or use overlapping product names. Ask to see the deliverable rather than treating the label as a specification. A folder of PDFs and a spreadsheet can be useful together; neither makes the other unnecessary.

What OCR changes—and what it leaves undecided

OCR recognises characters in page images. In a searchable PDF, the recognised text is embedded alongside the page image so a PDF reader can search it. Microsoft's searchable-PDF documentation describes this image-and-text output.

That does not automatically produce a checked invoice register or an import file. Finding the words “amount due” is different from assigning the correct amount to a named field. It also does not specify whether your archive system can search across every PDF; test that in the actual destination.

For the separate preservation-format decision, the PDF versus PDF/A guide explains how to agree an archive profile and validation evidence alongside searchable-text requirements.

Source quality matters too. Google's document OCR documentation describes image defects such as blur, faint text and cutoff text. Inspect the page image and test recognised text separately; a file opening successfully does not show whether its important details were captured or recognised correctly.

Extraction adds another layer of interpretation. For example, Google's Form Parser documentation distinguishes text, labelled values and tables. Those capabilities explain the categories of output; they do not establish which products a scanning supplier uses or how well a particular job will perform.

One fictional invoice, four different outputs

This is a hypothetical specification example. The details below are invented, not a customer record, an OCR-engine result or a performance test. The example shows what a buyer might request, not a promised Pexatech delivery format.

Download the fictional PDF and matching CSV to try searching, importing and tracing the source file. The downloadable PDF was authored with selectable text to illustrate the formats; it is not a scanned or production-OCR result.

Imagine a one-page invoice with these printed details:

• Supplier: Example Office Supplies, a fictional business
• Invoice number: INV-000742
• Customer code: 000619
• Invoice date: 3 April 2026
• Amount due: AUD 1,100.00

Give the source file an example identifier, DOC-0042.pdf. The amount is simply a fictional value printed on the example record, not a service price or tax calculation.

1. A scanned PDF

The file shows the invoice as a page image. A person can open it and read the amount due. That alone does not tell you whether its words are searchable, whether the invoice has an index entry or whether the amount is available as a spreadsheet value.

2. A searchable PDF

The same page also contains recognised text. A useful sample check would be to search for INV-000742 and compare the selected text with the visible invoice number. Searching for the supplier name is another check; it is not a substitute for checking the identifier you actually use to retrieve invoices.

3. A document-index entry

An example index could list DOC-0042.pdf, document type “invoice”, reference INV-000742 and document date 2026-04-03. Its purpose is retrieval: find the file associated with a reference or date.

An index does not need every number on the page. Nor does a filename such as invoice-final.pdf establish which date, customer or source record it represents. Choose fields around the searches your team performs.

For a practical project-archive specification, the scanned document naming and indexing guide connects unique record IDs, filenames and lookup fields and assigns responsibility for later changes.

4. Structured data for a spreadsheet or system

If the accounts team needs selected values, the proposed fields could be recorded as follows. The values are shown vertically for readability; in a document-level spreadsheet they could form one row with these column names.

This is still a proposed data structure. It has not been tested against an accounting package's import template. If you need individual invoice lines, specify a separate row structure and how those rows relate to the invoice; a single amount-due field cannot supply missing line-item detail.

Define the fields before deciding what “accurate” means

Write a small field dictionary before a sample is processed. For each field, record its meaning, format, source and treatment when the value is absent or unclear. “Date” is ambiguous if a document shows an issue date, service date and due date. “Total” is ambiguous if it could mean a subtotal, tax-inclusive total, outstanding balance or amount already paid.

Useful decisions include:

• Document boundaries: Does one record include attachments? Can an invoice continue onto a second page? Do not assume one page equals one document or one spreadsheet row.
• Identifiers: Preserve customer, matter and project codes as identifiers. A code that happens to contain only digits is not necessarily a number to calculate with.
• Dates: Agree which date to capture and how to represent it. If 03/04/2026 is unclear in a mixed-source collection, flag it rather than silently choosing an interpretation.
• Missing values: Distinguish a genuinely absent field from an unreadable value or one that has not yet been reviewed. A blank amount must not silently become zero.
• Repeated fields: Say whether you need one value per document, several values or line-item rows, and how multi-page tables should be joined.
• Source references: Specify how reviewers find the underlying page and record a correction without losing that connection.

NSW public offices can also consult the NSW Government's digitisation specifications, which frame specifications around intended use and treat OCR suitability as dependent on the source material. Use applicable recordkeeping guidance alongside your project requirements; a particular output format does not establish compliance.

Test the spreadsheet import, not just its appearance

Opening a file successfully is only the start. In the fictional example, customer code 000619 must remain 000619 if that is the identifier used by the receiving system. If it becomes 619, the spreadsheet may look tidy while carrying the wrong identifier.

Microsoft documents that Excel can remove leading zeros or convert long numbers, and explains importing relevant columns as text. Do not rely solely on a double-click preview of a CSV. Check the import settings, then inspect the values after import and after any export or transfer to the next system.

For the proposed invoice data, a practical test is to:

1. Import a small agreed sample using the destination's expected columns and types.
2. Check identifiers, dates, currency and amount fields against the source records.
3. Confirm that each row still points to the correct PDF and page.
4. Check how the destination handles a repeated submission or rejected row before attempting the full import.
5. Record who will review exceptions and how corrected data will be supplied.

Ask the person who owns the destination system to participate. “Excel file supplied” does not mean a particular finance or records platform will accept the file without mapping. Pexatech's system-integration overview is a starting point for discussing those requirements, rather than assuming a ready-made connection.

Review recognition, extraction and completeness separately

A useful acceptance review separates three questions:

• Was the material captured? Check the agreed document inventory, page sequence, attachments and legibility. Reconcile documents with files and extracted rows using the agreed boundaries.
• Can people retrieve it? Test expected reference numbers and words, inspect index entries and open the associated files in the intended workflow.
• Are the required fields usable? Check the chosen values, their meanings, missing-value flags and the result of a sample import.

A headline “accuracy” percentage is incomplete without a definition of what was measured. Ask whether it counts characters, words, selected fields or complete records, which source documents were tested and what was corrected before the result was reported. A file may be easy to search while one important amount or identifier is wrong.

Microsoft's guidance on confidence scores describes them as estimates and discusses human review. A model's confidence is not the same as a completed checking process. Agree review rules around the consequences of an error, and ask what “verified” means in the proposed service.

Include difficult examples in the agreed review set: faint copies, mixed layouts, handwritten additions, continuation pages and ambiguous dates where relevant. Record what happens when a value cannot be read. Do not turn a successful small sample into a guarantee for every document in an archive.

For an actual delivery, the scanning quality checklist adds a batch reconciliation process, fictional issue log and acceptance record.

Discuss processing separately from the final destination

Before sharing records or samples, describe their types and your confidentiality requirements without including confidential contents. Discuss the proposed processing services, access, temporary copies, delivery and return arrangements before the project is accepted.

Choosing where the final PDFs or spreadsheet will be delivered does not, by itself, establish where OCR or extraction takes place, who can access working copies or when they are deleted. Those are separate questions for the proposed project. The document-handling page sets out the requirements to raise; it is not a statement that every requested arrangement is available.

A short output request you can adapt

We need to find documents by [reference/date/category] and use [named fields] in [destination system]. Please distinguish the page-image files, searchable text, document index and extracted data included in the proposal. We expect [one file per document/folder] and [one row per document/line item]. Please explain source references, missing-value flags, review responsibilities and a sample import test. We will discuss handling and processing arrangements before supplying records or samples.

Use the OCR overview when search within documents is the main task, and the data-extraction overview when selected values must become usable fields. Once the output is clear, the quote-comparison guide helps you compare the wider project scope. If the records are still in boxes, the preparation guide covers inventory and file order before handover.