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

#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 default assumption when building an accounting module for businesses is that they know their own books. A law firm that has been tracking its finances for ten years has account names, structures, and categories that work for its practice. The obvious product instinct is to give them full control: let them rename accounts, restructure categories, delete what they do not use.

That instinct is wrong, at least for the accounts that billing, invoicing, and compliance matching depend on.

What a legal chart of accounts looks like

The module pre-populated a chart of accounts at onboarding, organized into six top-level categories: Assets, Liabilities (with a segregated trust account under it), Equity, Revenue, Expenses, and Compensation. The legal-specific structure differs from a standard business chart mainly in the trust liability account, which holds client funds the firm has not yet earned, and in how compensation is tracked separately from operating expenses for partnership accounting reasons.

Each category came with system-defined sub-accounts appropriate to a law firm. Firms could add their own sub-accounts under any category. They could rename their own custom accounts freely. What they could not do was rename or delete the system accounts.

That restriction is what this post is about.

Why auto-posting breaks with a moving target

When a firm sends an invoice through MyCase billing, the accounting layer needs to post the corresponding journal entries automatically. An invoice creates an accounts receivable entry on the asset side and a revenue entry on the income side. A payment marks the receivable satisfied and records cash or, for trust-funded payments, moves money from the trust liability account to the operating side.

Every one of those postings needs to land in a specific, stable place in the ledger. The posting logic does not ask the firm which account to use. It knows, because the chart of accounts has a defined structure with fixed identity for system accounts.

If a firm could rename "Trust Account" to "Client Funds" or delete it and create an equivalent under a different structure, the billing integration would post to an account that no longer exists under the expected name. The transaction would fail, or worse, post to a default catch-all with no meaningful category.

The same problem applies to expense entry and to the invoice-exact matching in Part 3. Matching a trust-to-operating transfer against the invoice that authorized it requires finding both the trust transaction and the invoice's corresponding posted entry. If the account names or identities can shift, the lookup falls apart.

The customization boundary

Locking accounts does not mean firms get no flexibility. The system accounts define the roots and some first-level structure. Anything below that is fair game. A firm that tracks fees in several categories can add sub-accounts under Revenue. A firm with specialized expense categories can build those under Expenses. None of that custom structure touches the system accounts that auto-posting and compliance matching depend on.

The product framing for this was straightforward: the locked accounts are ones the system writes to on your behalf. Everything else is yours to organize how you see fit.

In practice, the most common request from early adopters was renaming the trust account to match whatever they had been calling it in their previous system. The answer was a sub-account alias, not a rename of the root. The root kept its identity; the firm could see whatever label they preferred in their own views.

The downstream dependency

It would be easy to treat the chart of accounts as plumbing: necessary, not interesting. But the lock decision has a direct effect on everything built on top of it.

The three-way reconciliation in Part 2 works because the firm trust ledger has a known structure. The matching logic in Part 3 works because a posted invoice has a stable account identity to match against. The bank sync in Part 4 can distinguish trust accounts from operating accounts because that distinction is encoded in the chart, not inferred from whatever the firm named their accounts. The GL integration in Part 5 can post billing and LawPay events at event time because the target accounts are always there.

Firms that wanted full customization got it in the places where customization does not break the system. Firms that wanted to rename or delete system accounts got an explanation of why that was not possible and what the alternative was. A few firms pushed back. The answer was always the same: these accounts are written to on your behalf, and that only works if they have a stable identity the system can find.