Reconciliation views should follow the obligation

What the public implementation shows

GovPayments provides authority-scoped payment and reversal views with filters for UPR, invoice, transaction IDs, MDA, service, revenue account, and account number, plus bounded CSV exports.

The reconciliation module joins financial events back to bills and configured revenue accounts instead of exposing isolated payment rows. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleA transaction list becomes reconciliation only when it preserves the government obligation and its accounting destination.

The decision behind the mechanism

Separate payment and reversal projections retain their own identifiers and times while sharing the obligation dimensions required by government finance teams.

A flat transaction export can balance technically yet leave operators unable to explain which service, authority, or account received the funds. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Enforce authority scope before applying filters.
• Join to the bill and active revenue-account identity.
• Keep payment and reversal identifiers distinct.
• Bound exports and escape CSV values safely.

How the control should be operated

Reconcile by authority, period, currency, obligation, revenue destination, and lifecycle event, with export limits and access controls documented.

Finance and operations can trace collected and reversed value from payment rail identity back to the originating bill. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.