Starting with version 3.0, Receipts Space is designed for GoBD-compliant use (GoBD, as of July 14, 2025). Use of the software in conformity with the GoBD is particularly relevant for users in Germany.
User Interface Support
In the library settings, special audit compliance features can be activated. These tools are intended to simplify the proper filing of documents as described in the German GoBD.
When this function is activated, confirmed entries enjoy special protection: With the exception of tags, notes, and flags, all fields become read-only to prevent accidental or unwanted changes. If an entry is to be edited nevertheless, the write protection must be explicitly lifted – a step that is automatically logged.
A history can be viewed and exported for each entry at any time. This contains a comprehensible, chronological listing of all relevant changes. Previous versions of the data also remain traceable in this way.
The entire data inventory can be output via various export formats – including the unchanged original documents as they were originally imported.
Technical Implementation of Requirements
The architecture of Receipts uses a tamper-proof local-first approach, which technically underpins the central requirements of the GoBD:
1. Immutability
Every change to data is stored as a transaction in a continuous log (append-only). Simple “overwriting” is not possible due to the system design.
- Transaction Chaining: Each transaction file contains the SHA256 hash of its predecessor file (field
p). This creates a cryptographically secured chain. - Integrity Protection: Subsequent manipulation of old transactions (e.g., in the file system) would change the hash value and break the chain. This is detected by the system during the integrity check.
2. Traceability and Verifiability
- Gapless Journal: Every business transaction (creation, editing, deletion) generates a new entry in the transaction log with a timestamp (
t) and version number (_v). - History: The state of a data record can theoretically be reconstructed at any point in time (progressive and retrograde auditability).
- Logging: If an already “confirmed” entry is edited subsequently, this generates a new log entry that transparently documents the change.
3. Machine Evaluability and Data Security
- Asset Integrity: File attachments (receipts) are stored immutably (content-addressable storage). Integrity is ensured by SHA256 checksums in the reference.
- Format: The data is available in the open, documented JSON/JSONL format. This ensures long-term readability and enables data access independent of the application (Z3 access).
- Encryption: Optionally, workspaces can be fully encrypted (AES-256-GCM), whereby the verifiable chaining of transactions is preserved even in the encrypted state.
Limitations and User Obligations
Software alone can never be fully “GoBD-compliant”; it is merely a tool for fulfilling the requirements. The legally secure compliance with the GoBD is always the responsibility of the taxpayer and requires organizational measures. The following points must be particularly observed by the user:
- Procedural Documentation: The user must create their own procedural documentation describing how receipts are received, digitized, processed, and archived in the company (cf. margin no. 151 et seq. GoBD). The technical documentation provided here can serve as a technical part (appendix) but does not replace the description of operational processes.
- Internal Control System (ICS): It is the user’s responsibility to organize access rights and responsibilities and to establish control mechanisms (e.g., dual control principle) to prevent errors or manipulation.
- Data Backup: Since Receipts Space operates on the “local-first” principle, data is primarily stored on the user’s devices. The responsibility for regular, audit-proof backups and ensuring the long-term availability of data/hardware lies with the user. Pure synchronization does not replace an independent backup concept against data loss (e.g., through ransomware).
- Timely Recording: The technical logging merely documents the time of entry into the system. It cannot cure receipts being digitized late (i.e., not promptly after creation/receipt). Organizational workflows must ensure timeliness (cf. margin no. 45 et seq. GoBD).
- Dependence on System Time: The logging of timestamps in transactions relies on the system time of the recording device. Since no central server instance authoritatively dictates time in the “local-first” approach, traceability relies on the correct setting of end devices. Deliberate manipulation of system time by the user cannot be completely prevented by software and must be prevented by administrative restrictions on the operating system.
- User Assignment: In collaborative environments, the log identifies the changing instance via a unique
clientId(device ID). To meet the requirement of determining the responsible editor (margin no. 100 GoBD), the user must organizationally ensure that there is a unique assignment of devices or user profiles to natural persons (e.g., through personalized Windows/macOS user accounts).
Legal Notice and Disclaimer
The functions implemented in Receipts Space support the user as best as possible in complying with GoBD specifications. However, the final responsibility for the proper keeping and preservation of books, records, and documents lies solely with the taxpayer in accordance with § 146 AO.
We expressly assume no liability for the complete fulfillment of all legal requirements in individual cases and are not liable for tax disadvantages, estimated assessments, or fines resulting from the use of the software, incorrect configuration, or inadequate organizational accompanying measures. An official official certification of the software does not exist, as the tax administration itself does not issue software certificates and third-party certificates have no binding effect (cf. Section 12 GoBD). We urgently recommend coordinating the concrete use of the software and the created procedural documentation with a tax advisor.