Challenge
The payment system had accumulated an operations database nobody could close a year against. Amounts across payment directions disagreed, part of the rows were corrupted, and statements for partners were assembled by hand.
You cannot settle money with a partner while looking at a database like that. First you have to prove the database is telling the truth.
Solution
The work ran in the opposite order to the usual one: audit first, corrections second, reports only after that.
The dump was imported, filtered down to the rows that mattered, and reconciled in both directions. A one-sided check only catches what is visible from one side, which is exactly why discrepancies survive for years. Once the operations table held together, reconciliation and statement generation were built on top of it.
Architecture and implementation
The pieces of work:
· import and filtering of the dump down to 212 191 meaningful rows
· an audit of the operations table broken out by payment direction
· repair of corrupted record ranges
· reconciliation of amounts per direction, with statements generated per year
One rule governed all of it: no default values anywhere in a money calculation. If a figure is missing, the calculation does not balance — nobody substitutes an average.
Result
The years from 2023 to 2026 close with statements produced by a command instead of by hand. The client did not get a report, they got a way to produce one at any moment.
This is why we mention reconciliation on every payment page of this site. A system without it learns about a discrepancy from its partner.
