Early Payment Discounts: Why AP Misses 2/10 Net 30, and How to Capture Every One
A supplier offers 2% off for paying within ten days. The invoice arrives, waits for a manager's approval, and is paid on day 28, in full. Nobody decided to give up the discount; it simply expired while the invoice moved through the queue. This post looks at what early payment discounts are worth, why accounts payable misses them, and what it takes to read the terms off every invoice early enough to take them.
In brief
- Terms of 2/10 net 30 mean a 2% discount for paying 20 days early, which works out to an annualized rate of about 37%, more than most companies earn on cash.
- Discounts are lost before payment, not at it: the terms are not captured, the invoice reaches AP late, or approval takes longer than the discount window.
- Capturing a discount needs the terms parsed into fields (percent, discount days, net days and the date the clock starts) and a discount due date computed for every invoice.
- Invoices with a live discount should be routed and approved first, and the payment run scheduled around discount dates rather than only net due dates.
What an early payment discount is worth
Payment terms such as 2/10 net 30 are a short offer from the supplier: pay within 10 days and take 2% off, or pay the full amount by day 30. The choice looks small on any single invoice. On a 12,400.00 subtotal, 2% is 248.00, which is easy to let go when the approval is stuck. But the right way to read the offer is as a rate of return on cash, because what you are really doing is paying 20 days earlier than you have to.
Paying 98% of the invoice 20 days early to avoid paying 100% later is earning 2/98 over 20 days. Over a 365-day year that is about 37%. Few places to park short-term cash pay anything close, and most credit lines cost far less, which is why treasury teams generally want every discount taken unless cash is genuinely short.
37.2%
annualized rate of 2/10 net 30: 2/98 x 365/20
20
days paid early to earn it: day 30 minus day 10
5
reasons discounts are missed, charted below
Other common terms are worth less but still often above the cost of money. The table uses the same formula, discount over the remaining amount, times 365 over the days between the discount date and the net date.
| Terms | Discount | Days paid early | Annualized rate |
|---|---|---|---|
| 1/10 net 30 | 1% | 20 | 18.4% |
| 2/10 net 30 | 2% | 20 | 37.2% |
| 2/10 net 45 | 2% | 35 | 21.3% |
| 2/10 net 60 | 2% | 50 | 14.9% |
| 1/15 net 45 | 1% | 30 | 12.3% |
Why discounts are lost before the payment run
It is tempting to blame the payment run, but by the time an invoice reaches it, the discount has usually already gone. The window is short, often ten days from the invoice date, and every step before payment eats into it.
The terms were never captured
Many AP systems take payment terms from the vendor master, not from the invoice. If the master says net 30 and the invoice says 2% 10 days, net 30, the system only ever sees a net due date. The discount exists on the paper and nowhere else.
The invoice reached AP late
The clock usually starts at the invoice date, not at the day AP receives it. An invoice mailed to a branch, sent to a buyer, or left in a shared inbox can arrive with half its window gone, or none.
Approval and exceptions take longer than ten days
Coding, approval routing and three-way match exceptions rarely care which invoices carry a discount. An invoice waiting for a receipt or a price check is treated the same whether it costs nothing to wait or 2% of its value.
The run cadence skips the date
With one payment run a week, a discount date that falls between runs is lost unless the invoice is pulled into the earlier run. Systems that select invoices by net due date never see it coming.
Approval took longer than the window
Invoice reached AP late
Terms never captured
Held as a match exception
Payment run fell after the date
Reading the terms off the invoice
Terms are printed in many forms: "2/10 net 30", "2% 10 days, net 30 days", "2% 10th prox, net 30", "1/10 EOM". To act on them, each needs to become a few typed fields, defined once in your extraction schema.
- Terms as printed. Keep the original text, so a reviewer can always check the parsed values against it.
- Discount percent, discount days, net days. The three numbers in the terms. Invoices with no discount simply leave the first two empty.
- When the clock starts. Invoice date by default; receipt of goods for terms written as ROG; the end of the month for EOM and prox terms, where 10th prox means the tenth of the following month.
- Discount basis. Whether the discount applies to the merchandise subtotal or the full total. Some vendors exclude freight and tax from the discount; read their terms rather than assume.
- Invoice date and received date. Both, so you can measure how much of each window is lost before the invoice even reaches AP.
From these the discount due date, the net due date and the discount amount follow by arithmetic. Compare the invoice terms with the vendor master too: when they differ, one of them is wrong, and it is worth knowing which before the next invoice.
A workflow that takes the discount on time
1. Capture every invoice the day it arrives
Route all invoices, from every inbox and branch, into one AP intake, and extract them on arrival rather than in a weekly batch. A day of delay is a tenth of a 10-day window.
2. Compute the discount due date and route by it
Once the terms are fields, every invoice carries a discount due date. Invoices with a live discount go to the front of the approval queue, with the date and the amount at stake shown to the approver.
{ "invoice": { "vendor_name": "Example Packaging Co.", "invoice_number": "58821", "invoice_date": "2026-10-05", "received_date": "2026-10-07", "po_number": "PO-30914", "currency": "USD", "subtotal": 12400.00, "freight": 380.00, "tax": 0.00, "total": 12780.00, "payment_terms_as_printed": "2% 10 Days, Net 30" }, "terms": { "discount_percent": 2.0, "discount_days": 10, "net_days": 30, "clock_starts": "invoice_date", "discount_basis": "subtotal", "discount_due_date": "2026-10-15", "net_due_date": "2026-11-04" }, "discount": { "amount": 248.00, "pay_if_by_discount_date": 12532.00, "annualized_rate_percent": 37.2 }, "routing": "priority_approval", "schedule_in_run": "2026-10-14"}In this example the terms are printed as "2% 10 Days, Net 30" on an invoice dated October 5 and received two days later. Parsed, they give a discount due date of October 15 on the 12,400.00 subtotal, freight excluded. The invoice is flagged for priority approval and placed in the October 14 run, paying 12,532.00 instead of 12,780.00.
3. Schedule the run around discount dates
Select invoices for each run by the earlier of the discount date and the net date, and pull any invoice whose discount expires before the next run into this one. Only take the discount when payment goes out by its date: a discount taken late is usually billed back as unearned and turns into a dispute.
4. Keep the exceptions moving
When an invoice with a discount is held for a match exception, the hold has a price. Show it, and resolve those first. And apply any open vendor credits before the discount is calculated, so it is taken on the right amount.
Measure the discounts you lose, not only the ones you take
Before you automate: a short checklist
- Extract payment terms from every invoice, not only from the vendor master.
- Keep the terms as printed next to the parsed percent, discount days and net days.
- Record when the clock starts: invoice date, receipt of goods, or end of month.
- Capture invoice date and received date to see how much window is lost on arrival.
- Compute a discount due date and amount for every invoice that offers one.
- Route discount invoices to the front of approval, with the date and amount shown.
- Select payment runs by the earlier of the discount date and the net date.
- Report discounts offered against discounts taken, by vendor and by cause.
Where extraction fits
Early payment discounts are lost on details: terms printed in a vendor's own wording, an invoice that sat in the wrong inbox, a due date the system never knew. Parser extracts each invoice into structured JSON against the fields you define, including the payment terms as printed, the invoice and received dates, the PO and the totals, so your AP system can compute the discount date on arrival and schedule the payment before the offer expires. The same fields feed your duplicate checks and month-end vendor statement reconciliation.