Procedural documentation

Version 1.0 · as of 27 August 2026 · GoBD

This page describes how an invoice at patchletter comes about, how it is numbered and taxed, where it is stored and how long it stays there. It is written for two kinds of reader: a customer who wants to know what happens to their billing data, and an auditor who wants to understand the process before asking for documents.

1. Scope

Covered are outgoing invoices of patchletter UG (haftungsbeschränkt) i. G., Meisterweg 16, 45896 Gelsenkirchen. Two revenue streams exist: subscriptions (patchletter Pro and MSP) and vendor presence on a product page. Responsibility for the process lies with the Managing Director; bookkeeping and the annual accounts lie with the tax adviser.

2. Systems involved

• The application and its database run on our own server in Germany. The database holds one row per invoice: period, net, VAT, gross, rate, status, issue and payment date, and the storage key of the PDF.
• The payment provider (Mollie B.V., Amsterdam) collects payment, produces the invoice document and sends it to the customer.
• Our own object storage, on the same server, holds a copy of every invoice PDF.

3. How an invoice comes about

Subscriptions run automatically:

• A scheduled run picks up the organisations whose billing period has ended and which pay by direct debit mandate.
• Before anything is charged, the invoice row is written to our database. It carries a uniqueness constraint on organisation plus period start: if the run restarts, the second attempt hits that constraint and stops. Writing the row first and charging afterwards is the whole point — the other way round the money would be taken before anything could prevent it.
• An organisation without billing details is skipped and reported, not guessed at. Anyone paying by bank transfer has no mandate and is never included in a direct debit run.
• Every step leaves an entry in an event log — invoice created, payment succeeded or failed, mandate revoked, chargeback, plan changed, dunning step. A duplicate webhook delivery produces one entry, not two.

Vendor presence is invoiced by hand. The agreement is concluded by email, the invoice is written manually and filed in the same place as the automated ones. There is no self-service checkout for it yet. We name this because a procedural documentation that describes only the automated path would describe the smaller half of our invoices.

4. Invoice numbers

The number for a subscription invoice is issued by the payment provider, in its continuous number range, and stored in our row alongside its own identifier. We do not issue those numbers ourselves, and we do not claim to: what protects against a duplicate invoice here is the database constraint described above, not a counter of ours.

Manual invoices for vendor presence run in a separate, self-maintained number range. Keeping the two apart is deliberate — a shared range fed from two places is exactly where gaps appear.

5. VAT

The rate and the mandatory note on the invoice are determined in one single place in the code, because the same figure appears on the invoice, in the amount collected and in the text below it — three places that can drift apart without anyone noticing until someone checks. Four cases are distinguished:

• Small business scheme (§ 19 German VAT Act): no VAT is shown at all. This case overrides every other one — a rate shown despite it would still be owed under § 14c.
• Germany: the standard rate.
• Business customer in the EU: reverse charge — but only with a VAT ID that has actually been verified against VIES. An unverified number is treated like none at all, because basing reverse charge on it means owing the tax ourselves.
• Private customer in the EU: the rate of their country of residence, reported through the One-Stop-Shop scheme. The rate is supplied per case rather than from a table in the code — 26 rates that change do not belong in a file nobody maintains.
• Outside the EU: not subject to German VAT.

Amounts are calculated in cents and rounded commercially to the whole cent.

6. Format

Invoices are issued as PDF. A structured electronic invoice (ZUGFeRD/Factur-X or XRechnung) is prepared for in the data model but not in operation; we will say so here on the day it is, and not before. Incoming electronic invoices we can receive and archive.

7. Archiving

Immediately after an invoice is created, its PDF is fetched and written to our own object storage under a fixed key. The customer's account and every link we send point at our own copy, never at the payment provider's document: those links are signed and expire, so a directly linked PDF stops working the next day — and the ten-year retention is our obligation, not the provider's.

What is not in place: the object storage has no write protection (WORM/object lock), and we do not compute a checksum per document. Unchangeability today rests on access being limited to the operator and on the backups, not on the storage refusing the write. We consider that a gap worth closing, and it is on the list rather than in this text as an achievement.

8. Backups

The database is backed up hourly and every backup is checked for readability right after it is written; a copy goes to a second machine in Germany. Off-site copies to external storage are encrypted client-side before they leave the machine. Hourly backups are kept for 30 days, the one taken on the first of each month for a year.

9. Access

Inside a customer organisation, invoices are visible to owner and admin only — they carry the company address and VAT ID, and a technician with a login has no business there. On our side, access is limited to the operator through the admin interface and to the tax adviser for the documents handed over. Server access requires an SSH key; the product itself has no passwords.

10. Retention and audit access

We retain invoices and the associated records for ten years. The retention period for accounting vouchers was shortened to eight years by the Fourth Bureaucracy Relief Act; we do not make use of the shorter period, because two different periods within the same set of records create more room for error than they save in storage.

For a tax audit we can provide the invoice documents and an export of the invoice and event records in a common, machine-readable format. That export is prepared by hand today; there is no button for it.

11. Changes to this document

Every change to the process changes this page and the internal version of it, which carries the change history. Both live in the same repository as the code they describe, so a change to the billing run and a change to its documentation travel in one commit.

Version 1.0, as of 27 August 2026. Related: data processing agreement, operations & data protection, privacy policy.