Automating hotel invoices: German VAT splitting (§14 UStG) explained

A hotel invoice looks harmless: two nights, breakfast, a parking spot, done. For tax purposes it isn't. The moment the tax office audits you – or a business traveller hands their invoice to an accountant – it shows whether the VAT was split correctly. And this is exactly where most mistakes happen. Not out of bad intent, but because doing it by hand is simply tedious.

What §14 UStG actually requires

§14 of the German VAT Act (UStG) defines the mandatory contents of a proper invoice: full name and address of supplier and recipient, tax number or VAT ID, invoice date, sequential invoice number, a description of the service, the date of supply – and, crucially for us here, the amount broken down by tax rate.

That last phrase is the catch. As soon as an invoice contains services taxed at different rates, each rate must be shown separately: net amount, tax rate, tax amount. A single combined line item like "Overnight stay incl. breakfast: €180" with one tax rate is formally incorrect.

The splitting obligation: 7% vs. 19%

In Germany, pure accommodation is subject to the reduced rate of 7%. That's the overnight stay itself – the room, the bed linen, cleaning the room.

Everything that does not directly serve accommodation falls under the standard rate of 19%. This classically includes:

• Breakfast and other meals
• Parking / garage
• Sauna, spa, wellness
• Minibar, pay-TV, separately billed Wi-Fi
• Conference packages, to the extent they include catering

This separation is called the splitting obligation (Aufteilungsgebot). It is not optional. Germany's Federal Fiscal Court has confirmed this repeatedly: even when breakfast and accommodation are sold as a package, the breakfast portion must be taxed at 19%. The old simplification that let you apply a flat breakfast share has become risky in practice – the tax authorities now expect a comprehensible calculation.

A simple example. A €200 booking contains two nights at €80 and two breakfasts at €20:

That's the invoice the guest needs – and the one an auditor wants to see.

Why manual work almost always goes wrong

Day-to-day reality looks different. Reservations come in via three channels (own website, Booking, a niche portal), breakfast is sometimes included and sometimes not, the parking spot is buried in a comment field. Whoever types all of this into the invoicing software at night makes, on average, one of three typical mistakes:

1. A flat rate on everything. The whole booking runs at 7% because "it's a hotel". Breakfast and parking are under-taxed – an audit means back-taxes plus interest.
2. Gross/net confusion. Hotel prices are gross. If the gross amount is wrongly treated as net, the stated VAT is off – and the business customer reclaims too much input tax.
3. Rounding drift. With cent-precise per-line splitting, rounding adds up. If the line items don't sum exactly to the booking amount, the invoice is mathematically wrong.

None of these is dramatic on a single invoice. Across 80 invoices a month over several years, it becomes a systematic deviation that gets expensive in an audit.

How automation solves it

The trick isn't to type faster – it's to stop typing. The data already lives in the PMS: arrival, departure, room rate, booked extras. Clean automation reads this data and applies fixed rules:

• Mapping per service type. Each line item is assigned its tax rate once: accommodation → 7%, breakfast → 19%, parking → 19%. It's never decided by hand again.
• Consistent gross logic. Since the guest knows a gross total, VAT is extracted from the gross (net = gross / 1.07 or / 1.19), not added on top. The final amount stays exactly the amount booked.
• Rounding at the end. Only the total is rounded to the cent, and any difference is distributed to the largest item. The line items are guaranteed to sum to the booking amount.

At zimrly this is exactly the path: the PMS supplies the booking, the invoice is generated with correct splitting and handed to the accounting provider (easybill, lexoffice, sevdesk). The hotelier sees the finished invoice but never sets a tax rate themselves. Cancellations and retroactive price corrections are handled too – the single most common error source in pure manual work.

Outlook: ZUGFeRD and XRechnung

From 2025, Germany has a mandatory e-invoicing regime in B2B. Step by step, every company must be able to receive electronic invoices in a structured format, and later to issue them. The two relevant formats:

• XRechnung – a pure XML format, mandatory for invoicing public authorities (B2G).
• ZUGFeRD – a hybrid: a PDF with the structured invoice data embedded as XML. A human sees a normal PDF; the accounting software reads the XML.

For hotels this means: an invoice to a business traveller or corporate account will increasingly have to be machine-readable. And machine-readable means the tax-rate split has to be correct not just in the PDF layout but in the structured dataset. A mis-split line item stands out immediately in the XML – there's no tolerance for "close enough" there.

Whoever already automates the splitting cleanly has essentially completed the e-invoicing transition. The data structure is the same; only another output format is added. Whoever keeps booking everything flat at 7% will feel the gap the moment the first corporate customer demands a ZUGFeRD invoice and the embedded VAT doesn't add up.

Bottom line

§14 splitting isn't optional polish – it's a requirement, and a reliable source of errors when done by hand. The data for the correct split already lives in the PMS; it just has to be processed consistently against fixed rules. Automating it doesn't only save time at night, it makes you audit- and e-invoicing-proof. It's exactly the kind of invisible work a hotel is better off setting up once correctly than redoing by hand every evening.