Quick answer. Three-way reconciliation requires the trust bank statement, the firm's trust ledger, and the sum of all individual client ledgers to agree for the period. It breaks across Clio Manage, a payment processor, and QuickBooks Online because those three systems record the same transaction at different times and, once processing fees are deducted, at different amounts. Timing differences clear on their own. Fee and allocation differences do not, and the allocation ones are invisible to ordinary bank reconciliation because they net to zero at the firm level.
Read the marketing for any legal practice management platform and three-way reconciliation is a checkbox. Read the job boards and firms are hiring people every month, at $4 to $20 an hour, to actually perform it. Both things are true at once, and the gap between them is worth understanding whether you are buying software, hiring a bookkeeper, or trying to decide whether the two systems you already own are supposed to be talking.
What the three ways are
Two-way reconciliation, the kind every business does, matches the bank statement to the books. Three-way adds a leg that is specific to holding other people's money:
- The trust bank statement balance for the period.
- The firm's trust ledger balance, the internal record of the account as a whole.
- The sum of every individual client ledger balance.
All three must agree. The third leg is the point. It proves not only that the right amount of money exists, but that it is allocated to the right clients. A firm can have a perfectly reconciled bank account while one client's funds sit credited to another client, and that is precisely the failure the rule is designed to catch.
Most state bars require this monthly and require the working papers be retained. The specific rule, frequency, and retention period vary, so confirm yours rather than taking a software vendor's word for it. Nothing here is professional responsibility advice.
Why three systems disagree about one dollar
A typical small firm stack has the practice management system holding client ledgers, a payment processor moving the money, and a general ledger holding the books. One client payment touches all three, and each records it differently.
Different times. Clio Manage credits the client ledger when the payment is recorded. The processor settles into the bank days later. The general ledger sees whatever the sync sends, whenever it sends it. At month end, a payment made on the 29th may exist in one system, two systems, or three. This is ordinary timing and it clears itself.
Different amounts. This one does not clear itself. The client is credited the gross payment in the practice management system, and the processor deducts its fee before depositing, so the bank receives the net. The trust bank balance is now short by the fee amount against the client ledger total. How that is correctly handled depends on your jurisdiction's rules about which account bears processing costs on trust deposits, and firms get it wrong in both directions. It is the most common single cause of a trust break we see.
Different clients. The worst category. A payment applied to the wrong matter changes two client ledgers and changes the firm total by nothing at all. Bank reconciliation passes. Two-way passes. Only summing individual client ledgers catches it, which is exactly why the third leg exists, and exactly why doing it by hand once a month means the error has had thirty days to accumulate friends.
Different opinions about what a refund is. Voids, chargebacks, partial refunds, and reversed transfers each have a natural representation in a payment processor and a different natural representation in a ledger. A sync built for the common case handles the happy path and leaves the reversals for a person.
What the work actually looks like when a firm hires it out
Job postings are the honest description of any back-office process, because they are written by the person who has to hand the work over.
A Florida boutique firm serving a dozen counties recently advertised for a bookkeeper. The scope: day-to-day transaction recording and categorization, trust and IOLTA accounting with three-way reconciliation in line with state bar requirements, monthly reconciliation of operating and trust accounts plus merchant and payment activity, reconciling client billing and payments between the practice management system and the payment processor, accounts payable and receivable, payroll entries, and monthly financial statements. One firm, one person, every month, forever.
A boutique corporate firm of ten lawyers and five staff advertised separately for a billing manager and published its volumes: sixty to seventy standard invoices a month, invoice sizes from $100 to over $35,000, fifty-plus clients billed monthly, five to ten special invoices, more than twenty individual timekeepers including outside co-counsel, four to ten new clients onboarded a month, and revenue shares to calculate for payouts. The circulation loop was written into the job description: create draft invoices, circulate them for lawyer review and signoff, chase the approvals, issue, then chase the payment.
Neither of those is an accounting problem. Both are coordination problems that happen to be denominated in dollars.
Automate detection. Do not automate correction.
This is the whole recommendation and it is worth stating plainly, because most automation pitches in this space get it backwards.
Worth building:
- A daily three-way check. Not monthly. Pull client ledger movement from the practice management API, pull settled transactions from the processor, pull the bank feed, and compare. A break found on day one is a question. A break found on day thirty is an investigation.
- A fee-aware match. Match gross to net explicitly, treating the processor fee as a known, expected difference rather than an anomaly to be flagged every single time. Otherwise the alert becomes noise and gets ignored within two weeks, which is worse than having no alert.
- An allocation check. Flag any client ledger that moved without a corresponding, attributable bank movement. This catches the misapplied payment, the category that hides from every other control.
- An exception report a human works. The output is a short list with enough context attached that a bookkeeper can resolve each line without hunting across three tabs. That is the deliverable.
- An audit trail. Every comparison run, every break raised, every resolution recorded, with timestamps. This is what makes the retained working papers defensible rather than reconstructed.
Not worth building, at any price:
- Automatic posting of adjusting entries into a trust ledger. Someone with professional responsibility for that account needs to decide what a discrepancy means before anything is written to it. Software that quietly fixes trust discrepancies is a compliance problem wearing a convenience costume.
- An AI that interprets the discrepancy. Reconciliation is arithmetic and rules, and it wants a deterministic comparison rather than a probabilistic one. Save the model for the parts of the practice where language is the input.
Before you build anything, do these four things
Most reconciliation pain at small firms is process, and process is free to fix.
- Write down the mapping. Which system is authoritative for what. If the answer lives in one person's head, that is your actual risk, not the reconciliation itself.
- Decide the fee treatment once, in writing. Confirm it against your bar's rules, then make sure every system is configured to match that decision.
- Reconcile weekly instead of monthly. Same total work, dramatically smaller investigations, and this costs nothing to implement.
- Stop letting anyone apply a payment without a matter reference. Most misallocation traces back to a payment that arrived with nothing identifying it and a person who guessed.
If those four are in place and the breaks continue, the problem is genuinely the data flow between systems and it is worth building against.
Where Oktopeak fits, and where we do not
We are not bookkeepers, we are not accountants, and we do not advise on professional responsibility. Keep your bookkeeper and your CPA. Anyone offering to replace them with software is selling you a liability.
What we build is the data layer they work on top of: pulling records from the Clio API, the payment processor, and the general ledger, comparing them on a schedule, and producing an exception report with an audit trail. The mechanics of the Clio and payment-processor side are covered in how the Clio billing workflow actually flows, and the API constraints that shape any nightly job are in Clio API rate limits and batch normalization. For firms weighing whether to keep patching or replace the stack, build versus buy for legal case management covers that decision.
The first conversation is free and 30 minutes. Tell us how the money moves through your systems today and we will tell you where it can silently disagree with itself.
