How Casely Makes a Trust Account Overdraft Structurally Impossible
Most trust ledger features in legal software are a spreadsheet with extra steps. Here is exactly how Casely's trust ledger works underneath, why a disbursement that would overdraw a matter simply cannot be recorded, and what that actually means for a bar audit.
Let me be very honest about trust accounting, because this is the one area of running a law firm where "we will just be careful" is not actually a plan, right, client trust money sits under some of the strictest rules in the entire profession, and the firms that get into real trouble with it are almost never the firms that meant to do something wrong, they are the firms that were relying on a spreadsheet, or a paralegal's memory, to catch a mistake before it became a bar complaint.
So I want to walk through exactly how Casely's trust ledger actually works underneath, not the marketing version, the actual mechanism, because the specific engineering choice here is what separates "a trust ledger" from "a trust ledger you can actually defend in front of an auditor."
Most "trust ledger" features are just a spreadsheet with a nicer skin
Here is the catch with a lot of legal software, and I want to be specific about this rather than vague, a lot of tools will let you record a deposit and a disbursement, show you a running total, and call that a trust ledger, but if a paralegal enters a disbursement for more money than is actually sitting in that matter's trust account, the software just lets it happen, maybe with a small warning banner that is easy to click past, and now the firm has technically overdrawn a client's trust funds, which is not a minor bookkeeping error, that is the kind of thing that shows up in a bar complaint.
How the guard actually works underneath
Let me get specific here because the "how" is the whole point, right, when a disbursement is submitted, Casely does not calculate the balance first in one step and then decide whether to allow the write in a second step, because that gap between checking and writing is exactly where a race condition can slip through, for instance two people submitting a disbursement for the same matter within the same second.
Instead, the balance check and the insert happen as a single atomic database operation, the new trust entry is only written if the currently committed balance, calculated fresh from every entry that has already cleared, still covers the amount, and if it does not, the write is rejected outright and nothing is recorded, so there is no window where two simultaneous disbursements could both pass the check and only one of them actually fits.
| Entry Type | Direction | Effect on Balance |
|---|---|---|
| Deposit | Money in | Increases the matter's trust balance |
| Replenishment | Money in | Increases the matter's trust balance |
| Disbursement | Money out | Decreases the balance and is blocked before it can go negative |
| Fee deduction | Money out | Decreases the balance and is blocked before it can go negative |
| Wire | Money out | Decreases the balance and is blocked before it can go negative |
| Check | Money out | Decreases the balance and is blocked before it can go negative |
Mistakes get voided, never deleted
At the end of the day, people make mistakes, someone enters the wrong amount, or attaches an entry to the wrong matter, and the question is not whether that ever happens, it is what the system does about it when it does, and this is the other place a lot of trust ledger tools get it wrong, right, they let you delete the bad entry, which means the record now just looks clean, as if the mistake never happened, and that is exactly the kind of thing an auditor does not trust.
In Casely, a trust entry can never be deleted, only voided, and when it is voided it stays visible on the ledger with a clear void marker, along with who voided it and why, so the balance recalculates correctly but the history stays completely intact, an auditor can read the ledger from the very first entry to the most recent one and see exactly what happened, including every mistake and every correction, which is basically what ABA Model Rule 1.15 record keeping expects of you in the first place, we just made it the only way the system works instead of a policy someone has to remember to follow.
| Feature | Generic trust ledger | Casely |
|---|---|---|
| Overdraft check | A warning banner you can dismiss | A hard block at the database transaction level |
| Correcting a mistake | Delete the row and re-enter it | Void the entry, it stays visible with a clear marker |
| Concurrent disbursements | Both can pass if submitted close together | Only one can ever pass, checked atomically |
| Audit trail | Whatever the file's version history happens to keep | Every entry, every void, every reason, permanently readable |
What this actually means when an auditor asks for your records
Every bar association that regulates trust accounting expects the same basic things from your records, a running balance per matter, a full history of every deposit and disbursement, the payee and reference number for money going out, and reconciliation on a regular cadence, monthly is the standard most jurisdictions expect under rules like ABA 1.15(a), and the honest test of whether your system actually supports that is not whether it can produce a balance, it is whether it can produce the full history behind that balance without any gaps.
- Can your system show every entry that makes up the current balance, not just the total
- Has a disbursement ever been recorded that technically overdrew a matter
- Do corrections stay visible, or do they just disappear when someone deletes a row
- Can two people accidentally record conflicting disbursements at the same time
- Do you reconcile the trust account against actual bank statements every month
- Could you hand an auditor the full ledger for one matter and have it make sense on its own
Reconciliation is a monthly habit, not an annual scramble
Let me be honest about the part of trust accounting most attorneys actually dread, right, reconciling the trust ledger against the bank statement, and the reason it feels dreadful at most firms is that it only happens rarely, usually right before an audit, which means someone is trying to explain three months or six months of activity all at once, hunting for the one entry that does not match, with the actual context of why each entry happened long since forgotten.
The catch here is monthly reconciliation is genuinely not hard when the ledger itself is already correct by construction, right, because you are not hunting for arithmetic errors anymore, the balance was never allowed to be wrong in the first place, so reconciling against the bank statement becomes a matter of confirming timing, a check that cleared a few days after it was recorded, rather than untangling a mystery, and firms that reconcile monthly on Casely tell us it takes them a fraction of the time it used to, basically because the hard part, keeping the running balance accurate, was already handled the moment each entry was recorded.
And this matters for more than just convenience, right, at the end of the day a clean monthly reconciliation habit is exactly the kind of practice a bar examiner is looking for, it shows the firm is not just compliant on paper, it is actually watching the account the way it is supposed to, and a firm that can produce twelve clean monthly reconciliations is in a fundamentally different position than a firm that can only produce one messy one from right before the audit.
Setting it up takes minutes, not a training session
- 01Record your first deposit against a matter, for instance an initial retainer
- 02Log a disbursement and watch the balance update in real time
- 03Try to disburse more than the balance allows and see the block happen
- 04Void a test entry and confirm it stays visible with its marker
- 05Reconcile the matter's ledger against your actual bank statement
Let me be honest about the last part too, right, the goal here was never to make trust accounting feel complicated, it was the opposite, we wanted the correct, compliant way of handling client money to also be the easiest way, so an attorney who has never thought about ABA 1.15 in their life still ends up compliant just by using the system the way it is designed to be used, and that, at the end of the day, is what "built in" trust accounting is supposed to mean.
