GoBD for SaaS billing: immutability, audit trail and eight years

A customer rebrands in the autumn and updates its company name in your self-service portal. Three months later its accounts team asks for a copy of a spring invoice. Your billing system regenerates the PDF, and it now shows the new name. Nobody edited an invoice, yet the copy no longer matches what was sent.

Germany's GoBD, the tax administration's rules for keeping books and records electronically, use almost exactly this case as an example of what goes wrong: tax rate and customer name overwritten in master data with no history. The rules are published by the Federal Ministry of Finance as a BMF letter (GoBD, in German). They apply to anyone keeping German tax records, including non-German SaaS companies with a German entity. This article takes the GoBD principles that hit a SaaS billing stack hardest (immutability, traceability, retention and process documentation) and turns them into checks for your data model and operations. If you're choosing a tool right now, the selection criteria are in our post on choosing GoBD-compliant invoicing software.

No certificate makes your billing system GoBD-compliant

The German tax authorities don't issue positive attestations that a bookkeeping system is compliant, neither during a tax audit nor as a binding ruling. A vendor's "GoBD certificate" can help with selection, but it doesn't bind the tax office. Whether your billing is compliant depends on configuration, access rights, releases, and how your team handles corrections.

In a SaaS stack, compliance is spread across several systems. Metering supplies quantities, the product catalogue supplies prices, billing issues invoices, the payment provider reports payment status, and the accounting system books it all. Every hand-off between those systems is a place where information can be lost or overwritten.

Immutability: corrections are new records

The GoBD build on § 146(4) of the German Fiscal Code (AO): a booking or record must not be altered in a way that makes the original content impossible to determine, and changes and deletions must be logged. In billing, that affects three places.

The first is the invoice. While it's a draft it may change. Once it has an invoice number and has been sent, it's locked. A wrong amount gets fixed with a cancellation and a new invoice, or a corrective invoice referencing the original, never by updating the existing line. Check concretely whether your admin UI or API still lets someone PATCH a finalised invoice. Some tools allow it for "notes" or "metadata" fields that then appear on the PDF.

The second is master data. Customer name, address, VAT ID, tax rate and price must either be copied into the invoice when it's finalised, or kept with a validity period. A data model that does both looks roughly like this:

The third is usage data. When a product team sends corrected quantities after the fact, the old record isn't overwritten. A correction event is created that points to the original. That's the only way to show later which quantity was billed and why next month's credit note exists.

Traceability: from invoice line to event and back

The GoBD require that a knowledgeable third party can follow each transaction from origin to completion within a reasonable time, forwards and backwards, for the whole retention period. For usage-based SaaS invoices that's a concrete test.

Backwards: the March invoice says "API calls: 48,120". Can you trace that number to individual events, including discarded duplicates and the correction received on 2 April? Forwards: take an event from 14 March with idempotency key X. Which invoice line did it land on, and which entry in the DATEV export? If either direction needs a manual join across three CSV exports, the chain isn't auditable in practice.

Technical logs rarely suffice on their own. An invoice.updated entry tells an auditor nothing. They need the business event: who, when, what changed, why, and the effect on the receivable and the VAT.

Eight years from year end: when an invoice may be deleted

Germany requires invoices to be kept for eight years (§ 14b UStG), and accounting vouchers likewise for eight years under § 147(3) AO. Books, journals and annual financial statements stay at ten years. A deletion job in billing therefore has to tell invoice data apart from the ledger data held in accounting.

The period starts at the end of the calendar year in which the invoice was issued. An example: invoice dated 14 March 2026, period starts 31 December 2026, ends 31 December 2034, earliest deletion 1 January 2035. Even then only if the invoice no longer matters for taxes whose assessment period is still open, for instance during an ongoing tax audit. A job that simply computes "invoice date plus eight years" deletes this invoice more than nine months early.

Two points are specific to billing systems:

• For e-invoices, the structured XML is the original. The GoBD prohibit conversions that reduce machine readability, so an archive holding only the human-readable rendering or an image isn't enough.
• An invoicing system needn't store every PDF from the moment of issue if it can produce an identical copy on demand. The GoBD condition: master data, terms and conditions, and the letterhead layout are all versioned. That's exactly what fails in the opening example. If you re-render PDFs on request, you need that history. If you don't have it, archive the file you actually sent.

Process documentation for a SaaS billing stack

The process documentation (Verfahrensdokumentation) describes how data is created, processed, stored and reproduced. Under the GoBD it normally has four parts. For a SaaS stack they mean:

Versioning is the part teams underestimate. The documentation has to show, for the whole retention period, how the system worked at any given time. A team that deploys weekly doesn't need a document per release. It needs a change history that dates every billing-relevant change: new rounding logic, a changed tax determination, a new mandatory field in XRechnung output. A changelog in the repository that the process documentation references is often the most practical route.

Six checks you can run this week

These need no auditor, just a test environment and an afternoon:

1. Change a test customer's name and address. Re-render an old invoice and compare it with the file that was sent.
2. Try to change a finalised invoice through the admin UI and the API, including note and metadata fields.
3. Take one usage-based invoice line and trace it back to individual events. Note how long it takes.
4. Check which file your archive keeps for e-invoices: the XML, the rendering, or both.
5. Read your deletion job's condition. Does it count from year end, and does it know about open assessment periods?
6. Find the last change to tax determination in your process documentation. Is it dated?

Every check that fails becomes a specific task with a clear outcome. Kontier covers usage metering, subscription billing, XRechnung and auditable exports in one system; the German-market specifics are on the billing for Germany page.