# E-invoices: create, validate, parse

Source: https://veriport.io/docs/einvoice (published 2026-10-24)

Send the invoice as JSON (the InvoiceInput schema: seller, buyer, lines, VAT, allowances and charges, payment, references) and `format`: `xrechnung-ubl` (XRechnung 3.0, UBL 2.1), `xrechnung-cii` (XRechnung 3.0, CII D16B), `zugferd` (ZUGFeRD 2.x / Factur-X 1.0, profile EN 16931: a PDF/A-3 with the CII embedded as factur-x.xml) or `peppol-bis` (Peppol BIS Billing 3.0, UBL 2.1, with the Belgian rules). The answer is the file itself, with its validation summary in the `Veriport-Validation` header; `?envelope=json` returns { file (base64), contentType, validation, defaults } instead.

Nothing is ever dropped silently: every field of the input is written, or the request is refused with 422 `einvoice_unsupported` naming the feature and its path (`feature`, `path`, `unsupported[]`). The input is checked against the engine's rules first (422 `einvoice_invalid` with the published rule ids and the JSON paths), the arithmetic is computed (line nets, VAT per breakdown, totals), the file is written, and the file is then run through the XML schema and the official schematron (CEN EN 16931 1.3.16, XRechnung 3.0.2, Peppol BIS 3.0.21); a fatal finding there withholds the file. Every value the engine adds (a VATEX code for reverse charge, the § 19 UStG mention, a 0208 Peppol address, a due date from paymentTermsDays) is listed in `defaults` and counted in the `Veriport-Defaults` header.

v1 writes: EUR; a seller in Germany (XRechnung, ZUGFeRD) or Belgium (Peppol BIS); a buyer in any EU member state; VAT categories S, Z, E, AE and K; invoice 380, credit note 381, corrected invoice 384; SEPA credit transfer or credit transfer; up to 500 lines; document-level allowances and charges. It does not send the invoice (no Peppol access point), does not store it, and gives no tax advice. Up to 4.5 MB (4500000 bytes) per request. Send an `Idempotency-Key` (1–128 characters): a retry replays the same file without a second charge for 24 hours; nothing of the invoice is kept for that, only the time of the first build.

## POST https://veriport.io/api/v1/einvoice/create

Send the invoice as JSON (the InvoiceInput schema: seller, buyer, lines, VAT, allowances and charges, payment, references) and `format`: `xrechnung-ubl` (XRechnung 3.0, UBL 2.1), `xrechnung-cii` (XRechnung 3.0, CII D16B), `zugferd` (ZUGFeRD 2.x / Factur-X 1.0, profile EN 16931: a PDF/A-3 with the CII embedded as factur-x.xml) or `peppol-bis` (Peppol BIS Billing 3.0, UBL 2.1, with the Belgian rules). The answer is the file itself, with its validation summary in the `Veriport-Validation` header; `?envelope=json` returns { file (base64), contentType, validation, defaults } instead.

Nothing is ever dropped silently: every field of the input is written, or the request is refused with 422 `einvoice_unsupported` naming the feature and its path (`feature`, `path`, `unsupported[]`). The input is checked against the engine's rules first (422 `einvoice_invalid` with the published rule ids and the JSON paths), the arithmetic is computed (line nets, VAT per breakdown, totals), the file is written, and the file is then run through the XML schema and the official schematron (CEN EN 16931 1.3.16, XRechnung 3.0.2, Peppol BIS 3.0.21); a fatal finding there withholds the file. Every value the engine adds (a VATEX code for reverse charge, the § 19 UStG mention, a 0208 Peppol address, a due date from paymentTermsDays) is listed in `defaults` and counted in the `Veriport-Defaults` header.

v1 writes: EUR; a seller in Germany (XRechnung, ZUGFeRD) or Belgium (Peppol BIS); a buyer in any EU member state; VAT categories S, Z, E, AE and K; invoice 380, credit note 381, corrected invoice 384; SEPA credit transfer or credit transfer; up to 500 lines; document-level allowances and charges. It does not send the invoice (no Peppol access point), does not store it, and gives no tax advice. Up to 4.5 MB (4500000 bytes) per request. Send an `Idempotency-Key` (1–128 characters): a retry replays the same file without a second charge for 24 hours; nothing of the invoice is kept for that, only the time of the first build.

Tiers: free, credits, plan. Cost: 20 calls per produced file; 0 when refused (400, 413, 422) and on an Idempotency-Key replay.

- `envelope` (query): `json`: { format, filename, contentType, size, file (base64), validation, defaults } instead of the file.
- `Idempotency-Key` (header): Unique per request (`^[A-Za-z0-9_.:-]{1,128}$`). The same key, query and body within 24 hours replays the same file (`Idempotent-Replayed: true`), rebuilt from the request, not stored; another body under the key is 409.

## POST https://veriport.io/api/v1/einvoice/validate

Send an XRechnung, Peppol BIS or EN 16931 XML (UBL 2.1 Invoice or CreditNote, UN/CEFACT CII D16B) or a ZUGFeRD / Factur-X hybrid PDF, as the raw body (Content-Type application/xml or application/pdf) or as the `file` field of multipart/form-data. The XML schema and the official schematron of the document's profile run in-process: CEN EN 16931 1.3.16 always, XRechnung 3.0.2 (2.6.0) for an XRechnung, Peppol BIS Billing 3.0.21 for a Peppol document, with the severities of the KoSIT XRechnung configuration. Rule ids and messages are the published ones (CEN and Peppol in English, the XRechnung BR-DE rules in German); Veriport's own checks of national practice (VP-DE-*, VP-BE-*, VP-EU-*) come as warnings only. The evidence that this check names the same rules as the KoSIT validator, file by file, is at /einvoice-api. Not checked: PDF/A-3 conformance of a hybrid PDF (`checks.pdfa`: not_checked), Factur-X MINIMUM, BASIC WL and EXTENDED profiles (422 einvoice_unsupported). Without a key, 4 checks a day per address. The document is not stored.

Tiers: anonymous, free, credits, plan. Cost: 5 calls per report (valid or not); 0 for an unreadable file or an unsupported profile.

Example 200:

```json
{
  "valid": true,
  "profile": "xrechnung",
  "format": "xrechnung-ubl",
  "syntax": "ubl",
  "container": "xml",
  "attachment": null,
  "errors": [],
  "warnings": [],
  "checks": {
    "schema": {
      "status": "passed",
      "name": "UBL 2.1 (OASIS) and UN/CEFACT CII D16B XML schemas, from the KoSIT XRechnung validator configuration v2026-08-31"
    },
    "ruleSets": [
      {
        "id": "cen-ubl",
        "name": "CEN EN 16931 validation artefacts (UBL)",
        "release": "1.3.16",
        "sha256": "bafada015efbc5248bf5e05ad2191e1d9833ef96e9dd5f4bce420a747342da85",
        "fatal": 0,
        "warnings": 0
      },
      {
        "id": "xrechnung-ubl",
        "name": "XRechnung 3.0.2 schematron (UBL)",
        "release": "2.6.0",
        "sha256": "ca5e07afd04e72cd283d581590ffff3a15f4aac9d2f40c993345d78e67ea22b4",
        "fatal": 0,
        "warnings": 0
      }
    ],
    "pdfa": null,
    "veriport": 0
  },
  "ms": 84
}
```

## POST https://veriport.io/api/v1/einvoice/parse

Send an XML or hybrid PDF e-invoice (raw body or the `file` field of multipart/form-data). The answer is the invoice in the create model (the same JSON POST /einvoice/create accepts), its format and profile, and `notInJson`: everything the document holds that the JSON does not (attachments, line periods, a paid amount, other payment means, totals that differ from the recomputation…), so nothing is dropped silently. A file the API wrote parses with an empty list and writes the same file again. `?as=pdf` returns a readable PDF/A-3 copy instead (`?lang=de|en|fr|nl`). The document is not stored.

Tiers: free, credits, plan. Cost: 5 calls per answer; 0 for an unreadable file.

- `as` (query): `json` (default) or `pdf` (a readable copy).
- `lang` (query): Labels of the readable PDF: de, en, fr, nl (default from the seller’s country).

Example 200:

```json
{
  "invoice": {
    "format": "xrechnung-ubl",
    "type": "invoice",
    "number": "2026-017",
    "issueDate": "2026-10-20",
    "dueDate": "2026-11-03",
    "currency": "EUR",
    "buyerReference": "EK-2026-0345",
    "deliveryDate": "2026-10-15",
    "seller": {
      "name": "Lena Hartmann — Webdesign",
      "address": {
        "street": "Lindenstraße 14",
        "city": "Berlin",
        "postalCode": "10969",
        "countryCode": "DE"
      },
      "vatId": "DE136695976",
      "electronicAddress": {
        "scheme": "EM",
        "id": "rechnung@hartmann-webdesign.example"
      },
      "contact": {
        "name": "Lena Hartmann",
        "phone": "+49 30 1234567",
        "email": "rechnung@hartmann-webdesign.example"
      },
      "vatScheme": "standard"
    },
    "buyer": {
      "name": "Mustermann Maschinenbau GmbH",
      "address": {
        "street": "Industrieweg 7",
        "city": "Stuttgart",
        "postalCode": "70565",
        "countryCode": "DE"
      },
      "electronicAddress": {
        "scheme": "EM",
        "id": "buchhaltung@mustermann.example"
      },
      "contact": {
        "email": "buchhaltung@mustermann.example"
      }
    },
    "payment": {
      "means": "sepa_credit_transfer",
      "iban": "DE02120300000000202051"
    },
    "lines": [
      {
        "id": "1",
        "name": "Relaunch Website, Konzeption und Umsetzung",
        "quantity": 24,
        "unitCode": "HUR",
        "unitPrice": 95,
        "vat": {
          "category": "S",
          "rate": 19
        }
      },
      {
        "id": "2",
        "name": "Lizenz Bildmaterial",
        "quantity": 1,
        "unitCode": "C62",
        "unitPrice": 128.4,
        "vat": {
          "category": "S",
          "rate": 19
        }
      }
    ]
  },
  "format": "xrechnung-ubl",
  "formatLabel": "XRechnung 3.0 (UBL 2.1)",
  "profile": "xrechnung",
  "syntax": "ubl",
  "container": "xml",
  "attachment": null,
  "notInJson": []
}
```

## Read next

- [Product page: the e-invoice API](https://veriport.io/einvoice-api)
- [Free XRechnung check (German)](https://veriport.io/tools/xrechnung-pruefen)
- [Free Factur-X check (French)](https://veriport.io/tools/valider-factur-x)
- [Free Peppol BIS validator](https://veriport.io/tools/peppol-validator)
- [E-invoice viewer](https://veriport.io/tools/einvoice-viewer)