--- id: DOM-ACC-REC-001 title: Processor Payout realises: CON-ACC-REC-001 product_area: accounting module: reconciliation revision: 3 status: draft design_intent: proposed implementation_evidence: observed source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f owned_by: SVC-ACC-REC-reconciliation readable_by: [] lifecycle: STATE-ACC-REC-001 custom_fields: none identity: >- The service assigns a time-ordered identity and a unique workspace number. A merchant’s live payouts also have distinct processor references; a void releases that reference. attributes: - name: number kind: number required: true computed: true notes: >- The next available workspace number is assigned on creation and remains fixed. - name: business unit kind: reference required: true computed: true notes: 'The merchant supplies the business unit, which remains fixed.' - name: merchant account kind: reference required: true computed: false notes: >- The originating processor account determines the unit, currency and processor; entry requires an active account. - name: currency kind: enum required: true computed: true notes: Currency is copied from the merchant and remains fixed. - name: payment processor kind: reference required: false computed: true notes: Processor identity and account reference are copied when present. - name: processor payout reference kind: text required: false computed: false notes: >- This optional external reference detects duplicate live payouts for the merchant. - name: bank account kind: reference required: false computed: false notes: >- The destination must share the unit and currency; entry and finalization can use the merchant’s default bank. - name: net amount kind: money required: true computed: false notes: 'Signed whole minor units represent a deposit, debit or zero amount.' - name: 'reported, expected and processor funding dates' kind: date required: false computed: false notes: >- Entry requires the reported deposit date; expected arrival and processor funding dates are separate optional facts. - name: bank posted date kind: date required: false computed: false notes: Verification records the bank’s posting day. - name: accounting date kind: computed required: true computed: true notes: >- Verified bank posting takes precedence, followed by the reported deposit day and then funding day. - name: origin kind: enum required: true computed: true notes: >- Creation uses manual origin; import origins are reserved and cannot be changed later. - name: processor status and confirmation kind: enum required: false computed: false notes: No current payout command fills these import fields. - name: bank verification kind: enum required: true computed: false notes: >- The stored outcome distinguishes no verification, agreement and disagreement, with verifier and time. - name: 'description, bank description and notes' kind: text required: false computed: false notes: >- Staff can retain explanatory text; full banking credentials are outside this record. - name: acknowledged look-alikes kind: collection required: false computed: false notes: >- Creation retains the existing payouts staff acknowledged as distinct deposits. - name: void kind: collection required: false computed: false notes: 'Cancellation retains its time, actor and reason.' - name: returned payout reference kind: reference required: false computed: false notes: >- A future return may refer to another payout; this reference has no database foreign key. - name: evidence files kind: collection required: false computed: false notes: >- Up to fifty record assets document the payout; finalized holdings prevent evidence changes. - name: reconciliation status kind: computed required: true computed: true notes: >- The active holder determines unreconciled, in preparation or reconciled standing. - name: available actions kind: computed required: true computed: true notes: Each read intersects state eligibility with the caller’s command grants. - name: version kind: number required: true computed: true notes: >- Version checks apply where the command takes an expected version; evidence attachment increments it without requiring one. relationships: - to: DOM-ACC-REC-003 cardinality: >- many-to-many historically; each payout has at most one active reconciliation ownership: >- The explanation owns its holding references and preserves released history. cross_service: false - to: DOM-ACC-REC-002 cardinality: 'many-to-many, through the reconciliation that explains the payout' ownership: >- The association is derived through the explanation or candidate read; neither record owns the other. cross_service: false - to: DOM-ACC-REC-004 cardinality: one-to-many ownership: The concern retains its own references to affected records. cross_service: false - to: DOM-ACC-REC-005 cardinality: many-to-one per period ownership: Assessment reads the relationship without owning the underlying record. cross_service: false invariants: - id: INV-DOM-ACC-REC-001-01 statement: No two live payouts for a merchant use the same processor reference. enforced_at: - service - database provenance: observed source: >- services-accounting:modules/reconciliation/db/payouts.table.ts:payouts_processor_reference_uidx - id: INV-DOM-ACC-REC-001-02 statement: 'Creation fixes the number, business unit, currency, processor and origin.' enforced_at: - database provenance: observed source: >- services-accounting:modules/reconciliation/db/payouts.table.ts:payouts_write_once_trigger - id: INV-DOM-ACC-REC-001-03 statement: >- Referenced merchant and bank accounts belong to the payout’s unit and currency. enforced_at: - service - database provenance: observed source: >- services-accounting:modules/reconciliation/db/payouts.table.ts:payouts_merchant_account_fk - id: INV-DOM-ACC-REC-001-04 statement: >- A finalized holder prevents changes to payout money, merchant, currency, dates and evidence. enforced_at: - service - database provenance: documented source: >- services-accounting:docs/reconciliation/architecture.md#6. Reconciliation financial invariants (INV-09) - id: INV-DOM-ACC-REC-001-05 statement: Only one reconciliation actively holds a payout at a time. enforced_at: - database provenance: documented source: >- services-accounting:docs/milestones/plans/ACCT-M8-plan.md#4. Assumptions (from the design; each becomes a rule in the catalog if not already) - id: INV-DOM-ACC-REC-001-06 statement: >- Only the verification command changes the bank outcome; agreement and mismatch retain verifier and time. enforced_at: - service - database provenance: observed source: >- services-accounting:modules/reconciliation/db/payouts.table.ts:payouts_bank_verified_check - id: INV-DOM-ACC-REC-001-07 statement: >- Cancellation retains actor, time and reason together; removal is reserved for workspace purge. enforced_at: - database provenance: observed source: >- services-accounting:modules/reconciliation/db/payouts.table.ts:payouts_void_check - id: INV-DOM-ACC-REC-001-08 statement: >- Accounting uses the verified bank day, otherwise the reported day, otherwise the funding day. enforced_at: - service provenance: observed source: >- services-accounting:modules/reconciliation/services/persistence/payouts.ts:updatePayout - id: INV-DOM-ACC-REC-001-09 statement: Supporting evidence is limited to fifty files. enforced_at: - service - database provenance: observed source: >- services-accounting:modules/reconciliation/db/payouts.table.ts:MAX_PAYOUT_EVIDENCE_FILES physical: - accounting.payouts - accounting.reconciliation_evidence_files - accounting.reconciliation_events evidence: - >- services-accounting at f47cb263: modules/reconciliation/db/payouts.table.ts, reconciliation-evidence.table.ts; services/persistence/payouts.ts, payout-evidence-files.ts, payout-numbers.ts, payout-refusals.ts; services/rules/payout-rules.ts; services/payouts/payout-actions.ts; aws/api/payouts.routes.ts, payouts.schemas.ts; docs/reconciliation/architecture.md §6, §7.3.1, §14.1. - >- react-console at baf6dae3: lib/accounting/reconciliation/wire.ts, adapter.ts; components/accounting/reconciliation/add-payout-sheet.tsx. --- # Processor Payout ## What It Models A processor payout records the net deposit or debit staff see at the bank. Reported origin, processor confirmation, bank verification and reconciliation standing remain separate facts. ## Identity and Attributes Staff locate a payout by its number or processor reference. Money uses signed whole minor units; the accounting day follows the best available bank or reported evidence, while standing follows the active explanation. ## Relationships An explanation owns the payout holding and its release history. Settlement effects connect through that explanation, and concerns can identify the payout as their subject. ## Invariants The structured invariants identify the financial constraints and their enforcement boundaries. Service validation supplements the database’s identity, reference, compatibility and sealing protections. ## How It Is Stored and Shared Reconciliation controls payout writes and retains evidence as record assets. Close consumes payout facts through readiness; the record has no customer-defined fields. ## Open Design Questions Bank verification cannot succeed from the current console request. Import-only fields remain unused, and local numbering awaits shared infrastructure adoption.