A Billing API for Europe: Setting Up Complex B2B Billing Correctly
Anyone billing European customers with a US-centric billing architecture usually notices the break only at the first special case: a B2B customer with a valid VAT ID, a usage-based tariff, a SEPA chargeback, or an invoice expected as XRechnung. A billing API for Europe must not correct these cases after the fact via scripts and manual finance processes. It has to model them in the transaction model.
For B2B SaaS, platform, and infrastructure companies, billing is therefore not an isolated payments topic. Billing decides whether a new pricing model goes live in two weeks or whether engineering, finance, and operations spend months on tax rules, PDF templates, exports, and exception handling. The right API reduces implementation effort – and it creates a resilient foundation for revenue operations, compliance, and product velocity.
What a billing API for Europe must deliver
A European billing API doesn't start at checkout. It starts with a consistent data model for customers, contracts, prices, consumption, tax status, invoices, payments, and receivables. Every one of these states must be traceable: at the time of creation, of change, and of booking.
In a classic SaaS model, recurring monthly invoices often suffice. As soon as prices consist of base fees, seat tiers, API calls, data volume, or transaction values, the system needs precise usage metering. Consumption data must be processed idempotently: an event sent again must not be billed twice. At the same time, corrections, late-arriving events, and unambiguously versioned pricing logic must be possible.
A simplified technical flow looks like this:
usage.recorded → usage.validated → invoice.drafted → tax.calculated → invoice.finalized → payment.collected → payment.settled | payment.failed
This is more than an event chain. It defines responsibilities. Product and engineering deliver billable usage. Finance defines periods, tax scenarios, and approvals. Revenue operations steers dunning, customer exceptions, and contract changes. An API should connect these flows without every team maintaining its own spreadsheets and side processes.
Tax logic is part of the billing architecture
The most common architecture mistake goes like this: tax is added after billing. In Europe that doesn't work reliably. Tax status influences invoice content, tax amount, mandatory fields, reporting, and partly the timing of document creation.
For B2B supplies within the EU, reverse charge is a typical case. The system must capture the VAT ID and store it verifiably, determine the place of supply correctly, and generate the invoice with the appropriate notice. For B2C digital services, VAT OSS and country-specific tax rates are relevant. What matters is not only calculating the right rate. The data must be kept in a form that keeps filings, audits, and corrections traceable.
Pricing display also needs a clear rule. Are prices configured net or gross? What happens when a customer's tax status changes within a contract period? Is the running invoice adjusted, a credit note created, or does the change take effect from the next billing period? There's no universal answer. But the API must model this decision explicitly instead of hiding it implicitly in application code.
A resilient solution therefore separates pricing logic, tax determination, and invoice finalization. A price may change. A finalized invoice must not be silently overwritten. Corrections need documented follow-up documents, such as credit notes or cancellation invoices. That protects the integrity of the general ledger and simplifies audits considerably.
Plan e-invoicing and local requirements early
PDF invoices alone are no durable target picture for the European market. Public-sector buyers frequently demand structured electronic invoices. In Germany, XRechnung and ZUGFeRD are central formats, while other EU markets have their own networks, formats, or transmission rules.
The question is therefore not just: can the system create a PDF? It's: can it output invoice data in structured form, archive it audit-proof, and react to different delivery channels? If these requirements arrive only after go-live, a supposedly small extension often becomes an intervention in the core model of invoice, address, tax, and reference data.
For German accounting processes, the GoBD perspective comes on top: documents, changes, approvals, and export data must remain traceable. For companies reporting internationally, revenue deferral under IFRS 15 is another reason not to treat billing data as a mere payment feed.
Payments: SEPA needs its own exception handling
Card payments dominate many global billing stacks. In European B2B, however, SEPA is often more economically and operationally relevant. SEPA direct debit can be the better payment method for higher invoice amounts, recurring contract relationships, and customers without corporate cards. It brings its own states: mandate, submission, pre-notification, chargeback, deadlines, and re-collection.
A failed debit is not automatically an unpaid invoice. First it must be clear why it failed. Insufficient funds, an invalid mandate, or a return by the payer require different follow-up processes. A generic retry scheme like "try again in three days" is too coarse for that.
The billing API should cleanly separate payment status from receivable status. An invoice can be finalized and open while a payment attempt has failed. Dunning levels, fees, payment targets, and suspension logic must operate on the receivable, not on an undifferentiated payment flag. Product access and the finance process can then be coupled in a controlled way without manual intervention at every exception.
Which API decisions save implementation time
A good interface is not the one with the most endpoints. It's the one that models business states stably and predictably. For engineering teams, four properties matter most:
- Idempotency keys prevent duplicate contracts, usage data, or payments on retries.
- Versioned pricing plans ensure existing customers are billed at their agreed terms.
- Webhooks deliver reliable signals for invoice creation, payment errors, credit notes, and dunning levels.
- A sandbox with realistic tax scenarios enables testing before real documents are created.
With usage-based models, the API should additionally distinguish clearly between raw event, aggregated counter, and billable item. An event like api_request is not yet an invoice line. Only the assignment to customer, metric, period, tariff version, and aggregation rule creates a resilient billing basis.
This becomes decisive when product teams evolve pricing. If a new free threshold is introduced or a tier changed, the change must not retroactively distort running contracts. A billing infrastructure must support time-bound rules: valid from, valid until, bound price version, and documented exception.
Build or buy: the right question for CFO and engineering
In-house development initially feels controllable. A team can extend a Stripe integration, generate invoices, and lodge tax rules in services. The effort, however, doesn't grow linearly. Every new country, payment method, and pricing model multiplies the combinations of logic, exception cases, and testing obligations.
Building can make sense when billing is a genuine core of your own product and a permanent team for tax, payments, ledger logic, and compliance is available. For most growing B2B companies, though, the more pragmatic question is: which parts create differentiation, and which are regulatory infrastructure?
A Europe-specialized platform like Kontorion treats VAT OSS, reverse charge, SEPA, e-invoicing, and accounting-adjacent requirements not as extensions. These components belong to the core process. A team can then direct its energy toward entitlements, product packages, and customer experience instead of reproducing document logic across several services.
Rollout without a parallel billing world
A migration doesn't have to start with the entire customer base. It's often more sensible to put a clearly bounded model into production first: new EU customers, a new usage tariff, or a market with concrete e-invoicing needs. That lets you test the data model, tax rules, webhooks, and payment flows under real conditions.
Before starting, finance and engineering should jointly decide which data leads. The CRM can own account attributes, the product usage events, and the billing platform contracts, invoices, and receivables. Without these ownerships, contradictory customer data and inexplicable deviations between revenue reporting and invoicing arise.
Conclusion
The productive benchmark isn't whether the first invoice gets generated. It's whether a tax status change, a late usage report, a chargeback, and an invoice correction can be processed without manual special solutions. That's exactly where it shows whether a billing API for Europe was merely integrated or actually works as infrastructure.
Anyone treating Europe as a growth market shouldn't plan billing as a downstream admin process. The billing architecture determines how fast products get monetized, how reliably cash comes in, and how well the company holds up under audit.