Ask a finance director what makes reconciliation hard and you will rarely hear about arithmetic. You will hear about three things: too many channels, netted deposits, and reports that do not carry the fields anyone matches against.
Problem one: every channel is its own island
A jurisdiction taking payments online, at the counter, by phone and by mail is running four ledgers. Each settles on its own schedule and produces its own report, so the same day gets balanced four times and any discrepancy has four possible homes.
The fix is structural: all channels on one platform, one ledger, one report, one deposit.
Problem two: the deposit is a net figure
When a processor deducts fees before depositing, finance receives a number that matches nothing in the billing system and has to be reverse-engineered every day.
A model where the service fee is collected from the payer separately means the deposit equals what the jurisdiction is owed. The match is exact, and it is exact on the first try.
Problem three: reports carry the wrong identifiers
A transaction ID is meaningful to a payment system and meaningless to a court clerk. Reports need to carry the identifiers the receiving system uses — ticket number, parcel, account, permit, court date, subject name.
This is a configuration decision made during implementation, and it is the single highest-leverage decision in the whole project. Get it right and reconciliation is a comparison. Get it wrong and it is research.
A reconciliation readiness checklist
- Every payment channel posts to one ledger
- Deposits are gross amounts owed to the jurisdiction
- Reports carry your system's identifiers, not just the payment system's
- Fund and department codes travel with each line item
- Reporting is real time and searchable across history
- Voids and refunds are role-governed and recorded for audit
- Exports land in a format your financial system accepts without manipulation