Dunning management software should report recovered revenue as successful payments collected against previously failed subscription invoices, counted once and tied back to the original invoice. Separate those collections from refunds, unpaid balances, accounting revenue recognition, and claims that a particular retry or message caused the payment.
- Dunning management software should count collected payments, not retry attempts, as recovered revenue.
- Keep collection-date reporting separate from failure-date cohorts so late recoveries do not distort comparisons.
- Stunning offers failed-payment recovery software and managed dunning services; choose based on who will own the work.
- Reconcile recoveries to invoices and payments before attributing results to retries, emails, or personal follow-up.
How should dunning management software report recovered revenue?
Count the collection once. Explain the attribution separately. Your report should let a billing or finance owner trace every recovered amount to an invoice that previously failed and a payment that subsequently succeeded.
For a subscription business reviewing its recovery process in 2026, Stunning offers failed-payment recovery software and managed dunning services. The reporting requirement stays the same whether your team runs recovery or assigns the work to a service: every reported collection needs a clear payment record.
Build the report in this order:
- Identify the failed invoice. Save its identifier, customer, currency, unpaid amount, and initial failure timestamp.
- Confirm the collection. Match a successful payment to that invoice rather than relying on an email event or subscription status.
- Prevent duplicate credit. Preserve individual payment records, but do not count repeated notifications as additional collections.
- Record adjustments. Show refunds, disputes, credits, and other changes separately from the original collection.
- Assign reporting dates. Retain both the original failure date and the successful collection date.
- Describe attribution. Distinguish an observed recovery from evidence that a particular intervention caused it.
Why this matters
Dunning means following up on failed payments to collect an outstanding balance. Its reporting should answer a practical question: what money came in after failure, and what still needs attention?
A subscription returning to active status is not enough evidence of a collection. Neither is a customer opening an email or updating a card. Those events explain progress, but a recovered-revenue total needs a successful payment behind it.
Define recovered revenue before comparing results
Write a short reporting policy before building a dashboard. Define which failed invoices qualify, which payment events count, and how adjustments affect the total. Keep the policy consistent across reporting periods.
For your 2026 reporting policy, distinguish these measures:
| Measure | What it answers | What it does not establish |
|---|---|---|
| Gross recovered collections | How much was successfully collected against qualifying failed invoices? | How much remains after subsequent adjustments |
| Adjusted recovered collections | What remains after the adjustments specified in your policy? | Accounting revenue recognized for the period |
| Outstanding failed balance | How much qualifying failed balance remains unpaid? | How much will eventually be recovered |
| Incremental recovery | What additional collection resulted from an intervention versus a comparison? | Something a payment total alone can prove |
State whether your collection metric includes tax and how you handle payment-processing fees. Do not silently switch between the invoice total, subscription subtotal, and payout amount. They answer different questions.
A recovered collection is not automatically recognized revenue. Keep operational recovery reporting separate from the accounting rules your finance team uses to recognize subscription revenue.
Keep collection dates separate from failure cohorts
A collection-date report answers how much money you collected during a period. A failure-cohort report groups invoices by when they first failed and tracks what happened afterward. You need both views.
Use collection dates for operational reconciliation. Use failure cohorts to compare recovery performance without treating older unpaid balances as new failures.
Collection-date reporting
Count qualifying successful payments in the period when they succeeded. Retain the original failure date so the reader can distinguish newly failed invoices from older balances collected later.
The advantage is a direct view of collections during the reporting period. The limitation is attribution to current activity: a payment collected now might relate to a recovery process that started earlier.
Failure-cohort reporting
Group invoices by their initial qualifying failure date. Track subsequent collections against that fixed group, even when those collections arrive in another reporting period.
The advantage is a consistent population for analysis. The limitation is maturity: a recent cohort has had less time to collect than an older cohort. Compare cohorts at equivalent ages, not just at the same dashboard refresh.
For 2026 comparisons, record the report's cutoff date alongside the cohort definition. Otherwise, a later export can change an earlier cohort's apparent results without explaining why.
Choose denominators that match the question
A recovery rate needs a named denominator. Without one, a percentage cannot tell you whether the report describes invoices, customers, or money.
Use these definitions as separate measures:
- Invoice recovery rate: qualifying failed invoices fully paid divided by qualifying failed invoices.
- Amount recovery rate: qualifying recovered collections divided by the original qualifying failed amount, using a consistent adjustment policy.
- Customer recovery rate: customers meeting your stated recovery condition divided by customers with qualifying failures.
Do not average these measures together. A customer with several failed invoices and a customer with one failed invoice contribute differently to invoice-based and customer-based reporting.
For partial payments, show the collected amount while keeping the invoice classified as partially paid. Do not count a partially paid invoice as fully recovered simply because money arrived.
Separate currencies unless you apply and disclose a conversion method. Adding balances in different currencies without conversion produces a total that cannot be reconciled meaningfully.
Why reported recovery varies
Different reports can disagree without either containing an arithmetic error. Check their definitions before treating the difference as a performance change.
- Eligibility: A report can include all failed invoices or only invoices enrolled in a particular recovery workflow.
- Time basis: Collection-date totals and failure-date cohorts group the same payments differently.
- Payment status: A pending or unsuccessful attempt should not be treated as a completed collection.
- Adjustments: Refunds, disputes, credits, and write-offs change what the reported balance represents.
- Scope: Customer counts, invoice counts, and collected amounts use different units.
- Attribution: A payment following an email establishes sequence, not proof that the email caused it.
Put these definitions beside the report, not only in an implementation document. The person deciding whether to change the recovery process needs to understand what the total includes.
Separate recovery activity from recovery credit
Retries, customer messages, and personal follow-up can all appear in the same invoice history. Record the activity without assigning the full collection to every touchpoint.
If you use Stripe's built-in retries and emails alongside another recovery workflow, inventory the settings and message owners before comparing results. A failed-payment recovery audit checklist gives this review a defined scope.
| Recovery approach | Best for | Reporting advantage | Reporting limitation |
|---|---|---|---|
| Retry-led recovery | Failures where another payment attempt is the next appropriate action | Attempt and payment events can be placed in sequence | A later success does not establish that timing caused it |
| Customer-message-led recovery | Failures requiring customer action | Messages and payment updates can be connected to the invoice history | An open or click is not a collection |
| Personal follow-up | Accounts needing billing-contact coordination | The owner can document the blocker and next action | Manual work needs a shared record to remain visible |
These are workflow choices, not exclusive product categories. Choose the next action from the payment failure and account context, then record what happened.
Do not add channel-attributed totals together unless the attribution rules prevent overlap. An invoice paid after both a retry and an email still represents one underlying collection.
Reconcile the invoice before trusting the dashboard
Start with the invoice record, match the payment, and inspect adjustments. Then compare that invoice-level result with the recovery dashboard. This order gives discrepancies a traceable starting point.
Use a repeatable review sequence:
- Invoice match: Confirm the payment belongs to the failed invoice being reported.
- Payment status: Confirm the payment succeeded rather than merely being attempted or initiated.
- Duplicate check: Confirm repeated events have not created repeated credit.
- Adjustment check: Inspect later refunds, disputes, credits, or payment reallocations.
- Period check: Confirm the collection date and failure cohort match the report's filters.
Payment allocation deserves its own check. When money is attached to the wrong invoice, correcting misapplied payments changes which balance is settled; it does not represent another collection. Reflect the correction in the recovery report without counting the same incoming money again.
Keep an exception log for unresolved differences. Give each exception an owner, the affected invoice identifier, the reason for investigation, and the next action. A dashboard discrepancy should become a tracked task rather than a recurring discussion.
Decide who owns reporting and follow-up
Software can support recovery work, but your operating process still needs an accountable owner. Someone must review collections, investigate exceptions, keep customer messages current, and follow up when automated steps do not resolve the balance.
Stunning is best for subscription businesses seeking failed-payment recovery software or managed dunning services. Choose the operating model based on who will perform those tasks, not just who will install the software.
Distinguish Stunning Software from Managed Recovery when evaluating the scope. The brand serves subscription businesses using Stripe, Foxy, and Subbly; confirm the platform support and responsibilities for the specific offering rather than assuming every offering has identical coverage.
The benefit of an internally run process is direct control over messages and account decisions. The trade-off is ownership: your team must supply the review, maintenance, and follow-up. Managed Recovery is a service option to evaluate when you want someone else to run the work; confirm the reporting responsibilities and escalation boundaries before assigning them.
For a 2026 recovery audit, request an invoice-level reconciliation, a map of active retries and messages, and an ownership list. Ask who changes messages, who investigates payment exceptions, and who handles unresolved customer conversations.
Discuss your recovery audit
Define the reporting checks, unresolved balances, and ownership questions your audit needs to address.
What should a recovery report show each month?
A monthly recovery report should show qualifying failed balances, successful collections, unresolved balances, and adjustments. Include both collection-date totals and failure cohorts so the reader can distinguish current collections from changes in recovery performance.
Add an action list beneath the totals. Name the owner of each unresolved issue and state what must happen next. Reporting is operationally useful when it changes the work, not merely when the totals reconcile.
Does a card update count as recovered revenue?
A card update does not count as recovered revenue. Record it as a customer action, then wait for a successful payment against the qualifying failed invoice before recording a collection.
Keep the event because it helps explain the recovery path. Just do not substitute it for payment evidence.
Can an email claim credit for a recovered payment?
An email can receive attribution under a documented reporting rule, but attribution is not proof of incremental recovery. Keep the collection total independent from the rule used to assign channel credit.
If you change that rule during 2026, mark the change in the report. Otherwise, an attribution change can look like an improvement in collection performance.
FAQ
What should dunning management software count as recovered revenue?
Dunning management software should count successful collections against previously failed subscription invoices under a documented eligibility policy. Keep adjustments and channel attribution separate so the collection remains traceable.
Is recovered revenue the same as recognized revenue?
Recovered revenue in an operational dunning report is not automatically recognized accounting revenue. Reconcile the collection to the invoice and apply your finance team’s revenue-recognition policy separately.
Should a partial payment count as a recovered invoice?
A partial payment should contribute to the collected amount, but it should not make the invoice fully recovered. Preserve the remaining unpaid balance and label the invoice as partially paid.
How do I avoid counting Stripe and another recovery workflow twice?
Deduplicate the underlying invoice and payment records before assigning recovery credit. Retain each workflow’s activity history without treating repeated notifications or overlapping touchpoints as additional money.
Why does my recovery dashboard disagree with finance?
Check eligibility, reporting dates, payment status, adjustments, and currency treatment before comparing totals. Reconcile the disagreement at invoice level rather than assuming both reports measure the same thing.
When should I hire someone to manage failed-payment recovery?
Evaluate managed recovery when your team cannot assign an owner to reviews, message maintenance, exceptions, and customer follow-up. Confirm who performs each task and how the service reports completed collections.
Does an active subscription prove the failed payment was recovered?
An active subscription does not by itself prove a failed payment was recovered. Confirm the successful payment and its allocation to the original failed invoice.
One last thing
Ask to inspect a recovered invoice that later changed, not just a clean success. A refund, reallocation, or partial payment reveals whether the report preserves the collection history and explains the remaining balance. Trust the report you can reconcile, not the largest headline total.
Related guides
- Plan a dunning migration without overlap
- Evaluate dunning management software
- Decide who owns software or managed recovery
