Entwickler-API · Empfangsseite
InvoiceIn.
Jede E-Rechnung, die Sie empfangen, als ein JSON.
Ein zustandsloser Endpunkt. Senden Sie per POST, was in Ihrem Posteingang landet — XRechnung, ZUGFeRD, Factur-X, Peppol BIS 3, FatturaPA, KSeF — und erhalten Sie kanonisches JSON nach EN 16931, einen Prüfbericht, der sagt, was der Rechnungssteller korrigieren muss, ein PDF, das Sie einem Menschen zeigen können, und CSV oder DATEV für die Buchhaltung. Verarbeitung im Arbeitsspeicher, ~10–50 ms pro Dokument.
Nur im Arbeitsspeicher. Nichts wird gespeichert. Kein Peppol-Zugangspunkt erforderlich.
Warum es das gibt
Ihre Kunden müssen eingehende XRechnung- und ZUGFeRD-Dateien seit 2025 empfangen und auslesen können — dazu kommen KSeF in Polen, FatturaPA in Italien, Factur-X in Frankreich — und Ihr Code wurde für PDFs geschrieben. Statt fünf Parser und fünf Regelwerke zu pflegen, schicken Sie uns die Datei und bekommen ein JSON zurück, plus eine Liste dessen, was daran falsch ist — in Worten, die eine Buchhaltung an den Lieferanten weiterleiten kann. Wir behalten das Dokument nie.
Live-Demo
Legen Sie eine echte Eingangsrechnung ab. Wir lesen sie aus, prüfen sie gegen die offiziellen Regelwerke und zeigen die Hinweise — nichts wird behalten.
Kopfdaten
Befunde
Rohes JSON
Fünf Ausgaben. Ein Aufruf.
Kanonisches JSON nach EN 16931
Eine Struktur für jede Syntax. Felder nach dem semantischen Modell benannt, mit BT-/BG-Nummern: Rechnungssteller, Rechnungsempfänger, Positionen, Steueraufschlüsselung, Summen, Zahlung und IBAN, Referenzen, Anlagen. Nationale Erweiterungen liegen unter extensions.
Prüfbericht mit Korrekturhinweisen
Offizielle Regelwerke plus rechnerische Gegenprüfungen. Jede verletzte Regel trägt einen verständlichen Hinweis auf Deutsch, Englisch, Französisch, Italienisch oder Polnisch — was der Rechnungssteller ändern muss und welches Feld (BT-Nummer) betroffen ist.
Lesbares PDF oder HTML
Gleiches A4-Layout für jede Syntax, Beschriftung auf Deutsch, Englisch, Französisch, Italienisch oder Polnisch. Für die Person in der Freigabe, die die Rechnung sehen will, nicht das XML.
CSV und DATEV
Flaches CSV pro Position oder pro Dokument sowie ein DATEV-Buchungsstapel (EXTF 700) für die Eingangsrechnung — SKR03 oder SKR04, Ihr Kreditorenkonto.
MCP-Server
Entfernt unter /mcp oder lokal über stdio. Claude, Cursor, n8n oder Ihr eigener Agent liest und prüft eine Rechnung mit einem einzigen Tool-Aufruf.
Was hineingeht, was geprüft wird.
Die Erkennung erfolgt automatisch — Sie senden die Datei, wir sagen Ihnen, was es war. Hybride PDFs werden geöffnet und das eingebettete XML extrahiert; das PDF selbst wird nie auf die Festplatte geschrieben.
| Format | Syntax | Container | Angewandte Validierung |
|---|---|---|---|
| XRechnung 3.0 | UBL 2.1 oder CII D16B | XML | XSD · EN 16931 Schematron 1.3.17 · XRechnung 3.0.2 · Rechenprüfung |
| EN 16931 | UBL 2.1 oder CII D16B | XML | XSD · EN 16931 Schematron 1.3.17 · Rechenprüfung |
| Peppol BIS Billing 3 | UBL 2.1 | XML | XSD · EN 16931 · Peppol-BIS-3-Regeln · Rechenprüfung |
| ZUGFeRD 2.x / Factur-X — EN 16931, EXTENDED, XRECHNUNG | CII D16B | PDF/A-3-Hybrid oder reines XML | XSD · EN 16931 Schematron 1.3.17 · Rechenprüfung |
| ZUGFeRD 2.x / Factur-X — BASIC, BASIC WL, MINIMUM | CII D16B | PDF/A-3-Hybrid oder reines XML | XSD · Factur-X-1.09.2-Profilregeln (FX-SCH) · Rechenprüfung (die Kernregeln der EN 16931 gelten unterhalb des Profils EN 16931 nicht) |
| ZUGFeRD 1.0 | CII (CrossIndustryDocument 1p0) | PDF/A-3-Hybrid oder reines XML | Schema · Rechenprüfung |
| FatturaPA 1.2 | FatturaPA | XML | FatturaPA 1.2.2 XSD · Rechenprüfung (Dateien mit mehreren Rechnungskörpern werden als Stapel zurückgegeben) |
| KSeF FA(2) / FA(3) | FA-Schema | XML | FA(2) / FA(3) XSD · Rechenprüfung |
| Frankreich — CTC-FR (Verkäufer und Käufer in FR) | UBL 2.1 oder CII D16B | XML oder Factur-X-PDF | XSD · EN 16931 · FNFE CTC-FR 1.4.0.04 (BR-FR-Regeln, Flux 2) · Rechenprüfung |
| RO e-Factura (CIUS-RO) | UBL 2.1 | XML | XSD · CIUS-RO 1.0.1, das die EN-16931-Regeln bereits enthält · Rechenprüfung |
| VAE PINT AE (Billing, Self-Billing) | UBL 2.1 | XML | XSD · OpenPeppol PINT AE 1.0.4 (gemeinsame PINT-Regeln + VAE-Regeln) · kostenlose Prüfseite (EN) |
Die Regelversionen sind auch live unter GET /v1/formats gelistet. Fehlt ein Format, das Sie empfangen? Sagen Sie es uns.
Gebaut für die Teams, die diese Dateien jetzt empfangen müssen.
Strukturierte Rechnungen zu empfangen ist keine Option mehr: Deutschland seit 1. Januar 2025 (Empfangspflicht), Belgien über Peppol seit Januar 2026, Polen mit KSeF im B2B ab 1. April 2026, Frankreich ab 1. September 2026. Die Empfangsseite braucht einen Parser, eine Validierung und eine Möglichkeit, das Dokument einem Menschen zu zeigen — das ist das ganze Produkt.
Kreditoren- & Buchhaltungs-SaaS
Ihre Kunden leiten weiter, was ihre Lieferanten schicken. Ein Endpunkt macht aus sechs Syntaxen ein JSON, das Ihr Abgleich- und Freigabeprozess bereits versteht — plus einen Hinweis, den Sie an den Lieferanten weitergeben können, wenn dessen Datei fehlerhaft ist.
ERP- & Shop-Plugins
Dolibarr, InvoicePlane, Sylius, Shopware, Odoo — ein Plugin, das eingehende XRechnung und Factur-X lesen kann, liefern Sie in diesem Sprint aus statt nach einem sechsmonatigen Parser-Projekt. Kein Java, keine Schematron-Toolchain in Ihrem Build.
Agenturen, die Werkzeuge für KMU bauen
Kleine Kunden in DE, FR, IT, PL und Benelux bekommen E-Rechnungen und fragen Sie, was sie damit tun sollen. Validieren, darstellen, nach DATEV oder CSV exportieren — und die Ablehnung mit dem genauen Feld zur Korrektur an den Rechnungssteller zurückgeben.
Drei Zeilen bis zum ersten Auslesen.
Senden Sie die Datei als Multipart-Feld file oder als rohen XML-/PDF-Body. Authentifizierung über Authorization: Bearer <key> oder X-Api-Key. Ohne Schlüssel gilt das Demo-Kontingent: 20 Rechnungen pro IP und Tag.
curl -X POST "https://invoicein-api.peculiar.systems/v1/invoice?include=validation&lang=en" \
-H "Authorization: Bearer $INVOICEIN_KEY" \
-F "[email protected]"import { readFile } from "node:fs/promises";
const form = new FormData();
form.append("file", new Blob([await readFile("invoice.xml")]), "invoice.xml");
const res = await fetch("https://invoicein-api.peculiar.systems/v1/invoice?include=validation,datev&lang=de", {
method: "POST",
headers: { Authorization: `Bearer ${process.env.INVOICEIN_KEY}` },
body: form,
});
const data = await res.json();
if (!data.ok) throw new Error(`${data.error.code}: ${data.error.message}`);
console.log(data.invoice.totals); // { net, tax, gross, due, … }
console.log(data.validation.issues); // [{ id, severity, hint, field, who }]import os, requests
r = requests.post(
"https://invoicein-api.peculiar.systems/v1/invoice",
params={"include": "validation,pdf", "lang": "en"},
headers={"X-Api-Key": os.environ["INVOICEIN_KEY"]},
files={"file": open("invoice.pdf", "rb")},
timeout=30,
)
data = r.json()
if not data["ok"]:
raise SystemExit(f'{data["error"]["code"]}: {data["error"]["message"]}')
print(data["source"]["format"], data["source"]["profile"])
print(data["validation"]["valid"], data["validation"]["errors"], "errors")Beispielantwort (gekürzt)
{
"ok": true,
"source": {
"format": "xrechnung-ubl",
"syntax": "UBL",
"profile": "XRechnung 3.0",
"container": "xml"
},
"invoice": {
"document": {
"id": "RE-2026-0421",
"issue_date": "2026-08-30",
"type_code": "380",
"currency": "EUR",
"buyer_reference": "04011000-12345-03"
},
"seller": {
"name": "Nordlicht Werkstatt GmbH",
"vat_id": "DE123456789",
"electronic_address": { "value": "[email protected]", "scheme": "EM" },
"address": { "line1": "Kanalstraße 12", "city": "Kiel", "postcode": "24103", "country": "DE" }
},
"buyer": { "name": "Beispiel Bau AG", "address": { "city": "Hamburg", "country": "DE" } },
"payment": {
"means_code": "58",
"credit_transfers": [{ "iban": "DE02120300000000202051" }]
},
"totals": { "line_net": 314.86, "net": 314.86, "tax": 22.04, "gross": 336.09, "due": 336.09 },
"tax_breakdown": [{ "category": "S", "rate": 7, "taxable": 314.86, "tax": 22.04 }],
"lines": [
{ "id": "1", "quantity": 3.5, "unit": "HUR", "net_amount": 314.86,
"price": { "amount": 89.96 }, "tax": { "category": "S", "rate": 7 },
"item": { "name": "Wartung Lüftungsanlage" } }
],
"extensions": {}
},
"validation": {
"valid": false,
"errors": 1,
"warnings": 0,
"rule_sets": [
{ "id": "EN16931-UBL", "version": "EN 16931 validation artefacts 1.3.17" },
{ "id": "XRechnung-UBL", "version": "XRechnung 3.0.2 Schematron 2.6.0" }
],
"issues": [
{
"id": "BR-CO-15",
"severity": "error",
"rule_set": "EN16931-UBL",
"message": "[BR-CO-15]-Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110).",
"hint": "Der Rechnungsgesamtbetrag mit Umsatzsteuer (BT-112) muss dem Gesamtbetrag ohne Umsatzsteuer (BT-109) plus dem Gesamtbetrag der Umsatzsteuer (BT-110) entsprechen. 314.86 + 22.04 = 336.90, im Dokument steht aber 336.09 — die Summen des Rechnungsstellers wurden unabhängig von den Positionen gerundet.",
"field": "totals.gross (BT-112)",
"who": "sender"
}
]
},
"timings_ms": { "detect": 1.2, "map": 3.8, "validate": 18.1, "total": 23.4 }
}Endpunkte
- POST /v1/invoice
- Alles in einem JSON.
?include=validation,html,pdf,csv,datev&lang=en|de|fr|it|pl - POST /v1/validate
- Nur der Prüfbericht.
- POST /v1/parse
- Nur kanonisches JSON, ohne Validierung.
- POST /v1/render.html
- Lesbares HTML.
- POST /v1/render.pdf
- Lesbares A4-PDF.
- POST /v1/export.csv
- Flaches CSV.
?level=lines|documents - POST /v1/export.datev
- DATEV-Buchungsstapel.
?skr=03|04&creditor_account=70000 - GET /v1/formats
- Unterstützte Eingangsformate und Regelwerk-Versionen.
- GET /v1/rules/{id}
- Erklärt eine Regel-ID in verständlicher Sprache.
?lang=de - GET /v1/countries
- Welches Format die Pflicht eines Landes verlangt und womit wir es prüfen.
- GET /v1/vat/{number}
- Prüft eine EU-USt-IdNr.: Format offline, dann live über VIES, mit datiertem Beleg.
- GET /v1/peppol/{id}
- Ist ein Geschäftspartner im Peppol-Netz veröffentlicht, und was kann er empfangen.
- GET /docs
- OpenAPI-Referenz.
- MCP /mcp
- Entfernter MCP-Server; lokale stdio-Variante auf Anfrage.
Fehler kommen als {"ok": false, "error": {"code", "message", "hint"}} mit passendem HTTP-Status zurück. Das verbleibende Guthaben steht im Header X-Credits-Remaining.
Zahlung pro Dokument. Gekaufte Credits verfallen nie.
Eine Rechnung = ein Credit, egal welche Ausgaben Sie in diesem Aufruf anfordern; eine Datei mit mehreren Rechnungen kostet einen Credit pro Rechnung. Kein monatliches Minimum, keine Nutzerlizenzen.
Mit Ihrem ersten Schlüssel, 30 Tage gültig. Keine Karte. Genug, um die Integration anzubinden und mit echten Lieferantendateien zu testen.
Für ein Plugin im Produktivbetrieb mit einer Handvoll Kunden.
Die übliche Stufe für ein Kreditorenwerkzeug oder eine Agentur mit mehreren Kunden.
Höhere Volumen und On-Premise-Images auf Rechnung — fragen Sie an.
Preise zzgl. USt. Zahlung auf Rechnung oder per Zahlungslink; Self-Service-Checkout folgt. Für höhere Volumen Rechnung auf Anfrage. Das Demo-Kontingent (20 Rechnungen pro IP und Tag) braucht gar keinen Schlüssel.
Schlüssel anfordern.
Hinterlassen Sie Ihre E-Mail-Adresse und, wenn Sie möchten, was Sie empfangen. Wir antworten mit einem Schlüssel und bei kostenpflichtigen Stufen mit Rechnung oder Zahlungslink.
Validierungsergebnisse beschreiben, was die offiziellen Regelwerke über eine Datei aussagen. Sie ersetzen keine rechtliche oder steuerliche Beratung, und keine automatische Prüfung kann zusichern, dass eine Finanzverwaltung oder ein Rechnungsempfänger ein Dokument annimmt.
Kurze Antworten.
Ist das ein Peppol-Zugangspunkt?
Speichern Sie meine Rechnungen?
Welche Regelversionen setzen Sie ein?
- EN 16931 Validation Artefacts 1.3.17 (UBL- und CII-Schematron)
- XRechnung 3.0.2 — KoSIT-Schematron 2.6.0 (UBL und CII)
- Peppol BIS Billing 3.0 Regeln, aktueller Master
- FNFE CTC-FR 1.4.0.04 Übergangsprofil (BR-FR-Regeln, Flux 2) — greift, wenn Verkäufer und Käufer beide in Frankreich ansässig sind
- CIUS-RO 1.0.1 (ro16931-ubl-1.0.9) — Ergebnis und Wortlaut entsprechen dem, was das SPV der ANAF zurückgibt
- Marktkonventionen, die kein Schematron liest: Skonto-Angaben im Freitext und die polnische KSeF-Nummer (
?ksef=) - UBL 2.1 XSD · CII D16B XSD · FatturaPA 1.2.2 XSD · KSeF FA(2) und FA(3) XSD
- Rechnerische Gegenprüfungen (Positionssummen, USt je Kategorie, Summen) bei jedem Format
Jede Antwort nennt die verwendeten Versionen: validation.rule_sets im Body und der Header X-Invoicein-Rulesets. Änderungen stehen datiert unter /rules/changelog (Atom-Feed) und GET /v1/rulesets; jede Regel-ID lässt sich über GET /v1/rules/{id}?lang=de erklären lassen.
Was ist mit Factur-X BASIC und MINIMUM?
coverage: schema.