# Account Receivable Settlement ## Overview Account Receivable Settlement records how an AR-owned settlement source is allocated to posted AR due schedules. Each settlement connects one source to one AccountReceivableDueScheduleLine and carries a positive amount. Its `sourceType` discriminator and matching source-specific FK keep the allocation model stable as AR settlement instruments are added. Version 1 supports only `INCOMING_PAYMENT` through `incomingPaymentId`. Settlement rows have no standalone lifecycle. Incoming 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 Incoming 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 AR 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, customer prepayments, and cross-currency settlement remain excluded. ## Business Purpose - Preserve which posted AR due schedules an incoming payment satisfies and by how much. - Keep AR remaining-balance enforcement in one AR-owned settlement model as source kinds are added. - Support partial payment and many-to-many allocation between payments and due schedules. - Prevent a customer from being paid beyond the remaining amount of a due schedule. - Keep posted payment allocations immutable and auditable through linked reversal records. - Separate AR payment allocation from financial-accounting clearing and bank reconciliation. ## Process Flow ```mermaid flowchart TD A[Create a DRAFT Incoming Payment] --> B[Add or update settlement rows] B --> C{Post the Incoming Payment?} C -->|No| B C -->|Yes| D[Validate each target is a POSTED INVOICE or CREDIT_MEMO due schedule] D --> E[Validate company, customer, 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 Incoming Payment and immutable settlement rows] H --> I{Reverse the payment?} I -->|No| J[Retain posted settlement facts] I -->|Yes| K[Set the existing Incoming Payment to REVERSED] K --> L[Create linked reversing settlement rows under that payment] ``` ## Scenario Patterns - **Single invoice payment**: One Incoming Payment settles the full remaining amount of one posted invoice due schedule. - **Partial payment**: One Incoming Payment settles only part of a due schedule, leaving the remainder available for later payments. - **Combined payment**: One Incoming Payment has several settlement rows that allocate its total across multiple posted invoice due schedules for the same customer. - **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 Incoming Payments settle different portions of the same due schedule without exceeding its due amount. - **Payment reversal**: The existing Incoming Payment becomes REVERSED and carries new reversing settlement rows linked to the original posted settlements so the affected due schedules become receivable again. ## Test Cases - Creating settlement rows for a DRAFT Incoming Payment with positive amounts and eligible due schedules should succeed. - Updating or removing settlement rows while their Incoming Payment is DRAFT should succeed for an authorized AR user. - Posting an Incoming Payment whose signed settlement net equals the payment total should succeed when every other settlement rule is satisfied. - Posting one Incoming Payment against multiple due schedules should succeed when all due schedules belong to posted invoices or credit memos for the same company, customer, and currency. - Posting multiple Incoming 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 Incoming Payment without settlements must be prevented when its total amount is positive. - Posting an Incoming Payment when its signed settlement net does not equal its total amount must be prevented. - Posting an Incoming Payment against a due schedule from an unposted AR document must be prevented. - Posting an Incoming Payment against a POSTED CREDIT_MEMO due schedule should succeed when the payment also contains sufficient positive invoice settlement amounts. - Posting an Incoming Payment against a due schedule owned by a POSTED AR-increasing INVOICE correction document should succeed. - Posting an Incoming Payment against a due schedule for a different company must be prevented. - Posting an Incoming Payment against a due schedule for a different customer must be prevented. - Posting an Incoming Payment against a due schedule in a different currency must be prevented. - Posting an Incoming Payment when the net cumulative posted settlement amount would exceed a due schedule amount must be prevented. - Updating or deleting settlement rows after their Incoming Payment is POSTED must be prevented. - Cancelling a DRAFT Incoming Payment retains its settlement rows as immutable history without changing any due schedule balance. - Reversing a POSTED Incoming 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, customer, 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 AR authorization must be prevented. - Recording an Account Receivable 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 receivable because post-posting payment blocks are deferred to a separate payment-eligibility feature. ## Reference Links - [AccountReceivableDocument model](../model/AccountReceivableDocument.md)