Settings — Trust Accounting

The Settings ▸ Trust Accounting page is the admin surface for managing IOLTA trust accounts, monthly bank reconciliations, retention policy, and the manual two-admin purge workflow.

The single most important thing about this page: the platform never auto-purges. Every retention purge is an explicit two-admin decision captured in the audit log. This is by design to satisfy provincial bar expectations around evidence preservation and intentional destruction.

Anatomy of the page

1. Page header

Standard PageHeader with the title Trust Accounting and a multi-line description that emphasizes the never-auto-purge guarantee.

2. Six-tab layout

The page composes six independent surfaces under one Tabs container:

Tab	Contents
Dashboard	Trust balances, last recon dates, pending purge counts
Trust Accounts	CRUD on IOLTA account records + bank linkage
Reconciliations	Monthly bank-vs-ledger-vs-liability recon list
Retention Policy	Org-wide policy radio group + Save
Purge Eligibility	Records past the retention window
Pending Requests	Two-admin purge request queue

Tabs persist in the URL via the standard Tabs component pattern.

Trust accounts

Each row captures:

• Display name
• Bank (selected from a jurisdiction-approved list)
• Masked account number
• Currency (CAD / USD typical)
• Status (Active / Closed)
• Last reconciled timestamp

The Add Account button opens an inline form. Edits and closures happen from the row menu.

Cheque printing

Each bank account carries its own cheque-printing setup, used when you print a cheque for a trust payment. Most firms print onto pre-printed stock — the bank/supplier pre-prints the borders, field titles, MICR line and the cheque number, and Athenty lays down only the variable data (date, payee, amounts, memo). This mirrors industry-standard accounting software.

Pre-printed stock design. Pick the design that matches your physical cheque stock and the print layout follows it automatically — the same model the standard stock catalogue uses. Equivalents to the common Deluxe Canadian designs are built in:

Stock design	Layout
Stub · Cheque · Stub	Cheque with a stub on each side
Cheque · Cheque · Cheque	Three cheques per page
Cheque · Stub · Stub	Cheque on top, two voucher stubs below
Stub · Stub · Cheque	Two voucher stubs, cheque on the bottom
Deluxe HSL9037 (Canada)	Stub / Cheque / Stub
Deluxe HS9209 (Canada)	Cheque / Stub / Stub

Choose Custom to drive the layout yourself instead of from a design. The chosen design is the account default; the accounting manager can override it per cheque in the Print cheque dialog.

Alignment. If your printer lands the data slightly outside the pre-printed boxes, nudge it with the per-account Align X / Align Y offsets (millimetres; +X right, +Y down). Always print at actual size (100%, “fit to page” off).

Cheque numbering — automatic but editable. Athenty assigns the next cheque number automatically from the account’s sequence. You can edit the Next cheque number to sync with a fresh pad of pre-printed stock. When you change it, Athenty asks you to confirm a sequence reset — confirm to continue numbering from the new value (recorded in the audit trail as a CHEQUE_SEQUENCE_RESET), or keep the current sequence to discard the edit. If a printed cheque misfires, mark the physical cheque VOID and use Misprint — void & use next number in the Print cheque dialog: the old number is permanently consumed and the cheque claims the next one.

Reconciliation model

A clean monthly recon ties three numbers:

bank statement balance  ==  ledger debits − credits  ==  Σ per-client liabilities

When all three match, the recon status is Reconciled. Any drift flips it to Discrepant, and the recon detail page surfaces a per-line-item breakdown to identify the source.

Retention policy

Policy options reflect Canadian provincial bar requirements:

Policy	Window	Notes
5 years	5y from matter close	Minimum for several provinces; confirm with your bar
7 years	7y	Common middle-ground (LSO, FLSC)
10 years	10y	Covers every Canadian provincial bar including BC LawSociety
Permanent hold	∞	Trust ledger never becomes purge-eligible

The default is 10 years. A change to the policy affects future eligibility — already-eligible records remain eligible until purged or held.

Each save emits org.trust_retention_updated to the audit log.

Purge eligibility

Records become eligible for purge <retention-window> after the matter closes. Eligibility surfacing is informational — nothing happens automatically. The Eligibility tab lists every eligible record with a Request purge button.

Two-admin purge workflow

The deliberate two-admin gate:

1. Admin A clicks Request purge on an eligible record
2. A request lands in the Pending Requests tab
3. Admin B (different user_id) reviews and either approves or declines
4. On approve:
   • Trust ledger entries are cryptographically destroyed
   • The audit event captures both requested_by and approved_by
5. On decline:
   • The request is closed with the decline reason
   • The record remains in the Eligibility queue

The same-admin guard is enforced server-side. Attempting to approve your own request returns a 403 with error: "self_approval_forbidden".

Permissions and scope

Role	View	Configure	Request purge	Approve purge
Owner	✓	✓	✓	✓
Admin	✓	✓	✓	✓ (different admin from requester)
Member	✗	✗	✗	✗
Viewer	✗	✗	✗	✗

Audit logging

Every action emits an audit event:

• org.trust_retention_updated — policy change with diff
• trust.account_created / trust.account_closed
• trust.reconciliation_completed / trust.reconciliation_discrepant
• trust.purge_requested (with requester ID)
• trust.purge_approved (with both requester and approver IDs)
• trust.purge_declined (with decliner ID + reason)

Events surface in Settings ▸ Audit Log. Trust events are particularly important — exporting them is the easiest way to satisfy a bar audit’s evidence ask.

Troubleshooting

Symptom	Most likely cause	Fix
Recon flagged Discrepant	Three balances diverge	Open detail; per-tab breakdown identifies the source
Cannot approve purge	You requested it	Different admin must approve
Record stays Eligible after purge	Cache stale	Refresh the tab
Permanent hold setting reverts	Save failed	Re-save; check toast for cause
Purge request reappears after decline	Was re-submitted	Re-evaluate or decline with a clearer reason

Related pages

• Settings ▸ Compliance — litigation hold (adjacent retention surface)
• Settings ▸ Audit Log — trust.* events
• Matters — closing a matter starts the retention clock