The Cross-border B2B invoicing API your team doesn't have to maintain.

The case for building looks straightforward at first. EN 16931 is a public standard. Saxon-HE handles Schematron. PDF libraries exist. How hard could it be?

The honest answer is that the spec itself is the small part. The hard parts are the country-specific profiles (Factur-X has five profiles, ZUGFeRD has four, each with different mandatory fields), the PDF/A-3b embedding requirements (the XML must be attached with specific metadata flags and the PDF must be PDF/A-3b conformant for archival), and the validation rule maintenance (Schematron rulesets update with every regulatory revision).

A realistic in-house build is 6 to 12 weeks of focused engineering work for a single format and 0.3 to 0.5 FTE permanently allocated to tracking spec changes. For a team that already has a roadmap, that engineering time has a real opportunity cost. We've seen multiple teams start an in-house build, ship version one, then pivot to an API once they realized the maintenance burden didn't end with the launch.

InvoiceXML exists for the case where compliance is a means to an end, not your product itself. If your customers need to send and receive compliant European invoices, you ship that capability through us in days. If e-invoice compliance is your product, building probably makes sense, but you're not our buyer.

It will change, and it changes often. France's mandate is rolling in across 2026 and 2027. Germany's XRechnung profile updates roughly annually. ZUGFeRD released version 2.3 with new validation rules. Belgium's 2026 mandate is locked in. Poland's KSeF system continues to evolve. Peppol's BIS Billing profiles update on their own cadence.

In an in-house build, every one of these changes is a ticket on your team's backlog. Someone reads the changelog, parses the new Schematron, updates your validation engine, runs regression tests, and ships a deployment. Multiply by every format you support, every year, indefinitely.

InvoiceXML absorbs all of it. Your integration calls the same endpoints with the same payloads. We handle the spec deltas behind the API surface. When France amends its mandate documentation in Q2, your customers don't notice. When XRechnung publishes a new version, your integration keeps working.

This is the single largest reason customers tell us they bought rather than built: not the initial development time, but the certainty that compliance maintenance is no longer their problem.

We treat invoice data as transient. Here's the actual handling:

EU-hosted infrastructure. All processing happens on servers physically located within the European Union. Data does not leave EU jurisdiction during normal API operation.

No invoice content persisted. Invoice payloads are processed in memory and discarded when the API call completes. We do not retain invoice content in databases, logs, observability tools, or backups.

Continuous security monitoring. We work with a dedicated security partner for infrastructure monitoring, vulnerability scanning, and incident response. Our infrastructure is patched and updated on a frequent cadence rather than on a quarterly review.

GDPR compliant. Our processing model, data flows, and customer agreements are aligned with GDPR requirements, including data subject rights, processor obligations, and breach notification.

For procurement and security review, we provide standard documentation including data flow descriptions, sub-processor lists, and our incident response policy. If your security team has a specific questionnaire, we'll complete it.

Replicating this posture in-house, with EU hosting, no-persistence guarantees, ongoing security operations, and audit-ready documentation, is itself a significant fixed cost. For most teams, outsourcing it to a vendor whose entire job is getting this right is both cheaper and safer.

Yes. PDF/A-3b is a strict ISO standard for long-term archival of documents with embedded files, and it's the format required by EU e-invoicing regulations for the hybrid PDF variants of Factur-X and ZUGFeRD.

Most teams underestimate how strict the conformance requirements are. The PDF must use only allowed features (no JavaScript, no external dependencies, embedded fonts, color profile metadata). The XML attachment must be associated with the document using the AFRelationship key. The output must validate against PDF/A-3b conformance checkers like veraPDF.

Every invoice generated through InvoiceXML is PDF/A-3b conformant by construction, with the XML embedded according to the format's metadata requirements. The output passes veraPDF validation and meets the archival requirements of EU regulations and tax authority audits.

If you've ever tried to retrofit PDF/A-3b conformance onto an existing PDF generation pipeline, you already know why this matters. Getting it right requires sustained attention, not a one-time integration.

Existing enterprise alternatives are licensed for SAP-tier customers, with annual contracts in the tens of thousands of euros and feature bundles you'll mostly never use. That's not your competitor. Your competitor is "build it ourselves."

Here's the cost picture for in-house:

Initial development: 6 to 12 weeks of senior engineering time, conservatively 30,000 to 60,000 euros in salary and opportunity cost.

Ongoing maintenance: 0.3 to 0.5 FTE permanently allocated to spec tracking, format updates, and validation engine maintenance. At European senior engineer salaries, 30,000 to 60,000 euros annually, every year.

Infrastructure: Invoice parsing, Schematron validation, and PDF/A-3b generation are CPU- and memory-intensive. Provisioning for peak load means paying for capacity 24/7 even when traffic is low. Realistically several hundred to several thousand euros monthly depending on volume.

Security and compliance: EU hosting, monitoring, audit logs, security review, and documentation. If you don't already have this for other parts of your stack, the marginal cost is significant.

InvoiceXML pricing scales with usage rather than capacity. For most teams, the total cost over three years lands well below the in-house build, with the additional benefit that the maintenance burden never lands on your team.

The European Commission's VIDA proposal, national mandates rolling out through 2028, and the continued evolution of Peppol all point to a future where every B2B transaction in Europe involves a structured e-invoice. New formats, new profiles, and new validation rules will keep arriving.

InvoiceXML's job is to absorb that uncertainty. As new formats become required, we add support. As existing formats update their profiles, we update the engine. Your integration uses the same API surface, calls the same endpoints, sends the same payloads. The compliance surface area grows underneath you without your team noticing.

This is what "future-proof" actually means in this space: not that the spec won't change, but that the changes won't reach your codebase.