RKSV, in full.
Section by section.
RKSV compliance means a receipt cycle with deadlines, filings and an audit trail. This page states, for every one of them, what SUMWARE does automatically, what your business contributes once, and where the evidence sits. So that choosing a POS does not wait on a call back from your tax advisor.
Legal basis: § 131b BAO (Austrian Federal Fiscal Code) and the Registrierkassensicherheitsverordnung (RKSV, the Austrian cash register security regulation), §§ 6 to 17. Germany has this page's twin: KassenSichV with TSE and DSFinV-K.
What signs, and who registers it.
Every tax advisor asks the same opening question: signature card or HSM, and who files it with FinanzOnline. Here is the answer before it gets asked.
- Signature creation unit
Signing from the cloud, or from the building.
By default SUMWARE signs through the fiskaltrust SignatureCloud, registered as a signature unit of the type HSM service provider. That leaves no signature card in the register and no HSM in the back office. Prefer to keep signing inside the building and you can: providers such as fiskaltrust and EFSTA supply a local signature unit for Austria too, and SUMWARE runs on either.
- Registration under § 6
Register and signature unit are filed before the first receipt.
Registering the signature unit and the register with FinanzOnline is handled by the signature provider during setup. SUMWARE supplies a data sheet with the register identification number, certificate serial number and user key, for your records and for your tax advisor.
- Provider choice
The fiscal layer is an adapter, not a foundation.
The legal regime resolves per store from the country code: Austria signs under RKSV, Germany under KassenSichV. Switching signature providers therefore stays a configuration exercise instead of a platform migration.
The location decides which route fits. A local signature unit keeps signing when the line is down, which makes it the choice for valley stations, basement depots and anywhere the connection is unreliable. The trade is hardware on site, to be procured, maintained and replaced when it fails. The cloud route saves card readers and on-site maintenance, and it earns its keep across many well-connected locations. We weigh that up with you during the project, and the decision stays open per store.
Five receipt types. Four of them run themselves.
Monthly and annual receipts top the list of audit findings, because they fall due on an evening when nobody is thinking about the register. In SUMWARE a schedule creates them, and a second run the next morning checks that the receipt is really there.
| Receipt | RKSV | When it is due | How SUMWARE does it |
|---|---|---|---|
| Start receipt | § 8 | When a register or signature unit goes into service | One click in SUMWARE. Verification reaches FinanzOnline within a week. |
| Zero receipt | § 9 | As a function check and after a signing outage | One click, no revenue impact. Confirms the chain is closed again. |
| Monthly receipt | § 9 | At least once per calendar month | Automatically at 22:00 on the last day of the month, with a control run at 07:30 on the first. |
| Annual receipt | § 9 | For December, verified by 15 February | Automatically on 30 or 31 December, with a control run on 1 January. |
| Closing receipt | § 8 | When a register is taken out of service | Deliberately manual, because the step cannot be undone. |
A period receipt created late carries its actual creation date, never a backdated one. SUMWARE rejects a duplicate, so the data collection log holds exactly one monthly receipt per calendar month.
What gets filed, when, and through which channel.
Start and annual receipt verification run straight out of SUMWARE through the FinanzOnline web service, with nobody opening a portal session. The remaining filings have no web service, so we hand you the data ready to submit.
| Filing | RKSV | Deadline | Channel |
|---|---|---|---|
| Registration of signature unit and register | § 6 | Before the first receipt | Signature provider during setup, data sheet from SUMWARE |
| Start receipt verification | § 8 | One week after going into service | From SUMWARE through the FinanzOnline web service |
| Annual receipt verification | § 9 | By 15 February of the following year | From SUMWARE through the FinanzOnline web service |
| Outage beyond 48 hours, return to service | § 17 | One week | FinanzOnline portal, with timestamps and identifiers from the SUMWARE log |
| Taking a register or signature unit out of service | § 6 | One week | FinanzOnline portal, no web service is provided for this |
Regular sales receipts, the monthly receipts from January through November and the closing receipt itself are not filed at all. They live in the data collection log and are produced when the tax authority asks for them.
The evidence is ready before anyone asks.
- RKSV § 7
DEP export
The data collection log (Datenerfassungsprotokoll) is kept chronologically and tamper-evident, and exports at the press of a button as ZIP, JSON or TXT. A monthly archive run files the previous month automatically. Retention is seven years.
- RKSV § 7
Hash chain
A SHA-256 chain runs across every receipt. Chain head and verification are available as their own queries, so a gap becomes visible instead of disappearing into a file.
- RKSV § 10
Machine-readable code
Every signed receipt carries the QR code with the signed receipt data and the chaining value to the previous receipt. Anyone can verify it with the tax authority Belegcheck app on a phone, with no involvement from us.
- RKSV § 16
Spot checks
Self-verification runs either through the Belegcheck app or programmatically through the FinanzOnline web service. Both routes query the same tax authority database.
Signing is down. The register keeps selling.
On arrival Saturday at 8:00 the line is out the door, and that is exactly when a blocked register is the most expensive mistake software can make. So SUMWARE chooses the sale and documents the outage, instead of refusing the receipt.
- 01
The sale completes
When signing fails, SUMWARE does not block the receipt. It is issued and carries the prescribed note "Sicherheitseinrichtung ausgefallen" (security device out of service) in the signature field.
- 02
The outage is logged
Every failed attempt lands in the fiscal log with a timestamp, store and register. That is where the outage timestamp for the filing comes from, instead of somebody reconstructing it from memory.
- 03
Monitoring picks it up
The fiscal status light checks the most recent sales receipt per store for a valid signature and recognizes the outage signature on its own. The state gets reported, not just the complaint.
- 04
A zero receipt closes the chain
As soon as the signature unit responds again, a signed zero receipt confirms the restart. It doubles as the evidence of the moment clean signing resumed.
- 05
Past 48 hours it gets filed
An outage lasting more than 48 hours must be filed with FinanzOnline within one week under § 17, and so must the return to service. SUMWARE supplies the data for both.
One distinction matters for valley stations and basement depots: selling does not depend on the internet line. The store server sits in the building, registers talk to it over the LAN, and cart, master data and stock stay available locally. Whether signing continues too is down to the signature unit you chose: a local one signs straight through, a cloud one resumes with the line.
Who does what.
-
SUMWARE handles
- Signing every cash transaction, including voids, paid-ins and paid-outs
- Start, zero, monthly, annual and closing receipts with duplicate protection
- Deadline automation for monthly and annual receipts, plus a next-day control run
- Start and annual receipt verification through the FinanzOnline web service
- DEP export, hash chain and receipt archive
- Fiscal monitoring per store, with status light and log
-
Your business handles
- Creating a web service user in FinanzOnline once and passing us the credentials
- Scanning the start receipt once with the Belegcheck app
- Leaving the register switched on when a period receipt is due
- Filing the decommissioning of a register in the FinanzOnline portal
-
Your tax advisor receives
- The manufacturer declaration for the POS software
- The GoBD and RKSV dossier with evidence per requirement
- A template for the procedural documentation
- The audit trail from a single receipt through the chain to the DEP export
The register rests over summer. The deadlines do not.
Monthly and annual receipts follow the calendar, not the season. Shut the register down in April and open it again in November, and seven due dates pass with no system running. We settle that point before go-live together with your tax advisor, and we keep a dormant instance available that carries period receipts and data retention through the summer.
See season billing and pricing →Show this page to your tax advisor.
If a question stays open, we answer it in conversation and in writing. The full evidence dossier, with the manufacturer declaration, the procedural documentation and evidence per requirement, is public.