ED14 - Government Agency Interface Practice: ELSTER, DE-Mail, eXTra - Mediation by GitCover

Problem

Many government agency interfaces are regulated by law, but in practice are barely usable for laypeople:

• ELSTER: Complex, error-prone - the ELSTER interface requires certificates, XML formats, client software - a hurdle for laypeople
• DE-Mail: Discontinued - DE-Mail was planned as a secure communication channel with government agencies, but has been officially discontinued (last provider as of 31.12.2026). Archived emails in discontinued systems are no longer accessible - a GoBD-relevant retention problem
• eXTra: Unknown - the eXTra format (SV data) is for payroll offices, not for entrepreneurs - but it suddenly becomes relevant during a DRV audit
• Z3 data carrier: Specialized knowledge - the GoBD-compliant Z3 export requires specialized software or manual preparation
• Interface errors: Not documented - when ELSTER or DE-Mail fail, the error is not logged in the repo - the proof of "I tried" is missing
• Regulation binding: Not assigned - every interface submission is bound to a regulation (e.g., LStA → § 41a EStG), but this mapping is not documented

Core Message

The GitCover harness mediates between external systems and risk-affine regulations:

1. ELSTER mediation - LStA, UStA, LSt-Bescheinigung via the ELSTER interface; receipt as document with sidecar
2. DE-Mail: discontinued - migration required - historical DE-Mails must be migrated into the repo as EML + SHA-256 + sidecar before the shutdown; archived emails in discontinued systems are no longer accessible - a GoBD retention problem
3. eXTra/euBP export - SV data in eXTra format exportable for DRV audits
4. Z3 data carrier export - GoBD-compliant Z3 export for FA external audits (git bundle as self-contained archive)
5. Interface error logging - errors/aborts of external systems are logged as a repo event
6. Regulation binding - every interface transaction is mapped to the risk-affine regulation

Compliance by Design: The harness does not hide the complexity of the government agency interfaces - it documents it. Every submission, every receipt, every error is recorded traceably in the repo.

The Government Agency Interface Landscape

ELSTER Mediation

Regulation binding: Every interface transaction is mapped to the risk-affine regulation - e.g., LStA → § 41a EStG, UStA → § 18 UStG, LSt-Bescheinigung → § 41b EStG. This makes it traceable which regulation was fulfilled by which submission.

DE-Mail - Discontinued: Migration and Archiving Consequences

DE-Mail has been officially discontinued. The project is considered a failure. The last provider (FP Digital Business Solutions GmbH) will shut down the service on 31.12.2026 - after that, DE-Mail will no longer be usable and archived emails in these systems will no longer be accessible.

DE-Mail is history: The last provider (FP Digital Business Solutions GmbH) will shut down the service on 31.12.2026. The legal recognition as a secure means of transmission (§ 130a Abs. 4 Nr. 1 ZPO) was repealed on 22.12.2025. The federal administration discontinued the mandatory use in July 2024. In 2021, the Federal Court of Audit tallied: 6.5 million EUR in costs for ~3,500 EUR in savings. A "European Business Wallet (EBW)" is planned as the successor.

Consequences for archived emails in discontinued systems

When a DE-Mail provider discontinues its service, immediate GoBD-relevant retention problems arise:

Forensic evidence preservation - hardly recoverable afterwards: DE-Mail-specific evidentiary features (qualified electronic signature of the dispatch and access confirmation, provider timestamp, integrity hash value) can only be verified within the running provider infrastructure. After the shutdown, this verification data is no longer available. A layperson can no longer verify an exported EML file for its DE-Mail-specific authenticity after the fact - the signature verification fails due to the missing provider certificate, the timestamp server is offline, the provider logbooks are deleted. The email loses its status as "legally binding DE-Mail communication" and degenerates into a mere PDF copy with greatly reduced evidentiary value. Subsequent forensic evidence preservation by an expert would be theoretically possible, but practically hardly feasible - the required provider infrastructure data no longer exists.

Critical warning - migration before the shutdown: Entrepreneurs who still have a DE-Mail mailbox must export all relevant emails as EML files before the shutdown and migrate them into the Git repo (EML + SHA-256 + sidecar). After the shutdown, an export is no longer possible - the data is irretrievably lost. This is a GoBD violation if the retention period is still running (6 years from the end of the year, § 147 Abs. 1 Nr. 2/3 AO).

GitCover Migration: DE-Mail -> Repo

Practical tip: The migration should be carried out immediately, not only shortly before the shutdown. Providers may restrict the service ahead of time (e.g., no new registrations, restricted export). Those who wait risk data loss.

DE-Mail disaster mitigation: The harness warns when DE-Mail is used (if historical mailboxes still exist) and recommends immediate migration of all relevant emails as EML + sidecar into the repo. After the shutdown (at the latest 31.12.2026), the data is irretrievably lost - a GoBD violation if the retention period is still running. As an alternative for future communication: ELSTER inbox for tax matters, regular email + sidecar archiving for correspondence.

eXTra/euBP Export and Z3 Data Carrier

Practical example: During a company audit, the DRV requests SV data in eXTra format. The harness exports the relevant payroll and SV data from the repo as eXTra XML. During an external audit, the FA requests GoBD-compliant data (Z3) - the harness generates a git bundle + Static-Web (Z3+, see ED04). Both exports can be generated from the structured repo data (JSON, sidecars) - no manual preparation required.

Interface Error Logging

Important - liability shift: When an interface fails (e.g., an ELSTER timeout on the 10th of the month), the error logging in the repo documents that the entrepreneur tried to submit on time. This is evidence for § 152 AO (late filing surcharge) - the entrepreneur can argue that the error was not within their sphere.

Risk Leverage

Harness Requirements (Preview)

Derivable from ED14:

The complete list of requirements in Harness-Anforderungen.md.

Sources

• AO (§ 147 Abs. 6 - data access Z1/Z2/Z3, § 152 - late filing surcharge)
• EStG (§ 41a - wage tax return, § 41b - wage tax certificate)
• UStG (§ 18 - VAT advance return, § 14 - e-invoice)
• SGB IV (§ 28p - DRV company audit, § 28a - DEÜV notifications)
• GoBD (BMF letter, Rz. 147 - verifiability, Z3 data access)
• DE-Mail (Wikipedia, as of 14.08.2026) - "With this, De-Mail is history": Telekom 31.08.2022, 1&1 07.02.2025, § 130a ZPO repealed 22.12.2025, federal administration July 2024, FP Digital 31.12.2026, Federal Court of Audit 2021
• BGBl. 2025 I Nr. 349 - Act repealing § 130a Abs. 4 Nr. 1 ZPO (DE-Mail)
• Federal Court of Audit Annual Report 2021 - DE-Mail: 6.5 million EUR in costs, ~3,500 EUR in savings
• CCC 30C3 2013 - Linus Neumann: "Bullshit made in Germany"
• AFJD/agents/ (anonymized) - SSoT concept with ELSTER, interface error logging

Source Topology and CDN Reference Links

Note: This assignment of sources, mirror, and community hub reflects the current state and may change. Please check the respective canonical source on gitcover.org for the current state.