Identify the source of truth
Write down which system owns each field and what counts as one record. A source invoice, its line items and a payment are different entities; treating them as interchangeable can create convincing but incorrect totals.
Trace one record from request to report
Capture a sanitized source response, its stable identifier, transformation and destination record. Then inspect pagination and retry behavior. In the published accounts-payable investigation, a duplicated pagination parameter was the source of repeated data.
Separate the repair from the recurring fix
Cleaning the destination without repairing ingestion allows the next sync to recreate the problem. The payment case study describes removing 2,725 surplus rows and rebuilding the sync as idempotent. Those figures describe that investigation, not a typical cleanup size.
Define what a safe rerun means
A repeated input should have a defined effect. Stable keys, explicit update rules and a record of failures help distinguish a retry from a new business event. Avoid silently skipping errors simply to make a job appear successful.
Prove the result with reconciliation
Agree on counts, unique keys, relevant totals and representative records before making changes. Compare them after the repair and again after a rerun. Retain a recovery path and a list of unresolved exceptions.
Prepare the smallest useful evidence pack
Bring schemas, an anonymized example of the mismatch, the sync schedule and relevant error timestamps. Start discovery with examples rather than production credentials or a complete customer database.