4. Expanded Feature Catalog (What E-Invoice Buyers Ask For)
These are the features developers and finance teams ask for when they have to issue e-invoices from their own code. They're each classified with the same honesty as the candidates in doc 03. Being in demand doesn't mean you should build it.
Legend: TS = Table stakes, D = Differentiator, X = Distraction, L = Liability. Priority: P0 = v1, P1 = next (months 3–9), P2 = later (months 10–24), — = don't build.
4.1 Formats and countries
| Format / country | Why it matters | Category | Priority | Notes |
|---|---|---|---|---|
| ZUGFeRD 2.x / Factur-X, EN 16931 profile (Germany) | The hybrid PDF most German SMEs and SaaS will send by email | D | P0 | Don't offer the MINIMUM or BASIC-WL profiles for German B2B. The BMF FAQ excludes them. |
| XRechnung 3.x, CII syntax | Public sector and many German receivers | D | P0 | Same data model as ZUGFeRD, so it's cheap to add. |
| XRechnung, UBL syntax | Some receivers and Peppol flows | D | P1 | |
| ZUGFeRD EXTENDED profile | Complex invoices (discounts, multiple deliveries) | D | P2 | Only when a paying customer needs it. |
| Factur-X for France | Official French format since the 1 Sept 2026 go-live | D | P2 | Customers route it through their certified platform (PA). You produce the file only. |
| Peppol BIS Billing 3.0 via a partner access point (Belgium, others) | Mandatory network in Belgium since 1 Jan 2026 | D via partner | P2 | Resell or integrate e-invoice.be / Recommand. Never become an access point yourself. |
| Poland KSeF, Italy SDI, Spain | Clearance systems | X for you | — | Transmission-heavy, and local specialists exist (Invoicetronic, A-Cube, Openapi for Italy). |
4.2 Generation and validation
| Feature | Demand signal | Category | Priority | Notes |
|---|---|---|---|---|
| One JSON schema for all formats | High. Developers hate learning EN 16931 business terms (BT-xx). | D | P0 | Map friendly field names to BT codes, and publish the mapping. |
| Validation on every call, with the rule version recorded | High | D | P0 | The core promise. |
| Readable errors in German and English, with a fix hint | High | D | P0 | Turns "BR-DE-17" into an action. |
| Validate-only endpoint (check a file someone else made) | High among receivers | D | P0 | It also powers the free public validator. |
| Branded PDF layer (logo, colours, language, 3 templates) | Medium-high | TS | P0 | HTML templates only. No designer. |
| Credit notes, corrections, partial invoices | High in real billing | TS | P1 | Needed for retention. Real billing has refunds. |
| Reverse-charge and intra-EU wording helpers | Medium | D / L | P1 | Suggest the standard wording, and label it "check with your tax adviser". |
| Small-business (Kleinunternehmer) and tax-exempt cases | Medium | TS | P1 | A common German edge case. |
| Test mode / sandbox with watermark | High | TS | P0 | The free plan. |
| Batch endpoint (100s of invoices at month-end) | Medium-high for usage-billed SaaS | D | P1 | Month-end spikes are when support tickets happen. |
4.3 The receiving side (the second recurring job)
| Feature | Category | Priority | Notes |
|---|---|---|---|
| Parse incoming XRechnung / ZUGFeRD / UBL to clean JSON | D | P1 (month 3–4) | All German businesses must receive e-invoices since 1 Jan 2025. Platforms and expense tools need this. |
| Human-readable rendering of a received XRechnung (XML → PDF view) | D | P1 | XRechnung has no visual layer, and finance teams can't read XML. |
| Email inbox that receives e-invoices and posts JSON to a webhook | D | P2 | High stickiness. Keep it strictly receive-and-forward. |
| Supplier-invoice data extraction from plain PDFs (OCR/AI) | X | — | A different, crowded market with accuracy risk. |
4.4 Integrations and distribution
| Feature | Category | Priority | Notes |
|---|---|---|---|
Stripe connector (webhook on invoice.finalized → e-invoice → attach or email) | D | P1 | Stripe doesn't generate e-invoices itself. It's the densest buyer pool. |
| Stripe App Marketplace listing | D | P1 (month 9) | Billit is free there until 1 Jan 2027. Compete on developer control and inbound parsing, not on price. |
| SDKs: Node, Python, PHP, Java, .NET | TS | P0 (Node, PHP, Python) → P1 | German agencies are PHP-heavy (Laravel, Symfony, Shopware). |
| Laravel / Shopware / WooCommerce plugins | D | P2 | Agency channel. Only after the API retains. |
| Chargebee, Paddle, Lemon Squeezy connectors | TS | P2 | Merchants of record may handle invoices themselves. Check before building. |
| Zapier / Make / n8n | X → TS | P2 | A channel, not the core. It brings churn-prone buyers. |
| MCP server / AI-agent tool | D (cheap) | P2 | Cheap to add. It follows how developers now find tools. |
4.5 Trust, compliance and operations
| Feature | Category | Priority | Notes |
|---|---|---|---|
| EU hosting, DPA, subprocessor list, Impressum | TS | P0 | Required before German buyers send real data. |
| Data deletion by default (inputs deleted after N days unless archive is on) | TS | P0 | Reduces liability. |
| Archive with integrity hash (WORM-style storage) | D / L | P2 | German retention rules (GoBD) apply. Get the adviser's sign-off before marketing it as "GoBD-compliant". |
| Status page, uptime SLA on Scale | TS | P1 | Month-end reliability matters. |
| Changelog of rule and format versions, with email alerts | D | P0 | Turns rule updates into a reason to stay. |
| SOC 2 / ISO 27001 | X | — | Enterprise-only. Not needed for this buyer at this size. |
| Free VAT-ID check (VIES with retries and cached proof) | TS | P0 | A free extra. Never the headline. |
4.6 Rejected, even though people ask
| Feature | Category | Why not |
|---|---|---|
| Full invoicing app (customers, products, dunning, payments) | X / L | That's lexoffice, sevdesk and Billit. It changes you from an API into an app with support load. |
| Tax calculation engine (rates, OSS) | L | Stripe Tax, Avalara and Taxdoo own it. Getting it wrong has real cost. |
| Address validation | L | Licensing and legal risk (doc 03). |
| Screenshot and URL-to-PDF | X | The project-based market. |
4.7 Net effect
Of about 35 requested features, about 14 are real differentiators for an e-invoice API, and about 10 belong in v1. The rest is table stakes to add slowly, other companies' products to integrate with, or risk.