Case study
Five payment paths, one ledger.
Card, eCheck, bank transfer, peer-to-peer and paper cheques all arrived differently, and were matched to clients by hand every week — by someone whose job was not data entry.
The problem
Money reached the firm on five rails with nothing in common. Two produced a gateway record. Two produced only an email receipt. One produced a piece of paper. Allocation — deciding which client a payment belonged to — was manual, weekly, and the single most error-prone recurring task in the business.
The complication that defeats naive matching is simple to state and hard to solve: the person paying is frequently not the person on the file. A parent pays for an adult child. A new partner pays. The name and the email on the payment belong to neither the matter nor the client.
What was built
- One ingestion path for all five methods, each idempotent on the gateway's own transaction identity
- A resolution ladder that auto-allocates only where the evidence is unambiguous, and escalates to a person where it is not
- Payer aliases, so the third time a particular parent pays, the system already knows
- A nightly reconciliation against the systems of record, which messages one person when they disagree rather than producing a report
The failure we designed for
Two systems polling the same payment gateway will each report every charge, and a ledger that merges on amount and date will merge two genuinely separate instalments. This firm bills identical amounts days apart, routinely. So merging happens only on a system-issued identity, never on a heuristic, and a manually entered payment is never auto-merged at all.
Reconciliation is not a report you run after the integration. It is part of the integration, and if it is not in the budget the integration is not finished.
Want to know whether this applies to your firm?
Thirty minutes, an honest read on where your friction actually is, and a recommendation. If we are not the right fit, we will tell you.
Book an Operational Strategy Call