ED13 - Finanzamt : numéro fiscal, § 60a AO, Lohnsteuer-Anmeldung

Problème

Après la création et la déclaration d'activité commerciale, le Finanzamt (FA) se manifeste - mais dans le secteur des KMU, il n'est pas clair quelles obligations en découlent et comment elles sont prouvées dans le Repo :

• « Numéro fiscal ? C'est le conseiller fiscal qui l'a. » - beaucoup d'entrepreneurs ne connaissent pas leur propre numéro fiscal, et encore moins l'endroit où il se trouve
• Lohnsteuer-Anmeldung comme boîte noire - la LStA est effectuée par le service de paie, mais l'entrepreneur n'a aucune preuve dans le Repo
• Certificat ELSTER non documenté - le certificat personnel ou d'organisation est installé quelque part, mais aucune preuve n'en est apportée dans le Repo
• Notification USt confondue avec la notification KSt - différents numéros fiscaux pour différents types d'impôts, mais un seul est disponible
• Aucune surveillance des échéances pour les déclarations au FA - LStA, UStA, déclarations ESt/KSt ont des échéances différentes, mais personne ne les surveille de manière centralisée
• § 60a AO Bescheid inconnu - le Bescheid relatif à l'utilité publique (§ 60a Abs. 1 AO) est le fondement des exonérations fiscales, mais il traîne quelque part sous forme papier

Message clé

Les obligations envers le Finanzamt dans le Repo Git signifient :

1. Numéros fiscaux comme entrées de registry - stockage central dans registry/ avec Sidecar, un numéro par type d'impôt
2. Lohnsteuer-Anmeldung comme artefact JSON - LStA avec source_sha256 renvoyant à la quittance ELSTER
3. Certificat ELSTER documenté - fichier .pfx avec Sidecar (pas le certificat lui-même dans le Repo, mais la preuve)
4. Contrôle des échéances pour toutes les déclarations au FA - LStA, UStA, ESt/KSt avec alerte automatique
5. § 60a AO Bescheid comme justificatif avec Sidecar - Freistellungsbescheid avec suivi de la validité

Compliance by Design : les obligations envers le FA ne sont pas gérées a posteriori, mais saisies structurellement au moyen d'entrées de registry avec Sidecars, du contrôle des échéances et d'artefacts JSON.

Numéros fiscaux dans le répertoire registry

Exemple pratique : la KMU a le numéro fiscal KSt <STNR>, le numéro fiscal USt <STNR>, le numéro fiscal LSt <STNR>, le W-IdNr <WID>, l'USt-IdNr DE<UID>. Chaque numéro est archivé comme justificatif avec Sidecar dans registry/. Le § 60a AO Bescheid (reconnaissance de l'utilité publique) s'y trouve également, avec suivi de la validité.

§ 60a AO Bescheid - Utilité publique

Important : le § 60a AO Bescheid est le fondement de tous les privilèges liés à l'utilité publique (KSt, USt, VBG, forfaits). Sans ce Bescheid, les exonérations fiscales ne sont pas mobilisables. Le Bescheid doit être archivé dans le Repo avec Sidecar afin que la preuve puisse être fournie en cas de contrôle.

Lohnsteuer-Anmeldung (§ 41a EStG)

LStA comme artefact JSON

{
  "$schema": "https://gitcover.org/schemas/diary-entry-1.0.schema.json",
  "V7GUID": "<V7GUID-Class-aus-Registry>",
  "uuidV7": "<uuidV7-Object-mit-vorgegebener-Zeitmarke>",
  "author": "E1",
  "role": "Lohnverantwortlicher",
  "tenant": "ORG-1",
  "sphere": "ideell",
  "source": "FA",
  "source_sha256": "<SHA-256-der-ELSTER-Quittung>",
  "tags": ["lsta", "§41a-estg", "nullmeldung", "aktivrente"],
  "lsta": {
    "monat": "09/2026",
    "brutto": 2000.00,
    "lst": 0.00,
    "soli": 0.00,
    "kist": 0.00,
    "freibetrag_aktivrente": 2000.00,
    "art": "nullmeldung"
  }
}

Remarque : la uuidV7 est la DocID de l'entrée. Le Composite Key V7GUID:uuidV7 sert à l'organisation du stockage et aux requêtes DB. L'objet lsta documente la Lohnsteuer-Anmeldung avec toutes ses composantes. En cas d'Aktivrente (§ 3 Nr. 21 EStG), la LSt = 0,00 - il s'agit d'une Nullmeldung (voir ED23).

Documenter le certificat ELSTER

Important - pas de .pfx dans le Repo : le fichier .pfx (certificat + clé privée) n'est pas intégré au Repo Git - il contient des secrets cryptographiques. À la place, un Sidecar est archivé ; il documente l'existence et l'activation du certificat (date, statut, quittance de test ELSTER). Le fichier .pfx est conservé en lieu sûr hors du Repo (p. ex. sur un support de stockage chiffré).

Voir ED15 : l'utilisation pratique du certificat ELSTER (pratique des interfaces administratives, DE-Mail, intermédiation par GitCover) est traitée dans ED15.

Surveillance des échéances pour les déclarations au FA

Conseil pratique : le contrôle des échéances est tenu comme artefact Git et actualisé à chaque commit. L'alerte automatique (voir ED08) avertit 14 jours avant l'expiration d'une échéance FA. Ainsi, plus aucun dépassement d'échéance n'est négligé - et le § 152 AO (majoration pour retard jusqu'à 25 000 EUR) est évité.

Risiko-Leverage

Exigences Harness (aperçu)

Ce qui peut être dérivé de ED13 :

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

Sources

• AO (§ 60a - reconnaissance de l'utilité publique, § 149 - déclarations fiscales, § 152 - majoration pour retard)
• EStG (§ 41a - Lohnsteuer-Anmeldung, § 41b - Lohnsteuer-Bescheinigung)
• UStG (§ 18 - Umsatzsteuer-Voranmeldung, § 14 - E-Rechnung)
• AFJD/agents/ (anonymisé) - concept SSoT avec registry, contrôle des échéances, ELSTER

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

Remarque : cette attribution 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.