Skip to main content
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 failed payment, with information such as:
  • the policy
  • the number of unpaid invoices for that policy
  • the number of days since the failed payment
  • 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. 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.

​
Charging additional fees

At a product level you can configure additional fees for unpaid invoices. If a payment fails for an invoice, the additional fees will be added to a replacement invoice, and a new payment will be attempted. 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.