ED19 - Praxis des interfaces administratives : ELSTER, DE-Mail, eXTra - médiation par GitCover

Problème

De nombreuses interfaces administratives sont réglementées par la loi, mais en pratique difficilement utilisables pour les profanes :

ELSTER : complexe, sujette aux erreurs - l'interface ELSTER exige des certificats, des formats XML, un logiciel client - un obstacle pour les profanes
DE-Mail : abandonné - DE-Mail était prévu comme canal de communication sécurisé avec les administrations, mais est officiellement abandonné (dernier fournisseur au 31.12.2026). Les e-mails archivés dans des systèmes abandonnés ne sont plus accessibles - un problème de conservation pertinent pour la GoBD
eXTra : inconnu - le format eXTra (données SV) est destiné aux bureaux de paie, pas aux entrepreneurs - mais lors d'un contrôle DRV, il devient soudain pertinent
Support de données Z3 : connaissance spécialisée - l'export Z3 conforme à la GoBD exige un logiciel spécialisé ou un traitement manuel
Erreurs d'interface : non documentées - si ELSTER ou DE-Mail échouent, l'erreur n'est pas consignée dans le dépôt - la preuve « j'ai essayé » manque
Liaison aux prescriptions : non attribuée - chaque transmission via interface est liée à une prescription (p. ex. LStA → § 41a EStG), mais cette attribution n'est pas documentée

Message clé

Le GitCover-Harness assure la médiation entre les systèmes externes et les prescriptions sensibles au risque :

Médiation ELSTER - LStA, UStA, LSt-Bescheinigung via l'interface ELSTER ; quittance comme justificatif avec sidecar
DE-Mail : abandonné - migration nécessaire - les DE-Mails historiques doivent être migrés dans le dépôt avant l'arrêt sous forme EML + SHA-256 + sidecar ; les e-mails archivés dans des systèmes abandonnés ne sont plus accessibles - problème de conservation GoBD
Export eXTra/euBP - données SV exportables au format eXTra pour les contrôles DRV
Export du support de données Z3 - export Z3 conforme à la GoBD pour les contrôles externes du FA (git bundle comme archive self-contained)
Journalisation des erreurs d'interface - les erreurs/interruptions de systèmes externes sont consignées comme événement de dépôt
Liaison aux prescriptions - chaque opération d'interface est mappée sur la prescription sensible au risque

Compliance by Design : le Harness ne masque pas la complexité des interfaces administratives - il les documente. Chaque transmission, chaque quittance, chaque erreur est consignée de manière traçable dans le dépôt.

Le paysage des interfaces administratives

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart TD U["Unternehmer E1"] U --> H["GitCover-Harness"] H --> EL["ELSTER"] H --> DM["DE-Mail (eingestellt)"] H --> EX["eXTra/euBP"] H --> Z3["Z3-Datenträger"] EL --> FA["Finanzamt"] DM --> BH["Behörden (diverse)"] EX --> DRV["DRV (SV-Prüfung)"] Z3 --> AP["Finanzamt (Außenprüfung)"] style U fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style H fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style EL fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style DM fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style EX fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style Z3 fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style FA fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style BH fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style DRV fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style AP fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33

Interface	Objectif	Complexité	Médiation GitCover
ELSTER	LStA, UStA, LSt-Bescheinigung, E-Rechnung-Viewer	élevée (certificat, XML, client)	quittance comme justificatif avec sidecar
DE-Mail	Communication sécurisée avec les administrations	abandonné (dernier fournisseur 31.12.2026)	Migration : EML + sidecar dans le dépôt ; avertissement
eXTra/euBP	Données SV pour les contrôles DRV	élevée (format spécialisé)	Export à partir des données du dépôt
Support de données Z3	Export conforme à la GoBD pour le contrôle externe du FA	élevée (logiciel spécialisé)	git bundle comme archive self-contained

Médiation ELSTER

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart TD L["LStA/UStA berechnet"] L --> E["ELSTER-Übermittlung"] E --> Q["ELSTER-Quittung"] Q --> S["Quittung als Beleg mit Sidecar"] S --> R["Repo: LStA-Eintrag mit source_sha256"] R --> V["Vorschriften-Binding: § 41a EStG"] E -->|Fehler| F["Fehler-Logging im Repo"] F --> FR["Repo-Ereignis: ELSTER-Fehler"] style L fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style E fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style Q fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style S fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style R fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style V fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style F fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style FR fill:#FDBA74,stroke:#C2410C,color:#0F1B33

Étape	Action	Mise en œuvre GitCover
LStA calculé	déclaration préalable de l'impôt sur les salaires à partir de la paie	artefact JSON dans le dépôt (voir ED13)
Transmission ELSTER	électroniquement via ELSTER (certificat requis)	le Harness appelle ELSTER
Quittance	ELSTER confirme la transmission	quittance comme justificatif avec sidecar
Entrée de dépôt	LStA avec `source_sha256` sur la quittance	`tags: ["lsta", "§41a-estg"]`
Liaison aux prescriptions	LStA → § 41a EStG	`vorschrift: "§41a-estg"` dans l'artefact
Journalisation des erreurs	l'erreur ELSTER est consignée	événement de dépôt avec description de l'erreur

Liaison aux prescriptions : chaque opération d'interface est mappée sur la prescription sensible au risque - p. ex. LStA → § 41a EStG, UStA → § 18 UStG, LSt-Bescheinigung → § 41b EStG. Ainsi, on peut retracer quelle prescription a été remplie par quelle transmission.

DE-Mail - abandonné : migration et conséquences pour l'archivage

DE-Mail est officiellement abandonné. Le projet est considéré comme un échec. Le dernier fournisseur (FP Digital Business Solutions GmbH) met fin au service au 31.12.2026 - après quoi DE-Mail n'est plus utilisable et les e-mails archivés dans ces systèmes ne sont plus accessibles.

Événement	Date	Source
Telekom met fin à De-Mail	31.08.2022	« en raison d'un manque de rentabilité »
1&1 De-Mail GmbH met fin au service	07.02.2025	service inaccessible
§ 130a ZPO supprimé	22.12.2025	De-Mail supprimé comme voie de transmission sécurisée (BGBl. 2025 I Nr. 349)
L'administration fédérale met fin	juillet 2024	utilisation obligatoire abandonnée
Le dernier fournisseur (FP Digital) met fin au service	31.12.2026	« De-Mail appartient désormais à l'histoire »
Bundesrechnungshof 2021	2021	2011-2020 : ~6 000 De-Mails d'administrations, économies ~3 500 EUR, coûts >= 6,5 Mio. EUR
Critique du CCC	2013	Linus Neumann (30C3) : « Bullshit made in Germany - délibérément non sécurisé »

DE-Mail appartient à l'histoire : le dernier fournisseur (FP Digital Business Solutions GmbH) met fin au service au 31.12.2026. La reconnaissance légale comme voie de transmission sécurisée (§ 130a Abs. 4 Nr. 1 ZPO) a été supprimée au 22.12.2025. L'administration fédérale a abandonné l'utilisation obligatoire en juillet 2024. Le Bundesrechnungshof a dressé le bilan en 2021 : 6,5 Mio. EUR de coûts pour ~3 500 EUR d'économies. Comme successeur, une « European Business Wallet (EBW) » est prévue.

Conséquences pour les e-mails archivés dans des systèmes abandonnés

Lorsqu'un fournisseur DE-Mail met fin à son service, des problèmes de conservation immédiatement pertinents pour la GoBD apparaissent :

Problème	Conséquence	Lien avec la GoBD
Boîte aux lettres plus accessible	les e-mails ne peuvent plus être récupérés	§ 146 Abs. 5 AO (« disponible à tout moment »)
Suppression côté fournisseur	après l'arrêt, les données sont supprimées	§ 147 Abs. 1 AO (obligation de conservation 6 ans)
Aucun export possible	si le fournisseur n'offre pas de fonction d'export, les données sont définitivement perdues	GoBD Rz. 146 (traçabilité)
Force probante perdue	les confirmations spécifiques à DE-Mail (confirmation d'envoi/de réception) ne sont plus vérifiables	perte de preuve en cas de litige avec une administration
Aucune sécurisation forensique des preuves	un profane peut difficilement consolider a posteriori de manière forensique l'authenticité d'anciens e-mails - sans l'infrastructure du fournisseur, les données de vérification manquent (vérification de signature, serveur d'horodatage, journaux du fournisseur)	rétrogradation de la valeur probante à « simple copie PDF »
Délai de conservation toujours en cours	les e-mails de 2024 doivent être conservés jusqu'au 31.12.2030 - mais le système disparaît en 2026	violation de la GoBD due à une conservation non disponible

Sécurisation forensique des preuves - difficile à rattraper : les caractéristiques probantes spécifiques à DE-Mail (signature électronique qualifiée de la confirmation d'envoi et de la confirmation de réception, horodatage du fournisseur, valeur de hachage d'intégrité) ne peuvent être vérifiées qu'au sein de l'infrastructure du fournisseur en activité. Après l'arrêt, ces données de vérification ne sont plus disponibles. Un profane ne peut plus vérifier a posteriori l'authenticité spécifique à DE-Mail d'un fichier EML exporté - la vérification de signature échoue faute de certificat du fournisseur, le serveur d'horodatage est hors ligne, les journaux du fournisseur sont supprimés. L'e-mail perd son statut de « communication DE-Mail juridiquement contraignante » et dégénère en une simple copie PDF avec une force probante fortement réduite. Une sécurisation forensique des preuves a posteriori par un expert serait théoriquement possible, mais pratiquement difficilement réalisable - les données d'infrastructure du fournisseur nécessaires n'existent plus.

Avertissement critique - migration avant l'arrêt : les entrepreneurs qui ont encore une boîte aux lettres DE-Mail doivent avant l'arrêt exporter tous les e-mails pertinents sous forme de fichiers EML et les migrer dans le dépôt Git (EML + SHA-256 + sidecar). Après l'arrêt, un export n'est plus possible - les données sont définitivement perdues. C'est une violation de la GoBD si le délai de conservation court encore (6 ans à compter de la fin de l'année, § 147 Abs. 1 Nr. 2/3 AO).

Migration GitCover : DE-Mail -> dépôt

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart LR D["DE-Mail-Postfach (eingestellt)"] D --> EX["Export vor Abschaltung"] EX --> EML["EML-Dateien"] EML --> SH["SHA-256 pro EML"] SH --> SC["Sidecar .v7g.md pro EML"] SC --> R["Repo: sources/korrespondenz/"] R --> OK["GoBD-konform archiviert"] D -->|nach Abschaltung| LOST["Daten unwiederbringlich verloren"] LOST --> V["GoBD-Verstoß"] style D fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style EX fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style EML fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style SH fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style SC fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style R fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style OK fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style LOST fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style V fill:#FDBA74,stroke:#C2410C,color:#0F1B33

Étape	Action	Délai
Export	exporter tous les e-mails pertinents en EML	avant l'arrêt (au plus tard le 31.12.2026)
SHA-256	calculer le hachage pour chaque fichier EML	lors de la migration
Sidecar	`.v7g.md` pour chaque EML avec classification	lors de la migration
Rangement	EML + sidecar dans `sources/korrespondenz/`	lors de la migration
Vérification	contrôler l'exhaustivité (nombre d'e-mails)	après la migration

Conseil pratique : la migration devrait être effectuée immédiatement, et non seulement peu de temps avant l'arrêt. Les fournisseurs peuvent restreindre le service de manière anticipée (p. ex. aucune nouvelle inscription, export restreint). Qui attend risque une perte de données.

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart LR D["DE-Mail (eingestellt)"] D --> P["Gescheitert: 6,5 Mio EUR Kosten, ~3500 EUR Nutzen"] P --> W["Warnung: DE-Mail nicht nutzen"] W --> A["Alternative: ELSTER-Postfach"] D --> E["Eingehende Behörden-E-Mail (historisch)"] E --> AR["EML archiviert + Sidecar"] AR --> V["Absender-Verifikation (DKIM/SPF)"] style D fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style W fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style A fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style E fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style AR fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style V fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33

Aspect	Problème	Solution GitCover
Statut	DE-Mail officiellement abandonné (dernier fournisseur 31.12.2026)	avertissement : ne pas utiliser ; migration nécessaire
Coûts/bénéfices	6,5 Mio. EUR de coûts, ~3 500 EUR d'économies (Bundesrechnungshof)	git bundle et boîte aux lettres ELSTER sont gratuits
Sécurité	« délibérément non sécurisé » (CCC, Linus Neumann 2013)	Git + GPG + SHA-256
reconnaissance légale	§ 130a ZPO supprimé au 22.12.2025	plus pertinent
Archivage	e-mails archivés dans des systèmes abandonnés plus accessibles	Migration : EML + SHA-256 + sidecar dans le dépôt
Délai de conservation	les e-mails de 2024 doivent être conservés jusqu'en 2030 - système disparu en 2026	violation de la GoBD pour les données non migrées
Successeur	European Business Wallet (EBW) prévu	ouvert ; GitCover indépendant

Atténuation du désastre DE-Mail : le Harness avertit en cas d'utilisation de DE-Mail (si des boîtes aux lettres historiques existent encore) et recommande une migration immédiate de tous les e-mails pertinents sous forme EML + sidecar dans le dépôt. Après l'arrêt (au plus tard le 31.12.2026), les données sont définitivement perdues - une violation de la GoBD si le délai de conservation court encore. Comme alternative pour les communications futures : boîte aux lettres ELSTER pour les questions fiscales, e-mail ordinaire + archivage par sidecar pour la correspondance.

Export eXTra/euBP et support de données Z3

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart TD R["Repo-Daten (JSON, Sidecars)"] R --> EX["eXTra-Export"] R --> Z3["Z3-Export (git bundle)"] EX --> DRV["DRV-Prüfung: SV-Daten"] Z3 --> FA["FA-Außenprüfung: GoBD-Daten"] EX --> F1["Format: eXTra V3.4.0"] Z3 --> F2["Format: git bundle + Manifest"] style R fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style EX fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style Z3 fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style DRV fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style FA fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style F1 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style F2 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33

Export	Objectif	Format	Destinataire
eXTra/euBP	données SV pour le contrôle DRV	eXTra V3.4.0 (XML)	DRV
Z3 (git bundle)	données GoBD pour le contrôle externe du FA	git bundle + Manifest + Static-Web (Z3+)	FA

Exemple pratique : la DRV exige lors d'un contrôle d'entreprise des données SV au format eXTra. Le Harness exporte les données de paie et SV pertinentes du dépôt en eXTra-XML. Le FA exige lors d'un contrôle externe des données conformes à la GoBD (Z3) - le Harness génère un git bundle + Static-Web (Z3+, voir ED05). Les deux exports peuvent être générés à partir des données structurées du dépôt (JSON, sidecars) - aucun traitement manuel nécessaire.

Journalisation des erreurs d'interface

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart TD S["Schnittstellen-Aufruf (ELSTER, DE-Mail)"] S --> OK["Erfolg: Quittung + Sidecar"] S --> ERR["Fehler: Abbruch, Timeout, Formatfehler"] ERR --> L["Fehler-Logging im Repo"] L --> E["Repo-Ereignis: Schnittstellen-Fehler"] E --> N["Nachweis: Fehler nicht verschuldet"] style S fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style OK fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style ERR fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style L fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style E fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style N fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33

Événement	Action	Mise en œuvre GitCover
Succès	quittance archivée	justificatif avec sidecar, `source_sha256` dans l'artefact
Erreur	erreur consignée	événement de dépôt avec description de l'erreur, horodatage, prescription
Preuve	« erreur non imputable »	événement de dépôt comme preuve lors d'un contrôle

Important - transfert de responsabilité : lorsqu'une interface échoue (p. ex. timeout ELSTER le 10 du mois), la journalisation des erreurs dans le dépôt documente que l'entrepreneur a tenté de transmettre à temps. C'est une preuve au sens du § 152 AO (majoration pour retard) - l'entrepreneur peut arguer que l'erreur ne relevait pas de sa sphère.

Levier de risque

Aujourd'hui (cheap)	Demain (à l'épreuve des contrôles)	Risque atténué
quittance ELSTER comme justificatif avec sidecar	transmission prouvable	majoration pour retard § 152 AO
avertissement DE-Mail + alternative	canal adapté choisi	perte de la communication
export eXTra à partir des données du dépôt	données SV disponibles pour le contrôle DRV	violation de la GoBD lors d'un contrôle DRV
export Z3 en git bundle	données GoBD disponibles pour le contrôle du FA	violation de la GoBD lors d'un contrôle du FA
journalisation des erreurs d'interface	preuve « tentative »	transfert de responsabilité en cas de défaillance d'interface
liaison aux prescriptions	prescription documentée par transmission	contestation de l'exécution de la prescription

Exigence Harness (aperçu)

Déductible de ED19 :

ID	Exigence	Priorité
FA-12.1	Médiation ELSTER : LStA, UStA, LSt-Bescheinigung ; quittance comme justificatif avec sidecar	MUST
FA-12.2	Pont DE-Mail/De-Mail : EML + SHA-256 + sidecar ; vérification de l'expéditeur	SHOULD
FA-12.3	Export eXTra/euBP : données SV au format eXTra pour les contrôles DRV	SHOULD
FA-12.4	Export du support de données Z3 : export Z3 conforme à la GoBD (git bundle)	SHOULD
FA-12.5	Journalisation des erreurs d'interface : erreurs comme événement de dépôt	MUST
FA-12.6	Liaison aux prescriptions : chaque opération mappée sur la prescription sensible au risque	SHOULD
FA-12.7	Atténuation du désastre DE-Mail : avertissement en cas de canaux inadaptés	NICE
FA-12.8	Registre des identifiants d'administrations	MUST

La liste complète des exigences dans Harness-Anforderungen.md.

Sources

AO (§ 147 Abs. 6 - accès aux données Z1/Z2/Z3, § 152 - majoration pour retard)
EStG (§ 41a - déclaration préalable de l'impôt sur les salaires, § 41b - attestation de l'impôt sur les salaires)
UStG (§ 18 - déclaration préalable de TVA, § 14 - E-Rechnung)
SGB IV (§ 28p - contrôle d'entreprise DRV, § 28a - déclarations DEÜV)
GoBD (lettre BMF, Rz. 147 - vérifiabilité, accès aux données Z3)
DE-Mail (Wikipedia, état au 14.08.2026) - « De-Mail appartient désormais à l'histoire » : Telekom 31.08.2022, 1&1 07.02.2025, § 130a ZPO supprimé le 22.12.2025, administration fédérale juillet 2024, FP Digital 31.12.2026, Bundesrechnungshof 2021
BGBl. 2025 I Nr. 349 - Loi portant suppression du § 130a Abs. 4 Nr. 1 ZPO (DE-Mail)
Rapport annuel 2021 du Bundesrechnungshof - DE-Mail : 6,5 Mio. EUR de coûts, ~3 500 EUR d'économies
CCC 30C3 2013 - Linus Neumann : « Bullshit made in Germany »
AFJD/agents/ (anonymisé) - concept SSoT avec ELSTER, journalisation des erreurs d'interface

Topologie des sources et liens de référence CDN

Rôle	Emplacement	Objectif
Primary / SSoT	git.gitcover.org/GCC	Emplacement canonique (signé GPG, versionné)
Public OSS Mirror / CDN	codeberg.org/gitcover-commons	Miroir en lecture seule ; découverte FLOSS
Community Hub	github.com/gitcover-commons	Issues & Discussions ; référence du code source sur Codeberg

Remarque : cette attribution des sources, du miroir et du hub communautaire reflète l'état actuel et peut changer. Veuillez vérifier la source canonique respective sur gitcover.org pour connaître l'état actuel.