Why this is harder than it looks
Kurtaxe is a small charge with a disproportionate administrative footprint. It is levied per overnight guest, set and collected locally, and the accommodation acts as collector: add the right amount to each guest’s bill, remit the total to the commune, and file a report of nights stayed.
The difficulty is that "the right amount" is not one number. Rates are set per commune. They vary by guest age and season. Children are frequently exempt or discounted, and so are certain visitors and members. There are caps. And each municipality wants its settlement in its own format.
A campsite makes this worse than a hotel does, because guest numbers are high and stays are irregular. A family of five arrives for four nights, two of them children under the exemption age; a touring couple stays one night and leaves at dawn; a seasonal contract runs the whole summer. Every one of those has a different tax consequence, and by the end of the period there are hundreds of them.
HESTA compounds it. The Federal Statistical Office wants arrivals, overnight stays and guest origin — largely the same underlying facts, in a different shape, on a different schedule.
Capture once, at check-in
The fix is structural rather than clever: capture the guest record once, at check-in, in exactly the shape both obligations need.
That check-in can happen at reception or on the guest’s own phone before they arrive. Either way it produces one authoritative record: who stayed, how many of them, their ages, where they came from, how many nights. That record is the single source both the Kurtaxe calculation and the HESTA return read from.
Which is why the numbers agree. What you file matches what you took, not because someone reconciled two systems, but because there is only one system and every figure is traceable back to its source booking.
Kurtaxe, calculated per commune
You configure your commune’s rules once: the per-night rates by guest type — adults, children, day guests — the exemptions, and the caps. From then on Grondia applies them to every stay automatically. Nobody works out that the two children were under the exemption age; the record already knows their ages.
The tax lands on the guest’s running folio alongside the pitch, the shop purchases and any extras, so it is settled once at check-out rather than collected as an awkward extra at the desk. Guests can also settle it themselves through the portal as part of online check-in, before they ever arrive.
At period end, Grondia produces the settlement your municipality expects, in the format it wants.
HESTA, compiled and filed on schedule
HESTA reporting runs off the same check-ins. Arrivals, departures and overnight statistics are compiled in the background and submitted on schedule, with a full audit trail. There is no parallel spreadsheet and no month-end scramble to reconstruct who was there.
Because every record carries its own audit trail, an inspection is an export rather than a fire drill. A cantonal or communal auditor asking which stays were reported, when, and how the figures were derived is answered with a few clicks — every figure traces to its source booking.
What this actually gives you back
Two things, and it is worth being precise about which.
The first is time, at the worst possible moment: period end usually lands while the season is still running, so the tally competes with actual guests. Removing it removes a recurring interruption rather than a one-off task.
The second is correctness under audit. A hand-tallied return is not just slow, it is unverifiable — if a figure is questioned, reconstructing how it was reached means going back through the same spreadsheet that produced it. A return derived from booking records, with an audit trail per record, can be defended rather than re-argued.
On a Professional plan and above, HESTA integration, the visitor-tax module and self check-in are included rather than priced as add-ons.