Elektronische Rechnungen in FileMaker mit dem MBS Plugin lokal erzeugen

E-Rechnungen selbst erzeugen, empfangen, prüfen und visualisieren

Die E-Rechnung ist inzwischen mehr als ein PDF, das per E-Mail verschickt wird. Eine echte E-Rechnung enthält strukturierte Daten, die von Software automatisch verarbeitet werden können.

Für Unternehmen, die ihre Geschäftsprozesse mit FileMaker abbilden, stellt sich deshalb eine interessante Frage:

Warum sollte die E-Rechnung außerhalb der eigenen FileMaker-Lösung verarbeitet werden?

Mit dem MBS FileMaker Plugin lassen sich wesentliche Teile des kompletten E-Rechnungsprozesses direkt in FileMaker umsetzen:

XML erzeugen
XML aus eingehenden Rechnungen auslesen
XSD-Strukturen prüfen
Geschäftsregeln mit Saxon und XSLT prüfen
E-Rechnungen visualisieren
ZUGFeRD-/Factur-X-PDFs erzeugen
XML in PDF/A-3 einbetten
fertige Rechnungen erneut validieren
Originaldaten für die Aufbewahrung in FileMaker archivieren

Und das alles lokal, ohne dass die Rechnungsdaten für die Validierung an einen externen Web Service übertragen werden müssen.

Was ist eine E-Rechnung?

Seit dem 1. Januar 2025 unterscheidet das Umsatzsteuergesetz zwischen einer E-Rechnung und einer sonstigen Rechnung.

Eine E-Rechnung ist eine Rechnung, die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht. Ein normales PDF ist deshalb nicht automatisch eine E-Rechnung.

In Deutschland spielen insbesondere zwei Formate eine wichtige Rolle:

XRechnung
ZUGFeRD / Factur-X

ZUGFeRD beziehungsweise Factur-X kombiniert dabei eine visuelle PDF-Darstellung mit strukturierten XML-Rechnungsdaten.

XRechnung dagegen ist primär eine strukturierte Rechnung. Als Syntax kommen insbesondere CII und UBL zum Einsatz.

Die europäische Norm EN 16931 beschreibt das fachliche Rechnungsmodell. Die eigentlichen XML-Syntaxen sind davon zu unterscheiden.

Das ist für die technische Umsetzung wichtig: Eine E-Rechnung zu erzeugen bedeutet nicht einfach, ein paar XML-Tags zu schreiben. Die XML-Struktur, die Geschäftsregeln und die verwendeten Codelisten müssen zusammenpassen.

E-Rechnung direkt in FileMaker

Genau hier spielt eine FileMaker-Lösung ihre Stärke aus.

Die Daten sind bereits vorhanden:

Rechnung
Kunde
Adresse
Rechnungspositionen
Mengen
Preise
Steuersätze
Zahlungsbedingungen
Bankverbindung
Umsatzsteuer-ID
Rechnungsnummer
Leistungsdatum

Die E-Rechnung ist deshalb kein separates System. Sie ist eine weitere Darstellung beziehungsweise ein weiteres Austauschformat für dieselben Geschäftsdaten.

Mit dem MBS FileMaker Plugin können diese Daten als XML aufgebaut und anschließend mit den passenden Validierungsregeln geprüft werden.

Drei Stufen der Validierung

Bei E-Rechnungen sollte man drei verschiedene Arten der Prüfung auseinanderhalten.

1. Ist das XML überhaupt korrekt?

Zunächst muss das Dokument syntaktisch korrektes XML sein.

Das klingt trivial, ist aber die Grundlage für alle weiteren Schritte.

XML kann beispielsweise durch falsche Namespaces, nicht geschlossene Elemente oder ungültige Zeichen unbrauchbar werden.

2. Entspricht die XML-Struktur dem XSD?

Das ist die klassische Schema-Validierung.

Hier wird beispielsweise geprüft:

Welche Elemente sind erlaubt?
Welche Elemente sind Pflicht?
In welcher Reihenfolge müssen Elemente auftreten?
Welche Datentypen sind erlaubt?
Welche Attribute sind zulässig?
Welche Namespaces müssen verwendet werden?

Mit dem MBS Plugin lässt sich dafür beispielsweise XML.Validate verwenden. Die Funktion validiert XML gegen ein XSD und kann bei Fehlern eine Liste der gefundenen Probleme zurückgeben. Auch referenzierte XSD-Dateien können über das Arbeitsverzeichnis aufgelöst werden.

Ein vereinfachtes Beispiel sieht so aus:

Set Variable [

$result ;

Value: MBS (

"XML.Validate" ;

$XML ;

$Schema ;

)

]

Die XSD-Dateien können dabei zusammen mit den zugehörigen Dateien lokal in einem Verzeichnis abgelegt werden.

Das ist insbesondere für E-Rechnungen interessant, da die jeweiligen Standards oft aus mehreren miteinander verbundenen Schema-Dateien bestehen.

XSD und Business Rules sind nicht dasselbe

Eine Rechnung kann ein gültiges XML-Dokument sein und sogar die XSD-Struktur erfüllen – und trotzdem fachlich falsch sein.

Ein einfaches Beispiel:

Netto: 1.000,00 €

Umsatzsteuer: 190,00 €

Gesamt: 1.150,00 €

Die XML-Struktur könnte vollkommen korrekt sein, die Zahlen sind trotzdem falsch.

Solche Prüfungen sind keine reine XSD-Aufgabe. Hier kommen die Business Rules ins Spiel.

Genau dafür werden bei EN 16931 unter anderem Schematron-Regeln und daraus erzeugte XSLT-Stylesheets verwendet. Die offiziellen EN-16931-Validierungsartefakte werden getrennt für UBL und CII bereitgestellt und enthalten sowohl Schematron als auch vorverarbeitete beziehungsweise kompilierte XSLT-Varianten.

Saxon für XSLT, XSD und XPath

Für die anspruchsvolleren XML-Aufgaben kann das MBS Plugin die Saxon-Bibliothek verwenden.

Saxon unterstützt unter anderem:

XSLT 3.0
XQuery 3.1
XPath 3.1
XSD 1.1

Das MBS FileMaker Plugin stellt dafür Funktionen wie Saxon.Validate, Saxon.XPathQuery, Saxon.XQuery und Saxon.XSLT bereit.

Damit lässt sich beispielsweise ein Validierungsablauf aufbauen:

E-Rechnung.xml -> XSD-Prüfung -> Schematron/XSLT -> Business Rules -> Validierungsbericht

Eine XSLT-Transformation kann im MBS FileMaker Plugin beispielsweise über Saxon.XSLT ausgeführt werden:

Set Variable [

$result ;

Value: MBS (

"Saxon.XSLT" ;

$XML ;

$XSLT

)

]

Das Ergebnis kann wiederum XML, HTML oder – abhängig vom verwendeten Stylesheet – ein anderes Ausgabeformat sein.

Damit ist Saxon nicht nur ein Validator. Es ist gleichzeitig ein leistungsfähiger Transformationsbaustein.

Verschiedene Standards brauchen verschiedene Validierungsdateien

Ein wichtiger Punkt bei einer produktiven Lösung ist die Versionierung der Validierungsartefakte.

Es gibt nicht das eine XSD und das eine XSLT für alle E-Rechnungen.

Je nach Format und Version benötigt man beispielsweise unterschiedliche:

XSD-Dateien
Schematron-Dateien
XSLT-Dateien
Codelisten
Transformationsdateien

Auch CII und UBL haben unterschiedliche XML-Strukturen.

Die offiziellen EN-16931-Validierungsartefakte führen deshalb beispielsweise getrennte Verzeichnisse für ubl und cii. Die aktuelle veröffentlichte Version 1.3.16 stammt vom April 2026.

Auch bei ZUGFeRD gibt es verschiedene Versionen und Profile. Seit August 2026 ist ZUGFeRD 2.5.2 veröffentlicht. Das Korrigendum korrigiert unter anderem Inkonsistenzen aus der vorherigen Version.

Bei XRechnung ist aktuell die Version 3.0 in Kraft; das technische Bundle liegt in der Fassung 3.0.2 vom 31. August 2026. Das Bugfix-Release vom September 2026 enthält unter anderem den Validator 1.6.3 und aktualisierte technische Komponenten, ohne den normativen XRechnung-Standard zu ändern.

Für eine FileMaker-Lösung bedeutet das:

Validierungsdateien sollten nicht einfach irgendwo auf dem Rechner liegen. Sie sollten versioniert und eindeutig einer Formatversion zugeordnet werden.

Zum Beispiel speichert man ZUGFeRD in der Version 2.5.2 mit den jeweiligen XSD, Schematron und Codelisten.

Das macht spätere Updates wesentlich einfacher.

Codelisten gehören ebenfalls zur Validierung

Bei einer E-Rechnung gibt es neben XML-Schema und Business Rules noch einen weiteren wichtigen Baustein: Codelisten.

Dazu gehören beispielsweise Codes für:

Länder
Währungen
Steuerkategorien
Zahlungsarten
Einheiten
Identifier-Schemata
elektronische Adressierung

Die EN-16931-Validierungsartefakte berücksichtigen entsprechende Codelisten. Auch diese können sich ändern.

Eine gute FileMaker-Lösung speichert deshalb nicht nur: „Rechnung ist gültig.“

Sondern beispielsweise einen Datensatz mit:

Validierung: OK

Format: XRechnung

Version: 3.0

Syntax: UBL

XSD: OK

Business Rules: OK

Codelisten: OK

Validator-Version: 1.6.3

Zeitpunkt: 12.09.2026 09:15

Bei einem Fehler kann dagegen der konkrete Regelverstoß gespeichert werden.

So wird aus einer einfachen XML-Prüfung ein nachvollziehbarer Geschäftsprozess.

E-Rechnung visualisieren

XML ist hervorragend für Maschinen, aber nicht unbedingt angenehm für Menschen.

Eine XRechnung kann beispielsweise hunderte XML-Elemente enthalten. Niemand möchte eine solche Datei manuell lesen.

Dafür gibt es das XRechnung Visualization-Projekt von KoSIT.

Die bereitgestellten XSL-Transformationen können sowohl UBL- als auch CII-Rechnungen verarbeiten. In einem ersten Schritt wird das XML in ein Zwischenformat transformiert. Anschließend kann daraus beispielsweise HTML oder PDF erzeugt werden.

Die aktuelle Visualisierungsversion 2026-01-31 ist mit XRechnung 3.0.x kompatibel und verwendet Saxon 12.8.

Das passt hervorragend zu FileMaker:

E-Rechnung.xml -> Saxon.XSLT -> Zwischen XML -> Saxon.XSLT -> HTML

Das HTML kann beispielsweise in einem FileMaker Web Viewer dargestellt werden.

Damit kann der Benutzer eine E-Rechnung komfortabel ansehen, obwohl die Originaldaten weiterhin als XML vorliegen.

Wichtig ist dabei: Die Visualisierung ist nicht die Originalrechnung. Bei einer XRechnung ist der strukturierte XML-Teil das maßgebliche Original und muss entsprechend aufbewahrt werden. Die Visualisierung dient der menschlichen Lesbarkeit.

Was ist bei ZUGFeRD und Factur-X anders?

ZUGFeRD beziehungsweise Factur-X verbindet zwei Welten:

PDF + eingebettetes XML = hybride E-Rechnung

Das PDF kann der Mensch lesen.

Das XML kann die Software verarbeiten.

Bei ZUGFeRD 2.1 und höher wird für die eingebettete Rechnung factur-x.xml verwendet; auch ZUGFeRD und Factur-X sind auf PDF-Ebene ab ZUGFeRD 2.1 entsprechend definiert. DynaPDF unterstützt die notwendigen Funktionen zum Einbetten und Verknüpfen der XML-Datei.

Damit kann FileMaker beispielsweise eine Rechnung erzeugen und anschließend daraus eine ZUGFeRD-/Factur-X-Rechnung machen.

Eingehende ZUGFeRD-Rechnung aus einem PDF auslesen

Auch der umgekehrte Weg ist interessant.

Ein Lieferant schickt eine ZUGFeRD-Rechnung als PDF.

Der Benutzer sieht ein normales PDF, im Inneren steckt aber zusätzlich das strukturierte XML.

Mit DynaPDF und dem MBS Plugin kann dieses XML aus dem PDF ausgelesen werden.

Der Prozess sieht dann so aus:

PDF empfangen
XML extrahieren mit DynaPDF
Validieren mit XSD und Business Rules
Rechnungsdaten in Datensätze übernehmen

Das MBS Plugin stellt dafür unter anderem Funktionen zum Zugriff auf eingebettete Dateien bereit. Es gibt auch fertige MBS-Beispiele speziell für ZUGFeRD und Factur-X. Damit kann eine eingehende Rechnung automatisiert in den FileMaker-Prozess übernommen werden.

Eingangsrechnung: nicht nur importieren, sondern prüfen

Das ist ein entscheidender Unterschied zwischen einer Demo und einer produktiven Lösung.

Eine eingehende Rechnung sollte nicht einfach blind in FileMaker importiert werden.

Ein sinnvoller Prozess ist:

Rechnung empfangen
Dateityp erkennen PDF oder XML
Bei PDF das XML extrahieren
XML prüfen
Ergebnis der Validierung speichern
Daten in FileMaker prüfen und speichern

In FileMaker eigene Prüfungen durchführen:

Existiert der Lieferant?
Passt die Lieferantennummer?
Ist die Bestellung vorhanden?
Stimmen die Rechnungspositionen?
Ist die Rechnung bereits vorhanden?
Sind Mengen und Preise plausibel?
Ist die Rechnung freigegeben?
Stimmen Bankverbindung und Zahlungsbedingungen?

Hier geht die E-Rechnungsvalidierung direkt in die normale Geschäftslogik von FileMaker über.

Und was sagt das Gesetz zur Prüfung?

Hier ist eine wichtige Unterscheidung notwendig.

Es besteht keine allgemeine gesetzliche Pflicht, jede E-Rechnung mit einem bestimmten technischen Validator gegen XSD und Schematron zu prüfen.

Das Bundesministerium der Finanzen stellt ausdrücklich fest, dass eine technische Validierung keine unmittelbare Voraussetzung für die steuerliche Anerkennung einer E-Rechnung ist. Gleichzeitig empfiehlt das BMF eine Validierung, insbesondere bereits bei Erstellung und Versand, weil damit fehlende oder unlogische Pflichtangaben erkannt werden können.

Das bedeutet aber nicht, dass Rechnungen rechtlich ungeprüft bleiben können.

Für Ausgangsrechnungen bestehen gesetzliche Anforderungen an Inhalt und Ausstellung. Außerdem müssen Echtheit der Herkunft, Unversehrtheit des Inhalts und Lesbarkeit gewährleistet werden. § 14 UStG nennt dafür ausdrücklich innerbetriebliche Kontrollverfahren als mögliche Lösung.

Bei Eingangsrechnungen ist unter anderem der Vorsteuerabzug relevant: Nach § 15 UStG setzt der Vorsteuerabzug grundsätzlich voraus, dass der Unternehmer eine nach den gesetzlichen Anforderungen ausgestellte Rechnung besitzt.

Die praktische Konsequenz lautet daher:

Die technische XSD-/Schematron-Validierung ist nicht selbst die gesetzliche Pflicht. Sie ist ein sehr geeignetes Werkzeug, um die gesetzlichen Anforderungen zuverlässig und automatisiert zu unterstützen.

Gerade bei einer FileMaker-Lösung lässt sich diese Prüfung mit der eigentlichen fachlichen Rechnungsprüfung verbinden.

Ausgangsrechnung: XML direkt aus FileMaker erzeugen

Bei einer Ausgangsrechnung liegt der Vorteil noch deutlicher auf der Hand. Die Daten befinden sich bereits in FileMaker.

Aus diesen Daten kann das XML direkt erzeugt werden.

Die XML-Funktionen des MBS Plugins bieten dafür zahlreiche Möglichkeiten, beispielsweise:

XML-Strukturen erstellen
Elemente setzen
Attribute setzen
XML-Unterstrukturen einfügen
XPath-Abfragen durchführen
XML formatieren
XML als Datei speichern

Die XML-Komponente des MBS FileMaker Plugin umfasst unter anderem Funktionen wie XML.Parse, XML.Query, XML.SetPathValue, XML.SetPathXML und XML.Validate.

Ein typischer Ablauf könnte so aussehen:

Rechnung Datensatz in FileMaker erzeugen
Rechnung als PDF ausgeben
Passendes XML aufbauen
Per XSD Schema validieren
Eventuell mit Business Rules validieren
Mit DynaPDF aus XML und PDF ein ZUGFeRD PDF erzeugen.

Der große Vorteil: Es gibt keinen Medienbruch zwischen Rechnung und E-Rechnung.

Erst validieren, dann PDF/A-3 erzeugen

Bei einer ZUGFeRD-/Factur-X-Rechnung wird anschließend das XML mit dem PDF verbunden.

DynaPDF kann dafür die benötigten PDF-Funktionen bereitstellen.

Je nach Aufbau der Lösung gibt es zwei interessante Varianten.

Variante 1: PDF komplett mit DynaPDF erzeugen

Das PDF wird direkt mit DynaPDF erzeugt und anschließend als PDF/A ausgegeben.

Dafür ist die Lite-Variante ausreichen, wenn das PDF vollständig mit DynaPDF erzeugt wird und kein vorhandenes PDF als Vorlage importiert werden muss.

Variante 2: FileMaker erzeugt das PDF

FileMaker erzeugt zunächst das normale Rechnungs-PDF.

Danach wird das PDF in DynaPDF geöffnet, als PDF/A verarbeitet und mit dem XML verbunden.

Für diesen Weg nennt MBS DynaPDF Pro zusammen mit der PDF/A-Erweiterung, da FileMaker selbst kein PDF/A erzeugt.

Die fertige Datei nochmals prüfen

Ein besonders schöner Schritt ist die abschließende Prüfung.

Warum sollte man das fertige Dokument nicht noch einmal öffnen?

Damit wird nicht nur das XML geprüft, das irgendwann einmal erzeugt wurde. Geprüft wird die tatsächlich versendete Datei.

Das ist insbesondere bei automatisierten Rechnungsprozessen eine sehr interessante zusätzliche Sicherheitsstufe.

Und das Ergebnis der Validierung kann ebenfalls gespeichert werden wie bei einer Eingangsrechnung.

Archivierung: Das XML darf nicht verloren gehen

Bei der E-Rechnung ist die Aufbewahrung besonders wichtig.

§ 14b UStG schreibt grundsätzlich eine Aufbewahrungsfrist von acht Jahren für Rechnungen vor.

Bei E-Rechnungen muss zumindest der strukturierte Teil so aufbewahrt werden, dass er in seiner ursprünglichen Form erhalten bleibt und die Anforderungen an die Unversehrtheit erfüllt. Das BMF hebt diesen Punkt in seinen aktuellen FAQ ausdrücklich hervor.

Für eine FileMaker-Lösung bedeutet das:

Das XML sollte nicht nur aus den einzelnen Rechnungsfeldern jederzeit neu erzeugt werden können. Das ursprüngliche XML sollte tatsächlich aufbewahrt werden.

Bei einer ZUGFeRD-/Factur-X-Rechnung empfiehlt sich entsprechend die Aufbewahrung der vollständigen Originaldatei und des strukturierten Rechnungsinhalts.

In FileMaker können beispielsweise gespeichert werden:

Original PDF
Original XML
Format und Version
Profil
Validatorversion
Validierungsergebnis / Validierungsbericht
Eingangs-/Ausgangsdatum
Verarbeitungsstatus

So entsteht gleichzeitig ein nachvollziehbarer Prüfpfad.

Lokal statt Cloud-Validator

Ein großer Vorteil dieser Architektur ist die lokale Verarbeitung.

Für die XML-Erzeugung, Validierung und Visualisierung muss die Rechnung nicht an einen externen Dienst geschickt werden.

Das bedeutet:

keine Uploads von Rechnungsdaten an einen Validator
kein API-Key
keine Token
keine Gebühr pro Rechnung
keine Gebühr pro Validierung
keine monatliche Abrechnung für einen Validierungsdienst
keine Abhängigkeit von der Verfügbarkeit eines externen Web Services
kein Weitereichen der Daten an eine andere Firma bzw. ein anderes Land mit Rechnungzentrum.

Die benötigten XSD-, Schematron-, XSLT- und Codelisten-Dateien können lokal in der Anwendung beziehungsweise auf dem FileMaker Server vorgehalten werden.

Natürlich ist das etwas anderes als der spätere Transport der Rechnung. Eine E-Rechnung kann beispielsweise per E-Mail, über ein Portal oder über andere elektronische Übertragungswege versendet werden. Das BMF schreibt keinen bestimmten Übertragungsweg vor; seit 1. Januar 2025 muss ein Unternehmen allerdings den Empfang von E-Rechnungen sicherstellen.

Perpetual Lizenzen statt Abrechnung pro Rechnung

Auch beim Lizenzmodell gibt es einen wichtigen Unterschied zu vielen Cloud-E-Rechnungsdiensten.

Die MBS FileMaker Plugin Lizenzen sind perpetual. Ein Update nach Ablauf der enthaltenen Updateperiode ist nicht erforderlich, um die bereits erworbene Version weiter zu verwenden. Updates können separat erworben werden.

Das gilt auch für DynaPDF und Saxon Lizenzen. Die vorhandenen Bibliotheken laufen mit der Lizenz dauerhaft weiter.

FileMaker Server: E-Rechnung auch automatisiert verarbeiten

Die Lösung muss nicht auf dem Arbeitsplatzrechner laufen. Die relevanten XML-Funktionen des MBS Plugins stehen auch für FileMaker Server zur Verfügung.

Auch Ausgangsrechnungen können automatisiert erzeugt, validiert, als PDF/A-3 verpackt und anschließend abgelegt oder versendet werden.

Das ganze kann via Perform Script on Server von allen Arbeitsplätzen gestartet werden. Die relevanten XML Dateien mit Codelisten und Schemas können zentral auf dem Server in einem Ordner liegen.

Was ist mit Peppol?

Peppol ist dabei eine andere Ebene.

ZUGFeRD, Factur-X, XRechnung, CII und UBL beschreiben das Format beziehungsweise die strukturierten Rechnungsdaten.

Peppol beschreibt dagegen einen standardisierten Übertragungsweg beziehungsweise ein Netzwerk für den elektronischen Dokumentenaustausch.

Die FileMaker-Lösung kann also die E-Rechnung erzeugen und prüfen, ohne selbst der Übertragungsdienst sein zu müssen.

Das ist eine wichtige Architekturentscheidung:

FileMaker kümmert sich um die Daten und das Dokument. Der Transport kann unabhängig davon erfolgen.

Dadurch bleibt die eigentliche E-Rechnungslogik unabhängig vom später gewählten Übertragungsweg.

Zukunftssicher durch austauschbare Validierungsartefakte

Ein großer Vorteil dieser Architektur ist ihre Flexibilität.

Die Geschäftslogik in FileMaker muss nicht für jede neue Version eines Standards komplett neu geschrieben werden.

Stattdessen können viele Änderungen über neue Artefakte abgebildet werden. Die XML, Schema und XLST Dateien können jederzeit aktualisiert werden für eine neue Version.

Das ist besonders interessant, weil sich die europäischen E-Rechnungsstandards weiterentwickeln.

Die EU hat mit VAT in the Digital Age (ViDA) bereits den nächsten großen Schritt beschlossen. Das Paket wird schrittweise bis 2035 umgesetzt. Für grenzüberschreitende B2B-Umsätze beginnen neue Digital Reporting Requirements auf Basis elektronischer Rechnungen ab dem 1. Juli 2030.

Eine lokale XML-Architektur ist deshalb nicht nur für die heutigen Anforderungen interessant.

Sie schafft eine Grundlage, auf der sich zukünftige Formate und Regeln integrieren lassen.

Wenn es soweit ist, können wir dann mit den CURL Funktionen das XML zu einem Webservice hochladen.

Fazit

E-Rechnung muss kein externes Cloud-Projekt sein.

Mit FileMaker und dem MBS Plugin lässt sich ein großer Teil des gesamten Prozesses direkt in der eigenen Anwendung abbilden:

Rechnungsdaten liegen bereits in FileMaker vor.
XML kann direkt aus FileMaker erzeugt werden.
Mit XML.Validate kann die Struktur gegen XSD geprüft werden.
Saxon kann XSD, XPath und XSLT übernehmen.
Schematron-Regeln können als XSLT verarbeitet werden.
Business Rules können automatisiert geprüft werden.
Codelisten und Validierungsartefakte können versioniert lokal vorgehalten werden.
ZUGFeRD-/Factur-X-PDFs können mit DynaPDF erzeugt werden.
Eingebettetes XML kann aus eingehenden PDFs wieder ausgelesen werden.
XRechnungen und andere XML-Rechnungen können mit XSLT visualisiert werden.
Die fertige Rechnung kann nochmals validiert werden.
Original-XML und Original-PDF können zusammen mit dem Prüfbericht archiviert werden.

Das Entscheidende dabei ist die lokale Verarbeitung.

Es braucht für die eigentliche E-Rechnungsverarbeitung keinen externen Validierungs-Webservice. Es gibt keine Gebühren pro Rechnung und keine Tokenabrechnung. Die Lösung kann auf dem Arbeitsplatz oder auf FileMaker Server laufen und lässt sich direkt mit den vorhandenen Geschäftsprozessen verbinden.

Damit wird die E-Rechnung nicht zu einem zusätzlichen Fremdsystem.

Sie wird einfach ein weiterer, automatisierter Bestandteil der FileMaker-Lösung.

Technische Bausteine auf einen Blick

Aufgabe	Mögliche Lösung
XML erzeugen	MBS XML-Funktionen
XML lesen	MBS XML-Funktionen
XML/XSD prüfen	XML.Validate / XML.ValidateFile
Erweiterte Validierung	Saxon
XSD 1.1	Saxon
XPath / XQuery	Saxon
Business Rules	Schematron + XSLT + Saxon
Codelisten	lokale Validierungsartefakte
XML aus PDF lesen	DynaPDF
XML in PDF einbetten	DynaPDF
PDF/A	DynaPDF bzw. PDF/A-Erweiterung
E-Rechnung visualisieren	XSLT + Saxon / XRechnung Visualization
Speicherung	FileMaker + Originaldateien
Automatisierung	FileMaker Scripts / FileMaker Server
Externer Validator	nicht erforderlich
Abrechnung pro Rechnung	nicht erforderlich
API-/Tokenkosten	nicht erforderlich

Hinweis: E-Rechnungsstandards, technische Bundles und gesetzliche Anforderungen ändern sich. Vor einer produktiven Einführung sollten deshalb immer die zum Einsatzzeitpunkt aktuellen Spezifikationen und die individuelle steuerliche Situation geprüft werden.

Wir machen keine Steuer- oder Rechtsberatung. Bitte Fragen Sie zu steuerlichen Angelegenheiten ihren Steuerberater.

Dieser Artikel wurde mit Hilfe von KI überarbeitet und von Menschen editiert.