opengewerk-kanzlei
OpenGewerk Kanzlei ist ein self-hosted System für Steuerberaterkanzleien, das beliebig viele Mandanten-Instanzen anbindet und Daten zentralisiert, ohne die Datenhoheit der Mandanten zu gefährden.
Ficha actualizada 23 sept 2026, 10:35 · upstream 23 sept 2026, 10:17 · release sin release detectada
Qué es opengewerk-kanzlei
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
OpenGewerk Kanzlei ist ein zentrales, selbst gehostetes System für Steuerberaterkanzleien, das beliebig viele Mandanten-Instanzen der Handwerkersoftware anbindet. Der Leitsatz lautet Föderation statt Zentralisierung: Der Hub speichert keine Buchhaltung, er greift per API live auf die Mandantensysteme zu und hält nur einen Cache für Übersichten. Die Datenhoheit bleibt beim Mandanten, und genau das ist das Argument gegenüber DATEV Unternehmen online. Lesender Zugriff ist der Default, schreibende Rechte gibt der Mandant einzeln pro Scope frei und kann sie jederzeit widerrufen. Die Verbindung wird immer vom Mandanten aus aufgebaut, damit kein Betrieb ohne sein Wissen angebunden werden kann. Verschwiegenheit nach §203 StGB und §57 StBerG, Mandantentrennung und Zugriffsprotokollierung sind Architekturanforderungen, keine Features.
Die Abgrenzung zu bestehenden Lösungen zeigt, dass Kanzlei-Hub die Schwächen von DATEV Unternehmen online (Daten liegen zentral bei DATEV, laufende Kosten je Mandant, fehlender Handwerkersoftware-Kontext) mit den Stärken von sevdesk/Lexware Steuerberaterzugang (Ein Login pro Mandant, keine Kanzleiübersicht, keine Fristen über Mandanten hinweg) kombiniert. Ein Login pro Mandant ist hier nicht nötig; eine einzige Anwendung enthält alle Mandanten und bietet Gesundheitsindex, Fristenkalender und Rückfragen am Beleg.
So funktioniert die Anbindung: Der Mandant erzeugt in seiner Handwerkersoftware unter Einstellungen → Steuerberater einen Einladungscode (einmalig, 24 Stunden gültig) und wählt die freizugebenden Scopes. Die Kanzlei gibt Code und Mandanten-URL im Hub ein. Der Hub tauscht den Code gegen einen langlebigen, rotierbaren Token (ähnlich OAuth 2.0 Device- oder Authorization-Code-Flow). Die kryptografische Bindung des Tokens an die Hub-Instanz erfolgt über mTLS oder DPoP nach der ersten Fassung.
Welche Scopes es gibt und was sie umfassen, steht in docs/konzept/Planungskonzept.md Abschnitt 2.5 sowie in der Spezifikation unter opengewerk-api-spec.
- Ein Mandant nutzt die Kanzlei-Instanz als zentrale Schnittstelle zu allen seiner Handwerkersoftware (z.B. Agenda, Addison), um alle Mandanten aus einer Anwendung heraus zu bearbeiten
- Der Steuerberater kann in der Kanzlei-Instanz alle Mandanten sehen und bearbeitet, ohne dass er jede Mandantenschnittstelle einzeln öffnen muss
- Fristenkalender und Gesundheitsindex werden für alle Mandanten in einer einzigen Ansicht bereitgestellt, was die Übersicht über Fristen verbessert
- Rückfragen an Belege können von jedem Mandanten aus der Kanzlei-Instanz gestellt werden, ohne dass ein neuer Login nötig ist
- Der Mandant kann jederzeit die Verbindung zur Kanzlei trennen und wiederherstellen, ohne dass andere Mandanten betroffen sind
- Verschiedene Mandanten können in verschiedenen Scopes (z.B. nur bestimmte Belege bearbeiten) verbunden sein, was eine granulare Zugriffskontrolle ermöglicht
- Der Hub ist selbst-hosted und keine Daten werden bei DATEV oder anderen Anbietern gespeichert
- Datenhoheit beim Mandanten bleibt erhalten; der Hub greift nur per API auf die Mandantensysteme zu
- Die Verbindung wird immer vom Mandanten aus aufgebaut, was eine passive Anbindung verhindert
- Verschwiegenheitsgesetze (§203 StGB, §57 StBerG) und Mandantentrennung sind in der Architektur integriert
- Zugriffsprotokollierung ist als Architekturanforderung implementiert, nicht als Feature
- Der API-Vertrag wird in Version 1 definiert und unterstützt von Hub und Handwerkersoftware
- Die erste Phase des Projekts verlangt den API-Vertrag in Version 1 und das Connector-Modul in der Handwerkersoftware, was Zeit benötigt
- Vorher gibt es hier nichts zu bauen, was nicht ins Leere liefe; vorziehen lässt sich allein der Vertrag in opengewerk-api-spec
- Die kryptografische Bindung des Tokens an die Hub-Instanz über mTLS oder DPoP ist noch nicht vollständig implementiert
- Der vollständige API-Vertrag und das Connector-Modul liegen noch nicht als lauffähiges Produkt vor
Capturas del proyecto
Imágenes reales detectadas en la documentación del repositorio.
Perfil de infraestructura
Estimación inicial derivada del repositorio y de los servicios detectados.
Despliegue detectado
Qué señales reales de instalación hemos encontrado.
OpenGewerk Kanzlei wird in einer eigenen Instanz gehostet, die über einen Reverse Proxy (z.B. Nginx) erreichbar ist. Der Hub selbst läuft auf einem Server mit mindestens 1 CPU Core und 1 GB RAM. Für die API-Verbindung werden mTLS oder DPoP als Transportprotokoll empfohlen. Die Datenbank wird lokal gespeichert; keine Daten werden in der Cloud abgelegt. Der Mandant muss den Hub nicht aktiv installieren, sondern kann ihn über eine URL aus seiner Handwerkersoftware aufrufen. Der Code ist im Repository unter opengewerk-kanzlei verfügbar und sollte von einer lokalen Instanz ausgeführt werden.
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
Puede sustituir a
Relaciones detectadas por el análisis del repositorio y su categoría.
Experiencia real de la comunidad
Ayuda a contrastar la estimación automática con instalaciones reales.
Todavía no hay datos comunitarios para este proyecto.