Procedural documentation

Version 1.5 · as of 28 September 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), Meisterweg 16, 45896 Gelsenkirchen, Germany. Two revenue streams exist: subscriptions (patchletter Pro) 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 runs on a server in Nuremberg that we operate ourselves (hosting: netcup GmbH, Germany); the PostgreSQL database runs on the same server. 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 card and SEPA direct debit payments, produces every invoice document and sends it to the customer. Qonto SA (Paris) provides our receiving account for invoice transfers; a self-hosted reconciliation reads incoming transactions through its API.
• The object storage on the same server (Garage, S3-compatible) holds a copy of every invoice PDF.

3. How an invoice comes about

Subscriptions run automatically:

• A scheduled run picks up organisations whose billing period has ended. For card and SEPA direct debit it uses the stored mandate; for bank transfer it issues an open invoice without initiating a debit.
• 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 then created manually at the payment provider — in the same number range as the subscription invoices — and its copy is 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 leave out one of our two revenue streams.

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 are created at the payment provider as well and therefore carry numbers from that same range. There is exactly one number range; a second one, fed from a different source, is exactly where gaps and duplicates 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 code provides for this case, but it does not occur — the paid offerings are aimed exclusively at businesses (terms of service, section 4). The rate would be supplied per case rather than from a table in the code.
• 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 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

We pull a dump of the database every 15 minutes; every one of those dumps is checked for readability right after it is written and then goes off-site to an external storage service in Germany, encrypted client-side before it leaves the server. Once a day the database and the object storage with the invoice PDFs are additionally copied, encrypted, to a separate machine at a different provider, likewise in Germany; our server can add to that copy but not delete from it. Both destinations keep the states for 30 days.

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.5, as of 28 September 2026. Related: data processing agreement, operations & data protection, privacy policy.