Rule Studio
„Formal gültig“ heißt nicht „für uns in Ordnung“. Das Rule Studio ist ein Regel-Compiler mit grafischem Designer: Aus Stammdaten und eigenen Regeldefinitionen entsteht ein Prüfregelwerk, das der Validator zusätzlich zum offiziellen Szenario auswertet.
Das Grundprinzip
Das offizielle XRechnung- oder ZUGFeRD-Szenario wird nicht angefasst. Die eigenen Regeln kommen als zusätzliche, klar getrennte Ressource in dieselbe Szenario-Definition. Das hat drei Folgen, und jede davon ist der eigentliche Grund für diese Bauweise:
Ein Wechsel von XRechnung 3.x auf 4.x tauscht das offizielle Regelwerk aus. Ihre eigenen Regeln bleiben davon unberührt, weil sie nie hineinkopiert wurden.
Eigene Regeln tragen ein eigenes ID-Präfix. Im Prüfbericht ist damit auf den ersten Blick erkennbar, ob ein Befund aus dem Standard kommt oder aus Ihrem Haus.
„Konform zu XRechnung“ bedeutet weiterhin genau das. Ihre Regeln sind eine zusätzliche Aussage — konform zu den Anforderungen Ihres Unternehmens.
Zwei Rollen
Ausgang
Die eigenen Daten stehen beim Verkäufer. Geprüft wird gegen die eigene Firmierung, Anschrift, USt-IdNr., die am Rechnungsdatum gültigen Bankverbindungen und die definierten Nummernkreise.
Eingang
Die eigenen Daten stehen beim Käufer. Stimmen Name und Anschrift des Empfängers — daran hängt der Vorsteuerabzug? Ist bei Lastschrift wirklich unser Konto belastet? Der Eingangsfall ist der praktisch wertvollere und wird von den meisten Werkzeugen übergangen.
Aus denselben Stammdaten entstehen zwei unterschiedliche Regelsätze. Ändert sich ein Stammdatum, werden die daraus erzeugten Regeln neu gebildet — von Hand nachbearbeitete Regeln werden dabei nicht überschrieben, sondern zum Vergleich vorgelegt.
Die Lücken
EN16931 und die nationalen Regelwerke prüfen Struktur und Rechenwerk. Eine ganze Reihe von Anforderungen aus dem Umsatzsteuerrecht fällt dabei durch, weil das Feld im Standard schlicht optional ist:
Vier Regelsätze
Firmierung, Anschrift, USt-IdNr., gültige Bankverbindung, Nummernkreise, elektronische Adresse. Im Eingang zusätzlich: Wird bei Lastschrift wirklich unser Konto belastet, ist die Mandatsreferenz da, ist die Gläubiger-ID formal gültig?
Die Pflichtangaben, soweit sie maschinell entscheidbar sind — Leistungszeitpunkt, vollständige Anschriften, Steuernummer, Aufschlüsselung je Steuersatz, Befreiungswortlaut, Kleinunternehmerregelung, Kleinbetragsgrenze.
IBAN nach ISO 7064, BIC-Form, USt-IdNr. mit Prüfziffer je Land, GLN und GTIN nach Mod 10, DUNS, Leitweg-ID, SEPA-Gläubiger-ID. Der Standard prüft hier nur, ob ein Wert dasteht.
Plausibilität
Was herauskommt
Schematron als lesbares Zwischenformat, daraus das kompilierte Stylesheet und ein Szenario-Fragment zum Einfügen. Eine Regel wird einmal auf Feldebene formuliert und für CII, UBL Invoice und UBL CreditNote ausgegeben — die Zuordnung zu den Pfaden löst der Compiler auf, nicht der Mensch.
Ein Prüfkatalog als Dokument: jede Regel mit Klartext, Rechtsgrundlage und Behebungshinweis — und die Schritte, die bewusst manuell bleiben. Genau das, was eine Verfahrensdokumentation nach GoBD verlangt.
Quelle der Wahrheit ist dabei das Regelwerk selbst, nicht das erzeugte Schematron. Schematron und Stylesheet sind Build-Ergebnisse — dasselbe Verhältnis wie zwischen Mapping und generiertem Zugriff im Mapping Studio.
Die Grenze
Doppelte Rechnungsnummer, Abgleich gegen Bestellung und Wareneingang, Gültigkeit einer USt-IdNr. beim Bestätigungsdienst, Handelsregister- und Sanktionslistenabgleich. Solche Befunde markiert die Regel als „extern zu prüfen“ und liefert den Wert mit — den Abruf erledigt die API, damit die Prüfung selbst offline und wiederholbar bleibt.
Ob die Leistung sachlich berechtigt war, ob der Preis angemessen ist, ob die Leistungsbeschreibung wirklich handelsüblich ist und ob der gewählte Steuersatz zur konkreten Leistung passt. Diese Punkte stehen als dokumentierte manuelle Schritte im Prüfkatalog — das ist ehrlicher, als sie in eine Regel zu zwingen, die dann falsch anschlägt.
Aus demselben Grund ist die Voreinstellung eigener Regeln zurückhaltend: Eine Regel, die nicht sicher entscheiden kann, meldet einen Hinweis und führt nicht zur Ablehnung.
Das Werkzeug
Prüfprofil „XRechnung ohne Leitweg-Zwang“, auf Basis XRechnung 3.0.2 UBL. Links wird der Regelbestand gefiltert — nach Regelwerk (EN 16931 UBL, Factur-X CII, Peppol BIS, XRechnung), nach Herkunft, nach Jurisdiktion und nach Stufe. In der Mitte steht jede Regel im Klartext, mit den BT- und BG-Nummern, auf die sie sich bezieht; die Stufe ist je Regel einstellbar: fatal, error, warning, information — oder die Regel wird abgeschaltet. Rechts wächst das Profil mit: wie viele Regeln aus der Basis kommen, wie viele abgeschaltet, gestuft oder ergänzt wurden, und darunter das Profil-JSON. Genau diese Datei wird ausgeliefert und versioniert.
Die vier mitgelieferten Regelsätze sind ein Anfang. Interessant wird es bei den Regeln, die nur in Ihrem Haus gelten — Bestellnummernmuster, Freigabegrenzen, Pflichtangaben je Mandant.