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 and ZUGFeRD share five conformance profiles, each with different mandatory fields, plus an XRechnung reference profile; UBL adds six CIUS variants on top), 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 and Factur-X keep publishing new releases with revised validation rules. Belgium's 2026 mandate is live. Poland's KSeF system continues to evolve. Peppol ships rule updates twice a year, each with its own mandatory date.

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, and you don't have to take that on faith. The policy is published: rule updates land on the authority's legal effective date; new specification versions become opt-in via options.version during the official transition window; the default flips on the regulator's effective date, announced in advance; the outgoing version stays pinnable until its sunset. The exact artifact versions running right now are listed in the docs, down to the Schematron release number.

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, backed by a written policy instead of a promise.

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.

Ask the response. Every validation result names the profile whose rules were applied (data.profile) and echoes the specification identifier your document declared (data.customizationId), so there is never ambiguity about what was checked.

At the platform level, the rule sets are the authorities' own published artifacts, vendored unmodified: KoSIT's XRechnung Schematron, OpenPeppol's BIS Billing and PINT releases, the CEN EN 16931 validation artifacts, the Dutch Peppol Authority's SI-UBL, and the official Factur-X package with its per-profile schemas. The current version of each is listed on the versioning page and updated on legal effective dates.

And we prove it the way regulators do: our regression suite runs the official test corpora, KoSIT's XRechnung test suite, the FeRD profile samples, and OpenPeppol's examples, against every change before it ships.

Because those are two different rulebooks. EN 16931 is the European core; Peppol BIS 3.0 layers roughly a hundred extra rules on top: electronic addresses for both parties, endpoint identifier schemes, and national rules for Norway, Denmark, Italy and others. A document can satisfy all 200+ core rules and still bounce at the access point.

InvoiceXML runs both layers whenever a document declares a Peppol profile, and every finding tells you which layer it came from. If you create through us, the Peppol checks run before delivery, with errors that say exactly what to add, or you can switch to the plain en16931 profile if the invoice never touches the network. The "passes locally, dies at the access point" failure mode is specifically what this design eliminates.