How to Build an Invoice Factoring Company

Introduction

Running a growing business, especially a small business, comes with cash flow challenges that have faced entrepreneurs since the dawn of commerce—so much so that some of the earliest writing ever discovered, in the Mesopotamian Code of Hammurabi, codifies how small business financing should be done. And these days, as more commerce moves online, there’s a new crop of online financing companies that take the form of lending often referred to as invoice factoring.

Invoice factoring advances cash against invoices a company has issued, effectively prepaying the funds that a company’s customers have promised to pay in 30, 60, or 90 days. From a lender perspective, this type of loan is not quite as safe as collateralized loans against something such as a house, but it’s more secure than an unsecured personal loan, because it relies on an existing contractual obligation to pay that a customer has agreed to. And because understanding how likely the customer is to pay the invoice requires an understanding of a specific industry and its contracts, accounts receivable factoring companies oftentimes specialize in specific industries. Examples include BlueVine, Fundbox, Affirm, and Pipe.

This post describes how to build the payment operations required for an invoice factoring company. It does not touch on credit criteria or the underwriting model required for a specific industry. Both will change over time and be specific to each company. But the payment operations are similar between these companies, and this post will outline what they might look like in a few API calls.

But first, let’s outline the user experience our new invoice factoring company, Invoice.ly, might want to build.

The User Experience

For simplicity, let’s assume Invoice.ly offers 90% advance rate on any invoice that is to be paid in 90 days. That means that when a business owner Billy sells $1000 worth of goods and issues an invoice, Invoice.ly will send $900 to Billy. Then, 90 days later, when the buyer pays the full invoice, Invoice.ly will receive the full $1000. Note that this is a fairly simple case; oftentimes there’s a payment plan associated with an invoice, and in such cases there might be a repayment plan that mirrors those timings on the invoice factoring arrangement as well.

For the simple case, the steps we need to build out are:

1. A user, Billy, comes to the Invoice.ly website and is approved for all future invoices.
2. Billy uploads an invoice that was issued recently.
3. Invoice.ly sends funds equal to 90% of the invoice to Billy’s bank account.
4. 90 days later, when Billy receives the full payment from the buyer, Invoice.ly debits Billy’s bank account for the full amount, getting paid in the process.

With this experience in mind, let’s plan out the payment operations for Invoice.ly.

Payment Ops Architecture

Invoice.ly needs a bank account to fund the invoices and receive payments. But oftentimes companies choose to separate these functions into two separate accounts, for simplicity of accounting and payment ops. So suppose Invoice.ly sets up two accounts with its bank: a Funding account and a Repayment account.

When Invoice.ly approves an invoice, it sends funds from the Funding account. When the invoice is paid, it retrieves those funds into the Repayment account. Depending on the rules it agreed on with its own investors, maybe Invoice.ly “recycles” those funds a set amount of times before returning them to investors, or maybe it cycles indefinitely.

API Calls and Timings

When Billy signs up for the service, Invoice.ly creates a Counterparty in Modern Treasury and gathers bank account details. This can be done using Plaid or by having the user fill out a form (see more here on different ways to authenticate accounts).

Step 1: Collect bank account details

In addition to the account and routing number, you might want to hold additional information about the counterparty held in metadata. This information might include a unique customer ID, the way in which they signed up, and other information.

Step 2: Credit out the invoice advance

A counterparty creation response will notify you that everything has been successfully set up. Now that a counterparty exists, you can fund the invoice advance. Let’s say Billy is getting an advance of $900 against an invoice of $1000. Given the amount, you might choose to send that amount via ACH. Note that the amount is in cents, not dollars, so it shows up as 90000:

Once the payment goes through, the Funding account will be debited $900 but Billy will be able to use the $900 for working capital to cover inventory costs, use it for payroll, or invest in the business in another way. That’s it for the cash advance.

Again, you may want to add metadata to the payment for future reference. In addition to metadata (eg. key-value pairs such as Invoice_ID - abc123 or DaysAdvance - 90) you might also choose to hold line items for future reference to distinguish between different invoices, fees, etc. This will be useful for customer service and finance teams that might have to answer questions about this payment in the future.

Step 3: Collect repayment

Now, based on the terms of the invoice, Invoice.ly is entitled to be repaid in 90 days. Let’s suppose Billy has set up automatic debits and does not need to be involved in the process. That means that you have to initiate an ACH debit from Billy’s account for $1,000 at a future date 90 days later. Note that instead of using the Funding account, Invoice.ly is now using the Repayment account:

This flow can now be repeated for every invoice, or every time someone is approved for an invoice advance. The specifics of duration, advance rate, etc. can all be variable, but the payment ops architecture will work for a business providing invoice factoring services of any size or duration.

Those are the fundamentals of running payment ops for any invoice factoring business.

What can go wrong?

Of course, what was described above is the happy path. Issues with borrowers or with the payments themselves are the reason invoice factoring companies have large teams dedicated to customer service, payment ops, and servicing.

A common issue could be that Billy has insufficient funds in their bank account to pay the monthly loan payment. In that case, the ACH debit will fail and Invoice.ly will get a notification with a return code for R01—“insufficient funds”—which is one of many possible reasons for an ACH failure. In that case, a member of the customer service team might reach out to inquire about the situation and, if Billy approves it, might redraft the ACH debit once the funds are in the account.

Billy might change banks one day. When that happens, the Invoice.ly payment ops team might have to create a new bank account under the counterparty in the system for Billy and maybe deactivate the old one. That would require all future monthly payments to come from the new account.

Note that we assumed in this post that everything would happen over ACH. In some cases, if speed is of the essence, invoice factoring companies might prefer to use Real Time Payments (RTP). If that were the case, your "type" on the funding call might be "rtp" instead of "ach".

Looking for more?

This is just the basic architecture someone would use to create a new invoice factoring company, but it offers a strong foundation from which to build.

To make all your payment operations simple, scalable, and secure, request a demo of Modern Treasury.