Diese Verfahrensdokumentation beschreibt die technischen und organisatorischen Maßnahmen, mit denen das System Zelino die Anforderungen der Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff (GoBD) erfüllt.

Sie richtet sich an Betriebsprüfer, Steuerberater und Rechtsanwälte und dient als Nachweis der ordnungsgemäßen Buchführung im Sinne der §§ 146, 147 AO sowie § 239 HGB.

Zelino ist ein cloudbasiertes Rechnungs- und Angebotssystem für Handwerker und kleine Unternehmen. Die technische Architektur besteht aus:

• Frontend: React-basierte Single-Page-Application (SPA)
• Backend: Supabase (PostgreSQL-Datenbank mit Row-Level Security)
• Serverseitige Logik: Supabase Edge Functions (Deno-basiert)
• Dateispeicherung: Supabase Storage mit zugriffskontrollierten Buckets
• PDF-Erzeugung: Selbstgehosteter Render-Service Gotenberg (Chromium-basiert, Docker) auf einem dedizierten Hetzner-Server in Deutschland. Der Zugriff erfolgt ausschließlich Basic-Auth- geschützt aus den Supabase Edge Functions über eine TLS-gesicherte Domain.
• E-Rechnung (ZUGFeRD 2.0 / PDF/A-3b): Konvertierung über iLoveAPI (EU); die ZUGFeRD-XML wird serverseitig generiert und in das vom Gotenberg erzeugte PDF eingebettet.

Die Datenbank, Authentifizierung und der Dateispeicher werden auf Servern in Frankfurt am Main, Deutschland (Supabase auf AWS Region eu-central-1) gehostet. Die PDF-Render-Infrastruktur läuft im Hetzner-Rechenzentrum Nürnberg, Deutschland. Sämtliche Datenübertragungen erfolgen ausschließlich über verschlüsselte Verbindungen (TLS 1.2+).

Das System unterstützt die Erstellung von Angeboten, Rechnungen (inkl. Teilrechnungen und Schlussrechnungen) sowie Eingangsrechnungen und Belegen.

Jedes Dokument erhält eine fortlaufende, lückenlose Dokumentennummer, die vom System automatisch vergeben wird. Pflichtfelder wie Dokumentdatum, Kundenname, Positionen mit Menge, Einzelpreis und Steuersatz werden bei der Erstellung validiert.

Die Umwandlung von Angeboten in Rechnungen erfolgt über eine dokumentierte Referenzkette (parent_document_id), die den Bezug zwischen Ursprungs- und Folgedokument nachvollziehbar macht.

Die Unveränderbarkeit finalisierter Dokumente wird auf drei Ebenen sichergestellt:

• Datenbank-Trigger: Der PostgreSQL-Trigger enforce_document_immutability verhindert jegliche Änderung an Dokumenten in terminalen Status. Für Rechnungen sind dies die Status sent, paid und cancelled; für Angebote accepted, rejected und cancelled.
• Storage-Schutz: Archivierte PDF-Dateien werden mit upsert: false gespeichert, was ein Überschreiben vorhandener Dateien auf Infrastrukturebene ausschließt.
• UI-Sperren: Die Benutzeroberfläche zeigt finalisierte Dokumente als schreibgeschützt an (Schloss-Symbol) und verhindert jede Bearbeitungsmöglichkeit.

Eine definierte Ausnahme erlaubt ausschließlich die Aktualisierung von Mahn-Metadaten (Mahnstufe, Mahngebühr) bei versendeten Rechnungen.

Bei der Finalisierung eines Dokuments (Versand per E-Mail oder manueller Statuswechsel) wird automatisch ein ZUGFeRD 2.0 konformes PDF/A-3b erzeugt und im geschützten Bucket archived-documents dauerhaft archiviert.

Die Archivierung unterstützt die je nach Dokumentart geltende gesetzliche Aufbewahrungsfrist von bis zu 10 Jahren:

• Archivierte Dateien können weder gelöscht noch überschrieben werden (upsert: false)
• Der Speicherpfad wird als relativer Pfad in der Datenbank hinterlegt (keine ablaufenden URLs)
• Bei jedem späteren Download, Export oder erneuten Versand wird das identische Original-PDF verwendet
• Für Eingangsrechnungen und Belege gelten dieselben Lösch- und Überschreibsperren auf Storage-Ebene

Datensicherung: Supabase erstellt automatische tägliche Backups der gesamten Datenbank. Zusätzlich können Nutzer jederzeit über das Steuerberater-Paket einen vollständigen Export aller steuerrelevanten Dokumente als ZIP-Archiv erstellen.

Alle geschäftsrelevanten Vorgänge werden lückenlos in den Tabellen document_audit_log und email_log protokolliert. Folgende Ereignisse werden erfasst:

• Erstellung: Dokument angelegt mit Zeitstempel und Benutzer-ID
• Versand: E-Mail-Versand inkl. Empfänger, Betreff und Resend-Message-ID
• Zahlung: Zahlungseingang mit Betrag und Zeitpunkt
• Stornierung: Stornierungsgrund und Zeitpunkt
• Signatur: Digitale Unterschrift mit IP-Adresse und User-Agent
• Umwandlung: Referenz zwischen Angebot und Rechnung

Die Audit-Log-Einträge sind schreibgeschützt: Row-Level-Security-Policies erlauben ausschließlich INSERT und SELECT – kein UPDATE oder DELETE. Dies stellt die Unveränderbarkeit des Prüfpfads sicher.

Der Zugriff auf Geschäftsdaten ist durch Row-Level Security (RLS) auf Datenbankebene geschützt. Jede Abfrage wird automatisch auf den authentifizierten Benutzer eingeschränkt (auth.uid() = user_id).

Dies bedeutet:

• Kein Benutzer kann Dokumente, Kunden oder Belege anderer Benutzer einsehen oder verändern
• Edge Functions validieren die Authentifizierung über JWT-Token vor jeder Operation
• Storage-Buckets sind durch benutzerspezifische Policies geschützt

Das System unterstützt zwei Signatur-Workflows für Angebote und Lieferscheine:

• Vor-Ort-Signatur: Der Kunde unterschreibt direkt auf dem Gerät des Handwerkers. Die Signatur wird als Bilddatei dem Dokument beigefügt.
• Remote-Signatur: Ein zeitlich begrenzter, einmalig verwendbarer Token-Link wird per E-Mail versendet. Bei der Unterschrift werden IP-Adresse und User-Agent des Unterzeichners in der Tabelle signature_tokens protokolliert.

Die elektronische Unterschrift ist eine einfache elektronische Signatur (SES) gemäß Art. 3 Nr. 10 eIDAS-VO (EU) Nr. 910/2014. Ihre Rechtsgültigkeit ergibt sich aus §127 BGB. Die Beweiskraft wird durch die umfassende Protokollierung (IP-Adresse, Geräteinformationen, Zeitstempel, Bestätigungserklärung) im Sinne des §286 ZPO (freie Beweiswürdigung) gestützt.

Nach der Signatur wechselt das Angebot in den Status accepted bzw. der Lieferschein in den Status signed und ist damit unveränderlich geschützt.

Finalisierte Dokumente können nicht gelöscht oder nachträglich geändert werden. Korrekturen erfolgen ausschließlich über das Stornierungsverfahren:

• Eine Stornierung erfordert die Angabe eines Stornierungsgrundes
• Der Zeitpunkt der Stornierung wird in cancelled_at festgehalten
• Das Originaldokument bleibt vollständig erhalten und wird als storniert gekennzeichnet
• Korrekturbelege (Gutschriften/Stornorechnungen) verweisen über parent_document_id auf das stornierte Original
• Alle Stornierungen werden im Audit-Log protokolliert
• Im DATEV-Export werden Stornobuchungen als Gegenbuchung zum Originalbeleg ausgewiesen

Dokumentnummern werden automatisch und fortlaufend vom System vergeben. Eine manuelle Änderung einzelner Dokumentnummern ist nicht möglich, um die lückenlose Nummerierung gemäß GoBD sicherzustellen.

Getrennte Nummernkreise: Rechnungen (RE-JJJJ-NNNN), Angebote (ANG-JJJJ-NNNN) und Lieferscheine (LS-JJJJ-NNNN) führen unabhängige Nummernkreise. Jeder Nummernkreis wird pro Kalenderjahr geführt.

Startnummer bei Systemwechsel: Beim Umstieg von einem Altsystem (z.B. Excel, Word, andere Rechnungssoftware) können Nutzer in den Einstellungen eine Startnummer für Rechnungen und Angebote festlegen, um nahtlos an die bisherige Nummerierung anzuknüpfen.

Sicherheitsmechanismus: Das System verwendet intern die Formel Math.max(höchste vorhandene Nummer + 1, konfigurierte Startnummer). Dadurch sind Doppelvergaben technisch ausgeschlossen – die Startnummer kann nicht unter die höchste bereits vergebene Nummer gesetzt werden.

Empfehlung zur Dokumentation des Systemwechsels: Für die Betriebsprüfung sollte der Umstellungszeitpunkt sowie die letzte im Altsystem vergebene Dokumentnummer schriftlich festgehalten werden. Dies erleichtert die Nachvollziehbarkeit der lückenlosen Nummerierung über Systemgrenzen hinweg.

Die integrierte Zeiterfassung protokolliert Arbeitszeiten von Mitarbeitern mit Start-/Endzeit, Pausen und optionaler GPS-Position. Für GoBD-Konformität gelten besondere Anforderungen:

• Manuelle Einträge werden mit dem Flag is_manual_entry gekennzeichnet
• Bei nachträglichen Änderungen wird der Änderungsgrund (edit_reason) verpflichtend erfasst
• Die Originalwerte vor der Änderung werden als Snapshot in original_values gespeichert
• Zeitpunkt und Urheber der Änderung werden in edited_at und edited_by festgehalten

Das System unterstützt einen dreistufigen Mahnprozess für überfällige Rechnungen mit konfigurierbaren Mahngebühren:

• Stufe 1: Zahlungserinnerung
• Stufe 2: 1. Mahnung (mit Gebühr)
• Stufe 3: Letzte Mahnung (vor gerichtlichem Mahnverfahren)

Überfällige Rechnungen werden automatisch anhand des effektiven Zahlungsziels erkannt – dabei wird die letzte Mahnfrist gegenüber dem ursprünglichen Fälligkeitsdatum herangezogen. Für jede Mahnstufe kann eine individuelle Zahlungsfrist festgelegt werden.

Abschlagsrechnungen können unabhängig von der Hauptrechnung gemahnt werden, da jede Abschlagsrechnung ein eigenes Zahlungsziel besitzt.

Jede Mahnung wird als eigenständiges ZUGFeRD-konformes PDF erzeugt und im geschützten Archiv dauerhaft gespeichert. Dabei werden die Beträge (Mahngebühr, Gesamtforderung) direkt aus der Historie bezogen, um Konsistenz zu garantieren.

Alle Mahnvorgänge werden lückenlos in der Tabelle reminder_history protokolliert:

• Mahnstufe (reminder_level)
• Mahngebühr (reminder_fee)
• Gesamtforderung (total_amount)
• Neue Zahlungsfrist (new_payment_deadline)
• Versandzeitpunkt (sent_at)

Die Mahnhistorie ist unveränderlich: Row-Level-Security-Policies erlauben ausschließlich INSERT und SELECT – kein UPDATE oder DELETE. Alle Mahnvorgänge sind damit im Audit-Trail vollständig nachvollziehbar.

Der primäre Export-Workflow ist das Steuerberater-ZIP-Paket, das alle steuerlich relevanten Unterlagen eines frei wählbaren Zeitraums bündelt. Es kann wahlweise direkt an die hinterlegte Steuerberater-E-Mail-Adresse versendet oder als lokaler ZIP-Download gespeichert werden.

Inhalt des ZIP-Pakets:

• Originalbelege in strukturierter Ordnerhierarchie (/Rechnungen, /Eingangsrechnungen, /Belege)
• Stundenzettel-CSV mit Zeiterfassungsdaten des Zeitraums (optional)
• Export-Übersicht (Textdatei) mit Finanzkennzahlen, USt-Voranmeldung, Zahlungsdetails und Hinweisen auf fehlende Dateien

Angebote werden bewusst vom Export ausgeschlossen, da sie keine steuerlich relevanten Buchungsvorgänge darstellen.

Stornobuchungen: Stornierte Rechnungen werden mit Stornierungsdatum dokumentiert und in der Export-Übersicht ausgewiesen.

Skonto-Behandlung: Bei Zahlungseingang wird ein Dialog angeboten, in dem der Nutzer zwischen Vollzahlung und Skonto-Zahlung wählen kann. Bei Skonto-Zahlung wird der tatsächlich vereinnahmte Betrag in paid_amount und die Skonto-Nutzung in skonto_used GoBD-konform gespeichert. Die Export-Übersicht listet alle Skonto-Zahlungen detailliert auf.

Abschlagsrechnungen: Bei existierenden Teilbelegen wird die Hauptrechnung automatisch vom Steuerberater-Paket ausgeschlossen, um Doppelbuchungen zu vermeiden.

Zahlungsdetails in der Export-Übersicht: Die Textdatei enthält eine vollständige Aufschlüsselung aller bezahlten Rechnungen, gruppiert nach Zahlungskondition (Skonto genutzt, Mahngebühren, ohne Besonderheiten). Für Eingangsrechnungen erfolgt eine Gruppierung nach Zahlungsart (Überweisung, Karte, Bar).

Zur Sicherstellung der GoBD-Unveränderbarkeit werden ausschließlich bereits archivierte Original-PDFs und -Bilder aus den Storage-Buckets verwendet – es findet keine Neugenerierung von Dokumenten statt.

Datenschutz: Die gesamte ZIP-Erstellung erfolgt clientseitig im Browser des Nutzers. GPS-Daten aus der Zeiterfassung sind aus Gründen der Datensparsamkeit (DSGVO) explizit vom Export ausgeschlossen. Der Datenzugriff erfolgt ausschließlich über RLS-geschützte Supabase-Abfragen.

Ergänzend zum ZIP-basierten Steuerberater-Export kann der Nutzer seinem Steuerberater einen permanenten, PIN-geschützten Lese-Zugang auf alle buchungsrelevanten Dokumente einräumen. Der Zugang erfolgt über einen Token-Link der Form /steuerberater/:token, der vom Nutzer in den Einstellungen erzeugt und jederzeit deaktiviert oder neu erzeugt werden kann.

• PIN-Pflicht: Bei Neuanlage eines Zugangs ist die Vergabe eines PINs technisch erzwungen (RPC create_steuerberater_access_with_pin). Der PIN wird ausschließlich gehasht (bcrypt via pgcrypto) gespeichert.
• Lese-Rechte: Der Steuerberater sieht ausschließlich buchungsrelevante Dokumente (Rechnungen, Eingangsrechnungen, Belege). Angebote und Lieferscheine sind ausgeschlossen.
• Protokollierung: Jeder Portal-Zugriff wird in der Tabelle steuerberater_access_log mit Zeitstempel protokolliert.
• Verantwortlichkeit: Der Nutzer stellt sicher, dass der Steuerberater die Zugangsdaten (Link + PIN) getrennt und vertraulich erhält.
• Datenbasis: Das Portal greift über dieselben RLS-gesicherten Abfragepfade wie der Nutzer selbst, es werden ausschließlich archivierte Original-PDFs ausgeliefert (GoBD-Unveränderbarkeit).

Bei einer Kontolöschung durch den Nutzer wird ein GoBD- und DSGVO-konformer Lösch-Workflow ausgeführt, der das Recht auf Löschung (Art. 17 DSGVO) mit den steuerlichen Aufbewahrungspflichten (§ 147 AO) in Einklang bringt:

• Pseudonymisierung: Personenbezogene Daten (Name, E-Mail, Adresse, IBAN) werden durch Platzhalter ersetzt
• Archivierung: Steuerlich relevante Dokumente und Belege bleiben soweit möglich pseudonymisiert für die je nach Dokumentart geltende gesetzliche Frist von bis zu 10 Jahren erhalten
• Löschprotokoll: Anzahl archivierter Kunden und Dokumente wird in account_deletions festgehalten
• Automatische Bereinigung: Eine Scheduled Edge Function (cleanup-archived-data) löscht archivierte Daten nach Ablauf der Aufbewahrungsfrist endgültig

Die Löschung erfordert eine Passwort-Bestätigung und zeigt dem Nutzer vorab eine Zusammenfassung aller betroffenen Datensätze an.

Das System unterstützt den Import von elektronischen Rechnungen in den Formaten ZUGFeRD 2.0 und XRechnung (UN/CEFACT CII und UBL). Bei Hybrid-PDFs wird die eingebettete XML-Datei automatisch extrahiert.

Unveränderbarkeit: Eingangsrechnungen unterliegen denselben GoBD-Schutzmaßnahmen wie Ausgangsrechnungen. Der Trigger enforce_incoming_invoice_status_immutability erlaubt ausschließlich die Übergänge open → paid und open → cancelled. Bezahlte oder stornierte Eingangsrechnungen können weder gelöscht (prevent_incoming_invoice_deletion) noch inhaltlich verändert werden.

Original-PDFs und -XMLs werden im geschützten Bucket incoming-documents dauerhaft archiviert.

Das System ermöglicht eine chronologische Dokumentation von Baustellen in Form einer Chat-Timeline. Nutzer können Texteinträge und Fotos erfassen, die automatisch mit Zeitstempel versehen werden.

GoBD-Relevanz: Die Baustellen-Dokumentation dient als Nachweis für erbrachte Leistungen, insbesondere bei Baustellendokumentation und handwerklichen Tätigkeiten.

• Bildspeicherung: Fotos werden im Storage-Bucket project-images dauerhaft archiviert. Vor dem Upload werden Bilder clientseitig komprimiert (max. 1920px), um Speicherplatz effizient zu nutzen.
• Datenbankstruktur: Einträge werden in der Tabelle project_documentation gespeichert, verknüpft über project_id mit der zugehörigen Baustelle.
• Zugriffskontrolle: Row-Level Security stellt sicher, dass nur der Eigentümer einer Baustelle deren Dokumentation einsehen und bearbeiten kann.
• Baustellenbilder-Galerie: Zusätzliche Bilder können in der Tabelle project_images mit optionalen Bildunterschriften erfasst werden.

Baustellen können mit Kunden und Dokumenten verknüpft werden, sodass eine vollständige Zuordnung von Angeboten, Rechnungen und Zeiterfassungseinträgen zur jeweiligen Baustelle nachvollziehbar ist.

Lieferscheine dokumentieren die Erbringung von Leistungen und die Lieferung von Waren. Sie dienen als Leistungsnachweis und können mit Baustellen sowie Rechnungen verknüpft werden.

Nummernkreis: Lieferscheine verwenden einen eigenständigen Nummernkreis (LS-JJJJ-NNNN), der unabhängig von Rechnungen und Angeboten fortlaufend und lückenlos vergeben wird.

Status-Workflow:

• Entwurf: Bearbeitbar, noch nicht versendet
• Gesendet: Per E-Mail an den Kunden übermittelt, unveränderlich geschützt
• Unterschrieben: Vom Kunden digital signiert (Vor-Ort oder Remote-Signatur)
• Abgelehnt: Vom Kunden abgelehnt mit Begründung
• Storniert: Vom Ersteller storniert mit Stornierungsgrund

Signatur-Workflow: Identisch mit der Angebots-Signatur – sowohl Vor-Ort- als auch Remote-Signatur per Token-Link werden unterstützt. IP-Adresse und User-Agent des Unterzeichners werden protokolliert.

Archivierung: Finalisierte Lieferscheine werden als PDF im geschützten Bucket archived-documents archiviert. Der Immutability-Trigger schützt Lieferscheine im Status sent, signed und cancelled vor nachträglichen Änderungen.

Buchhaltungsrelevanz: Lieferscheine sind nicht buchungsrelevant – sie erscheinen weder im DATEV-Export noch in ZUGFeRD-Dokumenten und unterliegen keinem Mahnwesen.

Das System nutzt OpenAI API, Google Gemini API und für die visuelle Erkennung bestimmter Eingangsrechnungen Google Gemini über Lovable AI Gateway zur Unterstützung bei der Datenerfassung und Texterstellung. Die KI-Verarbeitungen werden über serverseitige Edge Functions ausgelöst und unterliegen den jeweiligen Auftragsverarbeitungs- und Datenschutzvereinbarungen.

Einsatzbereiche:

• Belegerkennung (Google Gemini): Beim Upload eines Belegfotos erkennt die Edge Function parse-receipt automatisch Betrag, Datum, Händlername, Steuersatz und Kategorie. Der Nutzer prüft und bestätigt die extrahierten Daten vor dem Speichern.
• Spracheingabe: Positionsbeschreibungen können per Mikrofon diktiert werden. Die Edge Function transcribe wandelt die Audioaufnahme in Text um.
• Dokumenten-Chat: Im Editor steht ein KI-Assistent zur Verfügung, der bei der Formulierung von Positionstexten unterstützt. Die Chat-Verläufe werden in der Tabelle document_chat_messages gespeichert.
• Textverbesserung: Einzelne Positionsbeschreibungen können über die Edge Function enhance-description professionell umformuliert werden.
• Baustellendokumentation und Aufmaß: Diktate können strukturiert, Skizzen durch Google Gemini ausgewertet und Aufmaß-, Plausibilitäts- oder Angebotsvorschläge durch OpenAI erzeugt werden.
• Eingangsrechnungen: Strukturierte XML-Daten werden regelbasiert verarbeitet. Bei unstrukturierten PDFs kann extrahierter Rechnungstext an OpenAI übermittelt werden. Bilder und visuelle PDF-Inhalte können über den Lovable AI Gateway durch Google Gemini ausgewertet werden.

Wichtig für die GoBD-Konformität: KI-generierte Inhalte werden nicht automatisch übernommen. Der Nutzer hat stets die volle Kontrolle und muss vorgeschlagene Texte aktiv bestätigen oder anpassen. Die endgültige Verantwortung für die Richtigkeit der Dokumenteninhalte liegt beim Nutzer.

Datenschutz: Abhängig von der Eingabe können auch personenbezogene Kunden-, Lieferanten- oder Beschäftigtendaten enthalten sein. Vor der ersten Übermittlung für jede KI-Funktion zeigt Zelino Funktion, Datenarten und Empfänger an und startet die KI-Anfrage erst nach ausdrücklicher Zustimmung für diese Funktion. Der Nutzer soll Eingaben auf das erforderliche Maß beschränken und kann die Zustimmung in den Einstellungen zurückziehen. Informationen zu Auftragsverarbeitern sind unter Auftragsverarbeitungsverträge einsehbar.