Skip to main content

Invoice Flow

Let's begin by walking through the major events in the invoice flow step by step 👣. From creation 👶 of an invoice, to the point when it is paid, booked, and the founds are in the clients bank account 👴.

Generating an Invoice​

An invoice is most commonly created via an ERP integration. When the integration has been setup a sync can be triggered from the Client Portal. It is also possible to create invoices manually via the Operations Portal or a batch import tool.

Factoring​

It is now possible for the client, using the Client Portal, to request financing on an invoice with or without recourse. The partner will need to process this request, which may include credit checks on the debtor. In some instances the partner uses a third party for financing the invoice. The platform has integration to support both credit checks and third party financing requests.

Invoice Activation​

Activating the invoice means that the invoice is ready for distribution. When an invoice is activated certain fields can no longer be changed as the invoice may already be sent to the debtor.

Invoice Distribution​

There are several ways that an invoice can be distributed, many of which are regional by nature. Distribution methods supported in the Quiddly platform include letter, email, SMS, electronic invoices and digital-mailbox. Quiddly integrates with distribution service providers who can fulfill the partner's distribution needs. This means that the partners can choose what distribution service providers to use.

Retry and Fall Back Distributions​

The distribution method for an invoice can be seen as a hierarchy of options. If the first option is not possible (e.g. due to a lack of data) or fails (e.g. due to an incorrect address), then the next option is tried. The final option is always for the invoice to be sent by letter, if this is returned manual action is needed.

A distribution can fail for several reasons triggering a fall back or retry logic. The exact steps taken depend on the distribution method.

To illustrate with an example lets say an invoice is to be distributed by email, but the address is incorrect or does not exist. This would create an errand to notify the client via the portal and a daily report. If the client follows up on this providing a new email address the distribution by email can be tried once again. If not the fall-back option will be used and the invoice will be sent by letter.

Invoice Payment​

The platform supports multiple payment methods. Just like with distributions, payment methods can be regional by nature and may rely on third party service providers. These are available in the Debtor Portal. Bank payments remains the most common, for this we import payments by reading in payment-files exported from the bank. We use the invoice's payment references provided by the debtor when making a payment to match payments and invoices. When the invoice is paid in full it is closed.

Part Payment​

The debtor may choose to split up a payment over a longer period of time. This is done in the Debtor Portal and requires debtor authentication. Doing so results in several smaller invoices being issued at regular intervals until the debt is paid.

Expired Invoice​

If the invoice is unpaid the day after its due date we refer to it as expired, and it is subject to reminder- and interest fees.

Reminders and Interest​

During their on-boarding each client will set how they want this handled by default, setting the time to expiry, notification rules, amount fee and amount interest. The platform allows fine-grained control of how expired invoices are handled. Interest is controlled using reminder profiles.

Collection​

If an invoice remains un-paid for an extended period of time past its due date a collection errand can be opened. Collection can either be done by the partners or a third party. If the collection errand is not successful the invoice sender can pursue legal action. The platform has functionality to help keep track of collection errands.

Charges for Service​

The partner applies fees, referred to as charges, for services rendered to the client. These are managed by a price list and are grouped into bills.

Payouts to Client​

On a daily basis the client will transfer the payments they have received to the clients. The record of the client payouts for a given product is called a payout batch. The system calculates the amount and the payment is done manually via the bank.

Bookkeeping​

Any financial event will generate a voucher in the platform. This information is needed in the client's bookkeeping system. Voucher export is normally handled via an integration, although a file export alternative exists.