How to Create a Reverse Charge Invoice for EU B2B SaaS

The error is rarely in the invoice PDF. To create a reverse charge invoice, you need to know at checkout or contract signing whether the customer is a business, where it is established, and whether its VAT ID (USt-IdNr.) was valid. If that decision is missing from the billing flow, you get invoices with the wrong tax logic, corrections after the fact, and a month-end close that ends up in Excel again.

For European B2B SaaS companies, reverse charge is a routine case. Recurring software fees, usage-based API billing, platform commissions, and professional services are regularly invoiced across borders. The invoice logic therefore has to determine from product, customer, and tax data, in a reproducible way, when an invoice shows no German VAT and when the customer owes the tax.

When to create a reverse charge invoice

In the typical EU B2B SaaS case, a German company supplies a service to a business in another EU member state. The place of supply is generally where the customer is established. Liability for the VAT passes to the customer. The German provider invoices the net amount, and the customer declares the VAT in its own country.

You cannot derive this rule from the country code alone, though. It depends on the specific supply, the customer's status as a business, and a reliable VAT ID. Reverse charge can also apply to domestic German transactions, but only for certain services defined in Section 13b UStG. Customers outside the EU come with different place-of-supply and evidence requirements. A flag like reverse_charge=true on the customer record is therefore not enough of a tax architecture.

For digital B2B services, billing teams should distinguish at least three cases: EU businesses with a valid VAT ID, domestic Section 13b cases, and customers in non-EU countries. Only then do they decide whether German VAT, OSS logic, or reverse charge applies. Customers who change their legal form, billing address, or VAT ID during a subscription need particular attention.

Mandatory details on a reverse charge invoice

A reverse charge invoice differs from a regular invoice with 0 percent VAT because it has to document the tax reason clearly. For German issuers, the requirements of Section 14 UStG apply, and for certain reverse charge cases also the additional rules in Section 14a UStG.

In particular, the invoice needs:

the full name and full address of the supplier and of the customer,
the tax number or VAT ID of the supplier and the VAT ID of the EU business customer,
the issue date, a sequential and unique invoice number, and the service period,
a precise description of the service, such as the plan, seats, usage period, or platform fee,
the net amount for each tax treatment and any discounts,
the statement "Steuerschuldnerschaft des Leistungsempfängers" (VAT liability of the recipient).

No VAT amount is shown in this case. A blanket note such as "VAT exempt" is also not precise enough for a German reverse charge invoice. It mixes up a tax exemption and the recipient's VAT liability, which are two different situations in legal and operational terms.

A minimal invoice example could look like this:

Service period: July 1, 2026 to July 31, 2026
Product: API Platform, 20 seats and 1,240,000 usage events
Net amount: EUR 2,480.00
VAT: not shown
Note: Steuerschuldnerschaft des Leistungsempfängers (reverse charge)

The precision of the service description matters. In an audit, "Software subscription" may be too vague if the contract and usage data describe a different service. With hybrid models, the invoice should show which base fee, which seats, and which variable events were billed.

Check the VAT ID and store the evidence

The VAT ID is a compliance attribute that belongs to a point in time, so it cannot be a field that sales enters once in the CRM and finance copies later. A qualified VIES check has to happen before the first EU B2B invoice without VAT. Store the result with the customer and invoice records in an audit-proof way, including the number checked, company name, address, timestamp, and result.

For recurring revenue, checking the number when the account is created and then forgetting about it is not enough. Risk-based revalidation makes sense, for example at renewals, changes to the billing address, large jumps in volume, or after failed checks. The right frequency depends on revenue volume, customer structure, and your internal tax risk framework.

If the check fails, the billing system must not apply reverse charge silently. It needs a defined status, for example a blocked tax decision, an invoice held for review, or taxation under a validated alternative rule. That way you can still trace why an invoice was held back or calculated with VAT.

Automating reverse charge in subscription billing

A single reverse charge invoice can be created correctly by hand. The problem starts with 5,000 invoices a month, mid-month plan changes, credit notes, and usage events that arrive late. At that point the PDF has to be right, and so does every downstream posting.

A sound architecture separates the product catalog, the tax decision, and invoice rendering. The product catalog defines prices and billing intervals. Customer and tax profiles supply the country, business status, VAT ID status, and any special rules. From these, the tax engine produces a versioned tax decision for each invoice line. Rendering carries that decision into PDF, XRechnung, or ZUGFeRD without templates changing it.

This is where revenue infrastructure differs from an invoice template. Price changes without a deploy only work if the tax decision is not stored several times over in checkout code, Stripe metadata, and accounting rules. Every invoice needs a traceable snapshot: the plan used, usage events, service period, customer data, VIES status, tax rule, and ledger posting.

Corrections follow the same standard. If a VAT ID is validated after the fact or a usage quantity is corrected, the system must not overwrite the historical original invoice. It creates a cancellation invoice or corrective invoice that references the original document and posts the difference to the ledger in a traceable way. Many billing stacks fail at exactly this point. The frontend shows the correct current amount, but finance can no longer reconstruct how the historical decision was made.

Kontier models this chain as a European billing workflow. Tax decision, invoice document, payment, receivable status, and DATEV-ready ledger data all rest on the same billing basis. This reduces manual corrective invoices and also keeps data from diverging between billing, the payment provider, and the general ledger.

Structured invoices: reverse charge in EN 16931

If you generate XRechnung or ZUGFeRD, writing reverse charge as free text into a PDF is not enough. The tax category and the reason for the tax treatment also have to be represented consistently in the structured invoice data. EN 16931 provides a reverse charge tax category for this. The code, tax base, and mandatory notes have to match the visible invoice document.

This matters most when recipients validate invoices automatically or when public-sector buyers require specific formats. A PDF that looks correct does not make up for missing or contradictory information in the XML. For engineering, this means modeling tax rules as business data instead of text snippets in an email template.

Typical mistakes with costly consequences

A common mistake is applying reverse charge even though the VAT ID is invalid or undocumented. Showing German VAT in addition to the reverse charge note is just as problematic. The customer then cannot process the invoice cleanly, and the issuer may end up owing the VAT shown on the invoice.

Credit notes are often underestimated too. They have to reference the tax logic of the original invoice and must not be recalculated with customer settings that have changed since. The same applies to prorated plan changes, where the service period helps determine which tax decision was valid at the time.

Finally, reverse charge does not replace proper revenue recognition. The invoice determines the receivable and the tax documentation, while IFRS 15 or ASC 606 also require consistent treatment of performance obligations, contract terms, and revenue schedules. A shared event and ledger model prevents usage from being fully invoiced in billing but only partly accrued at month-end close.

Whether a reverse charge invoice is right is decided before the PDF export. The invoice is the visible result of a documented tax decision, validated customer data, and immutable billing events. Once that data chain is in place, the month-end close stays under control without Excel.

How to Create a Reverse Charge Invoice in B2B