Reconcile invoice line counts before trusting an export

Where the extra work starts

Count what was purchased and compare it with the export so you do not trade retyping time for a hidden completeness problem.

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.

The count is a structural check, not proof that the values are correct. Follow it with field-level review and keep document summaries, repeated headers and genuine items distinct.

A practical way to get it right

Inspect each source page and list the item range or identifiable item references. Record expected item count, repeated headings and any continuation that spans pages. Do not count every visible text line as an item when descriptions wrap.

Compare the output by source page or source location. Mark each expected item as found once, missing, duplicated or unresolved. Investigate differences using the original PDF and extraction evidence. If a row is manually recovered, retain the source and correction note rather than silently increasing the count.

Check the reverse direction too: every output row should map to an expected source item. An extra subtotal or repeated header can offset a missing item numerically, leaving the total count apparently correct. Identity matching is therefore necessary alongside totals.

Microsoft: Power Query PDF connector offers page-range and multi-page table options. Record the actual pages examined so an omitted range cannot masquerade as a complete invoice.

What this looks like on a real task

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

The overall count agrees, but page two loses an item and page three adds a false row. Copy the page-level table and add the specific missing or unexpected references. Correcting only the total would miss both errors. After recovery and exclusion, verify that the nine accepted rows correspond to the nine genuine items.

Catch the cases that create rework

If the PDF has a continuation table without recognized headers, the bounded ParseMill workflow may not capture it reliably. Record the unsupported section and choose a reviewed recovery method. Do not assume the last processed page is the last source page containing items.

A duplicated item code is not automatically a duplicated row. Use source document, page and line relationship to distinguish legitimate repetitions from repeated extraction.

OpenPeppol: Invoice line syntax defines line identifiers within an invoice. Preserve source line identity where available rather than relying only on the number of extracted rows.

Decide whether the change is worth keeping

Close the structural review only when every expected item is accounted for and every output row has a supported identity. Keep unresolved rows visible in an exception log. Then check raw values and export behavior separately. The line-count reconciliation should remain reproducible from source evidence even after someone sorts the workbook.