ED20 - Authority Interface Practicalities: ELSTER, DE-Mail, eXTra - Mediation via GitCover

Problem

Many authority interfaces are legally regulated, but in practice barely usable by 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 authorities, but has officially been discontinued (last provider until 31.12.2026). Archived emails in discontinued systems are no longer accessible - a GoBD-relevant retention issue
• eXTra: Unknown - the eXTra format (SV data) is for payroll offices, not business owners - but during a DRV audit it suddenly becomes relevant
• Z3 data carrier: Specialized knowledge - the GoBD-compliant Z3 export requires special-purpose software or manual preparation
• Interface errors: Undocumented - if ELSTER or DE-Mail fails, the error is not logged in the repo - there is no evidence of having "tried"
• Statutory binding: Not assigned - every interface submission is tied to a statutory provision (e.g. LStA → § 41a EStG), but this assignment is not documented

Core Statement

The GitCover-Harness mediates between external systems and risk-relevant statutory provisions:

1. ELSTER mediation - LStA, UStA, payroll tax certificate via ELSTER interface; receipt as evidence with sidecar
2. DE-Mail: discontinued - migration required - historical DE-Mails must be migrated into the repo before shutdown as EML + SHA-256 + sidecar; archived emails in discontinued systems are no longer accessible - GoBD retention issue
3. eXTra/euBP export - SV data in the eXTra format can be exported for DRV audits
4. Z3 data carrier export - GoBD-compliant Z3 export for tax office field audits (git bundle as a self-contained archive)
5. Interface error logging - errors/aborts in external systems are logged as repo events
6. Statutory binding - every interface operation is mapped to the risk-relevant statutory provision

Compliance by Design: The Harness does not conceal the complexity of authority interfaces - it documents it. Every submission, every receipt, every error is recorded in the repo in a traceable manner.

The Authority Interface Landscape

ELSTER Mediation

Statutory binding: Every interface operation is mapped to the risk-relevant statutory provision - e.g. LStA → § 41a EStG, UStA → § 18 UStG, payroll tax certificate → § 41b EStG. This makes it traceable which statutory provision was fulfilled by which submission.

DE-Mail - Discontinued: Migration and Archiving Consequences

DE-Mail has officially been discontinued. The project is considered to have failed. The last provider (FP Digital Business Solutions GmbH) discontinues the service on 31.12.2026 - thereafter, DE-Mail is no longer usable, and archived emails in these systems are no longer accessible.

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

Consequences of Archived Emails in Discontinued Systems

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

Forensic evidence preservation - virtually impossible to reconstruct: DE-Mail-specific evidentiary features (qualified electronic signature of the dispatch and access confirmation, provider timestamp, integrity hash) can be verified only while the provider infrastructure is operational. After 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 - signature verification fails due to the missing provider certificate, the timestamp server is offline, and the provider logbooks have been deleted. The email loses its status as "legally binding DE-Mail communication" and degenerates into a mere PDF copy with sharply reduced evidentiary value. Subsequent forensic evidence preservation by an expert would theoretically be possible, but is practically almost impossible - the required provider infrastructure data no longer exists.

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

GitCover Migration: DE-Mail -> Repo

Practical tip: Migration should be carried out immediately, not just shortly before shutdown. Providers may restrict the service early (e.g., no new registrations, restricted export). Anyone who waits risks 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 shutdown (by 31.12.2026 at the latest), the data is irrecoverably lost - a GoBD violation if the retention period is still running. As an alternative for future communication: ELSTER mailbox for tax matters, regular email + sidecar archiving for correspondence.

eXTra/euBP Export and Z3 Data Carrier

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

Interface Error Logging

Important - liability shift: If an interface fails (e.g. an ELSTER timeout on the 10th of the month), error logging in the repo documents that the business owner attempted to submit on time. This is evidence under § 152 AO (late-payment surcharge) - the business owner can argue that the error lay outside their sphere of responsibility.

Risk Leverage

Harness Requirements (Preview)

Derivable from ED20:

The full requirements list is in Harness-Anforderungen.md.

Sources

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

Sources Topology and CDN Reference Links

Note: This mapping 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 status.