InvoiceXML

The backstory

A few months ago, I was working on a side project that needed to generate Factur-X invoices for French B2B customers. Easy, right? A hybrid PDF with embedded XML, follows EN 16931, well-documented standard. How hard could it be?

If you've ever tried implementing this yourself, you already know the answer: surprisingly painful.

The existing options came down to:

1. Pay thousands per year for an enterprise compliance suite that bundles a hundred features I didn't need.

2. Cobble together open-source libraries with stale dependencies and inconsistent validation behavior.

3. Build it from scratch and read 400 pages of UN/CEFACT CII specifications on a weekend.

I picked option 3, mostly out of stubbornness.

The API I wrote for myself

What started as "a quick helper function" turned into a full API. I needed it to:

• Generate valid Factur-X XML from a clean JSON input.

• Validate against the official Schematron rules.

• Embed the XML into a PDF/A-3 properly (not just stapling a file onto a PDF).

• Surface human-readable errors when validation failed, because the default Schematron output is, charitably, hostile to humans.

Once it worked for Factur-X, I realized the same engine could handle ZUGFeRD, XRechnung, UBL, and CII without much extra effort. They all share the same EN 16931 backbone with different national flavors on top.

Turning it into InvoiceXML

At some point I looked at what I had built and thought: other developers are hitting the exact same wall I just spent weeks climbing over. So I cleaned it up, added a real onboarding flow, wrote proper docs, and turned it into a public product.

InvoiceXML is what I wish had existed when I started:

• A single API that generates and validates every major European e-invoice format.

• HTTP 200 with a structured valid: false response for validation failures, because validation results are data, not exceptions.

• An ?errors=friendly flag that returns human-readable error explanations alongside the raw Schematron output, so you can show your users something useful.

• An experimental AI-assisted prefill that takes a regular PDF invoice and tries to extract structured fields. Treat it as a starting point, not a finished result.

• A Zapier integration so non-developers can plug it into their existing automation stack.

Built as API-first, focused on developers and automation workflows. English-only docs, predictable REST endpoints, no enterprise sales calls.

The companion sites for non-developers

While building InvoiceXML, I kept getting messages from people who weren't developers but still needed to validate or generate a single invoice. Founders, accountants, freelancers, German bookkeepers who got their first XRechnung from a public-sector client and had no idea what to do with it.

So I spun up a few small UX-first tools, one per format, each with its own focused landing page and validator:

• getfacturx.com for the French Factur-X format.

• getzugferd.com for the German ZUGFeRD format.

• getubl.com for the international UBL format.

These are not the same product as InvoiceXML. They're standalone consumer-grade tools, in the local language where it matters, designed for someone who just needs to validate one file and move on with their day. The API platform stays focused on developers.

What's next

I'm still adding formats and tightening the validation engine. Peppol flows are next on the roadmap, and I've been experimenting with better AI extraction so people can convert legacy PDFs into compliant XML without manual data entry.

If you're building anything that touches European B2B invoicing, I'd genuinely love your feedback. The mandate dates are coming fast (France in 2026, Germany already rolling out, Belgium in 2026, more behind them), and developer tooling around these formats is still early. There's plenty to fix.

Try it at invoicexml.com, or kick the tires on one of the format-specific tools above.

Happy to answer any questions in the comments.