All posts Data & Finance · 11 min read

The margin hiding in settlement float

Most companies know their revenue. Far fewer know their margin per transaction, and almost none measure the money that sits in the gap between a sale and a payout. Here's how I built a model that made all of it visible.

By Gökhan Ağarer · Growth Marketing Manager, Berlin · 23 June 2026

Revenue is easy. Margin is the hard part.

In a payments business, top-line numbers look healthy almost by default: volume goes up, revenue goes up, everyone's happy. But revenue is not profit. Each transaction carries its own costs, bank fees, partner commissions, operational overhead, and those costs vary wildly by channel, by network, by merchant. A transaction that looks identical on the revenue line can be a winner or a loser once the costs are subtracted.

When I dug into it, the honest situation was this: we could report revenue confidently, but nobody could say with precision what the margin was on a given slice of business. And you cannot manage what you cannot see. Pricing decisions, channel strategy, and where to push volume were all being made on a number (revenue) that hid the number that actually mattered (margin).

The piece almost everyone ignores: settlement float

There's a second, subtler source of value in payments that rarely makes it into a margin model at all: the settlement float. It's the window between the moment a transaction happens and the moment the money is actually paid out to the merchant. During that window, funds sit with the business.

That float has a real, measurable financial value, and it differs across networks and payout terms. Ignore it and your margin picture is incomplete; measure it and you can see profitability the same way Finance does, not just the way Marketing usually does. Bringing the float into the model was the difference between a "marketing dashboard" and a genuine commercial-intelligence tool that Finance could trust.

What I actually built

The result was an enterprise model in Power BI, built on DAX, sitting on top of the transaction data. The point wasn't a pretty chart. It was a single, trustworthy place to ask "what is this actually worth to us?" at any level of detail. The core of it:

Why a composite, live model and not a spreadsheet

A margin model in a spreadsheet is a snapshot that's wrong by the time anyone opens it. This had to be live. It used a composite connection straight to the data layer (DirectQuery to an Analysis Services model) so the numbers refreshed with the business rather than being copied and pasted. That choice is what let Finance and leadership open it any day and trust what they saw, which is the whole point of commercial intelligence: not a one-off analysis, but a permanent instrument.

It also meant the hard part wasn't the visuals. It was the measure logic in DAX: defining take rate and net rate cleanly, folding the float value in correctly, and making every measure behave under the time-intelligence and scenario filters without breaking. Get that layer right and the dashboard on top is almost an afterthought.

What changed once it existed

For the first time, the business could see margin at transaction level, with the float included, and slice it however a decision required. That reframed conversations: instead of "which channel drives the most volume," the question became "which channel drives the most margin, once we count the float and the costs." Those are very different answers, and only one of them protects the bottom line.

The takeaway

Revenue dashboards are comforting and incomplete. The real leverage is in measuring margin honestly, all the costs, and the easily-ignored value like settlement float, and making it live so people actually use it. It sits exactly where I like to work: the seam between marketing, data, and finance, where a model built right changes what the business decides to do.

A note on the numbers This describes the approach and architecture, not any employer's internal figures, thresholds, or data. The method is general; the specifics stay confidential.
Talk data with me Related: the complete RFM(T) guide → About me