Early Payment Discounts: The Real Annualized Math (2026)

A controller told me her AP team had "always known" 2/10 net 30 discounts were good deals but had never actually run the math on whether it beat their revolving credit line rate, so nobody had ever formally pushed to capture more of them. When I asked her what the annualized return on a 2/10 net 30 discount actually was, she said "pretty good, I think," which is roughly what most finance teams know, a headline number without the formula behind it. That gap between "sounds good" and "here is the exact math" is why discount capture programs stay informal instead of becoming a real cash-management priority, and it is a gap that costs real money every single month it goes unmeasured.

This is the actual formula, worked across the discount terms real vendors actually offer, for teams building invoice automation that needs to prioritize which discounts are worth chasing.

The formula nobody shows you

Every article that cites "36% annualized return on 2/10 net 30" is quoting the output of a specific formula without showing the formula itself. Here it is:

Annualized rate = [Discount % / (100% - Discount %)] × [365 / (Full payment days - Discount days)]

For a 2/10 net 30 term: the discount is 2%, the discount window is 10 days, and full payment is due at 30 days, so the gap between paying early and paying on time is 20 days. Plugging in: (2 / 98) × (365 / 20) = 0.0204 × 18.25 = 0.3724, or 37.2%. That is the number every article cites. Almost none show the two steps that produced it.

The math worked across the terms vendors actually offer

2/10 net 30 is the term everyone cites because it is the most common, but vendors offer plenty of other structures, and the annualized value swings enormously depending on the discount percentage and the gap between the discount window and the full due date. Here is the same formula applied to five real term structures.

Term	Discount	Days gained	Annualized return
1/10 net 30	1%	20 days	18.4%
2/10 net 30	2%	20 days	37.2%
2/10 net 60	2%	50 days	14.9%
1/15 net 60	1%	45 days	8.2%
3/15 net 45	3%	30 days	37.6%

The pattern that matters for prioritization: the discount percentage and the days-gained figure both drive the result, and they can trade off in non-obvious ways. A 1/15 net 60 term looks similar to 2/10 net 30 on paper, a small discount for paying somewhat early, but it annualizes to less than a quarter of the return, because the gap between the discount window and full payment is 45 days instead of 20, spreading the same relative discount over more than double the time. If your AP team is prioritizing discount capture by discount percentage alone, ignoring the days-gained term, you are ranking these opportunities wrong.

The comparison that actually decides whether to take the discount

The annualized rate is only useful once you compare it against your actual cost of capital, what it costs you to have that cash tied up ten or twenty days earlier than required. If your business borrows on a revolving credit line at 9%, a 37% annualized discount is an obviously good trade, you are effectively earning 28 percentage points above your borrowing cost by paying early. A 1/15 net 60 term at 8.2% is a much closer call against that same 9% cost of capital, and might not be worth prioritizing ahead of other cash uses at all. The formula tells you the return; your cost of capital tells you whether that return is actually attractive relative to your alternatives.

Companies without a revolving credit line still have a real cost of capital, it is just less visible and easier to overlook in this specific decision. The relevant comparison becomes the return available on the next-best use of that cash: a business with high-return growth opportunities (inventory that turns over quickly, marketing spend with a proven payback period) might reasonably conclude that even a 37% discount does not beat deploying that cash elsewhere first. This is a genuine judgment call finance leadership should make deliberately, not a default either to always capture every discount or to always preserve cash, since both defaults will be wrong in some proportion of cases.

What this actually looks like in dollars at scale

The formula is abstract until you put real invoice volume behind it. A company processing $2 million a month in invoices, with roughly a third of that volume carrying a 2/10 net 30 term from vendors who offer it, has $667,000 a month, about $8 million a year, in discount-eligible spend. Capturing the full 2% on that volume is $160,000 a year in direct savings, money that requires no negotiation, no new vendor terms, nothing except processing fast enough to hit a 10-day window consistently. Most companies capture a fraction of this, not because the math is unclear once you run it, but because the operational speed to act on it consistently was never built.

Dynamic discounting: a different structure, same underlying math

Static terms like 2/10 net 30 are fixed: pay within 10 days, get exactly 2%, no more, no less. Dynamic discounting, increasingly common in AP automation platforms, instead offers a sliding rate that scales continuously with how early you pay within the full payment window, often expressed as a daily rate rather than a single cliff. Pay 25 days early on a net-30 invoice and get a proportionally larger discount than paying 5 days early, calculated on a curve rather than an all-or-nothing threshold.

The same annualized-return formula still applies at any point on that curve, since a dynamic discount is functionally a continuum of static discount terms rather than a different kind of instrument. The practical implication for prioritization is the same: compare whatever rate is on offer at your intended payment date against your cost of capital, and pay as early as that comparison favors, rather than defaulting to either the earliest possible date or the latest one out of habit.

Why manual AP processing forfeits most of this value by default

Discount capture requires hitting the discount window, and that window is usually 10 to 15 days from invoice receipt, shorter than most manual AP cycles. If invoice processing (receipt, data entry, approval routing, payment scheduling) takes 8 to 14 days on its own, which is typical for manual workflows, there is almost no room left to also clear payment before a 10-day discount window closes. This is a timing problem before it is a decision problem: teams that would happily take a 37% annualized return simply never get the invoice approved and scheduled in time to claim it, and the discount lapses by default, not by choice.

This is exactly where invoice OCR earns its keep for discount capture specifically: shrinking the receipt-to-approval window from days to hours is what actually creates the room to hit a 10-day discount deadline, more than any change to the approval policy itself. A faster extraction and validation step upstream is what makes an aggressive discount-capture program operationally possible in the first place.

Approval routing matters just as much as extraction speed once the data is clean. An invoice that gets extracted in minutes but then sits for six days waiting on a single approver's inbox has gained nothing toward the discount window. Time-boxed approval SLAs specifically for discount-eligible invoices, with automatic escalation if an approver has not acted within a set number of hours, close the gap that pure extraction speed alone cannot, since the bottleneck moves downstream once the first bottleneck is solved.

Building a discount-priority queue instead of a first-in-first-out one

Most AP teams process invoices in the order they arrive. A discount-capture program processes them in order of annualized return instead, at least for the subset with an active discount window, so the highest-value discounts get approval attention first rather than getting stuck behind lower-priority invoices that happened to arrive earlier. This requires knowing the annualized rate per invoice at intake, which means capturing the discount terms as a structured field during extraction, not leaving it as unstructured text somewhere in the invoice image that nobody checks until someone manually notices a "2/10" printed in small type near the payment terms.

In practice this means the extraction step needs to specifically look for and structure discount-term language, not just the header fields (vendor, total, due date) that most invoice OCR treats as the complete extraction target. A discount term buried in a payment-terms line is easy for extraction to miss entirely if it was never treated as a field worth capturing in the first place, which is the same underlying lesson as the line-item extraction accuracy problem: a field nobody explicitly asked the model to capture is a field that quietly never shows up in the output.

What I would check in your current AP process

Pull your last quarter of vendor invoices and check what share carried an early payment discount term, then check what share of those you actually captured versus let lapse. If your capture rate is low, diagnose whether it is a timing problem (invoices are not cleared for payment before the window closes) or a visibility problem (discount terms are not being tracked as structured data at all). The fix is different for each: timing problems need faster intake-to-approval processing, visibility problems need the discount terms extracted and surfaced explicitly rather than buried in invoice text nobody reads closely.

Also check whether your top vendors by spend actually offer discount terms at all. If they do not, and your spend is concentrated with vendors on straight net-30 or net-60 terms, discount capture will never move the needle much regardless of how fast your AP process becomes, and the higher-leverage conversation is asking your largest vendors to add an early payment option in the first place, something many will agree to since it improves their own cash flow too, particularly smaller vendors who value getting paid sooner more than the discount costs them.

Frequently asked questions

What does 2/10 net 30 mean on an invoice?
It means the buyer can deduct 2% from the invoice total if payment is made within 10 days of the invoice date, instead of paying the full amount under standard 30-day terms.

How do you calculate the annualized return on an early payment discount?
Annualized rate = [Discount % / (100% minus Discount %)] × [365 / (Full payment days minus Discount days)]. For 2/10 net 30, that is (2/98) × (365/20), which equals approximately 37.2%.

Is a 1% early payment discount worth taking?
It depends entirely on the days gained, not the discount percentage alone. A 1/10 net 30 term annualizes to about 18.4%, generally worth taking against typical borrowing costs, while a 1/15 net 60 term annualizes to only about 8.2%, a much closer call depending on your actual cost of capital.

Why do companies miss early payment discounts even when the math favors taking them?
Most commonly because manual invoice processing takes longer than the discount window itself. If receipt-to-approval takes 8 to 14 days and the discount window is 10 days, there is little to no time left to also schedule and execute payment before the deadline, so the discount lapses regardless of whether anyone would have chosen to take it.

How should AP teams prioritize which invoices to process first for discount capture?
By annualized return on the active discount, not by arrival order or discount percentage alone. This requires capturing discount terms as structured data at invoice intake so the highest-value discounts can be routed for faster approval ahead of lower-priority invoices.

What is dynamic discounting and how is it different from a standard early payment discount?
A standard discount like 2/10 net 30 is a fixed threshold: pay within 10 days, get exactly 2%. Dynamic discounting offers a sliding rate that scales continuously with how early payment happens across the full payment window, often as a daily rate. The same annualized-return math still applies at any point on that sliding scale.

The math above holds regardless of company size. Run it on your own vendor terms before the next payment run. Written by Nupura Ughade.