Trust accounting is the one part of practice software where a clerical error becomes a professional problem. Most systems will happily record whatever you type, keep a running balance, and print a statement. Far fewer will refuse an entry that would overdraw a client, keep the double entry intact through every fee transfer, or let you prove — months later — who posted what and when. The eight questions below are designed to find that difference in an afternoon, using your own statement and three transactions.
Executive summary
Every practice-management system claims trust accounting. In practice they fall into three groups: systems that store figures against a client, systems that maintain separate client ledgers with a running balance, and systems that model the underlying double entry and refuse invalid movements at the point of entry.
Only the third group behaves like a ledger. The distinction matters because the risk is not that the software forgets a number — it is that the software permits a movement that should never have been possible, and no one notices until reconciliation, or until an auditor asks.
This paper sets out what a faithful ledger must do (§2), eight questions to ask any vendor (§3), a scripted half-day test (§4), the six contract terms worth insisting on (§5), and our own position — including where we are still hardening (§6–§7).
1 · Why client money is different
Client money is not firm money, and the software that holds it is not merely a bookkeeping convenience. Four differences drive everything that follows:
- It is not yours. Money held for a client is held in a fiduciary capacity. The firm is a custodian, and the records must show whose money is where at any moment — not just what the firm has in total.
- The rules are specific, not general. Most jurisdictions prescribe how client money is received, disbursed, transferred and reconciled, and bar mixing it with firm funds. A system that treats trust and office income as one pot fails at the level of design.
- An error is a personal exposure. Deficiencies in client accounts can be treated as misconduct, and professional-indemnity insurers ask pointed questions about how the accounts are kept and reconciled.
- The audit trail is the defence. When a question arises two years later, “the system showed a balance” is not an answer. “Here is the entry, the reference, the posting user, the date and the bank match” is.
The useful test of any system is therefore not whether it can print a trust statement, but whether it can prevent the entries that make a statement wrong.
2 · What a faithful ledger must do
Before the questions, the model they are testing. A ledger that follows the rules has five properties:
| Property | What it means in practice |
|---|---|
| Double entry | Every movement has two sides. A fee transfer is not “money leaves trust”; it is an outflow from the client’s trust balance and an inflow to the firm’s fee income, recorded together and referable to an invoice. |
| Per-client, per-matter balances | The ledger knows whose money it is. A firm-wide total is a derived figure, never the primary record. |
| Separate accounts | Client funds and office funds are distinct accounts, with transfers between them as explicit, referenced entries rather than adjustments. |
| Refusal at the boundary | An entry that would overdraw a client’s balance, or disburse money that has not been received, is rejected when it is attempted — not flagged later. |
| Evidence | Every entry carries a date, a reference, a posting user, and (where relevant) a link to the invoice, receipt or bank item that justifies it. The record cannot be quietly edited afterwards. |
Notice what is absent: no requirement that the system forecasts, budgets or advises. A trust ledger is not an accounting department; it is a structure that makes certain mistakes impossible and the rest visible.
3 · The eight questions
Ask these in the order given. Each one is followed by what a good answer looks like, how to test it, and the red flags that suggest the answer is marketing.
Question 1 — What is the primary record: the entry, or the balance?
Why it matters. If the system stores a balance and adjusts it, you have a running total, not a ledger. Balances can drift silently; entries cannot.
Good answer. Entries are the source of truth; every balance is computed from them, and the system can show the entries behind any balance.
How to test. Pick any client and ask the vendor to show the entries that produce today’s balance, on screen, in the demo.
Red flag. The answer involves the word “adjusted”.
Question 2 — Show me the double entry for a fee transfer.
Why it matters. Fee transfer is the movement where firms most often blur client and firm money. If the system cannot display both sides with a reference to the invoice, then trust and income are being treated as one pot with a label.
Good answer. One action produces two linked, referenced postings: out of the client’s trust balance, into fee income against a specific invoice.
How to test. Ask them to transfer part of a client balance against an invoice in the demo, then show you both sides.
Red flag. A single entry described as a “transfer” with no counterpart.
Question 3 — What happens if I try to overdraw a client?
Why it matters. This is the single most diagnostic question in the paper. A system that refuses the entry is enforcing the rule; a system that allows it and reports it later is merely recording the rule.
Good answer. The entry is rejected at the point of entry, with a clear message, and the attempt is visible to the person who made it.
How to test. Ask to attempt a transfer larger than the client’s balance, live.
Red flag. “It would show as a negative balance and you would see it in the reconciliation.”
Question 4 — Where does a disbursement come from, and can it come from the wrong place?
Why it matters. Disbursements paid on a client’s behalf are trust movements; a firm expense is not. Software that lets a payment be posted as either, at the user’s discretion, will eventually produce both.
Good answer. Disbursements are posted against the matter and the client’s funds, with the receipt or reference attached; firm expenses follow a separate path.
How to test. Ask what stops someone posting the same payment as an office expense.
Red flag. “The user chooses the account.” Choice is not a control.
Question 5 — Can the ledger be edited after the fact?
Why it matters. Reversals are legitimate; silent edits are not. The difference between a corrected record and a rewritten one is the whole value of the ledger as evidence.
Good answer. Posted entries are immutable. Corrections are made by a reversing entry that references the original, and both remain visible with the user and timestamp.
How to test. Ask to change an amount on a posted entry and see what happens.
Red flag. “An administrator can correct it.”
Question 6 — Who can post, and is that recorded?
Why it matters. Segregation of duties is an audit expectation and a fraud control. In a small firm, the same person may do everything — but the system should still record who did it, and allow a second signature where the firm wants one.
Good answer. Posting is permissioned by role, every entry carries the posting user, and the firm can require approval above a threshold or for fee transfers.
How to test. Ask a junior account to post a fee transfer in the demo and see whether approval is required.
Red flag. One “admin” role with no structure behind it.
Question 7 — How does reconciliation work, and what happens to the differences?
Why it matters. Reconciliation is where trust accounting either becomes routine or ruins a month. The test is not whether statements can be imported, but what the system does with items that do not match.
Good answer. Bank items are matched to ledger entries; unmatched items become listed exceptions with an owner and a status, and the reconciliation is saved as a dated record.
How to test. Bring a real statement and ask them to reconcile a month with one deliberate mismatch.
Red flag. Exports to a spreadsheet, described as “flexibility”.
Question 8 — What evidence can you hand me two years from now?
Why it matters. The purpose of the ledger is to answer a question that has not been asked yet — by an auditor, an insurer, a client or a regulator.
Good answer. A complete, exportable ledger per client and per matter, with entries, references, users, timestamps, reversals and the reconciliation history attached.
How to test. Ask for an export of a client ledger from the demo instance, and open it.
Red flag. A screenshot, or a PDF with totals and no entries.
4 · The half-day test
Four hours, one statement, three transactions and one deliberate rule violation. It requires no technical staff and produces a decision you can defend to the partnership.
| Step | What you do | What you are looking for |
|---|---|---|
| 1 · Opening position | Create a test client and matter; record an opening deposit of a round figure against a reference. | Does the entry carry a reference and user? Is the client balance immediately visible? |
| 2 · The disbursement | Post a payment on the client’s behalf from trust, attaching the supporting document. | Does it reduce the client balance, keep the reference, and remain distinguishable from firm expenses? |
| 3 · The fee transfer | Raise an invoice for part of the work done, then transfer that amount from trust to fees. | Do both sides appear, linked to the invoice? Is the client balance reduced by exactly the transferred amount? |
| 4 · The violation | Attempt a transfer larger than the remaining client balance. | Is it refused? Is the attempt visible? |
| 5 · The correction | Ask the vendor to “fix” a posted amount. | Does the system produce a reversal rather than an edit, keeping both entries? |
| 6 · The reconciliation | Import a statement with one item deliberately absent from the ledger. | Is the difference raised as a listed exception with an owner, rather than an unexplained variance? |
| 7 · The export | Export the client ledger and the reconciliation record. | Can you hand the file to your accountant without the vendor present? |
Write down the answers as you go. At the end you will have a one-page comparison that is far more useful than any feature matrix, because it is about your money and your rules.
5 · What to put in writing
Six terms. Any vendor whose ledger does what it claims will accept them without much argument; a vendor who resists has told you something important.
- Ledger integrity. Posted entries are immutable; corrections are reversals that reference the original and are retained.
- Refusal behaviour. The service will reject entries that would overdraw a client balance or disburse funds not received.
- Complete export. On request, the firm receives its full ledger — entries, references, users, timestamps, reversals, reconciliations — in an open format, at no charge.
- Retention. Ledger data is retained for the period the firm specifies, and retained beyond termination for the agreed statutory minimum.
- Access attribution. Every posting and every view of the ledger is attributable to a named user, and access records are available to the firm on request.
- Change notification. Any change to how the ledger behaves — rounding, approval thresholds, reconciliation logic — is notified in advance to the firm’s administrators.
If a firm operates in a jurisdiction with prescribed forms or named officers for client accounts, add the corresponding obligations explicitly. Software can enforce the arithmetic of a rule; it cannot take on the regulatory duty itself.
6 · How OpenLPM answers
Our own position against the eight questions, including where we are still hardening. Firms are entitled to the same scrutiny from us that we recommend applying to everyone else.
| Question | Our answer |
|---|---|
| 1 · Entry or balance? | Entries are the record; balances are derived from them and can be expanded to the entries that produced them. |
| 2 · Double entry | A fee transfer posts both sides — out of the client’s trust balance, into fee income against the invoice — and both remain visible with the reference. |
| 3 · Overdraw | Refused at the point of entry, with the attempt visible to the user who made it. Verified end-to-end in our own test record (§53 of the build runbook). |
| 4 · Disbursements | Posted against the matter and the client’s funds with the supporting document; firm expenses follow a separate path. |
| 5 · Edits | Posted entries are not editable in place; corrections are reversals that reference the original. |
| 6 · Who posted | Permissioned by role, every entry attributed to a user, with approval steps available for fee transfers. Honest note: approval thresholds are configured per firm and we expect firms with larger accounts teams to want more granular signatures — tell us where our defaults do not fit. |
| 7 · Reconciliation | Statement import, item matching, and unmatched items as listed exceptions with an owner and status; the reconciliation is saved as a dated record. |
| 8 · Evidence | Per-client and per-matter ledger export in an open format, with entries, references, users, timestamps, reversals and reconciliation history. |
7 · Limits and verification
Two limits we will state ourselves, because a firm that discovers them later will rightly feel misled:
- Balance checks are read-then-write. Our store does not support row-level locking, so the overdraw check reads the balance and then writes the entry. For the ordinary case — one person posting to one client at a time — this is safe and has been verified end-to-end. For firms where several fee-earners post to the same client simultaneously, the check needs to become batch-atomic. That work is on our list and is flagged in the product record rather than buried.
- We do not provide accounting advice. The system enforces the rules a firm configures within the structure described above; whether a particular treatment satisfies a particular regulator remains the firm’s professional judgement, and we will say so in writing.
Everything in §6 can be tested in the way described in §4: three transactions, one deliberate violation, and an export. If any answer fails your test, that is worth more to both of us than an agreeable demonstration.