Calculating tourist tax automatically: how it works across DACH

Few items on a hotel invoice are as inconspicuous and at the same time as error-prone as the tourist tax. A few euros per person per night – but every municipality defines it differently, every season can carry different rates, and there are more exemptions than you'd think. Anyone running several properties or hosting guests from many segments will not get far with a spreadsheet.

What tourist tax, bed tax and city tax actually are

In German-speaking countries the terminology isn't standardised, and that's part of the problem. Three things often get conflated:

• Kurtaxe / guest contribution – levied by recognised spa and recreation towns. It funds tourism infrastructure (spa park, beach maintenance, events). In return the guest usually gets a guest card with discounts.
• Bed tax / city tax / accommodation tax – a municipal expense tax that more and more cities levy (Berlin, Hamburg, Cologne, Frankfurt …). It's not a service in return, it's a pure tax on paid overnight stays.
• Tourism levy – burdens the business rather than the guest, but occasionally enters the discussion too.

For the hotelier the distinction matters in practice because the tax base differs: tourist tax is almost always per person per night, while city tax is often a percentage of the accommodation price.

DACH: three different systems

Germany

In Germany every municipality sets its own tourist tax by statute. That means hundreds of different rule sets. Typical variants:

• A fixed amount per person per night, e.g. €2.50 in high season, €1.50 in low season.
• Seasonal tiers with exact cut-off dates that can shift each year.
• For city tax often a percentage (e.g. 5% of the net accommodation price) with a per-night cap.

Austria

In Austria the equivalent is usually called Ortstaxe or tourism levy and is regulated at the provincial and municipal level. Rates and models vary considerably by province – sometimes a flat amount per overnight stay, sometimes a percentage. In Vienna, for instance, it's a percentage of accommodation revenue.

Switzerland

In Switzerland the classic Kurtaxe dominates, again regulated locally or through tourism organisations, almost always as a fixed amount per person per night (in CHF). It's frequently coupled with a guest card offering local benefits.

Three countries, three terms, dozens of local special rates. There's simply no central table that covers it.

Per-night vs. percentage – why the model matters

The two basic models affect billing differently:

• Per person per night (flat model): calculation = number of taxable persons × nights × rate. Sounds simple, gets complicated through seasonal cut-offs and exemptions.
• Percentage of the accommodation price: here you first have to isolate the pure accommodation share – breakfast and extras usually do not count towards the tax base. Calculate the percentage on the total price by mistake and you'll systematically over-charge.

Both models depend directly on data that lives in the PMS: number of persons, arrival/departure, net accommodation price. That's exactly why the calculation is ideal for automation – and exactly why it's so error-prone done by hand.

The exemptions are the real effort

If every guest paid the full rate, the matter would be trivial. Reality is full of exemptions, and they again differ by statute:

• Business travellers are exempt from city tax in many cities – but the exemption usually has to be proven by an employer certificate. Without proof, the tax is due.
• Children and teenagers are often exempt or reduced, with locally varying age limits (under 6, under 16, under 18 – all of them occur).
• People with disabilities, accompanying persons, partly the severely disabled above a certain degree.
• Locals / second-home owners who already contribute elsewhere.

Each of these exemptions has to be correctly recognised, documented and accounted for towards the municipality. That's the point where manual work tips over.

Why it fails at scale by hand

For a small property in a single spa town with a constant rate, the spreadsheet still works. But as soon as at least one of the following is added, it becomes untenable:

• Multiple locations, each with its own statute.
• Seasonal cut-offs that someone has to maintain every year – and forgets once.
• Many exemptions whose proofs must be documented cleanly, or the hotel pays the difference.
• Monthly reporting to the municipality that has to match the issued invoices exactly.

The typical error isn't the one wrong entry, it's the inconsistency over time: January was calculated differently from July, one employee handled children differently from another. A municipal audit catches that, and the back-charge hits the hotel.

The automation approach

The clean solution is rule-based. Per location, the statute is set up once as a rule set:

1. Model and rate: per night or percentage, with the amount or percentage.
2. Seasonal cut-offs as date boundaries so the correct rate applies automatically.
3. Exemption rules as conditions: age under X → free, business trip with proof → free, and so on.
4. Tax base chosen correctly – for percentage models only the accommodation share.

From each booking in the PMS – number of persons, length of stay, date, accommodation price – the system then calculates the tax automatically, shows it correctly on the invoice and delivers the totals for the municipal report at month's end. The decisive advantage: the logic is set up once and applies to every booking the same way. No drift, no forgotten cut-offs, no two employees treating children differently.

Bottom line

Tourist tax is a textbook example of a task that's trivial in isolation and grinding in aggregate. The data lives in the PMS, the rules sit in the statute – all that's missing in between is consistent, rule-based processing. Automating it not only means less work at month's end, it means a consistent, audit-proof calculation across all properties and seasons. That's exactly the difference between "works for one property" and "works for the tenth one too".