Inside LawAccounting's Multi-Bank Trust Account Engine: How Firms Run Multiple IOLTA, Non-IOLTA, and Operating Accounts Across 15,000+ Banks Without Losing a Single Client Ledger

Most law firms outgrow the single-IOLTA model faster than their software does. Multiple offices, multiple states, non-IOLTA client accounts for large balances, and separate operating accounts per entity — each one needing its own reconciliation and its own designated licensee. Here is how LawAccounting's multi-account architecture handles it.

Published: 2026-07-16T12:35:18.808Z · Category: Trust Accounting · 6 min read

💡 IN SHORT

Growing firms end up with more than one trust account — an IOLTA per state, a non-IOLTA account for a large client balance, separate accounts per office or entity. Every additional account multiplies reconciliation work, compliance surface, and the number of places a client ledger can silently drift. LawAccounting treats the account as a first-class object: each one carries its own bank connection, its own reconciliation cycle, and its own set of matter-level client ledgers — while consolidated reporting still gives the managing partner one view.

👥 Who should read this: Managing Partners Controllers Firm Administrators Multi-Office Firms

🏦 Why One Trust Account Stops Being Enough

The single-IOLTA firm is a firm with one office, one state, and no client whose funds are large enough to make interest a fiduciary question. Growth breaks all three assumptions at once:

A second office in a second state means a second IOLTA under a second bar's rules.
A large settlement or escrow means a non-IOLTA client account, because the funds are big enough or long-held enough that the interest belongs to the client, not the bar foundation.
A second legal entity — a PLLC for one practice group, an LLP for another — means its own operating account and its own books.

Each of those is a separate reconciliation, a separate bank relationship, a separate compliance obligation, and in California, a separate designated licensee. Software built for the single-account firm treats this as an edge case. It is not an edge case. It is what growth looks like.

⚠️ Watch Out

The most common multi-account failure is not fraud. It is a client ledger that got posted to the wrong trust account — correct in total, wrong per account. The bank reconciles. The books reconcile. The client ledgers reconcile in aggregate. And the individual account is out of balance in a way nobody sees until an auditor asks for a per-account three-way.

⚙️ How the Engine Is Structured

🗄️ The account is a first-class object

Every bank account in LawAccounting — IOLTA, non-IOLTA client, operating, per entity, per office — exists as its own record with its own GL mapping, its own bank connection, and its own reconciliation history. A trust account is not "the operating account with a flag on it." It is structurally distinct, which is what allows the system to enforce trust rules on trust accounts and not on operating.

📒 Client ledgers hang under the account

This is the piece generic accounting cannot do. In QuickBooks, a bank account has transactions. In LawAccounting, a trust account has transactions and a set of matter-level client ledgers, each of which must sum to the account's book balance. That relationship is enforced at the data layer — which means a per-account three-way reconciliation (bank vs. book vs. sum of client ledgers) is a report you run, not a spreadsheet you build.

🔗 15,000+ bank connections, per account

Each account carries its own live bank feed. AI-powered smart matching proposes matches per account: beginning balance, cleared deposits, cleared payments, statement ending balance, difference. Five trust accounts means five clean reconciliations — not one reconciliation with five times the noise in it.

🚨 Compliance rules enforce per account

Overdraft protection, commingling detection, and negative-balance alerts fire at the client-ledger level within each account. A matter cannot go negative in trust regardless of how much cushion the account has overall — because the fiduciary obligation runs to the client, not to the account.

🏦

Unlimited Accounts

IOLTA, non-IOLTA, operating — per state, per office, per entity. Each with its own GL mapping and rules.

🔄

Per-Account Three-Way

Bank vs. book vs. sum of client ledgers — run per account, not just in aggregate.

🤖

AI Smart Matching

15,000+ bank connections with per-account matching and difference detection.

🚨

Client-Ledger Alerts

Overdraft and commingling warnings fire at the matter level inside each account.

📊

Consolidated Reporting

Multi-entity roll-up so the managing partner sees one firm, not five spreadsheets.

🔍

Full Audit Trail

Every posting, transfer, and reconciliation — attributable by account and by user.

📊 Did You Know?

A per-account three-way reconciliation is the artifact most state bar audits actually request — and it is the one firms running trust in generic accounting software genuinely cannot produce, because the software has no concept of a client ledger nested under a bank account. They rebuild it in Excel every month, by hand, and hope the formula didn't break.

🔄 Moving Money Between Accounts — Correctly

Multi-account firms move money constantly: trust to operating when a fee is earned, IOLTA to a non-IOLTA client account when a balance crosses a threshold, operating to operating between entities. Each of those has a different compliance posture, and the system treats them differently.

Trust-to-operating transfers require an earned fee behind them. LawAccounting ties the transfer to the invoice that earned it — so the audit trail shows not just that money moved, but why it was allowed to move. An intercompany operating transfer, by contrast, is a straightforward journal entry between entities and reconciles on the consolidated statements.

💡 Pro Tip

Reconcile every trust account on the same day each month, and reconcile them all — including the one with three transactions a quarter. The dormant account is where drift hides, because nobody looks at it. Compliance alerts on low-volume accounts catch what monthly attention never will.

🏗️ Why the Salesforce Foundation Matters Here

Multi-account, multi-entity structures are where lightweight legal accounting tools hit their ceiling — usually somewhere around the 50-user mark, or the moment a second entity appears. LawAccounting runs on Salesforce, which means the data model extends: a new entity, a new account type, a new reporting dimension is configuration, not a vendor roadmap request. Role-based permissions scope who can see and post to which account. And the same platform runs your practice management, so a trust balance is one click from the matter it belongs to.

✅ Key Takeaways

Growth reliably produces multiple trust accounts — by state, by entity, by client balance size. It is not an edge case.
Every account needs its own three-way reconciliation. Aggregate reconciliation hides per-account drift.
Client ledgers must hang structurally under the account — the relationship generic accounting software does not model.
Compliance alerts belong at the client-ledger level inside each account, because the duty runs to the client.
Trust-to-operating transfers need an earned fee behind them and an audit trail that shows it.
Dormant accounts are where drift hides. Reconcile all of them, every month.
Salesforce-native architecture means new entities and accounts are configuration, not a support ticket.

One Firm. Five Accounts. Zero Surprises.

See how LawAccounting runs per-account three-way reconciliation, client-ledger compliance alerts, and consolidated multi-entity reporting from a single Salesforce-native platform.

Schedule Your Demo →