UBL nach CII konvertieren? Warum das bei E-Rechnungen der falsche Architekturansatz ist

Von Jan Hagemeister · Veröffentlicht am 25. August 2026

Viele E-Rechnungslösungen gehen einen scheinbar naheliegenden Weg: Aus den Rechnungsdaten wird zunächst UBL erzeugt. Wird zusätzlich CII benötigt, etwa für ZUGFeRD oder Factur-X, wird die vorhandene UBL-Struktur anschließend nach CII konvertiert.

Technisch kann das funktionieren. Für die Erzeugung eigener E-Rechnungen ist es jedoch der falsche Architekturansatz.

Denn die eigentliche Aufgabe besteht nicht darin, XML von einer Syntax in eine andere zu übersetzen. Die entscheidende Arbeit ist die fachliche Beurteilung des Geschäftsvorgangs und die korrekte Zuordnung der vorhandenen Rechnungsdaten zur jeweiligen Syntax.

Die Ausgangsdaten liegen in FileMaker – ihre Bedeutung aber nicht immer

In FileMaker stehen die Informationen, aus denen eine Rechnung entsteht:

• Rechnungsnummer und Rechnungsdatum
• Rechnungsart
• Verkäufer und Käufer
• Anschriften
• Positionen, Mengen und Preise
• Steuern
• Zahlungsbedingungen
• Referenzen
• Zu- und Abschläge
• Währung
• Zahlungsinformationen
• Summen

Das bedeutet jedoch noch lange nicht, dass diese Daten bereits eindeutig auf eine E-Rechnung abgebildet werden können.

Ein Feldname in FileMaker beschreibt häufig nur, wie das Unternehmen eine Information bisher bezeichnet oder für seine PDF-Rechnung verwendet hat. Daraus folgt nicht automatisch, welchem Business Term der EN 16931 diese Information entspricht.

Genau hier beginnt die fachliche Arbeit.

Mapping ist keine technische Fleißarbeit

Nehmen wir ein einfaches Beispiel. In FileMaker existiert ein Feld:

Kundenreferenz = "4711-AB"

Ein Entwickler kann diesen Wert problemlos in ein XML-Element schreiben.

Die entscheidende Frage lautet aber zunächst:

Was bedeutet diese „Kundenreferenz“ fachlich?

Ist es:

• die Buyer Reference?
• eine Bestellreferenz?
• eine Vertragsreferenz?
• eine Projektkennung?
• eine interne Kundennummer?
• ein Ansprechpartner?
• oder lediglich ein bisher auf der PDF-Rechnung ausgegebener Freitext?

Das ist keine XML-Frage.

Und es ist auch keine Frage, die ein Entwickler allein anhand des Feldnamens zuverlässig beantworten kann.

Erst wenn die fachliche Bedeutung geklärt ist, kann entschieden werden, wie dieser Wert in UBL und wie er in CII abzubilden ist.

FileMaker-Feld
      ↓
fachliche Beurteilung
      ↓
Bedeutung nach EN 16931
      ↓
UBL-Mapping

und unabhängig davon:

FileMaker-Feld
      ↓
fachliche Beurteilung
      ↓
Bedeutung nach EN 16931
      ↓
CII-Mapping

Der Entwickler kann nicht entscheiden, was eine Rechnung steuerlich bedeutet

Besonders deutlich wird das bei komplexeren Geschäftsvorgängen.

In einer bestehenden FileMaker-Lösung kann beispielsweise ein Beleg als „Gutschrift“ bezeichnet werden. Damit ist aber noch nicht geklärt, ob tatsächlich eine Gutschrift im umsatzsteuerlichen Sinn vorliegt oder eine Rechnungskorrektur.

Ähnlich sieht es bei anderen Fällen aus:

• Anzahlungen
• Abschlagsrechnungen
• Schlussrechnungen
• Teilrechnungen
• Rechnungskorrekturen
• Gutschriften
• Skonto
• Rabatten und Zuschlägen
• unterschiedlichen Umsatzsteuersätzen
• steuerfreien Umsätzen
• Reverse-Charge-Sachverhalten
• abweichenden Zahlungsempfängern
• Sammelabrechnungen

Die technische Umsetzung kann erst beginnen, wenn geklärt ist, welcher Geschäftsvorgang tatsächlich vorliegt und wie dieser fachlich abzubilden ist.

Ein Entwickler kann dafür die technischen Möglichkeiten von UBL und CII erklären.

Er sollte aber nicht allein entscheiden, welche steuerliche oder buchhalterische Bedeutung der konkrete Vorgang des Unternehmens hat.

Steuerberater und Wirtschaftsprüfer gehören deshalb früh in das Projekt

Bei der Einführung der E-Rechnung sollte die bestehende Rechnungslogik deshalb gemeinsam mit den fachlichen Beratern des Unternehmens betrachtet werden.

Je nach Unternehmen können das insbesondere sein:

• Steuerberater
• Wirtschaftsprüfer
• interne Finanzbuchhaltung
• Rechnungswesen oder Controlling
• gegebenenfalls Rechts- oder Steuerabteilung

Diese Beteiligten müssen nicht erklären, wie ein cac:-, cbc:- oder ram:-Element aufgebaut ist.

Das ist Aufgabe der technischen Umsetzung.

Sie müssen vielmehr beantworten können, welcher Geschäftsvorgang hinter den vorhandenen Daten steht.

Der Entwickler kann beispielsweise fragen:

Was bedeutet dieses Feld fachlich?

Handelt es sich hier um eine Rechnungskorrektur oder um eine Gutschrift?

Ist dieser Abzug Skonto, Rabatt oder bereits Bestandteil des vereinbarten Preises?

Welche Bedeutung hat diese Referenz im Geschäftsprozess?

Wie werden Anzahlungen und Schlussrechnungen tatsächlich gebucht?

Wer ist bei diesem Vorgang Leistungserbringer und wer Rechnungsaussteller?

Erst auf Grundlage dieser Antworten lässt sich ein belastbares Mapping erstellen.

Eine valide XML-Datei beantwortet diese Fragen nicht

Gerade hier entsteht leicht ein falsches Sicherheitsgefühl.

Ein Entwickler kann eine XML-Datei erzeugen, die:

• gegen das XSD validiert,
• die Schematron-Regeln erfüllt,
• vom E-Rechnungsvalidator akzeptiert wird.

Trotzdem kann der Inhalt fachlich falsch sein.

Wenn beispielsweise eine interne Projektnummer technisch korrekt als Bestellreferenz ausgegeben wird, kann das XML vollkommen valide sein.

Der Validator weiß nicht, was dieses Feld in FileMaker tatsächlich bedeutet.

Dasselbe gilt für einen falsch eingeordneten Geschäftsvorgang.

Ein Validator prüft, ob die angegebene Information an dieser Stelle zulässig ist.

Er kann nicht prüfen, ob das Unternehmen die richtige Information angegeben hat.

Deshalb ist die Analyse der bestehenden FileMaker-Lösung so wichtig

Vor der XML-Erzeugung sollte deshalb zunächst untersucht werden, wie Rechnungen im Unternehmen tatsächlich entstehen.

Dabei geht es nicht nur um Felder und Tabellen.

Es geht um Fragen wie:

• Welche Rechnungsarten gibt es tatsächlich?
• Welche Sonderfälle kommen vor?
• Welche Informationen werden heute nur als Freitext ausgegeben?
• Welche Angaben werden aus mehreren Feldern zusammengesetzt?
• Welche Bedeutung haben interne Referenzen?
• Wie werden Rabatte, Skonto und Zuschläge behandelt?
• Wie werden Anzahlungen verrechnet?
• Wie werden Korrekturen erstellt?
• Gibt es echte Gutschriften?
• Welche steuerlichen Fälle kommen vor?
• Stimmen die Bezeichnungen in FileMaker überhaupt mit der fachlichen Bedeutung überein?

Gerade ältere FileMaker-Lösungen wurden häufig für die Erstellung einer optisch richtigen PDF-Rechnung gebaut.

Für eine PDF reicht es oft, dass die Information irgendwo lesbar auf der Rechnung steht.

Bei einer E-Rechnung reicht das nicht mehr.

Die Information muss fachlich eindeutig sein und dem richtigen strukturierten Feld zugeordnet werden.

Warum UBL nach CII diese fachliche Ebene verdeckt

Wird zunächst UBL erzeugt und daraus anschließend CII konvertiert, entsteht:

FileMaker-Daten
      ↓
fachliche Entscheidungen
      ↓
     UBL
      ↓
technisches Mapping
      ↓
     CII

Damit wird leicht der Eindruck vermittelt, CII sei nur noch ein technisches Konvertierungsproblem.

Das ist jedoch genau der problematische Punkt.

Die UBL-Datei enthält bereits das Ergebnis einer fachlichen Interpretation der FileMaker-Daten.

Bei der CII-Erzeugung sollte deshalb nicht gefragt werden:

Wie übersetze ich dieses UBL-Element nach CII?

Sondern:

Welche fachliche Information aus FileMaker soll hier dargestellt werden und wie sieht die korrekte CII-Abbildung dafür aus?

Der direkte Weg lautet daher:

                     ┌── fachliche Zuordnung ──→ UBL XML
FileMaker-Daten ─────┤
                     └── fachliche Zuordnung ──→ CII XML

Beide Wege beginnen bei denselben Geschäftsdaten und denselben zuvor geklärten fachlichen Sachverhalten.

Ein allgemeines Zwischenformat löst das Problem ebenfalls nicht

Auch ein syntaxunabhängiges JSON oder ein vermeintlich neutrales Rechnungsmodell nimmt einem diese Arbeit nicht ab.

Steht dort beispielsweise:

{
  "buyerReference": "4711-AB"
}

ist die entscheidende fachliche Entscheidung bereits getroffen worden.

Die schwierige Frage war nicht, ob das Feld im JSON buyerReference heißt.

Die schwierige Frage war:

Ist „4711-AB“ aus dieser konkreten FileMaker-Lösung tatsächlich eine Buyer Reference?

Ein Zwischenformat kann technisch sinnvoll sein, um Daten zu transportieren.

Es ersetzt aber weder die Analyse der Geschäftsprozesse noch die fachliche Entscheidung über die richtige Zuordnung.

Was muss FileMaker bereitstellen?

FileMaker muss die Geschäftsdaten so strukturiert und eindeutig wie möglich bereitstellen.

Eine Anschrift sollte beispielsweise nicht nur als mehrzeiliger Text vorhanden sein, sondern nach Möglichkeit getrennt nach:

Straße
Hausnummer
Postleitzahl
Ort
Land

Auch Informationen wie:

Währung = EUR
Land = DE
Mengeneinheit = H87
Steuerkategorie = S
Steuersatz = 19

sollten eindeutig vorliegen.

Noch wichtiger ist aber die fachliche Bedeutung der Felder.

Ein Feld namens:

Referenz

ist für eine E-Rechnung kaum ausreichend definiert, wenn darin je nach Kunde eine Bestellnummer, Projektnummer oder interne Kennung eingetragen wird.

Die Einführung der E-Rechnung zwingt damit häufig erstmals dazu, bestehende Rechnungsprozesse wirklich sauber zu beschreiben.

UBL und CII müssen jeweils fachlich abgebildet werden

Nach dieser fachlichen Klärung können die beiden Syntaxen unabhängig umgesetzt werden:

FileMaker
   │
   ├── UBL-Mapping
   │       ↓
   │     UBL XML
   │
   └── CII-Mapping
           ↓
         CII XML

Dabei darf die technische Umsetzung unterschiedlich sein.

Das ist kein Nachteil, sondern gerade der Sinn der Trennung.

Wenn beispielsweise derselbe Geschäftsvorgang in UBL und CII unterschiedlich strukturiert werden muss, wird er in beiden Syntaxen entsprechend ihrer jeweiligen Regeln umgesetzt.

Keine Syntax muss dafür die andere interpretieren.

Beispiel Gutschrift

Gerade der Begriff „Gutschrift“ zeigt, warum fachliche Beratung vor der XML-Erzeugung wichtig ist.

In vielen Warenwirtschafts- und FileMaker-Systemen wird nahezu jeder Beleg mit negativem Betrag als „Gutschrift“ bezeichnet.

Für die E-Rechnung reicht diese Bezeichnung nicht.

Zunächst muss fachlich geklärt werden, welcher Geschäftsvorgang tatsächlich vorliegt.

Erst danach kann die entsprechende Dokumentenart festgelegt und für UBL beziehungsweise CII umgesetzt werden.

Die Reihenfolge lautet also nicht:

FileMaker-Beleg
      ↓
XML-Dokument auswählen

sondern:

FileMaker-Beleg
      ↓
Geschäftsvorgang fachlich beurteilen
      ↓
Dokumentenart bestimmen
      ↓
UBL und CII korrekt abbilden

Genau an dieser Stelle sind Steuerberater, Wirtschaftsprüfer oder die fachlich verantwortliche Buchhaltung unverzichtbare Ansprechpartner.

Die Rollen müssen klar getrennt sein

Eine erfolgreiche E-Rechnungsintegration braucht deshalb mehrere Perspektiven.

Erst das Zusammenspiel dieser Ebenen ergibt eine belastbare E-Rechnung.

Fazit

Die Erstellung einer E-Rechnung ist kein XML-Export und kein reines Softwareprojekt.

Die technische Erzeugung von XML ist am Ende häufig sogar der einfachere Teil.

Die eigentliche Arbeit besteht darin, die vorhandenen Daten und Geschäftsprozesse fachlich zu verstehen:

Was bedeutet diese Information?

Welcher Geschäftsvorgang liegt vor?

Wie ist er steuerlich und buchhalterisch einzuordnen?

Welchem fachlichen Element der E-Rechnung entspricht er?

Erst danach folgt die technische Frage:

Wie wird diese Information in UBL und wie in CII dargestellt?

Deshalb sollte die Architektur nicht lauten:

FileMaker → UBL → CII

sondern:

                         ┌──→ UBL-Mapping ──→ UBL
                         │
FileMaker ─→ fachliche ──┤
            Beurteilung  │
                         └──→ CII-Mapping ──→ CII

Und genau diese fachliche Beurteilung sollte nicht allein beim Entwickler liegen.