Chargebee dunning management is the built-in system that automatically re-attempts a subscription invoice after its first payment fails, on a schedule of retry days and reminder emails that you configure once in Chargebee's settings. It is a real, working recovery mechanism — not a placeholder feature — and for a lot of subscription businesses it recovers a meaningful share of failed payments without any extra tooling. But “it works” and “it recovers everything it could” are two different claims, and the gap between them is where a surprising amount of quietly lost revenue tends to sit: a fixed schedule that treats every decline the same way, a generic email template that doesn't change based on why the card failed, and a hard stop once the configured attempts run out, after which the invoice just sits unpaid with nothing automatically trying again.
This guide walks through how Chargebee's dunning configuration actually works under the hood, the specific settings worth checking today, the handful of gaps that are easy to miss because Chargebee never surfaces them as a warning, and an honest look at what a recovery layer added on top of Chargebee can and cannot do that Chargebee's native dunning does not already cover. Revova connects to Chargebee directly (read-only) alongside Stripe, Paddle, Braintree, and Recurly, so the limitations described here are ones we have had to design around ourselves, not secondhand speculation about a platform we don't actually integrate with.
Key takeaways
- Chargebee dunning is rule-based and configurable — a fixed schedule of retry days and reminder emails you set once, applied uniformly to every failed invoice, not a per-decline machine-learning model like Stripe Smart Retries.
- The default configuration commonly sends the same email copy regardless of decline reason — an expired card and a temporarily insufficient-funds decline get identical wording, even though the right customer action is completely different for each.
- Once the configured retry schedule is exhausted, the subscription typically gets paused or cancelled per your “dunning exhausted” setting, and nothing automatically retries that specific invoice again afterward.
- Invoices that already exhausted the schedule sit in a past-due state indefinitely — they are not automatically revisited by anything running today, even if the customer's card situation has since changed.
- A recovery layer added on top of Chargebee (like Revova) can add decline-aware email branching and a historical scan across already-exhausted invoices, without replacing Chargebee as the system of record for billing.
How Chargebee's dunning management actually works
Chargebee's dunning management lives in the billing settings of your Chargebee site, and it applies at the site or plan level rather than being something you configure per individual customer. When a subscription invoice's payment attempt fails — whether the failure comes back from Stripe, Braintree, or whichever gateway you have connected underneath Chargebee — the invoice enters what Chargebee calls the dunning process. From there, Chargebee runs through the schedule you configured: a set number of retry attempts, spaced a set number of days apart, each one paired with a reminder email sent to the customer around the same time.
This is meaningfully different from how Stripe's own Smart Retries feature works at the charge level, and conflating the two is a common source of confusion. Stripe Smart Retries uses a model trained across Stripe's network of transactions to estimate the statistically best moment to re-attempt a specific declined charge. Chargebee's dunning schedule, by contrast, is a configuration you set — the same day intervals apply to every failed invoice on that plan, regardless of the specific reason the card was declined. If Stripe happens to be the gateway underneath your Chargebee account, some of that charge-level retry intelligence can still be in play for the individual attempt itself, but the schedule wrapped around it — how many attempts, how far apart, what emails go out — is the configurable layer Chargebee itself controls.
Same word, two different mechanisms
What the default retry schedule actually looks like
A typical Chargebee dunning configuration spreads a handful of retry attempts across roughly the first one to two weeks after an invoice first fails, then stops. Exactly how many attempts and how many days apart is something you set in Chargebee's dunning settings for each site or plan — there is no single universal default that applies to every account, so the specific numbers below are illustrative of the shape of a schedule, not a claim about what your account is currently configured to do. What matters structurally, regardless of the exact numbers you've set: the schedule is finite, it runs on calendar days rather than being aware of weekends or the customer's likely payday, and it stops completely once the last configured attempt has run.
The practical risk in this shape is the same one that shows up in almost every rule-based (non-adaptive) retry system: a schedule tuned for the average case can be badly mistimed for any specific invoice. A customer whose card was declined for insufficient funds right before a payday might recover instantly on a retry scheduled two days later — or might still be short on day 2 and recover cleanly on day 9, well past where a tight four-attempt schedule already gave up. Widening the schedule to cover more of that variance is possible, but it trades off against how many days a subscription sits in an unpaid, dunning state before either recovering or being cancelled — which has its own cost in a customer's perception of your billing reliability.
The gaps a default Chargebee dunning configuration doesn't cover
None of what follows is a bug in Chargebee — it is simply outside what a configurable, rule-based dunning schedule is designed to do by default. These are the three gaps we see most often when looking at a merchant's existing Chargebee setup, roughly in order of how much recoverable revenue each one tends to represent.
| Gap | What Chargebee does by default | What it costs |
|---|---|---|
| Decline-reason branching | Sends the same templated email at each scheduled step, regardless of why the card failed | A customer with an expired card gets a passive "we'll try again" message instead of the one action that would actually fix it |
| Historical exhausted invoices | Stops retrying entirely once the configured schedule ends; the invoice stays unpaid | Invoices that failed months ago and never recovered sit untouched indefinitely unless someone manually revisits them |
| Send-time personalization | Sends reminder emails on the scheduled calendar day, not tuned to a specific customer's likely payday or timezone | A well-timed reminder converts meaningfully better than the same copy sent at a mistimed moment — timing is left on the table |
Gap 1: no automatic branching by decline reason
Chargebee generally forwards the specific decline detail your connected gateway returns, and you can see it manually on the invoice or transaction record. What the standard dunning configuration does not do out of the box is route that decline reason into different email copy or different retry timing automatically. An expired card, a temporarily insufficient-funds decline, and a bank flagging the charge as suspicious (a do_not_honor-style response) are three completely different situations that call for three different messages and, arguably, three different retry cadences — yet a default Chargebee configuration commonly sends the same wording for all three unless you build that branching logic yourself.
Our separate guide on soft decline vs. hard decline covers the underlying distinction in more depth: a soft decline (insufficient funds, a temporary processor issue) is usually recoverable with time and a well-timed retry, while a hard decline (an expired or stolen card, a closed account) will keep failing no matter how many times you retry the same card number — it needs the customer to actually update their payment method. A dunning schedule that retries a hard decline five times on the same card is not just ineffective, it wastes attempts and annoys the customer with repeated failure notices for something a retry was never going to fix.
Gap 2: invoices that already exhausted the schedule stay untouched
This is the gap we see cost the most, quietly, over time. Once Chargebee's configured dunning schedule runs out for a given invoice and the “dunning exhausted” action fires (commonly pausing or cancelling the subscription), nothing in Chargebee automatically comes back to that specific invoice later. It sits in a past-due or unpaid state, permanently, unless a person manually revisits it, the customer proactively reaches out to update their card, or a separate process specifically re-approaches that historical backlog.
The reason this backlog builds up invisibly is structural, not a failure of attention: a dunning schedule is designed to handle a failure once, at the time it happens, and then hand off to whatever “exhausted” action you configured. It was never designed to periodically re-scan old, already-exhausted invoices on its own — that would be a fundamentally different kind of system, closer to what our historical payment recovery guide describes in more general terms across any processor, Chargebee included.
Gap 3: send timing is calendar-based, not customer-aware
A reminder scheduled for “day 5” fires on day 5 for every affected customer, regardless of that customer's typical payday, timezone, or how likely their specific bank is to have cleared a temporary hold by then. This is a smaller effect than the first two gaps, but it compounds with them — a decline-reason-aware email sent at a mistimed moment still recovers less than the same email sent when the customer is actually in a position to act on it.
How to configure Chargebee dunning for better recovery today
None of the following requires leaving Chargebee or adding a new tool — these are adjustments available directly in Chargebee's own dunning settings, worth checking regardless of whether you eventually add a recovery layer on top.
- Open your current dunning schedule and write down what it actually is.Most teams configured this once, at setup, and haven't revisited it since — confirm the number of attempts, the day intervals between them, and the “dunning exhausted” action currently set for each plan.
- Separate your hard-decline handling from your soft-decline handling.For declines that clearly need a new payment method (expired card, closed account), the highest- leverage change is making the first email explicit about that — “update your card” rather than a passive “we'll try again” — since retrying the same card repeatedly on a hard decline wastes every remaining attempt in the schedule.
- Widen (or shorten) the schedule based on your actual billing cycle, not a default. A monthly plan and an annual plan carry very different stakes for how long an invoice should stay in dunning before the exhausted action fires — our annual plan renewal guide covers why annual renewals in particular benefit from a longer runway than a default monthly-tuned schedule gives them.
- Rewrite the default email copy to be specific and actionable.Generic “your payment failed” wording performs worse than copy that states plainly what happened and what the one next action is — see our dunning email examples and templates for copy patterns organized by exactly this kind of decline-reason branching.
- Confirm your dunning emails are actually reaching the inbox. A perfectly configured schedule sending well-branched copy still recovers nothing if the emails are landing in spam — check SPF, DKIM, and DMARC per our dunning email deliverability guide, since this is a separate layer entirely from anything in Chargebee's own settings.
- Decide, deliberately, what happens to invoices once the schedule is exhausted. Whether that's a manual monthly review of past-due invoices, or a connected tool that re-scans them automatically, an explicit decision beats the default of nothing happening at all.
What a recovery layer can honestly add on top of Chargebee — and what it can't
Being precise about the boundary here matters more than a feature list. Chargebee remains the system of record for your subscriptions, invoices, and billing logic — that does not change when you add a recovery layer on top, and no tool that connects read-only to Chargebee should claim otherwise. What a recovery layer like Revova adds is specifically the three gaps covered above: decline-reason-aware email copy generated automatically instead of one generic template, a historical scan across invoices that already exhausted Chargebee's own schedule, and send-time tuning around when a specific customer is more likely to act.
✓ Pros
- +Chargebee's native dunning is already configured and working — no need to rip anything out or migrate billing logic.
- +Adjusting the schedule, email copy, and exhausted-action settings directly in Chargebee costs nothing and can meaningfully improve recovery on its own.
- +A recovery layer connects read-only, so Chargebee stays the single source of truth for subscription state.
✕ Cons
- –Decline-reason branching and a historical scan require either custom engineering work inside Chargebee's webhook/API layer, or a separate connected tool — neither is free.
- –A recovery layer cannot fix a deliverability problem in your sending domain by itself — that still requires the SPF/DKIM/DMARC work covered in our deliverability guide.
- –Some of what a recovery layer adds (AI-personalized copy, automatic historical scans) is genuinely new functionality, not something you can toggle on inside Chargebee's existing settings.
Full plan details, including exactly what's included on Starter versus Pro, are on the Revova pricing page.
How to audit your current Chargebee dunning setup, starting today
- Pull up your dunning settings for every active planin Chargebee and confirm the retry count, day intervals, and exhausted action match what you'd actually choose today, rather than whatever was configured at initial setup.
- Read your current dunning emails as if you were the customer who just had a card expire, and separately as a customer who was just temporarily short on funds — if the email reads identically for both, that is the decline-reason gap described above, live in your account right now.
- Filter your invoices for a past-due or unpaid status older than your configured dunning window, and count how many there are — that count, multiplied by average invoice value, is a rough floor on what the historical-exhausted-invoice gap has already cost.
- Check your sending domain's SPF, DKIM, and DMARC recordsindependently of anything in Chargebee's settings — a schedule and copy problem and a deliverability problem look identical from the outside (low recovery rate) but need completely different fixes.
- Run a historical scan against your actual Chargebee invoice dataif you want a precise number rather than a rough estimate — this reads invoice state directly and does not depend on Chargebee's own dunning schedule having been configured correctly at the time.
For Chargebee's own documentation on configuring dunning management, retry schedules, and exhausted-action settings, see Chargebee's dunning management documentation.
Frequently asked questions
What is Chargebee dunning management, exactly?
Dunning management is the part of Chargebee that automatically re-attempts a subscription invoice after its first payment attempt fails, on a schedule you configure in Chargebee's settings, while sending a matching sequence of reminder emails to the customer. Chargebee runs this per site (not per invoice) — you set the number of retry attempts, the gap in days between them, and the email templates once, and every failed invoice going forward follows that same configured schedule until it either recovers or the schedule runs out.
Does Chargebee dunning use Smart Retries like Stripe does?
Not in the same sense. Stripe Smart Retries uses a machine-learning model trained across its whole network of transactions to pick the statistically best time to retry a specific decline. Chargebee's dunning schedule is rule-based and configured by you — a fixed set of days (for example, day 1, day 3, day 5, day 7) that applies uniformly to every failed invoice on that plan or site, regardless of the specific decline reason. If your underlying gateway is Stripe, some of that gateway-level retry intelligence can still apply to the individual charge attempt itself, but Chargebee's own dunning schedule around it is the configurable, rule-based layer described in this guide.
What happens after Chargebee's dunning schedule runs out?
That depends on the "dunning exhausted" action you configured for the plan — commonly, the subscription is marked as unpaid, paused, or cancelled, and no further automatic retries happen after that point. The invoice itself typically remains in a past-due or unpaid state in Chargebee's records. Nothing is automatically deleted, but nothing keeps trying either, unless a person manually intervenes, the customer proactively updates their card, or a separate recovery process re-approaches that specific invoice.
Can I customize the dunning email templates in Chargebee?
Yes — Chargebee lets you edit the subject line and body of each dunning email in the sequence, and you can typically use merge fields for the customer's name, plan, and amount due. What Chargebee's standard dunning configuration does not do natively is automatically branch the email copy by the specific decline reason returned by your gateway — an expired card, insufficient funds, and a bank decline all commonly receive the same templated email at each step unless you build separate logic for that yourself, which is one of the more overlooked gaps covered later in this guide.
Does Chargebee retry failed payments on weekends or only business days?
Chargebee's retry schedule runs on whatever day intervals you configured, not a business-day-aware calendar by default — a retry scheduled for day 5 fires on day 5 regardless of whether that lands on a weekend. This matters because a card issued by a smaller bank may process retries more slowly around weekends and holidays, which is a scheduling nuance worth accounting for manually when you pick your retry intervals rather than assuming every day behaves identically.
How many retry attempts should I configure in Chargebee?
There is no universal right number, and we are wary of any guide that states one as if it were fact — the right count depends on your billing cycle length, average transaction value, and how sensitive your audience is to repeated emails. What is true structurally, independent of the exact count: too few attempts spread too close together mostly just catch the same instantly-failing hard declines (an expired or stolen card) and waste the remaining attempts on invoices that were never going to recover; too many attempts spread too far apart can let a recoverable soft decline (insufficient funds) sit un-retried for so long that the customer has already churned emotionally, or worse, cancelled elsewhere, before Chargebee tries again.
Does Chargebee tell me the specific decline reason for a failed invoice?
Chargebee surfaces a payment failure and generally forwards whatever decline detail the connected gateway returns, which you can see on the invoice or transaction record inside Chargebee's dashboard. The nuance is that Chargebee's own dunning schedule and default email templates don't automatically branch based on that decline reason the way a decline-aware recovery layer does — the data is there to see manually, it just is not automatically routed by Chargebee's standard dunning configuration into different retry timing or different email copy without your own custom setup.
Can I run Chargebee dunning and a third-party recovery tool at the same time?
Yes, and for many teams this is exactly the right setup — Chargebee stays the system of record for subscriptions and invoicing, while a recovery layer on top adds the parts Chargebee's dunning configuration does not do natively: decline-reason-aware email branching, AI-personalized copy, and a historical scan across invoices that already exhausted the dunning schedule and went unpaid. Revova connects to Chargebee read-only for exactly this reason — it does not replace Chargebee's billing engine, it adds a recovery layer around what Chargebee already tracks.
How is this different from your general dunning email deliverability guide?
They cover two different layers, and it is worth being precise about which one applies to a given problem. Our separate dunning email deliverability guide covers whether any dunning email — from Chargebee, Stripe, or anywhere else — actually reaches an inbox, which comes down to SPF, DKIM, DMARC, and sender reputation, independent of which billing platform sent it. This guide is one layer earlier: how Chargebee's own dunning schedule and configuration decide what to send and when in the first place. A Chargebee dunning sequence configured perfectly can still under-recover if the emails it generates never clear deliverability checks — the two problems compound, and diagnosing a low recovery rate means checking both.
Will changing my Chargebee dunning settings affect existing subscriptions?
Generally, dunning configuration changes in Chargebee apply going forward to invoices entering the dunning process after the change, not retroactively to a schedule that has already started running for an invoice currently mid-sequence — the exact behavior can depend on your specific Chargebee plan and configuration, so it is worth confirming directly in Chargebee's own settings documentation or with their support before assuming a change applies everywhere at once.
Your Chargebee dunning schedule is only as good as what it can't see
Revova connects read-only to Chargebee, adds decline-reason-aware recovery emails on top of your existing schedule, and scans your full invoice history for anything that already exhausted dunning and went unrecovered. 14-day free trial, no credit card, 30-day money-back guarantee.
Start my 14-day free trial →No credit card · Free Lost Revenue scan · 30-day money-back guarantee
