The Ledger at the Edge: A Procurement Audit of Finance Features in UK Vertical SaaS

Vertical software has quietly acquired a second function. Platforms built for scheduling engineers, managing client records or taking bookings now offer card payments, direct debits and payout facilities inside the same administrative console. The feature is often presented as an operational convenience: one fewer integration, one fewer login, one fewer supplier to manage. For a UK buyer, that framing is incomplete. Once money moves through a business system, the procurement question is no longer only about software functionality. It is about the ledger, the regulatory perimeter and the exit route.

A finance function hidden in an admin menu

Embedded payments rarely arrive through a formal tender. They emerge during implementation, when a platform account manager explains that the service can collect deposits, settle invoices or take payment at the point of booking. The switch is flipped, the first transactions clear, and the finance team discovers a new settlement stream appearing in its bank account. By then, the commercial and contractual groundwork may already be behind the business.

Procurement should treat this as a financial service acquisition, even when the contract is packaged as a software subscription. The relevant questions are not whether the payment screen looks polished, but who carries the obligations when a transaction fails, a refund is disputed or a supplier changes hands. Those questions belong in the same due diligence file as hosting, data protection and service continuity.

Establish the merchant of record before anything else

The first audit step is to identify the merchant of record. In some arrangements, the vertical SaaS provider contracts directly with the cardholder and bears the settlement risk. In others, a regulated payment service provider sits behind the platform, with the software vendor acting as a technical integrator. A third model involves the platform operating as a payment facilitator or sub-merchant, with responsibilities distributed across several contracts.

The distinction matters because it determines who is accountable for authorisation, settlement, chargebacks and customer communications. It also affects credit exposure. If the platform holds funds before payout, the buyer should understand the safeguarding arrangements and the time between capture and settlement. If a payment provider holds the funds, the buyer should know what happens if that provider is replaced or fails. The answer should be evidenced in the contract, not inferred from a help-centre article.

Map the fee stack and the foreign-exchange margin

Embedded payment pricing is rarely a single rate. Scheme fees, acquiring fees, gateway charges, platform commissions, chargeback levies, refund processing and payout fees can sit at different layers. Foreign-exchange charges are particularly easy to overlook. A UK business may invoice in sterling but accept cards issued overseas, or use a platform that settles in euros before converting to pounds. The margin may be embedded in the exchange rate rather than shown as a line item.

Buyers should request a worked example for a typical month, including a domestic card payment, an international card payment, a refund and a chargeback. The example should show the gross transaction value, each deduction and the net settlement. It should also confirm how fees are invoiced and whether they are subject to VAT. Procurement teams should compare that total cost with the existing acquiring arrangement, not merely with the platform's headline percentage.

Reconciliation, refunds and chargeback liability

A payment feature that cannot be reconciled cleanly creates work for the finance team every month. The audit should establish how transactions are referenced in the platform, how payouts appear on the bank statement and whether journal exports can be mapped to the sales ledger. Settlement timing matters: daily payouts, weekly payouts and rolling reserves all affect cash flow and the month-end close.

Refund permissions deserve equal attention. Can any user issue a refund, or is there an approval threshold? Are partial refunds supported? How are refunds matched to the original transaction? Chargeback liability should be stated explicitly, including who responds to disputes, who supplies evidence and which party bears the loss if the evidence is insufficient. These are operational controls, but they are also procurement controls: a platform that bypasses them can undermine the finance team's own governance.

The regulatory perimeter you inherit

In the UK, payment services and e-money are regulated by the Financial Conduct Authority. A software vendor may rely on an exemption, operate as an agent of a regulated firm, or partner with an authorised provider. The buyer does not necessarily need to become a payments specialist, but it does need to understand which entity is authorised, what permissions it holds and how complaints and regulatory references are handled. Contractual warranties should be backed by evidence, not just assurances.

Card data brings a separate obligation. PCI DSS scope can expand when a platform stores, processes or transmits cardholder data, even if the software uses hosted payment fields. The buyer should ask for the provider's attestation of compliance, confirm which version applies and establish whether the platform's configuration affects the buyer's own scope. Data protection terms should also reflect the payment data flows, retention periods and any international transfers. The aim is not to duplicate the vendor's compliance work, but to avoid inheriting an obligation that was never priced or resourced.

Exit without losing the transaction trail

Embedded payments create a historical record that may be needed for accounting, tax, dispute resolution and audit. The exit plan should therefore be agreed before go-live. Buyers should confirm the format and frequency of transaction exports, the retention period after termination, the treatment of tokenised card data and the process for revoking payment consents. If the platform changes payment provider, will historical transactions remain accessible in the same interface?

Notice periods and wind-down assistance should be written into the contract. So should the ownership of transaction data and the return or deletion of records at the end of the relationship. A platform that can switch on payments in an afternoon should not be allowed to switch off access to the ledger with the same speed.

A practical audit sequence

• Identify every embedded finance feature in the platform, including deposits, recurring payments, payouts and lending referrals.
• Establish the merchant of record, the regulated entity and the flow of funds between capture and settlement.
• Request a full fee example covering domestic and international cards, refunds, chargebacks and FX.
• Test reconciliation against a sample of transactions before full rollout.
• Confirm refund permissions, chargeback liability and dispute-handling responsibilities.
• Obtain evidence of FCA permissions and PCI DSS compliance, and map data protection terms to the payment flows.
• Agree export formats, retention periods and wind-down assistance in the contract.

The convenience of embedded payments is real, but it is not a reason to leave financial controls at the edge of procurement. A short, structured audit before the feature touches the ledger is cheaper than reconstructing the arrangement after the first disputed settlement.