> 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/guides/priority-recovery-and-dynamic-recovery-handling-high-value-failed-invoices.md).

# Priority recovery and dynamic recovery: handling high-value failed invoices

Handling high-value failed invoices: score by ARR, LTV, tenure and CAC, extend recovery for the right customers, and set lifecycle rules per product and segment.

{% hint style="info" %}
**TL;DR:** Not every failed invoice deserves the same effort. Priority Recovery surfaces the failed invoices worth the most (scored by ARR, lifetime value, tenure and acquisition cost) and recovers them across email, SMS and alerts to the account owner. Dynamic Recovery extends the recovery window for customers worth pursuing longer, treats all of a customer's open invoices as one effort, and avoids creating duplicate invoices. Subscription Lifecycle rules then decide, per product and segment, what happens when recovery fails: cancel, void, or leave past due.
{% endhint %}

*By the FlyCode team. Last reviewed September 2026.*

{% hint style="success" %}
**Key takeaways**

* A fixed retry schedule and a fixed cancellation date treat a 29 dollar monthly plan and a 30,000 dollar annual contract identically. Value-based recovery does not.
* Priority Recovery scores each failed invoice on ARR, LTV, tenure and CAC and routes the top of the list to human follow-up while automation handles the rest.
* Dynamic Recovery lengthens or shortens the recovery window per customer, consolidates multiple open invoices into one recovery, and prevents the duplicate-invoice problem that manual retries create.
* Lifecycle rules are set without code, per product and per segment, so an enterprise plan can stay past due for 60 days while a consumer plan cancels after 21.
  {% endhint %}

## The problem with one schedule for everyone

Processor defaults apply one retry schedule and one cancellation rule to every subscription. That is fine for a homogeneous consumer product and wrong for anyone with mixed plans. Three failure modes follow:

* **High-value invoices get the same attention as low-value ones.** A failed annual enterprise invoice sits in the same queue as a failed 9 dollar add-on, with the same three emails.
* **Recovery ends on a calendar, not on likelihood.** Long-tenured customers with a strong payment history are cancelled on day 21 like everyone else, even though their recovery probability is far higher.
* **Manual intervention creates duplicates.** When a customer success manager notices a failed invoice and asks billing to "send a new invoice", the customer ends up with two open invoices and pays neither.

## Priority Recovery

Priority Recovery ranks open failed invoices by what they are worth to the business and routes the top of the list to the channels most likely to close them.

| Scoring input               | Why it matters                                                                                               |
| --------------------------- | ------------------------------------------------------------------------------------------------------------ |
| **ARR of the subscription** | The direct revenue at stake.                                                                                 |
| **Lifetime value**          | Predicted remaining value, so a customer early in a long tenure ranks above one likely to churn soon anyway. |
| **Tenure**                  | Long-standing customers recover at higher rates and are worth a human touch.                                 |
| **CAC**                     | Losing a customer who cost a lot to acquire is more expensive than the invoice suggests.                     |

Actions on the priority list: automated email and SMS sequences continue, and the account owner or customer success manager receives an alert with the invoice, the decline reason and the recommended next step, so the outreach can be personal (a call, a Slack message to the customer's champion, a purchase order fix) while the rest of the book is handled automatically.

## Dynamic Recovery

Dynamic Recovery changes how long and how widely recovery runs for each customer.

1. **Extended windows for the right customers.** Instead of a fixed number of days, the recovery window is extended for customers whose value and payment history justify it, and shortened where the model sees no path to recovery (for example a hard decline with no backup method and no email engagement).
2. **One effort across every open invoice.** When a customer has several open invoices (a renewal plus usage charges, or two months of failures), recovery treats them as one case: one message sequence, one card-update link, and settlement of all open invoices when a payment method works.
3. **No duplicate invoices.** Retries and payments are executed against the existing open invoice; new invoices are not created to "retry", so the customer never sees two bills for one period.

## Subscription Lifecycle rules

When recovery is exhausted, something has to happen to the subscription. Lifecycle rules make that decision explicit, per product and per segment, with no code:

| Outcome              | When to use it                                                                                                                                                    |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Cancel**           | Consumer plans and low-value subscriptions where continued access without payment is a cost.                                                                      |
| **Void the invoice** | Cases where you would rather keep the subscription and forgive the period than lose the customer (for example a long-tenured customer during a card replacement). |
| **Leave past due**   | B2B and enterprise plans where procurement delays are common and access should continue while finance resolves the payment.                                       |

Rules can differ by product (enterprise versus self-serve), by segment (tenure, region, plan value) and by decline type, and they apply consistently instead of depending on who noticed the failure.

## Putting it together: a B2B example

A 24,000 dollar annual renewal fails with `do_not_honor` on a corporate card. The invoice scores at the top of the priority list. Automation retries at the predicted best time and sends a branded email to the billing contact; the account manager receives an alert and messages the customer's champion, who explains the card limit was hit. The customer adds a bank debit as a backup method through the update link; the open invoice is paid, no duplicate invoice was created, and because the lifecycle rule for enterprise plans is "leave past due for 60 days", access was never interrupted.

## FAQ

### Is Priority Recovery only for enterprise plans?

No. It ranks every failed invoice; the difference is what happens at the top of the list. Consumer businesses use it to spot unusual concentrations (a large cohort failing at once) and their highest-LTV subscribers.

### Does extending the recovery window violate card network retry limits?

No. Retry counts stay within Visa and Mastercard rules regardless of window length. A longer window spreads fewer, better-timed attempts and relies more on backup methods and outreach. See [card network retry rules](/docs/read-more/card-network-retry-rules-for-failed-payments-visa-and-mastercard.md).

### Can lifecycle rules be different for trials?

Yes. Trial conversions are a common case for a shorter window and a cancel outcome, while paid renewals keep a longer window.

## Related

* [How FlyCode works](/docs/guides/how-flycode-works-architecture-of-the-recovery-engine.md)
* [Failed payment cost and recovery ROI](/docs/failed-payment-cost-recovery-roi.md)
* [Dunning management 2026 guide](/docs/dunning-management-2026-guide.md)
* [Handling failed payments](https://help.flycode.com/handling-failed-payments) in the Help Center


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.flycode.com/docs/guides/priority-recovery-and-dynamic-recovery-handling-high-value-failed-invoices.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.