Process documentation (Verfahrensdokumentation)

This documentation is aimed at Rechnungskit users and at the tax authorities and their auditors. It describes the process for outgoing invoices that are created and archived through the platform. Each user (the invoice issuer) remains responsible for the accuracy of the content of their documents and for their tax treatment.

Rechnungskit is a multi-tenant platform. Processing happens server-side in a secured environment. The core components are: the application and database layer (separated by tenant), a component that generates structured invoice data (ZUGFeRD/EN 16931), a component for PDF/A-3 generation, and an encrypted, immutable archive storage.

Invoice-relevant data comes from payments and orders received through connected payment services (including Stripe and Mollie) and shop systems, or from data entered manually. Incoming events are checked for signature or authenticity and assigned unambiguously to a transaction. Payments that cannot be assigned unambiguously are set aside for manual review and are not offset automatically.

When an invoice is created, a gapless, sequential invoice number is assigned within a database transaction. The invoice is locked as a complete, self-contained record (seller, buyer, line items, tax breakdown). If any step fails, the entire transaction is rolled back; no number is used up in the process, so no gaps arise.

A structured invoice in the ZUGFeRD/Factur-X format (EN 16931 profile) is generated from the record. Before archiving, the structured invoice is validated against the EN 16931 standard. Only an invoice that passes validation is archived; otherwise the process is stopped and flagged for review.

The human-readable view is generated as a PDF/A-3 with the structured invoice embedded in it (a hybrid ZUGFeRD document). The generated PDF is checked again. When needed, the view is derived reproducibly from the archived record.

The finalized invoice is stored encrypted in object storage with write protection (WORM, versioning). What is retained is the structured record (XML); the human-readable PDF/A-3 view is derived from it reproducibly when needed and is an identical copy in content. This is in line with the current version of the GoBD (BMF letter of 14.07.2025, para. 131), under which retaining the structured part is sufficient as long as the image part contains no additional tax-relevant information. Finalized invoices are neither changed nor deleted. Corrections are made exclusively through cancellation invoices (Storno) and new invoices. Immutability is additionally enforced at the database level by locks against changes and deletion.

For every archived invoice, cryptographic checksums (SHA-256) of the original and of the encrypted object are calculated and stored in the database. Every time the view is derived again, the checksum is verified against the stored value; if they differ, the process is stopped.

Access is limited to authenticated users of the respective tenant. Tenant separation is enforced at the database level (row-level security), complemented by a role-based permission model. Security-relevant actions are logged.

All systems are backed up automatically every day. The database and system configuration are encrypted on the client side and transferred to a geographically separate EU data center (Helsinki, Finland); the invoice archive is also mirrored there in encrypted form. The backup system is separate from the production system: the application has no access to the backups, and the backup credentials cannot change or delete production data. Backup integrity is checked automatically every day, and additionally spot-checked at the data level every week. Success checks run through monitoring; a missing backup triggers an alert. Recovery procedures are documented in writing; recovery drills are carried out and logged at regular intervals. For retention under § 147 AO, the versioned, immutable primary archive is what counts; the backups serve recovery only.

Documents are retained for the statutory retention periods (including § 147 AO and § 14b UStG). Users can export their archive data during the contract term and within the agreed period after the contract ends. Deletion only takes place after the retention periods have expired.

This process documentation is updated whenever the process changes materially. Each version is marked with its version number and date; earlier versions are kept for the retention periods, so the process in force at any given time remains traceable.