A posted transaction is missing from the report: check replica lag

A user can see a posted receipt in the accounting application while a reporting query still shows the invoice as unpaid. Before posting the receipt again, ask whether the application and report read the same database. A reporting copy may be behind even though the original transaction completed successfully.

Capture the transaction identifier, source posting confirmation and report run time. Ask the technical owner to identify the actual reporting endpoint, including whether a proxy can route different requests to different copies. A familiar database name in a connection setting is not enough to establish which state answered the query.

PostgreSQL's hot-standby documentation explains that data takes time to arrive from the primary server, so nearly simultaneous queries on primary and standby can differ. A committed change becomes visible to new standby snapshots after its commit record is replayed. That behavior explains one possible delay; it does not prove that every missing report row is awaiting replication.

Map the remaining stages: source database, reporting copy, transformation job, cached dataset and displayed report. Each may have its own completion boundary. A replica that has caught up cannot refresh an already extracted spreadsheet, and a newly refreshed chart can still be based on an old imported dataset.

Ask for the last confirmed data boundary at each relevant stage. The time a dashboard page opened or a refresh job started is different from the point through which source changes were included. Keep those meanings explicit in any freshness label shown to finance.

An operational trend report may tolerate a documented delay. A payment release decision or final close reconciliation may need evidence that particular transactions are included. Name the business requirement before choosing a technical response, and give users a clear waiting or exception status when it is not met.

For a close pack, identify an accepted source boundary and ask the technical owner how the reporting copy proves it has reached that boundary. Avoid inventing a universal acceptable lag in seconds. The useful threshold depends on the report, transaction flow and deadline.

If the business needs an alternative read route during an incident, have the system owner assess permissions, load and consistency before switching. Pointing every report at the production writer can create a different operational problem. Record the approved fallback and when the normal route may resume.

Use an authorized test or a known real transaction that the reviewer is permitted to inspect. Record when it appears at each reporting stage. Compare its identifier and final values, including any later correction, rather than relying only on a total that may change for unrelated reasons.

Test the report's stale-data behavior as well. It should not present an incomplete population as a current final balance merely because the query succeeded. Ask what happens if replication stops, a transformation fails, or the report remains open across a refresh.

When the missing record arrives, confirm that the original posting appears once and that the reconciled balance now includes it. If it remains absent after the accepted boundary has passed every stage, investigate filters, mappings and extraction failures instead of continuing to attribute it to ordinary lag.

Retain the measured delay, affected outputs and correction to any misleading freshness label. The useful outcome is a report whose age can be explained and whose release condition matches the decision it supports.