If your product touches invoices — ERP, DMS, accounting, procurement — you will get asked whether you support e-invoicing. There are two honest paths from there. This page compares them without pretending the build path is worse than it is, and without pretending buying removes every trade-off.
| Work item | Ongoing, not one-time |
|---|---|
| Parse & validate EN 16931 semantic model (UBL and CII syntaxes) | Yes — the standard itself changed to a new version in 2026 |
| XRechnung CIUS rules (BR-DE-*) on top of the base EN 16931 rules | Yes — versioned separately from the base standard |
| ZUGFeRD/Factur-X: embed/extract CII XML inside a PDF/A-3 container correctly | Yes — the mandatory profile version changed again in Jan 2026 |
| PEPPOL BIS 3.0 schematron, kept current with OpenPeppol releases | Yes — hotfix releases land several times a year |
| Any national format you expand into (KSeF, FatturaPA, Facturae, VeriFactu, ...) | Yes — each is its own spec, its own XSD, its own release cadence |
| Keeping a reference validator (or building test coverage against one) so you actually know your output is correct, not just "doesn't crash" | Yes |
None of this is a one-off integration project. It's a standing commitment — someone on your team has to track CEN, OpenPeppol, KoSIT and every national authority's release notes, indefinitely, for as long as you sell the feature.
| Build it yourself | Integrate INVOX | |
|---|---|---|
| Time to first working validation | Weeks to months, depending on how many formats/countries | Minutes — sandbox key, first call |
| Who owns correctness | Your team, against whatever test data you can find | INVOX, re-verified against each standard's own official conformance suite/XSD |
| Who tracks standard changes | Your team, indefinitely | INVOX, indefinitely |
| Multi-format coverage (national formats) | Each one is a separate project | Already covered — one integration |
| Proof/audit trail for a validated document | You'd have to build this separately | Signed, offline-verifiable attestation included |
| What you keep control of | Everything | Your product, your UI, your customer relationship — the compliance engine is delegated, not your business logic |
| Data residency / on-prem | Fully in your control by default | Available as a first-class deployment option, not just SaaS |
Honestly: if e-invoicing compliance is your core product — you're building a dedicated e-invoicing platform, not embedding compliance as a feature of something else — owning the engine end-to-end can be the right strategic bet. The build-vs-buy question is really about whether the validation engine is your differentiator or your cost center. For an ERP, DMS or accounting vendor, it's almost always the latter.
INVOX is not an ERP, not a DMS, and does not send invoices on your behalf by default — it validates, generates, converts, and (where wired to a partner Access Point) supports transmission. Your product, your customer relationships and your UI stay entirely yours. The scaffolding for live PEPPOL four-corner transmission exists; it goes through a partner Access Point rather than INVOX operating as an accredited AP itself — ask us directly about your specific transmission requirement before assuming either way.