Data reconciliation is the check that a target dataset matches its source after data moves: the same records, counts and amounts, with nothing missing and nothing counted twice. After an ERP backfill, reconcile the repaired population to the source reference before you rerun findings. A backfill that re-sends imported records turns missing history into duplicated activity.
A missing month turns up during a supplier-credit review. The source owner runs a backfill, more records appear and the team gets ready to rerun the findings. This worked example uses illustrative figures and prescribes no query or correction method for any particular ERP.
Preserve the population you intended to import
Keep a source-generated reference for the selected entity, currency, period and filters, and record what a row represents. An invoice header and a payment allocation are different units, so their counts do not compare.
Keep the first import version too. It shows which records the first evaluation saw and which findings might need revision.
Here the reference holds 1,240 allocation records with application amounts totalling $3,100,000. The first import holds 1,180 records and $2,940,000. The missing December slice holds 60 records and $160,000.
These totals describe the whole allocation population, separate from the single supplier credit examined later.
Data reconciliation: compare the backfill to the source reference
The backfill adds 80 records worth $205,000. Twenty of them, worth $45,000, overlap the first import.
| State | Records | Application amount, USD |
|---|---|---|
| Source reference | 1,240 | $3,100,000 |
| Initial import | 1,180 | $2,940,000 |
| Backfill added | 80 | $205,000 |
| Raw combined population | 1,260 | $3,145,000 |
| Verified overlap | 20 | $45,000 |
| Reconciled unique population | 1,240 | $3,100,000 |
The reconciliation is 1,180 + 80 − 20 = 1,240 unique records. The amounts reconcile the same way: $2,940,000 + $205,000 − $45,000 = $3,100,000.
Keep the raw backfill as evidence of what the repair supplied, beside the identity-based reconciliation, so someone else can reproduce the change.
Resolve overlap using source identities and version rules
Two equal amounts do not prove duplication. Separate partial applications can share an amount and an invoice reference. A changed record can keep its source ID while its newer version still needs to be represented.
Have the source owner identify the stable record keys and how the interface handles updates. Classify rows as new, repeated, changed or unresolved under that source’s rules, and keep the basis for each exclusion.
This step reviews the imported evaluation dataset. Removing an overlapping imported row leaves the source journal, the balance and the accounting record untouched. If the source itself is wrong, the accounting owner runs a separate correction process.
Check relationships after counts and totals agree
Matching the reference settles this numerical comparison. Further checks show whether the records support the duty.
Inspect the credit-to-application links and legal-entity boundaries. Confirm that the event history runs through the review cutoff, that late changes appear and that your intended reviewer can open the support.
Matching totals can hide offsetting errors: one missing record and one duplicate of equal amount still agree. Retained identifiers and relationship checks expose that problem.
Keep a separate accounting disposition. The systems owner explains the repair, and the accounting owner decides which conclusion the evidence supports.
Revisit the finding that depended on missing history
Illustrative credit CN-410 has an original value of $20,000. A restored December allocation shows $14,000 applied earlier, and $6,000 may remain, subject to other checks.
Before the history arrived, the team had no supported remaining amount. The revised explanation names the restored application and keeps the earlier output with its limitation.
Find the other outputs that used the repaired population, since AP packets and close reviews might have consumed the same history. Record what you reassessed, who received the revision and what stays open. A reviewer’s downloaded packet stays as it was until someone sends the revision, and an approval given on the earlier version needs the same attention; human approval tied to a packet version covers that case.
Leave a record the next source change can use
Keep the reference population, first import, backfill run, overlap rules and revised comparison. Add the accounting disposition and the owners of any remaining gap.
Repeat the checks when the extraction range or source logic changes. A repair proves what you checked for that version and scope, and the next import needs its own check. The wider readiness review, checking the history behind a finance answer, sets the questions those checks answer.
Rever’s zero-day scan follows the same rule on connected data: it includes every in-scope transaction in the connected population in the relevant checks, and missing sources stay visible beside the initial findings. The Explore Rever page on the zero-day scan explains how.
Record the duty, supported conclusion and missing evidence in the Check the History worksheet, and attach the backfill comparison so the technical repair and the accounting decision stay connected.
For one finance conclusion, What Does This Import Support? records which evidence supports it, the gaps that remain and the next step your team chooses.
