Series -- When the Aggregate Looks Right: 0: Overview · 1: Chart of Accounts · 2: Three-Way Reconciliation · 3: The Aggregate Can Lie · 4: Bank Sync · 5: GL Integration
A law firm's trust account holds other people's money, not the firm's own.
Every client with an open matter has a slice of that one pooled bank
account, and the rules governing it, IOLTA, in most US states, exist
because mixing up whose money is whose isn't a bookkeeping error. It's the
kind of mistake that gets a lawyer disbarred.
Here's the specific way a technically-correct-looking system can still be
wrong under those rules: the pooled account's aggregate balance can match
the bank exactly, down to the cent, while one client's individual slice of
it is wrong. The bank doesn't know about client-level sub-ledgers. It only
sees one account. A reconciliation system that stops at "does the aggregate
match" will pass that check every time, right up until a client asks where
their money went.
We watched exactly that happen during early testing. One firm's trust
account reconciled clean against the bank, down to the cent, and everyone
would have moved on. Then a client called to ask about their retainer,
and the firm went looking: that one client's sub-ledger was off by a few
hundred dollars. Funds that should have stayed in their slice had been
drawn against another matter. The aggregate had absorbed the error and
reported nothing wrong. A phone call was the only reason anyone found it.
I was the hands-on tech lead, on a 6-8 engineer squad, for the three-way
reconciliation system MyCase Accounting built to close that gap: matching
the bank statement, the firm's trust ledger, and every client's
auto-generated sub-ledger, all three, against each other. Three-way
reconciliation itself isn't an engineering choice. IOLTA requires it. The
real engineering decision, the one with a real rejected alternative behind
it, was narrower: once you're watching client-level balances closely enough
to catch a real problem, how do you do that without burying the two
engineers reviewing flagged transactions every day in false alarms.
Why the aggregate isn't enough
Two automated safeguards sat on top of the three-way match. One flagged any
client sub-ledger that went negative, a direct signal that money meant for
one client had been spent on another's behalf, whether by error or
otherwise. The other flagged trust-to-operating transfers, money moving out
of the pooled trust account into the firm's own operating account, that
didn't correspond to an actual invoice.
That second safeguard is where the real design tradeoff lived.
The naive version floods the queue
The first version of the safeguard flagged everything. Within a week of
internal testing, the queue had thousands of entries and nobody was opening
alerts anymore. The reason is obvious in hindsight: the overwhelming
majority of trust-to-operating transfers are completely routine. A firm
bills a matter, an invoice is generated, and the corresponding funds move
from trust to operating exactly as they should. Flagging all of it buries
the rare real problem under a flood of normal, correct activity. Reviewers
learn fast that most alerts aren't worth opening, and then they stop opening
any of them carefully. A safeguard nobody trusts isn't a safeguard.
What shipped: match against the invoice, not the amount alone
The version that shipped flags a transfer only when it doesn't exactly
match an unpaid invoice for that client. I pushed for invoice-exact
matching with no tolerance band and no approximate-amount matching, and had
to defend that: a tolerance band sounds forgiving, but it's exactly the
crack a wrong-by-a-few-hundred-dollars transfer slips through. A transfer
either lines up with a real invoice or it gets flagged. Legitimate
trust-to-operating movement, the routine case, almost always has an invoice
behind it, so it clears automatically without anyone needing to look at it.
A transfer with no matching invoice is exactly the situation the safeguard
exists to catch, an unauthorized or mistaken movement of client funds, and
it surfaces every time.
I designed the chart of accounts underneath all of this as a customizable,
legal-specific structure with billing-linked auto-posting, and that's what
made this matching possible in the first place: without a real link between
a posted invoice and its corresponding trust transaction, there'd be
nothing precise to match a transfer against.
What shipped
Firms using the reconciliation module cut trust reconciliation from roughly
6 hours of manual work a month to under 30 minutes per cycle, and 18% of
eligible firms enabled the module within its first 12 months after 2022
general availability. The unmatched-transfer safeguard's real contribution
wasn't a number on a dashboard. It was that reviewers could trust every
flag they saw, because the ones that didn't matter never showed up in the
first place.
The first time the safeguard caught a real unauthorized transfer, it was a
single flag in an otherwise empty queue, and the firm caught the mistake
the same day instead of on a client's phone call months later. That is the
whole point: the aggregate would have stayed silent, and this time someone
was watching the right thing.
The pattern generalizes past trust accounting specifically: when a
compliance requirement forces you to watch something closely, the
engineering problem usually isn't whether to watch it. It's how to watch it
without your own safeguard becoming the thing everyone learns to ignore.
Series -- When the Aggregate Looks Right: 0: Overview · 1: Chart of Accounts · 2: Three-Way Reconciliation · 3: The Aggregate Can Lie · 4: Bank Sync · 5: GL Integration
Top comments (0)