ED13 - Tâche : scanner et traiter les justificatifs de frais de réception
Déclencheur : Une réception à titre professionnel a eu lieu ; l'établissement de restauration a émis une facture (restaurant). Les dépenses doivent être reconnues comme charges d'exploitation déductibles — à cette fin, la preuve exigée par la loi doit être fournie (§ 4 Abs. 5 Satz 1 Nr. 2 EStG).
Ce que la loi exige
- § 4 Abs. 5 Satz 1 Nr. 2 EStG : 70 % des dépenses sont déductibles, dans la mesure où elles sont appropriées et où leur montant et leur motif professionnel sont justifiés. Pour la justification, il faut indiquer par écrit : lieu, date, participants, motif de la réception, ainsi que le montant des dépenses. Si la réception a eu lieu dans un restaurant, les indications relatives au motif et aux participants suffisent ; la facture doit être jointe. En outre, les frais de réception doivent être enregistrés séparément, frais par frais (§ 4 Abs. 7 EStG).
- Lettre BMF du 19.11.2025 (IV C 6 - S 2145/00026/005/033, remplace 30.6.2021) : Le justificatif interne peut être créé numériquement ; l'autorisation est accordée au moyen d'une signature électronique ou d'une approbation électronique (aucune signature qualifiée n'est nécessaire). Il faut une création en temps utile, un horodatage de création et de signature figurant dans le document, une liaison univoque entre le justificatif et le justificatif interne (p. ex. renvoi/index), ainsi qu'une conformité GoBD incluant la documentation des procédures (BMF 28.11.2019).
La tâche en cinq étapes
- Scanner — Le justificatif papier/restaurant est photographié/scanné et archivé comme document original (p. ex. PDF) dans le répertoire des justificatifs.
- Extraction par OCR — Le texte interprétable (
ocr.txt) est extrait du justificatif et documenté avec sa qualité/confiance (TrustVector-BitVector, valeur initiale0x0001=machine-unverified). - Reconnaître le type de justificatif — Le type de justificatif est déterminé à
partir du texte OCR à l'aide de règles : ici
BUSINESS_MEAL_RECEIPT(justificatif de frais de réception ; reconnu par « frais de réception », « personnes reçues », « motif de la réception »). - Reprendre dans le processus de signature — Un
*.gcsig.md(artefact de signature, classeGCSIG) est créé, qui porte le justificatif interne numérique : les mentions exigées par la loi sous la forme d'uncontentintégré (schémabusiness-meal-receipt-1.0), la provenance OCR (ocr), le bloc sidecar intégré (source) et le bloc de signature (signature) avec le fac-similé du signataire. - Présenter et signer — L'artefact passe au statut
presented, est soumis à l'intervenant humain (HITL) pour signature et, après approbation, passe aux statutsaccepted→signed. L'ancrage de la signature est le SHA-256 du document original.
L'artefact : justificatif et signature dans un document
Pour les justificatifs repris dans le processus de signature, aucun .v7g.md
distinct n'est nécessaire : le *.gcsig.md assume intégralement la fonction
sidecar (règle « Fonction sidecar/transition » : le .v7g.md devient le
.gcsig.md, sans perte d'information ni sidecars concurrents). À partir du schéma
gcsig-1.4, il contient :
| Bloc | Contenu |
|---|---|
subject / sha256 |
le document original (PDF) avec son SHA-256 comme ancrage de preuve |
content |
les mentions du justificatif interne (business-meal-receipt-1.0) |
ocr |
texte OCR intégral + TrustVector (provenance) |
source |
métadonnées sidecar intégrées : taxonomie V7GUID, tenant/catégorie, sphère, emplacements de stockage, tags, finalité, FZul, références GCPN |
signature |
signataire, procédure (§ 126b BGB), référence du fac-similé |
phases |
cycle de vie sous forme d'un BitVector de 32 bits : draft → presented → accepted → signed (orthogonal verified) |
Sécurité en matière de révisions — Conformité Git-native
- L'ancrage est immuable : le SHA-256 du document original. Il ne change jamais ; chaque modification de contenu produit un nouvel état du document original.
- Le
*.gcsig.md(comme le GCPN) est un conteneur mutable, dont les changements d'état (phases) sont consignés dans un registre d'audit au moyen de commits Git signés GPG. Le seul historique Git ne suffit pas (force-push possible) — d'où la signature portant sur le commit/le GCSIG. - Les modifications du contenu du justificatif interne sont ainsi traçables ; l'état signé à chaque instant reste conservé dans l'historique.
Exemple (série : organisation fictive KMU)
Le directeur général de KMU offre une réception après un salon professionnel
à un représentant d'un éditeur spécialisé, afin de discuter d'une publication
éventuelle. Le justificatif de restaurant de 59,80 € est scanné ; l'OCR permet
de déterminer le type de justificatif BUSINESS_MEAL_RECEIPT. Le justificatif
interne est créé sous forme de *.gcsig.md (participants, motif « salon professionnel —
publication éventuelle », montant, sphère ideell, sans déduction de TVA,
comptabilisation comme remboursement de dépenses) et soumis au directeur général
pour signature.
Outils
| Outil | Tâche |
|---|---|
gc-sidecar scan |
Enregistrer le document original (SHA-256), extraire le texte OCR + la confiance |
gc-sidecar detect |
Reconnaître le type de justificatif à partir du texte OCR (sur la base de règles) |
gc-docsign gcsig |
Créer/intégrer le *.gcsig.md (--content, --ocr, --source, --facsimile) et définir les phases |
Références
- Fondements juridiques : § 4 Abs. 5 Satz 1 Nr. 2 und Abs. 7 EStG; R 4.10 EStR; BMF 19.11.2025; GoBD (BMF 28.11.2019).
- Signature/Sidecar : voir GCBoK, partie VI (Digital Signage) — GCSIG et la transition
.v7g.md→.gcsig.md. - Classement des justificatifs : ED06.