A Reconciliation File for a Partial Spreadsheet Export
When an export finishes with fewer rows than expected, the tempting reaction is to check the count and move on. A count only tells you something is missing, not which rows. This article proposes a simple reconciliation file that answers the specific question: which requested rows were exported, and which were not.
Capture the request before the export
Before running the export, record the identifiers you are asking for. Use a stable key such as a product code or reference, not a row position, because positions shift when sorting or filtering. Save this as the first column of a new sheet and treat it as read only from then on.
The requested, exported, missing ledger
Build a sheet with these columns: Key, Requested (yes for every row), Exported (yes, no, or unknown), Missing (calculated), Note, Next action. Fill Requested from your saved list. After the export arrives, list its keys in a second sheet and fill Exported by looking each requested key up there. Set Missing to yes where Exported is no.
Three totals belong at the top: requested, exported, missing. A check: exported plus missing should equal requested. If it does not, you have unknown rows or duplicates, and you should resolve those before anything else.
Branching choices
If the exported file contains keys you did not request, list them in a separate Extra section rather than deleting them; they may reveal that the filter differed from your intention. If the same key appears twice, mark Exported as duplicate and keep both lines. If the key column itself was altered by the export (for example leading zeros dropped), compare on a normalised version and note the change. If the export has no usable key, use a combination of columns and say so in the ledger header.
Worked example (hypothetical)
Imagine you request 12 items and the file arrives with 9 rows. The ledger shows keys A01 to A12 requested. Looking each up in the export, A04, A07 and A11 do not appear. Totals: requested 12, exported 9, missing 3, and 9 plus 3 equals 12. Looking at the three, you notice all three share a field that was empty in the source. That suggests a possible cause worth testing, not a conclusion. Your next action for each is to re-export only those three, then add a second Exported column for the retry, rather than overwriting the first.
Stop conditions
Stop and do not pass the file on if the totals do not balance, if the missing rows cannot be listed by key, or if a retry returns rows that differ from the original in a way you cannot explain. Pause also if the missing rows seem to follow a pattern you were not expecting, since a hidden filter may be at work.
Acceptance checks
The requested list was saved before the export; every requested key has an Exported value other than blank; the three totals balance; extras and duplicates are recorded; each missing row has a next action; and the ledger is kept alongside the export under a name that links the two. A reader who has never seen the export should be able to tell from the ledger alone which rows are present. This process does not diagnose why rows are missing, and it makes no promise about completeness beyond the keys you listed.