# Neue ZUGFeRD Suite verfügbar
*Die COMFORT-Version der ZUGFeRD Suite für FileMaker ist in einer neuen Fassung fertig. Erzeugen und Lesen von ZUGFeRD/Factur-X und XRechnung, gehostet beim Kunden, ohne Abhängigkeit von einem Dienst. Neu dabei: eine KI-gestützte Feldzuordnung, die ohne einen einzigen Datensatz auskommt, eine Prüfseite für die Einrichtung und eine Anleitung, die den Namen verdient.*
---
## Was die Suite macht
**Factur-X / ZUGFeRD 2.x** ist ein Hybridformat: eine PDF/A-3, in der zusätzlich ein XML nach EN 16931 steckt. Der Mensch sieht die PDF, die Buchhaltungssoftware des Empfängers liest das XML. **XRechnung** ist die deutsche Ausprägung derselben Norm — reines XML, gegenüber öffentlichen Auftraggebern verbindlich.
Die Suite kann beides, und zwar in beide Richtungen:
| | erzeugen | lesen |
|---|---|---|
| **ZUGFeRD** | PDF/A-3 mit eingebettetem CII-XML | eine vorhandene ZUGFeRD-PDF auswerten |
| **UBL** | XRechnung 2.0 als XML | eine vorhandene XML auswerten |
Vier Wege, vier FileMaker-Skripte. Der Lesepfad ist der, den viele übersehen: eingehende E-Rechnungen automatisch erfassen, statt sie abzutippen.
*Oben die erzeugten Dateien, unten die eingelesenen. Ein Knopf je Richtung.*
## Die technischen Rahmenbedingungen
Das Wichtigste vorweg, weil es die häufigste Rückfrage ist: **es gibt keinen Dienst, der dazwischenhängt.**
Der Kunde bekommt einen Ordner, lädt ihn auf seinen eigenen Webserver, und damit läuft die gesamte Verarbeitung bei ihm. Ich betreibe für niemanden eine Verarbeitung, durch die fremde Rechnungsdaten fließen. Das ist Absicht: sobald ich das täte, wäre ich als Einzelentwickler in einer Rolle, die ich weder ausfüllen will noch muss.
Was der Server können muss:
```
PHP 8.1 oder neuer
Erweiterungen SimpleXML · DOM · iconv · cURL · mbstring · GD
Platz rund 35 MB
Datenbank keine
Composer nicht nötig -- vendor/ liegt vollständig bei
Kommandozeile nicht nötig
```
Das ist bewusst so niedrig gehalten. Jedes Shared Hosting der letzten Jahre erfüllt das. Auf FileMaker-Seite reicht **Pro 19 oder neuer**.
### Einrichtung: eine Adresse, ein Knopf
Es gibt zehn Adressfelder. Ausgefüllt wird genau eines.
*Eine Adresse eintragen, den Button daneben drücken — die übrigen neun ergeben sich. Die Bestätigung erscheint in grün über der Reiterleiste.*
Alle Endpunkte liegen im selben Ordner, also lassen sie sich ableiten. Das klingt nach einer Kleinigkeit und ist keine: zehn Adressen von Hand einzutippen sind zehn Gelegenheiten für einen Tippfehler. In einer früheren Fassung stand in einem der Felder `mc_create_ubl_xm.php` — ohne das schließende `l`. Ein falsch geschriebener Dateiname macht keinen Lärm, er wird einfach nicht gefunden, und die Meldung landet in einem Protokoll, das niemand liest.
### Und eine Prüfseite, die sagt, was zu tun ist
Nach dem Hochladen ruft man `install_check.php` auf. **22 Prüfungen** in vier Gruppen: PHP-Version und Grenzwerte, die benötigten Erweiterungen, Schreibrechte auf den Arbeitsordnern, und ob die Protokollverzeichnisse von außen gesperrt sind.
Zu jedem Fund steht dabei, **was zu tun ist** — nicht nur, dass etwas fehlt. Steht am Ende „Alles in Ordnung", kann man in FileMaker weitermachen. Danach löscht man die Datei; für den nächsten Umzug liegt sie im Paket weiterhin bereit.
## Die Feldzuordnung — worum es eigentlich geht
Die Suite kennt die Datenbank des Kunden nicht. Sie weiß nicht, ob die Rechnungsnummer `RgNr`, `rechnung_nr` oder `InvoiceNumber` heißt. Deshalb sagt man ihr das einmal, auf acht Laschen.
*Oben das Arbeitslayout, darunter je ZUGFeRD-Feld eine Klappliste mit den Feldern dieses Layouts. Links der technische Name, die deutsche und die englische Erklärung.*
Die Felder dürfen aus beliebigen Tabellen kommen, solange die Zuordnung stimmt. Das ist der Grund, warum sich die Suite in gewachsene Lösungen einbauen lässt, ohne dass am Datenmodell etwas geändert werden muss.
Es sind **rund fünfzig Felder.** Das ist zur Hälfte Fleißarbeit und zur Hälfte Ratearbeit. Fleißarbeit ist in Ordnung. Die Ratearbeit ist das Problem: Ist `dat1` das Rechnungs- oder das Lieferdatum? Heißt `k_ref` Kundenreferenz oder Kontoreferenz? Bei einer Lösung mit fünfzehn Jahren Historie weiß das manchmal nicht mal der, der sie gebaut hat.
Zwei bis drei Stunden. Und wenn man sich vertut, merkt man es nicht sofort — man merkt es, wenn die erste Rechnung beim Empfänger abgelehnt wird.
## Neu: die KI-gestützte Zuordnung
Genau dafür gibt es jetzt einen Knopf. Er heißt **KI Mapping** und sitzt oben rechts auf der Lasche Info.
### Was übertragen wird — und was nicht
Das ist die erste Frage, die kommt, deshalb steht sie zuerst. Übertragen werden genau drei Angaben je Feld:
```
Feldname · Feldtyp · Feldkommentar aus der Feldverwaltung
```
Also das hier:
```
k_iban [Standard Text Indexed] // IBAN des Kunden aus dem Altsystem
rg_datum [Datum Indexed] // Rechnungsdatum
pos_menge [Zahl] //
```
**Keine Datensätze. Kein einziger.** Keine Namen, keine Anschriften, keine Beträge, keine Kontodaten. Wenn ein Feld `k_iban` heißt, erfährt das Modell, dass es ein Feld dieses Namens gibt — nicht, welche IBAN darin steht.
Möglich wird das durch drei Funktionen, die FileMaker seit jeher mitbringt und die man viel zu selten sieht:
```
FieldNames ( Datei ; Layout ) die Feldnamen eines Layouts
FieldType ( Datei ; Feld ) Typ, Indizierung, Repetitionen
FieldComment ( Datei ; Feld ) der Kommentar aus der Feldverwaltung
```
Die lesen das **Schema**, nicht die Datensätze. Kein Export, keine Fundmenge, kein Datensatz im Zugriff — und auf Mac und Windows dasselbe Verhalten.
Das Erstaunliche daran: **die Zuordnung wird dadurch nicht schlechter, sondern besser.** Beispielwerte helfen weniger, als man denkt. Drei Beträge sagen nichts darüber, ob ein Feld die Bemessungsgrundlage oder der Steuerbetrag ist — beide sind Zahlen mit zwei Nachkommastellen. Der *Feldkommentar* sagt es. Wer seine Felder kommentiert, bekommt hier die Quittung dafür.
### Die Hälfte wird ohne KI entschieden
Bevor überhaupt etwas hinausgeht, räumt das Skript lokal auf. Alles, was sich über Namensgleichheit eindeutig auflösen lässt, wird sofort gesetzt.
In einer typischen Konfiguration sind das **24 von 53 Feldern**. Fast die Hälfte, ohne einen einzigen Aufruf, ohne einen Cent, ohne dass irgendetwas den Rechner verlässt. Nur der Rest geht als Frage hinaus — und weil in dieser Frage dann nur die wirklich unklaren Felder stehen, fällt die Antwort für jedes einzelne davon gründlicher aus.
Ein Lauf dauert **zwanzig bis vierzig Sekunden**.
### Der Schlüssel gehört dem Kunden
Jeder trägt in FileMaker seinen eigenen API-Schlüssel ein. Die Anfragen laufen über sein Konto, unter seinem Namen, auf seine Rechnung. Kein Sammelkonto, keine Weiterberechnung, kein Schlüssel von mir auf fremden Servern.
Kosten: rund **acht Cent** pro vollständigem Lauf. Das kleinste Guthaben, das man aufladen kann — meist 5 USD — reicht für etwa 60 Läufe. Man macht das ein- bis dreimal, nicht sechzigmal.
> **Ein Hinweis, der offenbar viele erwischt:** Ein Abonnement von Claude Pro oder Max enthält **keinen** API-Zugang. Das ist der Chat im Browser. Die API ist ein getrenntes Produkt mit getrennter Abrechnung und Guthaben im Voraus. Man kann ein Max-Abo haben und trotzdem keinen Schlüssel besitzen.
Und wer die KI gar nicht will: **Feld leer lassen.** Dann wird nichts übertragen und nichts aufgerufen. Die Suite funktioniert vollständig ohne diesen Schritt — es ist ein Hilfsmittel, keine Voraussetzung.
### Was die KI nicht weiß, sagt sie
Sie rät. Nicht immer, aber manchmal, und dann sieht das genauso überzeugt aus wie eine sichere Zuordnung. Deshalb trägt jede Zuordnung eine Einstufung:
```
hoch eindeutig -- gleicher Name, oder der Kommentar sagt es klar
mittel plausibel, aber es gab Alternativen
niedrig geraten -- bitte nachsehen
```
Was gar nicht zugeordnet werden konnte, landet im **Report Mapping**:
*Je Zeile ein Knopf, der alles zu diesem einen Feld zeigt: Typ, ob Pflicht, eine Empfehlung — und warum nichts gefunden wurde.*
Diese letzte Zeile ist mir die liebste. Nicht bloß „fehlt", sondern:
> *keine Kundennummer im Zahlungsbereich vorhanden*
Das ist der Unterschied zwischen einer Fehlermeldung und einem Arbeitsauftrag.
## Was sonst noch neu ist
- **Die vier XRechnung-Pflichtfelder** werden übertragen: Leitweg-ID (BT-10) und die drei Verkäufer-Kontaktangaben (BT-41 bis 43). Wichtiger noch: **es wird nichts mehr erfunden.** Frühere Fassungen setzten bei fehlenden Angaben Platzhalter ein — `info@example.com`, eine ausgedachte Telefonnummer. Solche Rechnungen kamen durch jeden Validator und enthielten trotzdem Kontaktdaten, die niemandem gehörten. Jetzt gilt: fehlt eine Angabe, bleibt das Element weg und eine Zeile landet im Protokoll.
- **Der UBL-Weg erzeugt XRechnung 2.0.**
- **Absicherung der Druckvorlage.** War ein Drucklayout nur halb konfiguriert — Feldzuordnung gesetzt, Layout nicht —, zerlegte das die Fundmenge für den gesamten weiteren Ablauf. Im Ergebnis kamen statt der Rechnungsdaten die Feldnamen an.
## Fazit
Die Suite läuft beim Kunden, braucht keinen Dienst und keine Datenbank, und die Einrichtung ist auf eine Adresse und einen Knopf zusammengeschrumpft. Was früher ein halber Vormittag Feldzuordnung war, ist jetzt ein Lauf von dreißig Sekunden plus Durchsehen.
Und der Teil, auf den ich am ehesten stolz bin, ist der, den man nicht sieht: **es gehen keine Rechnungsdaten hinaus.** Nicht, weil ich es verspreche, sondern weil es keinen Weg dafür gibt. Man kann nichts verlieren, was man nicht überträgt.
Wer ZUGFeRD oder XRechnung in einer bestehenden FileMaker-Lösung braucht — meldet euch gern.
---