Invoice repurchasing in working capital finance programmes

Invoice repurchasing is a feature of many invoice-backed working capital finance programmes, but it’s often a slightly blurred area where implementation is inconsistent between different programmes and interpretation can often depend on local jurisdictions and associated legal frameworks.

The obligation of a borrower to repurchase invoices depends on a combination of legal framework, program type and the repurchase reason.  So for example, in an off-balance sheet (non-recourse) transaction, repurchasing due to invoice credit performance would not be a contractual obligation, but is often done voluntarily by the borrower to avoid breaching triggers or to protect the overall funding programme.  Other contractual provisions relating to items such as dilutions or fraud could however force an invoice repurchase.

On-balance sheet (recourse) transactions are of course different.  The contract terms could require repurchase in the event of adverse credit performance, similar to the repurchase obligations as a result of dilutions or fraud.  And even in borrowing base transactions, a repurchase proxy exists through eligibility rules that jettison or expel invoices from the borrowing base when certain credit performance, eligibility criteria, warranties or programme obligations are breached.

The Aronova View

As service providers our role is not to structure transactions or set legal frameworks, but we increasingly see behaviour that is not traditionally monitored, and is probably not even considered when setting up the programme. This behaviour could affect eligibility and therefore funding, and should in many cases force the repurchase of an invoice, irrespective of the programme type.

Consider the case where an eligible invoice is submitted and sold (or forms part of the borrowing base), only for the issue date or due date of the invoice to be updated so that the invoice, if retested, would no longer be eligible.  Or what happens if the value of a sold invoice subsequently changes relative to the advanced amount, so that an ineligible advance rate has now been applied.

We see activity like this on a regular basis and in response we built Collateral Shield as a means of protecting the funder (and insurer) against this silent, mostly unobserved activity.  On a programme-by-programme basis, Collateral Shield applies a repurchase strategy that can be configured to respond to certain events.  So for example, if we detect a due date change to a sold invoice, Collateral Shield could automatically repurchase the invoice and retest it against relevant eligibility criteria.  It would only then be resold to the programme if it were still eligible.

Collateral Shield makes it possible to control repurchase activity in a more systematic way and to enforce repurchasing when required by the funding or insurance programme.