Austria RKSV fiscalization Usage Guide

Creating a Fiscal Invoice

Invoices are the documents that go through RKSV fiscalization - they are cryptographically signed by Fiskaly and reported to FinanzOnline. A fiscal invoice is created directly from a guest reservation folio:

1. Open the reservation and navigate to the Folio tab.
2. Ensure the guest has a recorded payment (a payment entry with a green Cash or equivalent badge will appear).
3. Click the Add button ➕ at the top right of the folio.
4. Select Generate receipt from the dropdown.
5. Cloudbeds sends the invoice data to Fiskaly, which signs it in real time and attaches the signed document to the reservation.

Automated Invoice Creation

Cloudbeds can generate and fiscalize invoices automatically, without any manual action from front desk staff. When enabled, the system triggers the complete RKSV fiscalization pipeline behind the scenes — fetching required fields, generating the QR code, and rendering the signed invoice — as soon as the configured event occurs.

To configure automated invoice generation:

1. Go to Settings ->Finance-> Invoices and Documents and select the Invoice tab.
2. Under Invoice Settings, locate the Generate Invoice radio button and select Automatically.
3. A second dropdown appears: When to automatically generate an invoice. Select the trigger that fits your property’s workflow (see options below).

Automation trigger options:

• At check-out — The invoice is created and submitted to Fiskaly for fiscalization automatically when a reservation is checked out. This is the recommended option for most Austrian properties: staff simply perform the check-out and the signed RKSV invoice is generated without any additional steps.
• When a payment is allocated — The invoice is generated automatically when a payment is recorded and allocated against the reservation folio. This option suits properties that collect payment before check-out (for example, advance-payment or OTA pre-paid workflows). Note: the interaction between this trigger and RKSV invoice content (specifically the cash/non-cash payment split) should be verified with your Cloudbeds account manager before enabling.

Once the trigger fires, Cloudbeds handles the entire fiscalization pipeline automatically: it sets all required RKSV fields, sends the invoice to Fiskaly for cryptographic signing, embeds the QR code, and stores the finished document in the reservation’s Documents tab — no staff action required. The signed invoice is available to view and send to the guest as soon as it appears.

Viewing Fiscal Documents

All signed fiscal documents are stored in the Documents tab of the reservation:

1. Open the reservation and click the Documents tab.
2. Each document is listed with its type, reference number, amount, creation date, and status.
   
   The RKSV document reference format is:

Example: RSKV-107-SUFFIX, RSKV-108-SUFFIX

Document Statuses

Invoices and Credit Notes

Invoices and credit notes are the two document types that go through RKSV fiscalization. The integration automatically manages the relationship between them:

• Invoice: When a guest checks out and an invoice is created via Create invoice, Cloudbeds sends it to Fiskaly for real-time signing. The signed invoice is stored in the Documents tab.
• Credit Note: If the invoice needs to be corrected or the guest is refunded, a Credit Note is generated to offset the original invoice. The credit note is also RKSV-signed. The original invoice is then marked Voided.

Payment receipts (created via ‘Generate receipt’) are separate documents used to acknowledge a payment. They are not fiscalized and do not carry an RKSV signature.

Cash vs. Non-Cash Payment Split

Legal basis

The RKSV (Registrierkassensicherheitsverordnung) was enacted specifically to secure cash transactions against manipulation and tax evasion. The companion regulation, the Barumsatzverordnung 2015 (Cash Revenue Ordinance), defines what constitutes a “Barumsatz” (cash revenue): it includes not only physical banknotes and coins but also payments by debit card, credit card, cheque, and voucher. In other words, the legal definition of “cash” under Austrian fiscal law is broader than everyday usage — it covers any payment made at the point of transaction, as opposed to deferred payments such as bank transfers or OTA pre-payments settled outside the property.

Despite this broad definition, the RKSV mandates that the cash amounts per VAT rate be cryptographically signed and embedded in the QR code on every receipt. This is what the tax authority verifies during an audit: the signed hash of each transaction includes the breakdown of cash revenue across each VAT bucket (standard 20%, reduced 10%, reduced 13%, special, zero). Non-cash revenue — amounts received by bank transfer, OTA settlement, or pre-payment outside the cash register system — is excluded from the QR code signature and declared separately on the face of the invoice.

What goes into the QR code

The Fiskaly SIGN AT API signs each invoice using the SCU. The signed payload includes, for each VAT rate bucket, the cash gross amount at that rate. There are five buckets:

• STANDARD — 20% VAT (standard rate; applies to most hotel services other than accommodation)
• REDUCED_1 — 10% VAT (reduced rate; applies to accommodation/room rate in Austria)
• REDUCED_2 — 13% VAT (second reduced rate; applies to certain food and cultural services)
• SPECIAL — special rate container (e.g. 4.9% from July 2026 onwards)
• ZERO — 0% VAT (zero-rated supplies)

Each bucket has a default value of €0.00. For a fully non-cash invoice — which is the typical case for hotel guests paying by card, bank transfer, or through an OTA — all five buckets remain at €0.00 in the signed QR code. This is legally correct: a €0.00 cash signature confirms the transaction was processed through the RKSV system with no cash component. The full invoice amount is still printed on the document, but only the cash portion is cryptographically signed. For a cash-paying guest, the relevant bucket is populated with the actual amount so that the tax authority can verify it against the signed hash on the QR code.

Explicit payment-type declaration on the invoice

Beyond what goes into the QR code, the Fiskaly SIGN AT API also requires an explicit declaration of how the invoice was settled, expressed as one or more entries of type CASH or NON_CASH with the corresponding amount. This payment-type field is separate from the VAT buckets above — it is visible on the printed invoice as the Cash / Non Cash summary line and provides the human-readable counterpart to the QR code. The two values must be consistent: if the payment-type declaration says €159.00 NON_CASH, the QR code VAT buckets will all be €0.00; if it says €159.00 CASH, the appropriate VAT bucket will carry €159.00 in the signed hash.

Practical summary for hotel properties

For most Austrian hotel properties the overwhelming majority of reservations are settled by card, bank transfer, or OTA pre-payment — all of which are NON_CASH. In these cases the five VAT-bucket values in the QR code will always be €0.00, and the invoice will show “Non Cash: €[total]” on its face. This is fully compliant with RKSV. The signed €0.00 QR code confirms that the cash register processed the transaction and found no cash component — precisely what the tax authority expects for a card or OTA payment.

Cloudbeds reads the payment method recorded in the folio at the moment of invoice creation and passes the correct CASH or NON_CASH declaration to Fiskaly. No manual entry is required. The cash/non-cash line visible on the printed or PDF invoice is the human-readable output of this automatic classification.

Emailing Documents to Guests

To send a fiscal document to a guest:

• In the Documents tab, locate the document you wish to send.
• Click the three-dot menu (⋯) next to the document.
• Select Email and confirm the recipient address.

Automated Period Closings

RKSV requires that a special signed closing receipt be generated at the end of each day, month, and year. These are legally mandatory closing documents that seal the fiscal record for the respective period and are submitted to the tax authority.

Fiskaly automates all three period closings on behalf of Cloudbeds. No manual action is required from your staff:

• End-of-Day: End-of-Day closing (Tagesabschluss) — automatically generated at midnight each day. Seals the daily fiscal chain and confirms no tampering has occurred since the last closing.
• End-of-Month: End-of-Month closing (Monatsbeleg) — automatically generated on the last day of each month. Required by RKSV and submitted to FinanzOnline as part of the monthly fiscal record.
• End-of-Year: End-of-Year closing (Jahresbeleg) — automatically generated on 31 December each year. This is the most important periodic closing under Austrian law and is verified by the BMF. Fiskaly generates, signs, and archives it without any action needed from the property.

Compliance & Audit Notes

The following information is recorded in every fiscally signed document and is available for tax authority inspection:

• Unique document number (RSKV-XXX-SUFFIX)
• Property’s registered Cash Register serial number
• Cryptographic signature chain from the Signature Creation Unit (SCU)
• QR code for offline verification by the tax authority
• VAT breakdown by rate (e.g., 20%, 0%)
• Payment method split — Cash and Non Cash amounts declared separately as required by RKSV
• Automated end-of-day, end-of-month, and end-of-year closing documents — generated and archived by Fiskaly without staff intervention.
  

Troubleshooting