How to Choose GoBD-Compliant Invoicing Software

An invoice is an accounting record. It has a history of how it was created, a tax context, a payment status and a correction path, so it cannot simply sit in an S3 bucket as a PDF once it has been sent. For SaaS companies this becomes a problem as soon as prices, usage, countries and payment methods no longer fit a rigid subscription scheme. GoBD-compliant invoicing software therefore has to do more than assign invoice numbers. It has to turn product and event data into business transactions that are traceable and documented in a way that cannot be changed.

This is not a side requirement for finance. When billing logic and compliance grow separately, you get manual corrections, unclear document chains and a month-end close that depends on CSV exports and on what a few individual employees know. A better architecture connects monetization, tax, receivables management and ledger data from the start.

What GoBD compliance requires from invoicing software

The principles for the proper keeping and retention of books, records and documents in electronic form and for data access (GoBD) cover more than archiving. They require traceability, verifiability, completeness, accuracy, timely recording, orderliness and immutability. For invoicing software, this means an auditor must be able to reconstruct a business transaction from the source document to the accounting entry and back.

A sent invoice must not be silently overwritten. If a price, an address or a tax rate changes after invoicing, you need a documented correction, for example a cancellation invoice followed by a reissued invoice, or a credit note. The original version is preserved, and the link between the original document and the correcting document stays visible. A UI that simply edits the amount on an old invoice does not produce a reliable history.

The procedural documentation matters just as much. It describes how invoices are created, checked, sent, corrected, archived and handed over to accounting. Software cannot fully replace this documentation, but it should supply the facts it relies on: status changes, timestamps, user or system actions, invoice number ranges, the tax decision, the payment reference and export logs.

Why classic invoicing tools fail at SaaS billing

A simple invoicing module works when a contract produces the same amount every month. European B2B software rarely works that way. A customer may pay for ten seats in advance, be billed for API requests by consumption, activate an add-on mid-month and receive a credit note because of an annual minimum commitment. Each of these changes affects the invoice, revenue deferral, tax and possibly the dunning process.

Many stacks spread this logic across the product database, the payment provider, homegrown jobs, the accounting tool and Excel. The cost goes beyond integration effort: there is no authoritative system of record. If usage events are delivered twice or processed late, you must be able to trace which events went into which invoice. If a plan changes, you need a versioned price rule. Updating a single field would also change historical billing.

Failed payments are the hardest case. An open invoice, a repeated SEPA collection and a returned direct debit are different events. The original receivable must not disappear just because a payment plugin sets a status to "failed." Finance needs the complete chain: receivable, payment attempt, return reason, renewed payment request and incoming payment.

GoBD-compliant invoicing software needs an immutable document flow

A dependable solution separates configurable business logic from results that have already been posted. Prices, discounts, entitlements and tax codes may change. Once an invoice has been generated from them, the underlying snapshot is frozen. At a minimum, that snapshot covers the invoice lines, quantities, service period, currency, customer data, tax decision, payment terms and the price version used.

For usage-based billing, an invoice PDF is not sufficient evidence. The invoice should point to usage data that can be aggregated and reproduced. In practice, the platform stores when an event arrived, which account it was assigned to, which metering rule rated it and which billing period it ended up in. Corrected events must not hide the history. They trigger a documented delta process.

Invoice numbering also deserves more attention than it often gets. Invoice numbers have to be assigned uniquely and traceably. Whether the sequence restarts each year or runs continuously depends on your internal process. What matters is that gaps can be explained and that canceled or aborted documents do not vanish from the system without a trace.

Tax logic is part of the invoice document

An invoice can be formally correct and still wrong for tax purposes. For European B2B models, invoicing software has to determine whether German VAT applies, whether reverse charge applies, or whether the transaction is a B2C supply that falls under the One-Stop Shop (OSS). To do that, it needs reliable customer data, place-of-supply logic and a traceable justification for each tax decision.

With reverse charge, showing 0 percent VAT is not enough. The invoice needs the correct reverse charge note, and the VAT ID (USt-IdNr.) should be verified before billing, with the result documented. A later change to the customer data must not retroactively rewrite an invoice that has already been issued.

Structured invoice formats improve interoperability. XRechnung and ZUGFeRD under EN 16931 also force teams to model invoice data precisely. That exposes gaps a clean-looking PDF hides, such as a missing Leitweg-ID, unclear service periods, tax categories that cannot be mapped or inconsistent units. If you sell to public-sector buyers, these formats have to be part of daily operations. Treating them as an export project at the end of the quarter does not work.

DATEV export and ledger: the month-end close test

GoBD-compliant invoicing software is not automatically a complete financial accounting system. It does have to hand over data in a form that lets finance post, reconcile and audit correctly. A DATEV export without a stable document reference, account assignment, tax code, posting date and offsetting account only moves the work to your tax advisor's office.

The deciding test is this: can a DATEV posting be traced back to the invoice, the payment event and, where relevant, the credit note? For payments through Stripe or SEPA, fees, payouts, returned direct debits and open receivables should each be traceable on their own. A net payout does not prove that every individual movement was recorded correctly.

Subscription and usage-based revenue adds revenue recognition to the picture. Invoice date, service period and revenue recognition do not necessarily line up. If you report under IFRS 15 or ASC 606, you need logic that assigns contract performance to the correct periods without distorting the invoice and tax data. That is one more reason not to sync billing and finance data across multiple spreadsheets.

Selection criteria for European billing teams

Almost any tool can produce invoices, so that question should not drive the evaluation. Ask whether the solution connects complex product models with an auditable document flow.

First, check whether price and product versions are frozen historically and whether corrections run through traceable correcting documents. Then look at the data layer: can usage events be deduplicated, assigned to the right period and reproduced per invoice? Without that capability, usage-based billing becomes expensive at the latest when a customer complains or an audit begins.

The third step covers European processes: EU VAT OSS, reverse charge, VIES checks, XRechnung, ZUGFeRD, SEPA Direct Debit and the routing of R-transactions. A global billing tool with a retrofitted VAT plugin can fit if the business model stays simple and German payment and accounting processes play no central role. As complexity grows, those add-ons become an operational dependency.

Finally, engineering needs an API that reliably represents state as well as generating documents. Price changes without a deploy are only an advantage when permissions, approvals and version histories are under control. A month-end close without Excel is only realistic when billing, payment status and the ledger export work from the same event data.

Kontier is built for exactly this combination: European compliance architecture, billing for hybrid revenue models, payment collection and accounting-ready data in one platform. The yardstick for any tool, though, is whether every amount in the month-end close can be traced back to the product decision and the individual document, and a feature list on a slide cannot show that.

If your team has to open tickets between engineering and finance before it can handle price changes, returned direct debits or tax edge cases, the missing piece is shared infrastructure that turns operational events into auditable financial data. Another invoice template will not supply it.