Eine E-Rechnung in FileMaker erzeugen ist schon nicht einfach. Aber ist sie auch valide?

Von Jan Hagemeister · Veröffentlicht am 9. September 2026

Inzwischen gibt es zahlreiche Bibliotheken, Plugins und Webdienste für XRechnung, ZUGFeRD/Factur-X, UBL oder CII. Was dabei leicht übersehen wird: Nicht jede Lösung, die eine E-Rechnung erzeugt, validiert sie auch.

Das kann lange unbemerkt bleiben. Die erzeugte XML-Datei sieht auf den ersten Blick plausibel aus, lässt sich vielleicht sogar visualisieren und wird möglicherweise auch problemlos per E-Mail verschickt.

Erst beim Empfänger stellt sich heraus, dass die Rechnung nicht den geforderten Regeln entspricht.

XML erzeugen ist noch keine Validierung

Eine E-Rechnung ist nicht einfach eine Rechnung im XML-Format.

Bei einer Rechnung nach EN 16931 oder einer darauf aufbauenden Spezifikation müssen unterschiedliche Anforderungen erfüllt werden. Dazu gehören beispielsweise:

• die korrekte XML-Struktur,
• die richtige Verwendung der Elemente und Namespaces,
• Pflichtangaben,
• zulässige Codes und Werte,
• Abhängigkeiten zwischen einzelnen Angaben,
• mathematische und steuerliche Regeln sowie
• profilspezifische Geschäftsregeln, etwa bei der XRechnung.

Ein XML-Schema kann dabei nur einen Teil dieser Anforderungen prüfen. Eine Datei kann deshalb schema-valide und trotzdem fachlich ungültig sein.

Genau dafür existieren zusätzliche Prüfregeln, die bei EN 16931 und XRechnung typischerweise mittels Schematron umgesetzt werden.

Das eigentliche Problem: Der Fehler fällt beim Kunden auf

Besonders problematisch sind Lösungen, die lediglich das XML erzeugen und anschließend ausliefern. Der typische Ablauf sieht dann so aus:

Damit wird die Validierung faktisch zum Empfänger verlagert. Das ist aus meiner Sicht die falsche Reihenfolge.

Sinnvoll ist:

Schlägt die Prüfung fehl, sollte die Rechnung die eigene Anwendung gar nicht erst verlassen.

„Die Datei wurde erzeugt“ ist kein Qualitätsmerkmal

Technisch ist es vergleichsweise einfach, aus vorhandenen Rechnungsdaten eine XML-Datei zu erzeugen. Auch eine Bibliothek, ein Plugin oder ein Webdienst kann aus übergebenen Daten ein syntaktisch plausibles CII- oder UBL-Dokument generieren.

Die entscheidende Frage lautet deshalb nicht:

Sondern:

Und unmittelbar danach: „Was passiert, wenn die Validierung fehlschlägt?“

Eine robuste Lösung muss den Fehler erkennen, verständlich zurückmelden und verhindern, dass eine als ungültig erkannte Rechnung versendet wird.

Der vermeintliche Sonderfall ist in der Praxis der Normalfall

Ein Generator kann bei hundert Rechnungen scheinbar problemlos funktionieren und bei der hundertundersten eine ungültige Rechnung erzeugen. Denn viele Regeln werden erst durch bestimmte Geschäftsvorfälle ausgelöst.

Das Problem dabei: Was bei einer Demo gerne als „Sonderfall“ bezeichnet wird, ist in einem realen Unternehmen häufig ganz normaler Rechnungsalltag. Kaum ein Unternehmen hat dauerhaft ausschließlich Rechnungen mit einem einzigen Umsatzsteuersatz und liefert niemals ins Ausland.

Sobald eine Rechnungssoftware tatsächlich produktiv eingesetzt wird, kommen schnell weitere Konstellationen hinzu:

• unterschiedliche Umsatzsteuersätze innerhalb einer Rechnung,
• steuerfreie oder steuerbefreite Umsätze,
• innergemeinschaftliche Lieferungen und Leistungen,
• Lieferungen oder Leistungen in Drittländer,
• Gutschriften,
• Zu- und Abschläge,
• Skonto,
• negative Positionen,
• Rundungsdifferenzen,
• unterschiedliche Zahlungsbedingungen oder
• profilspezifische Pflichtangaben.

Gerade Steuerfälle sind dabei kritisch. Mit einem anderen steuerlichen Sachverhalt ändern sich nicht einfach nur Steuersatz und Steuerbetrag. Je nach Fall müssen andere Steuerkategorien, Begründungen und weitere Angaben verwendet werden.

ZUGFeRD macht die Sache nicht automatisch sicherer

Bei ZUGFeRD beziehungsweise Factur-X kommt eine weitere Besonderheit hinzu: Die XML-Rechnung wird in eine PDF/A-3-Datei eingebettet. Dadurch entsteht ein Dokument, das für einen Menschen völlig normal aussehen kann.

Das Rechnungsbild im PDF kann korrekt sein, während die eingebettete XML-Datei Fehler enthält.

Hinzu kommt: Auch der Container selbst kann fehlerhaft sein. Ein ZUGFeRD-Dokument muss ein gültiges PDF/A-3 sein, die XML-Datei muss korrekt als eingebettete Datei mit passender Beziehung deklariert sein, und die XMP-Metadaten müssen Profil und Version ausweisen.

Fehlt eines davon, erkennt der Empfänger die Datei unter Umständen gar nicht als E-Rechnung – obwohl das XML für sich genommen fehlerfrei wäre. Die Prüfung muss deshalb beide Ebenen umfassen: das PDF/A-3 und die darin enthaltene Rechnung.

Und schließlich ist „ZUGFeRD“ nicht gleich „ZUGFeRD“. Die Profile MINIMUM und BASIC WL enthalten keine vollständigen strukturierten Rechnungsdaten und erfüllen damit nicht die Anforderungen an eine E-Rechnung nach EN 16931.

Wer mit „ZUGFeRD-Unterstützung“ wirbt, sollte deshalb sagen, welches Profil gemeint ist – und gegen welche Regeln geprüft wird.

Was das konkret für eine FileMaker-Lösung bedeutet

FileMaker bleibt die führende Anwendung für Rechnungssteller, Kunden, Positionen, Steuern, Zahlungsbedingungen und Belegbeziehungen. Die Datenbank muss diese Angaben fachlich vollständig und eindeutig bereitstellen. Die technische Komponente erzeugt daraus CII, UBL oder eine hybride PDF/A-3-Rechnung und prüft das Ergebnis.

Der FileMaker-Ablauf darf deshalb nicht bei einem erfolgreichen Scriptschritt Aus URL einfügen oder bei einer zurückgegebenen Datei enden. Ein HTTP-Status 200 bedeutet nur, dass der Dienst die Anfrage technisch beantwortet hat. Ob die Rechnung valide ist, muss FileMaker aus der strukturierten Antwort auslesen und zur verbindlichen Workflow-Entscheidung machen.

Nur wenn die Antwort ausdrücklich den Status valide enthält, sollte FileMaker das erzeugte Dokument in das vorgesehene Containerfeld übernehmen, den Export als erfolgreich protokollieren und den Versand freigeben. Bei einem Fehler bleibt der Versandstatus gesperrt; Regelkennung und verständliche Fehlermeldung werden dem Anwender angezeigt.

Validierung gehört in den Erstellungsprozess

Für mich gehört die Validierung nicht ans Ende einer optionalen Qualitätssicherung. Sie ist Bestandteil der Rechnungserstellung:

Bei ZUGFeRD/Factur-X folgt anschließend noch die Erstellung des PDF/A-3-Dokuments mit eingebetteter XML-Datei – und auch dieses Ergebnis sollte geprüft werden, bevor es die Anwendung verlässt.

Dabei sollte das Ergebnis der Validierung nicht irgendwo in einer Logdatei verschwinden. Die aufrufende Anwendung benötigt eine eindeutige Antwort:

• Rechnung valide,
• Rechnung nicht valide,
• Fehler mit verständlicher Beschreibung und
• gegebenenfalls Warnungen.

Auch bei Updates muss weiter validiert werden

Das Problem endet nicht mit einer einmal funktionierenden Implementierung. Standards, Profile, Codelisten und Prüfregeln entwickeln sich weiter. Eine Rechnung, die mit einer bestimmten Version korrekt erzeugt wurde, sagt deshalb wenig darüber aus, ob eine Implementierung dauerhaft korrekt arbeitet.

Wer E-Rechnungen automatisiert erzeugt, benötigt deshalb nicht nur einen Generator, sondern auch ein funktionierendes Update- und Validierungskonzept.

Gerade bei lokalen Bibliotheken und Plugins sollte geklärt werden, wer dafür verantwortlich ist, neue Versionen und geänderte Prüfregeln einzuspielen.

Fünf Fragen vor der Auswahl einer Lösung

Wer eine Bibliothek, ein Plugin oder einen Webdienst zur E-Rechnungserstellung auswählt, sollte deshalb nicht nur nach den unterstützten Formaten fragen:

1. Was wird geprüft? Nur das XML-Schema oder auch die Geschäftsregeln von EN 16931 und XRechnung einschließlich Codelisten – und bei ZUGFeRD zusätzlich das PDF/A-3?
2. Welches Profil und welche Regelversion? Mit welcher Version der Prüfregeln wird validiert, und wer hält sie aktuell?
3. Wie werden Ergebnisse zurückgegeben? Kommen Fehler und Warnungen verständlich bei der aufrufenden Anwendung an?
4. Was passiert bei einem Fehler? Verhindert ein Validierungsfehler tatsächlich die Ausgabe beziehungsweise den Versand?
5. Welche Geschäftsfälle sind getestet? Funktionieren Gutschriften, mehrere Steuersätze, Steuerbefreiungen, Ausland, Zu- und Abschläge und Rundungen – oder nur die Standardrechnung mit 19 %?

Fazit

Bei E-Rechnungen sollte man Generator und Validator nicht miteinander verwechseln.

Eine Software kann technisch problemlos XML erzeugen und trotzdem ungültige E-Rechnungen produzieren. Fehlt eine integrierte Validierung, wird der Empfänger im schlimmsten Fall zum unfreiwilligen Tester der eigenen Rechnungssoftware.

Das ist nicht nur unangenehm. Bei automatisierten Rechnungseingängen kann eine fehlerhafte Rechnung abgewiesen werden und muss korrigiert und erneut übermittelt werden.

Und die Vorstellung, man könne die Qualität einer E-Rechnungslösung anhand einiger einfacher Musterrechnungen beurteilen, geht an der betrieblichen Realität vorbei. Kaum ein Kunde schreibt ausschließlich Rechnungen mit einem einzigen Steuersatz, ausschließlich im Inland und ohne Gutschriften, Nachlässe oder andere steuerliche Konstellationen.

Wer eine Lösung zur E-Rechnungserstellung bewertet, sollte daher nicht zuerst fragen, ob sie XML erzeugen kann. Die wichtigere Frage ist: