Inside LawAccounting's Multi-Entity & Consolidated Reporting Engine: How Multi-Office Firms Keep Separate Books, Separate Trust Accounts, and One Real-Time P&L

A second office, a separate PLLC, an acquisition — and suddenly your firm is a multi-entity accounting problem. Most systems force you to choose between separate books with manual Excel consolidation or one ledger where entity is just a tag. Inside LawAccounting's multi-entity engine: entity-level GLs, jurisdiction-scoped trust accounts, automatic intercompany eliminations, and consolidated reporting in real time.

Published: 2026-07-15T12:12:15.361Z · Category: Legal Accounting · 8 min read

💡 IN SHORT

When a law firm adds a second office, a second entity, or a second partnership structure, most accounting systems force an ugly choice: run separate books and consolidate manually in Excel, or merge everything into one set of books and lose entity-level truth. LawAccounting's multi-entity engine does neither. Each entity keeps its own general ledger, its own trust accounts, and its own statutory books — while consolidated reporting rolls up in real time, with intercompany activity handled as data rather than as a quarterly spreadsheet exercise.

👥 Who should read this: Managing Partners Firm CFOs & Controllers Firm Administrators Legal Tech Buyers

🏢 The Moment a Firm Becomes a Multi-Entity Problem

It rarely arrives as a decision. It arrives as a series of reasonable steps.

You open a second office in another state — which means a second IOLTA account under a different bar's rules. You spin up a separate PLLC for the immigration practice because the partnership economics differ. A partner buys in on one side of the firm but not the other. You acquire a two-attorney shop and keep its entity alive for a transition period. You form a separate entity to hold the office lease and the case-cost line.

Now you have four entities, three trust accounts, two partnership agreements, and one very tired administrator building a consolidated P&L by hand every month.

📊 Did You Know?

Most law firms hit multi-entity complexity long before they hit the headcount that would justify enterprise financial software. A 25-attorney firm across three states with two partnership structures has genuinely harder accounting than a 60-attorney single-entity firm in one jurisdiction. Complexity scales with structure, not seats — which is exactly why "we're too small for that" is the wrong test.

❌ The Two Bad Options Generic Accounting Forces

Option A: Separate books, manual consolidation

Each entity gets its own QuickBooks file. Clean entity-level truth, no shortcuts — and then someone exports all of them to Excel each month, maps accounts by hand, eliminates intercompany transactions from memory, and produces a consolidated view that is stale on arrival and unauditable by design.

The consolidated number exists in one spreadsheet, on one person's machine. Ask what consolidated revenue was in March and you will get an answer in two days. Ask why it differs from what was reported at the time and you may not get one at all.

Option B: One set of books, entity as a tag

Everything in one file, with a class or location field standing in for entity. Consolidation is easy because nothing was ever really separated. And that is precisely the problem.

🚫 Red Flag

If your entities are distinguished only by a tag on a transaction, you do not have entity-level books — you have a filter. A filter can be applied inconsistently, changed retroactively, or forgotten. And when the entities hold separate trust accounts under separate bar jurisdictions, a filter is not a control. It is a hope.

🧱 How LawAccounting's Multi-Entity Engine Is Built

The architectural decision is simple and consequential: each entity is a real set of books, and consolidation is a reporting operation over real books — not a substitute for them.

📚

Entity-Level General Ledger

Every entity carries its own legal-specific chart of accounts with full multi-level hierarchy across Assets, Liabilities, Equity, Revenue, and Expenses. Not a filtered view of a shared ledger — its own.

🔒

Trust Accounts Scoped to Entity

Each entity's IOLTA accounts, matter-level trust ledgers, and three-way reconciliation run within that entity's books, under that jurisdiction's rules.

📊

Real-Time Consolidated Reporting

P&L, balance sheet, and cash flow roll up across entities on demand — no export, no mapping, no month-old spreadsheet.

🔄

Intercompany as Data

Cross-entity activity is recorded as linked transactions with a full audit trail, so eliminations are structural rather than remembered.

🧾

Entity-Aware Billing & AP

Invoices, LEDES files, and vendor bills carry the right entity, the right remit-to, and the right GL — automatically.

👥

Role-Based Entity Permissions

A partner in one entity sees that entity. Firm leadership sees the roll-up. Enforced by Salesforce-grade permissions, not by which tab you opened.

🔐 Why Trust Accounting Forces the Architecture

Multi-entity accounting in most industries is an efficiency question. In law firms it is a compliance question, and that changes what an acceptable answer looks like.

If your Arizona entity and your California entity each hold client funds, those are separate trust accounts under separate bar rules, with separate reconciliation obligations and — in California as of 2026 — separate designated licensee accountability. A system that treats entity as a reporting dimension cannot enforce that separation. It can only report on it after the fact.

LawAccounting scopes trust to the entity structurally. A matter belongs to an entity. Its trust ledger belongs to that entity's IOLTA account. Three-way reconciliation runs per account, per entity. There is no configuration in which funds drift across an entity boundary because someone mis-tagged a deposit.

⚠️ Watch Out

The most dangerous multi-entity trust error is not commingling across clients — firms watch for that. It is commingling across entities: a client of Entity B whose retainer lands in Entity A's IOLTA because that is the account the front desk had on file. It reconciles fine at the account level. It is still a violation.

🔄 Intercompany Without the Quarterly Archaeology

Multi-entity firms move money between entities constantly, and every movement is a pair of entries that must agree:

The management entity pays the shared lease; each operating entity owes its allocation
An attorney in Entity A works a matter belonging to Entity B
Entity C fronts a case cost on an Entity A matter
Fees are shared across entities on a referral
Payroll runs centrally and is allocated out

Handled manually, each of these becomes a memory. Someone has to remember to book both halves, remember to eliminate them at consolidation, and remember why the allocation percentage changed in Q2. Three quarters later, nobody remembers, and reconciling the intercompany accounts becomes archaeology.

LawAccounting records intercompany activity as linked double-entry transactions with both sides created together and auto-validated to balance. Eliminations at consolidation follow the link rather than a checklist. The intercompany account reconciles because it was never allowed to drift.

💡 Pro Tip

When you evaluate any system for multi-entity work, ask for one specific demo: show me a consolidated P&L with intercompany eliminated, then drill from a consolidated line item down to a single transaction in a single entity, then show me that entity's standalone P&L reconciling to the same number. Systems that fake consolidation cannot complete that round trip.

📈 What Changes Operationally

Task	LawAccounting Multi-Entity ✅	Separate Books + Excel ❌
Consolidated P&L	✅ Real-time, on demand	❌ Days after close, manually built
Entity-level statutory books	✅ Full GL per entity	❌ Yes, but disconnected
Trust scoped by entity & jurisdiction	✅ Structural	❌ Manual discipline
Intercompany eliminations	✅ Automatic via linked entries	❌ Rebuilt from memory each period
Drill from consolidated to transaction	✅ One click	❌ Not possible
Audit trail across the roll-up	✅ Complete	❌ Ends at the spreadsheet
Adding a new entity	✅ Configuration	❌ New file, new mapping, new risk

⚖️ The Verdict

Multi-entity is not an enterprise feature that mid-size firms grow into. It is the structure most growing firms already have and are absorbing as manual labor — a monthly spreadsheet, an administrator who cannot take vacation at close, and a consolidated number nobody can fully defend. LawAccounting keeps each entity's books real and makes the roll-up a query instead of a project.

✅ Key Takeaways

Multi-entity complexity arrives through ordinary growth — a second state, a separate PLLC, an acquisition — long before headcount suggests it should.
Generic accounting forces a bad choice: separate books with manual consolidation, or one ledger where entity is just a tag.
LawAccounting gives each entity a real general ledger and treats consolidation as a real-time reporting operation over real books.
Trust must be scoped to entity structurally — cross-entity commingling reconciles cleanly at the account level and is still a violation.
Intercompany activity is recorded as linked, auto-balanced double-entry transactions, so eliminations follow the data instead of someone's memory.
The test for any vendor: consolidated P&L → drill to one transaction → entity standalone P&L that reconciles. Fake consolidation cannot make the round trip.

One Firm. Multiple Entities. One Version of the Truth.

See LawAccounting's multi-entity engine run entity-level books, jurisdiction-scoped trust accounting, and real-time consolidated reporting — standalone or inside CaseQube.

Schedule Your Demo →