# Sales Payment Terms

## Overview

Sales Payment Terms defines how customer invoices become due once commercial billing is issued. A `SalesPaymentTerm` models rules such as net days, end-of-month due dates, installment splits, and early-payment discounts. These terms can default onto sales orders from the customer selling profile and flow forward into `SalesInvoice` so that the invoice carries the expected receivable schedule when handed off to downstream accounts receivable.

The feature is intentionally limited to customer-facing receivable terms within sales. It does not execute payment capture, collection, or settlement. Instead, it standardizes the contractual timing information that sales operations and downstream finance both need.

## Business Purpose

- Standardize customer payment expectations across sales orders and invoices
- Reduce manual invoice-entry work by defaulting due-date schedules from negotiated payment terms
- Support installment or staged payment structures for milestone-based or large-value deals
- Enable early-payment discount handling by making discount windows explicit and reusable
- Provide a consistent handoff contract from sales to downstream accounts-receivable processing
- Separate payment timing rules from customer master data so terms can evolve independently per transaction or commercial agreement
- Preserve how discountable amount is interpreted by explicitly recording whether discount logic applies to gross or net invoice amount

## Process Flow

```mermaid
flowchart TD
    A[Define Sales Payment Term] --> B[Configure schedule lines and discount rules]
    B --> C[Activate term]
    C --> D[Default term from customer selling profile or assign manually to order]
    D --> E[Sales Invoice created from order]
    E --> F[Copy payment term snapshot to invoice]
    F --> G[Calculate due dates and installment amounts]
    G --> H[Invoice becomes ready for downstream AR processing]
```

## Scenario Patterns

- **Net 30 standard term**: A customer agreement states payment is due 30 days after the invoice date, and every invoice using that term receives a single due date 30 days later
- **2/10 net 30**: A customer receives a discount if the invoice is paid within 10 days; otherwise full payment is due in 30 days. The term captures both the discount window and the final due date
- **Milestone billing**: A project order requires 50 percent due at invoice issue and 50 percent due 30 days later, and the payment term expresses two receivable schedule lines
- **End-of-month settlement**: Invoices dated throughout the month become due at month end plus a fixed number of days, matching the customer's settlement policy
- **Default term propagation**: A customer has a default sales payment term, and each new draft sales order starts with that term before the user decides whether to override it
- **One-off override**: A customer usually receives net 45 terms, but a specific order is changed to net 15 because of expedited delivery and exceptional commercial approval
- **Term retirement**: An old payment term is deactivated when the customer contract is renegotiated, but historical orders and invoices retain the prior snapshot
- **Advance-payment agreement**: A deal requires an invoice with immediate due status before shipment, while the actual payment capture remains outside the sales module
- **Discount visibility for AR**: The issued invoice exposes the discount cutoff date so downstream receivable automation can decide whether discount handling is allowed

## Test Cases

- Creating a sales payment term with at least one schedule line should succeed
- The sum of installment percentages on a percentage-based payment term must equal 100 percent
- A payment term schedule line must not allow a negative percentage or negative fixed amount
- A discount date must occur on or before the final due date
- A payment term that offers early-payment discount must record whether the discount base is `GROSS_AMOUNT` or `NET_AMOUNT`
- Inactive payment terms must not be assignable to new sales orders or new invoices
- When a customer selling profile provides a default payment term, a new draft sales order should inherit it automatically unless the user overrides it
- A sales order should snapshot its assigned payment term so later edits do not alter existing downstream invoices
- A sales invoice due-date schedule must be computable from the invoice date and the assigned payment term
- End-of-month terms must produce a due date based on calendar month logic rather than a simple fixed-day offset
- Installment terms should generate multiple due schedule lines on the customer invoice
- Early-payment discount metadata must remain available after invoice issuance so downstream AR can consume it
- A payment term can be overridden on a draft sales order but changing it after invoice issuance should be prevented or explicitly controlled
- Sales payment terms must be isolated by company when receivable policies differ by legal entity
- Deactivating a payment term that is already referenced historically must preserve existing order and invoice snapshots
- Only authorized sales or finance users should be able to create, update, activate, or deactivate payment terms

## Reference Links

- [Odoo customer payment terms documentation](https://www.odoo.com/documentation/19.0/applications/finance/accounting/customer_invoices/payment_terms.html)
- [Oracle receivables payment terms documentation](https://docs.oracle.com/en/cloud/saas/financials/index.html)
- [SAP payment terms documentation](https://help.sap.com/docs/SAP_S4HANA_CLOUD)
