Fehler und Katalog
Problem-JSON und jeder Katalogcode.
- In der Sandbox
In einfachen Worten
Wenn ein Aufruf fehlschlägt, sagt die Antwort, ob die Anfrage oder die Rechnung falsch ist. Bei einer Rechnung nennt ein Code das Feld im Export des Kunden und sagt, wer den Fehler behebt. Der Partner korrigiert fehlerhafte Anfragen und fehlerhafte Daten; wir korrigieren unser eigenes Mapping und versuchen es bei Fehlern auf Seiten des Übermittlungswegs erneut.
Tipp
400 betrifft unser Anfrageformat. 422 betrifft die Rechnung, und ihr Katalogcode nennt das Feld im ERP-Export. Halten Sie die beiden auseinander.
Problem-JSON
Jede Fehlerantwort ist Problem-JSON (RFC 9457): type, title und status, dazu detail, wenn es mehr zu sagen gibt. Ein 422 enthält zusätzlich errors, eine Liste von Befunden. Jeder enthält einen code aus dem Katalog, die Angabe, wer ihn behebt (who_fixes), einen fix_hint und eine message sowie ein field, wenn der Befund ein einzelnes Feld betrifft (siehe Seite 3.2). Die hervorgehobene Zeile ist der Code.
curl -X POST "https://api-sandbox-eu.eurinvoice.com/invoices/xml?route=PEPPOL&invoice_ref=INV-2026-0051" \
-H "Authorization: Bearer <your-api-key>" \
-H "Content-Type: application/xml" \
-H "Idempotency-Key: order-2026-0051" \
--data-binary @not-an-invoice.xmlimport java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.nio.file.Path;
public class Example {
public static void main(String[] args) throws Exception {
HttpRequest request = HttpRequest.newBuilder(URI.create("https://api-sandbox-eu.eurinvoice.com/invoices/xml?route=PEPPOL&invoice_ref=INV-2026-0051"))
.header("Authorization", "Bearer <your-api-key>")
.header("Content-Type", "application/xml")
.header("Idempotency-Key", "order-2026-0051")
.POST(HttpRequest.BodyPublishers.ofFile(Path.of("not-an-invoice.xml")))
.build();
HttpResponse<String> response = HttpClient.newHttpClient()
.send(request, HttpResponse.BodyHandlers.ofString());
System.out.println(response.statusCode());
System.out.println(response.body());
}
}import { readFile } from 'node:fs/promises';
const response = await fetch('https://api-sandbox-eu.eurinvoice.com/invoices/xml?route=PEPPOL&invoice_ref=INV-2026-0051', {
method: 'POST',
headers: {
Authorization: 'Bearer <your-api-key>',
'Content-Type': 'application/xml',
'Idempotency-Key': 'order-2026-0051',
},
body: await readFile('not-an-invoice.xml'),
});
console.log(response.status);
console.log(await response.text());{
"type": "https://eurinvoice.com/problems/validation-failed",
"title": "The invoice did not pass the checks",
"errors": [
{
"code": "EI-XML-TYPE",
"fix_hint": "Send the invoice itself, in the format agreed for the route.",
"who_fixes": "erp",
"source": "XML-safety",
"message": "The file is not an invoice in a format this route accepts. Please send the invoice in the agreed format."
}
],
"status": 422
}Für einen Pfad, den der Service nicht kennt, lautet die Antwort 404 mit {"detail": "Not Found"}, als einfaches JSON.
Was jeder Status bedeutet
| Status | Bedeutung | Was Sie tun |
|---|---|---|
400 | Die Anfrage kann nicht gelesen werden: kein JSON, ein Feld ist falsch, oder der Idempotency-Key fehlt oder hat nicht 8 bis 100 Zeichen. | Die Anfrage korrigieren. |
401 | Kein Schlüssel oder ein unbekannter Schlüssel. | Den Schlüssel korrigieren. |
403 | Dem Schlüssel fehlt der Scope, den der Aufruf braucht, oder der Aufruf betrifft die Daten eines anderen Kunden (forbidden). | Einen Schlüssel mit dem Scope oder den richtigen Kunden verwenden. |
404 | Keine solche Rechnung, kein solches Dokument, kein solcher Katalogeintrag oder Eintrag der Betreuungsliste für diesen Kunden. | Die ID prüfen. |
409 | Der Idempotency-Key wurde mit einem anderen Body verwendet, oder seine erste Anfrage läuft noch. Eine Stornierung kam zu spät. Zugangsdaten existieren bereits oder wurden widerrufen. | Den Aufruf korrigieren. |
413 | Der Body ist größer als 5 MB (payload-too-large). | Eine kleinere Datei senden. |
415 | Der Inhaltstyp ist weder XML noch PDF, oder ein PDF-Body ist kein PDF. | Den Inhaltstyp korrigieren. |
422 | Die Rechnung hat eine Prüfung nicht bestanden. Nichts wurde eingereiht. | Die mit erp markierten Befunde beheben. Die mit us markierten liegen bei uns. |
429 | Zu viele Anfragen für den Schlüssel. | Die Sekunden aus Retry-After abwarten und dann wiederholen. |
500 | Die Rechnung konnte nicht geprüft werden. Bei uns ist etwas fehlgeschlagen. | Denselben Aufruf mit demselben Schlüssel wiederholen. |
503 | Der Service ist ausgelastet (busy), oder ein Aufruf zu Zugangsdaten kam bei einem Prozess ohne gesetzten Hauptschlüssel an. | Denselben Aufruf nach Retry-After Sekunden wiederholen. |
Jedes 409 hat einen eigenen Problem-type unter https://eurinvoice.com/problems/: idempotency-conflict, request-in-progress, already-submitted, send-in-progress, dead-letter, credential-exists und credential-revoked. Lesen Sie den type, nicht den title, um sie zu unterscheiden. Ein 413 wird nicht unter dem Idempotency-Key gespeichert, derselbe Schlüssel kann also mit einem kleineren Body erneut verwendet werden.
Ein 429 kommt je Kunde und Scope, mit Retry-After (siehe Limits). Nach einem 202 senden Sie nie erneut. Bei Fehlern auf Seiten des Netzes, die vorübergehend sein können, versuchen wir es nach unserem Zeitplan erneut, und eine endgültige Ablehnung kommt auf die Betreuungsliste.
Wer handelt
Jeder Katalogcode hat genau eine zuständige Stelle.
| Zuständig | Wer das ist |
|---|---|
erp | Der Partner: der ERP-Export oder seine Stammdaten. |
us | eurinvoice: Mapping, Serializer oder Konfiguration. |
business | Das Unternehmen des Verkäufers, mit seinem Käufer oder Buchhalter. |
client | Der Kunde, also der Verkäufer: Registrierung, Zugangsdaten oder Autorisierung. |
buyer | Die Seite des Käufers. |
route | Der Betreiber des Übermittlungswegs, eine Behörde, ein Access Point oder eine Plattform: abwarten und wiederholen. |
Der Partner behebt 400, 401, 403, 409, 413 und 415. Ein 422 enthält Befunde, und jeder sagt, wer ihn behebt: erp ist der Partner, us ist eurinvoice.
Der Katalog
Der Katalog enthält für jeden Befund einen Code. Diese Seite zeigt eine Auswahl von zwölf, einen oder zwei je Regelfamilie. Geben Sie einen Code ein und drücken Sie Enter, um zu ihm zu springen. Mit einem Schlüssel erklärt GET /catalogue/{code} jeden Code (siehe Katalogabfrage). Der vollständige Katalog ist für Partner: Fordern Sie ihn mit dem Zugang zur Sandbox an.
12 Codes
| Code | Wer handelt | Was falsch ist | Was zu tun ist |
|---|---|---|---|
EI-ID-IBANUnsere Prüfungen, prüfung der kennungen | Partner | Die IBAN besteht ihre Prüfung nach mod 97 nicht. | Korrigieren Sie das Bankkonto in den Unternehmenseinstellungen. |
EI-SCHEMAUnsere Prüfungen, schema | eurinvoice | Das Rechnungs-JSON entspricht nicht dem kanonischen Modell: ein fehlendes oder unbekanntes Feld, ein falscher Typ oder Code oder eine Strukturregel des Übermittlungswegs. | Lesen Sie den JSON-Pfad im Fehler und korrigieren Sie das Mapping des Kunden. |
EI-TOTALS-MISMATCHUnsere Prüfungen, vorprüfung | Partner | Die Summen, die das ERP gesendet hat (erp_totals), weichen von den aus den Positionen berechneten Summen ab, das Dokument würde also nicht zu den eigenen Büchern des ERP passen. | Finden Sie die Differenz (meist Rundung je Position statt je Dokument oder eine Rabattposition, die der Export ausgelassen hat) und korrigieren Sie den Export oder das Mapping. |
BR-CO-16EN 16931 und Syntax, validator des übermittlungswegs | eurinvoice | Der Zahlbetrag (BT-115) entspricht nicht dem Gesamtbetrag mit USt. (BT-112) abzüglich des gezahlten Betrags (BT-113) zuzüglich Rundung (BT-114). | Wir berechnen Summen aus den Positionen, deshalb tritt dies nur auf, wenn die Summen von außen kamen (eine durchgereichte Datei) oder bearbeitet wurden. Bilden Sie die Summen neu aus den Positionen und senden Sie erneut. |
EI-XML-DTDEN 16931 und Syntax, validator des übermittlungswegs | Partner | Das XML deklariert einen DOCTYPE. UBL, CII und FA(3) verwenden nie einen, und über einen DOCTYPE gelangen externe Entitäten, entfernte DTD-Abrufe und Entitätsexpansion in eine Datei (XXE). Die Datei wird abgewiesen, bevor ein Validator oder ein Übermittlungsweg sie liest. | Exportieren Sie die Rechnung ohne die DOCTYPE-Zeile. Fügt das ERP sie absichtlich hinzu, sprechen Sie den ERP-Hersteller an: Kein E-Rechnungsformat verwendet sie. |
EI-XML-SYNTAXEN 16931 und Syntax, validator des übermittlungswegs | Partner | Die Datei ist kein wohlgeformtes XML: Sie ist zum Beispiel abgeschnitten, ihre Kodierung passt nicht zu ihrer Deklaration, oder ein Zeichen wie & ist nicht maskiert. Kein Validator kann sie lesen. | Exportieren Sie die Datei erneut und öffnen Sie sie in einem beliebigen XML-Viewer. Suchen Sie nach einer abgeschnittenen Datei, einer Kodierung, die von der Deklaration abweicht, oder einem nicht maskierten &. |
EI-XML-TYPEEN 16931 und Syntax, validator des übermittlungswegs | Partner | Das XML ist wohlgeformt, aber keine Rechnung, die wir validieren: keine UBL-Invoice oder -CreditNote, keine UN/CEFACT-CII-Rechnung und keine KSeF-FA(3)-Rechnung (zum Beispiel eine UBL-Order oder eine ältere FA(2)-Datei). | Senden Sie die Rechnung selbst, im für den Übermittlungsweg vereinbarten Format. |
EI-PEPPOL-NO-ROUTEPeppol, antwort des netzes, braucht ein Netz | Partner | Der Access Point hat für die Kennung des Käufers keinen Empfänger gefunden: Der Käufer ist für diese Dokumentart nicht bei Peppol registriert. Endgültig für diesen Versand. | Prüfen Sie die Peppol-ID des Käufers im Debitorenstammsatz des ERP anhand des Peppol-Verzeichnisses; ist der Käufer nicht bei Peppol registriert, vereinbaren Sie mit ihm einen anderen Kanal. |
PEPPOL-EN16931-R001Peppol, validator des übermittlungswegs | eurinvoice | Der Geschäftsprozess (BT-23) sollte vorhanden sein. Mustang hat dies als Hinweis zu unserer ZUGFeRD-Datei nach EN 16931 gemeldet, die kein Peppol-Dokument ist. | Für ZUGFeRD ist nichts zu tun; unser Peppol-UBL schreibt den Prozess immer. |
BR-DE-5Deutschland, validator des übermittlungswegs | Partner | Der Name des Ansprechpartners des Verkäufers (BT-41) fehlt. | Ergänzen Sie in den Unternehmenseinstellungen eine Kontaktperson oder Abteilung für die Rechnungsstellung. |
KSEF-440Polen, antwort des netzes, braucht ein Netz | eurinvoice | KSeF hält bereits eine Rechnung mit derselben NIP des Verkäufers, derselben Rechnungsart (RodzajFaktury) und derselben Nummer (P_2); diesen Schlüssel behält KSeF 10 Jahre lang. Der Schlüssel ist die Nummer, nicht die Datei: In TEST erhielt auch eine andere Datei unter einer angenommenen Nummer 440. Die Antwort nennt die KSeF-Nummer und die Sitzung der Kopie, die KSeF zuerst angenommen hat. Eine Nummer, die KSeF abgelehnt hat (430 oder 450), wird nicht gehalten und kann erneut verwendet werden. | Senden Sie nicht erneut. Halten Sie die ursprüngliche KSeF-Nummer aus der Antwort fest und melden Sie die Rechnung als unter dieser Nummer angenommen. |
BR-RO-001Rumänien, validator des übermittlungswegs | eurinvoice | Die Spezifikationskennung (BT-24) ist nicht der CIUS-RO-Wert. | Setzen Sie das Profil ro-cius, das die Kennung von CIUS-RO 1.0.1 schreibt. |