Six Categories, Some Locked: Designing a Legal Chart of Accounts

#fintech #compliance #backend #architecture

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 tempting chart of accounts design for a law-firm product is the
QuickBooks-shaped one: ship a starter tree, then let firms rename, move, and
delete whatever they want. Firms know their own books. Flexibility feels
like respect.

We did not ship that.

I designed MyCase Accounting's chart of accounts as a legal-specific,
pre-populated structure with six top-level categories -- Assets, Liabilities
(including segregated trust), Equity, Revenue, Expenses, and Compensation --
and with a hard rule underneath: some system accounts are locked. Billing,
invoicing, and related auto-posting write to those accounts. Firms customize
under them with sub-accounts. They do not get to mutate the roots the
product depends on.

This post is about that lock decision: the rejected alternative, what firms
can still change, and the downstream matching that only works because the
identity stayed stable.

The rejected alternative

A fully customizable chart looks customer-friendly until the product has to
post on the firm's behalf.

MyCase already had billing, invoicing, and payment flows. Accounting had to
record those events into the general ledger without a bookkeeper retyping
amounts into a second system. That means the product, not the firm, chooses
which account receives an invoice post or a trust-to-operating movement.
If the firm can rename, merge, or delete those accounts, every auto-post
becomes a moving target -- and every compliance check that needs "the trust
liability account" or "the operating revenue path for this invoice" loses
its handle.

The alternative we rejected was full editability with a shrug: "firms will
configure it correctly." That is not a design. It is hope. Hope is a bad
dependency when the money is client trust funds.

Six categories, customization underneath

The shape we shipped is deliberately legal, not a generic GAAP starter kit
with trust bolted on later.

Liabilities include segregated trust. That is not a cosmetic label. Trust
money is not the firm's money, and the chart has to say so in a place the
rest of the system can rely on. Assets, equity, revenue, expenses, and
compensation fill out the operating side firms already understand from
practice management.

Pre-population mattered for adoption. Accounting activates onto that
starter chart so a firm is not staring at a blank tree on day one.
Customization is real -- sub-accounts under the locked roots -- but it does
not include deleting the system accounts billing posts into.

When a firm wanted to rename a locked account, the answer was a hard stop
and a redirect: create a sub-account for the label you want. The roots stay
put.

Why the lock pays off downstream

Part 3 covers the safeguard that
flags trust-to-operating transfers that do not exactly match an unpaid
invoice. That safeguard only works if a posted invoice and its
corresponding trust transaction share a stable link through the chart.

Without locked, billing-linked accounts, there is nothing precise to match
a transfer against. You get amount-ish heuristics, tolerance bands, and the
false-positive flood that kills reviewer trust. The chart of accounts is
not a setup screen you finish and forget. It is the identity layer the rest
of the module hangs on.

Part 5 closes the other
half of the same decision: when billing and LawPay ledger events fire,
posting rules write into those locked accounts under trust and operating
rules. Event-time auto-post into a moving chart is how you reintroduce
re-keying with extra steps. Event-time auto-post into a locked chart is how
you eliminate it.

What this post is not

This is not a tour of every system account name we locked. The rule matters
more than the roster: if billing or compliance matching depends on an
account, it is locked; firm-facing labels live in sub-accounts.

It is also not the three-way reconciliation story. The chart makes precise
matching possible. Part 2
is about why the third ledger has to exist by default.