Verfahrensdokumentation

Rechnungs-Kontor – Version 1.2 – Stand: 21. Mai 2026
Dokumenten-ID: VD-RK-2026-001

Diese Verfahrensdokumentation beschreibt den Umgang mit Belegen, Daten und Verarbeitungsprozessen in Rechnungs-Kontor. Sie ist gemäss GoBD-Schreiben des BMF vom 28. November 2019 in der Fassung der 2. Änderung vom 14. Juli 2025, Rn. 151 ff., Pflichtbestandteil der ordnungsmässigen Buchführung eines jeden Mandanten, der das System einsetzt. Sie ergänzt – aber ersetzt nicht – die individuelle Verfahrensdokumentation der Kanzlei und ihrer Mandanten.

1. Zweck und Geltungsbereich

Rechnungs-Kontor ist ein konzentrierter E-Rechnungs-Eingangskanal für Steuerberatungskanzleien. Jeder Mandant der Kanzlei kann Eingangsrechnungen in beliebigem Format (XRechnung, ZUGFeRD, PDF, Foto, Scan) an eine persönliche E-Mail-Adresse weiterleiten oder über einen tokenisierten Hochladen-Link einreichen. Das System erfasst, validiert, archiviert und stellt die Belege der Kanzlei in einer monatsweise abschliessbaren Übersicht zur Verfügung. Am Monatsende erzeugt es einen vollständigen DATEV-Format-Stapel nebst Vorsteuer-Aufstellung und Originalbelegen.

Diese Verfahrensdokumentation gilt für den Lebenszyklus eines Belegs ab dem Zeitpunkt seines Eingangs bei Rechnungs-Kontor bis zur Übergabe an die Kanzlei-Buchhaltungssoftware (DATEV Rechnungswesen, Lexware Office, sevDesk, Agenda, STOTAX oder vergleichbare Systeme, die das DATEV-Format als Importschnittstelle unterstützen).

Rechtsgrundlagen: §§ 145 bis 147 AO, § 14 / § 14a / § 14b UStG, § 257 HGB, GoBD-Schreiben in der jeweils gültigen Fassung.

2. Systemüberblick

Rechnungs-Kontor besteht aus drei Schichten:

Edge-Schicht

Cloudflare Pages Functions (Frankfurt-PoP). Statische Inhalte, Authentifizierung, Anwendungslogik. Keine dauerhafte Speicherung personenbezogener Daten.

Daten-Schicht

PostgreSQL 18 auf einem privaten Hetzner-Cloud-Server in Nürnberg, Deutschland. Datenbankport ist nicht öffentlich erreichbar; Zugriff ausschliesslich über verschlüsselten Cloudflare-Tunnel.

Archiv-Schicht

Hetzner Object Storage (S3-kompatibel), Bucket „rk-invoices“, Rechenzentrum Nürnberg. Versionierung aktiv. Inhalts-adressiert über SHA-256.

Für die Verarbeitung von handschriftlichen, fotografierten oder rein bildbasierten Belegen sowie für den ergänzenden Kontierungsvorschlag wird Mistral AI (Paris, Frankreich) als Auftragsverarbeiter eingesetzt. Mistral verarbeitet ausschliesslich während der Erkennungs- bzw. Klassifikationsphase; eine Speicherung beim Anbieter findet nicht statt, eine Verwendung der Daten zu Modelltrainingszwecken ist vertraglich ausgeschlossen.

Eingehende Mandanten-E-Mails werden über Mailgun (EU-Region, Belgien) entgegengenommen, signiert weitergeleitet und vom System HMAC-verifiziert. Ausgehende Bestätigungs-E-Mails an Mandanten und Lieferanten erfolgen über Resend (EU-Region, Irland).

3. Verantwortlichkeiten

Verantwortlicher

Steuerpflichtiger Mandant der Kanzlei (Buchführungspflichtiger).

Beauftragter Datenverarbeiter

Die Kanzlei (im Verhältnis zum Mandanten) und Rechnungs-Kontor (im Verhältnis zur Kanzlei).

Technischer Betreiber

Hugo Marinho, Farnsburgerstrasse 44, 4052 Basel, kontakt@rechnungs-kontor.de.

Auftragsverarbeiter

Hetzner Online GmbH (Nürnberg, DE), Cloudflare (EU-Edge, Frankfurt), Mailgun Technologies (EU, Belgien), Resend Inc. (EU, Irland), Mistral AI (Paris, Frankreich), Stripe Payments Europe Limited (Dublin, Irland). Verträge zur Auftragsverarbeitung gemäss Art. 28 DSGVO bestehen mit allen genannten Anbietern. Zahlungsmittel werden ausschliesslich über Stripe abgewickelt; Kartendaten erreichen Rechnungs-Kontor zu keinem Zeitpunkt (PCI-DSS Level 1 konforme Abwicklung direkt zwischen Stripe und Endgerät des Inhabers).

4. Belegerfassung

Belege erreichen das System auf zwei Wegen:

• E-Mail-Eingang. Jeder Mandant erhält bei Anlage durch die Kanzlei eine individuelle Adresse der Form <slug>-<token4>@mailbox.rechnungs-kontor.de. Eingehende Nachrichten werden von Mailgun parsbasiert entgegengenommen und per signiertem POST-Webhook an /api/ingest-email übergeben. Die HMAC-Signatur wird mit dem Mailgun-Webhook-Signing-Key überprüft; ungültige Signaturen führen zur Ablehnung mit HTTP 401. Die Anlagen jeder akzeptierten Nachricht werden einzeln verarbeitet.
• Hochladen-Formular. Jeder Mandant hat einen tokenisierten Hochladen-Link /u/<ingest_token>. Der Token (32 Hex-Zeichen) ist die Authentifizierung; eine Anmeldung ist nicht erforderlich.

Für jede empfangene Datei werden Originalbytes, Dateiname, MIME-Typ, Empfangszeitpunkt, Empfangskanal und – soweit vom Kanal verfügbar – Absenderadresse sowie ursprüngliche Message-ID festgehalten. Die Originalbytes werden unverändert in der Archivschicht gespeichert; jegliche Weiterverarbeitung erfolgt ausschliesslich auf einer Lesekopie.

4.1 Erkennungs-Pipeline

1. XRechnung (XML) und ZUGFeRD (PDF mit XML-Anhang): Strukturiertes Auslesen über einen XML-Parser, der UBL (XRechnung-CIUS) und CII (ZUGFeRD ab Profil EN 16931) unterstützt.
2. PDF mit Textebene: Auslesen der Textebene über die Mozilla pdf.js-Bibliothek (unpdf), anschliessend heuristische Extraktion von Rechnungsnummer, Datum, Beträgen, USt-IdNr., IBAN, Lieferantenname.
3. Bild-Belege und Belege ohne Textebene (Foto, Scan, Handschrift): Texterkennung über Mistral Pixtral mit anschliessender Regelextraktion. Bei Misserfolg Fallback auf Mistral OCR.

5. Identifikation und Indexierung

Jeder Beleg wird beim Eingang mit einer fortlaufenden, eindeutigen System-ID (iv_*) versehen. Zusätzlich werden folgende Felder strukturiert hinterlegt:

• Rechnungsnummer, Rechnungsdatum, Leistungsdatum, Fälligkeitsdatum
• Lieferantenname, USt-IdNr. des Lieferanten
• Leistungsempfänger, USt-IdNr. des Empfängers
• Währung, Nettobetrag, Steuerbetrag, Bruttobetrag
• USt-Kategorie nach UNTDID 5305 (S/AA/Z/E/AE/K/G/O) und numerischer Steuersatz
• Kennzeichnung „Kleinbetragsrechnung“ nach § 33 UStDV (Brutto ≤ 250 €)

Die Periodenzuordnung erfolgt nach § 13 Abs. 1 Nr. 1 lit. a UStG über das Leistungsdatum mit Rechnungsdatum als Fallback. Der Empfangszeitpunkt durch Rechnungs-Kontor ist nicht für die Periodenzuordnung massgeblich.

5.1 § 14 / § 14a UStG-Vollständigkeitsprüfung

Jeder Beleg wird unmittelbar nach der Identifikation gegen die acht numerierten Pflichtangaben des § 14 Abs. 4 UStG sowie gegen die einschlägigen § 14a UStG- Sondervermerke (insbesondere Reverse Charge nach § 14a Abs. 5 UStG, innergemeinschaftliche Lieferung nach § 14a Abs. 3 UStG) geprüft. Für Kleinbetragsrechnungen gilt der reduzierte Pflichtangaben-Satz nach § 33 UStDV. Das Prüfergebnis (Liste fehlender Pflichtangaben, Hinweise) wird je Beleg als JSONB-Datensatz hinterlegt und in der Übersicht sichtbar gemacht.

5.2 Kontierungsvorschlag (SKR03 / SKR04)

Für jeden Beleg wird im Hintergrund ein Vorschlag zur Kontierung erzeugt. Der Vorschlag erfolgt zweistufig:

1. Regelbasierte Heuristik über einen kuratierten Katalog von rund 40 SKR03/SKR04-Konten. Jeder Katalogeintrag umfasst beide SKR-Varianten, den dominanten USt-Satz, die UNTDID-5305-Kategorie sowie regelmässige Ausdrücke gegen Lieferantenname und Belegtext. Ein Treffer erzeugt eine Vorschlagsquelle heuristic mit einem Konfidenzwert zwischen 0,70 und 0,95. Liegt kein Treffer vor, wird der vorsichtige Standardfall „Wareneingang 19 % Vorsteuer“ (SKR03 3400 / SKR04 5400) mit Quelle fallback und Konfidenz 0 vorgemerkt.
2. LLM-gestützte Klassifikation (Tier 2.2.C): Wenn die Heuristik entweder keinen spezifischen Treffer liefert oder die Konfidenz ≤ 0,75 ist, wird Mistral Small (Modell mistral-small-latest, Mistral AI, Paris) über die Chat-Completions-Schnittstelle aufgerufen. Das Modell erhält den gleichen Katalog als geschlossene Auswahlliste plus die strukturierten Belegfelder (Lieferant, Bruttobetrag, USt-Satz, USt-Kategorie) und einen Auszug des Belegtextes von maximal 1.200 Zeichen. Es liefert ausschliesslich JSON mit Kontonummer, Konfidenz und einer kurzen deutschsprachigen Begründung zurück. Vor der Übernahme wird die zurückgegebene Kontonummer gegen den Katalog validiert; halluzinierte oder auf die falsche SKR-Variante bezogene Nummern werden verworfen. Auf Erfolg wird die Vorschlagsquelle auf llm erhöht; auf Fehler (Zeitüberschreitung nach 12 Sekunden, 5xx, ungültiges JSON, halluzinierte Nummer) bleibt der Heuristik- bzw. Fallback-Vorschlag bestehen.

Der Vorschlag ist ein Vorschlag, keine Buchung. Vor jedem DATEV-Export muss die Kanzlei jede Kontierung ausdrücklich akzeptieren oder überschreiben; das Akzeptieren erfolgt entweder einzeln, per Sammel-Aktion, per Mehrfachauswahl oder durch manuelle Vorgabe eines anderen Kontos aus dem Katalog. Jede dieser Aktionen wird mit Benutzer-ID, Zeitstempel und Vorschlagsquelle (heuristic, llm, fallback) im Audit-Protokoll festgehalten (Aktionen kontierung_accepted, kontierung_overridden, kontierung_bulk_accepted, kontierung_multi_set, kontierung_llm_upgraded). Das System nimmt zu keinem Zeitpunkt eine eigenständige Buchung vor. Die finale Verantwortung für die Buchung verbleibt bei der Kanzlei (vgl. § 33 StBerG).

6. Speicherung und Archivierung

Die Originaldatei jedes Belegs wird inhalts-adressiert unter dem Schlüssel f:<sha256> im Hetzner-Object- Storage-Bucket „rk-invoices“ abgelegt. Der Bucket hat Versionierung aktiviert, so dass eine versehentliche oder böswillige Überschreibung an einer ursprünglichen Version nichts ändern kann. Identische Bytes (selbe Datei aus zwei Kanälen oder zwei Mandanten) werden physisch nur einmal gespeichert; jeder Bezug auf die Datei erfolgt über ihren Hash.

Die strukturierten Felder (Rechnungsdaten, Audit-Log, Vollständigkeitsprüfungen) liegen in der relationalen Datenbank, ebenfalls in Nürnberg. Datenbank und Archiv sind physisch getrennt; eine Datenbank-Wiederherstellung allein löscht die Originalbelege nicht, eine Bucket- Wiederherstellung allein verändert keine Buchungssätze.

7. Unveränderbarkeit und Revisionssicherheit

Die Unveränderbarkeit (GoBD Rn. 58–60) wird in Rechnungs-Kontor softwaretechnisch durchgesetzt:

• Inhalts-Adressierung: Belegdateien werden unter dem SHA-256-Hash ihrer Bytes gespeichert. Eine Veränderung der Bytes erzeugt eine neue Datei mit neuem Schlüssel; eine bestehende Schlüssel-Datei kann nicht „bearbeitet“ werden.
• Bucket-Versionierung: Versuche, einen vorhandenen Schlüssel zu überschreiben, erzeugen eine neue Objekt-Version. Vorgängerversionen bleiben abrufbar.
• Hash-verkettetes Audit-Log: Jeder Verarbeitungsschritt (Beleg empfangen, Felder geändert, Monat abgeschlossen, Export ausgelöst) wird als Zeile im Audit-Log festgehalten. Jede Zeile enthält den SHA-256-Hash ihrer Vorgängerzeile, so dass jede nachträgliche Änderung die Kette ab dem Manipulationspunkt entwertet. Eine Hilfsfunktion erlaubt jederzeit die Verifikation der gesamten Kette.
• Tägliche externe Zeitanker (OpenTimestamps): Der jeweils aktuelle Hash der Audit-Kopfzeile wird täglich um 03:00 UTC als kryptografischer Zeitanker an das OpenTimestamps-Protokoll übermittelt. Das Protokoll bündelt Einreichungen und veröffentlicht den Sammelhash periodisch in der Bitcoin-Blockchain (BIP-141 OP_RETURN). Die so entstehende Quittung wird im System gespeichert und ist gegenüber Prüfern als unabhängiger Nachweis vorlegbar: sie beweist, dass der Audit-Hash zum gegebenen Zeitpunkt bereits exakt diesen Wert hatte und nicht nachträglich umgeschrieben wurde. Sämtliche Anker mit Quittung und Schritt-für-Schritt-Verifikationsanleitung sind öffentlich verfügbar unter rechnungs-kontor.de/integrity. Voraussetzungslos öffentlich verifizierbar mit dem OpenTimestamps-Client gegen einen beliebigen Bitcoin-Knoten.
• Abschlussverriegelung: Ein Monatsabschluss (siehe Abschnitt 11) sperrt die Periode anwendungsseitig gegen weitere Änderungen. Ein erneutes Öffnen ist möglich, wird jedoch im Audit-Log mit Nutzer und Zeitstempel hinterlegt.

GoBD Rn. 58–60 lassen für die Unveränderbarkeit ausdrücklich sowohl hardwaretechnische (z.B. WORM-Datenträger) als auch softwaretechnische Verfahren (Festschreibung, Sperren, Protokollierung) zu, gleichwertig nebeneinander.

8. Verschlüsselung im Ruhezustand und in der Übertragung

Datenbank im Ruhezustand

Die Postgres-Datenbank liegt auf einer dedizierten, LUKS2-verschlüsselten Hetzner-Cloud-Volume in Nürnberg. Verschlüsselungsverfahren: AES-XTS-Plain64 mit 512 Bit Schlüssellänge, SHA-256, 4-KB-Sektoren. Der Schlüssel wird beim Systemstart aus einer auf der Maschine schreibgeschützten Datei (mode 0400, ausschließlich für root lesbar) geladen. Das Verfahren schützt insbesondere gegen Datenträger-Diebstahl, Snapshot-Leaks beim Auftragsverarbeiter sowie Recycling stillgelegter Datenträger.

Originaldateien im Ruhezustand

Server-seitige Verschlüsselung der Object-Storage-Inhalte durch den Anbieter Hetzner Online GmbH. Eine zusätzliche kundenseitige Verschlüsselung mit von Rechnungs-Kontor verwalteten Schlüsseln (SSE-C) ist Bestandteil der nächsten Hardening-Stufe.

Übertragung

TLS 1.2/1.3 auf allen Wegen. Der Datenbank-Zugriff erfolgt ausschließlich über einen verschlüsselten Cloudflare-Tunnel; ein öffentlicher Datenbank-Port existiert nicht.

Sicherungen

Tägliche Postgres-Sicherungen werden vor dem Upload mit GnuPG (AES-256, symmetrisch, Schlüsseldatei off-box) lokal verschlüsselt. Der Schlüssel ist ausschließlich dem verantwortlichen Betreiber bekannt.

9. Datensicherung und Wiederherstellung

Datenbank, primär

Tägliche logische Sicherungen (pg_dump, Custom-Format) um 02:30 UTC, off-box-verschlüsselt (GnuPG AES-256), Übertragung in einen separaten Hetzner-Object-Storage-Bucket (rk-backups) mit eigenen Zugangsdaten. Aufbewahrung: 30 tägliche, 12 wöchentliche, 24 monatliche Sicherungen. Rotation und Pruning automatisiert.

Datenbank, sekundär

Hetzner Cloud Snapshot-Backups, tägliche automatische Erstellung mit 7-Tage-Rotation.

Wiederherstellungs-Tests

Wöchentlich automatisiert: jede Sonntagnacht (03:30 UTC) lädt das System die jüngste Sicherung aus dem rk-backups-Bucket, entschlüsselt sie, stellt sie in eine temporäre Datenbank wieder her und verifiziert die Audit-Log-Hash-Kette des wiederhergestellten Standes gegen die Live-Datenbank. Fehlschläge werden protokolliert.

Objektspeicher

Versionierung aktiv, jede Objektversion bleibt mindestens für die Aufbewahrungsfrist (10 Jahre) erhalten. Object Lock im COMPLIANCE-Modus mit 10-Jahres-Vorhaltefrist wird zum Produktionsstart aktiviert.

Konfiguration und Code

Vollständig in Git versioniert. Wiederherstellung des Anwendungsstandes über einen Deployment-Rollback in Cloudflare Pages.

Wiederherstellungstests laufen automatisiert wöchentlich (siehe oben) und werden im System-Log dokumentiert.

10. Zugriffsschutz und Berechtigungen

• Authentifizierung über Passwort (PBKDF2-SHA256). Die Implementierung versucht zunächst 600.000 Iterationen nach OWASP 2023; falls die verwendete Crypto-Laufzeit diese Schwelle nicht unterstützt (z. B. Cloudflare Workers Crypto), wird automatisch auf 100.000 Iterationen (NIST-Mindestvorgabe) zurückgesetzt. In der aktuellen Produktionsumgebung werden Passwörter mit 100.000 Iterationen gehasht; die tatsächlich verwendete Iterationszahl ist im Passwort-Hash kodiert und im Audit-Log dokumentiert. Plus serverseitige Session.
• Optionale Zwei-Faktor-Authentifizierung (TOTP nach RFC 6238, 30-Sekunden-Zeitschritt, 6 Ziffern, SHA-1) mit 8 einmalig verwendbaren, gehashten Notfallcodes. Optionales „Diesem Geraet 30 Tage vertrauen" pro Browser, jederzeit einzeln oder vollstaendig widerrufbar.
• Sitzungscookies sind HttpOnly, Secure und SameSite=Lax; die Sitzungsdauer beträgt 30 Tage. Anmelde-Versuche werden je E-Mail in einem 10-Minuten-Fenster gezählt; ab fünf Fehlversuchen wird die Adresse vorübergehend gesperrt (anwendungsseitige Schutzschicht).
• Zusätzliche Edge-Schutzschicht (Cloudflare WAF): auf der Login-Route /api/auth/login ist eine Cloudflare-Rate-Limiting-Regel aktiv, die maximal acht POST- Anfragen je 10 Sekunden je Quell-IP zulässt. Bei Überschreitung antwortet die Cloudflare-Kante mit HTTP 429, ohne dass die Anfrage die Anwendung erreicht. Diese Schicht ergänzt die anwendungsseitige E-Mail-Sperre: erstere fängt Angriffe gegen ein bekanntes Konto ab (mehrere falsche Passworte je Adresse), letztere fängt IP-basierte Probier-Muster ab (eine Quelle versucht viele Adressen). Beide Schichten laufen unabhängig voneinander und greifen ohne Datenbank- Beanspruchung.
• Rollenmodell (Tier 2.3): innerhalb einer Kanzlei werden zwei Rollen unterschieden – Inhaber (kann Team-Mitglieder einladen / entfernen, Abrechnung ändern, Kanzlei löschen) und Mitglied (kann alle operativen Vorgänge wie Mandanten-Anlage, Beleg-Erfassung, Kontierung, Periodenabschluss und Übergabe ausführen). Der erste Nutzer einer Kanzlei erhält automatisch die Rolle Inhaber; eingeladene Personen erhalten standardmässig die Rolle Mitglied. Mindestens ein Inhaber muss zu jedem Zeitpunkt vorhanden sein; die Anwendung verhindert die Entfernung des letzten Inhabers.
• Einladungen werden mit 256-Bit-Zufalls-Token über E-Mail versendet und sind 7 Tage gültig sowie nur einmal einlösbar. Annahme einer Einladung gilt als Nachweis der Mailbox-Eigentümerschaft; eine zusätzliche Verifikations- Mail entfällt für eingeladene Personen.
• Mehrstufige Autorisierung: jede Anfrage wird gegen den Kanzlei-Scope geprüft; mandantenfremde Daten sind nicht erreichbar. Verwaltungsaktionen werden zusätzlich gegen die Rolle des aufrufenden Nutzers geprüft.
• SSH-Zugang zum Datenbank-Server ausschliesslich über Public-Key-Authentifizierung (Passwort-Authentifizierung deaktiviert), zusätzlich fail2ban-Sperrlogik.
• Mailgun-Webhooks werden HMAC-verifiziert; bei ungültiger Signatur wird die Anfrage mit HTTP 401 verworfen.
• Aufrufstatistik und Anomalien werden über die Cloudflare- Edge-Logs überwacht.

9.1 Kategorien ausgehender E-Mails

Ausgehende E-Mails sind technisch in zwei Klassen geteilt, die unterschiedlich auf eine Abmeldung durch den Empfänger reagieren:

Routinemitteilungen

Empfangsbestätigung eingegangener Belege an den Mandanten; Benachrichtigung des Steuerberaters über neue Belege. Diese Nachrichten respektieren die globale Abmeldung. Ein Empfänger, dessen Adresse in der Suppressionsliste notification_suppressions geführt wird, erhält diese Nachrichten nicht mehr. Der entsprechende Versandversuch wird im Audit-Log mit der Aktion *_skipped und der Begründung recipient_suppressed protokolliert.

Transaktionale / service-kritische Mitteilungen

Folgende Nachrichten werden im Rahmen der Vertragserfüllung versendet und respektieren die globale Abmeldung nicht:

• verificationEmail — Bestätigung der Konto-Registrierung, ausgelöst durch /api/auth/register.
• verificationEmail — Verifizierung der neuen E-Mail-Adresse nach einer Adressänderung, ausgelöst durch /api/auth/change-email.
• verificationEmail — erneuter Versand des Verifizierungslinks auf Anforderung durch /api/auth/resend-verification.
• passwordResetEmail — Link zum Zurücksetzen des Passworts, angefordert über /api/auth/reset-request.
• passwordChangedEmail — Bestätigung der Passwort-Änderung (sowohl aus /api/auth/password als auch aus /api/auth/reset-confirm). Sicherheitsmail zur Out-of-Band-Erkennung unbefugter Änderungen.
• teamInvitationEmail — Einladung in eine bestehende Kanzlei, ausgelöst durch /api/team/invite.
• mandantBlockedNotifyEmail — Hinweis auf gesperrten Belegeingang aufgrund einer Abrechnungsstörung (Test-Limit erreicht, Test abgelaufen, Zahlung fehlgeschlagen, Abonnement beendet).

Diese Nachrichten sind keine Werbung im Sinne des § 2 Abs. 1 Nr. 7 UWG und werden auch dann zugestellt, wenn der Empfänger sich von Routinemitteilungen abgemeldet hat. Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Erfüllung des Vertrages). Im Audit-Log wird die transaktionale Zustellung mit dem Detail bypassed_suppression: true protokolliert, sofern der Empfänger zum Zeitpunkt des Versands global abgemeldet war.

Eine vollständige Abmeldung sämtlicher E-Mails einschliesslich transaktionaler Mitteilungen ist nur durch Kündigung des Kontos möglich. Bis dahin sind transaktionale Mitteilungen notwendiger Bestandteil der vertraglichen Beziehung.

11. Aufbewahrung und Löschung

Rechnungen und Buchungsbelege werden gemäss § 147 Abs. 1 Nr. 4 und Abs. 3 AO, § 14b Abs. 1 UStG sowie § 257 Abs. 4 HGB für die regulatorische Frist von zehn Jahren aufbewahrt. Die Aufbewahrungsfrist beginnt mit dem Schluss des Kalenderjahres, in dem die letzte Eintragung in den Belegen vorgenommen wurde.

Konto- und Anmeldedaten werden so lange gespeichert, wie das Konto aktiv ist. Nach Vertragsbeendigung werden Konto- und Sitzungsdaten innerhalb von 30 Tagen gelöscht. Belege und Audit-Log-Einträge bleiben bis zum Ablauf der gesetzlichen Aufbewahrungsfrist erhalten.

Ein Monatsabschluss (Steuerberater-Aktion auf der Mandantendetailseite) sperrt die Periode anwendungsseitig. Belege, deren Leistungsdatum in einer abgeschlossenen Periode liegt, können nach Abschluss nicht mehr geändert werden, ohne dass die Periode ausdrücklich wieder geöffnet wird (mit Audit-Log-Eintrag).

12. Maschinelle Auswertbarkeit und Übergabe

Sämtliche strukturierten Felder sind maschinell auswertbar (GoBD Rn. 100 ff.). Die Übergabe an die Kanzlei-Software erfolgt periodenweise:

• DATEV-Format 7.00 EXTF Buchungsstapel – Windows-1252-codierte CSV mit den Pflicht- und Standardspalten der Buchungsstapel-Formatversion 13. Kontensystem SKR03 oder SKR04 wird je Mandant einstellbar.
• Vorsteuer-Aufstellung im UStVA-Format – Beträge nach Steuersatz aufgeschlüsselt und den ELSTER-Kennziffern 66 (Vorsteuer aus Rechnungen anderer Unternehmer), 61 (innergemeinschaftlicher Erwerb) und 67 (§ 13b-Leistungen) zugeordnet.
• Übergabe-Paket – ZIP-Archiv mit dem Buchungsstapel, der Vorsteuer-Aufstellung, allen Originaldateien des Zeitraums sowie einem Manifestbericht mit SHA-256-Prüfsummen.

Die DATEV-Format-Datei kann von DATEV Rechnungswesen, DATEV Unternehmen online, Lexware Office, sevDesk, Agenda, STOTAX, ADDISON und Simba importiert werden.

13. Verfahrenstest und Inbetriebnahme

Vor produktivem Einsatz für einen Mandanten ist die Kanzlei aufgefordert, mindestens einen Probemonat mit folgenden Schritten durchzuführen:

1. Mandanten in Rechnungs-Kontor anlegen.
2. SKR-Variante (SKR03 oder SKR04) festlegen.
3. DATEV-Beraternummer und Mandantennummer hinterlegen.
4. Probebelege über alle Eingangskanäle (E-Mail, Hochladen-Link) und alle Formate (XRechnung, ZUGFeRD, PDF, Foto) einreichen.
5. Erkannte Felder, Pflichtangaben-Prüfung und Vorsteuer- Aufstellung gegenprüfen.
6. Buchungsstapel exportieren und Probeimport in der gewohnten Kanzleisoftware durchführen.
7. Übereinstimmung zwischen Originalbeleg, archivierter Datei (SHA-256) und gebuchtem Eintrag in DATEV stichprobenhaft prüfen.

Der erfolgreiche Verfahrenstest sowie seine Durchführung werden von der Kanzlei dokumentiert und sind im Falle einer steuerlichen Aussenprüfung vorzuhalten.

14. Abrechnung und Stripe-Anbindung

Die Abrechnung des Abonnements wird vollständig über Stripe Payments Europe Limited (Dublin, Irland) abgewickelt. Rechnungs-Kontor verarbeitet zu keinem Zeitpunkt Kartendaten oder Bankverbindungen selbst.

Abrechnungsmodell

Monatlich. Pro Kanzlei eine Grundgebühr, je aktivem Mandant ein mengenabhängiger Zusatz. Beträge zuzüglich der gesetzlichen Umsatzsteuer; die anwendbare Umsatzsteuer wird durch Stripe Tax anhand der bei Stripe hinterlegten Adresse und USt-IdNr. berechnet (Reverse-Charge bei EU-B2B-Kunden mit gültiger USt-IdNr.).

Test-Zeitraum

60 Tage ab Konto-Anlage. Im Test sind alle Funktionen freigeschaltet, mit Mengenbegrenzung von 5 Mandanten, 200 Belegen (kumuliert) und 3 Team-Mitgliedern. Die effektiven Zähler werden anwendungsseitig geführt; ein Erreichen einer Grenze führt zu einer abgegrenzten Sperre der entsprechenden Aktion und einer dokumentierten Hinweismeldung an den Inhaber.

Datenfluss bei Abonnement-Abschluss

Klick auf „Jetzt abonnieren" erstellt eine Stripe-Checkout-Session. Der Browser des Inhabers wird auf die von Stripe gehostete Bezahlseite weitergeleitet. Die Kartendaten werden ausschliesslich zwischen Browser und Stripe ausgetauscht; Rechnungs-Kontor akzeptiert derzeit nur Kreditkarten-Zahlungen. Stripe erzeugt einen Customer- und ein Subscription-Objekt und übergibt Rechnungs-Kontor anschliessend per webhook die entsprechenden Identifier (cus_*, sub_*) sowie einen abgeleiteten Bezahlstatus (active / past_due / canceled). Die Webhook-Signatur wird mit dem Stripe-Signing- Secret nach HMAC-SHA256 verifiziert; ungültige Signaturen werden mit HTTP 400 abgelehnt und im Audit-Log mit stripe_webhook_rejected protokolliert.

Kunden-Selbstverwaltung

Inhaber erreichen über „Abrechnungs-Portal öffnen" das Stripe Customer Portal mit Zugang zu Rechnungen, Belegen, Zahlungsmittel-Wechsel und Kündigung zum Periodenende. Eine einseitige Kündigung durch den Anbieter erfolgt nicht.

Mengen-Synchronisation

Anzahl der aktiven Mandanten wird bei jeder Änderung (Anlage, Aktivierung, Deaktivierung, Löschung) über ctx.waitUntil mit der Stripe-Subscription synchronisiert. Stripe rechnet anteilig nach Tagen ab (proration), sodass Mengenänderungen unmittelbar in der nächsten Rechnung berücksichtigt werden.

Speicherung bei Rechnungs-Kontor

Persistiert werden nur die Stripe-Identifier (Customer-ID, Subscription-ID, letzter Bezahlstatus, Periodenende- Zeitstempel) sowie die Webhook-Idempotenz-IDs zur Mehrfach-Erkennung. Keine Kartendaten, keine Bank-Daten, keine PCI-relevanten Felder werden bei Rechnungs-Kontor gespeichert oder geloggt.

15. Sicherheitsvorfälle und Datenpannen

Treten Hinweise auf einen Sicherheitsvorfall auf (anomales Zugriffsmuster, fehlgeschlagene Verifikation einer Webhook-Signatur, ungewöhnliche Aktivität im Audit-Log, Meldung durch einen Subunternehmer), wird der Inhaber des Anbieters unverzüglich benachrichtigt und ein Bewertungsverfahren ausgelöst.

1. Eindämmung. Betroffene Sitzungen werden sofort beendet, ggf. werden Passwörter zurückgesetzt und Stripe- bzw. Cloudflare-API-Tokens rotiert.
2. Bewertung. Es wird geprüft, ob personen- bezogene Daten betroffen sind und welcher Verarbeitungs- kreis betroffen ist. Grundlage der Bewertung sind das Audit-Log, die Cloudflare- und Hetzner-Logs sowie ggf. Meldungen Dritter.
3. Meldung. Bei Verletzung des Schutzes personenbezogener Daten (Art. 4 Nr. 12 DSGVO) erfolgt eine Meldung an die zuständige Aufsichtsbehörde innerhalb von 72 Stunden ab Kenntnisnahme (Art. 33 DSGVO). Besteht voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen, werden die betroffenen Personen unverzüglich gemäss Art. 34 DSGVO informiert.
4. Dokumentation. Jeder Vorfall, seine Auswirkungen und die getroffenen Abhilfemassnahmen werden schriftlich festgehalten (Art. 33 Abs. 5 DSGVO).

Im Übrigen gilt: kein Bezahldatenfluss durch Rechnungs-Kontor, keine Karteninformationen gespeichert, keine offenen Datenbank- Ports im Internet. Brute-Force-Schutz, Hash-Chain-Audit-Log und abgeschlossene Periodenabschlüsse mit Datenbank-Triggern (siehe Abschnitt 7) reduzieren die Angriffsfläche im normalen Betrieb.

16. Änderungsverfolgung

Diese Verfahrensdokumentation ist als Bestandteil der GoBD-Pflichtdokumentation des Mandanten zu führen und bei Änderungen am Verfahren oder am eingesetzten System fortzuschreiben. Sie ersetzt nicht die individuelle Verfahrensdokumentation der Kanzlei oder des Mandanten, sondern dokumentiert ausschliesslich den Teilprozess „Belegeingang und -archivierung über Rechnungs-Kontor“.