Supply Chain Finance Software: Why Supplier Onboarding, Not Funding, Is What Kills the Programme

Why supply chain finance programmes stall, and it is never the funding

Ask anyone who has launched a payables finance programme what went wrong and you will not hear a story about capital. Funding is the easy part. Banks want approved payables from an investment grade buyer, because the credit risk is the buyer's and the tenor is short.

What goes wrong is onboarding. The programme launches with a target of 400 suppliers. Twelve months later, 60 are live and they are the large ones who least needed the liquidity. The tail, meaning the several hundred smaller suppliers where the programme would actually do some good, never got through the process. They were asked for corporate documents in a language they do not operate in, an identity verification flow built for a different jurisdiction, a receivables assignment agreement their lawyer wanted to redline, and a bank account verification that failed because the account name did not exactly match the registered entity name.

Meanwhile the buyer's treasury team is running a spreadsheet reconciliation every month between what the ERP says was paid, what the funder says was funded, and what the supplier believes it received. And the finance director is being asked by the auditors to describe the programme in the notes to the accounts, because supplier finance programme disclosure is now a requirement, and nobody can produce the outstanding balance by programme cleanly.

Across working capital and payments projects we have delivered, the pattern is the same wherever the programme sits: the economics are decided by onboarding conversion and data quality, and both of those are software problems rather than banking ones.

Problem 1: approved payable data is worse than the buyer thinks

The entire product rests on one fact: the buyer has irrevocably approved an invoice for payment on a date. Everything else, the discount, the funder's risk, the accounting, follows from that. Which means the extract from the buyer's ERP has to be exact, complete and stable, and it usually is none of the three at first.

The problems are mundane and fatal. Invoices approved then reversed by a credit note two days later. Partial approvals where a line is disputed. Payment terms held in a vendor master that disagrees with the terms on the invoice. Duplicate vendor records for the same legal entity, so a supplier appears three times with three payment histories. Payment runs that net multiple invoices and offsets into one remittance, which makes reconciliation at invoice level impossible unless the remittance detail comes through.

A build has to treat the ERP feed as a first class subsystem, not a nightly file. Approved payables arrive with the approval event and its timestamp, changes after approval flow through as events rather than silently altering a record, credit notes and offsets are linked to the invoices they affect, and the vendor master is deduplicated against a resolved supplier entity. Then the offer presented to a supplier is one the buyer will actually honour, which is the only thing standing between your programme and a funder dispute. When the ERP is SAP, Oracle or Coupa, the integration path is known but the data quality work is still yours to do.

Problem 2: onboarding is identity, legal agreement and a bank account, in three jurisdictions

A supplier joining the programme has to be identified to the funder's satisfaction, sign an agreement assigning its receivables, and prove control of a bank account. Any one of those can take a month if the flow is designed badly.

Identity is the hardest because the requirements come from the funder's obligations, not from your preference, and they differ by country and entity type. A sole trader in one market, a private limited company in another and a state owned entity in a third are three different evidence packages. Beneficial ownership has to be established, which for a family owned manufacturer with a holding structure is a genuine research exercise. Screening runs against sanctions lists and the result has to be recorded.

What a build should include: a jurisdiction aware onboarding flow where the document set requested is derived from country and entity type rather than being a single global checklist, extraction from uploaded registry documents to prefill rather than making a supplier type its own registration number, an ownership structure capture that handles layers, and a case queue for the ones that need a human. The assignment agreement should be generated with the supplier's own details, executed electronically where the jurisdiction allows it, and stored with an audit trail that a funder's counsel can rely on. Bank account verification needs a mechanism appropriate to the market rather than assuming one method works everywhere.

Measure conversion at every step. The programmes that succeed are the ones that treat onboarding as a funnel to be optimised, not a compliance hurdle to be endured.

Problem 3: multi funder allocation is a limits engine, not a spreadsheet

Programmes of any size involve several funders, each with a limit on the buyer, sometimes a limit by country, a target tenor, an appetite that changes quarterly, and a pricing grid. When a supplier accepts an early payment offer, the receivable has to be allocated to a funder with room, at the right price, and the allocation has to be recorded because it determines who gets repaid at maturity.

Run manually, this becomes a treasury analyst with a spreadsheet allocating by hand and a monthly reconciliation to prove it was done right. It also caps the programme, because nobody can allocate 4,000 invoices a day by hand.

What a build must include: funder limits with utilisation updated in real time, allocation rules that respect appetite and pricing, a fallback when the preferred funder is full, and an immutable allocation record per receivable. Settlement instructions generate from the allocation, and repayment at maturity reconciles against it automatically. Uncommitted facilities need explicit handling, because a funder withdrawing appetite mid programme is a scenario your system should degrade through gracefully rather than fail on. If the buyer also funds some invoices with its own cash, meaning dynamic discounting alongside third party funding, the engine has to treat that as another source with its own rules rather than as a separate product bolted on.

Problem 4: accounting treatment and disclosure are the treasurer's real risk

The commercial pitch for payables finance is that the buyer extends terms while suppliers get paid earlier. The risk that ends careers is that the arrangement is judged to have changed the character of the obligation, so what the buyer reports as trade payables looks more like borrowing. Rating agencies and auditors have paid close attention to this since a well publicised programme collapse a few years ago, and accounting standard setters responded: supplier finance programme disclosure requirements now oblige buyers to describe the programme terms and report outstanding amounts, with a rollforward.

That disclosure is a data problem. You need, per programme and per period, the amount outstanding that suppliers have received early, the amount the buyer still owes to funders, invoices added and settled during the period, and the payment terms before and after the programme. If your programme runs across three funders and two ERPs, producing that cleanly by hand is a week of work every quarter and it will not tie.

A build should produce it as a report from the same event data that runs the programme, with drill through to the individual invoices. It should also preserve the evidence that supports the treatment: that the payment date did not change, that the supplier's participation was voluntary, that the buyer did not provide credit support. Those facts live in the platform's records, and having them retrievable is what turns an audit question into a five minute answer.

Problem 5: the supplier who will never log in

Programme design almost always assumes a supplier who visits a portal, reviews offers, and accepts the ones that suit their cash position. Some do. A large share of the tail will log in once, then never again, and their liquidity need is real but their appetite for another portal is zero.

The fix is to meet them where they are. Standing instructions so a supplier can elect to take early payment on everything, or everything above a threshold, without logging in. Offers delivered by email with an accept link, and in some markets by messaging, because that is what the supplier's finance person actually reads. Statements that reconcile to their own accounting so their bookkeeper is not calculating the discount by hand. Local language throughout, not just at signup.

Deep tier programmes take this further and are where the interesting growth is: financing the supplier's suppliers, using the anchor buyer's credit two or three tiers down. That is materially harder because you are financing receivables the anchor buyer never approved, so the data has to come from purchase orders and delivery evidence rather than approved payables. Do not attempt it in phase one. Design the entity and receivable model so it is possible later.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this shape prices as follows. A focused first release covering ERP ingestion of approved payables with change events, supplier onboarding with jurisdiction aware identity and bank verification, offer and discount calculation, acceptance and settlement instruction generation runs $120,000 to $260,000 and ships in 16 to 24 weeks. A full platform adding multi funder allocation with limits and pricing grids, assignment agreements with electronic execution, dynamic discounting from buyer cash, deep tier structures, disclosure and accounting reporting, screening and full reconciliation runs $350,000 to $900,000 phased over 10 to 18 months.

What drives cost up in this category specifically: the number of countries, because identity requirements, bank verification methods, assignment enforceability and language all vary. The number of buyer ERPs, since a programme spanning several instances of SAP plus one legacy system is several integrations, not one. Funder count and the sophistication of their allocation rules. Payment rails, because paying suppliers in eight currencies through different local methods is its own project. And regulatory posture, if you are the funder rather than the buyer, since licensing and reporting obligations shape the architecture.

What keeps cost down: one buyer, one ERP, one funder and two countries for the first release. Onboarding conversion in those two countries teaches you more than a broad launch that stalls everywhere at once.

Build versus buy, and when buying is clearly right

If you are a corporate buyer wanting a programme for your own suppliers, buy. Taulia, PrimeRevenue, C2FO, Demica and Kyriba have solved the funder relationships, the onboarding operations and the ERP connectors, and building your own would be a treasury department funding a software company. That is the honest answer and it applies to most companies who search for this.

Build when two or more of these are true. You are the funder, a bank or a fintech, and the platform is your product rather than a tool you use. You are running deep tier or purchase order based financing that approved payable platforms do not model. Your supplier base sits in markets where the incumbent onboarding flows do not work, which is common across parts of Asia, Africa and Latin America and is the single most frequent reason a large buyer's programme underperforms. You need the programme embedded inside your own procurement or marketplace product rather than sitting beside it. Or your economics depend on onboarding conversion in the tail, and no platform will let you redesign the flow that is losing you suppliers.

The tipping point is who owns the economics. If a vendor's take rate is a cost line for you, buy. If the spread is your revenue, the platform is your business and you should own it.

How to choose a developer

Ask how they model an approved payable that is later reduced by a credit note after a supplier has taken early payment. If they do not immediately describe event sourcing and a dispute path back to the funder, they have not built one of these and you will discover the gap in production with real money involved.

Ask how the onboarding flow differs between a private company in Germany, a sole proprietor in India and a company in Brazil. The answer should be about jurisdiction driven document sets and verification methods. A single global checklist means your tail suppliers will not onboard.

Ask what they have integrated with by name. SAP, Oracle and Coupa each expose approved payable data differently, and remittance detail is often the harder half. Vague claims about ERP connectivity hide the weeks where the programme lives or dies.

Ask how funder allocation and limits are enforced, and what happens when the preferred funder is full at 2am during a payment run. You want to hear rules, fallbacks and an immutable allocation record, not a nightly batch someone checks.

Ask who owns the code and settle it before kickoff. You should hold the repository, the infrastructure accounts and the right to hire another firm. At Digital Heroes the client owns the code from the first commit, which matters most here because a financing platform accumulates regulatory and funder specific logic that you cannot afford to have locked inside someone else's account.