Test Whether an Integration Check Detects Missing Records

An integration check reports three records in each system and marks the transfer complete. Yet the source contains R101, R102 and R103, while the destination contains R101 twice and R103 once. The totals agree; R102 is missing.

This fictional example is a useful acceptance test for a reconciliation check. Instead of waiting for a customer to discover missing work, give the check a small set of deliberate defects in a test environment and verify its findings. The exercise below assumes one source record should produce one destination record.

Define the comparison contract

Choose one organization, one record type and one bounded source window. Specify which source timestamp selects records, its time zone, and whether the start is inclusive and the end exclusive. Record any excluded statuses. Use stable source IDs and the destination's stored source reference to match records; matching names alone can confuse two different requests.

Keep the first fixture fixed while comparing it. For a live check, record extraction times and versions or snapshot references when available. If records change during collection and comparable observations cannot be established, classify the run as inconclusive. A time filter alone does not freeze either system.

Confirm that both extracts include every required page and that the reader has the intended organizational scope. A failed read must not become an empty list. Otherwise, an access problem can look like mass deletion or a clean result.

Compare identity and meaning

AWS DMS documentation illustrates row-level validation: the service compares source rows with corresponding target rows and reports mismatches. It also distinguishes pending and suspended validation. That is a specific migration feature, not evidence that an arbitrary business integration already performs these checks.

For this proposed one-to-one workflow, report source IDs absent from the destination, repeated destination references, unexpected references, and differences in selected mapped fields. State how transformed values should compare. For example, two different status labels may legitimately represent the same agreed business state.

Give the check deliberate defects

Start with synthetic source records R101, R102 and R103 and a matching destination. Reset to that baseline before each variation so the expected finding remains unambiguous.

1. Healthy baseline: each source ID appears once at the destination with the expected mapped fields. The report lists no discrepancies for this fixture.
2. Equal totals, missing record: omit R102 and add a second destination record referencing R101. The report must identify both the missing ID and the duplicate reference.
3. Wrong field: retain all three IDs but assign R103 an incorrect mapped status. Identity matching must not hide the field mismatch.
4. Unexpected record: add R999 with no eligible source counterpart in the fixture. The report should flag it for investigation, not delete it.
5. Incomplete observation: make one test extraction fail or stop before its last page. The run must show incomplete evidence rather than a successful comparison.

Separate delayed from unresolved

Run another variation in which R102 is intentionally delayed. Define the expected delivery window with the integration owner, then check once within that allowance and again after it. Record the actual observation times. Within the allowance, label it pending; beyond it, flag an overdue discrepancy for investigation. Neither label alone proves permanent data loss.

Stripe documents automatic delivery retries and warns that event delivery order is not guaranteed. Your own provider's behavior must be verified separately. A quiet error log does not establish that every expected business record reached its destination.

Prove detection before attempting repair

For each variation, save the fixture version, comparison scope, expected findings, actual findings and reviewer. After a developer corrects the test data through the approved test workflow, rerun the same scope and confirm that the relevant discrepancy clears without hiding another one.

Keep production reconciliation read-only until a separate repair policy defines ownership, authorization and duplicate protection. A report should direct someone to evidence, not silently overwrite manual work. Assign an owner and next review time to unresolved items.

Review an integration reconciliation test with Dynelink and bring one record mapping plus examples of missing, repeated or delayed work you need the check to detect.

AI-generated conceptual illustration; not a client screenshot.