Business Workflows Brisk managed documentation Explore Brisk Workflows Follow complete Brisk workflows using fictional sample data. These examples show how sales, inventory, purchasing, service, ecommerce, accounting, manufacturing, payments, and government records can remain connected from the first action through reporting and follow-up. Demonstration data: Every name, identifier, amount, address, contact, and transaction shown here is fictional. Available steps vary by enabled modules, configuration, permissions, and payment provider. Sales and Retail Each workflow follows saved fictional records and the handoffs needed to verify their downstream effects. Customer Order to Cash — Follow a named customer order through fulfillment, payment or receivable status, inventory activity, and review. This is useful for parts, equipment, feed-and-supply, and general-business teams that need the original request to remain visible. Counter Sale to Reconciled Work Period — Follow a cashier transaction through tender, receipt, operating reports, and work-period close. It separates completing checkout from reviewing whether drawer and period totals make sense. Customer Accounts and Payments Customer Account to Collection — Follow an on-account sale into aging, statements, finance-charge review, and a controlled payment application. It is intended for businesses that extend terms and need traceable collections work. Ecommerce and Fulfillment Online Order to Fulfillment — Follow a storefront order into Brisk’s back-office order, payment review, and fulfillment state. The workflow makes the storefront boundary and the timing of inventory changes explicit. Service and Dispatch Service Request to Paid Invoice — Follow a reported issue through the service order, dispatch, technician activity, billing, and payment. It suits repair, field-service, and equipment-service operations. Purchasing and Payables Automatic Restock to Replenished Inventory — Follow warehouse reorder settings into reviewed draft purchase orders and a partial receipt. It shows where calculation stops and human purchasing judgment begins. Purchase to Pay — Follow an approved inventory purchase through receipt, vendor invoice, and payment allocation. This is the continuation for restocking work once a purchase order enters the normal payable process. Manufacturing and Agriculture Production Plan to Finished Goods — Follow a blueprint and scheduled batch through actual production, component use, finished stock, and cost review. It is aimed at agriculture, feed, light manufacturing, and assembly operations. Accounting and Reporting Month-End Close to Financial Review — Follow operating records from open work periods through a month cutoff and financial reports. It treats close as a controlled review, not a repair button. Government Operations Business License Application to Renewal — Follow a fictional application through review, charge, payment, issue, compliance follow-up, and renewal. It keeps legal decisions with authorized municipal staff while Brisk preserves the operational trail. Jail Banking and Trust Accounts Inmate Trust Account from Intake to Release — Review the accounting controls Brisk can provide for a separately configured trust ledger. Current Brisk has no inmate-account screen or CADMUS integration, so this guide states the boundary instead of presenting unsupported intake, commissary, or release features. See Whether Brisk Fits Your Workflow Brisk is designed around connected day-to-day operations rather than a collection of disconnected tools. A focused demonstration can follow the same kind of work your team performs now. Request a focused Brisk demonstration Sales and Retail Customer Order to Cash This workflow follows a named customer order from entry through fulfillment, payment or receivable status, inventory activity, and financial review. The original request, customer PO, item rows, and downstream records remain traceable, so the next employee can continue from saved work instead of rebuilding it. Demonstration notice: All names, identifiers, amounts, contact information, and transactions shown here are fictional and exist only in the Brisk documentation environment. Payment examples use saved test states and do not contact a processor. Workflow at a glance Outcome A fulfilled sale with a supported payment or receivable state and reviewable downstream history Starts with A verified customer request Ends with Sale, fulfillment, inventory, payment or receivable, and reporting review Primary roles Salesperson, fulfillment clerk, cashier, accounts-receivable clerk Brisk areas involved Customers, Sales, Inventory, Accounting, Payments Common businesses Parts, equipment, feed-and-supply, wholesale, general business Approximate handoffs Three Why this workflow matters A customer order carries more than a total. Staff need the requested items, customer PO, warehouse, price and tax decisions, delivery expectation, and payment terms. When those facts stay on the sale, fulfillment and accounting can work from the same source. The statuses also prevent a common shortcut: treating an entered order as shipped or an initiated payment as collected. Brisk keeps fulfillment and payment status separately, allowing each team to verify its own part. Before you begin Confirm the customer record before relying on its terms, pricing, tax, or credit context. Required: customer, active warehouse, saleable items and units, tax setup, and permission to create and update sales. Required for on-account work: valid payment terms and an authorized credit decision. Optional: price class, customer PO, fulfillment method, email receipt, or sandbox payment provider. Confirm stock separately. The draft documentation sale does not reserve or consume inventory. End-to-end steps DOC-SALE-1001 retains the customer PO, warehouse, lines, totals, fulfillment state, and balance. The sales workspace applies the selected customer and item context before payment or submission. Salesperson — verify the customer. Open Customers . Confirm identity, terms, tax code, price context, account status, credit context, and fulfillment defaults before entering lines. Salesperson — build the order. In Point of Sale or the supported sale form, select the customer and warehouse. Add each item, quantity, unit, price, authorized discount, tax treatment, and customer PO. DOC-SALE-1001 contains two stocked cartridges and remains Draft. Salesperson — review the intended outcome. Confirm totals, fulfillment requirement, requested method, and payment path. Finalize once through the action appropriate to the tender or on-account sale. Do not call a Draft sale a quote; Brisk has a separate Quote record. Fulfillment clerk — act on the saved sale. Use the sale’s fulfillment records and status. Verify the picked quantity and delivery, shipping, or pickup evidence before marking work complete. Inventory is consumed by processed sale fulfillment for qualifying item rows, not by merely opening a cart. Cashier or receivables clerk — record value received. Record a supported tender or leave the finalized sale in Receivable status under authorized terms. A processor launch, URL, or authorization is not settlement. Manager — verify the chain. Review the completed Sale , fulfillment history, item history, customer history, payment application, and Receivable Transactions when the sale is on account. What Brisk keeps connected Inventory history is the place to verify posted item movement; draft order entry alone does not prove movement. The saved sale remains available for operational follow-up rather than being reconstructed from the payment. Action Result or downstream record Where to verify it Select customer and enter rows Customer, PO reference, warehouse, items, pricing, tax, and totals remain on the sale Sale detail Complete supported fulfillment Fulfillment status and processed item movement Sale fulfillment and item inventory history Finalize as Receivable Customer obligation and due-date context Receivable inquiry and customer history Record payment Tender/application history; processor state remains separate when used Sale payment history and provider record Handoffs and controls When a finalized sale is placed on account, accounting verifies the resulting obligation from receivable history. Sales hands the saved sale to fulfillment; fulfillment hands verified completion to accounting or payment staff. Draft, Submitted, Complete, Paid, and Receivable are business controls, not decorative labels. The sale remains the source for customer and line detail, while its fulfillment and payment records are the evidence for those later events. Exceptions and safe corrections Wrong customer or line on a draft: correct the same sale before finalization. Short stock or partial delivery: record only the quantity actually fulfilled and leave the remainder visibly outstanding when the configured path supports it. Uncertain payment response: check both the saved sale and provider history before retrying. Completed error: use the supported return, void, credit, or linked correction. Do not create an unrelated opposite sale. Missing permission or setup: stop at the current state and have the responsible administrator correct access or configuration. Related documentation Start here Customers Point of Sale Continue with Sales Inventory Items Receivable Transactions Related controls and reports Offline POS Queue Receivables, Statements, and Finance Charges Could Brisk Simplify This Process for Your Team? See how this workflow could be configured around your records, permissions, approvals, and reporting requirements. Request a focused Brisk demonstration Counter Sale to Reconciled Work Period This workflow follows a counter sale from the cashier’s cart through tender, receipt, inventory review, operating reports, and work-period close. It shows why checkout is only the first control point: the business must still explain stock movement, tender totals, deposits, payouts, returns, and material differences. Demonstration notice: All displayed names, identifiers, amounts, contact information, and transactions are fictional. Tender results are seeded test states; no live card, ACH, or EMV request is made. Workflow at a glance Outcome A completed sale reviewed within its work-period cutoff Starts with An open workstation, drawer, warehouse, and work period Ends with Close evidence and reports traced to source transactions Primary roles Cashier, shift lead, accounting reviewer Brisk areas involved POS, Sales, Inventory, Cash Drawers, Accounting, Reports Common businesses Retail, parts counters, farm stores, service counters Approximate handoffs Two Why this workflow matters A receipt confirms what the cashier finalized, but it does not explain the whole period. Supervisors still need to compare tender types, deposits, payouts, returns, cash activity, and over/short entries with the saved sales. Brisk keeps those records available under one operating cutoff. That lets staff investigate a difference at its source instead of changing a close total to make it look correct. Before you begin The cashier confirms workstation, drawer, customer, and warehouse context before scanning items. Required: configured workstation, cash drawer, warehouse, open work period, saleable items, tax setup, and cashier permissions. Required: an approved walk-in customer or the correct named customer. Optional: barcode scanner, receipt printer, and sandbox terminal. The Offline POS Queue is a recovery tool, not the normal successful path. End-to-end steps A saved sale preserves lines, pricing, tax, payment, and fulfillment context after checkout. Drawer identity matters because tender activity must be reviewed against the correct physical till. Cashier — confirm operating context. Open Point of Sale . Verify workstation, warehouse, open work period, and the Cash Drawer that matches the physical till. Cashier — build the cart. Select the authorized walk-in or named customer. Scan or search two or three stocked items, then confirm quantity, unit, price, discount authorization, tax, fulfillment, and total. Cashier — accept the actual tender. Select cash or the supported test tender, verify references, and finalize once. Do not retry an uncertain processor attempt until the sale and provider history have been checked. Cashier — verify completion. Review the completed Sale and receipt. Confirm the displayed payment and fulfillment states match what happened, then review item history for the processed inventory effect. Shift lead — review the period. Compare sales, tenders, cash, deposits, payouts, returns, and over/short activity. Use Work Period Reports with one deliberate cutoff. Shift lead or accounting — close after exceptions are resolved. Use Close Accounting Periods to close the intended work period. A closed period is not automatically reconciled; retain the report and explanation for any approved variance. What Brisk keeps connected Apply one defined cutoff before comparing sales, tenders, deposits, and exception totals. The sales register supplies detail behind the period totals. Action Result or downstream record Where to verify it Finalize the cart Saved sale, lines, totals, tender and receipt context Sale detail and receipt Process fulfillment Item movement for qualifying rows Item inventory history Record cash, deposit, payout, or return Period activity with its own source record Drawer and period reports Close the work period Saved cutoff and close detail Work Period detail and close reports Handoffs and controls Closing creates a boundary after staff resolve material differences; it does not reconcile inaccurate source records. The cashier supplies completed sales and physical tender evidence. The shift lead reviews the drawer and exceptions; accounting relies on the saved cutoff and source records. Supervisory overrides require the authorized user—never shared credentials. The sale stays authoritative for checkout while the work period supplies the cutoff. Exceptions and safe corrections Wrong item before finalization: correct the cart. Duplicate-submission uncertainty: search Sales and provider history before retrying. Completed sales error: use the supported return or void tied to the original transaction. Offline ticket: inspect each queued item and live Sales before retrying; do not use Retry All without individual verification. Drawer difference: trace deposits, payouts, returns, tender selection, and timestamps. Closing does not repair missing activity. Related documentation Start here Point of Sale Continue with Sales Cash Drawers Work Periods Related controls and reports Work Period Reports Offline POS Queue Close Accounting Periods Could Brisk Simplify This Process for Your Team? See how this workflow could be configured around your records, permissions, approvals, and reporting requirements. Request a focused Brisk demonstration Customer Accounts and Payments Customer Account to Collection This workflow follows an on-account sale from its source transaction through aging, statement review, approved finance charges, safe collection, and balance application. It keeps the reason for the receivable visible while separating customer communication, provider response, settlement, and accounting application. Demonstration notice: All displayed data is fictional. Email delivery and payment-provider calls are suppressed; pending test records do not represent collected or settled funds. Finance-charge policy requires business and legal review. Workflow at a glance Outcome A customer balance reviewed and reduced through a supported application Starts with An authorized on-account sale Ends with Updated receivable history and an explained remaining balance Primary roles Salesperson, receivables clerk, accounting manager Brisk areas involved Customers, Sales, Receivables, Statements, Payments Common businesses Wholesale, service, parts, property and commercial accounts Approximate handoffs Three Why this workflow matters Collections become unreliable when staff cannot connect a balance to the sale, due date, statement, charges, credits, and payment applications that produced it. Brisk retains that history under the customer instead of reducing the work to one editable balance. Remote payments add another boundary. A request can be created, accepted, settled, and applied at different times. Staff should confirm each state rather than treating a link or uncertain response as cash. Before you begin Terms, contact information, and account status should be correct before extending credit. Required: correct customer, terms, contact information, account status, and authorized credit policy. Required: a finalized sale in Receivable status and a defined report cutoff. Required for charges: configured finance-charge group and payment-term eligibility plus management approval. Optional: configured sandbox email-payment provider or an authorized receivable payment plan. End-to-end steps Aging separates current and overdue balances at a stated cutoff; it is not the live balance by itself. The source sale explains why the customer balance exists. Sales or credit staff — verify the customer. Review Customers , including terms, group, credit limit, email, and account status. Salesperson — finalize the source sale on account. Review the Sale , due-date inputs, and Receivable payment status. Confirm the obligation in Receivable Transactions . Receivables clerk — review aging. In Receivables, Statements, and Finance Charges , set a defined cutoff and review current, overdue, credit, and zero-balance context together. Receivables clerk — preview the statement. Choose the customer and period, inspect opening activity, invoices, payments, credits, charges, and ending balance. The fixture suppresses sending. Accounting manager — decide on finance charges. Use Preview first. Apply only eligible, approved rows from the current preview token; do not use a charge to compensate for bad terms or a missing payment. Authorized collector — record the collection path. Create a sandbox Email Payment or record a safe customer account payment. Confirm provider outcome before treating it as complete. Receivables clerk — apply and verify. Apply the customer credit or payment to the intended receivable, then review the customer inquiry and ending balance. A Customer Receivable Payment Plan is an optional authorized branch, not the default. What Brisk keeps connected The preview is a decision point; policy, terms, dates, and eligibility still require review. Preview the statement before any external delivery and correct source transactions rather than its output. Action Result or downstream record Where to verify it Finalize on account Source sale and receivable obligation Sale detail and receivable inquiry Run aging or statement Cutoff-based presentation of saved transactions Aging report and statement preview Apply a finance charge New customer obligation when approved and applied Applied-charge list and customer history Collect and apply payment Provider/payment record plus receivable application Payment detail and receivable inquiry Handoffs and controls The final inquiry verifies invoices, charges, payments, credits, and the remaining customer position. A saved payment request has a provider state separate from accounting application. Sales establishes the valid obligation; receivables communicates it; management approves policy-sensitive charges; authorized payment staff verify provider results and application. The source sale and receivable transactions remain evidence. Generated statements communicate that evidence but do not alter it. Exceptions and safe corrections Wrong due date or terms: correct approved setup or source data before charging. Statement disagrees with the customer: trace its cutoff, payments, credits, and original sale; regenerate after correction. Pending or failed payment: inspect provider and Brisk states before retrying. Incorrect posted charge: use an approved credit or adjustment that preserves history. Uncertain plan run: verify subscription and transaction history before another attempt. Related documentation Start here Customers Sales Continue with Receivable Transactions Email Payments Customer Receivable Payment Plans Related controls and reports Receivables, Statements, and Finance Charges Could Brisk Simplify This Process for Your Team? See how this workflow could be configured around your records, permissions, approvals, and reporting requirements. Request a focused Brisk demonstration Ecommerce and Fulfillment Online Order to Fulfillment This workflow follows a customer-facing storefront order into Brisk’s back-office order, payment review, fulfillment work, inventory history, and reporting. Checkout crosses a deliberate application boundary, but staff continue from the created Sale and Ecommerce Order without re-entering the customer’s lines and fulfillment choice. Demonstration notice: All storefront and back-office data is fictional. Payment completion, email, webhooks, and carrier actions are simulated or suppressed; no live charge, message, or shipping label is created. Workflow at a glance Outcome A paid-or-reviewed online order completed through its configured fulfillment path Starts with A published product listing in an active storefront Ends with Fulfillment state, item history, customer history, and order reporting Primary roles Shopper, ecommerce clerk, fulfillment clerk, payment reviewer Brisk areas involved Storefront, Ecommerce, Sales, Inventory, Payments Common businesses Retail, parts, equipment, feed-and-supply Approximate handoffs Three Why this workflow matters An online channel creates extra reconciliation work when its products, orders, payment states, and fulfillment records live apart from the operating system. Brisk’s storefront services create a Sale and Ecommerce Order together so back-office staff receive the saved customer and order context. That connection does not erase the payment-provider boundary. Staff still verify whether payment is pending or paid and whether fulfillment is submitted, pending, fulfilled, or complete. Before you begin Only published, correctly priced product listings should enter the customer-facing catalog. Required: active Ecommerce Store, published product listings, customer/tax behavior, ship-from or pickup warehouse, and supported fulfillment configuration. Required: checkout mode and a safe payment configuration. Optional: customer link, shipping provider, carrier/service, or pickup instructions. Inventory is not consumed when an item enters a browser cart. For this path, qualifying inventory movement follows processed Sale fulfillment. End-to-end steps Checkout creates a Brisk sale and ecommerce order; staff work from the back-office order rather than re-keying it. Store setup defines the storefront boundary, fulfillment choices, and checkout configuration. Merchandising staff — verify the storefront record. Review Ecommerce Product Listings , price, publication state, item link, and availability presentation. Shopper — build and submit checkout. Add the fictional stocked products, select one configured fulfillment method, provide fictional contact/address data, review totals, and submit once. Brisk storefront — create the back-office records. Checkout creates a Draft Sale plus an Ecommerce Order . The order holds storefront, sale, order number, customer contact, fulfillment choice, and placed time. Payment reviewer — confirm payment state. A manual unpaid order can move to Payment Pending. Verified successful reconciliation marks the Sale Paid and moves required fulfillment from Draft to Submitted; staff must not infer success from a redirect alone. Fulfillment clerk — prepare the supported method. Work from the order and linked Sale. Pick and verify the actual quantity, then record shipping, delivery, or pickup progress using the configured path. This example does not create a carrier label. Fulfillment clerk and manager — complete and verify. Mark fulfillment only when the real handoff occurred. Review the Order, Sale, item history, customer history, payment event, and ecommerce reporting. What Brisk keeps connected Channel reporting reads the stored orders and states after operational work is recorded. Payment Pending is a control state, not evidence that a processor completed the payment. Action Result or downstream record Where to verify it Submit checkout Linked Sale and Ecommerce Order Order detail and linked Sale Reconcile verified payment Paid Sale and fulfillment-pending order state Payment Events, Order, and Sale Process fulfillment Fulfillment status and qualifying inventory movement Order, Sale fulfillment, item history Complete order Saved channel history and reporting input Ecommerce analytics and customer history Handoffs and controls Verify inventory movement after the sale fulfillment is processed, not when a shopper merely adds a cart line. The shopper submits the request; the storefront persists it; payment staff verify external results; fulfillment staff act on the saved order. The Ecommerce Order is the channel record and its linked Sale carries commercial lines and accounting/inventory behavior. Status must reflect evidence, not staff expectation. Exceptions and safe corrections Incorrect address or fulfillment method: correct the same order before shipment and document the approved change. Payment Pending or failed: review Payment Events and provider state before releasing goods or retrying. Duplicate checkout uncertainty: search by order number, customer, and Sale before resubmission. Stock shortfall: leave the unfulfilled quantity visible and contact the customer through approved channels. Missing warehouse/provider setup: stop; do not invent a tracking number or force a paid status. Related documentation Start here Ecommerce Stores Ecommerce Product Listings Continue with Ecommerce Orders Sales Ecommerce Payment Events Related controls and reports Inventory Items Ecommerce Could Brisk Simplify This Process for Your Team? See how this workflow could be configured around your records, permissions, approvals, and reporting requirements. Request a focused Brisk demonstration Service and Dispatch Service Request to Paid Invoice This workflow follows a reported service problem through the service order, booking, dispatch, technician activity, office review, billing, and payment. The office and technician continue from connected customer, equipment, schedule, time, parts, labor, and billing records instead of rebuilding the job at each handoff. Demonstration notice: Every person, location, item, identifier, amount, and transaction is fictional. Mobile alerts and payments are suppressed or simulated; no message or processor request is sent. Workflow at a glance Outcome Completed service work reviewed, billed, and paid or placed on account Starts with A verified customer, service subject, and reported issue Ends with Billing/payment state and retained customer service history Primary roles Service coordinator, dispatcher, technician, billing clerk Brisk areas involved Service, Dispatch, Time, Inventory, Sales, Accounting Common businesses Equipment, HVAC, appliance, motor, and general repair Approximate handoffs Four Why this workflow matters Service work loses context when intake notes, a schedule, technician time, parts, and the invoice live in separate places. The Service Order retains the work content while bookings coordinate when and by whom it should be performed. Billing remains a deliberate office handoff. A completed technician visit is not automatically a paid invoice, and a timer entry is not necessarily approved billable time. Before you begin Equipment history gives the office and technician the same service subject before a job is created. Required: customer, service location/context, equipment when used, service category/status, warehouse, and authorized service staff. Required for dispatch: active Technician linked to the employee/user and valid working hours. Required for billing: reviewed parts, labor, tax, price, and payment terms. Optional: mobile alerts, customer equipment, timer use, sandbox payment provider. End-to-end steps Dispatch assigns a booking and time without changing the underlying job scope. The service order retains the reported issue, equipment, warehouse, priority, and current work status. Coordinator — verify context. Open Customers and Equipment . Confirm the fictional unit, location, history, issue, and approved scope. Coordinator — create the Service Order. Enter the customer, equipment, warehouse, category, priority, memo, and current Service Status . DOC-SO-1001 is Awaiting Parts; it is not yet completed or invoiced. Dispatcher — create and assign a Booking. Use the Dispatch Board to set the supported date/time and technician. Review dispatch notes and alert state; the documentation fixture does not send a real alert. Technician — work from Technician Workspace. Open Technician Workspace , confirm the assigned booking, then open the same Service Order. Record only actual status, time, notes, parts, and labor. Technician — complete the actual work. Stop the timer, write completion notes, and move status only through the offered transition. Part inventory effects depend on the supported posting/conversion event; adding a note does not consume stock. Office — review and convert. Confirm completed scope, time, parts, labor, prices, tax, and customer authorization. Use the supported Service Order conversion to create/connect the Sale or Service Invoice; the Service Order remains the job-content source. Billing clerk — collect and verify. Record a safe tender or place the invoice on account. Confirm the Sale/Invoice payment state, customer history, item history, time entries, and reporting before calling the workflow paid. What Brisk keeps connected Status, notes, parts, labor, and time should reflect work actually performed before billing. The technician sees assigned bookings and opens the same service order used by the office. Action Result or downstream record Where to verify it Create and schedule job Service Order plus assigned Booking Service Order and Dispatch Board Record technician work Status, notes, time entries, parts/labor context Service Order and Technician Workspace Convert reviewed work Linked Sale or Service Invoice Service Order and resulting billing detail Record payment/on-account balance Payment or receivable history Sale/Invoice and customer inquiry Handoffs and controls Customer history and receivables provide the final accounting check when service is billed on account. Conversion carries reviewed service work into the supported Sale or Service Invoice path; payment is a later state. The coordinator owns intake accuracy, dispatch owns assignment, the technician owns work evidence, and the office owns billing review. Scheduled, dispatched, in progress, completed, invoiced, and paid describe different events. Permission boundaries should prevent a technician from silently rewriting dispatch or accounting decisions. Exceptions and safe corrections Wrong customer/equipment before work: correct the Service Order and Booking together. Missing part: use an honest waiting status; do not mark work completed. Timer left open: correct the time entry with supervisor review before billing. Wrong part or labor: correct reviewed job detail before conversion; use supported credit/return paths afterward. Payment pending or failed: keep invoiced and paid states separate and verify provider history before retrying. Related documentation Start here Service Orders Dispatch Board Continue with Technician Workspace Time Clock Entries Sales Related controls and reports Service Mobile Alerts Receivable Transactions Could Brisk Simplify This Process for Your Team? See how this workflow could be configured around your records, permissions, approvals, and reporting requirements. Request a focused Brisk demonstration Purchasing and Payables Automatic Restock to Replenished Inventory This workflow turns maintained warehouse reorder settings into reviewed purchase orders, a partial receipt, and an updated inventory position. It begins with item and vendor setup and ends when purchasing and receiving can explain what Brisk suggested, what staff approved, what arrived, and what remains open. Demonstration notice: All vendors, items, quantities, identifiers, costs, and transactions are fictional. The documentation run creates controlled draft records and sends nothing to a vendor. Workflow at a glance Outcome Reviewed purchasing work and a traceable partial or complete receipt Starts with Maintained warehouse reorder and vendor settings Ends with Current stock plus visible received and open quantities Primary roles Inventory manager, buyer, receiving clerk Brisk areas involved Inventory, Restock, Purchase Orders, Receiving Common businesses Feed/supply, parts, equipment, retail Approximate handoffs Two Why this workflow matters Reorder settings are useful only when they become reviewable work. Brisk considers warehouse stock and incomplete purchase quantities, groups qualifying items by vendor, and creates draft orders rather than silently sending purchases. Receiving continues from those orders. Staff can distinguish what was ordered, received, and still outstanding before accounting handles the vendor invoice. Before you begin Current purchase quantity, reorder level, maximum, and open purchasing context drive the restock decision. Required: stocked Inventory or Manufactured items, warehouse reorder/maximum quantities, primary vendors, units, and costs. Required: permission to run Restock, review Purchases, and create Receipts. Review incomplete purchase rows and known outside-Brisk orders before another run. Vendor minimums, pack sizes, lead times, and seasonal judgment remain human checks. End-to-end steps The automatic-purchase record preserves evidence that the draft orders came from a restock run. Run restock for one intended warehouse and review the qualifying item/vendor setup first. Inventory manager — review setup. Open the Inventory Item and verify vendor assignment, current purchase quantity, reorder quantity, maximum quantity, unit, and cost for warehouse DOC-W-001. Buyer — run Restock once. Open Restock Form , choose the intended warehouse and vendor scope, then submit. Brisk — calculate suggestions. Inventory and Manufactured items qualify when current purchase quantity plus incomplete purchase-order quantity is at or below the reorder quantity. Suggested quantity fills toward maximum after subtracting stock already in the purchasing pipeline; missing or non-positive maximum setup is skipped. Buyer — review generated work. Open the Automatic Purchase Record and each separate draft Purchase Order created per vendor. Correct quantity, cost, unit, date, pack, and vendor minimum before submission. Authorized buyer — submit the intended order. Submission does not mean the vendor received an external message unless that separate configured action occurred. Receiving clerk — record what arrived. Create an Inventory Receipt from the order. DOC-PO-1001 shows six of ten cartridges received, so its status is Partially Received and four remain open. Inventory manager — verify. Review stock summary, receipt quantity, purchase status, and open pipeline. Continue with Purchase to Pay for the vendor invoice and payment. What Brisk keeps connected A partial receipt keeps the remaining order quantity visible in the purchasing pipeline. Brisk separates qualifying items by vendor into draft purchase orders for human review. Action Result or downstream record Where to verify it Run Restock Automatic-purchase record and draft orders by vendor Automatic Purchase Records and Purchases Review/submit order Approved vendor, warehouse, rows, quantities and costs Purchase detail Receive delivered quantity Receipt rows linked to purchase rows Inventory Receipt detail Process partial receipt Partially Received purchase with remaining quantity Purchase detail and stock summary Handoffs and controls Receiving records what physically arrived; it does not assume the full purchase order was delivered. Inventory owns reorder setup, the buyer owns commercial review, and receiving owns physical quantity evidence. Draft, Submitted, Partially Received, and Received matter. The purchase order is the source for ordered quantity; the receipt is the source for what arrived. Exceptions and safe corrections Item missing from Restock: inspect vendor, type, warehouse quantities, maximum, and open rows. Suggestion looks too large: check UOM, current stock, incomplete orders, and outside-Brisk purchases before editing. Wrong vendor or pack: correct the draft Purchase before submission. Partial or damaged delivery: receive only accepted quantity and retain the remaining exception. Duplicate run uncertainty: inspect Automatic Purchase Records and draft Purchases before running again. Related documentation Start here Inventory Items Restock Form Continue with Automatic Purchase Records Purchase Orders Inventory Receipts Related controls and reports Purchase to Pay Inventory Could Brisk Simplify This Process for Your Team? See how this workflow could be configured around your records, permissions, approvals, and reporting requirements. Request a focused Brisk demonstration Purchase to Pay This workflow follows an inventory purchase from an approved order through a partial receipt, vendor invoice, and allocated payment. Vendor, warehouse, item, quantity, cost, receipt, obligation, and payment evidence remain connected so purchasing, receiving, and accounting can review the same chain without re-entering it. Demonstration scenario Demonstration notice: Every vendor, item, identifier, amount, bank reference, and transaction is fictional. Documentation fixtures persist safe states without sending purchase orders, issuing payments, or contacting external systems. Workflow at a glance Outcome Received inventory, supported vendor obligation, and traceable payment application Starts with Reviewed vendor, item, warehouse, and purchase need Ends with Payment allocation plus any visible remaining amount Primary roles Buyer, receiving clerk, accounts-payable clerk Brisk areas involved Vendors, Purchase Orders, Receiving, Vendor Invoices, Payments Common businesses Retail, feed/supply, parts, equipment, wholesale Approximate handoffs Three Why this workflow matters Purchasing staff know what was ordered, receiving knows what arrived, and accounting sees what the vendor billed. Keeping those records linked makes partial delivery, cost, freight, invoice, and payment differences visible rather than burying them in a single payable total. Each status marks a real control point. A submitted order is not a receipt, a receipt is not a verified vendor invoice, and an allocated partial payment does not make the invoice fully paid. Before you begin Confirm vendor terms and accounting setup before creating the purchase order. Required: valid Vendor , items, units, destination warehouse, payable/fee accounts, terms, and permissions. Required when receipt freight is entered: Receiving Freight Accrual Account preference. Required for final-cost processing: supported vendor and vendor invoice reference. Disable external payment actions in documentation environments. End-to-end steps The order retains the vendor, warehouse, ordered quantity, and remaining quantity after partial receipt. The purchase register shows the order in the purchasing pipeline before receipt. Buyer — verify vendor and need. Confirm vendor, warehouse, requested dates, item, unit, quantity, cost, freight, and total. If the need came from Restock, first review Automatic Restock to Replenished Inventory . Buyer — create and submit the Purchase Order. Create Purchase Order DOC-PO-1001. It begins Draft. Review rows before the supported submission action; submission alone does not prove a vendor received a message. Receiving checkpoint Receiving clerk — record delivered quantity. Convert the order to an Inventory Receipt . DOC-BILL-1001 records six of ten cartridges. Purchase status becomes Partially Received because the receipt total is below the ordered quantity. Receiving/accounting — review receipt costing. Confirm accepted quantity, date, warehouse, BOL, freight, costs, and remaining quantity. Deferred/final-cost processing can require the vendor and vendor invoice number. Accounts payable — enter the vendor invoice. Create Vendor Invoice DOC-BILL-1001 from the vendor document. Verify invoice/due dates, terms, subtotal, amount, receipt links, allocation accounts, and posting state. Authorized payer — record payment. Use Pay Invoice to create Vendor Payment . Check 1001 allocates $50 to the $75 fictional invoice. Confirm account, amount, date, reference, and allocation before posting or issuing anything. Reviewer — verify the chain. Review Purchase, Receipt, Vendor Invoice, credits, payment applications, accounting transactions, and the remaining open quantity/obligation. What Brisk keeps connected The vendor invoice remains Draft until accounting verifies dates, terms, amount, allocation, and receipt support. Receiving records only the six units that physically arrived and keeps their link to the order row. Action Result or downstream record Where to verify it Submit Purchase Vendor/warehouse order with item rows Purchase detail Receive quantity Receipt rows tied to purchase rows; partial status when incomplete Receipt and Purchase detail Record Vendor Invoice Payable document with allocations and receipt support Vendor Invoice detail Allocate Vendor Payment Payment-to-invoice link and remaining unpaid amount Payment and Vendor Invoice detail Handoffs and controls The partial payment retains its invoice allocation while the remaining obligation stays visible. The buyer hands an approved order and delivery expectation to receiving. Receiving supplies quantity and freight/cost evidence to accounting. Accounts payable matches vendor invoice, receipt, and purchase before payment. Purchase, Receipt, Vendor Invoice, and Payment each remain authoritative for their own business event. Exceptions and safe corrections Wrong draft vendor/item/quantity: correct the Purchase before submission. Short delivery: receive only accepted units and keep the order Partially Received. Missing freight account or final-cost inputs: correct configuration/evidence before processing. Duplicate vendor invoice: search vendor and invoice number before creating another. Wrong posted invoice/payment: use the supported credit, void, reversal, or corrected allocation; do not delete material history or create an unrelated opposite record. Related documentation Start here Purchase Orders Continue with Inventory Receipts Vendor Invoices Vendor Payments Related controls and reports Automatic Restock to Replenished Inventory Inventory Navigation Start here Create the purchase order Before this step Begin with automatic restocking Next steps Receive ordered inventory Record vendor payment Review the vendor invoice Could Brisk Simplify This Process for Your Team? See how this workflow could be configured around your records, permissions, approvals, and reporting requirements. Request a focused Brisk demonstration Manufacturing and Agriculture Production Plan to Finished Goods This workflow follows a planned production run from its blueprint and schedule through batch execution, component use, finished inventory, and cost review. Planned and actual states stay distinct, allowing staff to compare what should be produced with what completion actually posted to inventory. Demonstration notice: All formulas, products, quantities, costs, identifiers, and transactions are fictional. The example makes no feed-regulatory or manufacturing-compliance claim. Workflow at a glance Outcome A completed batch with traceable component and finished-stock effects Starts with A reviewed manufactured item and blueprint Ends with Inventory verification, production report, and optional scoped cost review Primary roles Production planner, operator, inventory/cost reviewer Brisk areas involved Manufacturing, Schedule, Inventory, Reports Common businesses Feed, agriculture, assembly, light manufacturing Approximate handoffs Two Why this workflow matters A production note cannot explain expected yield, component quantities, actual output, inventory changes, and calculated cost. Brisk uses the blueprint and Manufacturing Instance to retain those facts as operational records. Completion is the important boundary. The current completion handler consumes configured materials and then adds finished inventory, with flags preventing the same instance from posting those effects again. Before you begin The blueprint defines the component quantities, output unit, expected yield, and instructions used by the batch. Required: manufactured item, component items, units, blueprint, warehouse, mixer when configured, and manufacturing permissions. Confirm expected output, component conversions, shrink, instructions, and costs before scheduling. Optional: Scheduled Manufacturing Instance, printed batch sheet, and narrowly scoped price/cost update. A draft or scheduled instance has no inventory effect in the demonstration state. End-to-end steps The schedule coordinates planned work without pretending the batch has been completed. Scheduling or drafting a batch does not consume components or add finished stock. Planner — review the blueprint. Open Blueprints . Confirm manufactured item DOC-ITEM-002, output unit, quantity, component DOC-ITEM-001, conversions, expected yield, shrink, mixer, and instructions. Planner — schedule production. Create a Scheduled Manufacturing Instance with intended date, warehouse, batch size, and memo. Scheduling coordinates work; it does not post inventory. Operator — review the Production Schedule. Confirm the correct batch, timing, warehouse, and status. Use Batch Sheet Printing for the planned quantities and instructions. Operator — record actual production. Open the Manufacturing Instance , enter supported actual quantities and notes, then mark Complete only after production happened. Brisk — post completion effects. On Complete, the manufacturing signal consumes materials when not already consumed, then adds finished inventory when not already added. The materials consumed and inventory added states remain visible controls. Reviewer — verify inventory and results. Compare component history, finished-item stock, actual output, yield, and the Manufacturing Report . Authorized cost reviewer — optionally update. Use Manufacturing Price and Cost Update only for the intended scope. Review before/after values because submission changes saved costs/prices. What Brisk keeps connected The batch status is the control point for distinguishing planned and completed production. The batch sheet communicates the approved plan to production; actual quantities still need to be recorded. Action Result or downstream record Where to verify it Define blueprint Output, components, units, quantities and instructions Blueprint detail Schedule batch Planned production work Production Schedule Complete instance Component consumption and finished inventory, once Manufacturing Instance and item history Review/update cost Calculated and saved cost context Manufacturing report and scoped update result Handoffs and controls A cost update changes saved values when submitted; scope and before/after amounts require review. Verify components and finished goods in inventory after the completion handler has posted both sides. The planner owns the valid plan, the operator records actual work, and inventory/cost staff verify the result. Draft, scheduled, and Complete are distinct. The blueprint defines the plan; the Manufacturing Instance is the source for the batch and its posting flags. Exceptions and safe corrections Wrong component or unit: correct the blueprint before creating the batch when possible. Actual yield differs: record the supported actual quantity and investigate; do not rewrite the plan to hide variance. Complete chosen too early: stop and use the supported controlled correction; do not manually edit inventory flags. Unexpected stock: inspect instance status, posting flags, conversions, and item history before another completion attempt. Cost scope too broad: cancel before submission and select only the intended records. Related documentation Start here Blueprints Scheduled Manufacturing Instances Continue with Production Schedule Manufacturing Instances Batch Sheet Printing Related controls and reports Manufacturing Reports Manufacturing Price and Cost Update Could Brisk Simplify This Process for Your Team? See how this workflow could be configured around your records, permissions, approvals, and reporting requirements. Request a focused Brisk demonstration Accounting and Reporting Month-End Close to Financial Review This workflow turns daily operating activity into a defensible month cutoff and stable financial review. It begins with open periods and unresolved sales, tender, receivable, payable, inventory, and account activity, then ends with a closed month whose reports can be traced back to saved transactions. Demonstration notice: Every entity, amount, account, date, and transaction is fictional. This guide describes Brisk controls and is not tax, legal, or professional accounting advice. Workflow at a glance Outcome Approved month cutoff with retained close evidence and traceable reports Starts with Defined cutoff and unresolved daily operating records Ends with Closed Month and management financial review Primary roles Shift lead, receivables/payables staff, inventory reviewer, accountant Brisk areas involved Accounting, Sales, Inventory, Purchasing, Reports Common businesses Any Brisk organization using operational accounting Approximate handoffs Four Why this workflow matters A month close cannot make inaccurate sales, missing payments, unreceived inventory, or draft invoices correct. Its value is creating a stable boundary after those records have been reviewed and explained. Brisk keeps daily operations connected to accounting detail. Reviewers can move from a report total back to source transactions instead of accepting an unexplained export. Before you begin Begin month-end review by finding any operating period that has not reached its intended cutoff. Define the local closing date/time and obtain the required approval. Ensure all required Work Periods, Months, accounts, warehouses, and permissions exist. Gather bank statements, tender/deposit evidence, receivable/payable review, inventory receiving/costing review, and approved journal support. Do not backdate or reopen solely to improve screenshots or force a report. End-to-end steps A saved reconciliation supports account review when the feature and source statements are available. Sales, tenders, deposits, payouts, returns, and differences should be reviewed before closing each work period. Close lead — define the cutoff. Record the intended local boundary and use the smallest-period-outward sequence: Work Period, then Month, then Year when applicable. Shift lead — close remaining work periods. In Close Accounting Periods , review sales, tenders, cash, deposits, payouts, returns, tax, and over/short. Resolve open and uncertain transactions before closing. Receivables/payables staff — review obligations. Run aging, customer-credit, vendor-invoice, credit, and payment lists at the cutoff. Investigate Draft/unposted or unmatched records such as DOC-BILL-1001. Inventory and cash reviewers — complete source checks. Review receipts, final costs, adjustments, valuation inputs, deposits, and supported Reconciliations . Reconciliation is included only when configured and supported by source statements. Accountant — review approved journals and reporting inputs. Verify dates, accounts, warehouses/divisions, memo, supporting evidence, and approval. Do not use a journal to hide an operating discrepancy. Authorized closer — close the Month. Select the correct open Month , enter the approved cutoff, and process once. If the request is uncertain, inspect the Month before retrying. Management — review financial output. Review the available profit-and-loss, balance-sheet, trial-balance, transaction, and close reports. Trace material totals to their saved transactions and retain review evidence. What Brisk keeps connected Draft or unresolved payables must be investigated rather than concealed by the month close. Review customer balances and credits at the same defined cutoff used by the close. Action Result or downstream record Where to verify it Close Work Period Operating cutoff and close reports Work Period detail Review receivables/payables/inventory Exception lists tied to source records Aging, invoices, receipts and transaction detail Save reconciliation/journal Account review or approved adjustment evidence Reconciliation and Journal Entry detail Close Month Stable month boundary used by period reporting Month detail and financial reports Handoffs and controls Reports read saved transactions; transaction detail remains the path back to the operational source. Close the month only after source-record review and with the approved cutoff. Operating teams supply accurate source records; accounting tests completeness and cutoff; an authorized closer establishes the boundary; management reviews the result. Closed does not mean reconciled. The individual Sale, Receipt, Invoice, Payment, Deposit, Reconciliation, and Journal Entry remain the evidence behind reports. Exceptions and safe corrections Open period at cutoff: resolve the underlying work and close it in sequence. Payment or deposit uncertainty: verify transaction and provider/bank evidence before retrying. Draft invoice or receipt: determine whether it belongs in the month; do not force-post it. Report mismatch: compare cutoff, warehouse/division, status, and posting versus transaction date. Closed-period error: follow the explicit authorized reopen/correction policy; preserve the original history and approvals. Related documentation Start here Close Accounting Periods Work Periods Continue with Receivables, Statements, and Finance Charges Vendor Invoices Reconciliations Related controls and reports Work Period Reports Transactions Could Brisk Simplify This Process for Your Team? See how this workflow could be configured around your records, permissions, approvals, and reporting requirements. Request a focused Brisk demonstration Government Operations Business License Application to Renewal This workflow follows a fictional business-license application through staff review, a charge, payment, issuance, compliance follow-up, and renewal. It preserves the distinction among the applicant account, official application, amount due, payment, and issued license while keeping each date and status available for reporting. Demonstration notice: Exampleville, DOC-BIZ-1001, all people, amounts, addresses, identifiers, and transactions are fictional. Brisk records authorized municipal decisions; it does not determine legal compliance or provide statutory advice. Workflow at a glance Outcome Issued and later renewed license with traceable charge/payment history Starts with Verified municipal business/account and submitted application Ends with Renewal status and a report tied to source records Primary roles Intake clerk, reviewer, cashier, licensing supervisor Brisk areas involved Municipal Accounts, Applications, Charges, Payments, Licenses, Compliance Common businesses Municipal and local-government offices Approximate handoffs Four Why this workflow matters An application, approval, fee, receipt, issued license, and renewal are different events. Keeping them as linked records prevents a payment from being mistaken for approval or an approved application from being mistaken for an active license. Queues and reports then have a traceable source. Staff can identify pending, expiring, overdue, and completed work without maintaining a parallel spreadsheet. Before you begin Confirm the responsible business and municipal account before accepting an application. Required: Municipal Account , business, license type, jurisdiction process, fee policy, and authorized roles. Required: review criteria and supporting information defined by the jurisdiction outside this guide. Required for collection: municipal charge/accounting setup and a safe authorized payment method. Optional: compliance tasks, auto-renew flag, renewal lead days, and municipal report filters. End-to-end steps The operations queue lets authorized staff review status without treating approval as issuance. Application number, type, submitted date, requested date, and review due date remain distinct. Intake clerk — find the responsible party. Open Municipal Businesses and the linked account. Verify business identity without exposing confidential tax or personal data. Intake clerk — record the Application. Create License Application DOC-BIZ-1001 with type, application number, Draft/Submitted state, submitted date, requested effective date, review due date, and memo. Authorized reviewer — record the actual decision. Move through Submitted and In Review, then Approved or Denied only when the jurisdiction’s work supports it. Brisk does not make that legal determination. Licensing/cashier staff — establish and collect the charge. Create or confirm the linked Municipal Charge . Record a supported payment; its service recalculates Open, Partially Paid, or Paid from payment/credit applications instead of relying on a manual paid label. Licensing staff — issue the License. Convert the approved Application through the supported action. The Application becomes Converted and the License carries its own number, Active status, issue/effective/expiration dates, conditions, and source application. Compliance staff — monitor dated work. Use Municipal License Operations for expiring licenses and compliance tasks. An approved application is not active until the separate license exists. Authorized licensing staff — renew and review. Follow the supported renewal/update path, preserving old history and recording new effective/expiration context. Reconcile the municipal report to account, application, charge, payment, and License records. What Brisk keeps connected The issued License, not the approved Application alone, carries the active status and effective dates. The charge is a separate financial record whose status follows recorded payment applications. Action Result or downstream record Where to verify it Submit/review application Official application status and dates License Application detail Record charge/payment Separate obligation and payment history Municipal Charge and payment detail Convert approved application Issued License linked to source Application License and Application detail Record compliance/renewal Dated follow-up and updated license context Compliance Queue, License, reports Handoffs and controls Municipal reports should reconcile to the underlying account, application, charge, payment, and license records. The queue surfaces dated follow-up while staff remain responsible for the legal decision. Intake verifies identity and completeness; an authorized reviewer owns the decision; cashier staff own payment evidence; licensing staff own issuance and renewal. Draft, Submitted, In Review, Approved, Denied, Converted, Active, Expired, and Paid describe separate controls. The Application is the decision record; the License is the issued credential. Exceptions and safe corrections Duplicate applicant uncertainty: search businesses/accounts and application number before creating another. Missing requirements: keep the application in the truthful pending/review state and document follow-up. Incorrect fee: correct an unposted/open source charge or use approved credit/correction history; never set Paid manually. Payment pending: verify the payment record before issuing when payment is required. Wrong license date/status: use authorized correction or renewal steps and retain the source Application link. Related documentation Start here Municipal Businesses License Applications Continue with Municipal Charges Business License Payments Licenses Related controls and reports Municipal License Operations Could Brisk Simplify This Process for Your Team? See how this workflow could be configured around your records, permissions, approvals, and reporting requirements. Request a focused Brisk demonstration Jail Banking and Trust Accounts 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. 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. 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. 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. 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. 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. Reviewer — preserve corrections. Use an approved reversal or correcting transaction so history remains visible. Current code does not provide a trust-specific reversal screen. 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. 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 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 Transactions Continue with Customers Customer Payments Related controls and reports Reconciliations Work Period Reports Could Brisk Simplify This Process for Your Team? See how this workflow could be configured around your records, permissions, approvals, and reporting requirements. Request a focused Brisk demonstration