Report field correctness without hiding document failures

Use more than one denominator

Include document failures in the report so the comparison reflects the workload your team will actually have to complete.

In ParseMill, select an extracted invoice field to inspect its source, correct the value and export the reviewed workbook. Try your own invoices as well as the interactive sample. Compare upload, checking and correction time with your current way of building the same spreadsheet.

Keep quality and coverage connected without collapsing them into one unexplained number. A document may complete technically but fail a required-field check, while another may produce a useful partial output with explicit limitations. Record those outcomes by source identifier so an aggregate score can always be traced back to individual attempts.

Work through an invented evaluation

The 76 divided by 80 score is 95%, but it does not describe all one hundred expected fields. If the evaluation counts every unreturned expected field as unsuccessful, 76 divided by 100 is 76%. State that rule explicitly rather than presenting either percentage without its denominator.

scikit-learn: Metrics and scoring emphasizes defining metrics for the application. Different denominators answer different questions and should be labeled accordingly.

Build a complete result summary

1. Count every attempted source, including unsupported files, timeouts and unreadable documents. Preserve the reason for each failure.
2. Define required fields and expected coverage before scoring. Record missing, incorrect, unresolved and unsupported-added values separately.
3. Report field results by document class and relevant field type. Include document-level usability under the stated acceptance criteria.
4. Present correction effort and remaining exceptions alongside scores when they affect the practical decision to adopt the workflow.

UK Government: Data Quality Framework distinguishes dimensions such as completeness and accuracy. Reporting both helps prevent strong results on returned fields from concealing missing coverage.

Avoid double counting and silent exclusions

A duplicated output row can inflate the number of checked fields. Match observations to stable expected records before counting correctness. Likewise, an unresolved expected reference should have a stated treatment; exclude it from exact-value scoring only with a visible count and reason.

Do not average document percentages without explaining weighting. A one-row document and a hundred-row document contribute differently to a field-weighted score, while a document-weighted score answers a different operational question.

Make the result useful for a decision

For the fixture, report ten attempts, eight outputs, two failures and 76 correct fields out of eighty checked output fields. Add the all-expected-field measure only with its explicit failure-counting rule. The recipient can then see both fidelity and coverage.

When evaluating ParseMill, keep failed and partial inputs in the report. Use transparent denominators to compare the workflow with your current process and identify where further review or source improvement is needed.