Supply Chain Finance Platform Problems: The 7 That Stall a Programme, and How to Avoid Them

Why does the build start with funding logic instead of onboarding?

Every payables finance platform we have seen scoped begins in the same place: the offer engine, the discount calculation, the funder allocation. That is the part that feels like the product, and it is the part that is least likely to determine whether the programme works.

Funding is the easy end. Banks want approved payables from a strong buyer because the credit risk is the buyer's and the tenor is short. What is scarce is suppliers who have completed identity verification, signed a receivables assignment agreement and proved control of a bank account. Build a beautiful allocation engine and a portal, launch, and you will spend the next year discovering that your conversion funnel leaks at the third step in one country and the fifth in another.

What makes this specific to supply chain finance is that onboarding requirements are not yours. They come from the funder's obligations and they differ by country and entity type, so 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 for a family owned manufacturer with a holding structure is a genuine research exercise, not a form field.

The fix is to treat onboarding as a conversion funnel with measurement at every step, built first and refined against real suppliers in two countries before any broad launch. Derive the document set from country and entity type rather than issuing one global checklist, extract from uploaded registry documents to prefill rather than asking a supplier to type its own registration number, and route the difficult cases to a human queue instead of failing them. Programmes that succeed optimise this. Programmes that stall treated it as a compliance hurdle to be endured.

What goes wrong with the buyer's approved payable data?

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

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

The fix is to treat the buyer feed as a first class subsystem rather than a nightly file. Approved payables arrive with the approval event and its timestamp. Changes after approval flow through as linked events rather than silently altering a record, so a credit note arriving after a supplier has taken early payment is visible as a reduction against a funded amount and can be routed down a defined dispute path back to the funder. The vendor master is deduplicated against a resolved supplier entity before anything is offered.

Expect remediation on the buyer side and put it in the plan. In our delivery experience the calendar risk on these programmes is rarely engineering, it is data quality work that gets discovered rather than specified.

Why do the ERP (Enterprise Resource Planning) and payment rail connections break after launch?

The buyer ERP integration is the first fragile point, and it is fragile for organisational reasons. SAP, Oracle and Coupa each expose approved payable data differently, and remittance detail is often the harder half. Beyond the interface, the buyer's own accounts payable team changes approval workflows, adds a company code, migrates an instance or acquires a business with its own system, and none of those changes are communicated to a financing platform sitting downstream. The programme keeps running against a feed that has quietly stopped including a set of invoices.

Payment rails are the second. Paying suppliers in several currencies through different local methods is its own project, and each rail has its own failure behaviour: a rejected payment for a name mismatch, a cut off time that shifts around a local holiday, a correspondent bank returning funds days later. If your reconciliation assumes payments either succeed or fail immediately, you will carry unreconciled positions.

The third is screening. Sanctions list checks are not a one time gate at onboarding, they run against a list that changes, and a supplier who cleared in March may not clear in September. If rescreening is not automated with a defined case handling process, someone is doing it manually and eventually stops.

The fix is monitoring with commercial teeth. Every feed needs an expected cadence and an alert when it deviates, a named owner at the buyer and at the funder, and a contractual obligation to notify you of ERP changes. Reconcile daily rather than monthly, because a break found the next morning is a question and a break found at quarter end is an investigation.

What happens when disclosure, screening and reconciliation are not covered?

These three get deferred out of first releases and they are the ones that create real exposure for the buyer's finance director.

Disclosure is the sharpest. Supplier finance programme disclosure requirements oblige a buyer to describe the programme terms and report the amounts outstanding, with a rollforward of invoices added and settled during the period. That is a data problem before it is an accounting one. You need, per programme and per period, what suppliers received early, what the buyer still owes funders, and the payment terms before and after the programme, with drill through to individual invoices. If the platform cannot produce it, somebody assembles it by hand across several funders and it will not tie.

Alongside it sits the evidence supporting the accounting treatment: that the payment date did not change, that supplier participation was voluntary, that the buyer provided no credit support. Those facts exist in the platform's records and retrieving them turns an audit question into a short answer rather than a week of work.

Reconciliation is the quiet one. Every receivable needs an immutable allocation record showing which funder took it at what price, because that determines who is repaid at maturity. Programmes that allocate in a spreadsheet cap themselves, since nobody allocates thousands of invoices a day by hand, and they cannot prove the allocation afterwards. Build the limits engine with utilisation updated in real time, an explicit fallback when the preferred funder is full, and graceful handling of a funder withdrawing appetite, since most facilities are uncommitted.

Should you build custom or buy what already exists?

If you are a corporate buyer wanting a programme for your own suppliers, buy, and we will say that before quoting anything. Taulia, PrimeRevenue, C2FO, Demica and Kyriba have already solved the funder relationships, the onboarding operations and the ERP connectors. Building your own means a treasury department funding a software company, and that is the honest answer for most organisations that search this category.

Before committing either way, examine whether your real problem is the platform or the programme design. Low participation is frequently caused by a discount rate the tail cannot justify, an assignment agreement your legal team wrote defensively, or a supplier communication that reads like a compliance notice. All three are fixable without software.

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 incumbent onboarding flows do not work. You need the programme embedded inside your own procurement or marketplace product. Or your economics depend on conversion in the tail and no platform will let you redesign the flow losing you suppliers. The tipping point is who owns the economics: if a vendor's take rate is a cost line, buy. If the spread is your revenue, the platform is your business.

How do hidden costs get into the quote?

The number of countries is the largest and it compounds rather than adds, because identity requirements, bank verification methods, assignment enforceability and language all vary. A quote that prices multi country as a translation exercise has missed the point. Ask for a price per market and launch in two.

The number of buyer ERPs is second. A programme spanning several instances of one system plus a legacy application is several integrations, not one, and remittance detail is usually the harder half of each. The third is payment rails, priced per currency and per local method rather than as a single payments line.

The fourth is the data remediation on the buyer side, which is real work that somebody pays for and which is frequently written into proposals as an assumption that the buyer will provide clean data. They will not, and nobody is being dishonest, they simply do not know their vendor master has duplicates until you resolve entities. The fifth, if you are the funder rather than the buyer, is regulatory posture, since licensing and reporting obligations shape the architecture rather than sitting on top of it.

What separates a build that works from one that fails here?

Ask a prospective developer how they model an approved payable that is later reduced by a credit note after a supplier has already taken early payment. If they do not immediately describe events rather than edits, and a defined dispute path back to the funder, they have not built one of these and you will find the gap in production with real money moving.

Ask how the onboarding flow differs between a private company in one jurisdiction, a sole proprietor in another and a company in a third. The answer should be about jurisdiction driven document sets and verification methods, with conversion measured at every step. A single global checklist means the tail will not onboard, which means the programme underperforms regardless of how good the funding side is.

Ask what happens when the preferred funder is full during a payment run in the middle of the night. You want rules, a fallback and an immutable allocation record, not a batch someone checks in the morning. Ask what they have integrated by name rather than a general claim about connectivity.

Then design for the supplier who will never log in again, because a large share of the tail logs in once. Standing instructions to take early payment on everything above a threshold, offers delivered by email with an accept link and in some markets by messaging, statements that reconcile to the supplier's own books so nobody recalculates a discount by hand, and local language throughout rather than only at signup. Finally, settle ownership before kickoff. You should hold the repository, the infrastructure accounts and the right to hire another firm, which matters most here because a financing platform accumulates regulatory and funder specific logic you cannot afford to have locked inside somebody else's account. At Digital Heroes the client owns the code from the first commit.