Does your finance sync capture corrections and deletions?

A sync can collect every newly created invoice and still miss a correction to an older one. Before treating an incremental copy as current, identify the signal it uses to find changed records. A creation date, a modification date, an increasing version number and a database change feed answer different questions. Match that signal to the finance report's needs, including amendments, cancellations and deletions where the source permits them.

Microsoft Fabric's documentation gives a useful concrete distinction. Its watermark-based approach reads values beyond the last saved watermark and cannot detect deleted source rows. Its supported change-data-capture approach can carry inserts, updates and deletions. Other connectors have their own contracts. Ask for the actual behavior of yours, then test it. A label such as real-time or automatic does not explain how an edited prior-period record reaches the destination.

The accounting date tells the report which period a transaction belongs to. The change date tells an extraction process that a record was modified. If a supplier bill dated September is corrected in November, a query limited to November accounting dates will not necessarily find it. Keep both concepts in the dataset. The reporting owner should decide how an approved correction affects prior reports, while the connector should preserve evidence of the change.

List the record types that can change after creation and the fields relevant to your reports. Customer names, invoice amounts, payment applications, tax codes and account mappings may follow different update mechanisms. A connector that refreshes the invoice total but leaves its line items unchanged can create a contradictory record. Include dependent collections in the review. Treat the parent and its details as related evidence, not as separate successes that can be accepted without comparison.

Also distinguish a deleted record from an inactive master record or a voided transaction. Those states can have different business meanings and reporting consequences. The target must represent the source's documented state without silently erasing history that the business needs. Ask the accounting owner how each state should affect current reporting and historical evidence. Do not make a legal retention decision by copying whatever a connector's default delete option happens to do.

Use a nonproduction environment with known records. Create a transaction, run the sync and confirm the target. Then amend an allowed field, apply a partial payment, change an associated reference and exercise a supported cancellation or deletion case. Run the sync after each change. Compare the actual target record and report result with the expected behavior. A test limited to adding one new invoice proves very little about ongoing synchronization.

For an illustrative test, create an invoice for $1,000 and later correct it to $900 through the source's permitted process. The current-view destination should show the approved $900 obligation, while an audit-oriented history should retain the fact and timing of the change if that is its purpose. An append-only destination that now sums both versions to $1,900 is wrong for a current balance report. A replacement that removes every trace of the original may be unsuitable for a change-history report.

Test the boundaries of the change signal. Include two changes with the same timestamp precision, a record whose change field is missing, and an interruption between reading and saving a batch. Do not manufacture these conditions in production. Ask the integration owner to explain how the chosen connector handles them and retain the observed result. Where the source cannot support a reliable incremental signal, design an explicit reconciliation or refresh process instead of promising complete updates.

A current-state copy usually needs to replace or merge the relevant record version using a stable source key. A historical store needs a way to distinguish successive versions and their effective times. Either design can be useful, but a report must know which one it reads. Document whether rows represent current invoices, events or versions. Otherwise a later analyst may add together all versions and mistake the result for revenue or receivables.

Keep deletion and reversal evidence separate from physical removal wherever the reporting and retention design requires it. A source deletion event may tell the warehouse to exclude a record from a current view while retaining a restricted change history. A void or credit can instead be a separate accounting event that needs its own treatment. Verify those differences against the source application's supported behavior and the company's accounting policy rather than translating every state to a negative amount.

Define how a full reload interacts with existing destination data. Resetting a watermark does not necessarily clear a target table. If the destination appends, a reload can duplicate the entire population. Before recovery, identify whether the target merges, replaces or accumulates data and how its keys work. Use a staged copy and compare results where possible. Never truncate an authoritative ledger or an audit archive merely to make a connector's restart easier.

Reconcile current counts and relevant totals with the source on a schedule that fits the reporting risk. Include older periods that remain editable. Track the age of the latest processed change and unresolved exceptions, not only the last connection time. A connector can authenticate successfully while processing nothing useful. A sudden absence of changes may be valid, but the status should be supported by the actual source population and the extraction result.

When drift appears, preserve the last trusted checkpoint and identify the first affected records. Repair the missing changes through the supported recovery route, then rebuild reports derived from the incorrect version. Record whether the cause was a source limitation, an unsuitable watermark, a failed update or a target mapping defect. Repeat the relevant change test after the fix and retain its evidence with the connector's ownership and maintenance record.