The Reference Docs Developer Hub

Welcome to the Reference Docs developer hub. You'll find comprehensive guides and documentation to help you start working with Reference Docs as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    

Dunning Effectiveness

Dunning Effectiveness

Learn about the effectiveness of your current and past dunning cycle settings. Of the invoices that go past due, this report tracks the dunning recovery rate, amount of revenue recovered and number of subscriptions saved.

What's included in the report?

  • This report includes 3 methods for evaluating Dunning Effectiveness - Invoices Recovered (Recovery Rate), Revenue Recovered and Subscriptions Saved. It also has 2 sections for each method: Recovery over time and Dunning Lifecycle.
  • This report only includes AUTOMATIC invoices. Manual invoices and Manual invoice dunning settings are excluded from this report at this time.

Recovery over Time

Each vertical line on the graph represents a dunning version. A version is created when dunning settings are changed. If dunning settings are changed more than once in a month, only the last version in that month will show on the graph.


Monthly Recovery Rate

  • Similar to a cohort analysis, the invoice recovery is attributed to the time interval the invoice was billed rather than the time interval during which it was recovered. Example: If an invoice was billed on Jan 15th and was recovered on Feb 14th, the invoice would be counted towards the recovery numbers in January.
  • Recovered - Invoices that went past due and were recovered by some method, including but not limited to customer updates or retry logic. Other recovery reasons include account updater or force collection, for example.

  • Not Recovered - Invoices that went past due and were not recovered before the end of dunning. Depending upon your dunning settings, these invoice will be marked as “failed” or remain in a “past due” state.

  • Recovery Rate = (Invoices created during the selected interval that were recovered / invoices created during the selected interval) * 100.


Monthly Revenue Recovered

  • Similar to a cohort analysis, the revenue recovered is attributed to the day, week, or month when the invoice was created rather than when it was recovered.

NOTE: this is different from the Revenue Recovered report, which sums the amount of revenue recovered from invoices closed (aka paid) in that month.

  • Use Dunning Effectiveness Report to measure the impact of a dunning settings to invoices that were planned to be paid in X month but go past due and are later recovered.
  • Use Recovered Revenue Report to measure the amount of revenue from paid invoices that was recovered through Recurly's proactive (Account updater) and reactive measures (retry logic) in specific months.*

    • Total Billed - On a single invoice, this is the amount billed minus any applied credit payments. Total billed is the sum of all invoices created in the selected date range.

    • Customer Updates - The total amount billed on past due invoices that was recovered due to a customer updating their billing information.

    • Successful Retries - The total amount billed on past due invoices that was recovered due to a successful transaction retry by Recurly.

  • Total Recovered - The total amount billed on past due invoices that was recovered due to any recovery reason, including but not limited to customer updates or successful retries. Note that invoices can also be recovered from account updater while in dunning or by force collect.

    • For multi-currency sites, select a currency to view the revenue recovered on invoices processed in that currency.


Subscriptions Recovered

  • Similar to a cohort analysis, the subscription saved is attributed to the time interval the subscription went “at risk” rather than the interval in which it was saved.

  • Subscription At Risk: A subscription on an invoice that went past due into dunning.

  • Non-Active Paying: Subscriptions are included in this category if the invoice created for that subscriptions in a certain month was NOT recovered but the subscription remained active. This can happen through one of two ways:
    (1) Your site's dunning settings are set to keep the subscription active at the end of dunning
    (2) While the original invoice that went past due failed, another invoice was created before the end of dunning. This second invoice was paid by the customer and the subscription stayed active.

  • Filtering this report by plan allows you to see the number of subscriptions in each plan at the time its corresponding invoice went past due into dunning.

Dunning Lifecycle

This section of the report helps you monitor the efficiency of your current and past dunning settings by evaluating when in the dunning lifecycle recovery happens. Recovery is measured by invoices recovered, revenue recovered or subscriptions recovered, based upon selection.

  • When a dunning setting version is selected, you can view the recovery of all invoices that went into that dunning cycle as a recovery rate, revenue recovered or number of subscriptions saved.

  • The “days after first failure” intervals are created based upon when emails are sent in the selected dunning setting version.

  • Note that this section of the report only includes invoices/revenue/subscriptions that were recovered DURING the dunning window. Recovery after dunning ends is not included in this section.

Ways to use this report

  • Monitor your dunning recovery over time and identify changes to recovery at the time dunning settings are changed.
  • Understand the effectiveness of your current or past dunning settings and make corresponding changes to length, number of emails sent, etc. based upon this information.
  • Note: This report includes data from August 2016 going forward.
  • Availability - This report is only available to merchants on Recurly’s Professional or Enterprise 2016 plans. Please contact support if you are interested in access to this Report.

Updated 3 years ago

Dunning Effectiveness

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.