Schematron: Wie Geschäftsregeln in E-Rechnungen tatsächlich geprüft werden

Wozu eine zweite Prüfschicht

Eine XSD kann viel: Sie legt fest, welche Elemente vorkommen dürfen, in welcher Reihenfolge, wie oft und mit welchem Datentyp. Was sie nicht kann, ist eine Aussage über Zusammenhänge.

„Der Gesamtnettobetrag muss der Summe der Positionsnettobeträge entsprechen" ist keine Frage der Struktur. Beide Felder sind vorhanden, beide sind vom richtigen Typ, beide stehen an der richtigen Stelle. Trotzdem kann die Rechnung falsch sein.

Genau dafür gibt es Schematron.

Wie eine Regel aussieht

Schematron-Regeln sind bemerkenswert lesbar, sobald man das Muster kennt:

1<rule context="cac:AccountingSupplierParty/cac:Party">
2  <assert test="cac:Contact" flag="fatal" id="DE-R-002">
3    The group "SELLER CONTACT" (BG-6) shall be provided.
4  </assert>
5</rule>

Vier Bestandteile, und jeder ist nützlich:

• context — wo im Dokument die Regel greift. Hier: bei der Partei des Verkäufers.
• test — der XPath-Ausdruck, der wahr sein muss. Hier: Es muss ein cac:Contact existieren.
• flag — der Schweregrad. fatal lehnt ab, warning merkt an.
• id — die Kennung, unter der der Verstoß gemeldet wird.

Der Text dazwischen ist die Meldung, die Sie im Ergebnis sehen. Er nennt das Feld in BT/BG-Notation, weil dieselbe Regel für CII und UBL gelten muss — die Elementnamen unterscheiden sich, die BG-Nummer nicht.

Eine Regel, die rechnet

1<assert test="xs:decimal(cbc:LineExtensionAmount) =
2              round(10 * 10 * sum(//cac:InvoiceLine/cbc:LineExtensionAmount)) div 100"
3        flag="fatal" id="BR-CO-10">
4  Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131).
5</assert>

Hier sieht man, warum XSD nicht ausgereicht hätte: Der Test summiert über alle Positionen und vergleicht das Ergebnis mit einem Feld an ganz anderer Stelle.

🔵 Man sieht auch, warum Rundung so oft das Problem ist. Der Ausdruck rundet explizit auf zwei Nachkommastellen. Wer ungerundete Werte summiert und erst das Ergebnis rundet, landet bei vielen Positionen einen Cent daneben — und die Regel ist fatal.

Die Regelfamilien

Ein Dokument wird nie gegen ein einzelnes Regelwerk geprüft, sondern gegen einen Stapel. Am Präfix erkennen Sie, wer die Regel aufgestellt hat:

Ein Dokument muss alle zutreffenden bestehen. Deshalb genügt es nicht, gegen EN 16931 zu prüfen, wenn das Ziel eine deutsche Behörde ist.

Eine Fehlermeldung lesen

1[BR-DE-2] fatal
2The group "SELLER CONTACT" (BG-6) shall be provided.

Schritt 1 — Schweregrad. fatal? Dann ist das der Ablehnungsgrund. warning? Dann liegt die Ursache woanders.

Schritt 2 — Präfix. BR-DE- sagt: deutsche Zusatzregel. Ihr Dokument erfüllt also möglicherweise die europäische Norm einwandfrei und scheitert nur an der nationalen Verschärfung.

Schritt 3 — BT/BG-Nummer. BG-6 ist die Kontaktgruppe des Verkäufers. Suchen Sie in Ihrem System nach dem, was diese Gruppe füllt — nicht nach dem Elementnamen.

Schritt 4 — bei Bedarf den Test ansehen. Wenn die Meldung mehrdeutig bleibt, ist der XPath-Ausdruck die verbindliche Auskunft. Er sagt genau, an welcher Stelle gesucht wurde.

Warum Regelwerke Versionen haben

Schematron-Regelwerke werden gepflegt, und mit einer neuen Version ändern sich nicht nur Regeln, sondern gelegentlich auch Schweregrade. Eine Regel, die letztes Jahr eine Warnung war, kann dieses Jahr fatal sein.

Für die Praxis folgt daraus ein unbequemer, aber wichtiger Satz: Eine Rechnung, die durchgegangen ist, ist keine Zusicherung für die nächste. Prüfen Sie gegen die Version, die Ihr Empfänger einsetzt — nicht gegen die, die beim Bau Ihrer Schnittstelle aktuell war.