Verfahrensdokumentation

Fassung 1.0 · Stand 27. August 2026 · GoBD

Diese Seite beschreibt, wie bei patchletter eine Rechnung entsteht, wie sie nummeriert und besteuert wird, wo sie liegt und wie lange sie dort bleibt. Sie ist für zwei Arten von Lesern geschrieben: einen Kunden, der wissen will, was mit seinen Rechnungsdaten passiert, und einen Prüfer, der das Verfahren verstehen will, bevor er Belege anfordert.

1. Geltungsbereich

Erfasst sind die Ausgangsrechnungen der patchletter UG (haftungsbeschränkt) i. G., Meisterweg 16, 45896 Gelsenkirchen. Es gibt zwei Erlösquellen: Abonnements (patchletter Pro und MSP) und die Herstellerpräsenz auf einer Produktseite. Die Verantwortung für das Verfahren liegt bei der Geschäftsführung, Buchführung und Jahresabschluss liegen beim Steuerberater.

2. Beteiligte Systeme

• Anwendung und Datenbank laufen auf unserem eigenen Server in Deutschland. Die Datenbank hält je Rechnung eine Zeile: Zeitraum, Netto, Steuer, Brutto, Satz, Status, Rechnungs- und Zahldatum sowie den Speicherschlüssel des PDFs.
• Der Zahlungsdienstleister (Mollie B.V., Amsterdam) zieht die Zahlung ein, erzeugt das Rechnungsdokument und versendet es an den Kunden.
• Unser eigener Objektspeicher auf demselben Server hält eine Kopie jedes Rechnungs-PDFs.

3. Wie eine Rechnung entsteht

Abonnements laufen automatisch:

• Ein geplanter Lauf greift die Organisationen auf, deren Abrechnungszeitraum abgelaufen ist und die per Mandat zahlen.
• Bevor irgendetwas eingezogen wird, entsteht die Rechnungszeile in unserer Datenbank. Sie trägt eine Eindeutigkeitsbedingung auf Organisation und Periodenbeginn: Startet der Lauf neu, läuft der zweite Versuch dagegen und hört auf. Dass die Zeile zuerst entsteht und der Einzug danach kommt, ist der eigentliche Schutz — andersherum wäre das Geld gezogen, bevor etwas es verhindern könnte.
• Eine Organisation ohne Rechnungsdaten wird übersprungen und gemeldet, nicht geraten. Wer auf Rechnung zahlt, hat kein Mandat und gerät nie in einen Einzugslauf.
• Jeder Schritt hinterlässt einen Eintrag in einem Ereignis-Protokoll — Rechnung erzeugt, Zahlung erfolgreich oder fehlgeschlagen, Mandat widerrufen, Rücklastschrift, Tarifwechsel, Mahnstufe. Eine doppelt zugestellte Webhook-Meldung erzeugt einen Eintrag, nicht zwei.

Die Herstellerpräsenz wird von Hand abgerechnet. Der Abschluss läuft per Mail, die Rechnung wird händisch geschrieben und an derselben Stelle abgelegt wie die automatischen. Eine Selbstbedienungs-Strecke gibt es dafür noch nicht. Wir benennen das, weil eine Verfahrensdokumentation, die nur den automatischen Weg beschreibt, die kleinere Hälfte unserer Belege beschreiben würde.

4. Rechnungsnummern

Die Nummer einer Abo-Rechnung vergibt der Zahlungsdienstleister in seinem fortlaufenden Nummernkreis; wir speichern sie in unserer Zeile neben dessen eigener Kennung. Wir vergeben diese Nummern nicht selbst und behaupten das auch nicht: Was hier vor einer Doppelrechnung schützt, ist die oben beschriebene Datenbankbedingung, kein eigener Zähler.

Handrechnungen der Herstellerpräsenz laufen in einem eigenen, selbst geführten Nummernkreis. Die Trennung ist Absicht — ein gemeinsamer Kreis, der aus zwei Quellen gespeist wird, ist genau die Stelle, an der Lücken entstehen.

5. Umsatzsteuer

Satz und Pflichthinweis auf der Rechnung werden an genau einer Stelle im Code bestimmt, weil dieselbe Größe auf der Rechnung, im eingezogenen Betrag und im Text darunter steht — drei Stellen, die auseinanderlaufen können, ohne dass es auffällt, bis jemand prüft. Unterschieden werden vier Fälle:

• Kleinunternehmerregelung (§ 19 UStG): Es wird überhaupt keine Umsatzsteuer ausgewiesen. Dieser Fall schlägt jeden anderen — ein trotzdem ausgewiesener Satz wäre nach § 14c UStG geschuldet.
• Inland: der Regelsteuersatz.
• Firmenkunde in der EU: Reverse Charge — aber nur mit einer USt-IdNr., die tatsächlich gegen VIES geprüft wurde. Eine ungeprüfte Nummer wird wie keine behandelt, denn Reverse Charge darauf zu stützen heißt, die Steuer selbst zu schulden.
• Privatperson in der EU: der Satz des Wohnsitzlands, gemeldet über das One-Stop-Shop-Verfahren. Der Satz wird je Fall beigebracht statt aus einer Tabelle im Code — 26 Sätze, die sich ändern, gehören nicht in eine Datei, die niemand pflegt.
• Außerhalb der EU: nicht steuerbare Leistung.

Beträge werden in Cent gerechnet und kaufmännisch auf den ganzen Cent gerundet.

6. Format

Rechnungen werden als PDF ausgestellt. Eine strukturierte E-Rechnung (ZUGFeRD/Factur-X oder XRechnung) ist im Datenmodell vorbereitet, aber nicht in Betrieb; das steht hier an dem Tag, an dem es so ist, und keinen Tag früher. Eingehende E-Rechnungen können wir entgegennehmen und archivieren.

7. Archivierung

Unmittelbar nach der Erstellung wird das PDF abgeholt und unter einem festen Schlüssel in unseren eigenen Objektspeicher geschrieben. Das Konto des Kunden und jeder Verweis, den wir versenden, zeigen auf unsere eigene Kopie, nie auf das Dokument des Zahlungsdienstleisters: Dessen Verweise sind signiert und laufen ab, ein direkt verlinktes PDF funktioniert morgen nicht mehr — und die zehnjährige Aufbewahrung schulden wir, nicht der Anbieter.

Was nicht vorhanden ist: Der Objektspeicher hat keinen Schreibschutz (WORM/Object Lock), und wir bilden keine Prüfsumme je Dokument. Die Unveränderbarkeit stützt sich heute darauf, dass der Zugriff auf den Betreiber beschränkt ist, und auf die Sicherungen — nicht darauf, dass der Speicher das Überschreiben verweigert. Wir halten das für eine Lücke, die zu schließen ist, und sie steht auf der Liste statt als Errungenschaft in diesem Text.

8. Datensicherung

Die Datenbank wird stündlich gesichert und jede Sicherung direkt nach dem Schreiben auf Lesbarkeit geprüft; eine Kopie geht auf eine zweite Maschine in Deutschland. Off-Site-Kopien auf fremden Speicher werden clientseitig verschlüsselt, bevor sie die Maschine verlassen. Stündliche Sicherungen bleiben 30 Tage, die vom Monatsersten ein Jahr.

9. Zugriffsschutz

Innerhalb einer Kundenorganisation sind Rechnungen nur für Inhaber und Verwaltung sichtbar — sie tragen Anschrift und USt-IdNr. der Firma, und ein Techniker mit Zugang hat dort nichts verloren. Auf unserer Seite ist der Zugriff auf den Betreiber über die Administrationsoberfläche und auf den Steuerberater für die übergebenen Unterlagen beschränkt. Serverzugang erfordert einen SSH-Schlüssel; das Produkt selbst kennt keine Passwörter.

10. Aufbewahrung und Datenzugriff

Rechnungen und die zugehörigen Aufzeichnungen bewahren wir zehn Jahre auf. Die Frist für Buchungsbelege ist mit dem Vierten Bürokratieentlastungsgesetz auf acht Jahre verkürzt worden; wir nutzen die Verkürzung nicht, weil zwei verschiedene Fristen im selben Bestand mehr Fehlerquellen schaffen, als sie Speicher sparen.

Für eine Betriebsprüfung können wir die Rechnungsdokumente sowie einen Export der Rechnungs- und Ereignis-Aufzeichnungen in einem gängigen, maschinenlesbaren Format bereitstellen. Dieser Export entsteht heute von Hand; einen Knopf dafür gibt es nicht.

11. Änderungen an diesem Dokument

Jede Änderung am Verfahren ändert diese Seite und ihre interne Fassung, die die Änderungshistorie führt. Beide liegen im selben Repository wie der Code, den sie beschreiben — eine Änderung am Abrechnungslauf und die an seiner Dokumentation reisen damit in einem Commit.

Fassung 1.0, Stand 27. August 2026. Dazu passen: Auftragsverarbeitung, Betrieb & Datenschutz, Datenschutzerklärung.