European E-Invoicing API Buyer's Guide
If you build or run software that has to create, validate, send, receive or report e-invoices anywhere in Europe, you will eventually have to pick a vendor — or decide to build the compliance layer yourself. Most vendor content on this topic (INVOX's included, historically) leads with feature checklists that all look identical. This guide instead lists the specific, checkable questions a technical buyer should ask, and is honest about where INVOX itself is strong and where it currently has real gaps. A buyer's guide that only ever concludes "and the vendor writing it wins" isn't worth reading — so this one doesn't.
Every INVOX-specific claim below was checked against the actual codebase on 2026-09-02, not restated from older marketing copy. Where we say "we don't have this yet," that's current as of this date and may have changed — ask us directly, or check git log, before treating either the strength or the gap as permanent.
Disclaimer: this is a technical evaluation checklist, not legal or tax advice. E-invoicing mandates change; confirm current dates and thresholds with your tax advisor or the relevant national authority before relying on any date mentioned here.
1. EU Coverage
Ask: Which countries does the vendor actually support today, with a named, tested integration — not "Europe" as a slogan? Get the literal list. Ask what "support" means per country: validation only, or generation and transmission too.
INVOX ships 29 European country rule-packs (all EU/EEA member states plus Switzerland and the UK) plus a generic EU/EN16931 fallback pack, and three further non-European packs (Australia, New Zealand, Singapore) that share the same Peppol-based architecture. See our Coverage Matrix for the country-by-country breakdown — including which countries only have validation today versus full clearance-channel transmission.
2. EN16931 Conformance
Ask: Which validation engine does the vendor actually run — their own reimplementation of the Schematron rules, or the official reference engine (KoSIT for XRechnung/German-derived rulesets)? Reimplementations drift from the standard as rule versions update; ask how fast the vendor ships rule updates after a KoSIT/CEN release, and ask for evidence (changelog, version pin) rather than a verbal claim.
INVOX runs invoices through the actual KoSIT reference validator (not a reimplementation), currently pinned to the KoSIT XRechnung ruleset and Peppol BIS Billing 3.0.21 (mandatory since 2026-08-17). Ask any vendor for their current pinned version and how they track KoSIT/Peppol releases.
3. National Rules Beyond EN16931
Ask: EN16931 is a floor, not a ceiling — most countries layer national business rules on top (German Leitweg-ID routing, French SIREN/SIRET checks, Polish NIP/KSeF schema fields, Italian Codice Fiscale, and so on). Ask the vendor to show you an actual national-rule violation message, not just "we support country X."
INVOX implements per-country rule packs (invox/country_packs/) that run alongside the EN16931 core layer and fail closed: if a country pack errors internally, the pipeline marks the national layer "inconclusive," it never silently reports a false "valid." Ask any vendor what happens when their national-rules layer throws an exception mid-validation — a startling number of implementations simply drop it silently.
4. Validation Depth
Ask: Does validation cover only the XML schema, or also PDF/A conformance (for hybrid formats like ZUGFeRD/Factur-X), digital signatures (XAdES for Spain's Facturae), and business-rule arithmetic (totals, tax breakdowns)? Ask for a sample error response and judge whether it's a raw rule code (e.g. BR-DE-1) or something a non-specialist could act on.
INVOX validates PDF/A via veraPDF, XAdES signatures for Facturae, and returns plain-language error messages with the BT (Business Term) number attached, in multiple languages. Ask competing vendors to show you an actual failed response payload before you sign.
5. Generation, Not Just Validation
Ask: Can the API generate a compliant invoice from your data (CSV, JSON, your own object model), or does it only check documents you've already built elsewhere? If it generates, ask whether the generator self-validates its own output before returning it — a generator that doesn't check its own work is a liability, not a feature.
INVOX generates KoSIT-valid XRechnung 3.0 (UBL and CII), ZUGFeRD/Factur-X PDFs, Spanish Facturae, Italian FatturaPA, and Polish KSeF FA(3) XML, and self-validates generated output against the same certified engines used for inbound validation. Credit notes are supported for UBL; CII credit-note generation is not yet implemented — ask any vendor the same question for their own format matrix, not just the happy path.
6. Peppol Support
Ask: Is Peppol support "we can produce a Peppol-shaped UBL file" or "we are/partner with a certified Access Point that actually delivers to the network"? Ask specifically whether delivery goes out under the vendor's own AP certificate, a partner AP's certificate, or whether the API only returns the payload for you to send yourself.
INVOX's default sender returns the exact SBDH-wrapped payload a certified Access Point would transmit, with no live network send — useful immediately, with no Peppol certificate required on your side, but it is not itself a live delivery. Live delivery is available today through a certified partner Access Point (Storecove) behind the same interface; INVOX does not yet run its own certified AP. Ask any vendor claiming "Peppol support" which of these three they mean.
7. E-Reporting (Real-Time Transaction Reporting)
Ask: Beyond invoice exchange, does the vendor support the real-time transaction-reporting regimes several countries now require independently of (or alongside) invoice delivery — Spain's VeriFactu, Hungary's NAV Online Számla, Greece's myDATA? These are separate integrations from "sending an invoice" and are easy for a vendor to gloss over.
INVOX has working, tested senders for Spain's VeriFactu (RegFactuSistemaFacturacion), Hungary's NAV Online Számla (schema v3.0, the only version NAV still accepts), and Greece's myDATA. Ask whether a vendor's "reporting" claim means these specific national APIs or just "we can email you a report."
8. ViDA Readiness
Ask: ViDA (VAT in the Digital Age) mandates structured e-invoicing and digital reporting for cross-border B2B transactions from 2030-07-01. Ask the vendor what concretely they've built toward it today versus what's still a roadmap slide — a generic EN16931/UBL/CII/Peppol foundation is a legitimate, verifiable head start; a slide with the ViDA logo is not.
INVOX's architecture (EN16931 core validator, generic UBL/CII generation, Peppol transport, and a growing set of national real-time-reporting integrations) is the same foundation ViDA is expected to standardize on — but no vendor, INVOX included, can honestly claim a finished "ViDA-compliant" product today, because the implementing regulations are not final. Treat any vendor claiming full ViDA compliance in 2026 with real skepticism.
9. Invoice Lifecycle Coverage
Ask: Does the vendor handle the full document lifecycle — invoice, credit note, corrections/status updates — or only the initial invoice? Ask specifically about credit notes, since many implementations bolt this on late (it requires a genuinely different document type in UBL, not just a different type code).
INVOX supports credit-note generation for UBL today (a distinct document type, not a patched invoice); CII credit notes are an acknowledged gap, not yet built. Ask any vendor to draw you their actual lifecycle-state diagram, not describe it verbally.
10. Proof and Auditability
Ask: If a tax authority or auditor challenges an invoice years from now, what evidence can the vendor actually produce, and can it be verified without trusting the vendor's own systems still being online? A validation log stored in the vendor's database proves little to a third party.
INVOX issues Ed25519-signed, content-free proof records (validation attestations and, on the receiving side, reception proofs) that a recipient can verify offline with a standalone verifier tool, independent of INVOX's uptime. Ask any vendor whether their "proof" is independently, offline verifiable, or just a database row you have to trust them to keep.
11. Incoming Invoice Handling
Ask: Many vendors are outbound-only (help you send) with no symmetric answer for invoices you receive. Ask explicitly how inbound documents are validated, what proof you get that you validated what you actually received, and whether receiving costs extra or is a second product entirely.
INVOX validates inbound Peppol/UBL/CII payloads on the same certified engine used outbound and issues a signed reception proof. Ask any vendor to demonstrate the inbound path, not just assume it mirrors the outbound one.
12. Outgoing Invoice Handling
Ask: For outgoing invoices, ask which national clearance/registration channels are live (see criterion 1 and the Coverage Matrix) versus which are "we could build that." A live, tested sender against a real government API sandbox is a materially different claim from a roadmap item.
INVOX has tested senders live against France's Chorus Pro (B2G), Italy's SDI, Poland's KSeF, Spain's FACe (B2G) and VeriFactu, Hungary's NAV, Greece's myDATA, and Romania's e-Factura. Two integrations — Portugal's ATCUD/SAF-T and Croatia's Fiskalizacija 2.0 — have code written but their exact endpoint and authentication mechanism could not be confirmed with confidence from public sources as of this writing; treat those two as beta, not production, until independently reconfirmed. Ask any vendor which of their "supported" countries have actually been exercised against a live government sandbox versus written from a spec document alone.
13. Multi-Tenant Architecture
Ask: If you're building a platform that serves your own customers (an ERP, a marketplace, an accounting SaaS), ask whether the API is genuinely multi-tenant — scoped sub-keys per customer, per-key usage isolation, IP allowlisting per sub-key — or whether you'd be sharing one account and building tenant isolation yourself on top.
INVOX supports tenant sub-keys with per-key usage tracking and per-API-key IP allowlisting. It does not yet have a full role-based access control (RBAC) system with custom roles/permissions for end users within a tenant — today, access control is scoped at the API-key level, not a granular per-user permission model. If your product needs "this human can view invoices but not send them," ask any vendor (INVOX included) to show you that exact control, not just tenant separation.
14. Sandbox Quality
Ask: Is the sandbox a real validation/generation path against the same engines as production (with a lower rate limit), or a mocked response that always returns "valid"? A sandbox that can't actually fail teaches you nothing about your integration.
INVOX's sandbox mode runs the real validation engines and returns real verdicts — it is rate-limited (a shared daily volume cap), not faked. Ask any vendor to show you a sandbox call that returns a genuine validation failure, not just a success response.
15. SDKs
Ask: Are the SDKs actually published to a package registry (pip install x, npm install x, a Maven Central coordinate) so pip install works today, or are they source-available on GitHub only, requiring you to build from source? This is a real, easily checkable difference in day-one integration effort.
INVOX maintains SDKs for Python, TypeScript, PHP, Java, Ruby and .NET, but as of this writing none are published to a public package registry — they are source-available, not yet pip/npm/Maven-installable. This is a genuine current gap versus the easiest competing developer experience, and it's on our list to close. Ask any vendor to run pip install <their-package> in front of you before you believe otherwise.
16. Webhooks
Ask: For asynchronous events (validation complete, delivery acknowledged, clearance confirmed), ask about retry behavior, replay/re-send tooling for a dropped webhook, protection against the vendor's own webhook sender being used as an SSRF vector, and whether you can test-fire a webhook without a real event.
INVOX's webhook system includes retry with a circuit breaker, a delivery log, test-send and delivery-replay endpoints, and SSRF protection on outbound webhook calls. Ask any vendor specifically about the replay case — "the webhook fired once and my server was down" is the scenario that actually matters in production.
17. Security
Ask: How is XML parsed — is the parser hardened against XXE (XML External Entity) attacks and "billion laughs"-style entity expansion bombs, given that invoices are XML from external senders by definition? Ask about 2FA/TOTP for account access and how API keys and secrets are stored.
INVOX parses XML through a hardened safe-XML layer specifically built against XXE and entity-expansion attacks, and supports TOTP-based two-factor authentication. Ask any vendor to describe their XML parser's entity-handling configuration specifically — a generic "we use standard libraries" answer is not sufficient given how many XML parser defaults are unsafe out of the box.
18. EU Data Residency
Ask: Where does the vendor actually host — get the specific country/provider, not "cloud" or "EU-based" as an unverified slogan. Ask what happens to the invoice content itself: is it stored, and for how long, or discarded after processing?
INVOX's infrastructure runs on IONOS SE, hosted in the EU (Germany). Document content is processed and discarded (zero-retention — only a hash is kept, not invoice content) rather than stored. A small number of downstream processors (e.g., for AI-assisted error explanations) may be outside the EU under Standard Contractual Clauses; check the current DPA for the specific list before signing if this matters to your compliance posture.
19. Pricing
Ask: Get the actual per-unit cost at your expected volume, not the headline entry price — many vendors' entry tier looks cheap and their volume tier does not. Ask what counts as a billable unit (a validation? a generation? a transmission? all three separately?) and whether sandbox usage is free.
Ask INVOX (or any vendor) for a volume-based quote against your real monthly invoice count before comparing headline prices — headline "from €X/month" figures are not comparable across vendors without knowing what a credit buys.
20. Integration Effort
Ask: How long does a real integration actually take — ask for the OpenAPI specification itself (not a sales deck), and try generating a client from it before you commit. Ask whether the vendor's own SDKs are generated from the same spec you'd get, or hand-maintained separately (which tends to drift).
Ask any vendor, INVOX included, for their OpenAPI spec on the first call. If they won't hand it over before a contract is signed, that alone tells you something about how the integration will go.
The honest summary
INVOX's genuine strengths, verified in this pass: the KoSIT reference validator (not a reimplementation), signed offline-verifiable proof on both the outbound and inbound side, zero-retention EU hosting, a real (not mocked) sandbox, hardened XML parsing, and tested live senders against seven national clearance/reporting systems (France B2G, Italy, Poland, Spain, Hungary, Greece, Romania).
INVOX's genuine current gaps, also verified in this pass: no published package-registry SDKs (source-available only), no full per-user RBAC within a tenant, no SAML SSO (OIDC is implemented, SAML is not), no self-certified Peppol Access Point (partner-delivered via Storecove today), CII credit notes not yet implemented, and two national senders (Portugal, Croatia) that are code-complete but unconfirmed against a live government endpoint.
Ask every vendor on your shortlist — INVOX included — the same twenty questions above, and insist on the OpenAPI spec and a sandbox call before you sign anything.