Build or Buy? The Real Cost of Settlement Logic for UK and European B2B Platforms

The first version of a payment split is rarely difficult.

A customer pays. The platform takes its commission, pays the supplier and releases the balance. A competent engineering team can build that flow, and many do.

The difficulty is everything that comes after it.

What happens when a payment arrives without an order reference? When a delivery is partial? When a supplier's bank details change, an order is cancelled, a refund is required, or the same settlement instruction is at risk of being processed twice? How are records kept consistent when a payment partner's system is temporarily unavailable?

Each question creates more logic to design, test, monitor and maintain. For UK and European B2B platforms, wholesalers and trade businesses with complex downstream payment obligations, that logic — not the first split — is what the build-or-buy decision should actually be about.

The question is not simply, “Can we build it?” It is, “Is building and maintaining all of this the best use of our engineering time?”

The settlement work hiding inside a B2B transaction

Consider a construction wholesaler in the north of England taking ten customer orders on a typical Tuesday. This is an illustrative scenario, not a real customer case.

A customer pays for a bulk order of building materials. The wholesaler confirms delivery, receives the balance and considers the transaction complete.

Except it isn't.

The supplier still needs to be paid. The delivery partner is waiting for its fee. Finance needs to account for applicable tax obligations. And the wholesaler needs to make sure every amount is allocated correctly.

Before any of that, the finance team has work to do. Some customers include their invoice numbers in their bank transfer references. Others haven't. A few enter a customer name or a vague description that doesn't immediately show which order the payment belongs to. Someone opens the bank feed, compares incoming payments with outstanding invoices, checks amounts and dates, and works out which payment belongs to which order. Where the reference is missing, the payment may need investigation rather than a confident match.

Multiply that process across ten orders a day, then across a week or a month, and the workload becomes visible. The finance team is not just recording money that has moved. It is coordinating connected obligations using information spread across bank feeds, invoices, order management tools, emails and spreadsheets.

This is not necessarily difficult work. It is repetitive work. And repetitive work, repeated daily, has a habit of consuming a surprising amount of time.

Putting a number against the manual work

Return to those ten daily orders. Suppose, purely for illustration, that the business spends an average of four minutes matching each incoming payment to an order. If every order generates a deposit and a balance payment, that is twenty incoming payments a day.

At four minutes per payment, matching takes 80 minutes. Now suppose the team spends another six minutes per completed order calculating allocations and preparing settlement instructions. Across ten orders, that adds 60 minutes.

That is 140 minutes a day — around two hours and twenty minutes — spent on these two activities alone. Across five working days, it is about 11 hours and 40 minutes.

These are illustrative assumptions, not measured results or an industry benchmark. The calculation excludes exception handling, broader reconciliation, failed payments, refunds, reporting and the engineering work required to maintain a custom settlement system. The actual opportunity depends on transaction volume, process complexity, exception rates and the level of automation already in place.

But even this simple exercise gives a Finance Director or Head of Product a useful starting point: how much time does the current process consume, and what could the business do with that time if routine settlement work were handled more consistently?

What breaks after version one

Settlement logic looks like another feature to add to the roadmap. After all, the business already has developers. The challenge is the long tail of behaviour that only appears in production, at volume, with real counterparties.

• Unmatched value. A payment arrives with a missing or ambiguous reference. Matching by guesswork creates reconciliation errors downstream; the payment should be routed for review.
• Partial and changed outcomes. A delivery is partial, an order is amended, or a payment fails. Fixed, percentage-based and remaining-balance allocations must respond without manual recalculation of every obligation.
• Duplicate instructions. A retried request or a partner timeout can trigger the same settlement twice unless the system is idempotent by design.
• Refunds and cancellations. Money that has been allocated may need to be returned or redistributed, in the right order, with the original decisions still auditable.
• Partner change. A supplier's details change, a new payment provider is added, or a commercial agreement is renegotiated. Hardcoded rules turn each change into an engineering project.
• Reconciliation and records. Finance needs to review what was received, which conditions were checked, what was instructed, what settled and what remains outstanding — across systems that do not naturally agree.

Each of these is manageable in isolation. Together, they are a permanent product surface: states, retries, fallbacks, exception queues, observability and audit records that must be maintained for as long as the business settles money.

The build-or-buy comparison that matters

The honest comparison is not licence cost against developer salaries for the first release. It is the total cost of owning settlement behaviour over several years, against the cost of configuring and integrating an orchestration layer.

Consideration	Build in-house	Orchestrate with a platform
Time to first release	Quarters of design, build and testing before the first live settlement	Configuration and integration against an existing engine
Exception handling	Designed and built case by case, often after incidents	Configured states, fallbacks and review routes as part of the model
Reconciliation and audit	Records assembled from logs, bank feeds and spreadsheets	Settlement decisions and events recorded as part of the workflow
Partner and rule changes	Engineering change for each new partner, rail or commercial term	New rules and beneficiaries configured within the existing model
Maintenance burden	Permanent: monitoring, retries, testing, on-call ownership	Shared with the platform; internal effort focuses on exceptions and controls
Differentiation	High only if settlement itself is the product's edge	Frees engineering for the customer-facing product

For some businesses, a custom-built solution may be justified by genuinely unique requirements. But where the core need is to collect value, apply configurable settlement rules, coordinate multiple beneficiaries and maintain dependable records, it is worth evaluating whether that infrastructure should be bought rather than built from scratch.

The commercial framing matters too. Pepparest's positioning in this market is built around avoiding six-plus months and more than $80,000 of bespoke ledger build before a platform settles its first transaction at scale. That is capacity not spent on the product customers actually see.

The UK and European context: programmability is becoming infrastructure

This is not only an internal efficiency question. The direction of UK and European payments infrastructure is towards programmability.

The Bank of England's June 2026 consultation on the future design of UK retail payments infrastructure identifies programmability as an important capability, highlighting patterns such as conditional hold and release, enriched payment messaging and the need for clear failure and timeout handling.

At the account level, banks are already packaging infrastructure as commercial services. HSBC positions virtual accounts around receivables reconciliation, centralised payment processes and treasury visibility. ING's virtual cash management services support cash concentration, automated allocation and multi-entity oversight. Bank of London describes virtual account hierarchies, API access and on-demand account creation for corporate cash management.

These services principally address the organisation and visibility of funds. The settlement workflow — who is paid, how much, and under what conditions — remains the layer businesses are most often left to build or perform manually.

For platforms selling into UK and European B2B trade, construction, distribution and marketplaces, that gap is the product opportunity: settlement behaviour that responds intelligently to commercial conditions, delivered on top of existing, regulated payment infrastructure rather than instead of it.

The infrastructure question: coordinate the rules, keep execution with licensed partners

A scalable approach is to introduce a reusable orchestration layer between the business's commercial rules and its existing payment infrastructure.

This layer needs to coordinate:

• Incoming value and transaction references.
• Configurable settlement rules, allocations and permissions.
• Authorised business events, such as delivery confirmation or milestone approval.
• Payment instructions and beneficiary allocations.
• Exceptions, failed instructions, retries and duplicate protection.
• Audit records and reconciliation outputs.

The separation of responsibilities is deliberate and important. Payment processors and banking rails continue to handle payment acceptance, connected accounts, KYC and onboarding, custody and payouts. The orchestration layer coordinates the configured business logic and settlement instructions within that operating model.

That separation allows product teams to change settlement behaviour — a new beneficiary structure, a new release condition, a new market — by configuration rather than by rebuilding the money movement underneath it.

Where Pepparest fits

Pepparest is Peppa's conditional payment orchestration engine.

It is designed to decide who gets paid, how much, when, and which conditions must be satisfied first: conditional rules, multi-party allocation, milestone-based release, configurable settlement states, fallback scenarios, payment routing, reconciliation and audit-ready records.

For UK and European platforms and wholesalers, the opportunity is to use this infrastructure instead of starting with every rule, state and exception-handling component from scratch. A business can evaluate how much of that capability it can configure and integrate through Pepparest, while its existing processors and banking partners continue to execute payments.

Peppa operates as enterprise software middleware. Regulated accounts, fiat custody, foreign exchange and compliance validations remain within the perimeter of licensed partner institutions, according to the deployment and applicable arrangements. Initial implementations can run without Pepparest taking custody of funds.

The objective is straightforward: give product and finance teams a reusable foundation for settlement, so engineering capacity goes to the product customers see — not to rebuilding settlement infrastructure that does not differentiate it.

Explore the Pepparest conditional payment orchestration engine and Peppa's enterprise architecture.

The strategic question for product and finance leaders

Getting paid is a solved problem. Coordinating what happens to the money afterwards, reliably and at volume, usually is not.

For CTOs, CPOs and Finance Directors in UK and European B2B businesses, start with three questions:

1. Where does your team still rely on manual work to match, allocate, approve or release funds?
2. What has your settlement logic actually cost to build and maintain so far — including exceptions, reconciliation and on-call ownership, not just the first release?
3. Which parts of that behaviour genuinely differentiate your product, and which parts are infrastructure you are maintaining out of necessity?

The businesses that answer these questions honestly tend to find the same thing: the settlement layer is expensive precisely because it is invisible when it works.

The opportunity is not to move money faster. It is to stop spending scarce engineering and finance time coordinating what happens to it.

Sources and further reading

• Peppa: When Getting Paid Is Only Half the Job — Programmable Settlement in B2B Wholesale
• Peppa: Beyond Virtual Accounts — How Banks Can Monetise Programmable Settlement Services
• Bank of England: Consultation on the design of the future retail payments infrastructure (June 2026)
• HSBC: Virtual Accounts
• ING: Virtual Cash Management
• Bank of London: Virtual Account