How should a booking platform handle tourist tax in Europe

A booking platform handles tourist tax in Europe by answering three questions for every market it operates in: what is the applicable rate, who is legally required to collect it, and who forwards it to the local authority. The answers differ per municipality, they change without warning, and a wrong answer applied across thousands of bookings is a liability problem. This post walks through the five steps a platform needs to work through, and where each one tends to break.

What actually varies per market

Most European tourist tax is set locally, with the municipality or region making almost every design choice. A handful of countries, Malta among them, set a single national rate instead. Where local-level pricing applies, which is most of the markets a platform will operate in, the variables to track per jurisdiction are:

• The rate structure. Most cities charge a fixed amount per person per night. Some charge a percentage of the accommodation price instead, Amsterdam among them, and that distinction changes how the tax has to be calculated, not only what the final number is.
• Accommodation class and property type. Many schemes vary the rate further by hotel category, room type, or property type within the same city. In markets like Italy, where these variations stack on top of seasonal and per-person rules, the combination produces hundreds of distinct rate scenarios for a single country.
• The base and caps. Some schemes tax every night of the stay, others cap the number of taxable nights per stay. Children are exempt in some cities, half-rated in others, fully taxed elsewhere.
• The collecting party. In most markets the duty sits with the accommodation provider. A growing number of city mandates name booking platforms directly as the collector, and separate collection agreements between platforms and cities add a third variant.
• The remittance path and cadence. Monthly, quarterly, or per-stay remittance, to a city, a region, or a national body, each with its own filing format.

No two of these variables move together. A rate change in one city says nothing about the exemption rules in the next.

The five steps to get it under control

Step 1: Map where you carry the duty. Go market by market and establish whether the collection obligation sits with you, with the host, or is shared under a mandate or agreement. This is a legal question per jurisdiction, and the answer for the same platform can differ between two cities in the same country.

Step 2: Establish the correct rate per jurisdiction. For every market where you collect, you need the current rate, base, caps, and exemptions. The source has to be authoritative, meaning municipal decisions rather than aggregator listicles, which are frequently stale.

Step 3: Apply the tax at booking or checkout. Decide where in the funnel the amount is calculated and shown. This step matters more every year: the UK's CMA now requires the total price, tourist tax included, to appear from the first moment a price is shown to a UK customer, not only at checkout, and getting it wrong at scale has already produced a multi million pound fine. We cover the build sequence for a compliant total price in how to show a total price that includes local taxes.

Step 4: Keep the rates current. This is the step most platforms underestimate. Municipalities change rates, add exemptions, and extend mandates without notifying platforms. Whatever you built in step 2 starts decaying the day it ships, so rate maintenance needs a permanent owner rather than a place on a launch checklist.

Step 5: Confirm the remittance path. For every market where you collect, confirm who files and pays, on what cadence, and in what format. Money collected but wrongly remitted creates exposure toward the authority and toward your hosts.

Where this breaks down in practice

Steps 1, 3, and 5 are one-time decisions per market. Steps 2 and 4 are the ongoing cost, and they scale with every market you add. A compliance team can track a handful of cities in a spreadsheet. At meaningful European coverage the monitoring work becomes a full time job, and the failure mode is silent: nobody notices a stale rate until an authority, a host, or a guest does.

Platforms end up sourcing rate data one of three ways. Someone maintains it by hand, which works only at small scale. Engineering builds and maintains an internal rate database, which gives full control but makes tax maintenance a permanent claim on the roadmap. Or the platform connects to a maintained external source through an API and applies the rate without owning the tracking work behind it.

The registration layer on top

The EU Short-Term Rental Regulation 2024/1028 adds a separate duty next to tax: platforms must verify that hosts hold a valid registration number before a listing goes live, in the jurisdictions where such numbers are required. Tax collection and registration verification are different obligations, but they land on the same compliance desk, and a platform designing for one should account for the other. The full obligation picture is mapped in the compliance stack for booking platforms in Europe.

How Trippz covers the steps that never end, and the ones around them

Trippz's Location Tax API is the maintained external source for step 2. A platform sends a location, and the API returns the applicable tourist tax rate for that jurisdiction at the time of the query. Every calculation is based on verified, up to date local rules, because Trippz monitors every relevant jurisdiction and pushes rate updates automatically as they change. That same call resolves step 3 in the same motion, since the rate arrives in time to include in the price before it renders, whether that is a search result, a listing page, or a basket. Step 2 and step 4, the two steps that never end, stop being your team's work.

The Tax Content API's per jurisdiction dataset, the same data underlying the Location Tax API, also covers who the obligation falls on in a given market, which is the input step 1 needs. And for OTAs already routing tax through Trippz, the same visibility into what is owed and where closes out step 5: Trippz calculates the tax due per jurisdiction and instructs its payment service provider to pay local governments directly, currently active in France, Canada, Mexico, and Italy.

Trippz is SOC1 Type 2 and SOC2 Type 2 certified and GDPR compliant, and is trusted by platforms including Airbnb, Booking.com, and Expedia. For the registration duty under EU STR Regulation 2024/1028, a separate service, the Host Compliance API, connects directly to national and local authority systems.

Getting started

See how the Location Tax API fits your setup on the Trippz platforms page. Creating an account carries no commitment, and sandbox access follows within two business days.