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 Operation Modes for the components and the supported signature creation devices, and Cash Register Integration for the receipt workflows, including the zero-amount receipts the RKSV requires (start, monthly, annual, end-of-failure and stop receipt) and the handling of signature creation device failures.

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) and RKSV-DEP Export for the corresponding journal call. 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. Operation Modes - the Middleware components, the signature creation devices and the configuration scenarios to choose from.
  3. Installation - installing the chosen signature creation device.
  4. 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, Function Structures, Communication, 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.