Workflow series #2 - Running a multi-country, multi-bank factoring operation

Victor Mithouard
March 2023
min read

Invoice factoring is used by companies to free up working capital. It involves the sale of accounts receivable (invoices) to a factoring company. The factoring company collects customer payments, taking the operational hurdle of recovering the funds and the risk of default. This allows businesses to use their invoices as collateral for quick access to cash, without taking out additional loans or other forms of debt. 

Factoring companies make money by charging a fee for their services. The fee may be a flat rate or it could be based on a percentage of the invoice amount. As they operate on thin margins, factoring companies must be extremely efficient in their collection operations – but this can be difficult when dealing with multiple markets and payment methods.

In this article, we develop how banking aggregation platforms such as Numeral support factoring companies by centralising and automating all payment operations through a single API and central dashboard. Let’s dive into the workflow.

Buying a receivable invoice

Selecting a connected account

The factoring company starts by receiving an invoice to be factored from one of its customers. Upon acceptance of the invoice, the factoring company decides to initiate the payment from one of its accounts. In Numeral, connected accounts can be any bank accounts for which the company has a cash management contract with its banking partners. This can for example include payments accounts, operating accounts, or accounts holding collateral for default provision.

Multiple banks can also hold connected accounts in multiple geographies. By changing the connected_account_id in payment, the factoring company can change the originating accounts for its payouts to best fit its treasury and operational needs.

Processing the payout

If the customer is new, its banking details are then created in Numeral in a new counterparty account object storing account information as well as any meta relevant for reconciliations.



The payment is initiated using the newly created counterparty object by creating a payment order object. By setting the attribute to type=sepa_instant, the payment order will be paid through a SEPA instant credit transfer to provide faster liquidity to the customer.


After its creation, the payment is usually approved before it is sent to the bank. Approvals can take place at the payment order level or at the file level. Numeral automatically batches individual payment orders into ISO 20022 payment files transmitted automatically to the bank.



Once approved and batched into a payment file, the payment file is transmitted to the bank for processing. Numeral then updates each payment order’s status in real-time whenever the bank shares file updates on its servers. Status updates are streamed back to the company’s own system through webhooks.

Recovering the receivable invoice with the invoice debtor

With the invoice advance paid out, now comes the hard part for the factoring company: recovering the amount due on payment terms. There are multiple ways for factoring companies to conduct recovery.

In this section, we will focus on two main ones

  • Through an incoming credit transfer automatically reconciled through virtual IBANs

  • Through direct debit initiated by invoice on pre-agreed terms

Reconciling incoming payments

Creating and assigning a virtual account Virtual IBANs are key tools provided by banks to automate the incoming payment reconciliation process. In the recovery process, the factoring company associates a virtual IBAN with the debtor company in its systems. All invoices sent to the debtor will request payment to this virtual IBAN. In Numeral, linking the virtual IBAN to the counterparty is done by creating a virtual account linked to the debtor’s counterparty.



Creating an expected payment to automate reconciliations Reconciling a transaction with an expected invoice repayment can be a challenging task when thousands of payments are received per day. Numeral supports full incoming payment automation through the use of expected payments. An expected payment is a payment that is not initiated through Numeral, but that you nonetheless want to track and reconcile with a transaction. The expected payment is linked to the virtual account created above.


Reconciling and monitoring expected payments Upon the booking of a transaction on the bank account, the Numeral automatic reconciliation engine will create a reconciliation between the relevant transaction and the expected payments, updating the expected payment to reconciled status. Reconciliation rules can be tailored to your company's needs and can leverage up to 10+ parameters for matching. Numeral will also send a real-time notification through webhooks when the reconciliation happens.

When debtors miss their due dates, the collection process must be escalated. Collection teams can then either use:

  • The Numeral dashboard to filter all their expected payments by date to immediately create views of non-reconciled expected payments which can be transmitted to the relevant team in charge of recovery

  • The API to extract a list of those overdue expected payments and send the list to other systems within the company

Direct debits

Creating a direct debit order At the invoice due date, the factoring company can initiate a direct debit payment by creating a payment order with type=sepa and direction=debit. The payment order includes the invoice details and the associated direct debit mandate details.


Just like any payment order, it can be reviewed and approved, at the payment order level and payment file level. Once approved, it is sent to the bank in a payment file created by Numeral.

The Numeral reconciliation engine automatically reconciles upcoming transactions on the account with the direct debit operation based on a combination of data around the payment itself, its counterparty and various technical IDs. If webhooks are set up, Numeral also notifies the factoring company’s systems of the reconciliation.

Managing SDD rejections and returns With an average failure rate of a direct debit anywhere between 2.6% and 3% and potential refunds for up to 13 months, R-transactions (rejects, refunds, returns…) need to be identified and acted upon quickly.

R-transactions trigger in Numeral a real-time update of the payment order status. A reconciliation between the return transaction on the account and the related payment is then created. Tracking returns through the Numeral dashboard can save significant time in resolving incidents. To further automate, webhooks can be set up to automatically trigger other company processes (like emails or internal notifications) with the need for human intervention.

Other articles you might like

Not sure where to start?

Let’s talk about how we can work together to accelerate your payment flows. Get a demo of our platform, explore our pricing, or get started right away.

Contact us