Handle a wrapped invoice description that does not fit the parser

Where the extra work starts

Test that layout before committing to a tool so you know how much correction the real invoice will need.

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.

ParseMill supports some wrapped invoice descriptions, with source evidence retained for review. Put a real wrapped row in the trial and check the complete description against the PDF. If the output joins or splits the wrong items, include the correction work when deciding whether that layout is a practical fit.

A practical way to get it right

Read the item code, description and numeric columns together. Mark where the description continues and identify the next genuine item boundary. Record the expected single item with its full source description and source page, without changing the original PDF.

When testing ParseMill or another extraction method, compare the candidate output against that expected relationship. A cleanup that joins adjacent lines must have a source-supported rule; otherwise it may combine two genuine items. Keep the initial output and the transformation note so the correction is inspectable.

Choose the next method based on the amount of work and risk of misassociation. For a few lines, reviewed manual transcription may be simpler than developing a fragile cleanup rule. For repeated layouts, a bounded trial should include several wrapped and ordinary rows, with clear failure outcomes.

Microsoft: Power Query PDF connector explicitly notes multiline-row difficulties and possible cleanup operations. Any cleanup still needs a verified row relationship; it is not automatic proof of correctness.

What this looks like on a real task

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

The source has two items, not three. The continuation belongs to B17 even though it has no repeated code or numeric values. Copy this relationship map for a test fixture. An output that creates a blank-code item for line two or attaches its wording to B18 fails the structural check, even if the numeric amounts remain correct.

Catch the cases that create rework

Do not fill down an item code across every blank cell without examining the boundaries. A blank row could be a note, a section heading or the start of an unnumbered item. Likewise, joining descriptions based only on punctuation can fail when a description contains a full sentence.

If the source relationship is ambiguous to a human reviewer, record the ambiguity and request clarification rather than making the parser's guess authoritative.

OpenPeppol: Item information separates item description from identifiers. Preserve the description’s association with the right item rather than treating each visual text line as an independent record.

Decide whether the change is worth keeping

The accepted result should preserve two item identities and the correct full description for each, with a documented review or manual correction. Count the time spent reconstructing relationships as part of the workflow effort. A fast extraction followed by extensive row repair may not be the best method for this input class.