Trust Operations
Trust Operations is the firm-wide trust ledger. It renders the same unified trust ledger as the per-matter Trust tab — one sortable row per trust ledger entry (receipts, payments, transfers, reversals) — but across every matter, with a durable per-firm entry number (”#”) that stays fixed when you sort or filter. It is also the canonical surface for creating, reversing and correcting multi-matter trust transactions (one deposit or cheque split across several matters).
The ledger
Section titled “The ledger”One row per trust ledger entry, firm-wide, with the unified column model: Date · # · Type/Acct · Party/Matter · Method/Ref · Description · Receipts / Payments / Reversals · Balance. Sort by Date, #, Type, trust account or Matter; filter by Type and trust account. The running Balance is the per-trust-account chronological balance and ties to the consolidated trust ledger and the General Ledger.
- Per-row Matter link — every row shows and links to the matter it belongs to.
- Multi-matter rows — an allocation of a multi-matter receipt or cheque appears as its own per-matter row tagged with a teal Multi-matter chip; click it to see the parent transaction and every sibling allocation.
- Detail popover (the ⓘ button) — Status, full method, reference, notes, reconciliation and FX detail without leaving the table.
Exporting the ledger
Section titled “Exporting the ledger”Export ▾ (top-right of the ledger) downloads the ledger as CSV or PDF. The file uses the exact on-screen column model in order — Date, #, Type, Account, Party, Matter ID, Method, Reference, Description, Receipts, Payments, Reversals, Balance — followed by a totals row that matches the on-screen footer. The same Export control appears on the per-matter Trust tab and downloads that matter’s full trust ledger.
The export is the full scope shown (firm-wide on this page; the whole matter on the Trust tab); the on-screen Type and trust-account filters are not applied to the downloaded file.
Notes are a screen-only field and are intentionally excluded from every downloaded report (both CSV and PDF). Notes remain available on screen via the row’s notes icon and the ⓘ detail popover.
When to use this page
Section titled “When to use this page”| Scenario | Path |
|---|---|
| Review all trust activity firm-wide | Trust Operations (this page) |
| Single-matter receipt or payment | Matter → Trust Accounting tab (or here) |
| One settlement cheque covering several matters | Trust Operations (this page) |
| Bulk deposit allocated across several files | Trust Operations (this page) |
| Same-client matter-to-matter transfer | Matter → Trust Accounting → “Transfer to another matter” |
| Cross-client matter-to-matter transfer | Same action — but both clients must first sign a consent, and the amount is held (earmarked) on the source matter while it is pending. See Cross-client transfers, consents & holds. |
Actions
Section titled “Actions”Trust Receipt and Trust Payment use the same unified entry form as the per-matter Trust tab — identical field order everywhere you record trust money, so there is nothing new to learn between surfaces.
Trust Receipt
Section titled “Trust Receipt”Records a deposit, optionally allocated across two or more matters. Form fields, in order:
- Trust account — source/destination account; its currency is shown read-only (you never type the currency).
- Date
- Method and Reference
- Payor participant (optional) — tag who sent the funds, or skip for ad-hoc payors — then the free-text “Received from” name.
- Allocations — one row per matter, each with amount, an inline retainer flag, and optional description. The form rejects allocation sets whose sum doesn’t equal the parent total.
- FX details — only when the deposit arrived in a different currency from the trust account (source currency excludes the account currency).
- Notes
Trust Payment
Section titled “Trust Payment”Same form and field order as receipts but the money goes out, and the
participant field becomes the Payee participant (which surfaces that
participant’s saved banking methods; banking details are required for
methods the firm has flagged as needing them). Admins also get a
negative-balance override field when it applies. Disbursements posted
with method=cheque auto-claim the next sequence number on the source
trust account; the Print cheque action generates the printable PDF.
This is where a cost paid from a client’s trust funds is recorded — not on the matter’s Disbursements tab. A disbursement is the firm’s money, advanced on the client’s behalf and recovered on an invoice; the client’s trust money was never the firm’s to recover, so paying a cost from it is a trust payment on this ledger and never becomes a recoverable cost or an invoice line. See Costs paid from the client’s trust money are not disbursements.
Print on post (print now or print later)
Section titled “Print on post (print now or print later)”For a cheque disbursement you can either:
- Save and post — post the entry now and print the cheque later from the transaction’s row in the Trust Operations ledger (the Print cheque action on the row).
- Post & print cheque — post the entry and immediately open the print dialog seeded with the just-posted cheque, so you print without leaving the flow.
Once a cheque has been printed, the print dialog records the print and its action changes from Print cheque to Reprint cheque — so it’s clear the cheque was already produced, with reprint available if a sheet jams. If a sheet misprints on pre-printed stock, mark the physical cheque VOID and use Misprint — void & use next number to claim the next sequence number (the voided number is permanently consumed and audit-logged).
This mirrors the industry-standard workflow: the Trust Check screen carries a Print button on the posting form itself, separate from the final OK that saves the entry, so cheques can be printed at post time or later.
Correct entry (reverse-and-replace)
Section titled “Correct entry (reverse-and-replace)”The trust ledger is append-only — corrections don’t mutate the existing rows. Instead, the entry is atomically reversed and a fresh corrected entry is posted, linked back to the original. The original stays in the audit trail.
Reverse
Section titled “Reverse”The trust ledger is append-only — a reversal appends offsetting rows and never deletes the original. The reverse action is type-aware so a multi-matter row never hits a single-entry endpoint:
| Row type | What gets reversed |
|---|---|
| Multi-matter allocation | The parent transaction and every sibling allocation, atomically |
| Matter-to-matter transfer | Both legs of the transfer pair, atomically |
| Ordinary trust entry | Just that entry |
The per-matter ledgers show both the original and the offsetting reversal rows.
Status badges
Section titled “Status badges”| Badge | Meaning |
|---|---|
| Cleared | Default for posted activity |
| Pending | Recorded but not yet reconciled against the bank statement |
| Reversed | The parent and all children have been atomically reversed |
| Override | Admin allowed the transaction to post even though one or more matter allocations would have gone negative (requires org-level opt-in under Settings → Trust → Allow negative trust balances) |
| Retainer / Retainer (partial) | One or more allocations are retainer contributions |
Permissions
Section titled “Permissions”- View + create + edit + reverse + print — Owner, Admin, Accountant
- Negative-balance override — Owner, Admin only
Troubleshooting
Section titled “Troubleshooting”| Symptom | Likely cause |
|---|---|
| ”Allocations must sum to the parent total” | The per-matter amounts don’t add up. Either adjust an allocation or change the parent total. |
| ”This posting would push … into a negative trust balance” on a disbursement | One or more matter allocations would take that matter’s trust below zero at some point on or after the posting date — not just today. The message names every affected matter and the date each one first goes negative. Either reduce those allocations, top up the matter’s trust first, or have an owner/admin record a negative-balance override (org-level opt-in required). |
| ”This posting would spend through funds held pending client consent” | The shortfall reaches money earmarked by an active consent hold. A negative-balance override cannot clear this, whatever your role — void or release the pending consent hold first, then re-post. |
| A back-dated or edited transaction is refused even though the balance looks fine today | Trust balances are checked across the whole period from the posting date forward, so a transaction that leaves a matter negative for a stretch in the past is refused even when its closing balance recovers. Editing a posted transaction is a reverse-and-replace, and the reversal is dated the UTC calendar day the edit is made — which is not always your local day. Between 8:00 pm and midnight Eastern (7:00 pm in winter) the UTC date has already rolled over, so an edit made in that window carries tomorrow’s date. The replacement and the original overlap until the reversal’s date, whichever day that turns out to be. Move the posting date, or top the matter up for the affected window. |
| Cheque sequence number skipped | The trust account’s next_cheque_number claims one sequence number per posted disbursement, regardless of whether the cheque is printed. Reversals don’t release the sequence number — they’re part of the audit trail. |