Compare page coverage after changing extraction settings

Change one factor and preserve both outputs

Compare coverage as well as appearance so the new run is genuinely more usable than the output it replaces.

For multipage invoices, use ParseMill to review extracted invoice data beside the source and export separate summary and line-item sheets. Include a page break in your trial and check that every required line made it through. Other report types need their own fit assessment.

Define what counts as a row before comparing. If one run joins continuation fragments and another leaves them separate, raw line counts measure different things. Keep raw fragments available and compare reconstructed business records separately.

Read this synthetic coverage diff

Both invented runs contain twelve records, yet their coverage differs. The after run adds A5 and removes B5. Even page 4 needs a field comparison because identical identifiers do not guarantee identical values, units or source references.

Microsoft: Pdf.Tables documents options including page bounds and multipage table handling. Record the exact option changed, alongside the tool version and source identity, so the comparison can be repeated.

Build a reviewable difference set

1. Define a stable key using source segment, physical page and reviewed record identifier. Keep ambiguous keys in a separate unresolved list.
2. Classify records as unchanged, added, removed or changed. For changed records, list the fields that differ instead of replacing the earlier value silently.
3. Inspect every added and removed record against the source. Review field changes and their neighbors where alignment may have shifted.
4. Choose the preferred run only after checking the full affected scope. If neither is acceptable, document a controlled correction or keep the issue unresolved.

Microsoft: Table.RowCount provides a row count useful for reconciliation. Use that count alongside the keyed difference set; neither a larger count nor an unchanged count is itself a quality score.

Keep the comparison fair

Do not compare one run against an edited source and attribute all changes to the setting. Likewise, a manually corrected output should be labeled as such. Record corrections separately from parser behavior if the purpose is to decide whether the new setting helps.

If a setting changes detected table boundaries, retain a mapping from old ranges to new ranges. Otherwise, a renamed table may appear entirely removed and re-added, obscuring the actual observation-level changes that need review.

Write the decision and its limits

For the fixture, investigate A5 and B5 before accepting the new run. If A5 is real and B5 was wrongly lost, the new configuration has a mixed result that requires further work. Record the pages and fields checked, unresolved issues and the chosen output revision.

Use the same invoice PDFs and acceptance checks when comparing ParseMill with your existing extraction method. Keep the worksheet alongside both outputs, including any missing rows and the time needed to repair them, so the choice reflects the complete job.