Settlement Discounts & Terms
"2/10 Net 30" — pay within 10 days and keep 2%, otherwise the full amount is due in 30. Suppliers offer these settlement discounts (early-payment discounts) because getting cash sooner is worth money to them; taking the discount is one of the easiest returns in finance. This article explains how payment terms work in REDA Financials and how to capture the discount when you pay.
Access you'll need. Recording discounts on payments and applications requires the Accounts Payable v2 permission set (AP clerks & managers) or Accounting Admin v2 (system administrators). The Accounting Controller v2, Accounts Receivable v2, and Read Only v2 sets can view but not record them; the payment-terms library itself is administrator territory.
Payment terms: the rules of when and how much
A Payment Term is a small reusable definition your administrator maintains — for example:
| Term | Meaning |
|---|---|
| Net 30 | Full amount due 30 days after the invoice date. No discount. |
| 2/10 Net 30 | 2% discount if paid within 10 days; otherwise net due in 30. |
| 1/10 Net 60 | 1% discount within 10 days; otherwise net due in 60. |
Each term carries its net days, and optionally a discount percentage with its discount window in days. Assign a default term to each vendor (and customer) on their account — from then on, new invoices pick up the term automatically and calculate their Due Date from it. Meridian's construction vendors are on 2/10 Net 30; the office tenants pay on Net 30.
Where the term does its work
| Moment | What the term drives |
|---|---|
| Invoice entry | The Due Date fills itself from the vendor's default term. It's adjustable — but required, and never before the invoice date (the exact guard: "Due date cannot be before the invoice date. Please review the payment terms and due date.") |
| Aging, every day after | The Due Date feeds Days Past Due, Is Overdue and the invoice's Aging Bucket — the term you set on the vendor quietly shapes your whole AP aging |
| Paying a single bill | You check the window and enter the discount in Payment Discount on the payment form |
| The payment run | Step 2 of the batch wizard suggests the discount automatically for every selected invoice still inside its window — adjust or clear before confirming |
Taking the discount when you pay
The discount is captured on the payment, not the invoice — because whether you earn it depends on when you pay.
Check you're inside the window
Count from the invoice date. A $2,000 bill on 2/10 Net 30 dated March 6 earns its $40 discount through March 16.
Record the discount on the payment
On the payment form, enter the discount in Payment Discount — you pay the reduced cash amount, and the discount fills the gap so the invoice still clears in full. In a payment run, eligible discounts are suggested automatically for invoices inside their window; you can adjust them before creating the batch.
Post
The invoice is settled in full, cash goes out net of discount, and the discount lands in your books as income.
What the books record for that $2,000 bill paid at $1,960:
| Account | Debit | Credit |
|---|---|---|
| Accounts Payable — Trade (invoice clears in full) | $2,000.00 | |
| Cash and Cash Equivalents (what actually left) | $1,960.00 | |
| Purchase Discounts (the discount you earned) | $40.00 |
The discount account comes from your entity's defaults (your administrator can point it elsewhere per payment with Payment Discount GL Account).
Under the hood: the discount lives on the payment
The combined picture above actually happens in two moves — worth knowing when you read the records afterwards. The payment carries the discount, and it posts all three legs at once: the full value being settled, the cash that actually left, and the discount earned.
| Account | Debit | Credit |
|---|---|---|
| Supplier Prepayments (the full amount being settled) | $2,000.00 | |
| Cash and Cash Equivalents (what actually left) | $1,960.00 | |
| Purchase Discounts (the discount you earned) | $40.00 |
Then the application settles the invoice — a plain two-line entry for the full $2,000, because the discount has already been dealt with:
| Account | Debit | Credit |
|---|---|---|
| Accounts Payable — Trade | $2,000.00 | |
| Supplier Prepayments | $2,000.00 |
Three useful consequences of the discount living on the payment:
- The invoice stays honest. It was always a $2,000 bill; your purchase history and the vendor's records agree. Nothing about the invoice was edited to "make it cheaper".
- The audit trail is exact. The payment names the cash that left and the discount taken — anyone can reconstruct why a $2,000 bill closed for $1,960 of cash.
- Undoing is clean. Void the payment (or delete the application) and the discount reverses with it — the invoice returns to its full balance due.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Entering the invoice net of the discount | Purchase history understates the billing; the discount income never shows; the vendor statement won't reconcile | Invoice gross, discount on the payment — always |
| Taking a discount after the window closed | The vendor's books show you short-paid — expect the awkward call and a rebill of the difference | Check the window from the invoice date; if it's gone, it's gone — pay in full |
| Paying every bill on its due date "for cash flow" | You give up ~36% annualized returns to hold cash a couple of extra weeks | Time payment runs to discount windows for discount-bearing vendors, due dates for the rest |
| Confusing a vendor memo with a discount | They're different money: a memo is credit the vendor issued; a discount is what you earned by paying early — mixing them up muddles both trails | Credit notes become Vendor Memos; early-payment savings go in Payment Discount |
| Forgetting terms exist when onboarding vendors | Every invoice defaults to no discount — savings the vendor offered are never even visible | Set the default Payment Term on the vendor account on day one |
The same idea, in reverse
Your customers may take settlement discounts from you when they pay early — recorded on cash receipts and posted to a sales-discount account. See Applying Receipts to Invoices.
Where to go next
- Payment Terms — creating and managing the terms library.
- Batch Payment Run — automatic discount suggestions at scale.
- Applying Disbursements — where discounts are recorded.
Frequently asked questions
Enter the invoice at its full (gross) amount and take the discount on the payment. That keeps your purchase history accurate and lets the books show discounts you actually earned. If the vendor truly billed a lower price (not an early-payment discount), then the lower price is simply the line amount.
The system won't stop you — the discount field is yours to fill — but taking an unearned discount usually earns a call from the vendor. The suggested discounts in payment runs respect the window for exactly this reason.
It accumulates in the Purchase Discounts account — visible on your Income Statement and drillable like any other account.
On the application that settles the invoice — its Discount Amount sits beside the applied cash. That's why the invoice itself never changes, and why deleting the application (or voiding the payment) reverses the discount cleanly.
No — the wizard's suggestions respect each invoice's window at the time of the run. If you postpone the batch, re-check the suggestions rather than carrying stale discounts into a later payment.
Yes — the entity's default Purchase Discounts account applies unless a payment's Payment Discount GL Account points somewhere else. Most organizations keep one account; a per-payment override exists for the exceptions.
Was this article helpful?