Skip to main content

Introduction

This section expands on the General Part with the information that is specific to the Austrian market (RKSV). It is only complete in combination with the General Part: get familiar with the general information first, then use the Austrian pages for the country-specific details. Chapters that need no Austrian specifics are omitted here.

What is required for the Austrian market​

Austria requires a POS system to fulfil three obligations. The fiskaltrust.Middleware covers all three; the pages linked below hold the details.

Signing cash transactions​

Every cash transaction must be recorded by a cash register with a tamper protection device that signs each transaction with a signature creation device and chains it to the previous receipt, so that the receipt chain cannot be changed afterwards (§131b Abs 2 BAO, §§9 and 10 RKSV); the requirements for the signature creation device itself are laid down in §§12 to 14 RKSV. In the Middleware, the Queue records and chains the receipts and the Signature Creation Unit (SCU) drives the signature creation device (SSCD).

See Cash Register Integration for Austrian specific details on the cash register integration.

Data collection log and exports (DEP-7)​

Every cash register must keep a data collection log (RKSV-DEP, also referred to as DEP-7 after §7 RKSV) of all cash transactions and be able to export it in the export format defined in the annex to the RKSV. In the Middleware the fiskaltrust.SecurityMechanism manages this log, and the fiskaltrust.Journal extracts it.

See Data Collection Log for the two logs kept in Austria (RKSV-DEP and E131-DEP). Records must be retained for seven years (§132 BAO); creating exports in the fiskaltrust.Portal is described in Exports, and the cloud-based storage options in Revision-safe archiving.

FinanzOnline notifications and validations​

The signature creation unit and the cash register must be registered with the tax authority through FinanzOnline, together with the AES key used to encrypt the cumulative sales counter (§16 RKSV). After the registration, the start receipt must be created from the POS and the start receipt validated with Finanzonline to check the signature creation and the encryption of the cumulative sales counter (§6 Abs 4 RKSV). Yearly receipts must be validated, SCU outages > 48h and the deregistration of an SCU and a queue. This can be achieved by using the fiskaltrust.Carefree or Notification subscription or manually - see FinanzOnline Management.

Where to start​

  1. Terminology - the Austrian terms and abbreviations used throughout these pages.
  2. Cash Register Integration - the receipt workflows, special receipts, receipt structure and data collection log your POS system has to implement.

The remaining Austrian pages - Data Structures, Receipt Case Definitions and Reference Tables - are references to use while implementing.

Upgrading to PosSystem API (v2)

New features such as eInvoicing are available exclusively through the PosSystem API (v2). If you are currently using the v0 interface (WCF/REST), see the Migrating from API v0 to PosSystem API (v2) guide.