ED02 - Das KMU-Organisationsmodell: Tenants, Sphären, Rollen

Problem

Ein Unternehmer gründet eine Organisation - und steht vor der Frage: Wie strukturiere ich meine Organisation, dass Compliance-Pflichten sauber getrennt, nachvollziehbar und revisionssicher abgebildet werden?

Die heutige Praxis im KMU-Bereich kennt keine saubere Trennung:

• Alles in einem Topf - private und geschäftliche Unterlagen vermischen sich in einem Postfach, einem Laufwerk, einem Cloud-Account.
• Keine Tenant-Trennung - eine Holding mit mehreren Gesellschaften führt alle Bücher in einer Instanz, ohne dass klar ist, welche Aufzeichnung zu welcher Gesellschaft gehört.
• Keine Sphären-Trennung - bei Gemeinnützigkeit vermischen sich ideelle, vermögensverwaltende, zweckbetriebliche und wirtschaftliche Vorgänge in einem Konto, einem Ordner, einem Repo.
• Keine Rollen-Trennung - der Unternehmer macht alles selbst (GF, Buchhalter, Lohn, F&E), aber das Repo weiß nicht, in welcher Rolle er gerade handelt.
• Keine klare Identität - Aufzeichnungen haben keinen eindeutigen Identifikator, der sie einer Organisation, einer Sphäre, einer Rolle zuordnet.

Kernaussage

Eine Organisation als GitCover-Verbund zu strukturieren bedeutet: Tenant (Organisation), Sphäre (Tätigkeitsbereich bei Gemeinnützigkeit) und Rolle (Funktion des Akteurs) werden als Pflichtfelder jedes Artefakts definiert - nicht als optionale Metadaten. Git-Hooks prüfen bei jedem Commit, dass die Trennung vollständig ist. So entsteht Compliance by Design: Die Struktur der Organisation ist in der Struktur des Repos verankert.

Compliance by Design: Tenant, Sphäre und Rolle sind keine nachträglichen Etiketten - sie sind strukturelle Pflichtfelder, ohne die ein Artefakt nicht in das Repo aufgenommen wird.

Das Drei-Ebenen-Modell: Tenant, Sphäre, Rolle

Ebene 1 - Tenant (Organisation)

Ein Tenant ist eine rechtlich selbständige Organisationseinheit, für die eigene Aufzeichnungspflichten bestehen. Im GitCover-Verbund wird jeder Tenant als eigene Organization (Git User) mit zugeordneten Git-Repos (oder eigener Branch-Namespace) geführt.

Praxis-Beispiel: Ein Unternehmer (E1) führt eine Holding (ORG-1) mit zwei Töchtern (ORG-1a, ORG-1b). Jede Tochter ist ein eigener Tenant mit eigenem Repo. Die Holding hat ein Meta-Repo, das die Töchter über V7GUID-Referenzen verknüpft - aber die Bücher der Töchter bleiben getrennt.

Ebene 2 - Sphäre (Tätigkeitsbereich, nur bei Gemeinnützigkeit)

Die Sphäre ist nur bei gemeinnützigen Organisationen relevant - aber dann zwingend. Das Steuerrecht (§ 51–68 AO) verlangt die Trennung der vier Sphären, um die Gemeinnützigkeit nicht zu gefährden.

Risiko bei fehlender Sphären-Trennung: Vermögensmischung (§ 55 Abs. 1 Nr. 5 AO) ist ein Aberkennungsgrund für die Gemeinnützigkeit. Eine gemeinnützige Organisation, die wirtschaftliche und ideelle Vorgänge nicht trennt, riskiert die Aberkennung des gemeinnützigen Status - und damit Nachversteuerung der Rücklagen (bis zu 15(!) Jahre rückwirkend).

Ebene 3 - Rolle (Funktion des Akteurs)

Die Rolle dokumentiert, in welcher Funktion ein Akteur gehandelt hat. Das ist wichtig, weil in vielen Organisationen oft eine Person mehrere Rollen innehat (besonders bei KMU) - und weil die Rolle bestimmt, welche Pflichten greifen.

Praxis-Beispiel: Der Unternehmer E1 ist gleichzeitig GF, Buchhalter, Forscher, Entwickler und F&E-Leiter. Im Repo wird bei jedem Artefakt dokumentiert, in welcher Rolle er gehandelt hat - z. B. role: "GF" bei einem Beschluss, role: "F&E-Leiter" bei einem FZul-Stundennachweis. So bleibt nachvollziehbar, ob eine Aufzeichnung aus der GF-Perspektive (Verwaltung) oder der F&E-Perspektive (Forschung) entstand.

Rolle ist nicht Person: Die Rolle beschreibt die Funktion (und bei Erklärungen die vertretene Partei), nicht die Identität. Dieselbe Person kann an einem Dokument in mehreren Rollen handeln oder zeichnen; die technische Ausführungsidentität (Konto, Schlüssel) ist wieder eine eigene Ebene. Die fünf Ebenen Person · Funktion · vertretene Partei · Ausführungsidentität · Signaturhandlung sind in ED03 beschrieben.

Umsetzung im Git-Repo

Verzeichnisstruktur

ORG-1/                          # Tenant: KMU
├── .gitcover/                  # GitCover-Konfiguration
│   ├── LEGAL_ENTITY.gc.json   # Tenant-Identität (V7GUID)
│   ├── dictionaries/           # Sphären, Rollen, Beleg-Typen
│   └── schemas/                # JSON-Schemata für Artefakte
├── diary/                      # Tagebuch (SSoT)
│   ├── entries/                # Tages-Einträge
│   └── tenants/                # Tenant-Sichten (Symlinks)
├── registry/                   # Behörden-Identifikatoren
├── sources/                    # Belegarchiv (PDF, XML, EML)
├── sidecars/                   # .gc.md Sidecars
├── checks/                     # Fristen-Check, Sphären-Check
└── {weitere bei Bedarf}/

JSON-Artefakt mit Tenant, Sphäre, Rolle

Jedes Artefakt (Tagebucheintrag, Beleg, Grundbuch-Eintrag) enthält Tenant, Sphäre und Rolle als Pflichtfelder. Zentrales Kernprinzip der temporalen Nachvollziehbarkeit: Die Erfassungszeit ist kein separates Feld, sondern in der uuidV7 selbst verankert - als 48-Bit-Zeitstempel gemäß RFC 9562 §5.7. Die uuidV7 kann aus einer vorgegebenen Zeitmarke (nicht nur now()) via GitCover Helper (gc-v7guid) generiert werden, der Rest mit Zufall aufgefüllt. Damit ist die Erfassungszeit kryptographisch mit der Identität des Artefakts verknüpft und nicht nachträglich änderbar.

Wichtig - Was im Git-Repo landet: Nur diese strukturierten Artefakte (JSON-Einträge, Sidecars, Belege) werden ins Git-Repo aufgenommen. Private Dokumente werden nie ins Repo aufgenommen, sofern sie nicht ausdrücklich als Artefakt eingeführt und klassifiziert wurden. Was einmal drin ist, ist drin.

{
  "$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": "GF",
  "tenant": "ORG-1",
  "sphere": "ideell",
  "source": "E1",
  "source_sha256": "<SHA-256-...>",
  "tags": ["lohnabrechnung", "sv-meldung"]
}

Erläuterung Composite Key: V7GUID (Class Identifier) klassifiziert das Dokument/die Action anhand der .gitcover Registry (was/welcher Typ). uuidV7 (Object ID) ist der konkrete Objekt-Identifikator mit der vorgegebenen Zeitmarke (RFC 9562 §5.7, 48-Bit Unix-ms). Beide zusammen bilden den GCPN Sidecar Composite Key V7GUID:uuidV7. Eine separate datetime- oder date-String-Darstellung ist redundant und wird nicht in den Fakten geführt - der 48-Bit-Zeitstempel steckt bereits in der uuidV7. String-Darstellungen für DTO/HTMX-Transfer sind Harness-Verantwortung, nicht Fakten-Ebene.

Git-Hooks prüfen die Trennung

Tenant-Verbund: Mehrere Organisationen

Ein Tenant-Verbund (Holding mit Töchtern, Konsortium) wird über V7GUID-Referenzen verknüpft - nicht über gemeinsame Repos. Jeder Tenant behält seine eigene Buchführung, aber das Meta-Repo der Holding kann auf Belege und Einträge der Töchter verweisen, ohne sie zu kopieren.

Wichtig: Das Meta-Repo enthält keine Buchungen - nur Querverweise. Die Buchführung bleibt bei jedem Tenant. Das Meta-Repo ist eine Index-Ebene, keine Buchhaltungsebene.

Risiko-Leverage

Harness-Anforderung (Vorschau)

Aus ED02 ableitbar:

Die vollständige Anforderungsliste in Harness-Anforderungen.md.

Quellen

• AO (§§ 51–68 - Gemeinnützigkeit, Sphären-Trennung, § 55 Abs. 1 Nr. 5 - Vermögensmischung)
• EStG (§ 3 Nr. 26/26a - Pauschalen, Sphären-Bezug)
• GoBD (BMF-Schreiben, Verfahrensdokumentation, Tenant-Trennung)
• E1/agents/ (anonymisiert) - SSoT-Konzept mit Tenant, Sphäre, Rolle

Quellen-Topologie und CDN-Referenz-Links

Hinweis: Diese Zuordnung von Quellen, Mirror und Community-Hub spiegelt den aktuellen Stand wider und kann sich ändern. Bitte prüfen Sie die jeweilige kanonische Quelle auf gitcover.org für den aktuellen Zustand.