Record an invoice extraction correction with its source

Where the extra work starts

Make the correction during review so the exported workbook reflects the decision instead of requiring a separate cleanup trail.

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.

Keep raw transcription and derived calculations distinct. A source-backed correction repairs the representation of the document; a business decision about what the value should mean requires its own authority and explanation.

A practical way to get it right

Identify the exact source occurrence and field. Record the original extracted string and inspect the visible source before editing. Enter the corrected raw value only when the source supports it. If the source itself is ambiguous, keep an unresolved note instead of converting a guess into a confident cell.

Record reviewer, time, source page or evidence reference and a concise reason. Classify the change as extraction correction, permitted normalization or separate interpretation. Preserve the previous output revision where the workflow supports it and ensure the final export corresponds to the reviewed revision.

After correcting one cell, inspect neighboring rows and similar fields for a systematic problem. A lost leading zero or missing minus sign may affect more than the first discovered case. Keep any broader correction rule explicit and verify its scope against the source.

Microsoft: Get help with Show Changes documents supported cell-change tracking and possible gaps. Keep an explicit source-backed reason rather than assuming the Changes pane is a complete review record.

What this looks like on a real task

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

This correction restores a source string; it does not invent a standard width for all item codes. Copy the record fields and add the actual revision identifier and review date. If other codes legitimately have different lengths, preserve them rather than applying the same padding rule across the column.

Catch the cases that create rework

Spreadsheet change history can be incomplete depending on application and editing route. Do not rely on it as the sole explanation for a consequential correction. A visible history entry may show the value changed without explaining why the source supports the new value.

If a later source revision arrives, recheck affected corrections. A correct transcription of the old document may no longer be the current evidence, but the old decision should remain understandable.

Microsoft: Restore a previous OneDrive file version supports earlier file versions where available. Preserve the reviewed revision and inspect version context when a later source or output replaces it.

Decide whether the change is worth keeping

Export the reviewed revision and compare the corrected field after re-import. Confirm that the correction note remains accessible to the receiving reviewer and that the original source reference still works. A useful correction trail lets someone reconstruct what changed and why, while making unresolved source questions visible instead of polishing them away.