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

Fictional sale DOC-SALE-1001 illustrating one of the connected Brisk workflow examples.
Each workflow follows saved fictional records and the handoffs needed to verify their downstream effects.

Customer Accounts and Payments

Ecommerce and Fulfillment

Service and Dispatch

Purchasing and Payables

Manufacturing and Agriculture

Accounting and Reporting

Government Operations

Jail Banking and Trust Accounts

Sales and Retail

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

Customer detail for fictional customer DOC-C-001 showing account and sales context.
Confirm the customer record before relying on its terms, pricing, tax, or credit context.

End-to-end steps

Sale DOC-SALE-1001 showing fictional customer, customer PO, items, Draft fulfillment, and Draft payment status.
DOC-SALE-1001 retains the customer PO, warehouse, lines, totals, fulfillment state, and balance.
Brisk Point of Sale with fictional documentation items ready for order entry.
The sales workspace applies the selected customer and item context before payment or submission.
  1. Salesperson — verify the customer. Open Customers. Confirm identity, terms, tax code, price context, account status, credit context, and fulfillment defaults before entering lines.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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 for fictional item DOC-ITEM-001 used on the customer order.
Inventory history is the place to verify posted item movement; draft order entry alone does not prove movement.
Brisk sales list showing the fictional documentation sale among saved transactions.
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

Accounts receivable inquiry for the fictional documentation customer.
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

Start here

Continue with

Sales and Retail

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

Brisk Point of Sale workspace prepared for a fictional counter transaction.
The cashier confirms workstation, drawer, customer, and warehouse context before scanning items.

End-to-end steps

Fictional sale DOC-SALE-1001 showing item rows and transaction totals.
A saved sale preserves lines, pricing, tax, payment, and fulfillment context after checkout.
Cash Drawers list used to identify the drawer assigned to the fictional register.
Drawer identity matters because tender activity must be reviewed against the correct physical till.
  1. Cashier — confirm operating context. Open Point of Sale. Verify workstation, warehouse, open work period, and the Cash Drawer that matches the physical till.
  2. 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.
  3. 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.
  4. 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.
  5. Shift lead — review the period. Compare sales, tenders, cash, deposits, payouts, returns, and over/short activity. Use Work Period Reports with one deliberate cutoff.
  6. 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

Work Period Reports date-range screen for the deterministic documentation period.
Apply one defined cutoff before comparing sales, tenders, deposits, and exception totals.
Sales list containing fictional documentation transactions for work-period review.
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

Close Work Period screen for a fictional documentation work period.
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

Start here

Continue with

Customer Accounts and Payments

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

Customer detail for fictional customer DOC-C-001 with terms and account context.
Terms, contact information, and account status should be correct before extending credit.

End-to-end steps

Accounts Receivable Aging report for the deterministic documentation cutoff.
Aging separates current and overdue balances at a stated cutoff; it is not the live balance by itself.
Fictional sale DOC-SALE-1001 with an outstanding balance prepared for the collection example.
The source sale explains why the customer balance exists.
  1. Sales or credit staff — verify the customer. Review Customers, including terms, group, credit limit, email, and account status.
  2. Salesperson — finalize the source sale on account. Review the Sale, due-date inputs, and Receivable payment status. Confirm the obligation in Receivable Transactions.
  3. Receivables clerk — review aging. In Receivables, Statements, and Finance Charges, set a defined cutoff and review current, overdue, credit, and zero-balance context together.
  4. Receivables clerk — preview the statement. Choose the customer and period, inspect opening activity, invoices, payments, credits, charges, and ending balance. The fixture suppresses sending.
  5. 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.
  6. 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.
  7. 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

Finance Charge preview screen for fictional eligible receivables.
The preview is a decision point; policy, terms, dates, and eligibility still require review.
Customer Statement form scoped to fictional documentation customer DOC-C-001.
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

Receivable inquiry for fictional customer DOC-C-001 showing account transaction history.
The final inquiry verifies invoices, charges, payments, credits, and the remaining customer position.
Sandbox email payment detail for fictional customer DOC-C-001 with sensitive values masked.
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

Start here

Continue with

Ecommerce and Fulfillment

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

Brisk Ecommerce Products list for fictional documentation products.
Only published, correctly priced product listings should enter the customer-facing catalog.

End-to-end steps

Ecommerce order form showing the back-office fields used for a fictional online order.
Checkout creates a Brisk sale and ecommerce order; staff work from the back-office order rather than re-keying it.
Brisk Ecommerce Stores screen for the fictional documentation storefront.
Store setup defines the storefront boundary, fulfillment choices, and checkout configuration.
  1. Merchandising staff — verify the storefront record. Review Ecommerce Product Listings, price, publication state, item link, and availability presentation.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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

Ecommerce analytics screen based on saved fictional order records.
Channel reporting reads the stored orders and states after operational work is recorded.
Pending-payment ecommerce order queue for fictional documentation orders.
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

Inventory history for fictional stocked item DOC-ITEM-001 used by an online order.
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

Start here

Continue with

Service and Dispatch

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 detail for fictional unit DOC-EQ-001 belonging to the documentation customer.
Equipment history gives the office and technician the same service subject before a job is created.

End-to-end steps

Dispatch board showing fictional service bookings and technician assignments.
Dispatch assigns a booking and time without changing the underlying job scope.
Service order DOC-SO-1001 for the fictional irrigation pump in Awaiting Parts status.
The service order retains the reported issue, equipment, warehouse, priority, and current work status.
  1. Coordinator — verify context. Open Customers and Equipment. Confirm the fictional unit, location, history, issue, and approved scope.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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

Service order edit screen for fictional job DOC-SO-1001 with work details.
Status, notes, parts, labor, and time should reflect work actually performed before billing.
Technician Workspace showing fictional assigned service work and timer context.
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 receivable inquiry used to verify the fictional service invoice balance.
Customer history and receivables provide the final accounting check when service is billed on account.
Linked fictional sale used to illustrate service-order billing after office review.
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

Start here

Continue with

Purchasing and Payables

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

Stock Summary for fictional inventory item DOC-ITEM-001 at the documentation warehouse.
Current purchase quantity, reorder level, maximum, and open purchasing context drive the restock decision.

End-to-end steps

Automatic Purchase Records list showing the retained documentation restock run.
The automatic-purchase record preserves evidence that the draft orders came from a restock run.
Restock Form for fictional warehouse DOC-W-001 with documentation items eligible for review.
Run restock for one intended warehouse and review the qualifying item/vendor setup first.
  1. 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.
  2. Buyer — run Restock once. Open Restock Form, choose the intended warehouse and vendor scope, then submit.
  3. 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.
  4. 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.
  5. Authorized buyer — submit the intended order. Submission does not mean the vendor received an external message unless that separate configured action occurred.
  6. 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.
  7. 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

Purchase order DOC-PO-1001 showing Partially Received status and an outstanding quantity.
A partial receipt keeps the remaining order quantity visible in the purchasing pipeline.
Purchase Orders list containing fictional documentation purchase orders.
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

Inventory receipt DOC-BILL-1001 showing six fictional filter cartridges received.
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

Start here

Continue with

Purchasing and Payables

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

Vendor detail for fictional vendor DOC-V-001 showing purchasing and payable context.
Confirm vendor terms and accounting setup before creating the purchase order.

End-to-end steps

Purchase order DOC-PO-1001 showing Partially Received status and ten ordered cartridges.
The order retains the vendor, warehouse, ordered quantity, and remaining quantity after partial receipt.
Purchase Orders list containing fictional purchase order DOC-PO-1001.
The purchase register shows the order in the purchasing pipeline before receipt.
  1. 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.
  2. 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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. Reviewer — verify the chain. Review Purchase, Receipt, Vendor Invoice, credits, payment applications, accounting transactions, and the remaining open quantity/obligation.

What Brisk keeps connected

Vendor invoice DOC-BILL-1001 for fictional Northwind Office Supply in Draft and unposted state.
The vendor invoice remains Draft until accounting verifies dates, terms, amount, allocation, and receipt support.
Inventory receipt DOC-BILL-1001 showing six fictional cartridges received against DOC-PO-1001.
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

Vendor payment 1001 allocating fifty fictional dollars to invoice DOC-BILL-1001 with bank details masked.
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

Start here

Continue with

Manufacturing and Agriculture

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

Blueprint detail for fictional manufactured item DOC-ITEM-002 and component DOC-ITEM-001.
The blueprint defines the component quantities, output unit, expected yield, and instructions used by the batch.

End-to-end steps

Production Schedule showing fictional documentation manufacturing work.
The schedule coordinates planned work without pretending the batch has been completed.
Draft manufacturing instance for fictional item DOC-ITEM-002 with materials and finished inventory not posted.
Scheduling or drafting a batch does not consume components or add finished stock.
  1. 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.
  2. Planner — schedule production. Create a Scheduled Manufacturing Instance with intended date, warehouse, batch size, and memo. Scheduling coordinates work; it does not post inventory.
  3. Operator — review the Production Schedule. Confirm the correct batch, timing, warehouse, and status. Use Batch Sheet Printing for the planned quantities and instructions.
  4. Operator — record actual production. Open the Manufacturing Instance, enter supported actual quantities and notes, then mark Complete only after production happened.
  5. 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.
  6. Reviewer — verify inventory and results. Compare component history, finished-item stock, actual output, yield, and the Manufacturing Report.
  7. 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

Manufacturing Instances list showing the fictional batch and its status.
The batch status is the control point for distinguishing planned and completed production.
Batch Sheet Printing screen for the fictional Documentation Demo Service Kit.
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

Manufacturing Price and Cost Update screen scoped for deliberate review.
A cost update changes saved values when submitted; scope and before/after amounts require review.
Stock Summary for fictional manufactured item DOC-ITEM-002 after production 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

Start here

Continue with

Accounting and Reporting

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

Work Periods list showing open and closed fictional documentation periods.
Begin month-end review by finding any operating period that has not reached its intended cutoff.

End-to-end steps

Reconciliations list used to review fictional bank and cash account work.
A saved reconciliation supports account review when the feature and source statements are available.
Close Work Period screen for a fictional documentation cutoff.
Sales, tenders, deposits, payouts, returns, and differences should be reviewed before closing each work period.
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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

Fictional vendor invoice DOC-BILL-1001 retained in Draft and unposted state.
Draft or unresolved payables must be investigated rather than concealed by the month close.
Accounts Receivable Aging report for the fictional closing cutoff.
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

Accounting Transactions list supporting a fictional post-close financial review.
Reports read saved transactions; transaction detail remains the path back to the operational source.
Close Month screen for the deterministic documentation accounting month.
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

Start here

Continue with

Government Operations

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

Municipal Businesses list containing fictional documentation business DOC-BIZ-1001.
Confirm the responsible business and municipal account before accepting an application.

End-to-end steps

Municipal License Management queue showing fictional application and license states.
The operations queue lets authorized staff review status without treating approval as issuance.
License Application form for fictional application DOC-BIZ-1001 in Exampleville.
Application number, type, submitted date, requested date, and review due date remain distinct.
  1. Intake clerk — find the responsible party. Open Municipal Businesses and the linked account. Verify business identity without exposing confidential tax or personal data.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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

Municipal Licenses list containing the fictional issued license and expiration date.
The issued License, not the approved Application alone, carries the active status and effective dates.
Municipal Charges list showing fictional business-license fee records.
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 screen used to review fictional license and payment records.
Municipal reports should reconcile to the underlying account, application, charge, payment, and license records.
Municipal Compliance Queue showing fictional upcoming and incomplete license work.
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

Start here

Continue with

Jail Banking and Trust Accounts

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

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.

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

Start here

Continue with