--- id: CON-ACC-REC-001 name: Processor Payout feature: FEAT-ACC-REC-01 product_area: accounting module: reconciliation revision: 2 status: draft product_intent: confirmed implementation_evidence: observed source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f definition: >- A payout records the net deposit or debit a payment processor reports for a merchant account. It gives reconciliation a bank movement to explain. owned_by: MOD-ACC-REC synonyms: - deposit - processor deposit - disbursement - bank debit (a negative payout) not_to_be_confused_with: - an operational batch of payments - a bank statement line - a payment facets: - name: Entry origin meaning: Manual entry describes how staff recorded the payout; processor confirmation is a separate fact. used_for: Distinguishing entered information from external confirmation. - name: Bank evidence meaning: 'Verification records agreement or mismatch with the bank, the supporting document and posted day.' used_for: Checking the bank movement and its accounting period. - name: Reconciliation standing meaning: 'Active reconciliation holdings determine whether a payout is waiting, being explained or finalized.' used_for: Finding unfinished work and available actions. - name: Accounting day meaning: The best supported deposit day locates the payout in the books. used_for: Period selection and matching chronology. - name: Duplicate safeguards meaning: Live processor references and acknowledged near-date look-alikes prevent accidental repeated entry. used_for: Reviewing whether a deposit already exists. - name: Supporting documents meaning: Evidence belongs to the payout and becomes protected with finalized money. used_for: Reviewing the reported deposit and bank verification. - name: Entry cancellation meaning: Void keeps the mistaken entry and reason while releasing its processor reference. used_for: Correcting an unheld entry without losing its record. - name: Reference number and activity meaning: Workspace numbering identifies the payout for staff and activity explains committed changes. used_for: Locating records and reviewing responsibility. relationships: - to: CON-ACC-REC-003 statement: A reconciliation supplies the explanation associated with a payout. provenance: observed source: 'services-accounting:modules/reconciliation/services/persistence/payouts.ts' - to: CON-ACC-REC-002 statement: Settlement items provide the money effects used to explain a payout. provenance: observed source: 'services-accounting:modules/reconciliation/services/persistence/payouts.ts' - to: CON-ACC-REC-004 statement: Exceptions record discrepancies or unfinished work concerning the payout. provenance: observed source: 'services-accounting:modules/reconciliation/services/persistence/payouts.ts' - to: CON-ACC-REC-005 statement: Close readiness evaluates payouts as part of the selected period’s work. provenance: observed source: 'services-accounting:modules/reconciliation/services/persistence/payouts.ts' lifecycle: - state: Unreconciled meaning: No active reconciliation holds the recorded payout. how_it_changes: Staff open a reconciliation or void the mistaken entry. - state: In reconciliation meaning: An open draft currently explains the payout. how_it_changes: Finalize or abandon the holding draft. - state: Reconciled meaning: The payout belongs to a finalized explanation. how_it_changes: Reverse that explanation before preparing another. - state: Voided meaning: The entry is retained as a cancellation with its reason. how_it_changes: No subsequent payout lifecycle action is available. acted_on_by: - CAP-ACC-REC-001 - CAP-ACC-REC-002 - CAP-ACC-REC-003 - CAP-ACC-REC-004 - CAP-ACC-REC-008 - CAP-ACC-REC-011 - CAP-ACC-REC-020 visible_to: - ACT-ACC-017 - ACT-ACC-018 - ACT-ACC-007 - ACT-ACC-019 evidence: - >- Inspected concept support: db/payouts.table.ts; services/persistence/payouts.ts, rules/payout-rules.ts; docs/reconciliation/brief.md (Three core concepts), architecture.md §5, §14.1. - >- Inspected concept support: components/accounting/reconciliation/payouts-screen.tsx, add-payout-sheet.tsx, workspace/workspace.tsx. supersedes: [] --- # Processor Payout ## What It Is A payout is the bank movement that finance staff want to explain after a processor settles money collected through a merchant account. Usually the processor sends a deposit. A day with refunds or charges can instead produce a debit, and a net-zero payout can still need an explanation. The payout records that result rather than treating every bank movement as incoming cash. Staff identify it through its payout number, merchant account, processor reference when available, amount and dates. Those details let them compare the processor’s report with the bank and with earlier entries. Manual entry records what staff know now; it does not establish that either external party has independently confirmed the record. Keeping those facts separate is central to reviewing a deposit confidently. ## What It Is Not The payout is the net bank movement, while a settlement item is an individual financial effect contributing to it. Its reconciliation holds the explanation connecting those two views. It also differs from an operational batch, which organizes accounting work for posting. A saved payout alone does not establish bank agreement, successful reconciliation or completed ledger posting. ## How It Is Used A preparer starts with a processor report or bank deposit and records the payout in the correct merchant context. Readers use the payout list to locate it and inspect its standing. The preparer then opens an explanation, while an approver reviews the completed reconciliation. Staff can correct entry mistakes before the financial record is sealed. Bank evidence is a separate review task. The service can record agreement or disagreement, but the current console control sends an incomplete request. A product manager evaluating this workflow therefore needs to distinguish available service behavior from a usable bank-verification screen. The published acceptance proposal must not treat a successful mock badge as proof that the live bank review works. ## Its Facets **Entry origin** explains how the record enters Rhythm and keeps that distinct from processor confirmation. **Bank evidence** supplies the independent statement and posted day supporting verification. **Reconciliation standing** follows the current explanation, while the **accounting day** places the bank movement in the relevant period. Neither is a substitute for understanding the other. **Duplicate safeguards** distinguish a reused processor reference from a deposit that merely looks similar. **Supporting documents** preserve the material an approver needs to inspect. **Entry cancellation** keeps a mistaken payout recognizable without leaving it available for normal work. **Reference number and activity** support later retrieval and responsibility review. ## How It Relates The merchant and bank accounts come from accounting configuration. Reconciliation connects the payout to settlement money, exceptions describe outstanding concerns, and readiness puts those concerns in a period context. Operational batch posting completes the requested accounting entries. These relationships let staff follow one deposit without assuming that every part belongs to the same workflow. ## What It Could Become The product should provide complete bank-evidence entry and a clear path for acknowledging possible duplicates from the console. Processor imports could provide independently reported payout information later. Any extension should preserve the separate meanings of entry origin, bank agreement and reconciliation approval.