What's the difference between XRechnung and ZUGFeRD?

XRechnung is a pure XML format required for public sector invoicing in Germany. ZUGFeRD combines a PDF with embedded XML data, making it human-readable and machine-processable. For government clients, you need XRechnung. For B2B transactions, ZUGFeRD is often accepted and sometimes preferred because recipients can view it as a PDF.

Do I need a separate API for each country's e-invoice requirements?

Currently, yes. Most European countries have their own e-invoicing standards, even though they're based on the same EU directive. An x-invoice api generates German XRechnung files, but you'd need different solutions for Italy's FatturaPA, French Chorus Pro, or Spanish Facturae formats. Some providers offer multi-country APIs, but these are relatively new.

How do I handle invoice corrections or cancellations through the API?

XRechnung supports credit notes and corrective invoices through specific document type codes. Your API request should indicate the invoice type (standard invoice, credit note, corrective invoice) and reference the original invoice number if applicable. The API generates the appropriate XML structure based on this information.

Can the API validate invoices before submission to avoid rejections?

Yes, that's a core feature of quality x-invoice apis. Pre-submission validation checks all mandatory fields, data formats, and structural requirements against the XRechnung specification. This catches most errors before you submit to official portals, which saves time and prevents payment delays.

What authentication methods do these APIs typically use?

Most modern x-invoice apis use API key authentication or OAuth 2.0 tokens. You include your authentication token in request headers. Some enterprise solutions support client certificates for enhanced security. The specific method depends on the provider, but API keys are most common for simpler integrations.

How long does it take to integrate an x-invoice api?

For a basic integration where you're adding XRechnung generation to an existing invoicing system, expect one to three weeks. This includes development time, testing with sample data, validation against official checkers, and deployment. More complex integrations with custom workflows or multiple system connections can take longer.

Are there free or open-source x-invoice api options?

There are open-source libraries for generating XRechnung XML, but these typically aren't full APIs—they're code libraries you integrate directly. For hosted API services with validation, transmission, and support, you'll generally need a paid solution. Some providers offer free tiers for low volumes, which work well for testing or small-scale use.

What happens if the API generates an invalid invoice?

Good APIs shouldn't generate invalid invoices because of their validation layers, but if a receiving portal rejects an invoice despite API validation, the provider should help troubleshoot. Check your API provider's SLA and support policies. Most will investigate discrepancies between their validation and portal requirements and update their systems accordingly.

x-invoice api Guide for Developers and SaaS Integrators

What Exactly Is an X-Invoice API

Diagram showing how an x-invoice API transforms invoice data into XRechnung XML

An x-invoice api is a software interface that allows your systems to programmatically generate XRechnung documents. If you're billing German government agencies or public institutions, this format is mandatory — XRechnung has been legally required since 2020 for invoices to German public sector clients.

In practice, the API accepts invoice data — customer details, line items, tax rates, payment terms — and returns a validated XRechnung XML file. Most providers expose a REST interface: you send a POST with JSON (or XML) and receive either the compliant XML or a descriptive error response. The underlying XML conforms to UBL or UN/CEFACT CII schemas, both with strict validation rules.

"The first integration I did saved ~15 hours per week of manual XML work after about two weeks of implementation."

Why Standard Invoicing APIs Don't Cut It

Comparison graphic: standard invoicing APIs vs XRechnung-specialized APIs

General-purpose invoicing APIs (e.g., Stripe, Bill.com) are flexible, but they prioritize ease-of-use over regulatory specificity. XRechnung requires precise XML elements such as Leitweg-ID, specific tax categorization codes, and legally structured payment terms. A PDF — even with correct visible data — won't satisfy public-sector portals.

Lesson learned: retrofitting a general API often takes far longer than adopting a purpose-built x-invoice api. The validation layer alone makes specialized APIs worthwhile — they catch issues before submission to government portals.

Core Features Your X-Invoice API Should Have

Checklist of essential x-invoice API features

Must-haves:

Generation of valid XRechnung XML in UBL or CII formats (current schemas).
Comprehensive validation with field-level error messages (tax IDs, invoice numbers, required elements).
Integration tooling: SDKs, REST/JSON endpoints, and sample payloads for common languages.
Transmission options: Peppol, ZRE portals, direct portal uploads, and tracking of delivery/statuses.
Transformation utilities to convert other invoice structures or PDFs into XRechnung XML.

The best APIs return detailed error objects like invoice.seller.taxID: Invalid format, expected DE123456789, which dramatically reduces debugging time.

Implementing an X-Invoice API in Your Stack

Sequence diagram: backend triggers → POST to x-invoice API → XML returned

Typical workflow:

Collect invoice data from your DB, ERP, or order system.
Structure the payload according to the API spec (JSON with nested objects for parties, line items, taxes).
POST to the API; handle 200/201 success, 400-level validation errors, and 500-level server issues.
Store returned XML or reference URL; track delivery status if transmission is handled by the API.

For production, implement robust error handling, retries, logging for audit trails, and a queue to avoid blocking operational workflows during transient failures.

Validation and Compliance Checking

Table illustrating common XRechnung validation rules

Why validation matters: XRechnung contains dozens of mandatory and conditional fields across a long specification. Manual validation is error-prone and slow. An API that verifies invoice number uniqueness, tax calculations, tax category codes, date formats, and required identifiers (like Leitweg-ID) saves time.

Field-level error responses are critical. Replace generic errors with actionable messages so developers can fix issues quickly. Well-tested providers surface edge cases (e.g., extra spaces in tax IDs) that cause portal rejections.

Real-World Integration Patterns

Architecture diagram: ERP → Middleware → X-Invoice API → Peppol/ZRE

Common patterns:

Direct ERP integration: ERP generates invoice and calls the API; XML stored with the invoice record.
Batch processing: Collect invoices and send them in scheduled batches to optimize rate limits.
Middleware/microservice: A facade that handles transformation, retries, caching, and provider swap-outs without touching upstream systems.
Multi-tenant SaaS: Use account-specific tokens and isolated storage to prevent data leakage between customers.

A microservice approach makes it easy to change providers and centralizes XRechnung-specific logic.

Choosing the Right API Provider

Checklist of provider evaluation criteria

Evaluate providers on:

Compliance: Test sample outputs with official validators.
Documentation: Clear endpoints, examples, and error references speed integration.
Support & reliability: SLAs, status pages, and responsive support are essential.
Pricing: Compare per-invoice vs subscription tiers and watch for hidden fees.
Integration tooling: SDKs and plugins reduce development time.

Some platforms also offer web interfaces for manual invoice creation in addition to APIs — useful for mixed workflows.

Future-Proofing Your Implementation

Timeline showing regulatory updates and version migrations

Regulatory change is constant. Germany is expanding mandatory e-invoicing to B2B from 2025, and the EU continues harmonization efforts. Choose providers that actively maintain schemas and announce updates with migration windows.

Practical tips:

Keep client code modular and versioned → switch API versions with minimal disruption.
Retain original invoice data and generated XRechnung XML for audits.
Periodically validate generated invoices against official validators even if the API indicates success.
Plan for scaling and rate limits; have an upgrade or provider-switch path ready.