Tourism Tax Registration in Three Steps: What Hosts Routinely Miss

Registering is the easy half. The half that generates penalties is the remittance clock that starts on the first night you host.

Last updated: September 23, 2026

The letter arrives in February about a quarter you closed in November, and it isn't about the amount. It's about a nights figure you can't rebuild.

Tourist tax is a small amount of money per night and a disproportionate amount of administrative trouble, because it's levied by one authority, collected through another, and reconciled against records most hosts never assembled.

The sequence is only three steps long. Get the registration number before the first guest. Report on the period the authority uses rather than the dates your guests slept. Remit against a receipt that actually reconciles.

This guide walks those three steps and names the one hosts routinely miss. It sets out the three records per stay that make a later cross-check add up. Every figure below is a dated example from one specific place, not a standard — rates, forms and deadlines differ by city, and your local authority is the only source that settles what you owe.

Key Takeaways

• Register before the first night. The number is a precondition for letting, not a formality to tidy up in the second month.
• The reporting clock isn't the stay. Deadlines attach to the reporting period, and a stay straddling two periods lands in both.
• A receipt has to reconcile. Nights, guests, exemptions, rate and period, shown separately rather than as one total.
• Three records per stay. Guest register entry, booking and payment record, and the tax line — kept together.
• Every number here is local and dated. Places and effective dates are named; nothing generalises.

Step one: getting the registration number before the first guest, not after

The registration number is what ties a specific unit to a specific responsible person. In most places it has to exist before the first paying night, and it has to appear in the advertisement. That's why hosts who register late usually discover the gap through a listing that won't publish, rather than through a form they forgot.

What the number looks like, and what it must be displayed on, is set locally, so treat the following as dated examples rather than as a pattern:

• Italy. A national identification code (CIN) together with the regional code (CIR) is required, and both are expected to appear in advertising; industry reporting also describes Perugia moving to a new band of roughly €2.50 per person per night from 1 April 2026. One-party claim, industry source.
• Paris. The city tax is described as a percentage of the nightly room rate — 5% in the account we read — with a per-person, per-night cap of €15.93 applying from 1 January 2026. One-party claim, verified to 18 September 2026.
• Latvia. The tourism law is described as requiring accommodation providers to submit foreign guest registrations through the Latvija.lv portal, with the data governed by GDPR retention limits and deleted automatically when the statutory window expires. One-party claim.

Two boundaries matter as much as the number itself. First, the tourist tax isn't your income tax. In France, for example, the micro-BIC regime — a 30% allowance capped at €15,000 for 2026 income — sits on a different track from the per-night tax. So does the separate non-resident route with its 20% minimum. One-party claim. Second, where an identification code must be published, publishing it is part of registration rather than a marketing choice.

Step two: the reporting calendar, and why the deadline isn't the same as the stay date

Hosts build a mental model in which a stay is a thing with dates, and then assume the tax deadline hangs off those dates. It doesn't. Authorities work in periods — by month, by quarter, sometimes per stay — and the deadline attaches to the period, not to the night.

That distinction produces the two mistakes that generate most of the trouble. The first is a stay that crosses a period boundary. A guest arriving on the last day of one month and leaving in the next produces nights in two periods. A report built from checkout dates puts both nights in the wrong one. The second is a rate that changes mid-period, which is common where the tax is seasonal.

Greece is the clearest current example of why the calendar matters: industry reporting describes the climate resilience tax switching to its winter band from 1 November 2026, with the summer figures of €8 and €2 becoming €2 and €4 (one-party claim, industry media). If that holds, the same unit owes a different per-night amount in November than it did in August. Same rate card, different band. And a host who last checked the band in June will remit the wrong figure for the whole winter.

So build a monthly close and do it on a fixed day. For each property: nights sold in the period, guests, guests in any exempt category the locality recognises, the band or rate in force on each night, the amount due, and the amount remitted. Then reconcile the nights figure against your bookings before you submit, not after.

Step three: what a remittance receipt has to show, and why hosts lose audits here

A receipt that says "€240 remitted" isn't evidence of anything. A cross-check doesn't ask whether you paid. It asks whether the number you paid can be rebuilt from your own records, and a single total can't be rebuilt.

What has to appear, separately? The period covered. The number of nights. The number of guests, and the number in any exempt category, with the basis for the exemption. The rate or band applied to each night, with the place and the date that band was in force. The amount. And a reference tying the payment to the filing. Where the identification code is part of the filing, it belongs on the receipt too.

Hosts lose here in three predictable ways. They remit on a total built from a platform's payout figure rather than from nights, which is a different number for a different reason. They apply one band across a period in which the band changed. And they can't produce the guest register that would justify the exempt guests they deducted — which turns an honest deduction into an unexplained one.

The nights figure is the one most often wrong, because it gets assembled from memory across several channels instead of read off one calendar. Airbnb, Booking.com, Agoda and Trip.com bookings sit on one grid at localsbnb.com. Connect Claude, ChatGPT or Cursor to your property and one sentence returns order detail, arrivals, departures and room status for the period you're closing. Installed once, no new app, read-only — which is what you want when the output is going into a filing.

The three records to keep per stay so a later cross-check reconciles

Keep three things per stay, in one place, and the reconciliation stops being a project.

The guest register entry. Whatever your locality requires for each guest, captured at the time rather than reconstructed. Where submission is mandated, the entry you keep is your copy of what was submitted, with the submission timestamp. Latvia's Latvija.lv route for foreign guests is one such case, described with GDPR retention limits and automatic deletion when the window expires (one-party claim). A paper book can't prove when a line was written, which is the reason digital submission exists.

The booking and payment record. Channel, booking reference, nights, guests, and what the guest actually paid. This is what lets you defend the nights figure, and it's also what separates a night you sold from a night you blocked.

The tax line. Nights, exempt guests, band applied, amount computed, amount remitted, reference, and the period it was filed in. One row per stay, or one row per period per property — pick one and never switch, because a cross-check reads the pattern as much as the values.

Retention is a local question. Some places require a statutory window and then require deletion; others expect a longer audit trail. Follow your local authority rather than any habit you brought from another country, and note that where a retention window exists, keeping data past it is its own problem.

FAQ

Do I register once, or once per property?

Per property, in the places we have looked at, and sometimes per unit within a property. Treat each advertised unit as needing its own number until your local authority tells you otherwise.

I only let for a few weeks a year. Does this still apply?

Usually yes. Registration is generally triggered by letting at all rather than by volume. And the reporting periods keep running even in a month with no guests. That's where "nothing to report" and "nothing to file" get confused. Check your locality's rules.

Does the platform collect the tax for me?

In some jurisdictions a platform collects and remits under an agreement with the authority, and in others it doesn't. Whether yours does, and whether that covers your whole obligation or only part of it, is set by that platform's terms and by local law. Confirm both with your local authority before assuming the line is handled.

Registration, reporting and remittance are three separate clocks, and the second one is the one that runs whether or not anybody reminds you. Set the monthly close on a fixed day. Keep three records per stay. Treat every figure you read online as a dated example — starting with the nights, which are easier to defend when every channel's bookings live on one calendar at localsbnb.com.

---

Rates, bands, forms, deadlines and retention periods differ by city and country and change over time; every figure here is a dated example from the place named, sourced from a single party, and isn't a standard. Confirm your own obligation with your local authority. This is not tax or legal advice.