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

#rails #backend #legal #fintech

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

The call came in mid-morning. A firm had reconciled their trust account the day before. Bank balance matched the firm ledger to the cent. Books were closed for the month.

The client calling was asking about their retainer. The paralegal pulled up the matter. The trust sub-ledger for that client showed a balance several hundred dollars lower than the client expected. Funds meant for one matter had been drawn against another. No one had noticed because the aggregate absorbed the error. The bank only ever showed one pooled number.

That failure mode is not a bug in someone's arithmetic. It is what happens when you watch the wrong thing. A pooled IOLTA trust account hides client-level movement inside an aggregate that can reconcile cleanly while individual slices are wrong. The aggregate can lie.

The problem IOLTA creates

IOLTA stands for Interest on Lawyers' Trust Accounts. Most states require attorneys to hold unearned client funds in a pooled trust account rather than the firm's operating account. Retainers go in. Invoices draw against them. The interest goes to a state bar fund.

The pooled structure creates an accounting problem the bank cannot solve. The bank sees one account. The firm has obligations to dozens of clients, each with their own retainer and their own matter. State bar rules require firms to know, at any point, exactly how much of that pooled balance belongs to each client. A discrepancy is not an accounting quirk. It is a bar-complaint risk.

Banks report balances. They do not track sub-ledgers. The firm is responsible for maintaining the client-level view. In 2021, most firms using MyCase were doing that tracking manually, in spreadsheets or separate bookkeeping software, reconciling monthly or not at all.

That is the gap the module was built to close.

What the series covers

The module had five interlocking parts. Each one is a separate post in this series.

Part 1 -- The chart of accounts. Before any posting or matching could work, the module needed a stable ledger structure. Six top-level categories -- Assets, Liabilities (including segregated trust), Equity, Revenue, Expenses, Compensation -- pre-populated with legal-specific accounts. Some accounts were locked because billing, invoicing, and expense entry auto-posted to them. Firms could customize via sub-accounts but could not rename or delete the roots. The downstream safeguards in Part 3 depend on that stability.

Part 2 -- Three-way reconciliation. Bank statement versus firm trust ledger versus per-client trust sub-ledgers. Two-way matching (bank against firm books) will pass while a client-level slice is wrong, because the pooled bank account cannot see individual matters. The design decision that made three-way runnable at scale: auto-generating client trust sub-ledgers from existing MyCase client records instead of requiring firms to set up sub-ledgers manually. Firms that had to build the third leg themselves skipped it. Without the third leg, three-way is two-way with paperwork.

Part 3 -- Safeguards against flagging too much. Once you can see client-level balances, the next problem is catching errors without burying reviewers in noise. This is the post that was already published as "The Aggregate Can Lie." It covers naive flag-everything, the false-positive flood it produces, and the invoice-exact matching design that caught real violations without producing daily alert fatigue.

Part 4 -- Plaid bank sync. Pulling bank feeds via Plaid required a decision that is not obvious until you see the failure: trust accounts cannot follow the same categorization workflow as operating accounts. If the firm has already recorded a trust transaction in MyCase, importing the bank line and categorizing it into a GL account creates a second source of truth and breaks the three-way model. The For Review pipeline, and why trust transactions skip categorization entirely, is Part 4.

Part 5 -- GL integration. The last loop to close was eliminating re-keying. An invoice already lived in MyCase billing. A payment already hit LawPay. A bookkeeper was re-entering both into accounting. The integration posts billing and payment events directly to the GL at event time -- trust versus operating routing handled by the locked chart of accounts from Part 1 -- so there is nothing left to re-key and no lag between what billing recorded and what the books show.

What it shipped as

The module reached general availability after the AffiniPay acquisition closed in June 2022. Within twelve months of GA, 18% of eligible firms had enabled it.

For those firms, monthly trust reconciliation dropped from roughly six hours of manual work to under thirty minutes per cycle. The six hours was mostly matching -- pulling bank statements, cross-referencing firm records, hunting for discrepancies. The thirty minutes is reviewing a screen of pre-matched items and confirming the ones that need a human decision.

What comes first

Part 1 starts with the chart of accounts, because nothing else in the module works without it. The three-way reconciliation needs stable account identity to match against. The bank sync needs to know which accounts are trust and which are operating before it can route a feed line. The GL integration needs locked system accounts to post into.

A fully customizable chart looks like the right call when you are onboarding a firm that already has books. It turns out to be the wrong call the moment auto-posting and compliance matching need to find an account that has not been renamed or deleted. Part 1 is about that tradeoff.