Comprehensive Expert Analysis of German Fiscal Compliance for Property Management Systems Integrating fiskaltrust Middleware and Cloud-Based Technical Security Systems

The regulatory landscape governing electronic recording systems in Germany has undergone a profound transformation since the enactment of the Act on Protection against Manipulation of Digital Basic Records in late 2016. For operators of Property Management Systems (PMS) that incorporate Point-of-Sale (POS) functionalities, navigating the intersection of the German Fiscal Code (Abgabenordnung, AO), the Cash Register Security Ordinance (KassenSichV), and the Principles for the Proper Management and Storage of Books, Records, and Documents in Electronic Form (GoBD) is no longer an optional administrative task but a foundational requirement for legal operation. This report provides a detailed examination of a system utilizing the fiskaltrust Sorglos Cloud Cashbox in conjunction with a Fiskaly Technical Security System (TSE), specifically addressing the nuances of balance management and the legality of digital-only reporting structures.

The Evolution of § 146a AO and the KassenSichV Framework

The primary legal pillar of German fiscal compliance is Section 146a of the Abgabenordnung, which mandates that all electronic recording systems used to document business transactions must record every transaction individually, completely, correctly, timely, and in an orderly manner. To prevent the subsequent manipulation of these digital records, the law requires that such systems be equipped with a certified Technical Security System (TSE). The KassenSichV, which came into full effect on January 1, 2020, provides the technical specifications for these requirements, defining the mandatory components of a TSE: a security module, a storage medium, and a digital interface.

For integrated systems where a PMS handles room bookings and a small POS handles on-site hospitality or retail sales, the entire ecosystem must be evaluated as an electronic recording system (Elektronisches Aufzeichnungssystem). The transition period for systems that were not technically capable of being retrofitted with a TSE ended on December 31, 2022, meaning that as of 2023, every active system must be fully compliant with the KassenSichV standards. The system under review, which utilizes a cloud-based TSE provided by Fiskaly and managed via the fiskaltrust middleware, represents the modern standard of “Compliance-as-a-Service,” shifting the burden of technical maintenance from the hotel operator to specialized service providers.

Regulatory Component	Primary Objective	Key Implementation Requirement
§ 146a AO	Manipulation protection	Mandatory use of a certified TSE.
KassenSichV	Technical standardization	Definition of TSE components and receipt data.
GoBD	Orderly bookkeeping	Immutability, completeness, and traceability.
DSFinV-K	Audit efficiency	Standardized digital interface for data export.

Technical Architecture of the fiskaltrust Sorglos Cloud Cashbox

The use of the fiskaltrust Sorglos Cloud Cashbox indicates a sophisticated middleware strategy. The “Sorglos” (carefree) package is designed to provide POS creators and operators with an all-encompassing solution that handles receipt signing, sequential numbering, and long-term archiving in a revision-safe manner. In this architecture, the middleware acts as a secure buffer between the PMS application and the TSE.

The Role of the CashBox and Queue Mechanism

The CashBox is a logical configuration container within the fiskaltrust portal. It defines how the various components—the Queue, the Signature Creation Unit (SCU), and the TSE—interact. The Queue serves as the entry point for the PMS to send its transaction data. Each transaction sent to the Queue is hashed, assigned a unique, up-counting number, and linked to the previous transaction, creating a cryptographically secure chain.

The specific serial number provided, WqK0pGTB0eSazQFMgKXuA, corresponds to the ftCashboxIdentification. This is a unique, Base64-encoded identifier that is required to be printed on receipts or encoded in a QR code. It allows tax auditors to trace a specific receipt back to a unique logical recording system within the operator’s infrastructure. The “Cloud” designation means that this entire middleware stack is hosted in high-availability data centers (such as Microsoft Azure), ensuring that the fiscal logic is consistently updated and available without the need for local server maintenance.

Fiskaly as a Cloud-Based Technical Security System

The selection of Fiskaly as the TSE provider is a critical element of the compliance profile. Fiskaly offers a 100% cloud-based TSE that is fully certified by the Federal Office for Information Security (BSI). Unlike hardware-based TSEs (USB sticks or SD cards), which are susceptible to physical theft or failure, a cloud TSE ensures that transaction logs are stored in a distributed, secure environment. The “Commissioning Date” of 2025-07-22 indicates a system that is operating under the latest certifications and is prepared for the rigorous reporting requirements that come into full effect in mid-2025.

Balance Management and GoBD Compliance

The user’s system utilizes different “balances” to categorize payment flows, such as a specific balance for in-person payments. This methodological separation of payment streams is highly aligned with the GoBD principles of order and clarity.

Categorization and Traceability

Under the GoBD, a primary requirement is that business transactions must be traceable from their inception to their final entry in the financial statements (the “Belegfunktion”). By creating a dedicated balance for in-person payments, the system facilitates “Kassensturzfähigkeit”—the ability of a tax auditor to conduct an unannounced cash count and compare the actual cash on hand with the electronic records. The separation of online payments (which are often processed by third-party gateways) from in-person cash or card payments ensures that the electronic ledger accurately reflects the physical reality at the point of sale.

The “Autoclose” functionality mentioned in the balance management documentation is particularly relevant for the GoBD’s “Zeitgerechtheit” (timeliness) requirement. Cash transactions should ideally be recorded on a daily basis to prevent the loss of data or the potential for retrospective manipulation. Automated daily closures that are sent to fiskaltrust provide an additional layer of security, as the closure event itself is a signed transaction that resets the daily counters and archives the day’s totals in a tamper-proof state.

Balance Type	GoBD Relevance	Compliance Benefit
In-Person Cash	Kassensturzfähigkeit	Enables real-time verification of physical cash vs. digital records.
Online Payments	Clear Separation	Prevents mixing of processed funds with physical cash flows.
Autoclose Daily	Timeliness	Ensures records are finalized and signed within legal timeframes.

Legal Validity of the Digital-Only Reporting Environment

A central question posed is whether the inability to download Z-reports and X-reports as files—instead viewing them only within the application—affects the system’s compliance. To address this, one must look at the transition from paper-based auditing to digital-first auditing in German tax law.

The Shift from Z-Receipts to DSFinV-K Exports

Traditionally, the “Z-Bon” or Z-receipt was the most important document for daily revenue verification. It represented the final daily total and the zeroing of the register. However, with the introduction of the DSFinV-K (Digital Interface of the Tax Administration for Cash Register Systems) and the TSE, the legal emphasis has shifted from the visual report to the underlying data.

The DSFinV-K is a standardized data format that every electronic recording system must be able to export. It contains several modules, including the “Kassendatenabschluss” (Cash Data Closing) module, which captures exactly the same information as a traditional Z-report—totals per tax rate, payment methods, and counter status—but in a machine-readable format (CSV or JSON).

Machine Evaluability and Data Access (Z1, Z2, Z3)

Under § 147 AO and the GoBD, the tax authority has the right to three types of data access:

1. Z1 (Unmittelbarer Datenzugriff): The auditor uses the taxpayer’s software to view the records.
2. Z2 (Mittelbarer Datenzugriff): The taxpayer provides the data through evaluations requested by the auditor.
3. Z3 (Datenträgerüberlassung): The taxpayer provides a machine-readable data export.

Because the system allows the user to view the Z-report and X-report within the application, it fulfills the “Z1” requirement. Because the system allows the download of a DSFinV-K export, it fulfills the “Z3” requirement, which is the gold standard for modern audits. In fact, many modern tax auditors prefer the DSFinV-K export over a collection of PDF Z-reports because the export can be directly ingested into their audit software (such as IDEA) for automated cross-referencing with individual transaction logs. Therefore, the absence of a Z-report “download” button is not a compliance failure; the data is being archived and provided in the more legally robust DSFinV-K format.

The Receipt Issuance Obligation and 2024 Standards

Since January 1, 2020, the Belegausgabepflicht (receipt issuance obligation) has been a central tenet of the KassenSichV. Every transaction must result in a receipt that is offered to the customer. As of January 1, 2024, the requirements for the content of these receipts have become even more specific.

Mandatory Data Points on the Receipt

A compliant receipt in 2024 must include specific identifiers for both the recording system and the technical security device. The system under review generates these through the fiskaltrust middleware and Fiskaly TSE.

Mandatory Field (2024)	Description	Source in fiskaltrust/Fiskaly
Operator Name/Address	Full details of the business.	Master Data in Portal.
Date and Time	Start and end time of the transaction.	time_start, time_end.
Amount and Description	Items sold and the applicable tax rates.	PMS Transaction Data.
ERS Serial Number	Identifier of the recording system.	ftCashboxIdentification.
TSS Serial Number	Unique ID of the security module.	tss_serial_number.
Signature Counter	Consecutive number of the signature.	TSE Log.
Check Value	Digital signature of the transaction.	signature.value.

The law allows these technical details (TSE serial number, signature, etc.) to be provided as plain text or as a QR code. The tax authorities strongly recommend the QR code solution, as it facilitates the unannounced “Kassen-Nachschau” (cash inspection), where an official can quickly scan the code to verify that the transaction was recorded in the TSE in real-time. Since the user’s system is a cloud-integrated PMS, it likely generates digital receipts or print-ready receipts via the fiskaltrust API that include these required elements.

DSFinV-K: The Standard for Digital Audits

The user noted that a DSFinV-K export can be downloaded from the fiskaltrust app within the PMS. This is the single most important technical feature for ensuring audit compliance. The DSFinV-K ensures that the data is structured in a way that is independent of the specific software vendor, allowing for a standardized review process across all industries in Germany.

Modules of the DSFinV-K Export

A typical DSFinV-K export from the fiskaltrust system consists of several interlinked CSV files, typically categorized into three blocks:

• The Individual Record Module: This contains the bonkopf.csv and bonpositionen.csv, documenting every item sold and every change made to a transaction.
• The Master Data Module: This includes information about the location, the specific cash registers, and the tax rates applied.
• The Cash Data Closing Module: This module is what replaces the traditional Z-report. It summarizes all transactions, payment methods, and VAT totals for the daily closing period.

The fact that this export is available means the system is “audit-ready.” During a “Kassen-Nachschau” or a full external audit, the taxpayer is often given a very short window (sometimes 24-48 hours) to provide this specific export. Having it accessible directly within the PMS application is a significant compliance advantage.

Long-Term Data Retention and Revisions-Sicherheit

The GoBD mandates that all tax-relevant data must be stored for ten years (or eight years for certain vouchers) in a way that is “revisionssicher”—meaning it must be impossible to change the data without leaving a permanent record of the modification.

The Role of the fiskaltrust PosArchive

The fiskaltrust Sorglos package includes the “PosArchive,” which is a centralized, cloud-based storage system designed specifically to meet these national retention rules. When the user creates a daily closure, the data is not just shown in the app; it is transmitted to the PosArchive, where it is hashed and stored in a tamper-evident manner. This ensures that even if the PMS provider were to go out of business or the hotel were to change its local IT infrastructure, the fiscal data remains available and verifiable for the duration of the ten-year retention period.

New Reporting Obligations for 2025

A critical upcoming requirement that the user must be aware of is the mandatory reporting of all electronic recording systems to the tax office, which begins in earnest in 2025. This is mandated by Section 146a (4) of the Abgabenordnung.

Registration Requirements and Deadlines

Businesses must register their POS systems through the official ELSTER portal or via an integrated API. The system described by the user, having a commissioning date in July 2025, falls directly into the primary enforcement window.

Event	Reporting Deadline	Information Required
Initial Commissioning	Within one month.	Name, Tax ID, ERS Serial, TSE Serial.
System in use before July 2025	By July 31, 2025.	All technical identifiers of the existing stack.
Decommissioning	Within one month.	Date of removal and final transaction log.

The “Sorglos” package and the Fiskaly integration are designed to provide these reporting details easily. The serial number WqK0pGTB0eSazQFMgKXuA (the ftCashboxIdentification) and the Fiskaly TSE serial number are the primary identifiers that must be submitted to the tax office. Failure to register can be considered an administrative offense, potentially leading to fines of up to €25,000.

Synthesis of Compliance: The Verdict on the System

To determine if the system is legally compliant, we evaluate it against the four primary legal requirements of the German fiscal system.

1. Protection Against Manipulation (§ 146a AO)

The system uses a certified cloud TSE (Fiskaly) and a certified middleware (fiskaltrust). Every transaction is digitally signed, and the sequence is cryptographically chained. The provided serial number and commissioning date indicate a modern, certified setup. This requirement is Fully Satisfied.

2. Standardized Export (DSFinV-K)

The user explicitly states that a DSFinV-K export can be downloaded. This fulfills the obligation to provide a standardized digital interface for tax audits and unannounced inspections. This requirement is Fully Satisfied.

3. Orderly Bookkeeping and Archiving (GoBD)

The system manages separate balances, uses an automated daily closure, and archives data in a revisions-sicher cloud archive (fiskaltrust PosArchive). The “view only” nature of Z-reports is permitted as long as the “Z3” data access (DSFinV-K) is available. This requirement is Fully Satisfied.

4. Receipt Issuance (KassenSichV)

The integration allows for the creation of receipts with the mandatory TSE data. As long as these receipts are offered to the guest (either in print or digitally with their consent), the requirement is met. This requirement is Satisfied.

Procedural Documentation: The Missing Link

Докато technical components of the system are compliant, legal compliance also depends on the operator’s actions. The most frequent deficiency found during audits is the lack of a “Verfahrensdokumentation” (procedural documentation).

The GoBD requires that every business maintain a document that describes the entire electronic accounting process. This must include:

• A description of the system architecture (PMS + fiskaltrust + Fiskaly).
• The organization of the balances (In-person vs. Online).
• The internal control system (who has access, how errors are corrected, how daily closures are verified).
• The technical details of the TSE (serial numbers, certificate validity).
• The procedure for data archiving and retrieval.

Because the system is “Sorglos Cloud” and cloud-TSE based, the operator can rely heavily on the technical documentation provided by fiskaltrust and Fiskaly for the system-specific sections. However, the internal business processes (the “organizational” part) must still be documented by the hotel operator.

Detailed Analysis of the Daily Closure Mechanism

The user’s description of the “automatic daily closure” being sent to fiskaltrust is a critical compliance feature. In the context of the KassenSichV, a daily closure is more than just a summary of sales; it is a “Sicherungsbeleg” (security receipt).

Zero-Receipts and Closing Logs

When a daily closure is performed in the fiskaltrust system, the middleware often generates a “Zero-Receipt” (Nullbeleg). This is a specialized receipt that contains no items or payments but triggers a state change in the TSE, finalizing the current sequence of transactions. This event is then recorded in the “ActionJournal” of the fiskaltrust portal. For the auditor, the consistency between the PMS’s reported daily totals and these cryptographically signed “Zero-Receipts” in the fiskaltrust journal is proof that the system has not been manipulated to “hide” transactions between shifts.

Implication of the Serial Number Format

The serial number eg. WqK0p……. follows the standard format for the ftCashboxIdentification. This alphanumeric string is the Base64 encoding of the internal CashBox ID. In the event of a tax inspection, the auditor will scan the QR code on a receipt and expect to see this identifier. They will then match this identifier with the DSFinV-K export’s cashregister.csv file, specifically the KASSE_SERIENNR field. The fact that this information is clearly visible within the PMS application ensures that the operator can provide it immediately upon request during a “Kassen-Nachschau.”

Conclusion and Actionable Recommendations for Campsites

Based on the technical configuration described, the system is legally compliant with the current German fiscal regulations. The combination of the fiskaltrust Sorglos Cloud Cashbox and the Fiskaly cloud-TSE addresses the requirements for manipulation protection, standardized reporting, and long-term archiving. The absence of a downloadable PDF format for Z-reports and X-reports does not constitute a legal violation, as the system provides the required “Kassendatenabschluss” data via the more rigorous DSFinV-K export.

To maintain this compliance and prepare for future audits, the following steps are recommended for campsite owners:

• Compile a Procedural Documentation: The campsite has to integrate the technical specifications of the fiskaltrust Cloud Cashbox and Fiskaly TSE into a comprehensive GoBD-compliant procedural document. An example of a document can be found тук.
• Reporting ELSTER Portal: Log in to the fiskaltrust portal to retrieve the precise activation dates and serial numbers required for the ELSTER reporting process. Ensure that, you as a campsite, the system is registered with the local tax office.