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
Picture a clean close. The bank statement lines are checked off against the
firm's trust ledger. The difference is $0.00. Everyone is ready to move on.
Then a client calls about a retainer, and one client's sub-ledger is wrong
by a few hundred dollars. Money that should have stayed in their slice was
drawn against another matter. The bank never saw it. The aggregate never
flagged it. Two-way reconciliation had succeeded at the only thing two-way
can see.
That is why bank-versus-firm matching is not enough for IOLTA trust
accounts. This post is about the third leg -- per-client Client Trust
Ledgers -- and the product decision that made the third leg exist by
default instead of as optional setup.
Why two-way fails structurally
A pooled trust account is one bank balance and many client slices. The bank
statement is authoritative for the pool. The firm's trust ledger is
authoritative for what the firm recorded. Neither one, alone or together,
proves that each client's slice is correct.
Two-way can tell you the pool matches. It cannot tell you whose money moved
inside the pool. Under IOLTA, whose money moved is the whole point.
Three-way reconciliation -- Trust Account Bank Statement, Firm Trust
Ledger, and Client Trust Ledger (balance by matter) -- is not a MyCase
invention. It is what the rules already require. The engineering question is
whether the product makes the third ledger inevitable or optional.
The decision: auto-generate the third leg
The rejected alternative was manual setup. Ask the firm to create
per-client sub-ledgers, then reconcile against them once they exist.
That alternative fails quietly. Three-way on paper with a missing third leg
is two-way in practice. Firms under time pressure skip optional
configuration. The aggregate-lie failure mode stays invisible until a
client phones in.
What we shipped: Client Trust Ledgers are auto-generated per client as
matters and trust activity require them. "Balance by matter" is the default
path, not a checklist item. If you are recording trust activity in MyCase
Accounting, the third ledger is already there when reconciliation starts.
That was the load-bearing product decision inside an otherwise mandated
model. IOLTA says you need three-way. Auto-generation says you will still
have three-way on a Thursday afternoon when nobody wants to configure
anything.
The workflow
Reconciliation itself is deliberately boring. Compare bank statement lines
against logged journal entries. Check off matches. Target a $0.00
difference -- no variance band. A tolerance band is the crack a real error
slips through; the same philosophy shows up again in
Part 3 on invoice-exact matching.
The module supports checking, savings, credit card, and trust accounts on
that check-off path. Trust is the hard case: it adds the client sub-ledger
leg and the IOLTA constraints. Operating account types reuse the same
statement-versus-journal workflow without client sub-ledgers. Supporting
four account types was real work, but it is not the spine of this story.
The spine is making the third trust ledger unavoidable.
What comes next
Once client-level balances are visible by default, you can finally watch
the failure mode two-way cannot see. Watching introduces a new problem:
how do you flag real trust-to-operating mistakes without burying reviewers
in routine, correct transfers?
That is Part 3 -- the aggregate
can lie, and a naive safeguard can lie louder.
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)