I didn't plan to learn anything about restaurants this year. I cook a lot at home, I eat out occasionally, and on those occasions I rarely think about how the card terminal at the counter gets paid for.

I know how it works, just not the economic model behind it.

Earlier this month I spoke to our customer Tebi, that sells software to restaurants, but then I noticed we have a few more in the same space - Klearly (in-person payments for restaurants), SOUS (discovery, online ordering and delivery, with Uber Direct plugged in), and FareHarbor (bookings for tours and experiences, part of Booking Holdings)… But we didn't set out to win at hospitality, it just kinda happened so I needed to understand why

Every restaurant is a snowflake

Here's what the four have in common: Their customer isn't a company with a procurement team. It's a restaurant group with one location, or 12, or a franchise… Or a franchise where every franchisee signed something slightly different.

Sometimes the platform sells per location. Sometimes per terminal, sometimes per order.

And almost always, some part of the fee follows the money going through the till.

Lots of billing tools don't really know how to do that. A typical SaaS company charges you €97 a seat and that's that, but a hospitality platform charges you a platform fee, plus a fee per terminal, plus a percentage of the volume that ran through that terminal, plus a monthly add-on for the second location, minus the delivery fee that already came out of your payout, and a referral fee sometimes. That's like 5 different pricing shapes on one transaction, one of them at least being negative.

Then, when the restaurant group opens their next location in another country, new VAT rate, hardware needs to be shipped, and that's often not a subscription but a one-off.

I've been in billing for a while and I still find this interesting, because the pricing model of a 30-person restaurant software company is more complicated than most enterprise SaaS!

The platform knows the merchant better than any billing vendor does

When Tebi designs pricing, they know what a restaurant in Lisbon can absorb versus one in Amsterdam, which is why they run 8 markets on one billing setup rather than 8 setups (read our case study).

When SOUS charges per conversion rather than per month, it's because they know a restaurant will pay for a filled table and will not pay for "software". When a payments company prices a terminal by the volume it processes, it's because they've watched which restaurants churn when the fee is flat.

None of that knowledge lives in the billing vendor. We certainly don't think about this day to day. But it does live in the platform. That vertical SaaS knows best!

So our job in billing is to follow the pricing the platform designed, and to keep following it when the platform changes its mind next quarter.

Lots of billing tools get this completely backwards because they have a pricing model, and the platform bends its commercial model to fit it and that's how you end up with a script to add the "terminal delivery fee" hard-coded as a seat or hacked in as a "pending lineitem".

To be fair, I've also seen this done in spreadsheets which I didn't like at all.

What the finance team really needs

I went back through what these four teams said when they first talked to us, and it's the same list every time, in different words:

• Too much manual work to invoice a merchant correctly.

• Multiple invoices per merchant per month, because the subscription and the usage came from different systems.

• Tax done by hand in in-house invoices, which an auditor will eventually ask about.

• Revenue that finance couldn't recognise properly because the invoice didn't match the contract.

• A new pricing idea that took a quarter to ship because engineering had to build it.

The fifth one is the one I'd put at the top. A hospitality platform that can't change its pricing without an engineering sprint can't compete, because the next platform will. Pricing in this space moves with the market, with the delivery apps, with what Uber charges this month. Billing has to move at the same speed or it becomes the reason you don't.

What "following the pricing" looks like in practice

Kinda like this:

1. Platform fee plus per-terminal fee plus volume-linked fee on one ledger, with the volume metered rather than typed in.

2. Hardware invoiced from the same system as the software, with the right VAT treatment per country, so finance doesn't run a second invoicing process for boxes.

3. Payout deductions (delivery fees, PSP fees) shown as what they are, so the merchant's invoice and the merchant's payout agree.

4. Exact Online or whatever the ERP is gets the entries automatically. Tebi used to book all revenue as one manual entry. Not my favourite accounting practice, but whatever, it's fixed now.

5. When the platform wants to try per-conversion pricing for a cohort of venues, that's a config change by the person who owns pricing, and the invoices just come out right.

I'm aware that reads like a feature list. It's really one feature: the platform designs the pricing, the billing does what it's told!

Why does this keep happening?

My theory, which I'd hold with a ", probably" as I often do: hospitality platforms are hybrid by nature.

Hardware, software, payments and marketplace economics were never separate for them, so they never had the luxury of a clean subscription model. They are the hybrid economy, many many years before AI companies started discovering credits and caps.

That's also why they end up here. A billing system built for seats cracks on the terminal fee. A usage meter built for API calls stops before the invoice.

A company whose founders ran billing at Adyen (€1T+ of volume, a lot of it restaurants, as it happens) is a reasonable place to end up when your pricing is four shapes on one invoice and one of them is negative.

SOUS calls us an ecosystem partner, which I find a little bit generous and also, I'll take it.

Anyway. I now know how the card terminal gets paid for. It's more complicated than the food.