data import reconciliation checklist
A data import reconciliation checklist proves that the destination received the intended records and values, not merely that an upload finished. It ties each batch to its source, expected totals, mapping version, rejected rows, corrections, reviewer, and final disposition. Operations teams can use that record to prepare evidence and route exceptions while an authorized owner decides whether the imported result is acceptable.
The checklist should begin before anyone loads a file. Capture the source extract, define the comparisons that matter, and agree on what stops the import. After the load, compare the source and destination at both batch and record level. Keep unresolved differences open. A successful system message is useful evidence, but it is not reconciliation by itself.
Fix the comparison before moving data
Write down what the import is supposed to preserve. The answer may include a record count, a monetary control total, a set of unique identifiers, or the presence of required fields. Use only controls that fit the actual data. A row count cannot prove that amounts remained intact, and a matching total can hide offsetting errors.
Name the source of truth for every comparison. If a report is the approved source, record the report name, covered period, run time, filters, and stable storage location. If the team exports a file, retain an approved reference to that exact extract. Do not overwrite it with a corrected version after the load. The original and corrected files answer different questions.
Decide how the team will identify a batch. A practical batch ID connects the request, source extract, import attempt, reconciliation record, and approval. It should remain stable when a failed attempt is rerun so the history stays together, while each attempt receives its own timestamp or sequence.
Set stopping rules here, too. Missing source approval, an unexplained change in extract scope, a mapping that has not been reviewed, or an unexpected file format should stop preparation. The coordinator should record the precise gap and route it to the named owner rather than guessing how to proceed.
Record the source without copying it everywhere
The working checklist needs enough context for another trained person to find the evidence. It does not need a second uncontrolled copy of every source file. Store restricted material in the approved system and use a safe reference in the reconciliation record.
NIST SP 800-47 Rev. 1 addresses protection of information before, during, and after an exchange and says organizations should tailor that guidance to their own needs and requirements. That makes it a useful security reference for an import process, although it does not decide accounting, privacy, retention, or legal rules for a particular organization. Apply those rules with the responsible owners. See NIST SP 800-47 Rev. 1.
At minimum, the source section should identify:
| Field | What to record | Why it matters |
|---|---|---|
| Batch ID | Stable identifier for the requested import | Connects attempts and evidence |
| Source reference | Approved location and file or report name | Lets a reviewer find the exact input |
| Extract scope | Period, filters, entity, or population | Defines what the controls cover |
| Extract time | When the source was produced | Separates one version from another |
| Expected count | Source record count, when relevant | Supports a batch-level comparison |
| Expected total | Approved control total, when relevant | Tests value preservation |
| Mapping version | Reviewed field mapping used for the run | Explains how values should move |
| Request owner | Person authorized to resolve scope questions | Prevents informal decisions |
Treat blanks as visible conditions. If a total does not apply, record that it is not applicable and why. An empty cell is ambiguous: it might mean unavailable, forgotten, or irrelevant.
Inspect mappings before the first attempt
A usable mapping says where each destination field comes from and what transformation is permitted. Direct copies should be distinguishable from calculated, normalized, defaulted, and manually supplied values. Later, that distinction helps the reviewer diagnose a difference without retracing the whole load.
Before import, compare required destination fields with the source. A missing required value needs an approved rule. The record might be rejected, routed for completion, or populated with an authorized default. A coordinator can flag the condition and assemble examples, but should not invent that rule.
Check identifiers with extra care. Leading zeros, date formats, character encoding, duplicate keys, and whitespace can alter a value without creating an obvious load failure. Use a small test batch when the mapping is new or has changed. Compare a few known records field by field, including at least one awkward case, before expanding the run.
The mapping needs its own version history, separate from the data. A rerun with a changed mapping is a new attempt even if the source extract stays the same. Its record should name the reviewer and the problem the change was intended to correct.
Reconcile at batch and record level
Begin the post-load review with batch controls. Compare expected and imported record counts. Compare approved totals where they make sense. Confirm that the destination reports the same scope and period as the source. Record the observed values, not only a status such as "passed."
Then inspect record-level results. Capture rejected rows, skipped rows, duplicates, and fields changed by transformation. Sample accepted records across ordinary and unusual cases. The sampling rule should be written before the review so it does not quietly narrow after a problem appears.
A reconciliation difference needs its own line. Include the record or safe reference, control affected, source value, destination value, reason if known, assigned owner, next action, and current status. Do not erase the original difference when it is corrected. Add the correction evidence and retest result.
Use statuses that describe observable states. "Waiting for source owner" is clearer than "in progress." "Correction loaded, comparison pending" tells a backup what remains. Reserve "reconciled" for a batch whose required comparisons passed and whose exceptions have approved dispositions.
Route exceptions by cause
Different failures need different owners. A source omission belongs with the source owner. A mapping defect belongs with the person authorized to maintain the mapping. A system rejection may need technical review. A duplicate or conflicting business record may require an operational decision.
The coordinator can collect the evidence, classify the visible condition under an approved taxonomy, and route it. The coordinator should stop when classification requires interpreting policy, choosing between conflicting records, changing a financial value, or approving a permanent data change.
An escalation packet should include the batch ID, affected records, failed comparison, relevant source and destination references, mapping version, actions already attempted, and the exact decision needed. Avoid forwarding a large message chain with "please advise." The owner should not have to reconstruct the import to understand the question.
Keep corrected and rejected items distinct. A rejected item never entered the destination. A corrected item did enter, then required another action. Their operational impact and evidence differ, so combining them under a generic error count weakens the review.
Close the batch with evidence
When the organization's process separates preparation and review, a different authorized person completes the final check. That reviewer confirms that the required controls were used, exceptions have dispositions, corrections were retested, and the destination result matches the approved acceptance criteria. The record shows who completed the review and when.
A calendar cutoff does not resolve an open difference. The batch remains rejected, conditionally accepted under a documented owner decision, or pending. The checklist records that disposition without granting the coordinator authority to choose it.
Retain references to the final source extract, import output, reconciliation detail, exception log, mapping version, and approval in the location required by the organization's policy. Avoid putting passwords, credentials, or unnecessary personal information in the checklist.
Closure can also leave useful follow-up work. A recurring rejection may point to a source validation problem. Repeated manual corrections may show that the mapping or intake instructions need review. Those observations belong in the normal change process, not in an unrecorded edit to the checklist.
Test whether another person can continue
Coverage is part of control design. Give an open reconciliation to a trained backup without an oral briefing. The backup should be able to locate the source, identify the latest attempt, see which controls passed, find open differences, and name the person who owns each decision.
If the backup cannot continue, revise the record before increasing volume. Common gaps include links that work only for one user, unexplained abbreviations, status notes without dates, and corrections that overwrite earlier evidence. Fix the handoff at the source instead of adding a second private tracker.
Review access at the same time. The people preparing comparisons need only the systems and fields required for that work. Approval, mapping changes, and irreversible destination actions can remain with designated owners. Remove access when coverage changes, and never use shared credentials to make a backup arrangement easier.
Delegate the repeatable preparation work
The best work to delegate is explicit and reversible: checking intake completeness, recording source controls, preparing comparison files, logging rejected rows, following up on missing evidence, and assembling exception packets. Keep acceptance decisions, policy interpretation, mapping approval, credential management, and irreversible changes with authorized staff.
Start with one import type and a written checklist. Review the first batches closely, including the difficult ones. If the process depends on recurring file preparation, record comparison, and exception follow-up, HireBackOffice data entry specialists can provide dedicated administrative capacity inside the controls your team defines.
Use the virtual assistant access checklist when defining system permissions, and review document management support when import work depends on controlled source files. Every imported batch should leave a traceable path from its approved source to the reviewed destination result. Contact HireBackOffice to discuss a recurring administrative support role.