> For the complete documentation index, see [llms.txt](https://docs.flycode.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flycode.com/docs/read-more/recovery-metrics-and-reporting-reference.md). # Recovery metrics and reporting reference Definitions and formulas for failed payment recovery metrics: recovery rate, baseline, incremental lift, time to recovery, attempts per recovery, outreach funnel. {% hint style="info" %} **Quick answer:** Measure failed payment recovery with four numbers: recovery rate (recovered failed invoices divided by failed invoices, by count and by amount), incremental recovery above your pre-tool baseline, time to recovery, and attempts per recovery. Gross recovery alone is misleading because processor defaults already recover a large share; incremental lift is the number that reflects what a tool earns, and it is the basis for FlyCode's pricing. {% endhint %} *Reference maintained by the FlyCode team. Last reviewed September 2026.* ## Core metrics | Metric | Definition | Formula | Notes | | ------------------------------------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Failed payment rate** | Share of subscription charges that fail on first attempt. | failed first attempts / total first attempts | Typically 5 to 15 percent for subscription businesses; higher for consumer, prepaid-heavy and low-AOV books. | | **Recovery rate** | Share of failed invoices eventually paid within the recovery window. | recovered failed invoices / failed invoices | Report by count and by amount; large invoices skew the amount view. Processor defaults land at roughly 40 to 55 percent; best-in-class programs reach 70 to 91 percent. | | **Baseline recovery rate** | Recovery rate before a new tool or process, over a fixed lookback (90 days is standard). | as above, over the pre-change period | The comparison point for every lift claim. Freeze it at cutover. | | **Incremental recovery (lift)** | Recovery attributable to the change, above the baseline. | (recovery rate after minus baseline) x failed amount | Express as percentage points and as currency. FlyCode charges a percentage of this amount only. | | **Incremental lift on top of processor defaults** | Incremental recovered revenue divided by what the processor failed to recover. | incremental recovered / (failed amount x (1 minus baseline)) | The denominator is the recoverable pool, not all failures; this is how the open [Stripe recovery benchmark](https://www.flycode.com/blog/stripe-failed-payment-recovery-benchmark) scores vendors. | | **Time to recovery** | Days from first failure to successful payment. | median and p90 of (paid date minus first failure date) | Shorter is better for cash flow and for customer experience; watch p90 for long tails. | | **Attempts per recovery** | Retries used per recovered invoice. | total retry attempts / recovered invoices | Lower with better timing. Rising attempts with flat recovery signals a stacked or over-aggressive schedule. | | **Retry success rate** | Share of retry attempts that are approved. | approved retries / retry attempts | Compare by decline code and by attempt number. | | **Recovery by method** | Split of recoveries by how they were achieved. | retry / backup payment method / outreach / manual | Shows how much is silent. A healthy program recovers most soft declines before any message is sent. | ## Outreach funnel metrics | Metric | Definition | Notes | | -------------------------------- | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------- | | **Contact rate** | Failed invoices that received at least one email or SMS / failed invoices | Should be well below 100 percent; silent recovery handles the rest. | | **Open and click rate** | Standard email and SMS engagement on recovery messages | Segment by decline type; hard-decline messages should outperform. | | **Update completion rate** | Card updates completed / update links clicked | Login-free links raise this materially. | | **Outreach-attributed recovery** | Invoices paid within a defined window after a message, with no successful retry in between | Attribution window and precedence rules must be stated. | | **Opt-out rate** | Unsubscribes or STOP replies / messages sent | Rising opt-outs usually mean messages are going out too early. | ## Churn metrics | Metric | Definition | Formula | | ------------------------------ | ------------------------------------------------------------ | -------------------------------------------------------------------- | | **Involuntary churn rate** | Subscribers lost to unrecovered payment failure in a period. | cancellations for non-payment / subscribers at period start | | **Involuntary share of churn** | How much of total churn is payment-driven. | cancellations for non-payment / all cancellations | | **Recovered MRR** | MRR retained because failed invoices were recovered. | sum of MRR of recovered subscriptions | | **Post-recovery retention** | Whether recovered customers stay. | recovered customers still active after 90 days / recovered customers | Benchmarks by segment are in [Involuntary churn benchmarks by segment](/docs/read-more/involuntary-churn-benchmarks-by-segment.md). ## Reporting rules that keep the numbers honest 1. **State the denominator.** Recovery rate on "invoices we emailed" is not the same as recovery rate on all failed invoices. Campaign-based figures overstate performance. 2. **Fix the window.** Recovery windows of 21, 30 and 60 days produce different rates; report the window with the number. 3. **Separate cohorts at cutover.** Invoices that failed before a tool change belong to the old cohort even if they recover after it. 4. **Watch first-attempt authorization.** If first-attempt approval drifts down while a retry tool runs, retries are being stacked; net recovery should subtract that loss across all volume. 5. **Report by count and amount.** A tool that recovers many small invoices and misses large ones looks good by count only. ## Where the numbers live in FlyCode The FlyCode dashboard reports recovery rate against your frozen baseline, incremental recovered revenue, recovery by method (retry, backup card, outreach), time to recovery, attempts per recovery, the outreach funnel, trial recovery as a separate view, and Reactivation volume and engagement. Periodic reports summarize the same metrics for finance. ## FAQ ### What is a good failed payment recovery rate? Processor defaults recover roughly 40 to 55 percent of failed subscription invoices. Programs combining adaptive retries, backup payment methods and coordinated outreach reach 70 to 91 percent in published customer results. The right comparison is your own baseline, not an industry average. ### Why measure lift instead of gross recovery? Because the processor already recovers a large share for free. A tool claiming 80 percent gross recovery may add little beyond that. Incremental lift over your baseline is what the tool actually delivered, and it is what pay-on-recovery pricing is based on. ### How long should the baseline period be? Ninety days is standard: long enough to cover three billing cycles and seasonal pay-date effects, short enough to reflect the current book. ## Related * [Failed payment cost and recovery ROI](/docs/failed-payment-cost-recovery-roi.md) * [Involuntary churn: the hidden revenue killer](/docs/involuntary-churn-hidden-revenue-killer.md) * [Failed payment recovery glossary](/docs/read-more/failed-payment-recovery-glossary.md) * [Analyze your subscription churn (free report)](/docs/introduction/analyze-your-subscription-churn-free-report.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.flycode.com/docs/read-more/recovery-metrics-and-reporting-reference.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.