ED13 - Tâche : scanner et traiter les justificatifs de restauration
Déclencheur : une invitation de restauration à caractère professionnel a eu lieu ; l'établissement de restauration a émis une facture (restaurant). Les dépenses doivent être faire valoir comme charge d'exploitation — pour cela, il faut établir la preuve légale (§ 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 que le montant et le lien avec l'activité professionnelle sont justifiés. Pour la preuve, il faut indiquer par écrit : lieu, date, participants, motif de l'invitation ainsi que le montant des dépenses. Si l'invitation a eu lieu dans un restaurant, des indications sur le motif et les participants suffisent ; la facture doit être jointe. En outre, les dépenses de restauration doivent être enregistrées individuellement et séparément (§ 4 Abs. 7 EStG).
- Circulaire du BMF du 19.11.2025 (IV C 6 - S 2145/00026/005/033, remplace le 30.6.2021) : le justificatif interne peut être établi numériquement ; l'autorisation s'effectue par signature électronique ou approbation électronique (aucune signature qualifiée nécessaire). Sont requis un établissement en temps utile, l'horodatage de création et de signature dans le document, une liaison biunivoque entre le justificatif et le justificatif interne (p. ex. référence/index) ainsi que la conformité GoBD, y compris la documentation des procédures (BMF 28.11.2019).
La tâche en cinq étapes
- Scanner — le justificatif papier/restaurant est photographié/scanné et déposé comme document original (p. ex. PDF) dans le répertoire des justificatifs.
- Saisie OCR — à partir du justificatif, le texte interprétable
(
ocr.txt) est déterminé et documenté avec sa qualité/confiance (TrustVector-BitVector, début0x0001=machine-unverified). - Reconnaître le type de justificatif — à partir du texte OCR, le type de justificatif
est déterminé selon des règles : ici
BUSINESS_MEAL_RECEIPT(justificatif de restauration ; reconnu à « Bewirtungsaufwendungen », « Bewirtete Personen », « Anlass der Bewirtung »). - Intégrer au processus de signature — un
*.gcsig.md(artefact de signature, classeGCSIG) est généré ; il porte le justificatif interne numérique : les mentions légalement exigées commecontentintégré (schémabusiness-meal-receipt-1.0), la provenance OCR (ocr), le bloc sidecar intégré (source) et le bloc de signature (signature) avec fac-similé de la personne signataire. - Présenter et signer — l'artefact est mis à
presented, présenté à l'humain (HITL) pour signature, puis, après validation, mis àaccepted→signed. L'ancre de la signature est le SHA-256 du document original.
L'artefact : justificatif et signature dans un seul document
Pour les justificatifs intégrés au processus de signature, aucun .gc.md séparé
n'est nécessaire : le *.gcsig.md porte entièrement la fonction sidecar
(règle « Sidecar-Funktion/Übergang » : le .gc.md devient le .gcsig.md,
aucune perte d'information, aucun sidecar concurrent). À partir du schéma
gcsig-1.4, il contient :
| Bloc | Contenu |
|---|---|
subject / sha256 |
le document original (PDF) avec son SHA-256 comme ancre de preuve |
content |
les mentions du justificatif interne (business-meal-receipt-1.0) |
ocr |
texte intégral OCR + 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 au fac-similé |
phases |
cycle de vie sous forme de BitVector 32 bits : draft → presented → accepted → signed (orthogonal verified) |
Sécurité de révision — conformité native Git
- L'ancre est immuable : le SHA-256 du document original. Elle ne change jamais ; toute modification de contenu génère un nouvel état du document original.
- Le
*.gcsig.md(comme le GCPN) est un conteneur mutable dont les changements d'état (phases) deviennent un registre d'audit grâce à des commits Git signés GPG. L'historique Git seul ne suffit pas (force-push possible) — d'où la signature sur le commit/le GCSIG. - Les modifications du contenu du justificatif interne sont ainsi traçables ; l'état signé correspondant reste conservé dans l'historique.
Exemple (série : organisation fictive KMU)
Le directeur général de KMU invite, après un salon professionnel, un représentant
d'une maison d'édition spécialisée afin de discuter d'une éventuelle publication. Le
justificatif de restaurant de 59,80 € est scanné ; via OCR, le type de justificatif
BUSINESS_MEAL_RECEIPT est reconnu. Le justificatif interne est généré sous forme de *.gcsig.md
(participants, motif « Salon professionnel — publication possible », montant, sphère
ideell, sans déduction de la TVA en amont, comptabilisation comme remboursement de frais) et présenté
au directeur général pour signature.
Outils
| Outil | Tâche |
|---|---|
gc-sidecar scan |
Saisir le document original (SHA-256), déterminer le texte OCR + la confiance |
gc-sidecar detect |
Reconnaître le type de justificatif à partir du texte OCR (basé sur des règles) |
gc-docsign gcsig |
Générer/intégrer *.gcsig.md (--content, --ocr, --source, --facsimile) et définir les phases |
Références
- Bases légales : § 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
.gc.md→.gcsig.md. - Classement des justificatifs : ED06.