AI PDF Extraction Must Keep the Right Numbers in the Right Rows

Every number can be correct and the imported record can still be wrong. PDF extraction needs a row-integrity test, not just a readable spreadsheet.

Correct characters can still produce the wrong business record

Your team does not need a machine that can read a supplier statement aloud. It needs the balance against the correct account, the quantity against the correct product and the delivery date against the correct order. Those are relationships, not just characters. An extraction can look impressively clean while quietly changing all three. That is why judging a PDF tool by how readable its output looks is a weak purchasing test.

Imagine a price list with product codes on the left and two prices under a merged heading. One price applies to a single unit; the other applies to a carton. The extractor recognises every digit correctly but flattens the header into an ordinary row. Your import then treats carton prices as unit prices. Nothing has been invented. The failure is structural, and a spellcheck or a confident summary will not reveal it. This is an illustrative scenario, not a reported client incident.

Recent vendor writing recognises this distinction. Nutrient's November-updated comparison identifies merged cells, borderless tables, scans and tables continuing across pages as separate challenges. It also explains why Markdown alone cannot represent merged-cell spans. That is useful technical context, not independent proof that its own product is the best choice. Ask every supplier to show the structure it retains, rather than accepting a polished screenshot.

What this means in practice: define the business record before choosing the parser. Write down the fields that must stay together and the heading, unit or footnote that changes their meaning. For a stock order, that might be product code, pack size, quantity and delivery location. If the output cannot preserve those associations in a form your importer understands, character recognition accuracy is beside the point. The acceptance question is whether the correct action would follow from the extracted record.

A correctly recognised number in the wrong row is still wrong.

Choose the simplest existing extraction route that fits the files

Start with a very ordinary test: can you select text inside the PDF? A selectable text layer gives conventional extraction tools something to work with. A scan needs optical character recognition or an equivalent visual processing step. Mixed documents may contain both. Treat this as a starting classification, not a guarantee, because selectable text can still be positioned in ways that make table reconstruction difficult. A document can be readable to you without containing usable rows for software.

For a one-off conversion, investigate an existing desktop tool before building anything. Tabula is a named open-source option for text-based tables. For repeatable local processing, pdfplumber and Docling are candidates worth evaluating against your files. Nutrient describes pdfplumber as suitable for tuning machine-generated PDFs and Docling as providing local document conversion with table structure recognition and OCR support. Verify the current version and supported formats yourself. These are starting points for a shortlist, not a claim that each tool works on every scan.

Hosted products can be sensible when your team needs intake, review and delivery as well as parsing. Parseur's guide published on 4 November 2026 makes that workflow distinction and explicitly warns that vendor accuracy figures are not comparable without the same documents and method. Its commercial interests are clear, so use the argument to improve your test rather than treating its comparison as a neutral ranking. There is no need to approve a paid subscription just to establish whether a local route works.

A second named example is LlamaIndex's 2026 comparison of LlamaParse, Docling and DeepSeek-OCR, which focuses on merged cells, multi-line headers and layout relationships. The useful common theme is structure. Shortlist one simple local route and, only where justified, a hosted route with the required review controls. Compare the same documents, the same expected records and the same downstream import. Avoid comparing a library's bare output with a platform's fully configured workflow as though they include identical work.

Do not buy a language model to solve a text-layer problem.

Build a row-integrity test, not a beauty contest

Create a small, deliberately awkward acceptance pack from documents you are permitted to use. Include a clean table, a scan, a rotated page, a long description wrapping across lines, a merged header and a table that continues onto another page. Add a document where a subtotal resembles a normal record. You do not need a statistically representative benchmark to discover obvious failure modes, but you must not present a small test as proof of universal reliability. Its purpose is to expose weaknesses before a pilot expands.

Write the expected answer manually for each selected table. Count the actual records, identify the column headings and preserve units, currency and negative signs. Where headers have multiple levels, record the complete meaning of the destination field. A column labelled 'Actual' under 'Previous year' must not become interchangeable with 'Actual' under 'Current year'. Store page references alongside the answer so a reviewer can resolve disagreements without rereading the whole file or trusting the parser's explanation of itself.

For a concrete pilot design, suppose you choose 20 documents and annotate 200 rows. Those numbers are proposed test sizes, not research findings. Report the denominator clearly: 198 correct rows out of 200 is different from saying that 19 documents looked fine. Also track duplicated rows, missing rows, swapped columns and invented joins separately. A row can contain five correct fields and one commercially important mismatch. Averaging field correctness may hide the exact failure you needed to detect.

What this means in practice: ask a second person to check the expected answers on the risky examples, then freeze the pack while comparing tools. Keep routine and difficult layouts as separate results. Do not allow a strong score on simple pages to conceal failure on the supplier format responsible for most of your workload. Add new layouts to the pack when they appear, and rerun the relevant examples after parser, model or configuration changes. This is a business acceptance test, not a competition to produce the nicest spreadsheet.

The hardest page is more informative than the cleanest demonstration.

Validate relationships before the import can change anything

The safest place to find a misplaced row is before it enters your operational system. Separate extraction from approval and import. Keep the source file, raw extraction and proposed records available together. A reviewer should be able to move from a field to the relevant source page, and ideally the relevant cell location, without guessing which version was processed. Whether your tool exposes bounding boxes, page references or another grounding method, test that the link actually points to the right evidence.

Use deterministic checks wherever the business rules are known. Quantities should have allowed units; dates should fit the document's stated period; product codes should match a maintained catalogue when one exists. Check totals where the document supports a genuine reconciliation. A matching grand total is useful evidence, but it cannot prove that each amount belongs to the right customer. Two swapped amounts can cancel out. Likewise, a required-field check does not establish that the filled field came from the correct column.

Define exceptions explicitly. If a table continues across pages, repeated headings should not become stock items. If a product description spans two lines, those lines should not become two orders. If the unit cannot be established, keep the record in review rather than letting a model infer the most plausible one. This differs from the missing-fact problem: all the necessary text might be present, yet the relationships remain ambiguous. Preserving that ambiguity is more honest than emitting a complete but misleading row.

Nutrient's comparison advises treating confidence as a routing signal rather than a probability that the value is correct. Apply that distinction to your own approval rules. Set conservative review requirements for the consequential fields and calibrate them with observed mistakes in your acceptance pack. During the pilot, stage proposed records in a review area and leave the live import disabled. Once the checks are reliable, expand only the document classes that passed. Keep unfamiliar layouts outside automatic processing until they have earned their own acceptance decision.

A confidence score is a review signal, not permission to write.

Make the economics and accountability visible

The obvious counterargument is that this sounds like a lot of checking for a task AI was supposed to remove. It is a fair challenge. For a handful of irregular documents each month, manual entry or a desktop conversion may genuinely be cheaper. The right answer is not always a more capable model. It is the smallest dependable workflow whose total cost is lower than the current process. If extraction adds a new review queue without removing enough work, the pilot has supplied a useful negative result.

Measure time from document arrival to approved import, including corrections, exceptions and reconciliation. As an illustration, reducing extraction from ten minutes to one minute saves little if reviewers then spend twelve minutes repairing the rows. Record the number of usable records delivered, not just pages processed or files opened. Include the cost of maintaining mappings when a supplier changes its layout. A free library still requires somebody to own updates and failed jobs, while a hosted subscription does not eliminate your responsibility for destination-system rules.

Where tables contain personal data, there is also a UK data-protection dimension. The ICO's accuracy guidance says organisations should take reasonable steps to ensure personal data is not incorrect or misleading, record its source and consider challenges to accuracy. The page is marked as under review following the Data (Use and Access) Act, so check the current guidance for your deployment. This does not make every commercial table a GDPR matter; the principle becomes relevant when the rows relate to identifiable people.

Before enabling a recurring import, name the person who approves the mapping, the person who handles exceptions and the person who can stop processing. Give them access to the original evidence and a documented correction route. Agree how wrong imports will be traced and repaired, rather than assuming that deleting the extracted file reverses the downstream effect. A useful first milestone is modest: one document family, verified row relationships and a measurable reduction in end-to-end handling time. Expand from that evidence, not from a demonstration that recognised every character.

The useful saving is approved rows delivered, not pages processed.