The ledger says it happened. What can an outsider check?

A single payment of public money can cross more than one rail before it lands – a batch file settling to a bank account, an instant-payment leg completing the same obligation. The settlement receipt confirms the obligation was discharged exactly once across every declared rail leg, with a finality class echoed from the caller's own declared basis per rail.

A payment of public money is meant to attribute to a specific ministry, agency, or revenue code. That attribution is checked against the caller's own revenue-code table, and the amount credited is compared to the amount collected with every fee itemised individually. A fee silently netted out of the comparison is exactly the failure this question is built to catch.

The verdict compares amount credited to amount collected with every fee named on its own line – a fee that only shows up inside the difference, never itemised, is the specific gap this check exists to close.

A daily reconciliation attestation names its exceptions for the window it covers. Nothing in that duty forces a link between one day's named exception and the next day's population – an item can be present and flagged today, and simply absent tomorrow, with no attestation anywhere connecting the two events.

Both days pass their own attestation. The gap this question exposes sits between them, in a place no single day's duty is built to look.

A transaction log alone is not a complete trail. An administrator who edits a record, reverses an entry, or changes a permission acts on the same system a payer's transaction passes through – and if that action falls outside the logged chain, the trail has a gap an outside reviewer cannot see from the transaction log alone.

The idea this question tests is not whether payer transactions are logged – they always are. It is whether the same unbroken chain also covers what an administrator did to the record.

Salaries, benefits, or vendor payments often go out as one bulk disbursement run. This question compares the run's itemised and aggregate totals against the authorisation record. Where a mismatch appears, the receipt records it as a candidate discrepancy for a human reviewer to resolve, never as a finding of wrongdoing.

When a payment platform migrates to a new system, a matching grand total before and after proves nothing on its own – one partition can lose records while another gains an equal number of duplicates, and the aggregate check never notices. This question compares record counts partition by partition: by program, by period, by agency.

When an operator's contract ends or a platform is replaced, this question evidences a declared exit posture: which data categories are portable to the successor, which the outgoing operator retains under its own obligations, and which become stranded – inaccessible to anyone once the transition completes. The receipt evaluates that declared posture; it is not a live observation of what actually happens at exit.

What this evidences, and what it does not

Every node above computes over inputs the caller declares. Each receipt evidences that the computation ran correctly over those declared inputs – it says nothing about whether the declarations were true. The exit panel is the sharpest case: it evidences that a declared exit posture satisfies its own stated categories, not what the operator actually does with the data once the transition completes.