How to configure tourist tax

Most cities that live on tourism charge a tax on overnight stays: taxe de séjour in France, Kurtaxe in Germany and Austria, imposta di soggiorno in Italy, occupancy tax across the United States. The rules differ everywhere — per person or per room, a fixed amount or a percentage, children exempt or half price, capped after a week or not capped at all — and the rates change more often than anything else in your pricing.

Solidres handles this with two ideas, and understanding them is most of the work:

• A property has any number of tourist taxes, each a separately named line on the booking. A New York hotel has two; a Barcelona hotel has one with VAT on it; a German spa town has one that changes with the season.
• Each tax has any number of rates, each valid from a date. You enter next year's rate the day it is announced, and Solidres charges each night of a stay at the rate in force that night.

Where tourist tax lives

Tourist taxes are no longer a setting inside the property. They are their own screen, because one property can have several of them and each carries its own history of rates.

In the Joomla administrator, go to Components → Solidres, then in the sidebar open System Info → Tourist taxes. The property edit screen has a Set up tourist taxes button that takes you to the same list, already filtered to that property.

If you run a Solidres Hub site, your partners manage their own properties' tourist taxes from the partner dashboard: the Tourist taxes entry in the property menu, after Extras. Everything in this article applies there too — it is the same form, scoped to the partner's own properties.

Creating a tourist tax

Press New. The Details section at the top describes what kind of levy it is — the things that do not change when the rate changes.

Rates: entering a change before it happens

The Rates section below it is the list of rates. Each row is the tax as it stands over a range of dates, and the numbers that change on 1 January live here — not on the tax itself.

The rule is simple: for each night of the stay, Solidres uses the rate whose First night is the latest one that has already started. A rate with no Last night runs until the next rate takes over. So the normal way to raise a rate is to add a row, not to edit the old one — which keeps last year's bookings charged at last year's rate, and keeps your report honest.

Two helpers sit beside the list. Add next year's rate copies the latest rate forward to the next 1 January, so you only have to type the new amount. And if no rate covers the nights ahead, the edit screen and the list both warn you — No rate from… — so you find out before a guest is charged nothing.

Seasons

A season is just a rate with both dates filled in. Keep the low-season rate open-ended and add a closed row for each high season:

A stay from 29 October to 2 November is charged 4.00 for three nights and 1.00 for the last two, without you doing anything.

Several taxes on one property

Where an authority stacks levies, create one tax per line rather than adding the amounts together. Guests see each by name, your report totals each separately, and when one of them changes you change one rate.

This is how a US city is configured — a percentage tax and a flat per-room fee, side by side — and how Barcelona's municipal surcharge is separated from the regional tax if you want it shown separately. See the recipes below.

Several properties in the same city

A tourist tax belongs to one property, so that ownership is never ambiguous — particularly on a Hub site. If you run several properties under the same municipality, set the tax up once, then select it in the list and use Actions → Copy to property.

The copy carries all its rates, and lands unpublished so you can check it before guests are charged. Copying is the only batch operation offered: a tax cannot be moved to another property, because bookings that were already charged point at it.

What guests see

The tax appears by name, with its own row, everywhere a booking's money is shown: the room price preview, the confirmation step before the guest commits to pay, the confirmation e-mail, the invoice PDF and the registration card. Where the tax carries VAT, a second row shows VAT on <tax name> (10 %).

The tax is always visible before payment. That is not just good manners — the US FTC fee rule and California SB 478 require the full price up front, and European price-transparency practice expects the same.

Taxes collected at the desk

In much of southern Europe the tourist tax is handed over at check-out rather than paid with the booking. Set Paid at the property to Yes and Solidres splits the difference for you:

• The tax stays in the booking total, and the guest's row reads <tax name> (payable at the property), so nobody is surprised at the desk.
• It is left out of what the payment gateway charges — full payment, a percentage deposit, an invoice's amount due, a balance reminder. Money taken at the desk never passes through the gateway, so it can never count as paid online.

A booking that has been paid in full online is still treated as settled, even though the desk portion is outstanding: it is not a payment the gateway is ever going to see.

Changing the tax on one booking

Diplomats, government travellers, disability exemptions, a business stay in a city that exempts them — every exemption worth having needs proof that somebody looks at, so Solidres does not let guests claim one. Staff do it on the booking.

Open the reservation in the administrator and edit it. Under the price overrides you will find Override the tourist tax: one amount per tax on the booking. Enter what should be charged — 0 exempts the booking — and give a Reason, which is required.

• The amount you type survives later amendments to the booking. It is not quietly recalculated behind you.
• To go back to the calculated tax, clear the override box. The screen shows you the calculated figure while you work.
• VAT is charged on the amount you enter, at the tax's own rate, so the invoice still separates tax from VAT.
• An exempted booking keeps the taxes it was liable to, so your return can report an exemption rather than lose the stay.
• The reason is stored with the booking and listed on the tourist tax report.

The tourist tax report

System Info → Tourist tax report is what you file your return from. Pick the property, a date range and whether to group by month, quarter or year; Hub partners get the same report over their own properties.

The important detail is that every night counts in the period it falls in. A stay from 29 September to 2 October is split between September and October, because that is how the period is defined on every return that asks for one — not by the date the booking was made or paid.

Each row gives you, per tax and per period: bookings, taxed nights, guests at the full rate, at the reduced rate and exempt, nights left untaxed by a cap, the taxable base, the tax, VAT on it, and how much was paid online versus at the property. Bookings whose figure was typed by staff are listed separately with their reasons. Export CSV gives you the same rows with six decimals and the raw period key, ready for a spreadsheet.

Two things to know about the numbers. Nothing is converted between currencies — every figure is grouped by the currency the booking was taken in, because a return is filed in the money that was actually collected. And a period total can differ from the sum of the bookings' own totals by a rounding step, because each booking is rounded once while the report adds up the night-by-night allocation, which is the figure an authority asks for.

Configuration recipes

Several regimes look like they need a feature of their own and turn out to be a way of filling in the form. Here are the three most often asked about, then a short list of the rest.

Paris — a percentage with a cap, and the surcharges folded in

French communes charge a fixed amount per person per night for classified accommodation, and unclassified accommodation pays a percentage of the nightly price per occupant, capped. On top of the communal figure come additive surcharges — departmental +10 %, Île-de-France +15 % and +200 %. Paris therefore multiplies the base by 3.25.

Do not try to model the surcharges. Enter the commune's published total, which is the figure the guest actually pays — for a percentage tax, multiply both the rate and the cap, because min(16.25 % × s, 15.93) = 3.25 × min(5 % × s, 4.90).

The percentage form divides the night's price over all occupants, children included, and then charges only the guests who are liable — which is exactly what the French guide specifies, and the reason the per-person and per-room percentage units are separate choices.

New York City — a percentage and a flat fee, as two lines

US cities stack three to seven levies, and several of them are flat fees rather than percentages. Rather than a feature for "percentage plus fee", create two taxes on the same property. In practice a New York City hotel room carries about 14.75 % plus $3.50 per room per night:

The same recipe covers Nashville and New Orleans. Where levies compound — Chicago taxes some of its levies on a base that already includes another — enter the published effective rates rather than the nominal ones; the authority publishes both.

Barcelona — a night cap, an age exemption, and VAT on the tax

Catalonia's IEET is charged per person per night by accommodation category, capped at seven nights per stay, with under-17s exempt and 10 % VAT on the tax itself, shown as its own invoice line. Barcelona adds a municipal surcharge that steps up by €1 a year.

The surcharge is folded into one amount here. If your accountant would rather see the two separately on the invoice, make them two taxes, exactly as in the New York recipe — the totals are identical.

Because the surcharge rises every year, this is the case Add next year's rate exists for: the day the increase is announced, add a row starting 1 April with the new amount, and stays before that date keep the old one.

The rest, briefly

What Solidres deliberately does not do

Some rules genuinely need information a booking engine does not have, and are handled at the desk with an override instead:

• Liability that depends on nationality or residence (Malaysia, the Maldives, Buenos Aires) — a booking does not carry a guest's nationality.
• Caps counted across separate stays, such as Rome's per-calendar-year night cap — that needs to identify the same guest across bookings.
• Retroactive long-stay refunds (New York at day 90, Texas) — post-stay accounting rather than pricing.
• Rates that key on the payment date rather than the stay (Hawaii, San Diego). Booked from is the closest approximation.
• A built-in database of municipal rates. Rates change in hundreds of jurisdictions every year; the figures have to be the ones your authority publishes, not ones Solidres guessed.

Upgrading from Solidres 4.3 and earlier

Earlier versions had a single tourist tax setting on the property itself. Installing 4.4.0 migrates it for you: every property that had tourist tax switched on gets one tourist tax, with one open-ended rate carrying its amount, its age threshold and its night cap. The old setting is then switched off, and the nine fields it used are replaced on the property form by a Set up tourist taxes link.

Amounts change on properties that used "Per person per room". That charge type had two defects: it ignored the number of nights, and its night cap did nothing. Those properties were under-collecting on every multi-night stay. After the upgrade the tax is multiplied by the taxed nights and the cap works — which is what the setting always claimed to do, and what your authority expects, but it does mean a quote changes.

"Per person per stay" setups were migrated as per person per night, nobody exempt — which is what they actually did, child exemption included. If children should be exempt at your property, set Exempt under age now.

A configuration that could not be expressed faithfully — an adult rate of 0 with a child rate, a child rate higher than the adult rate, or the old percentage form of "per person per stay", whose formula was not meaningful — is migrated unpublished with a notice naming the property, so it cannot charge anything until you have looked at it.

Past bookings keep the tourist tax they were charged, so your totals for earlier periods are intact. They have no night-by-night breakdown, though, since nothing recorded one at the time; the report counts them in a Without breakdown column rather than pretending they were per-booking charges.

If you use the Complex Tourist Tax plugin

Some sites run a third-party plg_solidres_complextouristtax plugin to get year-by-year rates. You no longer need it. The migration imports its yearly rates as dated rate rows — each year as a closed range, so a year it had no row for still falls back to the base rate, exactly as the plugin did.

The upgrade is safe with the plugin still enabled; the System page will warn you that it is. Once you have checked the imported rates, disable and uninstall it.

Troubleshooting

If you are building an integration, a booking's tourist tax breakdown is available read-only on the reservation resource of the Solidres API, line by line, together with the portion payable at the property.