Verfahrensdokumentation

Fassung 1.5 · Stand 28. September 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), Meisterweg 16, 45896 Gelsenkirchen. Es gibt zwei Erlösquellen: Abonnements (patchletter Pro) 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

• Die Anwendung läuft auf einem Server in Nürnberg, den wir selbst betreiben (Hosting: netcup GmbH, Deutschland); die PostgreSQL-Datenbank läuft auf demselben Server. 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 Karten- und SEPA-Lastschriftzahlungen ein, erzeugt jedes Rechnungsdokument und versendet es an den Kunden. Qonto SA (Paris) stellt unser Empfängerkonto für Rechnungsüberweisungen; ein selbst betriebener Abgleich liest Zahlungseingänge über dessen API.
• Der Objektspeicher auf demselben Server (Garage, S3-kompatibel) hält eine Kopie jedes Rechnungs-PDFs.

3. Wie eine Rechnung entsteht

Abonnements laufen automatisch:

• Ein geplanter Lauf greift Organisationen auf, deren Abrechnungszeitraum abgelaufen ist. Bei Karte und SEPA-Lastschrift nutzt er das gespeicherte Mandat; bei Überweisung stellt er eine offene Rechnung aus, ohne einen Einzug anzustoßen.
• 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 legt der Betreiber danach von Hand beim Zahlungsdienstleister an — im selben Nummernkreis wie die Abo-Rechnungen — und ihre Kopie wird 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, eine unserer zwei Erlösquellen ausließe.

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 entstehen ebenfalls beim Zahlungsdienstleister und tragen damit Nummern aus demselben Kreis. Es gibt genau einen Nummernkreis; ein zweiter, aus einer anderen Quelle gespeister, ist genau die Stelle, an der Lücken und Doppelungen 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 Code sieht diesen Fall vor, er kommt aber nicht vor — die entgeltlichen Angebote richten sich ausschließlich an Unternehmer (AGB, Abschnitt 4). Der Satz würde je Fall beigebracht statt aus einer Tabelle im Code.
• 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 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

Alle 15 Minuten ziehen wir einen Dump der Datenbank; jeder wird direkt nach dem Schreiben auf Lesbarkeit geprüft und geht dann als Off-Site-Sicherung auf fremden Speicher in Deutschland, clientseitig verschlüsselt, bevor er den Server verlässt. Einmal täglich gehen Datenbank und Objektspeicher mit den Rechnungs-PDFs zusätzlich verschlüsselt auf eine getrennte Maschine bei einem anderen Anbieter, ebenfalls in Deutschland; unser Server kann dort Stände ablegen, aber keine löschen. Beide Ziele halten die Stände 30 Tage.

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.5, Stand 28. September 2026. Dazu passen: Auftragsverarbeitung, Betrieb & Datenschutz, Datenschutzerklärung.