Dieser Erfahrungsbericht ist anonymisiert (Organisation ORG-1, Unternehmer E1). Er beschreibt, wie aus einer wiederkehrenden Büro-Aufgabe — Bewirtungsbelege sammeln, nachweisen, ablegen — ein kleines, regelbasiertes Tooling wurde. Die Lehre ist weniger technisch als strukturell: Wenn ein Beleg ohnehin digital nachgewiesen wird, gehört der Nachweis zur Unterschrift — nicht daneben.

Ausgangslage

ORG-1 ist gemeinnützig und führt für E1 auch Aufwendungsersatz. Bei Bewirtungen aus geschäftlichem Anlass verlangt § 4 Abs. 5 Satz 1 Nr. 2 EStG einen Nachweis mit Ort, Tag, Teilnehmern, Anlass und Höhe; in der Gaststätte genügen Anlass und Teilnehmer plus beigefügte Rechnung. Das BMF-Schreiben vom 19.11.2025 stellt klar: Der Eigenbeleg darf digital sein, wenn er zeitnah erstellt, elektronisch signiert oder genehmigt, eindeutig mit der Rechnung verknüpft und GoBD-konform dokumentiert ist.

Der übliche Weg — Rechnung scannen, handschriftlichen Eigenbeleg-Block ausfüllen, abheften — ist medienbrüchig. Die Frage war: Wie hält man es git-nativ?

Die fünf Schritte, die sich bewährt haben

1. Scannen — der Gaststättenbeleg wird als Ur-Doc (PDF) abgelegt.
2. OCR — aus dem Beleg wird der Text ermittelt; sein Vertrauensgrad (TrustVector, Start 0x0001 = maschinell ungeprüft) wird festgehalten.
3. Belegart erkennen — regelbasiert aus dem OCR-Text: hier BUSINESS_MEAL_RECEIPT (Merkmale: „Bewirtungsaufwendungen", „Bewirtete Personen", „Anlass der Bewirtung").
4. Signaturvorgang — es entsteht ein Signatur-Artefakt (*.gcsig.md), das den digitalen Eigenbeleg trägt: die Angaben als eingebetteter Inhalt, die OCR-Provenienz, den Signatur-Block mit Facsimile und die Sidecar-Metadaten.
5. Präsentieren und zeichnen — das Artefakt wird zur Zeichnung vorgelegt (presented) und nach Freigabe auf accepted/signed gesetzt.

Die eigentliche Entscheidung: kein Beleg „neben" dem Beleg

Konzeptionell naheliegend wäre gewesen, zwei Dateien zu führen: einen herkömmlichen Sidecar und ein separates Signatur-Artefakt. Genau das erzeugt aber konkurrierende Metadaten zur selben Quelle — zwei Identitäten, die auseinanderlaufen können.

Die bewährte Regel lautet deshalb: Wird ein Beleg signiert, wandert der Sidecar-Inhalt vollständig in das Signatur-Artefakt. Das *.gcsig.md trägt Anker (SHA-256 des Ur-Docs), Inhalt, OCR-Provenienz und die Klassifizierungs-Metadaten (Taxonomie, Sphäre, Ablageorte, Tags, Zweck) in einem Dokument. Es bleiben zwei Dinge übrig: der Ur-Doc und sein Signatur-Artefakt — kein „Sidecar-über-Bescheid".

Werkzeuge, die Belege automatisch einsammeln, mussten dafür umdenken: Sie erkennen ein *.gcsig.md als gleichwertigen Beleg-Träger und erzeugen kein zweites Sidecar mehr. Sonst „entdoppelt" sich der Bestand beim nächsten Lauf ungewollt wieder.

Warum das revisionssicher bleibt

Der eigentliche Beweis-Anker ist die Quelle: der SHA-256 des gescannten Belegs. Er ändert sich nie; jede inhaltliche Änderung erzeugt einen neuen Beleg-Stand. Das Artefakt selbst ist dagegen ein mutabler Container — wie ein Prozess-Dokument. Seine Zustandsänderungen (Signatur-Phasen) werden über GPG-signierte Commits zu einem Audit-Ledger. Wichtig: Die bloße Git-Historie genügt nicht (force-push wäre denkbar) — erst die Signatur über den Commit macht die Kette history-rewrite-fest.

Was übrig bleibt

Am Ende steht ein Vorgang, der wenige, klar benannte Artefakte und wenige, klar benannte Werkzeuge kennt: einen Scanner/Erfasser, eine Belegart-Erkennung und ein Signatur-Werkzeug. Der Beleg ist einmal da, sein Nachweis ist einmal da, und die Unterschrift ist Teil des Nachweises — nicht ein handschriftlicher Zettel daneben.

Die ausführliche, nicht anonymisierte Fassung des Verfahrens (Rechtsgrundlagen, Schrittfolge, Artefakt-Aufbau) findet sich im GitCover Body of Knowledge, Artikel ED13 „Aufgabe: Bewirtungsbelege scannen und verarbeiten".