Recover unpaid invoices

With a large number of policies all being billed at different rates, it is easy to lose track of outstanding invoices. Korint proposes an unpaid management module to visualize failed payments, and automate payment recovery.

Customer Balance

Each customer has a balance tracking the difference between invoices and payments. If a balance is negative, then the customer owes money for their policy. If the balance is positive, then the customer is owed money - typically this happens after a customer requests to stop the policy at a date far in the past, for example if they forgot to declare a sale of their insured asset.

Tracking failed payments

Each brokerage firm can access an accounting summary of their portfolio. In it you will find a list of all policies that have at least one unpaid invoice — a failed or disputed payment, or an issued invoice still awaiting settlement, such as one owed by a customer paying outside the platform — with information such as:

• the policy
• the number of unpaid invoices for the customer
• the number of days since the failed payment, or since the issuance when no payment was attempted
• the planned recovery action, when automatic recovery is enabled
• links to dashboards so that you can retry payment, send a recommended letter (ERE) if configured, suspend or stop the policy.

You can filter these results by issuance date of the invoices, and separate the policies Korint is already chasing with automatic retries from the ones left to collect by hand.

Recovery forecasts use the customer’s current invoices, payment attempts, and product configuration. Actions depend on the balance remaining unpaid. Planned dates may be in the past; execution is not checked.

All failed payments can be retried. By default, the retry will use the current default payment method.

Falling back to another payment method

A payment method can become permanently unusable: a bank cancels a direct debit mandate, closes the account, blocks direct debits on it, or a card expires. Retrying such a method can never succeed, and the carrier collects nothing.

A product can therefore declare a fallback payment method type. When every method of the product's usual billing type is beyond repair, the next payment is taken on the fallback type instead — a card, typically. The fallback applies only in that situation: a mandate still waiting for its signature is left alone, because it will become usable, and a payer with no registered method is not affected. A method chosen explicitly by an operator is never substituted.

This is a deliberate trade-off for programmes whose usual billing type carries the lowest transaction fees: collecting with the fees of a second payment type is preferable to not collecting at all.

Automating recovery

You can describe a product's whole recovery ladder in its configuration, and Korint walks that ladder once a day for every policy that still owes something. One clock drives all of it: the number of days since the earliest invoice that is currently unpaid was issued. Settle everything and the cycle ends; the next failure starts a new one from zero.

Three tracks share that clock:

• Retries re-attempt the payment of a single invoice, on the configured method and its fallback. A failed invoice replaced by one carrying the unpaid fees is chased on the replacement, whose own charge is the first retry: it already follows the configured method, warns the payer before a card attempt, and leaves the remaining attempts for the days that follow.
• Reminders email the payer. You get one per policy rather than one per invoice, and they cover the invoices retries cannot recover — a revoked mandate, or a failure reason outside the list you configured.
• Escalation is the dunning ladder, run on the calendar whatever the retries are doing: email the broker, send a formal notice, suspend the policy, then cancel it for non-payment.

Every email in recovery — the reminder, the broker notice, the warning before a card retry — names a trigger from the product's emails configuration rather than a template of its own, so one place keeps deciding the template, the recipients and the layout.

A rung you cannot act on is skipped rather than retried. A formal notice needs the registered-letter integration enabled on the product, a suspension needs a policy that is still running, and a cancellation is never attempted on a policy that is already stopped.

Recovery runs at night, after billing and renewals, so an action you configure for day 30 happens on the night of day 30 rather than at the hour the payment first failed. Until you switch a product on, Korint still evaluates and publishes the same ladder every day without executing any of it, so you can read what would have happened on each policy's recurring-tasks timeline.

Charging additional fees

At a product level you can configure additional fees for unpaid invoices. When a payment fails for an invoice, the additional fees are added to a replacement invoice and a new payment is attempted.

Fees are only charged when the failure is the payer's own — insufficient funds, a closed account, an expired card, a revoked mandate. A failure caused by the payment provider or by an opaque bank refusal that gives no motive is recovered without any fee: the invoice is still chased, and retries continue as usual. A Korint-side infrastructure error never fails the invoice in the first place, so it starts no recovery at all. Card refusals are judged on the decline code underneath them, since the refusal itself carries no motive.

The list of chargeable codes is configuration, not code: a product can override it, and an empty list turns fees off for that product entirely.

For example, a customer is invoiced 100€, and additional fees are set to 10€. If the payment for that invoice fails, then the invoice is automatically credited and a new invoice for 110€ is issued.

Invoice	Amount	Status
Original invoice	100€	WRITTEN_OFF - This invoice has been credited
Credit invoice	-100€	CREDITED - Credits Original invoice
December 2025	110€	PAYMENT_IN_PROGRESS - Replaces Original invoice