E-Rechnung in FileMaker: Plugin, Open Source oder Webdienst?
FileMaker kann die kaufmännischen Daten einer Rechnung sehr gut verwalten. Für Validierung, XML-Ausgabe und hybride PDF/A-3-Rechnungen braucht eine produktive Lösung jedoch immer eine zusätzliche technische Komponente.
In meinem Beitrag „FileMaker & E-Rechnung – ein technischer Hindernislauf“ habe ich die technische Ausgangslage beschrieben: FileMaker bringt weder eine vollständige Validierungsumgebung für E-Rechnungen noch die erforderlichen Funktionen zur Erzeugung hybrider PDF/A-3-Rechnungen mit.
Die entscheidende Frage lautet nicht, ob etwas ergänzt werden muss – sondern wie diese Ergänzung angebunden und betrieben wird.
In der Praxis werden meist drei Möglichkeiten genannt: ein FileMaker-Plugin, eine Open-Source-Lösung wie Mustangproject oder ein Webdienst. Diese Begriffe stehen allerdings nicht ganz auf derselben Ebene.
Plugin, Webdienst und Open Source sind nicht dasselbe
Ein Plugin beschreibt die technische Einbindung: Zusätzlicher Programmcode wird direkt von FileMaker geladen und stellt neue Funktionen oder Scriptschritte bereit.
Ein Webdienst beschreibt eine Systemgrenze: FileMaker sendet Daten über eine definierte Schnittstelle an einen anderen Prozess und erhält das Ergebnis zurück.
Open Source beschreibt dagegen zunächst nur, unter welchen Bedingungen eine Software verfügbar ist. Mustangproject ist eine Java-Bibliothek, ein Kommandozeilenprogramm und ein Validator. Es kann lokal auf einem eigenen Server laufen – oder die technische Grundlage eines Webdienstes bilden.
Mustang und Webdienst sind deshalb keine Gegensätze. Ein Webdienst kann vollständig auf Open-Source-Komponenten beruhen. Umgekehrt wird Mustang für FileMaker meist erst dann gut nutzbar, wenn man eine Schnittstelle darum baut.
Das Plugin: nah an FileMaker, aber auch nah am Betriebssystem
Ein Plugin wirkt aus Sicht der FileMaker-Entwicklung zunächst besonders bequem. Die zusätzlichen Funktionen erscheinen direkt in Berechnungen oder Scriptschritten. Dateien können aus Containerfeldern gelesen, verarbeitet und wieder zurückgeschrieben werden.
Ein bekanntes Beispiel ist die Kombination aus dem MBS FileMaker Plugin und DynaPDF. Damit lassen sich XML-Dateien in PDF-Dokumente einbetten, eingebettete Dateien wieder auslesen und PDF-Dokumente für PDF/A beziehungsweise ZUGFeRD aufbereiten. Ein aus einem FileMaker-Layout erzeugtes PDF kann damit lokal weiterverarbeitet werden.
Der große Vorteil liegt auf der Hand: Die Rechnungsdaten müssen das eigene System nicht verlassen. Die Verarbeitung kann auch ohne Internetverbindung funktionieren, und der gesamte Ablauf bleibt eng mit den FileMaker-Skripten verbunden.
Der Nachteil liegt in der lokalen Abhängigkeit: Das Plugin muss auf den jeweiligen FileMaker-Systemen installiert und gepflegt werden. Je nach Betriebssystem und Ausführungsort sind unterschiedliche Komponenten erforderlich.
Hinzu kommt: Ein PDF-Plugin löst zunächst die PDF-Seite. Es kann ein PDF/A-3-Dokument erzeugen und das XML korrekt einbetten. Damit ist aber noch nicht automatisch geklärt, wie das XML fachlich erzeugt und vollständig gegen XSD-, Schematron- und Geschäftsregeln validiert wird. Das muss das gewählte Produkt ausdrücklich mitbringen oder durch weitere Komponenten ergänzt werden.
Ein Plugin passt besonders gut, wenn …
- Rechnungsdaten das eigene Netz nicht verlassen dürfen,
- die Verarbeitung auch ohne Netzwerkverbindung funktionieren muss,
- bereits eine gepflegte Plugin-Infrastruktur vorhanden ist,
- ausschließlich klar definierte FileMaker- und Betriebssystemumgebungen unterstützt werden müssen.
Weniger attraktiv wird dieser Weg, wenn zahlreiche Kundeninstallationen, verschiedene Plattformen oder FileMaker Cloud versorgt werden sollen. Dann wird die Verteilung und Pflege der lokalen Komponenten schnell zum eigentlichen Projekt.
Mustangproject: leistungsfähige Open Source, aber kein FileMaker-Baustein
Mustangproject ist ein umfangreicher Open-Source-Werkzeugkasten für elektronische Rechnungen. Das Projekt stellt eine Java-Bibliothek, ein Kommandozeilenprogramm und einen Validator bereit. Es kann ZUGFeRD- beziehungsweise Factur-X-Dokumente lesen, schreiben und validieren und unterstützt außerdem XRechnung. Der Validator verbindet unter anderem PDF/A-Prüfung, XML-Schema und Schematron-Regeln.
Die Software steht unter der freizügigen Apache-2.0-Lizenz und kann damit grundsätzlich auch in kommerziellen Projekten eingesetzt werden. Das macht Mustang für eine eigene technische Plattform sehr interessant.
Für FileMaker ist Mustang jedoch keine unmittelbar verwendbare Erweiterung. FileMaker kann eine Java-Bibliothek nicht direkt laden und besitzt keinen nativen Scriptschritt, der aus einer JAR-Datei plötzlich eine FileMaker-Funktion macht. Zwischen FileMaker und Mustang wird daher eine zusätzliche Integrationsschicht benötigt.
Mustangproject bietet keine direkte Einbindung von aus FileMaker erzeugten PDF-Dateien. Für die Erzeugung einer hybriden ZUGFeRD-Rechnung ist daher eine zusätzliche Verarbeitungsschicht erforderlich, die das FileMaker-PDF übernimmt und mit den Rechnungsdaten zu einem PDF/A-3-Dokument zusammenführt.
Man kann Mustang über ein Kommandozeilenprogramm aufrufen, dafür ein Shell-Plugin einsetzen oder einen separaten Prozess entwickeln. Die sauberste Lösung ist häufig ein kleiner lokaler HTTP-Dienst: FileMaker sendet JSON an diesen Dienst, der Mustang aufruft und XML, PDF oder Validierungsergebnis zurückliefert.
„Open Source statt Webdienst“ läuft in vielen Fällen auf einen selbst betriebenen Webdienst mit Open-Source-Komponenten hinaus.
Der Quellcode ist kostenlos verfügbar. Der produktive Betrieb ist es nicht. Jemand muss die Java-Laufzeit, Bibliotheken, Validierungsartefakte und Abhängigkeiten aktualisieren. Hinzu kommen Prozessüberwachung, Protokollierung, Zeitüberschreitungen, Fehlerbehandlung, Tests, Zugriffsschutz und die Gestaltung einer stabilen Schnittstelle.
Mustang passt besonders gut, wenn …
- die gesamte Verarbeitung im eigenen Netz bleiben soll,
- eigenes Java- und Server-Know-how vorhanden ist,
- besondere Anforderungen eine individuelle Erweiterung notwendig machen,
- Quellcodezugriff und langfristige technische Kontrolle wichtiger sind als ein geringer Betriebsaufwand.
Mustang ist damit eine ausgezeichnete Grundlage für eine eigene E-Rechnungsplattform. Es ist aber keine fertige FileMaker-Integration.
Der Webdienst: eine klare Grenze zwischen Fachlichkeit und Format
Bei einem Webdienst behält FileMaker die Verwaltung der kaufmännischen Daten: Kunden, Aufträge, Positionen, Preise, Steuern, Zahlungsbedingungen und Belegbeziehungen.
Ein entsprechend ausgestatteter Dienst übernimmt die formatspezifische Arbeit. FileMaker sendet die Rechnungsdaten als JSON. Der Dienst erzeugt daraus CII oder UBL, führt die vorgesehenen Prüfungen aus, erstellt bei Bedarf ein PDF/A-3-Dokument, bettet die XML-Datei ein und liefert das Ergebnis zurück.
Die Anbindung nutzt Funktionen, die in den verschiedenen FileMaker-Ausführungsumgebungen zur Verfügung stehen: Die JSON-Funktionen bilden hierarchische Daten ab, und HTTPS-Aufrufe lassen sich mit „Aus URL einfügen“ und cURL-Optionen ausführen. Dieser Scriptschritt steht in FileMaker Pro, FileMaker Go, WebDirect, FileMaker Server und FileMaker Cloud zur Verfügung.
FileMaker muss dadurch keine XML-Namespaces, Schema-Reihenfolgen oder PDF-Metadaten beherrschen. Die Datenbank beschreibt den Geschäftsvorfall; der Dienst übersetzt ihn in das jeweils verlangte technische Format.
Ein charakteristisches Merkmal des Webdienstes ist die zentrale Pflege. Ändern sich Codelisten, Schemata oder Validierungsregeln, wird der Dienst einmal zentral aktualisiert. Die FileMaker-Lösung muss nur angepasst werden, wenn sich die vereinbarte Schnittstelle oder die fachlichen Anforderungen ändern.
Dass diese Pflege keine theoretische Aufgabe ist, zeigen die Veröffentlichungszyklen: Das ZUGFeRD-Paket 2.5.2 stammt vom 4. August 2026. Auch für XRechnung werden neben den eigentlichen Spezifikationen regelmäßig neue technische Bundles und Validator-Konfigurationen veröffentlicht.
Ebenfalls charakteristisch ist die gebündelte Betriebserfahrung: Seltene Kombinationen aus Steuerarten, Anzahlungen, Abschlägen, Rundungen und Rechnungskorrekturen zeigen sich oft erst bei echten Rechnungen. Wird ein solcher Fall im Dienst korrigiert und als Regressionstest festgehalten, profitieren anschließend alle angeschlossenen Lösungen davon.
Ein Webdienst muss übrigens nicht zwingend als öffentliche Cloud-Lösung betrieben werden. Dieselbe Schnittstelle kann auch auf einem eigenen Server, in einem deutschen Rechenzentrum oder in einer getrennten Kundeninstanz laufen. Der eigentliche Architekturvorteil ist die klar definierte API-Grenze – nicht der geografische Standort des Prozesses.
Gegen den Webdienst sprechen reale Einwände
Bei einem extern betriebenen Dienst verlassen Rechnungsdaten das eigene System. Hosting-Standort, Auftragsverarbeitungsvertrag, Unterauftragnehmer, Verschlüsselung und Löschfristen müssen deshalb transparent geregelt sein.
Außerdem entstehen Abhängigkeiten von der Verfügbarkeit des Dienstes und vom Anbieter. Technische Ausfälle, Änderungen der Leistung oder das Ende eines Angebots müssen deshalb von Beginn an als reale Szenarien berücksichtigt werden.
Betriebssicherheit braucht einen Plan B – nicht zwingend Eigenbetrieb
Unabhängig davon, ob die E-Rechnung mit einem Plugin, einem eigenen Open-Source-Dienst oder einem externen Webdienst erzeugt wird: Betriebssicherheit entsteht nicht automatisch durch die Wahl der Architektur. Aus der Abhängigkeit von einem externen Dienst folgt daher nicht, dass möglichst alle Komponenten selbst entwickelt und im eigenen Unternehmen betrieben werden müssen.
Auch eine vollständig interne Lösung kann ausfallen. FileMaker Server, Betriebssystem, Hardware, Netzwerk oder selbst entwickelte Komponenten können Probleme verursachen. Vor allem aber muss eine solche Lösung dauerhaft gepflegt werden. E-Rechnungsstandards, Validierungsregeln, Bibliotheken, Betriebssysteme und Entwicklungsumgebungen verändern sich. Was heute funktioniert, muss deshalb auch in fünf oder zehn Jahren noch verstanden, getestet und weiterentwickelt werden können.
Damit entsteht eine weitere Abhängigkeit, die leicht übersehen wird: die Abhängigkeit vom eigenen Know-how. Wenn Entwicklung, Betrieb und Wissen über eine geschäftskritische Lösung bei einer einzigen Person liegen, ist auch diese Person ein Single Point of Failure. Eine intern betriebene Lösung ist daher nicht automatisch ausfallsicherer als ein externer Dienst.
Gerade deshalb lagern auch große Unternehmen spezialisierte technische Aufgaben an externe Anbieter aus. Ein Dienstleister, dessen Kerngeschäft der Betrieb einer bestimmten technischen Komponente ist, kann Updates, Überwachung, Fehleranalyse und Weiterentwicklung auf mehrere Mitarbeiter und viele Kunden verteilen. Das kann die Betriebssicherheit erhöhen und gleichzeitig den eigenen Betriebsaufwand reduzieren.
Umgekehrt darf daraus natürlich keine unkontrollierte Abhängigkeit von einem einzelnen Anbieter entstehen. Eine gute Architektur berücksichtigt deshalb von Anfang an den Ausfall einzelner Komponenten.
Für die E-Rechnung bedeutet das beispielsweise:
- Die kaufmännischen Rechnungsdaten bleiben vollständig in FileMaker.
- Erzeugte XML- und PDF-Dokumente werden dauerhaft im eigenen System archiviert.
- Fehlgeschlagene Aufträge können erneut ausgeführt werden.
- Die Schnittstelle zum Dienst ist klar definiert und dokumentiert.
- Für einen längerfristigen Ausfall sollte ein unabhängiger alternativer Weg zur Erzeugung valider E-Rechnungen vorhanden sein.
Der Fallback muss dabei nicht dieselbe technische Architektur verwenden. Fällt der primäre Webdienst aus, kann im Notfall beispielsweise ein anderer Dienst oder eine lokale Lösung aus denselben vorhandenen Rechnungsdaten eine E-Rechnung erzeugen.
Betriebssicherheit bedeutet deshalb nicht, möglichst viel selbst zu betreiben. Sie bedeutet, Single Points of Failure zu vermeiden – bei Technik, Anbietern und Menschen.
Nicht jedes technische System muss redundant vorhanden sein. Der geschäftskritische Prozess der Rechnungsstellung sollte es sein.
Die drei Wege im direkten Vergleich
| Kriterium | FileMaker-Plugin | Open Source wie Mustang | Webdienst |
|---|---|---|---|
| Anbindung | Funktionen und Scriptschritte direkt in FileMaker | Kommandozeile, Wrapper oder eigener lokaler Dienst | HTTPS und JSON |
| Lokale Installation | Plugin und häufig zusätzliche Bibliothek | Java-Laufzeit, Bibliotheken und eigener Prozess | Keine zusätzliche FileMaker-Komponente |
| FileMaker Cloud | Custom Plug-ins nicht verfügbar | Nur über einen separat erreichbaren Dienst | Direkt über HTTPS nutzbar |
| Offline-Betrieb | Möglich | Möglich | Nur bei lokalem oder internem Dienst |
| Daten bleiben im Haus | Ja | Ja | Abhängig vom Betriebsmodell |
| PDF/A-3 und Einbettung | Je nach Plugin sehr gut lösbar | Mit passenden Bibliotheken lösbar | Bestandteil des Dienstes |
| Vollständige Validierung | Muss ausdrücklich enthalten oder ergänzt werden | Mit Mustang-Validator gut abbildbar | Sollte verbindlicher Bestandteil der API sein |
| Updates | Auf den betroffenen Installationen | Zentral, aber in eigener Verantwortung | Zentral durch den Betreiber |
| Plattformabhängigkeit | Vergleichsweise hoch | Vom eigenen Betriebsmodell abhängig | Gering auf FileMaker-Seite |
| Anpassbarkeit | Abhängig vom Plugin-Anbieter | Sehr hoch | Abhängig von API und Vertrag |
| Betriebsverantwortung | Anwender und Integrator | Vollständig beim eigenen Betreiber | Überwiegend beim Dienstanbieter |
| Einführungsaufwand | Mittel | Hoch | Meist gering bis mittel |
Welcher Weg passt zu welchem Fall?
Keiner der drei Wege ist grundsätzlich überlegen. Welche Entscheidung sinnvoll ist, hängt von den Rahmenbedingungen des Projekts ab.
Ein Plugin ist nah an FileMaker und kommt ohne Netzwerkanbindung aus. Es ist eine Überlegung wert, wenn Rechnungsdaten das eigene Netz nicht verlassen dürfen, die Verarbeitung auch offline funktionieren muss und nur klar definierte FileMaker- und Betriebssystemumgebungen unterstützt werden müssen. Bei vielen verteilten Installationen, verschiedenen Plattformen oder FileMaker Cloud wird die Verteilung und Pflege der lokalen Komponenten jedoch zum eigenen Projekt.
Mustangproject ist eine leistungsfähige Grundlage für eine eigene E-Rechnungsplattform. Es lohnt sich, wenn die gesamte Verarbeitung im eigenen Netz bleiben soll, eigenes Java- und Server-Know-how vorhanden ist und Quellcodezugriff sowie langfristige technische Kontrolle wichtiger sind als ein geringer Betriebsaufwand. Voraussetzung ist eine eigene Integrationsschicht, die Mustang für FileMaker nutzbar macht.
Ein Webdienst nutzt die in FileMaker bereits vorhandene HTTPS- und JSON-Schnittstelle, die über die verschiedenen Ausführungsumgebungen hinweg funktioniert. Es müssen keine plattformspezifischen Bibliotheken verteilt und keine fremden Laufzeiten eingebaut werden. Zugleich bleibt die anspruchsvolle Standardpflege an einer Stelle konzentriert: Neue ZUGFeRD-Pakete, XRechnung-Bundles und Validierungsartefakte erscheinen regelmäßig und können bei einem zentral betriebenen Dienst zusammen eingespielt, getestet und freigegeben werden. Dafür verlassen die Rechnungsdaten das eigene System, und es entsteht eine Abhängigkeit vom Anbieter.
FileMaker verwaltet den Geschäftsvorfall.
Die ergänzende Komponente erzeugt daraus das technische Format.
Diese klare Verantwortungsgrenze hält die FileMaker-Skripte überschaubar und verhindert, dass sich PDF-Technik, XML-Schema, Schematron, Java-Laufzeiten und Betriebssystemfragen mit der eigentlichen Rechnungslogik vermischen.
Was keine der drei Lösungen abnimmt
Kein Plugin, keine Open-Source-Bibliothek und kein Webdienst kann die fachliche Modellierung vollständig ersetzen.
Die FileMaker-Lösung muss weiterhin wissen,
- welche Steuerkategorie zu einem Geschäftsvorfall gehört,
- wie Zu- und Abschläge auf mehrere Steuersätze verteilt werden,
- wann auf Positions- und wann auf Summenebene gerundet wird,
- wie Anzahlungen berücksichtigt werden,
- ob ein Beleg eine Rechnungskorrektur oder eine umsatzsteuerliche Gutschrift ist,
- welche Referenzen und Pflichtangaben der jeweilige Empfänger verlangt.
Die ergänzende Komponente kann aus richtigen Daten eine technisch valide E-Rechnung erzeugen. Sie kann aber nicht zuverlässig erkennen, ob ein wirtschaftlicher Vorgang in der FileMaker-Datenbank falsch eingeordnet wurde.
Der sinnvollste Projektbeginn ist deshalb eine Analyse realer Rechnungen. Eine Stichprobe der letzten hundert Belege zeigt meist schnell, welche Standardfälle den größten Teil des Volumens ausmachen und welche Sonderfälle tatsächlich unterstützt werden müssen.
Diese Fallliste ist der eigentliche Projektumfang. Sie sollte anschließend mit Beispieldokumenten, automatisierten Tests und mindestens einem unabhängigen Validator abgesichert werden.
Meine Umsetzung für FileMaker
Für meine FileMaker-Beispieldatei zur E-Rechnungserstellung habe ich mich für einen kleinen Webdienst entschieden. Die FileMaker-Lösung bereitet die fachlichen Rechnungsdaten strukturiert auf; der Dienst übernimmt die technische Ausgabe.
Zusätzliche FileMaker-Plugins sind dafür nicht erforderlich. Der Mikroservice speichert keine Inhaltsdaten; sie werden ausschließlich im flüchtigen RAM-Arbeitsspeicher verarbeitet. Datenschutz und DSGVO-Konformität spielen bei der Ausgestaltung und beim Betrieb des Dienstes eine zentrale Rolle.
Damit bleibt die Integration in FileMaker vergleichsweise klein. Gleichzeitig können die technischen Komponenten und Validierungsregeln zentral gepflegt werden, ohne jede angeschlossene FileMaker-Datei neu ausliefern zu müssen.