Building MyCase Accounting: Trust Books That Can Look Right While Being Wrong

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. Under IOLTA rules in
most US states, every client with an open matter owns a slice of one pooled
bank account, and mixing up whose money is whose is not a bookkeeping quirk.
It is the kind of mistake that gets a lawyer disbarred.

Here is the failure mode that shaped everything we built: the pooled
account's aggregate balance can match the bank exactly, down to the cent,
while one client's individual slice is wrong. The bank does not know about
client-level sub-ledgers. It only sees one account. A reconciliation 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 that happen during early testing. One firm's trust account
reconciled clean against the bank. Everyone would have moved on. Then a
client called 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. A phone call was the only
reason anyone found it.

I was the hands-on tech lead on a 6-8 engineer squad for MyCase Accounting,
the legal bookkeeping module we built on Rails from late 2021 through early

1. This post is the series map, not the deep dives. The deep dives start in Part 1.

The thesis

Three-way reconciliation is not the engineering invention. IOLTA already
requires matching the bank statement, the firm's trust ledger, and every
client's sub-ledger against each other. The real work is building a system
firms can actually run while watching closely enough to catch client-level
errors -- without drowning reviewers in false positives, and without
re-keying the same invoices and payments across two systems of truth.

Watch closely without destroying the signal. That is the series in one line.

What this series covers

Five deep dives walk the path through that problem:

1. Chart of accounts -- six legal-specific categories, with system accounts locked so billing can auto-post and compliance matching has a stable identity to hang on.
2. Three-way reconciliation -- why bank-vs-firm two-way is not enough, and why per-client sub-ledgers have to be auto-generated or the third leg never exists in practice.
3. IOLTA safeguards -- how we flagged real trust-to-operating problems without flooding the review queue (the already-written deep dive).
4. Plaid bank sync -- the For Review queue that matches feed lines to existing MyCase records without double-posting, including the trust-side rule that skips categorization entirely.
5. Billing to GL -- posting invoice and LawPay payment events into the chart of accounts at event time, so firms stop re-keying.

Expense tracking, matter allocation, and financial reporting shipped in the
same module. Those were a teammate's primary work, not mine, and they are
out of scope for this series.

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. Within twelve
months of 2022 general availability, 18% of eligible firms enabled the
module.

Those numbers matter, but they are not the thesis. The thesis is that an
aggregate can look perfect while a client's money is in the wrong place, and
that the engineering problem is how to watch for that without building a
safeguard nobody trusts.

Part 1 starts where the precision has to live first: the chart of accounts.

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