When Getting Paid Is Only Half the Job: Programmable Settlement in B2B Wholesale

When getting paid is only half the job

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.

Welcome to the less visible side of B2B wholesale—and to a practical use case for programmable settlement.

In our previous discussion, we described programmable settlement in everyday terms: a business defines who should be paid, how much they should receive, and what needs to happen before settlement is released. It also needs a reliable record of the decisions and transactions so the team can reconcile what happened later.

Let's make that concrete.

Meet Billy and Sons Construction Ltd

It's a sunny Tuesday in the north of England, and Billy and Sons Construction Ltd has just taken ten customer orders. This is an illustrative scenario, not a real customer case.

Each customer has specified the materials required, the quantities, the delivery address and whether they want the wholesaler to arrange delivery or collect the goods themselves. A deposit has been paid—let's assume 25% of the order value for this example.

Happy days, you might think. Another ten orders in the bag.

But the finance team now has work to do.

Some customers have included their invoice numbers in their bank transfer references. Others haven't. A few have entered a customer name or a vague description that doesn't immediately tell the team which order the payment belongs to.

So 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 team may need to look for other supporting information or ask a colleague to confirm the transaction. If the payment still cannot be matched confidently, it needs investigation.

Only then can the team confidently update the order and move on.

This is not necessarily difficult work. It is repetitive work. And when the business processes orders every day, repetitive work has a habit of consuming a surprising amount of time.

The delivery is complete. Now the real work begins.

Fast-forward a few days. The goods have been delivered. The customer confirms the order is complete and pays the outstanding balance.

From the customer's point of view, the transaction is finished. For Billy and Sons, that incoming payment starts another sequence of tasks.

The wholesaler may need to pay the original supplier or manufacturer, settle the delivery partner's fee, account for applicable tax obligations and retain the amount due to the business. The exact amounts and timing depend on the commercial agreements, the order and the relevant tax treatment. For this example, assume finance has already defined the appropriate allocation rules.

Someone now needs to work out which obligations apply to this order, calculate the amounts, check whether the necessary conditions have been met, arrange the payments and record what has happened.

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

And when something doesn't match, someone has to work out why.

What if the rules did the repetitive work?

Imagine Billy and Sons could define its settlement rules in advance.

• When a customer payment arrives, the workflow attempts to match it to the correct order using the payment reference and other available information.
• If the payment can be matched confidently, it is associated with that order and the result is recorded.
• If the reference is missing or the information is ambiguous, the payment is sent for review rather than matched by guesswork.
• When delivery has been confirmed and the other required checks have passed, the configured rules determine the amounts due to the relevant beneficiaries.
• The workflow triggers the appropriate settlement instructions and retains records of what was received, which conditions were checked and what happened next.

The finance team still defines the rules, manages exceptions and oversees the process. The difference is that staff do not have to repeat every calculation and instruction for every straightforward transaction.

That is the practical idea behind programmable settlement: the business defines the rules, the system applies them consistently, and the team retains visibility over what happened and what still needs attention.

What happens behind the scenes?

Pepparest is Peppa's conditional payment orchestration engine. In plain English, it helps a business coordinate what should happen to collected money when several parties, payment rules or release conditions are involved.

Step	Who defines or supplies it	System action
Payment received	Payment provider and transaction data	Makes the payment information available to the configured workflow
Order matching	Business rules and available transaction information	Associates the payment with an order when the evidence supports a confident match; otherwise flags it for review
Conditions and allocations	The business and relevant partners	Applies configured beneficiaries, amounts or percentages and checks required conditions
Settlement instruction	Configured workflow and payment partners	Triggers the appropriate instruction when the required conditions have been satisfied
Reconciliation and records	Transaction events and partner responses	Helps the business review what was received, instructed, settled or left outstanding

The precise implementation depends on the business's payment providers, partner arrangements and configured workflow. Pepparest coordinates the settlement logic; it does not replace banks, payment providers or licensed institutions responsible for regulated financial activity. It also does not determine a business's tax obligations or legal entitlement to funds.

The product question: why build all of this yourself?

For a Head of Product or CTO, settlement logic can look like another feature to add to the roadmap. After all, the business already has developers. How difficult can it be to split a payment between a supplier, a delivery partner and the platform?

The first version might not be particularly difficult. The challenge is everything that comes after it.

What happens when a payment arrives without an order reference? What if a supplier's details change? What if a delivery is partial, a payment fails, an order is cancelled or a refund is required? How do you avoid processing the same instruction twice? How do you keep records consistent when a partner's system is temporarily unavailable?

Each question creates more logic to design, test, monitor and maintain. Finance needs reliable answers. Customers need the transaction to work. And engineering needs to keep the whole system working as the business introduces new partners, products and commercial arrangements.

That is a meaningful amount of engineering capacity to commit to infrastructure that may not differentiate the product in the customer's eyes.

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

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.

Putting a number against the manual work

Let's 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?

Practical takeaways

If your business coordinates payments between buyers, suppliers, delivery partners and other beneficiaries, start with one real transaction and map it from the moment money arrives to the moment every obligation has been settled.

• Identify each manual check, calculation, hand-off and exception.
• Measure the time spent matching payments, preparing payouts and reconciling outcomes.
• Document which conditions must be met before each settlement instruction can be triggered.
• Decide which exceptions require human review and what evidence the team needs to resolve them.
• Compare the cost of maintaining this infrastructure in-house with the work needed to configure and integrate a suitable orchestration platform.

The goal is not to remove finance from the process or automate every exception regardless of the circumstances. It is to give the team a more reliable way to manage routine work, so people can focus on genuine exceptions, controls and the commercial health of the business.

Pepparest provides an orchestration layer for businesses that need this kind of control over multi-party settlement. Rather than 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.

The starting point is simple: map one real transaction. That is where the manual work, the exceptions and the opportunity for better control become visible.

Learn more about Pepparest or explore our Architecture.