Early-Payment Discount Capture

The control flow a finance team actually needs.

The ERP surface involved.

Payment terms must support standard formats: Net N, N/M Net N, EOM, prox; system calculates discount_due_date and discount_amount at invoice approval time; discount-opportunity report queryable by expiry date range with total potential savings; auto-flag invoices where discount_amount > bank_float_cost_estimate for the early-payment period; early payment posted with two GL lines: debit AP full amount, credit Cash net amount, credit Purchase Discounts Earned discount amount; discount terms overridable per invoice by authorized user; discount amounts stored in *_minor + currency_code; audit log captures decision to take or forego each discount opportunity.

US and UK teams have different compliance hooks, but the same control problem.

US teams usually care about clean evidence for audit support, vendor records, payment controls, tax reporting, and management review. UK teams usually care about VAT-ready records, approval evidence, digital-record discipline, and traceable postings. The country-specific details differ, but the operating pattern is the same: the ERP needs controlled records, explicit ownership, defensible state changes, and evidence that survives beyond the person who completed the task.

The control matrix.

Audit evidence is a chain, not a folder.

When an invoice is approved, the system reads its payment terms (e.g., 2/10 Net 30) and calculates the discount due date and discount amount. The payment scheduling engine flags invoices with available discounts that expire before the next standard payment run date. The AP manager reviews a discount-opportunity report showing potential savings and elects to schedule an early payment. The system generates an accelerated payment, posts the invoice as PAID, and records the discount as a credit to a Purchase Discounts Earned account. The remaining balance-due drops to zero.

payment_terms { id: string, description: string, net_days: int, discount_pct: decimal, discount_days: int };
invoices { id, vendor_id, payment_terms_id, invoice_date, discount_due_date, net_due_date, discount_amount_minor: int64, balance_due_minor: int64, currency_code: char(3) };
payments { id, invoice_id, amount_minor, discount_taken_minor, payment_date, currency_code, external_id };
(reference, product may differ).

GET /v1/invoices/discount-opportunities { expiry_before: date } -> 200 { items: [{invoice_id, discount_amount_minor, discount_due_date, potential_savings_minor}] };
POST /v1/payments { invoice_ids: [], take_discount: bool, payment_date, external_id } -> 201 { id, net_amount_minor, discount_applied_minor };
emits ap.discount.captured event;
idempotent via external_id.

DISCOUNT_AVAILABLE -> DISCOUNT_CAPTURED (when paid before discount_due_date);
DISCOUNT_AVAILABLE -> DISCOUNT_EXPIRED (when paid after);
guard: discount cannot be captured after discount_due_date without override.

The useful version of this workflow is not only fast. It is inspectable. A controller, auditor, or operator should be able to move from source event to system record to state transition to final business outcome without guessing.

Implementation contracts.

`payment_terms` { id: string, description: string, net_days: int, discount_pct: decimal, discount_days: int }; `invoices` { id, vendor_id, payment_terms_id, invoice_date, discount_due_date, net_due_date, discount_amount_minor: int64, balance_due_minor: int64, currency_code: char(3) }; `payments` { id, invoice_id, amount_minor, discount_taken_minor, payment_date, currency_code, external_id }; (reference, product may differ).

`GET /v1/invoices/discount-opportunities` { expiry_before: date } -> 200 { items: [{invoice_id, discount_amount_minor, discount_due_date, potential_savings_minor}] }; `POST /v1/payments` { invoice_ids: [], take_discount: bool, payment_date, external_id } -> 201 { id, net_amount_minor, discount_applied_minor }; emits `ap.discount.captured` event; idempotent via `external_id`.

`DISCOUNT_AVAILABLE -> DISCOUNT_CAPTURED` (when paid before discount_due_date); `DISCOUNT_AVAILABLE -> DISCOUNT_EXPIRED` (when paid after); guard: discount cannot be captured after discount_due_date without override.