How to show a total price that includes local taxes

This post is the Third in a four-part series on the CMA's pricing rules for travel and what they mean for booking platforms:

1. The CMA's pricing rules for travel: what has to be in the total price
2. Tourist tax in the headline price: what the CMA's total price rule means for platforms
3. This post: How to show a total price that includes local taxes
4. Are platforms liable for pricing errors under the CMA rules, not just the seller? Who carries the responsibility when a price is wrong, and why the answer changed.

How to show a total price that includes local taxes

A total price that includes local taxes has to be built before the price ever renders, not corrected afterward. Under the CMA's total price rule, every search result, listing page, app banner, and basket a UK customer sees has to carry the complete number, tourist tax included, from the first moment a price appears. A wrong or incomplete number at any of those touchpoints is a breach, and at platform scale a single stale rate repeats across thousands of displayed prices a day. Getting the number right is a sequence with four steps: resolve the jurisdiction, pull the current rate, apply it before render, and keep the rate current after launch. We cover the legal basis in tourist tax in the headline price and the wider CMA rule in the CMA's pricing rules for travel. This piece covers how to get the price itself right.

Step 1: resolve the jurisdiction before you touch the price

The obligation follows the destination. Tourist tax is set by the municipality where the guest stays, not by the customer's home market or the platform's country of incorporation, so a UK OTA selling a stay in Amsterdam owes the Amsterdam rate and the same OTA selling a stay in Rome owes the Rome rate. Before any tax figure can be calculated, the booking flow needs the exact location of the property at city or municipal level, since rates and rules frequently differ within the same country. Get this step wrong and every later step inherits the error.

Step 2: pull the current rate for that location

Once the jurisdiction is known, the price has to reflect the rate that applies right now, since the CMA judges the displayed total, not the intention behind it. This is where a static, internally maintained rate table breaks down. Rates change without warning and following every municipality by hand is a full time job. The rate returned through the LocationTax API reflects these variations at the jurisdiction level, with every calculation based on verified, up-to-date local rules rather than a number someone entered at launch and never revisited.

Step 3: apply the rate before the price renders anywhere

The CMA requires the total price at every invitation to purchase, and it reads that term broadly: the first search result, the listing page, any app banner, and the basket all qualify. A tax figure added only at checkout, or a note that local taxes may apply, fails the rule regardless of how accurate the number turns out to be later. For the team building the price display, that means the rate has to be resolved and included in the calculation that runs before the page renders, not bolted on at a later step in the journey.

Step 4: keep the rate current after launch

A rate that was correct on launch day can be wrong within months. Municipalities raise rates, add seasonal variations, or change per person and per night structures with little notice, and a displayed price built on a stale rate becomes a compliance exposure the moment the municipality moves. The CMA's first fine under the new regime shows the scale the regime works at: a mandatory £3 booking fee shown too late in the journey cost the AA's driving schools £4.2 million in April 2026. Trippz monitors every jurisdiction it covers and pushes rate updates automatically, so the price a platform displays stays current without anyone on the compliance or engineering team tracking each municipality by hand.

What about exemptions and rate variations?

Tourist tax rarely applies as a single flat number. Children under a set age are commonly exempt, some cities cap the number of taxed nights, and rates can differ by season or by accommodation type within the same city. A rate lookup that returns only a headline number without these variations will produce a wrong total on exactly the bookings where it matters most. The rate returned through the LocationTax API reflects these variations at the jurisdiction level, so exemption logic does not need to be built and separately maintained inside the pricing engine itself.

Testing the integration before it touches live prices

Every one of these four steps can be verified against real jurisdiction data before it reaches a live search result. Creating an account carries no commitment, and sandbox access follows within two business days, so the integration can be tested end to end, jurisdiction resolution through to rendered price, before it goes anywhere near a customer.

Trippz covers rate maintenance across 70+ countries, and the underlying data model is the same one covered in what is a tourist tax API. The service is SOC1 Type 2 and SOC2 Type 2 certified and GDPR compliant, and it is the tax engine behind pricing at Airbnb, Booking.com, and Expedia.

Trippz keeps the local tax rate current for every price you display. Create your account.