Was sich geändert hat, und wann.
Jede Version, jede Fehlerbehebung, jede erneute Prüfung, mit Datum. Wir prüfen die von uns gepinnten Formate nach Kalender, statt zu warten, bis eine Behörde etwas ankündigt. Und wenn sich etwas unter einem Dokument bewegt, das Sie bereits versenden, steht es hier mit Datum. So machen wir das Herkunftsversprechen sichtbar.
Ein Dokument, das das französische Profil EXTENDED-CTC-FR angibt, wird gegen das EXTENDED-CTC-FR-Paket von FNFE-MPE geprüft und darunter gegen die EN-16931-Regeln von CEN. Diese ließen es an Regeln scheitern, die die französische Norm XP Z12-012 V1.4 aus dem Profil streicht, etwa BR-O-11, sodass eine Rechnung mit Positionen außerhalb des Anwendungsbereichs der Umsatzsteuer neben Positionen zum Normalsatz abgelehnt wurde. Solche Befunde entfallen jetzt, und ein Info-Befund nennt sie. AFNORs eigene Beispiele bestehen jetzt, wie gegen das französische Paket allein. Kein Dokument, das vorher bestand, scheitert jetzt. Das Ruleset-Changelog nennt jede Regel.
POST /v1/generate antwortet jetzt mit 400 VALIDATION_ERROR und nennt das Feld, wenn eine Anfrage für XRechnung, Peppol BIS, FatturaPA, Facturae, e-SLOG oder KSeF invoice.franceCtc auf true setzt oder invoice.businessProcessId enthält. Beliq schreibt France-CTC-Ausgabe nur als Factur-X oder ZUGFeRD. Bisher antwortete eine Anfrage für XRechnung in CII-Syntax mit franceCtc bei eingeschaltetem verify mit 422 INVALID_INVOICE, eine Anfrage für Peppol BIS mit einem der beiden Felder mit 200. franceCtc false gilt als nicht gesendet. Wenn Sie eines der Felder bei einem dieser Standards senden, lassen Sie es weg. Anfragen für Factur-X und ZUGFeRD ändern sich nicht. Die Docs-Seite Generate nennt, wo jedes Feld geschrieben wird.
Beliq speichert die Prüfbefunde Ihrer API-Anfragen 12 Monate lang, und die Job-Seite im Dashboard zeigt sie an. Ein gespeicherter Befund behält jetzt seine Regel-ID, seinen Schweregrad und seine Fundstelle, und seine Meldung wird durch einen festen Satz ersetzt, weil eine Meldung die Werte zitieren kann, die eine Regel geprüft hat. Bisher wurden nur Werte in einfachen Anführungszeichen entfernt, sodass die Werte gespeichert wurden, die die französischen Pakete Flux 2 und EXTENDED-CTC-FR zitieren, etwa SIRET-Nummern, Rechnungsnummern und Beträge. Die Antwort auf eine validate- oder generate-Anfrage enthält weiterhin jede Meldung vollständig.
Ein Dokument der Factur-X-Profile MINIMUM, BASIC WL, BASIC oder EXTENDED prüft das eigene Factur-X-Paket seines Profils, nicht CENs EN-16931-Schematron. validate und generate nannten trotzdem dessen Version in schematronVersion und im Header x-schematron-version, convert in seinem Header x-version-block. Diese Version fehlt jetzt für die vier Profile, wie schon für Formate, die nur gegen ihre XSD geprüft werden. Bei validate listet rulesetArtifacts jedes Paket, das das Dokument geprüft hat. Urteil und Badge ändern sich nicht.
KoSIT veröffentlicht den XRechnung-Schematron und die Validator-Konfiguration, die seine Schweregrade festlegt, als ein Bundle. Eine validate-Anfrage, die nur eines von xrechnung_schematron und xrechnung_severity_overrides pinnte, prüfte das andere in seiner neuesten Version, eine Kombination, die KoSIT nie veröffentlicht hat: xrechnung_schematron:2.5.0 allein meldete CII-SR-465 und CII-SR-466 als Fehler, die das Bundle vom 2026-01-31 als Warnungen führt. Ein Pin auf eines der beiden prüft das andere jetzt aus demselben Bundle, und rulesetArtifacts nennt beide. Pins auf die beiden aus verschiedenen Bundles erhalten eine 422. Auf unserem XRechnung-Testkorpus ändern sich zehn Ergebnisse, jedes von ungültig zu gültig, und KoSITs Validator mit der Konfiguration vom 2026-01-31 nimmt alle zehn an. Anfragen auf latest und previous bleiben unverändert.
Eine validate-Anfrage, die Factur-X 1.08 auswählt, über den Pin facturx_schematron:1.08, Beliq-Ruleset: previous oder previous als Standard der Organisation, wurde gegen die Profil-XSD von 1.09.2 geprüft und danach gegen den Schematron von 1.08. Jetzt wird sie gegen die Profil-XSD von 1.08 geprüft. Unter 1.08 scheitert ein EXTENDED-Dokument jetzt, wenn es ein Element trägt, das nur 1.09.2 deklariert, etwa SpecifiedFinancialAdjustment, wenn es eines von sechs Elementen weglässt, die 1.09.2 optional gemacht hat, oder wenn es listID an einem Begründungscode für einen Nachlass oder Zuschlag setzt; das EXTENDED-Schema 1.08 von FNFE-MPE lehnt jedes davon ab. Kein Ergebnis für MINIMUM, BASIC oder BASIC WL ändert sich. rulesetSha256 ändert sich einmal für jedes Ergebnis unter 1.08 auf diesen drei Profilen und EXTENDED. Anfragen auf latest, dem Standard, bleiben unverändert.
Wir haben Sloweniens Mandatszeitplan am 23. Oktober 2026 gegen ZIERDED im Amtsblatt (Uradni list RS 85/2025) neu geprüft. Kein Datum hat sich verschoben: B2B-E-Rechnungen werden am 1. Januar 2028 Pflicht, und das amtliche Register der E-Route-Anbieter wird am 1. Oktober 2027 eingerichtet. Der Zeitplan nennt jetzt zusätzlich den 1. April 2027, ab dem das Kapitel des Gesetzes über E-Route-Anbieter gilt. Beliq betreibt den UJP-Einreichungskanal nicht und ist kein E-Route-Anbieter nach ZIERDED; Sie übermitteln über Ihren Dienstleister. Die Zeile zu 2015 nennt jetzt ihr Gesetz, ZOPSPU in der Fassung von 2013, und sagt, was es verlangt: Budgetnutzer empfangen Rechnungen nur noch in elektronischer Form. Außerdem haben wir unseren Hinweis gestrichen, die Länderseite der Europäischen Kommission zeige ein älteres Entwurfsdatum: Das tut sie nicht mehr.
Wir haben die Mandatszeitpläne für Irland und Schweden am 22. Oktober 2026 gegen die nationalen Quellen neu geprüft. Irland zeigt jetzt die Termine der Steuerverwaltung Revenue: Ab dem 1. November 2028 stellen Großunternehmen inländische B2B-E-Rechnungen mit Echtzeitmeldung aus, und jedes Unternehmen muss sie empfangen können; ab dem 1. November 2029 folgen Unternehmen im innergemeinschaftlichen Handel und weitere Großunternehmen. Beide Daten stehen im Gesetzentwurf Finance (No. 2) Bill 2026, den das Oireachtas noch berät. Zwei Zeilen zum öffentlichen Sektor waren falsch. Irlands S.I. No. 258 of 2019 verpflichtet die Zentralregierung ab dem 12. Juni 2019 und die übrigen Auftraggeber ab dem 18. April 2020. Schwedens Gesetz 2018:1277 gilt seit dem 1. April 2019, nicht seit dem 1. November 2019, und verpflichtet auch die Lieferanten. Keiner der beiden Zeitpläne zitiert noch die Seite der Europäischen Kommission.
Wir haben Deutschlands Mandatszeitplan am 20. Oktober 2026 gegen die FAQ des Bundesfinanzministeriums zur E-Rechnung (Stand März 2026), § 27 Abs. 38 UStG und die Länderseite der Europäischen Kommission neu geprüft. Kein Datum hat sich verschoben, und die Grenze von 800.000 Euro gilt weiter. Drei Texte stimmten nicht mit den Quellen überein. Die Zeile zum 1. Januar 2028 nimmt jetzt Unternehmen in der Kleinunternehmerregelung aus: Rechnungen über ihre Leistungen müssen in keiner Phase E-Rechnungen sein, ebenso wenig Kleinbetragsrechnungen bis 250 Euro brutto und Fahrausweise. In der Übergangszeit braucht eine Papierrechnung keine Zustimmung; ein PDF braucht sie, ebenso ein EDI-Verfahren, das nicht den Anforderungen an eine E-Rechnung entspricht. Unser Beitrag vom 13. Oktober ist ebenfalls korrigiert. Die Seite der Kommission spricht weiter von allen übrigen Unternehmen, deshalb nennt der Zeitplan sie nicht mehr.
Eine PDF-Quelle an zugferd oder facturx kommt jetzt als PDF zurück, wenn ihr eingebettetes XML geändert werden muss; vom 9. bis 14. Oktober wurde sie abgelehnt. Die Engine nimmt die Rechnungsdateien aus den eingebetteten Dateien, bettet das konvertierte XML als einzige Rechnungsdatei ein, prüft es Byte für Byte, und gibt das PDF nur zurück, wenn das PDF/A-3b-Profil von veraPDF es besteht. Ein PDF, das sie nicht neu verpacken kann, ergibt 422 CONVERSION_UNSUPPORTED_PAIR mit sourceFormat pdf-not-rewrappable. Der reason pdf-rewrap-not-offered bleibt für ein Profil ohne hybrides PDF, etwa EXTENDED-CTC-FR. Ein vor dem 9. Oktober neu verpacktes PDF kann das XML der Quelle neben dem konvertierten enthalten: Konvertieren Sie das Quell-PDF erneut.
Wir haben Dänemarks Mandatszeitplan am 7. Oktober 2026 gegen das dänische Gesetzblatt und die Erhvervsstyrelsen neu geprüft. Kein Datum hat sich verschoben. Der Zeitplan hält jetzt auch die Mitteilung der Erhvervsstyrelsen vom 14. Januar 2026 fest, dass es kein OIOUBL 3.0 geben wird, und ihren Plan, OIOUBL 2.1 zu behalten, bis NemHandel Rechnungen 2028 bis 2029 auf Nemhandel BIS 4 umstellt. BEK nr 811 af 22/09/2026, seit dem 29. September 2026 in Kraft, stellt neue Anforderungen an registrierte Buchhaltungssysteme; sie bindet deren Anbieter, nicht die Unternehmen, deren Fristen der Zeitplan verfolgt. Beliq erzeugt und validiert kein OIOUBL. Unsere Neuprüfung vom 19. und 20. September hat außerdem Frankreich, Irland, Slowenien und Schweden unverändert bestätigt; unser Eintrag vom 20. September nannte nur die fünf Länder, die sich bewegt haben.
Am 5. September hatten wir geschrieben, dass Beliq-Ruleset: previous XRechnung Schematron 2.5.0 und die Severity-Tabelle vom 2026-01-31 bis zum 11. Juni 2027 erreicht, und am 17. September, dass das weiterhin gilt. Diese Aussage nehmen wir zurück. KoSIT gibt das Bundle vom 2026-08-31, das 2.6.0 und seine Severity-Tabelle enthält, ab dem 31. August 2026 als gültig an. Ein Kanal sollte das ausgehende Paar deshalb nicht für Sie auswählen. Eine XRechnung-Anfrage mit previous löst jetzt auf latest auf und meldet rulesetFellBack: true. Senden Sie die exakten Pins xrechnung_schematron:2.5.0 und xrechnung_severity_overrides:2026-01-31 zusammen, dann reproduzieren sie weiterhin bis zum 11. Juni 2027 ein früheres Urteil; ein einzelner Pin mischt die beiden Releases. Factur-X 1.08 und France CTC 1.3.1 sind weiterhin über previous erreichbar.
Lehnt die Engine eine /v1/generate-Anfrage ab, trägt der 400 VALIDATION_ERROR den Grund jetzt in error.message: das Feld, die Regel und was zu ändern ist. Bis zu dieser Änderung lautete jeder solche 400 nur "Engine generation failed (400)", obwohl diese Hinweise und die Dokumentation sagen, dass die Ablehnung die Listen oder die Regel nennt. Das betrifft Nachlässe und Zuschläge bei e-SLOG, KSeF, FatturaPA und Facturae, eine taxId des Käufers bei Factur-X und ZUGFeRD, die elektronische Adresse bei XRechnung und die Regeln zu den Beträgen von Nachlässen und Zuschlägen. Ein 400 aus dem Anfrageschema bleibt unverändert und listet weiter error.details.fields.
Mit standard facturx oder zugferd und dem Profil basicwl, basic, en16931 oder extended ist ein Käufer mit taxId jetzt ein 400, der die Regel des Profils nennt. Die FNFE-MPE-Regeln dieser Profile erlauben dem Käufer nur eine Umsatzsteuer-Registrierung, also verletzte das Dokument sie. Bisher antworteten BASIC WL, BASIC und EXTENDED mit verify mit 422. EN16931, das Beliq nach den EN-16931-Regeln prüft, antwortete mit 200 und einem Dokument, das sein eigenes Factur-X-Paket ablehnt. en16931 ist das Standardprofil, eine Anfrage, die Sie schon senden, kann jetzt also mit 400 antworten. Die USt-IdNr. des Käufers gehört in buyer.vatId. MINIMUM, EXTENDED-CTC-FR und die anderen Standards behalten das Feld.
Mit standard fatturapa oder facturae ist eine Rechnung oder Position mit allowances oder charges jetzt ein 400, der die Listen nennt, wie bei e-SLOG und KSeF. Keiner der beiden Builder schreibt sie. Bisher kamen sie als 200 und als Dokument ohne sie zurück. Bei FatturaPA konnte ein Nachlass auf Rechnungsebene einen Zahlbetrag (ImportoPagamento) hinterlassen, der nicht zur Umsatzsteuer-Zusammenfassung passte, und die XSD-Prüfung, die einzige Prüfung, die Beliq auf FatturaPA ausführt, ließ ihn durch. UBL, CII, e-SLOG und KSeF bleiben unverändert.
POST /v1/convert validiert das konvertierte XML jetzt, bevor es zurückkommt: gegen die Schemas und Regelwerke, die Beliq für die Kennung ausführt, die das Dokument dann trägt. Ein Ergebnis, das nicht besteht, ist ein 422 CONVERSION_OUTPUT_INVALID mit dem Prüfergebnis in error.details.validationResult: Es kommt kein Dokument zurück, die Einheit des Kontingents bleibt verbraucht, und es wird kein Webhook gesendet. Bisher kam das Dokument ungeprüft zurück; eine Anfrage, die Sie schon senden, kann jetzt also mit 422 antworten, etwa eine Rechnung mit Positionen an Factur-X MINIMUM oder BASIC WL, die keine Positionen enthalten. Ein 200 trägt kein Prüfergebnis; sein Webhook job.completed enthält valid true und die Zahl der Warnungen. Nicht geprüft: der Container eines hybriden PDF und ob jedes Feld der Quelle angekommen ist. Details stehen auf der Docs-Seite Convert.
Zwei Konvertierungen werden jetzt mit 422 CONVERSION_UNSUPPORTED_PAIR und einem reason in error.details abgelehnt; beide konnten bisher mit 200 antworten. profile-relabel-not-offered: Die Syntax bleibt gleich, und die reine EN-16931-Kennung würde über eine Quelle in Factur-X EXTENDED oder EXTENDED-CTC-FR geschrieben, oder irgendeine Kennung über eine, die die Engine nicht benennt. missing-specification-identifier: Die Quelle gibt keine Spezifikationskennung (BT-24) an. targetProfile zählt jetzt auch, wenn die Quelle schon das Zielformat hat. Ein Dokument in Factur-X BASIC, an facturx mit targetProfile=minimum gesendet, kam unverändert als BASIC zurück. Jetzt wird seine Kennung auf MINIMUM umgeschrieben und das Ergebnis als MINIMUM validiert; ein Dokument mit Positionen antwortet also mit 422 CONVERSION_OUTPUT_INVALID.
Eine PDF-Quelle an zugferd oder facturx wird jetzt mit 422 CONVERSION_UNSUPPORTED_PAIR und dem reason pdf-rewrap-not-offered abgelehnt, wenn ihr eingebettetes XML geändert werden müsste. Bisher konnte eine solche Anfrage ein neu verpacktes PDF zurückgeben. Das Quell-PDF kommt nur zurück, wenn sich darin nichts ändern muss: Sein eingebettetes XML trägt schon die Kennung des Zielprofils und wird als das Zielformat erkannt. Mit sourceFormat=auto wird ein Factur-X- oder ZUGFeRD-Profil als facturx erkannt; ein Ziel zugferd braucht also sourceFormat=zugferd. Ein hybrides PDF, dessen XML die reine EN-16931-Kennung trägt, wird auch bei targetProfile=en16931 abgelehnt. Wer stattdessen das Rechnungs-XML sendet, erhält CII-XML zurück, kein PDF. Ein hybrides PDF erzeugt POST /v1/generate mit output pdf.
POST /v1/generate antwortet jetzt mit 400, wenn eine Anfrage für CII-Ausgabe invoice.businessProcessId enthält und nicht France CTC ist: franceCtc ist nicht true, und das Profil ist nicht extended-ctc-fr. Bisher antwortete sie mit 200. Bei XRechnung in CII-Syntax wurde der Wert als BT-23 geschrieben, anstelle der Kennung des Peppol-Billing-Prozesses; bei anderer CII-Ausgabe wurde er verworfen. Das Feld nimmt einen Code des cadre de facturation nach AFNOR XP Z12-012 auf, und Beliq schreibt ihn nur bei France-CTC-Ausgabe. Wenn Sie das Feld bei einer anderen Anfrage für CII-Ausgabe senden, lassen Sie es weg. Anfragen für France CTC ändern sich nicht, und Ausgabe, die nicht CII ist, liest das Feld wie bisher nicht. Die Docs-Seite Generate nennt, wo das Feld geschrieben wird.
POST /v1/parse setzt keinen Wert mehr ein, wo das Dokument keinen angibt. Ein Feld, dessen Element fehlt, leer ist oder nur Leerraum enthält, fehlt in invoice; bisher konnte es als leere Zeichenkette, als 0 oder in einer Position als unitCode C62 und vatCategoryCode S zurückkommen. Nur lines ist immer vorhanden; prüfen Sie also, ob ein Feld da ist, bevor Sie es lesen. Eine Zahl, die kein xs:decimal ist, oder ein Datum, das nicht die Form hat, die die Syntax vorgibt, lässt das Feld ebenfalls weg, und eine Warnung PARSE_VALUE_NOT_FOUND nennt das Feld und das Element. totalTaxAmount (BT-110) fehlt ohne eine solche Warnung, wenn kein Umsatzsteuer-Gesamtbetrag in der Dokumentwährung vorliegt, und mit einer, wenn es mehrere sind. Bei UBL steht der Handelsname nicht mehr für name ein. Die Docs-Seite Parse erklärt, was ein fehlendes Feld bedeutet.
Jede Antwort von POST /v1/parse trägt jetzt warnings. PARSE_NOT_RETURNED nennt, woraus der Parser keinen Wert gelesen hat: jedes Element, das Text oder ein Attribut enthält, mit Pfad und Anzahl, einmal an der Spitze eines Teils, den er nicht gelesen hat. Attribute eines gelesenen Elements werden nicht aufgeführt. Seine terms nennen acht Gruppen der EN 16931, wenn eine darunter ist: BG-3, BG-16, BG-20, BG-21, BG-23, BG-27, BG-28 und BG-32. PARSE_VALUE_NOT_FOUND sagt, wenn totalTaxAmount 0 ist, weil das Dokument nicht genau einen Umsatzsteuer-Gesamtbetrag in der Dokumentwährung enthält. Das geparste JSON ist eine Teilmenge des Dokuments; ein daraus generiertes Dokument ist also nicht das, das Sie geparst haben. Ebenfalls neu in der Antwort: profileUrn (BT-24), businessProcessId (BT-23) und franceCtcDetected.
POST /v1/parse liest jetzt die Positionen einer UBL-Gutschrift; bisher kam lines leer zurück. Zwei neue Felder: typeCode (BT-3) und documentType, invoice oder creditnote. Bei UBL entscheidet das Wurzelelement über documentType; bei CII der Typcode, und bei einem Code, den BR-CL-01 für beides (81) oder für keines zulässt, fehlt das Feld. Drei Dinge haben sich für Dokumente geändert, die Sie bereits parsen. totalTaxAmount (BT-110) ist der eine Umsatzsteuer-Gesamtbetrag, dessen currencyID die Dokumentwährung ist (BR-CO-15), und 0, wenn es keinen oder mehrere gibt; bisher war es der erste gefundene Betrag. Bei UBL ist vatId die Kennung unter dem Steuerschema VAT; bisher war es die erste, gleich unter welchem Schema. Ein Wurzelelement im UBL-Namensraum von Invoice oder CreditNote, das anders heißt, ist ein 400; bisher wurde es als Rechnung gelesen.
supportingDocuments (BG-24) nimmt bis zu 50 Einträge: eine id (BT-122) und optional eine description, eine externalLocation als URL und ein attachment, die Datei als base64 mit mimeCode und filename. Bei UBL- und CII-Ausgabe sind eine leere id, ein Inhalt, der kein base64 ist, und ein leerer mimeCode oder filename ein 400. Die Liste der Mime-Codes (BR-CL-24) überlässt Beliq der Validierung: Mit verify ist ein Code außerhalb der Liste des Regelwerks ein 422. Ein Anhang zählt zum Limit von 1 MB für den Request-Body, und ein größerer Body ist ein 413. UBL und CII schreiben die Gruppe. Bei Factur-X und ZUGFeRD lassen MINIMUM, BASIC WL und BASIC sie weg, die Profile ab EN16931 schreiben sie. FatturaPA, Facturae, KSeF und e-SLOG nehmen sie an und schreiben sie nicht.
invoicingPeriod (BG-14) nimmt ein startDate, ein endDate oder beide, auf der Rechnung und auf einer Position (BG-26). Ein Ende vor dem Beginn ist ein 400, ebenso ein Positionszeitraum, der den der Rechnung verlässt. Bei einer innergemeinschaftlichen Lieferung (Umsatzsteuerkategorie K) akzeptiert BR-IC-11 den Zeitraum anstelle eines Lieferdatums. vatPointDate (BT-7) ist das Datum, an dem die Umsatzsteuer abrechnungsrelevant wird. vatPointDateCode (BT-8) benennt es, wenn Sie das Datum noch nicht kennen: 3 das Rechnungsdatum, 35 das Lieferdatum, 432 das Zahlungsdatum. Beide zusammen sind ein 400 (BR-CO-03). Factur-X und ZUGFeRD schreiben den Rechnungszeitraum und den Code ab BASIC WL, den Positionszeitraum ab BASIC und das Datum ab EN16931. FatturaPA, Facturae, KSeF und e-SLOG nehmen alle vier an und schreiben sie nicht.
Acht optionale Felder: projectReference (BT-11), contractReference (BT-12), salesOrderReference (BT-14), receivingAdviceReference (BT-15), despatchAdviceReference (BT-16), tenderReference (BT-17), invoicedObjectIdentifier (BT-18, eine id mit optionaler schemeId) und buyerAccountingReference (BT-19). UBL verlangt neben einer Auftragsreferenz eine Bestellreferenz; ohne orderReference schreibt Beliq dort NA, den Wert, den die Peppol-BIS-Bindung vorgibt. NA zählt für PEPPOL-EN16931-R003 nicht als Bestellreferenz. Factur-X und ZUGFeRD schreiben BT-12, BT-16 und BT-19 ab BASIC WL und die übrigen ab EN16931. FatturaPA, Facturae, KSeF und e-SLOG nehmen alle acht an und schreiben sie nicht.
Rumänische CIUS-RO-Ergebnisse tragen jetzt verificationTier reconstructed-rules und das Siegel Community-geprüft statt Behördengeprüft. Die Regeln, die Ihr Dokument prüfen, haben sich nicht geändert; geändert hat sich, was wir über sie sagen. Die beiden XSLT-Dateien, die Beliq ausführt, sind die Kompilierung des quelloffenen Projekts phive-rules aus ANAFs CIUS-RO-1.0.9-Schematron, nicht ANAFs eigene Dateien, und wir haben sie noch nicht mit denen von ANAF verglichen. ANAF veröffentlicht außerdem keine Beispielrechnungen, gegen die wir sie prüfen könnten. Ergebnisse, Regel-IDs und rulesetSha256 bleiben gleich. Das Siegel wird wieder Behördengeprüft, sobald beide Lücken geschlossen sind; die Docs-Seite How verification works erklärt die Stufen.
Die `validate`-Funktion führt jetzt auch die Prüfungen auf Dokumentebene aus, die das Finanzministerium für jede KSeF-Rechnung aufführt: UTF-8 ohne Byte-Order-Mark, keine Verarbeitungsanweisungen, keines der Unicode-Zeichen, von denen XML 1.0 abrät, und höchstens 1.000.000 Bytes. Ein FA(3)-Dokument, das eine davon verletzt, kommt mit valid: false und einer ruleId KSEF_* zurück; KSeF hätte es abgelehnt. Die `generate`-Funktion berechnet die Umsatzsteuer jetzt einmal je Satz auf die summierte Nettosumme, wie FA(3) es festlegt, statt zeilenweise gerundete Beträge zu addieren, und lehnt Summen oder eine taxSummary, die von den Zeilen abweichen, mit 400 ab. DataWytworzeniaFa ist jetzt der Zeitpunkt der Erzeugung, nicht mehr das Rechnungsdatum um Mitternacht.
Die `generate`-Funktion akzeptiert den Standard `ksef` und erzeugt das nationale polnische KSeF-FA(3)-XML. Der Generator deckt reguläre Umsatzsteuerrechnungen in PLN zwischen polnischen Parteien zu den Sätzen 23, 22, 8, 7 und 5 % ab; Gutschriften, Korrekturen sowie Zu- und Abschläge werden abgelehnt. Die `validate`-Funktion erkennt FA(3) anhand des Namespace oder über `format=poland_ksef_fa3` und prüft gegen das XSD des Finanzministeriums. Dieser Pfad ist rein XSD-basiert: KSeF prüft die Geschäftsregeln bei der Einreichung, und die Einreichung bei KSeF übernimmt Beliq nicht. Das Profil wird als vorläufig eingestuft.
Am 15. September hatten wir geschrieben, dass unter France CTC 1.4.0.04 nichts von dem, was wir gemessen haben, neu scheitert. In einem Fall war das falsch. Die neun BR-FREXT-*-01-Regeln zählen jetzt nur noch DETAIL-Zeilen und prüfen jeweils zwei Dinge: Eine Umsatzsteuerkategorie, die in der Umsatzsteueraufschlüsselung fehlt, darf auf keiner Zeile stehen, und eine Kategorie aus der Aufschlüsselung muss auf mindestens einer Zeile oder einem Nachlass oder Zuschlag auf Dokumentebene stehen. Die erste Prüfung wurde lockerer, die zweite strenger. Eine CII-Rechnung, deren Aufschlüsselung eine Kategorie nennt, die nur GROUP- oder INFORMATION-Zeilen tragen, ging unter 1.4.0.03 durch und scheitert unter 1.4.0.04. Die entsprechenden BR-FXEXT-Regeln für Factur-X EXTENDED haben sich genauso geändert. UBL hat sich nicht geändert.
Zwei optionale Objekte. payee (BG-10) nennt eine andere Partei als den Verkäufer, die die Zahlung erhält, mit optionaler Kennung (BT-60) und Registernummer (BT-61). Ein Zahlungsempfänger mit dem Namen oder der Registernummer des Verkäufers ist ein 400, wie BR-17 es verlangt, ebenso eine Kennung im Schema SEPA: Senden Sie die Gläubiger-Identifikationsnummer als paymentMeans.creditorId, die UBL jetzt beim Zahlungsempfänger schreibt, wenn es einen gibt. taxRepresentative (BG-11) nimmt einen Namen, eine Umsatzsteuer-Identifikationsnummer und eine Adresse, in der nur das Land Pflicht ist. Factur-X trägt beide ab BASIC WL. FatturaPA, Facturae und e-SLOG nehmen beide an und schreiben sie nicht.
paidAmount (BT-113) ist, was der Käufer bereits gezahlt hat, und roundingAmount (BT-114) rundet den fälligen Betrag. Beliq leitet diesen Betrag (BT-115) als totalGrossAmount minus paidAmount plus roundingAmount ab; ohne beide bleibt er totalGrossAmount. Factur-X BASIC WL und BASIC haben keinen Platz für eine Rundung und lehnen einen roundingAmount ungleich null ab. FatturaPA, Facturae und e-SLOG geben totalGrossAmount als fälligen Betrag an und lehnen daher beide Felder ab, außer sie sind null. typeCode (BT-3) setzt den Code innerhalb Ihres documentType, etwa 384 für eine korrigierte Rechnung. Ein Gutschrift-Code auf einer Rechnung, oder umgekehrt, ist ein 400 (BR-CL-01). XRechnung, Factur-X, ZUGFeRD und Peppol BIS nehmen ihn an; die übrigen Standards antworten mit 422.
precedingInvoiceReference (BG-3) wurde nur in Gutschriften geschrieben; auf einer Rechnung ließen UBL und CII es kommentarlos weg. Jetzt wird es auf jedem Dokumenttyp geschrieben, sodass ein Rechnungs-Payload, der es schon mitschickte, ein Dokument ergibt, das es trägt. Eine korrigierte Rechnung (typeCode 384) braucht den Verweis: XRechnung warnt ohne ihn (BR-DE-26), ebenso Peppol BIS bei deutschem Verkäufer und Käufer (DE-R-026). Gutschriften kommen unverändert heraus. FatturaPA, Facturae und e-SLOG schreiben es weiterhin nicht.
Mit standard eslog ist eine Rechnung oder Position mit allowances oder charges jetzt ein 400, der die Listen nennt. Beliq schreibt sie auf keiner Ebene in e-SLOG-Dokumente. Bis zu dieser Änderung kamen Positionslisten und Rechnungslisten, die die Summen nicht veränderten, als 200 mit einem Dokument ohne sie zurück; die Positionsbeträge steckten schon in lineTotal. Andere Rechnungslisten wurden schon vorher abgelehnt, von einer Summenprüfung, deren Meldung sie nicht nannte. Der Eintrag vom selben Tag zu Nachlässen und Zuschlägen sagt, dass e-SLOG keine der Listen liest; es lehnt sie ab. UBL, CII, FatturaPA und Facturae bleiben unverändert.
Vier optionale Listen. allowances (BG-20) und charges (BG-21) auf der Rechnung ziehen einen Betrag vom ganzen Dokument ab oder schlagen ihn auf, etwa einen Mengenrabatt oder Fracht, und jeder Eintrag braucht eine Umsatzsteuerkategorie. allowances (BG-27) und charges (BG-28) auf einer Position, Unterpositionen eingeschlossen, tun dasselbe für diese Position. Beliq schreibt ihre Summen als BT-107 und BT-108 und leitet den Gesamtbetrag ohne Umsatzsteuer (BT-109) ab; totalNetAmount bleibt die Summe der Positionen. Ein lineTotal oder totalGrossAmount, der nicht auf zwei Cent genau aufgeht, ist ein 400: PEPPOL-EN16931-R120 und BR-CO-15 würden das Dokument ablehnen. Eine Rechnung, die keine davon trägt, kommt unverändert heraus. Factur-X trägt die Rechnungslisten ab BASIC WL und die Positionslisten ab BASIC; FatturaPA, Facturae und e-SLOG lesen keine davon.
Wir haben den Zeitplan der Niederlande am 23. September 2026 gegen niederländische Quellen neu gelesen. Am 11. September 2026 hat das Kabinett dem Parlament mitgeteilt, dass es E-Rechnungen für inländisches B2B ab dem 1. Juli 2030 verpflichtend machen will, dem Tag, an dem EU-ViDA das für grenzüberschreitendes B2B tut, und ab dem 1. Juli 2031 eine Meldung inländischer Rechnungsdaten an den Belastingdienst verlangen will. Unternehmen in der Kleinunternehmerregelung (KOR) sind ausgenommen. Gesetz ist das noch nicht: Ein Gesetzentwurf geht diesen Herbst in die Konsultation. Der Termin für öffentliche Stellen ist jetzt der genaue, der 18. April 2019. Unser Eintrag vom 20. September sagte, jeder Quellenlink nenne die Behörde, die wir gelesen haben; die Niederlande verlinkten damals noch die Seite der Europäischen Kommission und verlinken jetzt den Brief an das Parlament.
Wir haben alle neun Mandatszeitpläne am 19. und 20. September 2026 gegen die Behörde des jeweiligen Landes neu gelesen: nationale Gesetzblätter, Steuerverwaltungen und HMRC statt der Länderseiten der Europäischen Kommission, die zweimal ein Datum trugen, das das nationale Recht nicht kennt. Dänemark verliert eine Stufe zum 1. Juli 2026, die keine dänische Vorschrift enthält, und gewinnt die zum 1. Januar 2025, die es gibt. Der NHS-Meilenstein des Vereinigten Königreichs ist April 2014, nicht März 2022, und es kommt die Pflicht öffentlicher Stellen aus 2019 und 2020 hinzu, E-Rechnungen anzunehmen; April 2029 bleibt, aber keine britische Behörde hat ein Vier-Ecken-Modell festgelegt. Belgiens E-Reporting ist das Jahr 2028, nicht der 1. Januar 2028. Jeder Quellenlink nennt jetzt die Behörde, die wir gelesen haben.
Sieben optionale Felder auf jeder Rechnungsposition, Unterpositionen eingeschlossen. grossPrice (BT-148) ist der Preis vor einem Rabatt je Einheit, priceDiscount (BT-147) ist dieser Rabatt, und priceBaseQuantity (BT-149) ist die Anzahl Einheiten, für die ein Preis gilt; deren Einheit ist immer der unitCode der Position (BT-150), wie PEPPOL-EN16931-R130 es verlangt. Erst eine Basismenge lässt einen je 100 Einheiten kalkulierten lineTotal unter BT-131 aufgehen. Netto muss brutto minus Rabatt ergeben, sonst ist es ein 400: PEPPOL-EN16931-R046 würde das Dokument ablehnen. Zur Artikelidentität: standardItemId (BT-157), classifications (BT-158), originCountryCode (BT-159) und attributes (BG-32). Factur-X trägt die Preisfelder ab BASIC, den Rest ab EN 16931; FatturaPA, Facturae und e-SLOG lesen keines davon.
Ab dann nennt rulesetArtifacts auch das Syntaxschema, gegen das ein EN-16931-Dokument geprüft wurde: ubl_xsd, cii_xsd, cii_xsd_d22b oder das Schema eines Factur-X-Profils unter facturx_schematron. Auch das Schema entscheidet über das Urteil: Ein Dokument, das es ablehnt, erreicht keine Geschäftsregel. rulesetSha256 schließt es ein, daher ändert sich der Regelsatz-Hash jedes Ergebnisses für XRechnung, Peppol, Factur-X, ZUGFeRD und alle anderen EN-16931-Dokumente einmal. Keine Regel und kein Urteil ändert sich. Ein Dokument, das das Schema ablehnt, erhält beide Felder, die ihm heute fehlen. Wenn Sie rulesetSha256 speichern und über die Zeit vergleichen, rechnen Sie mit diesem einen Sprung oder vergleichen Sie die Zeilen von rulesetArtifacts. FatturaPA, Facturae und e-SLOG bleiben unverändert.
Jedes Factur-X- und ZUGFeRD-PDF ohne pdfTemplateId und jede Anfrage mit template: "standard" trug am Fuß jeder Seite die Zeile „Generated with beliq.eu“. Diese Zeile ging mit Ihrer Rechnung an Ihre Kunden. Sie entfällt jetzt für alle Aufrufer, auch im kostenlosen Generator. Die PDF-Metadaten nennen beliq.eu weiterhin als erzeugende Software, wie es jedes PDF-Werkzeug tut. Vorlagen, die Sie im Dashboard gestaltet haben, trugen die Zeile nie und bleiben unverändert. XML und Prüfergebnisse ändern sich nicht.
Zwei neue Felder erlauben es, den Umsatzsteuerbetrag einer Rechnung in der Währung auszuweisen, in der der Verkäufer die Umsatzsteuer verbucht. taxCurrencyCode ist diese Buchungswährung (BT-6), taxTotalInAccountingCurrency der Umsatzsteuerbetrag in ihr (BT-111). Die Umrechnung liegt bei Ihnen; Beliq wendet keinen Wechselkurs an. Senden Sie beide oder keines, und nie einen taxCurrencyCode gleich currencyCode: beides ergibt einen 400, weil BR-53 und PEPPOL-EN16931-R005 das Dokument ablehnen würden. Beide erreichen UBL- und CII-Ausgaben, Factur-X MINIMUM ausgenommen. Damit wird eine rumänische Rechnung in EUR möglich: BR-RO-030 verlangt RON als Buchungswährung für die Umsatzsteuer.
Fünf Felder, die Sie bereits senden konnten, erscheinen jetzt in der Ausgabe. registrationId ist die Registernummer, BT-30 beim Verkäufer und BT-47 beim Käufer, und genau die Angabe, auf die BR-CO-26 zurückfällt, wenn eine Rechnung keine Umsatzsteuer-Identifikationsnummer trägt. buyerItemId (BT-156) ist in beiden Syntaxen neu. itemId (BT-155) und taxId (BT-32) erreichen jetzt auch UBL, nicht nur CII. address.state wird als Länderunterteilung (BT-79) ausgegeben, wenn countrySubentity fehlt; senden Sie nach Möglichkeit countrySubentity, das ist das von EN 16931 definierte Feld. Zusammen mit einem Steuersatz, der einer nicht steuerbaren Zeile nicht mehr aufgezwungen wird, schließt das die Umsatzsteuerkategorie O. Wenn Sie peppol und registrationId zugleich senden, ist die UBL-CompanyID jetzt die von Ihnen gesendete.
itemId (BT-155) ging in jedes CII-Dokument, auch in das Factur-X- und ZUGFeRD-Profil BASIC. BASIC sieht dafür kein Feld vor: Seine Artikelgruppe endet beim Namen. Ein BASIC-Dokument mit einer itemId scheiterte deshalb an der XSD-Prüfung, an unserer wie an jeder anderen. Das war ein Dokument, das Sie nicht versenden konnten. BT-155 wird jetzt ab dem Profil en16931 ausgegeben und darunter weggelassen, damit die BASIC-Ausgabe wieder schemakonform ist. Wenn Sie auf die Artikelnummer des Verkäufers angewiesen sind, fordern Sie en16931 oder extended an. Sonst ändert sich an BASIC nichts.
Jede von Beliq erzeugte CII-Rechnung trug ein tatsächliches Lieferdatum (BT-72), gesetzt auf das Rechnungsdatum — ein Wert, den Sie nie gesendet haben. Einzige Ausnahme war das Factur-X-Profil MINIMUM, weil es dafür kein Feld vorsieht. Das war eine Erfindung, und eine Betriebsprüfung liest sie wörtlich. Wir geben BT-72 deshalb nur noch aus, wenn Sie delivery.date senden. Unter den aktuellen Regelwerken ändern sich Ihre Urteile nicht. Ein Fall doch: Bei einer inländischen deutschen Rechnung, deren Dokumentart nicht 386 ist, geprüft mit Beliq-Ruleset: previous oder einem Pin auf facturx_schematron:1.08, verlangt BR-FX-EN-04 BT-72, und das Dokument wird von gültig zu ungültig. Senden Sie delivery.date, dann besteht es in beiden Fällen. Das auslaufende Regelwerk zu pinnen ist hier kein Ausweg: Genau das wählt die Regel aus.
Lieferangaben (BG-13 und BG-15) und die SEPA-Lastschriftgruppe (BG-19) erreichen jetzt das Dokument. Senden Sie delivery mit einem Datum (BT-72), einem Empfängernamen, einer Standortkennung und einer Adresse, deren einziges Pflichtfeld countryCode ist (BT-80), sowie paymentMeans mit mandateReference, creditorId, debitedAccountId und information. Damit ist die Umsatzsteuerkategorie K geschlossen, die innergemeinschaftliche Lieferung von Gegenständen: Sie konnte bisher auf keinem Ausgabeformat ein gültiges Dokument erzeugen, weil BR-IC-11 das Lieferdatum und BR-IC-12 das Empfängerland verlangt, beide fatal, und kein Feld eines von beiden trug. In ein Factur-X-MINIMUM-Dokument gelangt nichts davon, dafür sieht das Profil keine Felder vor.
Am 3. September hatten wir geschrieben, dass Beliq-Ruleset: previous Peppol BIS Billing 3.0.20 bis zu dessen Ablauf im März 2027 erreicht. Diese Aussage nehmen wir zurück. OpenPEPPOL hat 3.0.21 zum 17. August 2026 verbindlich gemacht. Ein Dokument nach 3.0.20 kommt im Netzwerk deshalb nicht mehr durch, und ein Kanal sollte es nicht für Sie auswählen. Eine Peppol-Anfrage mit previous löst jetzt auf latest auf und meldet rulesetFellBack: true. Der exakte Pin peppol_bis_billing_schematron:3.0.20 bleibt unverändert und reproduziert weiterhin bis zum 4. März 2027 ein früheres Urteil: Ein Pin benennt eine Version, previous überlässt uns die Wahl. Das betrifft nur Peppol. Factur-X 1.08, France CTC 1.3.1 und XRechnung 2.5.0 sind weiterhin über previous erreichbar, weil keine Behörde deren Nachfolger verbindlich gemacht hat.
Ein reines Korrekturpaket von FNFE-MPE, ab sofort aktiv. Neun BR-FREXT-Regeln sollten nur für DETAIL-Zeilen gelten, sprachen aber ein Geschwisterelement als Kindelement an. Die Einschränkung griff deshalb nie und jede Zeile wurde wie eine DETAIL-Zeile bewertet: Rechnungen mit GROUP-Zeilen scheiterten an Regeln, die sie nie betreffen sollten. Mehrere Betragsprüfungen wechseln von number() zu xs:decimal(), damit Summen nicht mehr an der Fließkommadarstellung scheitern, BR-FR-CO-07 akzeptiert jetzt mehr als ein Fälligkeitsdatum und BR-FR-20 akzeptiert B2CINT. Ein seltener Fall scheitert neu, siehe die Korrektur vom 29. September. Die Factur-X-Spezifikation bleibt unverändert bei 1.09.2: Bewegt hat sich nur das Paket. 1.3.1 bleibt bis zum 16. Mai 2027 pinnbar.
Der am 20. August angekündigte FNFE-MPE-Wechsel gilt ab jetzt und nicht erst am 20. November 2026: Auf die ausgehenden Pakete ist niemand gepinnt. Die France-Seite wägt schwerer. Das Flux-2-Paket hebt 141 seiner CII-Regeln und 145 seiner UBL-Regeln von warning auf fatal, ohne eine Regel-ID zu ändern. Eine France-CTC-Rechnung, die mit BR-FR-Befunden unter den Warnungen als valide zurückkam, kommt jetzt als invalide zurück, in beiden Syntaxen. Bei Factur-X erhalten vier der fünf Profile zusätzliche Prüfungen, und BR-CO-25 fällt aus BASIC, BASIC_WL und EN16931 weg, wo daraus ein Hinweis wird. Auch die Regel-IDs ändern sich: Die Pakete geben Upstream-IDs neben den generierten FX-SCH-A-IDs aus. Pinnen Sie facturx_schematron:1.08 oder france_ctc_schematron:1.3.1 oder Beliq-Ruleset: previous, bis zum 16. Mai 2027.
Wir haben die Mandatsfristen für Belgien, Dänemark, Deutschland, Frankreich, Irland, die Niederlande, Schweden, Slowenien und das Vereinigte Königreich am 24.08.2026 erneut gegen die jeweils zuständige Behörde geprüft. Sieben gelten genau wie veröffentlicht. Zwei haben sich geändert. Dänemark erhält einen zusätzlichen Meilenstein: Die Einführungsphase des Buchführungsgesetzes wurde am 1. Juli 2026 für Unternehmen mit eigenentwickelten und internen Systemen abgeschlossen, und die NemHandel-Registrierung erfolgt seit demselben Datum im Opt-out-Verfahren. Beim Vereinigten Königreich kommt der Monat hinzu: April 2029 statt eines bloßen 2029, laut dem Tax Update der HMRC vom 23. Juni 2026, das außerdem Peppol als zentrales Interoperabilitätsnetz in einem Vier-Ecken-Modell ohne E-Reporting zum Start bestätigt. Die Fristen, die die API und die Dokumentation veröffentlichen, stammen aus derselben Quelle, die diese Prüfung liest.
KoSIT hat das XRechnung-Bundle vom 31.08.2026 veröffentlicht: Schematron 2.6.0 und eine neue Validator-Konfiguration. Wir stufen den Wechsel weiterhin als breaking ein, latest wechselt aber jetzt und nicht erst am 11. Dezember 2026: Auf das ausgehende Paar ist niemand gepinnt, und 2.5.0 weist konforme Dokumente ab. Zwei Dinge schlagen jetzt fehl, und keines davon ist eine neue Regel. BR-TMP-2 geht in beiden Syntaxen von warning auf fatal: BT-124 External document location muss eine absolute URL mit Schema sein, ein bloßer Pfad oder ein www-Host wird also abgewiesen. Und CII-SR-465 sowie CII-SR-466 gehen bei CII von warning auf error: Ein Verkäufer- oder Käuferkontakt darf nicht gleichzeitig einen Personen- und einen Abteilungsnamen tragen. In die andere Richtung schlägt eine leere OrderReference/ID nicht mehr fehl. Pinnen Sie xrechnung_schematron:2.5.0 oder Beliq-Ruleset: previous, bis zum 11. Juni 2027.
OpenPEPPOL hat Peppol BIS Billing 3.0.21 zum 17. August 2026 verbindlich gemacht, und Beliq validiert nun dagegen. Es gibt keinen Stichtag, vor dem Sie handeln müssten: Die Änderung ist im Netzwerk bereits in Kraft, daher ist latest unmittelbar darauf gewechselt. Zwei der Änderungen lassen Dokumente fehlschlagen, die zuvor durchgingen. Die Codeliste der elektronischen Adressen hinter PEPPOL-EN16931-CL008 verliert 14 Schemata, die die Behörde als unbrauchbar bezeichnet, darunter 0202, 0212 und 0217; eine damit adressierte Partei wird nun rundweg abgewiesen. Und vier dänische Regeln gehen von warning auf fatal: PEPPOL-COMMON-R052 und R053 in beiden Syntaxen, DK-R-003 und DK-R-017 in UBL. Pinnen Sie peppol_bis_billing_schematron:3.0.20, um bis zum 4. März 2027 ein früheres Urteil zu reproduzieren. Beliq-Ruleset: previous erreicht 3.0.20 nicht mehr.
Wir prüfen jedes versionierte Format nach Kalender gegen seine Behörde, nicht erst dann, wenn die Behörde etwas ankündigt. Dieser Eintrag entsteht deshalb unabhängig davon, ob sich etwas geändert hat. Am 26. August 2026 hatte sich bei keiner der beiden spanischen Quellen etwas geändert. Facturae steht weiterhin auf 3.2.2, und das Ministerium veröffentlicht nach wie vor ausschließlich die Spezifikation und die XSDs, ohne maschinenlesbares Regelwerk. Deshalb trägt Facturae die Kennzeichnung Schema-geprüft und nicht Behördengeprüft. VeriFactu ist ein Meldeverfahren und kein Rechnungsformat; dorthin übermittelt Ihre Rechnungssoftware, nicht Beliq. Die Fristen sind unverändert: 1. Januar 2027 für Unternehmen, die der Körperschaftsteuer (Impuesto sobre Sociedades) unterliegen, 1. Juli 2027 für alle übrigen.
Unsere Mitteilung vom 20. August beschrieb die France-Seite des 1.4.0.03-Wechsels als korrigierten XPath, der BR-FR-01/02/03 bei UBL-Dokumenten betrifft. Das war zu eng gefasst. Das neue Paket hebt 141 seiner CII-Regeln und 145 seiner UBL-Regeln von warning auf fatal, ohne eine einzige Regel-ID zu ändern. Jede France-CTC-Rechnung, die heute mit BR-FR-Befunden unter den Warnungen als valide zurückkommt, kommt als invalide zurück, in beiden Syntaxen. Der Stichtag wurde später auf den 10. September 2026 vorgezogen, siehe den Eintrag weiter oben. Der Pin, der das alte Verhalten erhält, ist derselbe, den die ursprüngliche Mitteilung nannte, france_ctc_schematron:1.3.1, und Beliq-Ruleset: previous erreicht ihn weiterhin.
Eine XRechnung-Extension- oder CVD-Rechnung gibt das Basisprofil mit einem angehängten Zusatz an, und wir haben diese Kennung exakt verglichen. Solche Dokumente wurden deshalb nur gegen EN 16931 geprüft, und keine BR-DEX-Regel ist auf einem gelaufen. Bei Peppol lag derselbe Fehler: eine nationale CIUS, die auf der Peppol-BIS-Kennung aufsetzt, etwa das norwegische EHF, traf auf keine Peppol-Regel. Außerdem haben wir die rohen Schweregrade des Schematrons angewandt statt der von KoSIT je Szenario veröffentlichten. Beides folgt jetzt den Regeln der Behörden selbst, womit unsere Abweichungen zum KoSIT-Validator über einen Korpus aus 271 Dokumenten auf null gesunken sind. Bei Extension, CVD und aufsetzenden nationalen CIUS erwarten Sie mehr Befunde, bei einfacher XRechnung weniger Ablehnungen aus Codelisten.
FNFE-MPE hat Factur-X 1.09.2 und France CTC 1.4.0.03 veröffentlicht, einen von uns als breaking eingeordneten Wechsel. Die France-Seite reicht weiter als zunächst beschrieben, korrigiert im Eintrag vom 31. August weiter unten. Vier der fünf Factur-X-Profile erhalten zusätzliche Prüfungen. Ein Dokument, das heute besteht, kann danach fehlschlagen, ohne dass sich auf Ihrer Seite etwas geändert hat. Eine Regel geht in die andere Richtung: 1.09.2 entfernt BR-CO-25 aus BASIC, BASIC_WL und EN16931, woraus ein Hinweis statt eines Fehlers wird. Dieser Stichtag wurde später auf den 10. September 2026 vorgezogen, siehe den Eintrag weiter oben. Auch die Regel-IDs ändern sich: Die neuen Pakete geben Upstream-IDs neben den generierten FX-SCH-A-IDs aus und nummerieren Letztere neu. Wer Regel-IDs aus Factur-X-Ausgaben auswertet, muss neu zuordnen.
Ein generate-Aufruf mit verify: false lieferte valid: true zurück, obwohl das Dokument nie validiert wurde. Antworten führen jetzt ein Feld verified, und valid bedeutet als valide geprüft: der übersprungene Fall meldet valid: false, verified: false. Wenn Sie eine Pipeline an valid hängen, lehnt sie ein ungeprüftes Dokument jetzt ab, statt es durchzulassen.
Die Kontingentprüfung las den Kalendermonat, während das Rücksetzdatum aus der Systemzeit berechnet wurde. In einem Prozess außerhalb von UTC wichen beide für einen Teil jedes Tages um einen Monat voneinander ab. Prüfung, das Feld resetsAt in GET /v1/me und der Retry-After bei QUOTA_EXCEEDED zählen jetzt alle bis zum Ende des Abrechnungszeitraums Ihrer Organisation. Das Sandbox-Kontingent setzt sich weiterhin zum 1. zurück, weil es tatsächlich pro Kalendermonat gezählt wird.
status.beliq.eu veröffentlicht die Verfügbarkeit von API und Dashboard über 90 Tage, von außerhalb unseres Netzes durch einen unabhängigen Dienst gemessen, mit Vorfallshistorie. Die Verfügbarkeitszahl auf der Startseite liest aus dieser Messung, nicht aus einer Zahl, die wir eingetippt haben.
beliq.eu/de liefert die Website, die Preise, dieses Changelog und die Rechtsdokumente auf Deutsch. Die deutschen Rechtstexte sind Originale und keine Übersetzungen des Englischen, weil Deutsch die Sprache ist, in der sie gelten.
Das Rate Limit besteht aus einem Burst-Kontingent plus einer Dauerrate; die Drosselung auf Kontoebene ist ein eigener Mechanismus. Eine gedrosselte Anfrage liefert jetzt den eigenen Fehlercode ACCOUNT_THROTTLED statt des allgemeinen Rate-Limit-Fehlers, sodass ein Client erkennt, worauf er gestoßen ist, und entsprechend zurückstecken kann.
Senden Sie Accept: application/json an /v1/generate, und das Dokument kommt base64-kodiert im Antwortkörper zurück, neben dem Validierungsergebnis, dem Fingerprint des verwendeten Regelsatzes und dem SHA-256 der exakten Bytes. Führen Sie sha256sum auf der gespeicherten Datei aus, und Sie können prüfen, ob es das ist, was wir gesendet haben. Die binäre Antwort bleibt unverändert.
Jede Organisation hat Test-Schlüssel neben den Live-Schlüsseln. Ein Test-Schlüssel durchläuft dieselbe Pipeline und zählt gegen ein separates Sandbox-Kontingent statt gegen Ihr Plan-Kontingent, und seine Jobs sind im Dashboard als Test-Modus gekennzeichnet, sodass ein Probelauf auch später von echtem Verkehr zu unterscheiden ist.
Der Vorlagen-Designer bindet {placeholder}-Felder als primären Mechanismus, bettet seinen eigenen Schriftsatz ein, damit ein Layout überall gleich aussieht, und bietet Startpunkte statt einer leeren Seite: Tabellen mit USt-Aufschlüsselung pro Satz, einzelne Adressfelder, Impressum des Verkäufers und Blöcke für die Zahlungsverbindung. Vorlagen werden über eine kurze ID statt einer UUID referenziert.
Wenn eine Anfrage auf unserer Seite fehlschlägt, enthält die Antwort eine incidentId. Nennen Sie sie dem Support, und wir finden den genauen Fehler in unseren Aufzeichnungen, ohne Sie um eine Reproduktion zu bitten.
Der PDF-Vorlagen-Designer erhielt eingebettete Logos, eine größere Farbpalette und einen SEPA-Zahlungs-QR-Code, der sich aus der Rechnung füllt. SVG-Felder werden serverseitig bereinigt, bevor sie gerendert werden.
Validierungsantworten liefern jetzt den SHA-256 Ihrer hochgeladenen Bytes und des exakt ausgeführten Regelsatzes, und GET /v1/rulesets veröffentlicht den Katalog der Artefakt-Hashes. So können Sie selbst prüfen, dass das Artefakt, das wir hinterlegen, dasselbe ist, das wir ausgeführt haben.
Senden Sie Beliq-Ruleset an eine Validierungsanfrage, um zu bestimmen, welche Regeln laufen: latest, previous oder ein exaktes Artefakt mit Version. Ihre Organisation hat zusätzlich einen Standard-Kanal, sodass ein ganzes Konto auf previous bleiben kann, während eine Umstellung greift; GET /v1/me nennt den aktuellen. Der Kanal gilt pro Format, denn previous führt erst dann einen eigenen Regelsatz, wenn eine brechende Umstellung wirksam wird: bis dahin löst er zu latest auf und die Antwort setzt rulesetFellBack, sodass Sie eine greifende Fixierung von einer ohne Ziel unterscheiden können. Die Antwort nennt in beiden Fällen die tatsächlich ausgeführten Artefakte.
Gestalten Sie ein PDF-Layout im Dashboard und generieren Sie per Vorlagen-ID: Ihr Factur-X oder ZUGFeRD im eigenen Branding entsteht als PDF/A-3b mit eingebettetem strukturiertem XML, validiert wie die Standardausgabe.
ZUGFeRD und Factur-X erzeugen ein hybrides PDF/A-3 mit dem rechtlich relevanten XML-Dokument eingebettet. Bei reinen XML-Standards gibt es keine Hybridform, daher liefert die PDF-Anfrage hier eine Visualisierung: eine menschenlesbare Darstellung, wobei das XML selbst weiterhin der rechtliche Beleg bleibt. Ein neuer Antwort-Header `x-pdf-kind` gibt an, welche Variante Sie erhalten haben, sodass eine Verarbeitungspipeline darauf verzweigen kann, statt die Variante aus dem Format abzuleiten.
Das ZUGFeRD-CII-Profil ist jetzt ein vollwertig unterstütztes Format, gestützt auf einen öffentlichen Positiv-Korpus und im selben Round-Trip wie Factur-X validiert.
Ereignisse im Abonnement-Lebenszyklus werden jetzt als signierte Webhooks ausgegeben, sodass Änderungen am Abrechnungsstatus Ihre eigene Automatisierung auslösen können.
Jeder Webhook-Versuch wird im Dashboard mit seinem Antwortcode festgehalten, samt erneutem Senden per Klick.
Das niederländische NLCIUS-Profil wird nun gegen den vollständigen Referenztestdatensatz der Behörde mit 120 Testfällen geprüft. Für jeden Testfall wird das erwartete Ergebnis bestätigt, und jede kritische Regelgruppe ist durch einen Fall abgedeckt, den die Engine korrekt ablehnt. In der API ändert sich nichts: `generate` und `validate` verhalten sich exakt wie bisher. Der Statuswechsel ist der entscheidende Punkt: Die Aussage ist nun durch den Referenzkorpus der Behörde abgesichert und nicht mehr nur durch unseren.
Webhooks tragen eine HMAC-SHA256-Signatur über einen signierten Zeitstempel. Signaturgeheimnisse werden über das Dashboard rotiert.
Die `generate`-Funktion akzeptiert den Standard `eslog` und erzeugt das nationale slowenische e-SLOG 2.0-XML für Rechnungen und Gutschriften auf derselben Nachrichtenstruktur. Die `validate`-Funktion erkennt e-SLOG-Dokumente anhand des Namespace und prüft sie gegen das behördliche XSD-Bundle. Dieser Pfad ist rein XSD-basiert: Die slowenische Behörde veröffentlicht keine maschinenlesbaren Geschäftsregeln, daher gibt es keine Schematron-Ebene, und ein struktureller Fehler trägt die Regel-ID `XSD` statt eines `BR-`-Identifiers. Das Profil wird als vorläufig eingestuft.
Die `generate`-Funktion akzeptiert das Profil `netherlands-nlcius` auf Basis von Peppol BIS und erzeugt UBL mit der aktuellen NLCIUS-Anpassungs-URN. Die `validate`-Funktion erkennt niederländische NLCIUS-Dokumente und wendet das von der niederländischen Peppol-Behörde veröffentlichte SI-UBL-Overlay an, das Rechnungen und Gutschriften in einem Durchgang abdeckt. Die Anforderungen an niederländische Rechtseinheiten werden erfüllt, indem der Parteienblock über das KvK- oder OIN-Schema geleitet wird. Das Profil wird als vorläufig eingestuft.
Vier weitere Länder nutzen die gemeinsame Peppol BIS-Pipeline ohne nationale Anpassung, sodass sie über den bereits vollständig geprüften Pfad erstellt und validiert werden. Alle vier Profile werden als unterstützt ausgeliefert. Jedes Land erhält einen Länderleitfaden mit Zeitplan für die E-Rechnungspflicht und dem jeweiligen Endpunkt-Schema. Schweden ist besonders zu beachten: Hier adressieren die Endpunkte die Organisationsnummer statt der Umsatzsteuer-Identifikationsnummer, sodass das Land vom länderspezifischen USt-ID-Fallback ausgeschlossen ist und das Schema explizit gesetzt werden muss.
Beide Länder nutzen den Standard Peppol BIS Billing 3.0 ohne nationale Anpassung. Beide Profile werden als unterstützt ausgeliefert. Die Länderleitfäden decken Irlands bereits geltende B2G-Pflicht sowie den B2B-Zeitplan für 2028 ab, ebenso wie die für 2029 bestätigte E-Rechnungspflicht im Vereinigten Königreich (bestätigt im Budget 2025). Das britische Profil basiert auf der vorläufigen Annahme, dass Peppol BIS mit einem Vier-Ecken-Modell eingesetzt wird. Die offiziellen Standards von HMRC und DBT werden voraussichtlich um das Budget 2026 herum veröffentlicht. Das Profil wird nach einem festen Kalenderzeitplan gegen diese Standards neu geprüft, nicht erst, wenn jemand daran denkt.
Die `generate`-Funktion akzeptiert das Profil `romania-ro-cius` des Standards `peppol-bis` und erzeugt UBL mit der aktuellen CIUS-RO-Anpassungs-URN. Die `validate`-Funktion erkennt rumänische Dokumente anhand der URN, sowohl aktuelle als auch ältere Versionen, und wendet das zweiteilige CIUS-RO-Schematron an. Zwei Erweiterungen werden für alle Profile eingeführt, nicht nur für dieses: das Feld für die regionale Untereinheit sowie ein zweiter Steuersummen-Block, der den Umsatzsteuerbetrag in der Buchungswährung enthält, was grenzüberschreitende rumänische Rechnungen benötigen. Ein Länderleitfaden informiert über die E-Rechnungspflicht. Das Profil wird als vorläufig eingestuft.
Eine Konvertierung, bei der akzeptable Elemente verloren gehen, gibt nun die vollständige Liste im Antwort-Header `X-Lost-Elements` zurück: Pfad, Wert, Grund und Schweregrad für jedes Element. Bisher wurde nur die Anzahl der verlorenen Elemente angezeigt, sodass Sie zwar wussten, dass etwas fehlte, aber nicht was. Der Header ist immer vorhanden, bleibt bei einer fehlerfreien Konvertierung leer und ist begrenzt, sodass pathologische Fälle auf einen Platzhalterwert gekürzt werden, statt Ihre Log-Zeile zu überfluten.
Konvertieren Sie eine EN 16931-Rechnung in einem Aufruf von einem Format in ein anderes: CII und UBL in beide Richtungen, ZUGFeRD und Factur-X durch Profilwechsel, XRechnung zwischen Syntaxvarianten sowie Peppol BIS UBL zu reinem EN 16931. Hybride PDFs funktionieren in beide Richtungen, wobei die visuelle Hülle neu verpackt wird, wenn das Zielformat eine PDF-Form vorsieht. Verluste werden in zwei Kategorien unterteilt: Elemente, die nicht stillschweigend akzeptiert werden dürfen, führen zum Abbruch und benennen die nicht abbildbaren Pfade; akzeptable Verluste werden mit einer Zählung zurückgegeben. FatturaPA, Facturae und KSeF sind weder Quell- noch Zielformate, da für sie kein veröffentlichter EN 16931-kompatibler Konverter existiert.
Die belgische B2B-E-Rechnungspflicht nutzt den Standard Peppol BIS Billing 3.0 ohne nationales Format oder nationale Anpassung. Belgische Rechnungen werden daher über die bereits bestehende Peppol-Pipeline erstellt und validiert. Adressieren Sie sie über das Unternehmensnummern-Schema oder den belgischen USt-ID-Fallback. Das Profil wird als unterstützt ausgeliefert. Eine belgien-spezifische Regel prüft die Prüfziffer der Unternehmensnummer. Ein Länderleitfaden informiert über die E-Rechnungspflicht.
Die `generate`-Funktion akzeptiert den Standard `facturae` und erzeugt XML gemäß dem behördlichen XSD-Bundle für Facturae 3.2.2. Die `validate`-Funktion prüft Facturae-Rechnungen, die anhand des Namespace erkannt werden. Dieser Pfad ist rein XSD-basiert, da Facturae auf der spanischen Ministeriumsspezifikation und nicht auf CEN basiert. Deshalb gibt es keine EN 16931-Schematron-Ebene und keine `BR-`-Regel-IDs, gegen die geprüft werden könnte.
Das niederländische SI-UBL-Overlay wurde erneut gegen die Referenztestfälle von NPa und NEN geprüft. Keine Abweichung.
Die `validate`-Funktion akzeptiert das Format `sdi_messaggio` und prüft die Benachrichtigungs- und Empfangsnachrichten, die das italienische Austauschsystem erzeugt. Dabei handelt es sich um eine andere Dokumentenklasse als eine FatturaPA-Rechnung, die gegen ein anderes Bundle validiert wird. Deshalb ist ein eigenes Format erforderlich, statt einer automatischen Erkennung als Rechnung. Die Prüfung erfolgt rein XSD-basiert. Bundle und Version werden in den Metadaten der Antwort zurückgegeben.
Die `generate`-Funktion akzeptiert den Standard `fatturapa` und erzeugt `ordinaria`-XML (FPR12) gemäß dem behördlichen XSD-Bundle. Die `validate`-Funktion prüft FatturaPA-Rechnungen, die anhand des Namespace erkannt werden, und deckt alle drei Varianten ab: `ordinaria` und PA ebenso wie `semplificata`. Die Prüfung erfolgt rein XSD-basiert ohne EN 16931-Schematron-Ebene, da FatturaPA auf der Spezifikation der italienischen Finanzverwaltung und nicht auf CEN basiert. Die Bundle-Versionen werden in den Metadaten der Antwort zurückgegeben.
Die semantischen Kernregeln für CII und UBL wurden auf das CEN-Validierungs-Release 1.3.16 aktualisiert und auf dessen veröffentlichten Tag versioniert.
Das Frühjahrs-Release von OpenPeppol wurde versioniert und gegen das veröffentlichte BIS-Billing-Testset validiert.
Das Januar-Schematron-Release von KoSIT für die XRechnung-Spezifikation 3.0.2 wurde für die UBL- und CII-Syntax versioniert.
Die Factur-X-1.08-Profile von MINIMUM bis EXTENDED sind für die PDF/A-3-Generierung und -Validierung angebunden.