Data that arrives after the reporting period

A transaction dated March 31 reaches a pipeline on April 2. A view of March activity may include it under its event date. A load-monitoring view should show its April arrival. The two dates describe different parts of the record's history.

Overwriting the event date with the extraction date removes information. Overwriting the arrival metadata with the event date hides the fact that the source supplied it later. The analytical environment should retain the distinctions it needs to explain a changed report.

This hypothetical example concerns data processing. It does not decide an accounting policy or whether a business should reopen a financial reporting period.

Some reporting processes recalculate a recent window when new data arrives. Others preserve a published version and make subsequent adjustments identifiable. Different outputs from the same source can legitimately follow different rules.

The model should implement that choice rather than inherit it accidentally from an extraction filter. Reading only records with a recent event date can miss a late first arrival. Reading a source modification timestamp may catch it, but only if the source updates that field reliably for the relevant change.

Where the source offers neither a change history nor dependable update metadata, the pipeline may need a wider comparison. The cost and limitations of that approach belong in the design.

A late first arrival introduces a record that was not previously available. A correction changes a record already loaded. An unchanged replay supplies the same information again. Treating all three as an additional new transaction can inflate the result.

A stable source identifier helps distinguish them. The destination also needs a rule for which fields are updated and whether earlier values must remain available. An identifier that changes between exports cannot be assumed to identify the same event.

We test these cases with representative source behavior, including what happens when a batch stops partway through. A recovery should have an explainable effect on the analytical output, rather than relying on an operator to remember which rows were already processed.

When a later load changes an earlier report, a reader needs enough context to identify what moved. That could include the affected period, the source update and the refresh at which it became available.

Keeping published extracts or versioned model output can support that explanation when the reporting process needs it. Retaining every intermediate copy is not automatically the right storage policy. The requirement should follow the comparison the business needs to make.

A practical reconciliation can show the previous included records, the additions or corrections, and the resulting difference. The business can then distinguish new information from a revised calculation.