Trust balance thresholds that prompt a replenishment request automatically, with the firm's accounting system still the system of record.
Bring your stack to a call and we will scope it against how your business actually runs.
Book a callA firm that bills against client funds held in trust is running on a balance that depletes with every hour worked. The replenishment request is the mechanism that keeps the firm solvent on that matter, and in most small firms it is the least systematic thing the firm does. Somebody notices the balance is low, usually while preparing a bill, usually after the balance has already gone to zero, and sends an email asking for more. In the gap between the balance running out and the replenishment arriving, the firm is working for free and does not know it.
The failure has a particular shape. Trust balances are visible in the accounting system, which the people doing the work mostly do not open. The person who knows the matter is burning hours is the attorney; the person who knows the balance is the bookkeeper; and they reconcile monthly. So a matter can run three weeks past empty before anyone connects the two facts. Then the replenishment request goes out in the same breath as a bill for work already done, which is the worst possible moment to ask - the client is looking at a number they did not expect and being asked for another one.
The leak is simple and large: unbilled and uncollectible work in progress, write-offs when a client declines to replenish for work already performed, and matters that have to be paused or withdrawn from at an awkward stage because the funding ran out and nobody saw it coming. There is also a professional dimension. Rules on client funds are strict and unforgiving, and a firm that is casual about when it asks for money is often casual about how it records it. This build addresses the first problem and is deliberately conservative about the second: the platform watches a threshold, prompts a human, and sends the request a human approved. The firm's accounting system stays the system of record for every dollar in trust, and reconciliation stays exactly where it is, under the applicable bar rules.
Read this before you build a single workflow. The platform is a tracking and prompting layer. It holds a copy of a balance figure and a threshold, watches the relationship between them, prompts a human, and delivers an approved request with a payment link. It is not the system of record for client funds held in trust. The firm's trust accounting system or practice management system remains authoritative for every balance, every deposit, every disbursement and every transfer. Three-way reconciliation of the trust account, the bank statement and the client ledgers stays in that system, performed by the firm's bookkeeper under the applicable bar rules. No automation in this build moves money between accounts, applies funds against a bill, or records a trust transaction. Where the two systems disagree, the accounting system is right and the platform is stale. Build a visible discrepancy alert rather than a silent reconciliation.
One pipeline, Retainer Health, tracking the funding state of each matter.
Every balance field in the platform is a cached copy of a figure the accounting system owns. Name them so nobody forgets that.
This is the most tightly constrained BO in the legal set, because the subject is client money.
One matter on an hourly arrangement funded by a retainer held in trust, from engagement to refund.
Eight workflows. Four global guards apply to every one of them, checked before any client-facing send: retainer-tracking-active must be present; fee-dispute-open must be absent; balance-stale must be absent for any message that references a figure; and quiet hours and sms-opt-out are respected. No workflow here records a trust transaction, moves funds, or treats a payment as received before the firm's accounting system confirms it.
Trigger: scheduled sync from the trust accounting or practice management system, nightly at 2am, plus on-demand after any recorded deposit.
Exit: runs on schedule indefinitely while tracking is active.
Trigger: Projected Depletion Date falls within the warning window (default 21 days) and the deal is at Funded.
Exit: threshold crossed (hand to workflow 3) or projection recovers.
Trigger: Trust Balance Cached is at or below Replenishment Threshold, timestamp fresh.
Exit: a decision is recorded.
Trigger: approval recorded in workflow 3.
Exit: payment confirmed, arrangement agreed, or dispute raised.
Trigger: deal at Request Sent. Checked before every send: no confirmed receipt, no fee-dispute-open, no payment-plan-active, no booked fee call, balance not stale.
Exit: confirmed receipt, arrangement agreed, dispute raised, or reminder 3 sent.
Trigger: payment gateway notification, or a deposit recorded in the accounting system.
Exit: confirmation recorded and deal moved.
Trigger: reminder 3 sent and 7 days elapsed with no confirmed receipt, or the cached balance reaches zero.
Exit: attorney closes the task with a recorded decision.
Trigger A - evergreen: evergreen-autopay present, Autopay Authorized is yes, threshold crossed.
Trigger B - dispute: any inbound message, call note or form submission questioning the charges, the balance or the arrangement.
Trigger C - refund due: matter closed with a credit balance confirmed in the accounting system.
Exit: refund recorded as issued; remove retainer-tracking-active, apply retainer-closed.
The firm stops discovering funding problems in the billing cycle. The threshold is watched continuously, the projection gives the responsible attorney two to three weeks of warning before a client hears anything, and the request goes out while there is still a balance to work against. The window where the firm is working on an empty account closes from weeks to days.
The ask also gets better. A replenishment request arriving on its own, referencing terms the client already agreed to in the engagement letter, reads as administration. The same request bundled into a bill for work already done reads as a demand. Separating the two changes the response rate and the tone of the conversation, and the clients who need to talk about timing now have a form and a calendar rather than a phone call they are dreading.
Internally the roles separate cleanly. The attorney decides what to ask for, the administrator handles the chase, and the bookkeeper remains the only person who records anything about client funds. Nobody is guessing at a balance, because every figure anyone sees carries the date it was true. The firm also gains a complete record of when each request was made, approved, sent, reminded and confirmed - which is exactly the record you want when a client later says they were never asked.
None of the above is legal advice, and nothing in this guide should be treated as guidance on trust accounting or on the rules governing client funds. Confirm the specifics - the engagement letter language, the autopay authorization, the payment routing, card acceptance into trust, retention, debt collection rules, supervision of automated financial communications and the reconciliation cycle - with the firm's own compliance counsel, its bookkeeper or accountant, and against the applicable rules of professional conduct and trust accounting rules in every jurisdiction where the firm practises. If the firm's rules conflict with anything described here, the rules win and the build changes.
Fee arrangement types, the accounting integration, payment routing into trust, autopay and the number of practice areas all move the build, and this one is genuinely advanced. To scope it for a specific firm, book a call at bookings.appbo.io.
Every build on this page is something we configure, test and hand over with the SOPs your team needs to run it.
Book a call