ED20 - Pratique des interfaces administratives : ELSTER, DE-Mail, eXTra - Médiation par GitCover

Problème

De nombreuses interfaces administratives sont régies par la loi, mais en pratique difficilement utilisables pour les non-professionnels :

ELSTER : complexe, sujet aux erreurs - l'interface ELSTER exige des certificats, des formats XML, un logiciel client - pour les non-professionnels un obstacle
DE-Mail : arrêté - DE-Mail était prévu comme canal de communication sécurisé avec les administrations, mais il est officiellement arrêté (dernier fournisseur au 31.12.2026). Les e-mails archivés dans des systèmes arrêtés ne sont plus accessibles - un problème de conservation pertinent au regard des 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 : connaissances spécialisées - l'export Z3 conforme aux GoBD exige un logiciel spécialisé ou une préparation manuelle
Erreurs d'interface : non documentées - si ELSTER ou DE-Mail échoue, l'erreur n'est pas consignée dans le dépôt - la preuve « j'ai essayé » manque
Rattachement aux prescriptions : non affecté - chaque transmission via une interface est liée à une prescription (par ex. LStA → § 41a EStG), mais cette affectation n'est pas documentée

Message clé

Le harness GitCover sert d'intermédiaire entre les systèmes externes et les prescriptions à risque :

Médiation ELSTER - LStA, UStA, LSt-Bescheinigung via l'interface ELSTER ; accusé de réception comme justificatif avec sidecar
DE-Mail : arrêté - migration nécessaire - les DE-Mails historiques doivent être migrés avant l'arrêt sous forme d'EML + SHA-256 + sidecar dans le dépôt ; les e-mails archivés dans des systèmes arrêté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 support de données Z3 - export Z3 conforme aux GoBD pour les contrôles externes du FA (git bundle comme archive autonome)
Journalisation des erreurs d'interface - les erreurs/interruptions de systèmes externes sont consignées comme événement du dépôt
Rattachement aux prescriptions - chaque opération d'interface est mise en correspondance avec la prescription à risque

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

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, visionneuse de factures électroniques	élevée (certificat, XML, client)	accusé de réception comme justificatif avec sidecar
DE-Mail	Communication sécurisée avec les administrations	arrêté (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 aux GoBD pour le contrôle externe du FA	élevée (logiciel spécialisé)	git bundle comme archive autonome

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ée	Déclaration de retenue à la source sur les salaires à partir de la paie	artefact JSON dans le dépôt (voir ED14)
Transmission ELSTER	Par voie électronique via ELSTER (certificat requis)	le harness appelle ELSTER
Accusé de réception	ELSTER confirme la transmission	accusé de réception comme justificatif avec sidecar
Entrée dans le dépôt	LStA avec `source_sha256` sur l'accusé de réception	`tags: ["lsta", "§41a-estg"]`
Rattachement aux prescriptions	LStA → § 41a EStG	`vorschrift: "§41a-estg"` dans l'artefact
Journalisation des erreurs	L'erreur ELSTER est consignée	événement du dépôt avec description de l'erreur

Rattachement aux prescriptions : chaque opération d'interface est mise en correspondance avec la prescription à risque - par ex. LStA → § 41a EStG, UStA → § 18 UStG, LSt-Bescheinigung → § 41b EStG. Il est ainsi possible de retracer quelle prescription a été remplie par quelle transmission.

DE-Mail - Arrêté : migration et conséquences archivistiques

DE-Mail est officiellement arrêté. Le projet est considéré comme un échec. Le dernier fournisseur (FP Digital Business Solutions GmbH) met fin au service au 31.12.2026 - ensuite, 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 arrête De-Mail	31.08.2022	« en raison de l'absence de rentabilité »
1&1 De-Mail GmbH arrête	07.02.2025	service plus accessible
§ 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 arrête	juillet 2024	utilisation obligatoire arrêtée
Dernier fournisseur (FP Digital) arrête	31.12.2026	« Ainsi s'achève l'histoire de DE-Mail »
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 - volontairement conçu de manière non sécurisée »

DE-Mail, c'est terminé : 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 arrêté 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, un « European Business Wallet (EBW) » est prévu.

Conséquences des e-mails archivés dans des systèmes arrêtés

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

Problème	Conséquence	Référence GoBD
Boîte aux lettres plus accessible	Les e-mails ne peuvent plus être consulté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 de 6 ans)
Aucun export possible	Si le fournisseur ne propose pas de fonction d'export, les données sont irrémédiablement 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 conservation forensique de preuves	Un non-professionnel ne peut guère renforcer a posteriori l'authenticité d'anciens e-mails sur le plan forensique - sans infrastructure du fournisseur, les données de vérification manquent (vérification de signature, serveur d'horodatage, journaux du fournisseur)	déclassement de la valeur probante à « simple copie PDF »
Le délai de conservation court encore	Les e-mails de 2024 doivent être conservés jusqu'au 31.12.2030 - mais le système aura disparu en 2026	violation des GoBD par conservation non disponible

Conservation forensique des preuves - difficilement rattrapable : les caractéristiques probantes spécifiques à DE-Mail (signature électronique qualifiée de la confirmation d'envoi et de réception, horodatage du fournisseur, valeur de hachage d'intégrité) peuvent uniquement être vérifiées au sein de l'infrastructure du fournisseur encore en service. Après l'arrêt, ces données de vérification ne sont plus disponibles. Un non-professionnel ne peut plus, a posteriori, vérifier un fichier EML exporté quant à son authenticité spécifique à DE-Mail - 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 simple copie PDF à la force probante fortement réduite. Une conservation forensique 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 possèdent 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 irrémédiablement perdues. C'est une violation des 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 .gc.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 au format EML	avant l'arrêt (au plus tard le 31.12.2026)
SHA-256	Calculer le hachage par fichier EML	lors de la migration
Sidecar	`.gc.md` par EML avec classification	lors de la migration
Classement	EML + sidecar dans `sources/korrespondenz/`	lors de la migration
Vérification	Contrôler l'exhaustivité (nombre d'e-mails)	après migration

Conseil pratique : la migration devrait être effectuée immédiatement, et non seulement peu avant l'arrêt. Les fournisseurs peuvent restreindre le service prématurément (par ex. plus de nouvelles inscriptions, export limité). Celui 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 arrêté (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 la boîte aux lettres ELSTER sont gratuits
Sécurité	« volontairement conçu de manière non sécurisée » (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 arrêté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 des GoBD pour les données non migrées
Succession	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 d'EML + sidecar vers le dépôt. Après l'arrêt (au plus tard le 31.12.2026), les données sont irrémédiablement perdues - une violation des GoBD si le délai de conservation court encore. Comme alternative pour la communication future : boîte aux lettres ELSTER pour les sujets fiscaux, e-mail régulier + archivage 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 + manifeste + web statique (Z3+)	FA

Exemple pratique : lors d'un contrôle d'entreprise, le DRV exige des données SV au format eXTra. Le harness exporte les données de paie et SV pertinentes du dépôt au format XML eXTra. Lors d'un contrôle externe, le FA exige des données conformes aux GoBD (Z3) - le harness génère un git bundle + web statique (Z3+, voir ED05). Les deux exports peuvent être générés à partir des données structurées du dépôt (JSON, sidecars) - aucune préparation manuelle 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	Accusé de réception archivé	justificatif avec sidecar, `source_sha256` dans l'artefact
Erreur	Erreur consignée	événement du dépôt avec description de l'erreur, horodatage, prescription
Preuve	« erreur non imputable »	événement du dépôt comme preuve lors d'un contrôle

Important - déplacement de responsabilité : si une interface échoue (par 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 en cas de § 152 AO (majoration de retard) - l'entrepreneur peut arguer que l'erreur ne relevait pas de sa sphère.

Levier de risque

Aujourd'hui (peu coûteux)	Demain (auditable)	Risque réduit
Accusé de réception ELSTER comme justificatif avec sidecar	transmission prouvable	majoration de retard § 152 AO
Avertissement DE-Mail + alternative	canal approprié 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 des GoBD lors du contrôle DRV
Export Z3 sous forme de git bundle	données GoBD disponibles pour le contrôle du FA	violation des GoBD lors du contrôle du FA
Journalisation des erreurs d'interface	preuve « tentative »	déplacement de responsabilité en cas de défaillance d'interface
Rattachement aux prescriptions	prescription documentée par transmission	contestation de l'accomplissement de la prescription

Exigence du harness (aperçu)

Déductible de ED20 :

ID	Exigence	Priorité
FA-12.1	Médiation ELSTER : LStA, UStA, LSt-Bescheinigung ; accusé de réception 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 support de données Z3 : export Z3 conforme aux GoBD (git bundle)	SHOULD
FA-12.5	Journalisation des erreurs d'interface : erreur comme événement du dépôt	MUST
FA-12.6	Rattachement aux prescriptions : chaque opération mise en correspondance avec la prescription à 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 administratifs	MUST

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

Sources

AO (§ 147 Abs. 6 - accès aux données Z1/Z2/Z3, § 152 - majoration de retard)
EStG (§ 41a - déclaration de retenue à la source sur les salaires, § 41b - attestation de retenue à la source sur les salaires)
UStG (§ 18 - déclaration préalable de TVA, § 14 - facture électronique)
SGB IV (§ 28p - contrôle d'entreprise DRV, § 28a - déclarations DEÜV)
GoBD (lettre du BMF, Rz. 147 - vérifiabilité, accès aux données Z3)
DE-Mail (Wikipédia, état au 14.08.2026) - « Ainsi s'achève l'histoire de DE-Mail » : 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 de § 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 »
E1/agents/ (anonymisé) - concept SSoT avec ELSTER, journalisation des erreurs d'interface

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

Rôle	Lieu	Objectif
Primary / SSoT	git.gitcover.org/GCC	stockage 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 répartition des sources, du miroir et du Community Hub reflète l'état actuel et peut changer. Veuillez vérifier la source canonique respective sur gitcover.org pour connaître l'état actuel.