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 eigenes Git-Repo (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.

Umsetzung im Git-Repo

Verzeichnisstruktur

ORG-1/                          # Tenant: KMU
├── .gitcover/                  # GitCover-Konfiguration
│   ├── LEGAL_ENTITY.v7g.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/                   # .v7g.md Sidecars
└── checks/                     # Fristen-Check, Sphären-Check

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 wird aus einer vorgegebenen Zeitmarke (nicht now()) via GitCover Helper (UuidV7Gen) generiert, 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.

{
  "$schema": "https://gitcover.org/schemas/diary-entry-1.0.schema.json",
  "V7GUID": "<V7GUID-Class-aus-Registry>",
  "uuidV7": "<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)
• AFJD/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.