Invoice

Pilot customers wanted · White-label / OEM available

The problem

An e-invoice can look correct and still be rejected.

Businesses have to process e-invoices across different formats and rule sets. Small deviations in required fields, profiles or validation rules can cause an invoice to fail technically — often only after it has already reached the recipient.

An invoice looks correct and is still rejected.

A missing required field, the wrong profile or a broken business rule can be enough.

Different recipients require different formats.

XRechnung, ZUGFeRD, Factur-X, Peppol and ebInterface have different technical requirements.

Rules change.

Validation against an old rule set can still run technically while being unsuitable for the current case.

“Invalid” does not explain the problem.

Without traceable evidence, investigation only starts after rejection.

Multiple systems need the same invoice logic.

ERP, accounting, custom software and integrations should not each rebuild their own validation rules.

The solution

Invoice combines detection, validation, generation and evidence in one e-invoicing platform.

An invoice is ingested, converted into a common internal representation and validated against the intended technical rule set.

Supported output formats can be generated from the same foundation. The rules and validation artefacts used for a specific invoice remain traceable.

Your ERP or accounting system remains your leading business system. Invoice provides the specialist e-invoicing processing layer.

What Invoice handles

Process, validate and evidence e-invoices.

Format detection and intake

Identify and process supported XML and hybrid PDF/XML invoices.

Technical validation

Check structure, profile and business rules. A validation step that could not run is never reported as a pass.

Official validation artifacts

Use official technical rule sets where they are part of the intended validation process.

Invoice generation

Create released output formats from the shared invoice representation.

Rule-set traceability

Record which rule set and validation artifacts were used for a validation.

Integration

Connect through an API and deliver events through signed webhooks.

Tenant separation

Process multiple organizations separately within one operating environment.

Evidence and retention

Support retention, legal hold and auditor export in the intended operating mode.

Formats

Germany

XRechnung 3.0 — UBL and CII

EN 16931 — UBL 2.1 and UN/CEFACT CII

ZUGFeRD 2.5.2 and Factur-X — MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED (PDF/A-3 with embedded CII)

1,902 / 1,902 rule instances closed terminally

Austria

Peppol BIS Billing 3.0.21 — Invoice and CreditNote (UBL)

ebInterface 6.1 and 6.1 Bund

1,042 / 1,042 rule instances closed terminally

Rule packages are digest-bound and versioned. The Peppol pack is pinned at 3.0.21 — the version fixed in the repository, not a claim about the latest published release.

Evidence

Verified with evidence. Conformance checks, reference-validator comparison and external acceptance instead of product promises alone.

Status: 1 October 2026. These figures describe reproducible technical evidence under the stated rule sets and test conditions; they are not legal or tax advice.

86 / 86Official XRechnung test cases — Official positive cases from the KoSIT test suite passed and were confirmed by two rechecks. This is not a claim of full corpus parity.

1,969 / 1,969KoSIT validator comparison — Validation judgments matched the official KoSIT Validator 1.6.0 under the XRechnung 3.0.x configuration used. These are identical judgments, not 1,969 invoices that all passed.

2,618 / 2,618Test documents across 7 formats — Processed with the expected validation outcome: valid documents accepted and invalid documents rejected according to the expected rules.

46 / 46ZUGFeRD / Factur-X — Hybrid invoices generated by Invoice passed PDF/A-3B validation with veraPDF.

AcceptedAustrian test portal — CIUS-AT and ebInterface 6.1 were accepted by the e-Rechnung.gv.at test portal. The portal evidence is documented.

24,333Automated quality assurance — Automated tests passed in the documented full run. The figure describes test volume, not a claim of complete absence of defects.

Rule set.Validation.Result.Evidence.

Pilot customers & white-label

I am looking for companies that want to use Invoice in practice or offer it as part of their own solution.

For pilot customers, the focus is a clearly scoped real-world use case: Invoice is integrated into a concrete invoicing process, I support the technical integration directly, and practical feedback feeds into continued product development.

For software vendors, ERP and vertical solutions or integrators, Invoice can also serve as a technical foundation under their own brand. I discuss white-label, OEM and dedicated deployment individually.

Pilot project

For companies that want to validate, process or integrate e-invoices with Invoice in a real workflow.

White-label / OEM

For vendors that want to integrate e-invoicing capabilities into their own product or offer them under their own brand.

Dedicated

For scenarios that require separate deployment, clearly defined operational boundaries or individual integration.

Discuss a pilot or white-label setup →

Product boundaries

Invoice is not a Peppol access point and does not itself transport invoices across the Peppol network.

Invoice does not replace accounting, ERP or document management.

Invoice validates technical conformance and does not replace legal or tax advice.

Next step

Does Invoice fit your invoicing process?

Briefly describe the e-invoice formats, systems or integrations involved. For a pilot, white-label or OEM setup, we can then define the right scope.

Discuss Invoice →