How to Choose E-Invoicing Software for SaaS

An invoice can look correct as a PDF and still not be an e-invoice. For B2B SaaS companies this gap shows up in day-to-day operations. When the product catalog, usage events, tax logic, payment collection, and accounting come from different systems, discrepancies appear exactly where EN 16931 requires structured, verifiable data. E-invoicing software therefore has a bigger job than generating XML: it has to turn billable product and financial data into a consistent invoice, a traceable payment process, and ledger data you can rely on.

Since 2025, domestic B2B businesses in Germany must, as a rule, be able to receive e-invoices. Sending is phased in with transition periods. From 2027 the obligation applies to companies with prior-year revenue above €800,000, and from 2028 it covers, in principle, all domestic B2B sales. If you are setting up billing now, don't treat these deadlines as an output format to add later. Your data models, approvals, and archiving processes need to be built for structured invoices today.

What e-invoicing software has to handle in SaaS billing

In the German context, an e-invoice is an invoice in a structured electronic format that allows automatic, electronic processing. A PDF sent by email does not meet that definition, even though it is delivered digitally. XRechnung and ZUGFeRD based on EN 16931 are the established formats for German and European requirements.

For a company with fixed monthly plans, generating these formats is already a process of its own. With hybrid models it becomes an integration problem. Take a customer with 20 seats at the base price, volume-based API calls, a time-limited discount, and a credit note issued later. The e-invoice has to present the resulting line items, quantities, periods, tax rates, and payment terms correctly, and it has to output them in a machine-readable, semantically consistent form.

So when you evaluate a tool, an XRechnung export alone tells you little. Ask whether the XRechnung is generated from the same versioned billing data as the payment amount, the receivable status, revenue recognition, and the DATEV posting record. If it is not, every corrective invoice turns into a manual reconciliation case.

EN 16931 defines a data contract

EN 16931 defines the core semantic model of an electronic invoice. Among other things, it sets the requirements for seller and buyer data, invoice references, payment information, tax breakdowns, and totals. XRechnung implements this model for German public-sector buyers. ZUGFeRD, depending on the profile, combines structured XML data with a human-readable PDF.

For engineering teams this leads to a clear architecture decision. The structured invoice must not be derived backward from a PDF or rebuilt in a separate converter. It should come from a canonical invoice object that holds the immutable invoice data, line items, tax decisions, references, and totals. PDF, XRechnung, and ZUGFeRD are then different representations of the same financial transaction.

This reduces errors in rounding, currency conversion, and corrections. It also prevents a familiar conflict in which finance finds one invoice amount in the ERP while engineering sees a slightly different calculation in the billing system. A month-end close without Excel starts with a shared source for billing-relevant data.

Choosing e-invoicing software starts before invoices go out

Many tools cover part of the requirement. They generate XML, send documents, or store PDFs. For European SaaS companies, one of these capabilities on its own is rarely enough. The decision depends on how closely the software has to connect to product logic and financial processes.

For a simple German B2B business with fixed prices, the invoicing module in the ERP may be enough. Once price changes, usage-based billing, multiple countries, or automated collection come in, the integration effort grows quickly. At that point the company needs a billing infrastructure with controlled states, and e-invoice output becomes one part of it.

Check four layers in particular:

• Product and pricing logic: Can plans, seats, tiered pricing, minimum amounts, promotions, and usage events be versioned? An invoice has to stay reproducible even if the product catalog changes later. Price changes without a deploy only hold up if the pricing version in effect at billing time is stored.
• Tax and compliance logic: Does the system handle German VAT, EU VAT OSS, reverse charge, tax exemptions, and VIES checks as part of the invoice logic? A tax rate field on its own does not make a tax engine.
• Payment and receivables processes: Are payment terms, SEPA Direct Debit, card and bank payments, returned direct debits, dunning levels, and R-transaction routing linked to the open receivable? When an invoice is paid, the status change cannot stay inside a payment plugin.
• Ledger and accounting: Can invoices, credit notes, tax amounts, incoming payments, and revenue be turned into traceable journal entries and DATEV exports in the correct period? For IFRS 15 or ASC 606, an invoice number does not serve as a revenue schedule.

These layers don't have to sit in a single product. Several specialized systems can make sense, for example when you already run an ERP or have complex enterprise collections. In that case you need an explicit system of record for each decision. Which system decides the invoice amount and invoice version? Which one owns the receivable status? Which one writes the immutable audit log? Without these answers, every API integration multiplies the cost of reconciliation.

Use XRechnung, ZUGFeRD, and PDF side by side

XRechnung matters most for invoices to public-sector buyers. ZUGFeRD is practical in B2B when recipients expect both a readable document and structured data. A PDF stays useful for people, but on its own it does not meet the requirements for an e-invoice in the intended structured sense.

Good e-invoicing software handles all three in one workflow. It picks the representation to deliver based on the recipient profile, jurisdiction, channel, and agreement. The underlying invoice stays identical. If a recipient switches from PDF to XRechnung, the switch must not recalculate prices or create a second invoice record.

Validation matters too. XML that is technically well-formed can still violate the EN 16931 business rules. A missing buyer reference, incomplete payment information, or inconsistent tax and total amounts then lead to rejections. Validation has to run before sending and be visible as a process status, so errors come up before the customer complains.

With usage-based billing, the event chain decides

Usage-based billing raises the requirements for every invoice. A usage event needs a unique identity, a timestamp, a customer reference, a unit of measure, and a traceable mapping to a price version and billing period. Events delivered twice, late corrections, or customer migrations after the fact must not lead to uncontrolled double billing.

The invoice comes at the end of this chain. In a reliable flow, events are deduplicated and rated, the billing period is closed, and an invoice draft is created. Only after business approval is the final invoice numbered and issued. Once the invoice is finalized, the existing document stays as it is. Any change goes through a credit note, a cancellation, or a new invoice with a clean reference.

This goes beyond formal compliance. The same state logic lets finance explain a disputed amount and lets engineering reproduce a calculation when debugging. If you overwrite usage data after an invoice has been sent, you lose both.

Tax, payments, and accounting need the same source of truth

Billing stacks break most often at national borders. Say a German SaaS company invoices a French company with a valid VAT ID (USt-IdNr.), a German customer without a VAT ID, and a private individual in another EU country. The tax treatment, the mandatory invoice details, and, where applicable, the OSS reporting data differ for each. If the tax decision is made outside the billing system, you end up with manual exceptions and unclear responsibilities.

The same goes for payments. An invoice with a SEPA direct debit mandate, a failed submission, and a later returned debit needs more than an "unpaid" status. R-transactions such as reject, return, or refund determine whether you collect again, start dunning, or offer a different payment method. These decisions have to be tied to the specific receivable and its invoice history.

At month-end close, everything has to reconcile. Finance needs period-accurate data on revenue, receivables, VAT, discounts, credits, fees, and payment movements, and a stack of invoice documents does not supply that. If revenue recognition is calculated separately from the invoice run, the contract term, service period, and changes have to be referenced cleanly. Kontier connects these layers through a single API and a European compliance architecture, so e-invoicing, tax, and payment status don't have to be wired together after the fact.

Start the implementation with a reference case

Before you migrate your whole customer base, define a reference case that reflects your real complexity: an EU B2B customer, a hybrid plan, a validated VAT ID, usage events, SEPA collection, a price change during the contract, and a later credit note. This case should run from the product catalog to the DATEV export without manual correction.

Beyond checking that an XML file gets generated, measure the time to invoice, the share of documents validated before sending, the number of manual tax corrections, payment recovery after failed attempts, and the time spent on reconciliation at close. These metrics show whether e-invoicing software is just another channel in the stack or an operational foundation for scaling revenue operations.

When you compare vendors, look past the number of formats on the feature list. What usually decides the choice is whether each format traces back to verifiable product, tax, payment, and ledger data. With that in place, e-invoicing stays under control as you add plans, enter new markets, and grow volume.