For invoicing software · XRechnung · ZUGFeRD · Peppol

XRechnung API for invoicing software

Create a validated XRechnung from simple JSON, check existing XRechnung and ZUGFeRD files against the official KoSIT and CEN rules, and send over Peppol when the buyer is reachable there. Dieselbe Seite auf Deutsch.

Get free key For platforms with many companies

No card needed. Create and rotate keys yourself at api.wsystem.dev/account. Sandbox on every endpoint.

Short answer: POST https://api.wsystem.dev/einvoice/create turns JSON into a UBL 2.1 XRechnung and validates it immediately. POST /einvoice/validate checks your own files — UBL, CII or a ZUGFeRD/Factur-X PDF — against the XML schema, CEN EN 16931 and the KoSIT XRechnung 3.0.2 configuration. POST /einvoice/send runs the same flow in the sandbox (transmission simulated, signed receipt). Live Peppol sending is switched on per company after a mandate and our KYC check.

What the API does today

Create. POST /einvoice/create turns JSON into a UBL 2.1 invoice in format xrechnung, en16931 or peppol-bis3. Totals and the VAT breakdown are computed for you. It does not create ZUGFeRD PDFs today.
Validate (KoSIT and EN 16931). POST /einvoice/validate checks UBL, UN/CEFACT CII and ZUGFeRD/Factur-X PDFs. For an XRechnung it runs the official KoSIT XRechnung 3.0.2 rules (configuration dated 31 August 2026) and EN 16931 1.3.15, unmodified. Each error has a rule ID, message, XPath and a fix hint. The checked field names the rule sets that ran. Peppol-BIS-3-specific rules (PEPPOL-EN16931-*) are not run yet. You can also drop a file into the browser validator or read one back as JSON with POST /einvoice/parse.
Check the buyer before sending. GET /einvoice/route?id=… checks the VAT number in VIES and whether the buyer is reachable in the Peppol Directory or via SML/SMP. POST /einvoice/preflight adds a sanctions screen and invoice validation, without sending. Step-by-step: Check if the buyer is on Peppol before sending.
Send. In the sandbox the whole flow runs and only the transmission is simulated. Live Peppol sending (mode=live) goes through our certified access-point partner, per company after a Peppol mandate and our KYC check.

German B2B invoices do not have to go over Peppol. A valid EN 16931 format (XRechnung or ZUGFeRD/Factur-X) is enough; the channel is agreed, and e-mail is allowed. Source: BMF, FAQ E-Rechnung. Deadlines: receiving since 1 January 2025, issuing from 1 January 2027 above €800,000 prior-year turnover and from 1 January 2028 for all. Details: Germany e-invoicing deadlines.

Example: create and validate against KoSIT

The sample is a German XRechnung in our JSON format; your software maps its own fields to the same JSON. $KEY is your API key (free, no card).

shell

# 1. Example invoice (no key)
curl -s https://api.wsystem.dev/einvoice/sample > invoice.json

# 2. Create an XRechnung (UBL 2.1) and check it on the official KoSIT / CEN rules
curl -s -X POST https://api.wsystem.dev/einvoice/create \
  -H "X-API-Key: $KEY" -H 'Content-Type: application/json' \
  -d @invoice.json \
  | jq -r .xml > INV-2026-001.xml

curl -s -X POST https://api.wsystem.dev/einvoice/validate \
  -H "X-API-Key: $KEY" -H 'Content-Type: application/xml' \
  --data-binary @INV-2026-001.xml

Response (trimmed, from a real run on 2026-11-12, API 0.3.97): Create.

{
  "valid": true,
  "format": "xrechnung",
  "syntax": "UBL 2.1",
  "checked": {
    "xsd": true,
    "EN16931": true,
    "XRechnung": true,
    "PeppolBIS3": false,
    "SK_national": false,
    "NO_national": false
  },
  "totals": {
    "currency": "EUR",
    "line_total": "980.98",
    "vat_total": "183.27",
    "total_with_vat": "1164.25",
    "payable": "1164.25"
  }
}

Validate the same file: valid true, profile XRechnung, KoSIT XRechnung 3.0.2 and EN 16931 ran.

{
  "valid": true,
  "profile": "XRechnung",
  "checked": {
    "xsd": true,
    "EN16931": true,
    "XRechnung": true,
    "PeppolBIS3": false,
    "SK_national": false,
    "NO_national": false
  },
  "rule_versions": {
    "EN16931": "1.3.15+ via KoSIT config",
    "XRechnung": "3.0.2 config 2026-08-31"
  },
  "error_count": 0
}

Or check a file that fails, with no key:

shell

curl -s https://wsystem.dev/examples/broken-xrechnung.xml | curl -s -X POST https://api.wsystem.dev/einvoice/validate -H 'Content-Type: application/xml' --data-binary @-

The same check on the public sample broken-xrechnung.xml: valid false, rule BR-CO-16.

{
  "valid": false,
  "profile": "XRechnung",
  "error_count": 1,
  "errors": [
    {
      "rule_id": "BR-CO-16",
      "message": "Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) -Paid amount (BT-113) +Rounding amount (BT-114).",
      "fix": "Amount due must be total with VAT minus prepaid amount plus rounding."
    }
  ]
}

Send over Peppol (sandbox first)

One call checks the buyer and the invoice, creates the XRechnung and returns a signed receipt (Ed25519 JWS). In the sandbox nothing is transmitted to a real recipient. For a live send you later set mode=live and recipient_check=strict: if the buyer is not on Peppol, the API answers HTTP 422 recipient_not_on_peppol before anything is sent.

shell

# Sandbox: the same checks as a live send, transmission simulated, signed receipt
jq '{invoice: ., mode: "sandbox", transport: "mock"}' invoice.json \
  | curl -s -X POST https://api.wsystem.dev/einvoice/send \
      -H "X-API-Key: $KEY" -H 'Content-Type: application/json' -d @-

Response (trimmed, from a real run on 2026-11-12, API 0.3.97):

{
  "status": "simulated",
  "receipt_id": "ev_4fa8f6b525f64315b868976a77eddc1e",
  "transmission": {
    "transport": "mock",
    "status": "simulated",
    "transmitted": false,
    "note": "Mock transport: no network transmission happened."
  },
  "preflight": {
    "verdict": "warn",
    "warnings": [
      "peppol"
    ]
  }
}

Price

A free sandbox key, then the Platform plan for invoicing software that sends for many client companies: €149 a month including 10 active companies and 1,000 checked invoices. Details and Peppol document prices are on the pricing page. Design partners get the first month free.

Questions

Is this a certification?

No. The API runs the official artefacts unmodified — the KoSIT XRechnung 3.0.2 configuration (dated 31 August 2026) and the CEN EN 16931 artefacts — and each response names the rule sets that ran. That is not a certification, and it is not legal or tax advice.

Does the API create ZUGFeRD PDFs?

Not today. POST /einvoice/create turns JSON into a UBL 2.1 invoice in format xrechnung, en16931 or peppol-bis3. Existing ZUGFeRD and Factur-X files (PDF or the embedded XML) can be checked with POST /einvoice/validate and read back as JSON with POST /einvoice/parse.

Do German invoices have to go over Peppol?

No. Domestic German B2B requires a valid EN 16931 format (XRechnung or ZUGFeRD/Factur-X); the channel is agreed, and e-mail is allowed. Peppol is one channel; Belgium requires it. If the buyer is not registered on Peppol, the API still creates and validates the file, and your software delivers it through its usual channel.

When can we send live over Peppol?

The sandbox runs from day one with a free key. Live Peppol sending (mode=live) is switched on per company after a Peppol mandate and our KYC check, on a Peppol or Platform plan.

What does it cost?

The first 20 calls a day per IP are free without a key (enough to try /einvoice/validate and /einvoice/route). A free API key (work email only, no card) includes 500 units a month: a validation costs 3 units, create or send 8, a preflight 5, a Peppol lookup 1. For invoicing software that sends for many client companies, the Platform plan is €149 a month including 10 active companies and 1,000 checked invoices.

Technical check, not legal or tax advice.

XRechnung API for invoicing software

What the API does today

Example: create and validate against KoSIT

Send over Peppol (sandbox first)

Price

Questions

Is this a certification?

Does the API create ZUGFeRD PDFs?

Do German invoices have to go over Peppol?

When can we send live over Peppol?

What does it cost?

Related