# Inmate Trust Account from Intake to Release
Brisk’s current accounting foundation can be configured as a separate secondary ledger for controlled trust activity, but the current product does not provide an inmate-account workflow from intake to release. This page explains the closest supportable accounting pattern and the product boundary so staff and prospects do not mistake a demonstration ledger for a jail-management integration.
> **Important demonstration boundary:** All names, identifiers, amounts, and transactions are fictional. Current Brisk has no inmate or booking record, commissary transaction, intake/release workflow, trust-specific permission set, or CADMUS JMS synchronization. Do not present Brisk as replacing a JMS or as having an official CADMUS partnership.
Workflow at a glance
| | |
|---|---|
| **Outcome** | A proposed, separately configured accounting ledger with explicit unsupported steps |
| **Starts with** | Approved trust-account design and manual identity controls outside Brisk |
| **Ends with** | Generic ledger/reconciliation review; release disbursement remains unsupported as a dedicated workflow |
| **Primary roles** | Authorized trust clerk, accounting reviewer, administrator |
| **Brisk areas involved** | Ordinary Accounting, Customers, Payments, Reports |
| **Common organizations** | Detention facilities evaluating a secondary ledger only |
| **Approximate handoffs** | Configuration-dependent; not implemented end to end |
Why this workflow matters
Trust funds require a balance that can be traced to approved deposits, deductions, corrections, and disbursements. Direct balance edits or deleted history would undermine that review. Brisk’s double-entry accounting and transaction history can support a carefully designed separate ledger.
However, general accounting records do not supply detention-specific identity, booking lifecycle, commissary authorization, release controls, or statutory compliance. Those remain with the facility’s JMS and approved operating procedures unless a future, reviewed integration is built.
Before you begin
A dedicated chart-of-accounts design is a prerequisite; it is not an inmate-account feature by itself.
- Obtain accounting, legal, security, and correctional-operations approval for the ledger design.
- Define dedicated bank, trust liability, clearing, fee, and disbursement accounts plus segregation-of-duties rules.
- Keep authoritative resident, booking, custody, release, and commissary data in the JMS. Current Brisk entry would be manual or separately imported through a reviewed process; no CADMUS sync exists.
- Configure least-privilege accounting access and never place sensitive criminal, medical, or identity data in the documentation dataset.
Supported accounting pattern and unsupported handoffs
This ordinary customer inquiry is illustrative accounting infrastructure, not a dedicated trust-account ledger.Current Brisk can use ordinary party/accounting records, but it has no inmate or booking-specific master record.
1. **Authorized staff — confirm identity outside Brisk.** The JMS remains authoritative for resident, booking, custody status, and release. An ordinary [Customer](https://help.brisksystems.us/link/2680#bkmrk-overview) is the closest current party record, but it is not an inmate or booking account.
2. **Accounting administrator — establish the ledger.** Configure dedicated [Accounts](https://help.brisksystems.us/link/2567#bkmrk-overview) and a bank account under an approved trust-account design. Do not mix operating revenue with trust liabilities.
3. **Trust clerk — record a deposit only through an approved accounting transaction path.** Current Brisk has no inmate-deposit screen or trust receipt. A customer payment or journal-based pattern would require human design, permissions, and validation before production use.
4. **Trust clerk — record approved deductions through the designed source transaction.** There is no commissary, fee, withdrawal, or inmate-purchase workflow in current code. Never edit a balance directly or label an ordinary sale as an integrated commissary event.
5. **Reviewer — inspect the ledger.** Use [Transactions](https://help.brisksystems.us/link/2591#bkmrk-overview), account detail, and approved reports to trace debits and credits. The repository’s reporting demo contains an “Inmate Trust Checking” example, but that seed is reporting content—not a product module.
6. **Reviewer — preserve corrections.** Use an approved reversal or correcting transaction so history remains visible. Current code does not provide a trust-specific reversal screen.
7. **Authorized staff — handle release outside the claimed Brisk workflow.** Current Brisk has no release/transfer event or final trust disbursement feature. A facility must not rely on this demonstration to close an account or issue funds.
8. **Accounting reviewer — reconcile configured accounts.** A generic [Reconciliation](https://help.brisksystems.us/link/2587#bkmrk-overview) and reports may support the bank/ledger review, but there is no inmate-level trust reconciliation report.
What Brisk can keep connected today
A configured bank-account reconciliation can support review, but Brisk has no trust-specific daily reconciliation screen.Every implemented balance change should be represented by an approved transaction rather than direct balance editing.
| Action | Result or downstream record | Where to verify it |
|---|---|---|
| Configure dedicated accounts | Separate accounting structure | Account and bank-account detail |
| Save an approved accounting entry | Debit/credit history | Transaction detail and account activity |
| Record a correcting entry | Preserved correction trail | Original and correction transactions |
| Reconcile a configured bank account | Generic reconciliation record | Reconciliation detail and reports |
No current code connects those records to a booking, commissary order, release, or CADMUS JMS record.
Handoffs and controls
Generic reports can support a configured ledger; they do not create detention-specific controls or compliance.
The JMS and detention staff remain authoritative for identity and custody events. Authorized trust staff would originate approved financial evidence; accounting would review posting and reconciliation; administrators would control access. The accounting transaction is the Brisk source of truth for recorded value, but it cannot validate the underlying custody event.
Exceptions and safe corrections
- Identity or booking mismatch: stop and resolve it in the authoritative JMS before any financial entry.
- Duplicate deposit uncertainty: search transactions and receipt evidence before entering again.
- Incorrect amount: use an approved reversal/correction; never delete material financial history or overwrite a balance.
- Unclear commissary/fee authority: do not post until the facility validates the source and account treatment.
- Release or transfer: use the facility’s approved non-Brisk process until dedicated functionality exists.
- Reconciliation difference: trace each transaction and cutoff; do not create an unsupported plug entry.
Related documentation
### Start here
- [Accounts](https://help.brisksystems.us/link/2567#bkmrk-overview)
- [Transactions](https://help.brisksystems.us/link/2591#bkmrk-overview)
### Continue with
- [Customers](https://help.brisksystems.us/link/2680#bkmrk-overview)
- [Customer Payments](https://help.brisksystems.us/link/2571#bkmrk-overview)
### Related controls and reports
- [Reconciliations](https://help.brisksystems.us/link/2587#bkmrk-overview)
- [Work Period Reports](https://help.brisksystems.us/link/2951#bkmrk-overview)
