Decide what one invoice extraction row should represent

Where the extra work starts

Decide what one row means before extraction so the workbook fits the task you need to finish.

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.

This is a transcription model, not a decision about how charges should be booked or paid. Preserve the source's distinctions and route unclear meanings to the responsible reviewer.

A practical way to get it right

Inspect the whole invoice and identify where the item table begins and ends. Write down the required columns and what each means on this document. Distinguish item identifiers from line numbers and document identifiers. Keep a document context record that can be joined to every extracted line through a stable source reference.

List summary rows and notes that should not become ordinary items. A subtotal, tax summary and amount due can be retained separately for review without inventing quantities or descriptions to make them fit the item schema. If the source includes a delivery charge as an actual item line, preserve it according to the defined boundary.

Count expected item lines before reviewing output. After extraction, compare every row with its source and record excluded content explicitly. A row model is useful only if another reviewer can reproduce the inclusion decisions.

OpenPeppol: Invoice line syntax provides a structured example of distinct line identifiers, quantities and item details. Use that distinction as a modeling aid; an arbitrary PDF is not thereby certified as Peppol-conformant.

What this looks like on a real task

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

The fixture has four item rows even though the page contains additional numeric lines. Delivery remains an item because that is how this invented source presents it, and its explicit zero must not become a missing value. Copy the source-element and treatment columns into an inclusion map before building a register.

Catch the cases that create rework

A wrapped description may occupy two visual lines but still describe one item. Do not count visual baselines as independent items without checking their relationship. Conversely, repeated item codes can represent separate source rows and should not be merged automatically.

If the document's layout does not support a reliable row boundary, stop the bounded extraction attempt and use reviewed manual transcription or a suitable alternative. Do not force prose or summaries into the item table.

OpenPeppol: Invoice syntax separates document totals from invoice lines. Preserve that difference in your register instead of treating every printed monetary line as an item.

Decide whether the change is worth keeping

Reconcile expected item count, observed rows and documented exclusions. Check that every output row has a source-document reference and that document-level facts have not become fabricated line values. The result should make the source easier to inspect while preserving ambiguity. A spreadsheet that opens successfully is not evidence that its row model is correct.