Record cash intentionally removed from a register for a business purpose and identify the employee responsible.
## At a glance
- **Identify it by:** **Amount**, **Employee**, **Memo**, and **Processed**.
- **Check its business context:** **Employee**.
- **Why care:** Customer, warehouse, quantities, prices, tax, payment, and fulfillment represent different parts of the transaction. Review each before treating the sale as complete.
- **Why care:** Treat posted, processed, paid, reversed, and edit-locked states as controls—not ordinary descriptive fields. Confirm the source transaction before changing any state that the screen permits you to change.
## Before you begin
You need the Brisk permission for the action you are taking on payouts. If a Create, Edit, or Delete control is absent, do not work around it with another user’s account; ask an administrator to review your role.
Have valid **Employee** records ready first. Those selections determine where this Payout belongs and which later screens can find it.
Create a Payout
The Payouts create screen in the Brisk documentation demo.
Create a Payout only after confirming that the source document or operational event has not already been entered.
1. Select the business context first: **Employee**.
2. Enter the required identifying and operational values: **Amount**, **Employee**, and **Memo**.
3. Review **Processed** deliberately; these choices control availability or workflow rather than merely describing the record.
4. Save the Payout, then confirm **Amount**, **Employee**, and **Memo** on its detail page before continuing.
After saving: Verify **Processed**, and **Employee** on the detail page, then continue the sales workflow only when those values agree with the source document and actual work performed.
Delete a Payout
Delete this Payout only when it was entered by mistake and no downstream history depends on it. Use a reversal, void, credit, counter-adjustment, or status correction for a real event that later changed.
Before confirming, check for related **Transactions**. Brisk may refuse deletion when another record depends on this one; resolve the duplicate or use the supported correction workflow instead of breaking the trail.
On the confirmation page, verify **Amount**, **Employee**, **Memo**, and **Processed**. After confirmation, return to the Payouts list and make sure only the intended Payout was removed.
Review Payout details
Use the detail page as the shared record of what this Payout currently means. Verify **Amount**, and **Processed** before relying on it for a decision.
Follow **Employee** to determine whether the issue is on this Payout or on one of those linked records.
Next check: Verify **Processed**, and **Employee** on the detail page, then continue the sales workflow only when those values agree with the source document and actual work performed.
Edit an existing Payout
Edit this Payout to correct or complete the same source document or operational event; use the supported reversal or follow-up workflow when the business event itself changed.
1. Open the detail page. Compare **Employee** with the supporting document or approved request.
2. Recheck **Amount**. These values are most likely to change customer totals, tax, payment, fulfillment, and receivables.
3. Save the change, return to the list, and confirm that the Payout now appears under the expected **Processed**.
After the change: Verify **Processed**, and **Employee** on the detail page, then continue the sales workflow only when those values agree with the source document and actual work performed.
Find and review payouts
The Payouts list screen in the Brisk documentation demo.
Use the Payouts list to find the correct record before opening or changing it. Compare **Amount**, **Employee**, **Memo**, and **Processed**. Records with similar names or numbers can still belong to different **Employee**.
- The initial order emphasizes **Id**. Select a column heading when you need a different comparison.
Open the Payout whose **Amount**, **Employee**, **Memo**, and **Processed** match the task. If it is missing, clear the list filters and recheck **Processed** rather than creating a replacement immediately.
## Fields and business rules
Brisk stores 4 user-relevant fields for this Payout, including 1 linked-record selection and 0 controlled-choice fields. Create and edit screens may hide calculated or workflow-managed values from this full reference.
| Field | Required | What it controls |
|---|---:|---|
| **Amount** | Yes | The amount value recorded for this payout. |
| **Employee** | Yes | The employee that performed this payout. |
| **Memo** | Yes | Reason/information as to why this money was taken from the register. |
| **Processed** | No | Whether the processed option applies to this payout. |
## What happens next
Verify **Processed**, and **Employee** on the detail page, then continue the sales workflow only when those values agree with the source document and actual work performed.
## Common mistakes and troubleshooting
- **The record will not save:** Recheck **Amount**, **Employee**, and **Memo** and any message beside the field. A required related record may also be inactive or unavailable to your role.
- **The record saved but is not available where expected:** Recheck **Processed**, then clear the filters on the destination list. A saved record can still be inactive, unpublished, locked, unapproved, or in the wrong workflow state.
- **The values look right but the result is wrong:** Open **Employee** from the detail page. Correct the specific relationship that is wrong instead of forcing a total or status to compensate for it.
