ED14 - Centre des impôts : numéro fiscal, § 60a AO, déclaration de retenue à la source

Problème

Après la création et l’immatriculation de l’entreprise, le centre des impôts (FA) prend contact — mais, dans le secteur des PME, il n’est pas clair quelles obligations en découlent ni comment les prouver dans le dépôt :

• « Numéro fiscal ? Le conseiller fiscal s’en charge. » - de nombreux entrepreneurs ne connaissent pas leur propre numéro fiscal, et encore moins l’endroit où il se trouve
• Déclaration de retenue à la source comme boîte noire - la LStA est établie par le service de paie, mais l’entrepreneur n’a aucune preuve dans le dépôt
• Certificat ELSTER non documenté - le certificat personnel ou d’organisation est installé quelque part, mais n’est pas attesté dans le dépôt
• Confusion entre la notification de TVA (USt) et celle d’IS (KSt) - différents numéros fiscaux selon le type d’impôt, mais un seul est disponible
• Aucune surveillance des délais pour les déclarations auprès du FA - les LStA, UStA et déclarations ESt/KSt ont des échéances différentes, mais personne ne les contrôle de manière centralisée
• Décision § 60a AO inconnue - la décision reconnaissant l’utilité publique (§ 60a Abs. 1 AO) est la base des exonérations fiscales, mais elle se trouve quelque part sous forme papier

Message clé

Les obligations liées au centre des impôts dans le dépôt Git se traduisent ainsi :

1. Les numéros fiscaux comme entrées de registre - stockage centralisé dans registry/ avec sidecar, un numéro par type d’impôt
2. La déclaration de retenue à la source comme artefact JSON - LStA avec source_sha256 pointant vers la quittance ELSTER
3. Certificat ELSTER documenté - fichier .pfx avec sidecar (non pas le certificat lui-même dans le dépôt, mais sa preuve)
4. Contrôle des délais pour toutes les déclarations auprès du FA - LStA, UStA, ESt/KSt avec avertissement automatique
5. Décision § 60a AO comme justificatif avec sidecar - décision d’exonération avec suivi de validité

Compliance by Design : Les obligations liées au centre des impôts ne sont pas gérées après coup, mais sont consignées de manière structurelle au moyen de entrées de registre avec sidecars, d’un contrôle des délais et d’artefacts JSON.

Numéros fiscaux dans le répertoire du registre

Exemple pratique : L’entreprise KMU dispose d’un numéro fiscal KSt <STNR>, d’un numéro fiscal USt <STNR>, d’un numéro fiscal LSt <STNR>, d’un W-IdNr <WID> et d’un USt-IdNr DE<UID>. Chaque numéro est stocké sous forme de justificatif avec sidecar dans registry/. La décision § 60a AO (reconnaissance d’utilité publique) s’y trouve également, avec suivi de validité.

Décision § 60a AO - Utilité publique

Important : La décision § 60a AO constitue la base de tous les privilèges liés à l’utilité publique (KSt, USt, VBG, Pauschalen). Sans cette décision, les exonérations fiscales ne peuvent pas être justifiées. La décision doit être stockée dans le dépôt avec un sidecar, afin que la preuve puisse être apportée lors d’un contrôle.

Déclaration de retenue à la source (§ 41a EStG)

LStA comme artefact JSON

{
  "$schema": "https://gitcover.org/schemas/diary-entry-1.0.schema.json",
  "V7GUID": "<V7GUID-Class-aus-Registry>",
  "docUid": "<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 le DocID de l’entrée. La clé composite V7GUID:uuidV7 sert à organiser le stockage et les requêtes de la base de données. L’objet lsta documente la déclaration de retenue à la source avec toutes ses composantes. En cas de rente d’activité (§ 3 Nr. 21 EStG), la LSt = 0,00 — il s’agit d’une déclaration à zéro (voir ED23).

Documenter le certificat ELSTER

Important - .pfx ne doit pas être placé dans le dépôt : Le fichier .pfx (certificat + clé privée) n’est pas ajouté au dépôt Git — il contient des secrets cryptographiques. À la place, un sidecar est conservé, qui documente l’existence et l’activation du certificat (date, statut, quittance de test ELSTER). Le fichier .pfx est stocké en toute sécurité hors du dépôt (p. ex. sur un support chiffré).

Voir ED16 : L’utilisation pratique du certificat ELSTER (pratique des interfaces avec les autorités, DE-Mail, transmission par GitCover) est traitée dans ED16.

Surveillance des délais pour les déclarations auprès du FA

Conseil pratique : Le contrôle des délais est géré comme un artefact Git et actualisé à chaque commit. L’avertissement automatique (voir ED08) signale les échéances du FA 14 jours avant leur expiration. Aucun dépassement de délai n’est désormais plus négligé — et la pénalité de retard au titre de § 152 AO (jusqu’à 25.000 EUR) est évitée.

Risque réduit

Exigence du harnais (aperçu)

Déductible d’ED14 :

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

Sources

• AO (§ 60a - Reconnaissance d’utilité publique, § 149 - Déclarations fiscales, § 152 - Pénalité de retard)
• EStG (§ 41a - Déclaration de retenue à la source, § 41b - Attestation de retenue à la source)
• UStG (§ 18 - Déclaration de TVA, § 14 - Facture électronique)
• E1/agents/ (anonymisé) - Concept SSoT avec registre, contrôle des délais, ELSTER

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

Remarque : Cette correspondance entre les sources, le miroir et le hub communautaire reflète l’état actuel et peut évoluer. Veuillez vérifier la source canonique correspondante sur gitcover.org pour connaître l’état actuel.