Skip to main content

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

Accounting Account detail illustrating a fictional, separately configured trust-liability account.
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

Accounts-receivable inquiry illustrating transaction history in the current accounting interface.
This ordinary customer inquiry is illustrative accounting infrastructure, not a dedicated trust-account ledger.
Fictional customer detail used only to illustrate the closest current party-ledger record.
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 is the closest current party record, but it is not an inmate or booking account.
  2. Accounting administrator — establish the ledger. Configure dedicated Accounts 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, 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 and reports may support the bank/ledger review, but there is no inmate-level trust reconciliation report.

What Brisk can keep connected today

Reconciliation form illustrating review of a separately configured trust bank account.
A configured bank-account reconciliation can support review, but Brisk has no trust-specific daily reconciliation screen.
Accounting Transactions list illustrating traceable debit and credit history.
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

Date Range Reports screen illustrating cutoff-based review of saved accounting activity.
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.

Start here

Continue with

No comments to display

Back to top