# Account Payable Settlement ## Overview Account Payable Settlement records how an AP-owned settlement source is allocated to posted AP due schedules. Each settlement connects one source to one AccountPayableDueScheduleLine and carries a positive amount. Its `sourceType` discriminator and matching source-specific FK keep the allocation model stable as AP settlement instruments are added. Version 1 supports only `OUTGOING_PAYMENT` through `outgoingPaymentId`. Settlement rows have no standalone lifecycle. Outgoing Payment commands edit them while their source is DRAFT and make them immutable when the source is POSTED, REVERSED, or CANCELLED. Reversal changes the existing Outgoing Payment to REVERSED and appends linked reversing settlement rows without changing or deleting the original rows. `reversalOfSettlementId` determines the effective sign on the row. This feature records AP operational allocation; financial-accounting open-item clearing, cash execution, bank settlement, and bank reconciliation remain separate downstream facts. Version 1 supports direct cash settlement of posted INVOICE and CREDIT_MEMO due schedules, including correction documents. Settlement amounts are positive applied magnitudes. The target document's `documentType` determines whether the settlement increases or decreases the payment net. Discounts, withholding, fees, write-offs, unapplied payments, supplier prepayments, and cross-currency settlement remain excluded. ## Business Purpose - Preserve which posted AP due schedules an outgoing payment satisfies and by how much. - Keep AP remaining-balance enforcement in one AP-owned settlement model as source kinds are added. - Support partial payment and many-to-many allocation between payments and due schedules. - Prevent a supplier from being paid beyond the remaining amount of a due schedule. - Keep posted payment allocations immutable and auditable through linked reversal records. - Separate AP payment allocation from financial-accounting clearing and bank reconciliation. ## Process Flow ```mermaid flowchart TD A[Create a DRAFT Outgoing Payment] --> B[Add or update settlement rows] B --> C{Post the Outgoing Payment?} C -->|No| B C -->|Yes| D[Validate each target is a POSTED INVOICE or CREDIT_MEMO due schedule] D --> E[Validate company, supplier, currency, and positive amounts] E --> F[Validate signed settlement net equals payment total] F --> G[Validate net posted settlement does not exceed each due amount] G --> H[POSTED Outgoing Payment and immutable settlement rows] H --> I{Reverse the payment?} I -->|No| J[Retain posted settlement facts] I -->|Yes| K[Set the existing Outgoing Payment to REVERSED] K --> L[Create linked reversing settlement rows under that payment] ``` ## Scenario Patterns - **Single invoice payment**: One Outgoing Payment settles the full remaining amount of one posted invoice due schedule. - **Partial payment**: One Outgoing Payment settles only part of a due schedule, leaving the remainder available for later payments. - **Combined payment**: One Outgoing Payment has several settlement rows that allocate its total across multiple posted invoice due schedules for the same supplier. - **Invoice net of credit memo**: Positive settlement magnitudes of 100 against an INVOICE and 20 against a CREDIT_MEMO produce a signed payment net of 80. - **Installment paid by multiple payments**: Several posted Outgoing Payments settle different portions of the same due schedule without exceeding its due amount. - **Payment reversal**: The existing Outgoing Payment becomes REVERSED and carries new reversing settlement rows linked to the original posted settlements so the affected due schedules become payable again. ## Test Cases - Creating settlement rows for a DRAFT Outgoing Payment with positive amounts and eligible due schedules should succeed. - Updating or removing settlement rows while their Outgoing Payment is DRAFT should succeed for an authorized AP user. - Posting an Outgoing Payment whose signed settlement net equals the payment total should succeed when every other settlement rule is satisfied. - Posting one Outgoing Payment against multiple due schedules should succeed when all due schedules belong to posted invoices or credit memos for the same company, supplier, and currency. - Posting multiple Outgoing Payments against one due schedule should succeed while their net cumulative posted settlement amount does not exceed the due amount. - Creating a settlement with a zero or negative amount must be prevented. - Posting an Outgoing Payment without settlements must be prevented when its total amount is positive. - Posting an Outgoing Payment when its signed settlement net does not equal its total amount must be prevented. - Posting an Outgoing Payment against a due schedule from an unposted AP document must be prevented. - Posting an Outgoing Payment against a POSTED CREDIT_MEMO due schedule should succeed when the payment also contains sufficient positive invoice settlement amounts. - Posting an Outgoing Payment against a due schedule owned by a POSTED AP-increasing INVOICE correction document should succeed. - Posting an Outgoing Payment against a due schedule for a different company must be prevented. - Posting an Outgoing Payment against a due schedule for a different supplier must be prevented. - Posting an Outgoing Payment against a due schedule in a different currency must be prevented. - Posting an Outgoing Payment when the net cumulative posted settlement amount would exceed a due schedule amount must be prevented. - Updating or deleting settlement rows after their Outgoing Payment is POSTED must be prevented. - Cancelling a DRAFT Outgoing Payment retains its settlement rows as immutable history without changing any due schedule balance. - Reversing a POSTED Outgoing Payment should create new reversing settlement rows linked to the original settlement rows. - Reversing settlement rows must reference the same due schedules and amounts as the original posted settlement rows. - Reversal must retain the payment's original ID, company, supplier, currency, payment account, payment date, and total amount. - Reversing the same posted settlement more than once must be prevented. - Creating, posting, cancelling, or reversing settlements without the required AP authorization must be prevented. - Recording an Account Payable Settlement must not itself represent financial-accounting clearing or bank-statement reconciliation. - Every settlement must have a supported `sourceType` and exactly its matching source-specific FK. - A reversal row must derive its restoring sign from `reversalOfSettlementId`, not from its source header. - Version 1 must require the payment total to equal the signed settled-obligation net and must reject discounts, withholding, fees, write-offs, and other payment differences. - Version 1 must treat every eligible posted invoice due schedule as payable because post-posting payment blocks are deferred to a separate payment-eligibility feature. ## Reference Links - [AccountPayableDocument model](../model/AccountPayableDocument.md)