Build a repeatable invoice extraction acceptance sample

Where the extra work starts

Build a small sample of recurring suppliers and known awkward cases, then compare complete reviewed workbooks with your current process.

Upload a representative supplier invoice, inspect its extracted fields and line items beside the PDF, then download Excel. Put the awkward invoice in your trial too: the useful result is less total work after corrections.

Use synthetic or otherwise permitted material with known expected outcomes. Freeze those expectations before evaluating a changed setup so the test does not quietly redefine success to match the new output.

A practical way to get it right

Define the input boundary: native invoice PDFs or clear printed English PDF scans, supported headings, row shape and file limits. Select fixtures with leading zeros, explicit zero amounts and wider numeric values. Include wrapped descriptions, changed heading wording and a textless scan so the sample tests the variations you actually receive.

For each fixture, record expected rows, raw strings, source references and the intended outcome: accepted extraction after review, explicit exception or unsupported input. A boundary case should not be scored as successful merely because a workbook was produced.

Retain the source file identity, configuration, run date and result artifact. Review fields, row structure and evidence separately. Include manual correction and failed-attempt effort if the sample is used to assess workflow usefulness rather than only parser behavior.

Microsoft: Power Query PDF connector documents multiline limitations and page/table options. Include fixtures that expose those structural boundaries rather than testing only flat, single-page tables.

What this looks like on a real task

Synthetic example. The people, references and figures below are invented to demonstrate the method.

The sample tests five different questions. Copy the fixture, feature and expected-outcome columns and add the actual file references and expected raw output. Do not reuse the same ideal document under five filenames; variation should exercise a real boundary. A successful result on these fixtures still says nothing about untested supplier layouts.

Catch the cases that create rework

OCR-prepared files need their own verification because selectable text can contain recognition errors. Keep them outside a native-original-text claim unless the test scope explicitly includes them. A change in headers or parser version should trigger the relevant fixtures again, not only the one that previously passed.

Do not report an accuracy percentage without the tested document and field counts, and do not omit unsupported or failed fixtures from the disclosed set.

Adobe: Recognize text in scanned documents explains that OCR creates a text layer and requires accuracy review. Treat OCR preparation as a separate tested condition, not automatic evidence of native-text reliability.

Decide whether the change is worth keeping

The acceptance record should explain every fixture outcome and preserve unexpected results for investigation. Use the public invoice example and native-table evaluation to understand ParseMill's current evidence, then test your own permitted layout separately. Expand the sample when a new failure mode appears, keeping expected outputs independently reviewed rather than generated from the same parser being tested.