Billing Software for European SaaS: What It Needs to Handle

Billing software becomes a critical system for B2B SaaS once revenue stops being a single fixed monthly price. The first enterprise contract with custom commitments, a usage-based plan, or sales into several EU countries is enough to turn invoicing into a revenue operations problem. From then on, scaling depends on whether product data, tax logic, payment status, and accounting data stay consistent.

Many teams notice this only at month-end close. Usage events sit in the data warehouse, prices in feature flags, discounts in the CRM, payments at the PSP, and invoices in a separate tool. Finance reconciles all of it in Excel, and engineering builds the exceptions into webhooks. That works until a price change has to be corrected retroactively, a direct debit bounces, or a tax audit asks how a particular invoice was derived.

What billing software has to handle in SaaS

An invoice is the end result of a chain of business decisions. First, the product team defines a catalog of products, prices, seats, included usage, overages, minimum spend, and promotions. Next, the system assigns the right price version to each customer contract. Only then can it calculate recurring and usage-based line items, apply tax rules, collect payments, and generate accounting data.

A pure invoicing tool usually covers only the last, visible part of that chain. It creates PDFs and sends payment reminders, but it doesn't know when a usage event becomes billable or what contract logic sits behind a revenue deferral. A payment provider processes payment instruments, yet it isn't the system of record for invoice numbers, the place of supply for VAT, or revenue schedules.

For European B2B software companies, billing is therefore infrastructure. The authoritative data objects should be clearly defined: customer, legal entity, contract, price version, entitlement, usage event, invoice, payment, receivable, and ledger. Every change has to be traceable. If a customer switches to a new plan in May, the April invoice must not silently lose its basis.

The main architecture question: which system holds the truth?

The usual stack of product database, CRM, payment provider, invoicing plugin, and accounting system looks flexible at first. In practice it produces several versions of the truth. The CRM says the customer has 100 seats, the application counts 104 active users, and the invoice bills 95 seats. Beyond the operational cleanup, that mismatch affects revenue, receivables, tax, and auditability.

A reliable billing architecture separates responsibilities without breaking the data flow. The product sends normalized events such as api_call, active_seat, or gb_processed, each with a stable customer and time reference. The billing layer rates these events against a versioned catalog. It creates documented invoice line items and hands payment transactions to Stripe, GoCardless, or SEPA Direct Debit processes. The general ledger then receives ledger data it can rely on.

Corrections are where this gets hard. Usage events can arrive late, be sent twice, or be canceled after the fact. Billing software needs idempotency, clear cut-off rules, and a defined way to handle late arrivals. One event must never create revenue twice. A retroactive correction must not overwrite a finalized invoice without a trace; it has to appear as a credit note, an additional charge, or a clearly referenced corrective invoice.

Price changes without a deploy

Pricing logic doesn't belong in scattered application code paths. If every change to package limits, free allowances, or discounts needs a release, pricing ends up in the engineering backlog. That slows down experiments and raises the risk that contracts are calculated incorrectly.

Versioned price plans fix this only if they apply across the whole lifecycle, from contract signature through usage rating to the invoice line item and revenue recognition. Each plan needs an effective date and unambiguous proration rules. It also needs a defined answer to whether a customer moves to the new catalog when prices change or keeps their existing terms.

Hybrid models make this especially relevant. One contract can combine a €500 platform fee, 20 included seats, a price per additional seat, and volume-based API overages. Add an annual commitment, a one-time onboarding item, and a time-limited discount. If you model rules like these as free-form invoice lines, you lose automation exactly where it starts to matter financially.

European compliance can't be added later

International billing tools are often optimized for card acceptance and US tax logic. That isn't enough for European SaaS. The billing software has to handle invoicing under local requirements, the tax decision, and payment processing as one connected process.

For B2B sales within the EU, the invoice depends on where the customer is established, a valid VAT ID (USt-IdNr.), the type of service, and the legal status of the companies involved. The VIES check and correct reverse charge wording have tax consequences. If they're missing, or applied without evidence, the company carries the tax risk. B2C transactions can add the EU VAT One-Stop Shop (OSS), country-specific tax rates, and correct reporting data.

The invoice format isn't a free choice either. Public-sector buyers, and more and more large companies, require structured e-invoices. XRechnung and ZUGFeRD under EN 16931 need consistent mandatory fields, machine-readable line items, and valid tax information. A PDF with an embedded logo is no substitute.

GoBD compliance is about the traceability of records. Invoice numbers, cancellations, changes, and supporting documents need an auditable history. A platform that overwrites data retroactively saves effort in the short term and later leaves a gap in the audit trail that is hard to explain.

Payment collection: a "failed" status isn't enough

With recurring B2B revenue, you can't take a paid invoice for granted. SEPA direct debits play a big role in Germany and across Europe, and they behave very differently from a simple card authorization. Returns and R-transactions come with reasons, deadlines, and follow-up actions that a blanket retry doesn't cover.

A direct debit rejected for insufficient funds needs different handling than a mandate problem or a return after the customer disputes the debit. Good dunning processes take into account the payment method, customer value, invoice amount, retry timing, and the actual return reason. They send reminders, and they also keep the open receivables under control.

The same applies to card payments. Well-designed dunning limits how often it retries a charge. It records the status, triggers clear communication paths, and prevents a suspended account from continuing to use the service because the product logic wasn't aligned with billing. Payment status, access rights, and receivables management need defined interfaces between them.

Revenue recognition and accounting can't wait

Cash, invoiced revenue, and recognized revenue are different figures. Annual contracts paid in advance make this obvious: the invoice can be issued and paid on day one, while the revenue is earned over the service period. With usage models, the amount also depends on the contract logic and on when the usage happened.

IFRS 15 and ASC 606 require reliable rules. Which performance obligations exist? Is a setup fee recognized immediately or over the contract term? How are contract modifications handled? Can revenue deferrals be derived from the original invoice and service data?

If finance builds revenue schedules by hand from invoice exports, the work grows with every contract variant. A month-end close without Excel only becomes realistic when billing schedules, deferred revenue, and accounting periods come from the same data. The DATEV export is part of that chain. It has to deliver accounts, tax codes, document references, and periods in a form accounting doesn't have to translate again.

Criteria for choosing billing software

The right solution depends on the business model. A SaaS company with one fixed monthly plan needs less than a marketplace with multiple legal entities, variable usage, and local payment methods. Still, engineering and finance should work through the same questions:

• Can the product catalog be versioned, including proration, commitments, promotions, and custom contracts?
• Are usage events processed idempotently, assigned to the correct period, and stored so they can be traced down to the invoice line?
• Does the system natively support EU VAT OSS, reverse charge, VIES checks, and XRechnung and ZUGFeRD under EN 16931?
• Can you control SEPA direct debits, R-transaction routing, dunning, and external payment providers through unambiguous status transitions?
• Does the platform produce auditable ledger data, revenue schedules under IFRS 15 or ASC 606, and exports that work in DATEV?
• Is the API designed so product teams can integrate billing without rebuilding tax and invoicing logic themselves?

Kontier is built for exactly this combination of product catalog, usage, European compliance, payment collection, and financial data. Even so, a feature list tells you less than a concrete end-to-end test: take one customer from a plan change through recorded usage and a tax-correct invoice to a successful SEPA payment, the revenue deferral, and the posting at month-end close.

Make the decision on a real contract with all its exceptions. If you model that case precisely before rollout, your billing can grow with the business model and won't slow it down every time prices change.