E-Rechnungen in FileMaker erstellen: Was vor ZUGFeRD 2.5.2, Factur-X 1.09.2 und XRechnung 3.0.2 geklärt werden muss

Von Jan Hagemeister · Veröffentlicht am 20. August 2026 · Aktualisiert am 26. August 2026

Viele Unternehmen stehen aufgrund der gesetzlichen Vorgaben vor der Integration der E-Rechnung. Gleichzeitig entwickeln sich die technischen Standards weiter.

Damit stellt sich für viele FileMaker-Anwendungen die Frage: Wie lässt sich aus einer bestehenden Rechnungsdatenbank eine valide E-Rechnung erzeugen?

Eine E-Rechnung ist kein anderes Dateiformat für eine PDF-Rechnung

Bei klassischen FileMaker-Lösungen wurde die Datenbank häufig über viele Jahre mit einem klaren Ziel entwickelt: Am Ende soll eine optisch richtige Rechnung als PDF herauskommen.

Das ist etwas völlig anderes als eine strukturierte E-Rechnung.

Bei einer PDF-Rechnung reicht es beispielsweise, wenn irgendwo lesbar steht:

Zahlbar innerhalb von 30 Tagen. 2 % Skonto bei Zahlung innerhalb von 10 Tagen.

Oder:

Steuerfreie innergemeinschaftliche Lieferung gemäß § 4 Nr. 1b i. V. m. § 6a UStG.

Für einen Menschen ist sofort verständlich, was gemeint ist.

Ein E-Rechnungssystem muss dagegen wissen, welche Information welche fachliche Bedeutung hat. Betrag, Währung, Steuerkategorie, Zahlungsbedingung, Referenz, Lieferdatum oder Mengeneinheit müssen an den dafür vorgesehenen Stellen der XML-Struktur erscheinen.

FeRD weist selbst darauf hin, dass ZUGFeRD keine Anwendungssoftware ist. Die Struktur des Standards und die damit verbundenen Abhängigkeiten müssen vielmehr in die jeweilige Unternehmenssoftware implementiert werden.

Und genau an dieser Stelle beginnen bei bestehenden FileMaker-Datenbanken die Probleme.

Bei den zahlreichen E-Rechnungsintegrationen, die ich selbst durchgeführt habe, begegnen mir regelmäßig dieselben Themen.

1. Datenstruktur: Für das PDF ausreichend, für XML nicht

Viele Rechnungsdatenbanken sind ausschließlich auf das Rechnungslayout optimiert.

Ein Feld enthält beispielsweise:

12 Stück Edelstahlhalter, Sonderausführung, 240,00 €

Für die PDF-Ausgabe kann das vollkommen ausreichend sein.

Für eine E-Rechnung werden daraus jedoch mehrere unterschiedliche Informationen:

• Artikelbezeichnung
• Beschreibung
• Menge
• Mengeneinheit
• Einzelpreis
• Preiseinheit
• Positionsbetrag
• Steuerkategorie
• Steuersatz

Die erste Aufgabe einer E-Rechnungsintegration besteht deshalb nicht darin, XML zu erzeugen. Zunächst muss geprüft werden, ob die Datenbank überhaupt über die notwendigen fachlichen Informationen verfügt.

Was im PDF nur dargestellt wird, muss für die E-Rechnung als Datenmodell vorhanden sein.

2. Freitexte: Menschen verstehen Zusammenhänge, XML nicht

Freitextfelder gehören zu den größten Problemen gewachsener Rechnungsdatenbanken.

Informationen wie

Lieferung gemäß Angebot 4711 vom 12.05.2026

oder

Leistungszeitraum Januar bis März 2026

oder

Ihre Bestellung 0815

können im PDF problemlos ausgegeben werden.

Für eine E-Rechnung handelt es sich aber um völlig unterschiedliche Informationen: Angebotsreferenz, Leistungszeitraum und Bestellreferenz besitzen jeweils eigene fachliche Bedeutungen.

Der Text kann gegebenenfalls zusätzlich in der Rechnung erscheinen. Er ersetzt aber nicht die strukturierten Daten.

Ein E-Rechnungsgenerator sollte deshalb möglichst wenig versuchen, aus fertigen Rechnungstexten zu „erraten“.

Die bessere Lösung besteht darin, die zugrunde liegenden Informationen strukturiert in FileMaker zu speichern und aus diesen Daten sowohl den Rechnungstext als auch die XML-Daten zu erzeugen.

3. Adressdaten müssen strukturiert vorliegen

Auch Adressen sind in älteren Datenbanken häufig erstaunlich unstrukturiert.

Typische Felder sehen beispielsweise so aus:

Musterstraße 17
30159 Hannover

oder sogar:

Firma Müller, Musterstraße 17, 30159 Hannover, Deutschland

Für den Ausdruck ist das ausreichend. Für die elektronische Verarbeitung benötigt man zumindest eine eindeutige Zuordnung der einzelnen Adressbestandteile.

Dazu gehören insbesondere:

• Straße beziehungsweise Adresszeile
• Postleitzahl
• Ort
• Land
• gegebenenfalls zusätzliche Adresszeilen

Straße und Hausnummer müssen dabei nicht zwingend in jedem E-Rechnungsformat in getrennten XML-Elementen landen. Intern sollten Adressinformationen trotzdem so strukturiert gespeichert werden, dass sie zuverlässig verarbeitet werden können.

Besonders problematisch ist häufig das Land. Ein leerer Ländereintrag wurde im bisherigen Layout vielleicht automatisch als „Deutschland“ interpretiert. Für einen strukturierten Datenaustausch ist eine solche implizite Annahme problematisch.

4. ISO-Codes und andere Codelisten

Ein Mensch versteht:

Deutschland
Euro
Stück

Ein E-Rechnungssystem erwartet dagegen standardisierte Codes.

Beispielsweise:

• Länder nach ISO 3166
• Währungen nach ISO 4217
• Mengeneinheiten nach den verwendeten UN/ECE-Codelisten

Aus „Deutschland“ wird beispielsweise DE, aus „Euro“ EUR.

Auch die Mengeneinheit „Stück“ wird nicht einfach als deutscher Text übertragen, sondern über den dafür vorgesehenen Code abgebildet.

Das bedeutet nicht, dass der Benutzer künftig kryptische Codes eingeben muss. In FileMaker kann selbstverständlich weiterhin „Stück“ angezeigt werden. Im Datenmodell muss aber eine eindeutige Zuordnung zum entsprechenden Code existieren.

5. Abschlags-, Teil- und Schlussrechnungen

Bei einer einfachen Rechnung ist die Welt noch übersichtlich:

Leistung → Rechnung → Zahlung.

Bei längeren Projekten sieht die Realität schnell anders aus.

Es gibt beispielsweise:

1. Abschlagsrechnung
2. zweite Abschlagsrechnung
3. dritte Abschlagsrechnung
4. Schlussrechnung

Die Schlussrechnung muss berücksichtigen, welche Leistungen bereits berechnet wurden und welche Beträge bereits anzurechnen sind.

Viele FileMaker-Systeme lösen dies bislang über Layoutlogik oder Rechnungstexte.

Für eine E-Rechnung reicht das nicht.

Die Datenbank muss nachvollziehen können:

• Welche Rechnungen gehören zusammen?
• Welche Beträge wurden bereits berechnet?
• Welche Beträge wurden bereits bezahlt?
• Was wird mit der Schlussrechnung verrechnet?
• Welcher Betrag bleibt tatsächlich fällig?

Spätestens an dieser Stelle zeigt sich, dass E-Rechnung nicht lediglich ein neues Ausgabeformat ist, sondern in das fachliche Rechnungsmodell eingreift.

6. Anzahlungen

Ähnlich problematisch sind Anzahlungen.

Eine Zahlung vor Erstellung der endgültigen Rechnung muss später korrekt berücksichtigt werden.

Dabei müssen mindestens zwei Dinge auseinandergehalten werden:

• Was wurde bereits berechnet?
• Was wurde bereits bezahlt?

Das ist nicht dasselbe.

Eine bestehende FileMaker-Lösung enthält häufig lediglich ein Feld wie „Anzahlung 1.000 €“, das beim Drucken von der Rechnungssumme abgezogen wird.

Für eine strukturierte Verarbeitung muss dagegen nachvollziehbar sein, woher dieser Betrag kommt und welche Funktion er innerhalb der Rechnung hat.

7. Rechnungskorrektur und Gutschrift sind nicht dasselbe

Hier begegnet mir besonders häufig historisch gewachsene Begriffsverwirrung.

In vielen Datenbanken heißt praktisch jeder negative Beleg „Gutschrift“.

Umsatzsteuerlich muss jedoch zwischen einer Rechnungskorrektur und der sogenannten echten Gutschrift unterschieden werden.

Eine Rechnungskorrektur korrigiert eine zuvor ausgestellte Rechnung, beispielsweise wegen:

• Retoure
• Preisnachlass
• fehlerhafter Menge
• falschem Preis
• nachträglicher Minderung

Eine Gutschrift im umsatzsteuerlichen Sinn ist dagegen ein Abrechnungsverfahren. Nicht der Leistungserbringer stellt die Rechnung, sondern der Leistungsempfänger rechnet gegenüber dem Leistungserbringer ab.

Diese beiden Geschäftsvorfälle dürfen nicht allein deshalb technisch gleich behandelt werden, weil das bisherige FileMaker-Layout bei beiden einen negativen Betrag dargestellt hat.

Entsprechend müssen Belegart, Beteiligte, Referenzen und Vorzeichenlogik fachlich definiert werden.

8. Sammelrechnungen

Eine Rechnung kann mehrere Lieferungen oder mehrere Aufträge zusammenfassen.

In älteren Datenmodellen besteht dagegen häufig eine starre Beziehung:

ein Auftrag → eine Rechnung

Sobald mehrere Vorgänge gemeinsam berechnet werden, werden Referenzen dann beispielsweise als kommaseparierter Text in ein Feld geschrieben.

Für eine strukturierte Rechnung ist das keine besonders gute Lösung.

Die Datenbank sollte tatsächlich abbilden können:

eine Rechnung → mehrere Aufträge beziehungsweise Lieferungen

und bei Bedarf zusätzlich:

eine Rechnungsposition → bestimmter Auftrag oder Lieferschein

Hierfür werden echte relationale Strukturen benötigt.

9. Fremdwährungen

Auch Fremdwährungsrechnungen erfordern mehr als ein Währungssymbol im Layout.

Die Rechnungswährung muss eindeutig hinterlegt sein. Beträge müssen sich auf genau diese Währung beziehen.

Je nach Geschäftsvorfall können daneben weitere Angaben erforderlich werden, beispielsweise eine abweichende Währung für steuerliche Angaben.

Problematisch wird es insbesondere dann, wenn ein bestehendes System intern immer mit Euro rechnet und lediglich im Layout umgerechnete Beträge anzeigt.

Die Währung gehört deshalb zum eigentlichen Rechnungsdatensatz und nicht nur zum Layout.

10. Rechnungs- und Lieferadressen

Rechnungsempfänger und Warenempfänger müssen nicht identisch sein.

Ein Unternehmen kann beispielsweise an seine Zentrale bestellen, die Ware aber direkt an eine Niederlassung oder Baustelle liefern lassen.

In einer PDF-Rechnung kann eine solche Lieferadresse einfach irgendwo zusätzlich ausgegeben werden.

Für die E-Rechnung muss dagegen klar sein:

• Wer ist der Käufer?
• Wohin wurde geliefert?
• Wer ist gegebenenfalls Rechnungsempfänger?
• Welche Adresse gehört zu welcher Rolle?

Ein einzelnes Feld „abweichende Adresse“ reicht dafür langfristig nicht aus.

11. Mehrere Umsatzsteuersätze

Schon bei einer Rechnung mit 19 % und 7 % Umsatzsteuer muss das System die Rechnungspositionen eindeutig den entsprechenden Steuerkategorien zuordnen.

Aus den Positionen ergeben sich anschließend die Steueraufschlüsselungen der Gesamtrechnung.

Es reicht deshalb nicht, am Ende einer Rechnung einfach zwei Steuerbeträge anzuzeigen.

Das System muss für jede einzelne Rechnungsposition wissen:

• Welche Steuerkategorie gilt?
• Welcher Steuersatz gilt?
• Welcher Nettobetrag gehört dazu?

Nur dann können Steuerbasis, Steuerbetrag und Gesamtsummen konsistent erzeugt werden.

12. Skonto

Skonto ist ein gutes Beispiel dafür, wie sehr sich gedruckte und strukturierte Rechnungen unterscheiden.

In vielen FileMaker-Lösungen existiert lediglich ein fertiges Textfeld:

Zahlbar innerhalb von 30 Tagen, 2 % Skonto bei Zahlung innerhalb von 10 Tagen.

Die Parameter, aus denen dieser Satz entstanden ist, sind anschließend gar nicht mehr verfügbar.

Für eine E-Rechnungsintegration sollte ein System dagegen beispielsweise kennen:

• Zahlungsziel
• Skontosatz
• Skontofrist
• gegebenenfalls Berechnungsbasis

Aus diesen Daten kann anschließend der erforderliche Zahlungstext erzeugt werden.

Der umgekehrte Weg – aus einem beliebigen Freitext wieder verlässliche Zahlungsbedingungen zu rekonstruieren – ist wesentlich problematischer.

13. Rabatte und Zuschläge

Ein Rabatt kann technisch sehr unterschiedlich behandelt werden.

Beispielsweise:

Listenpreis 100 €, 10 % Rabatt

oder:

Einzelpreis 90 €

Beides ergibt wirtschaftlich zunächst denselben Betrag.

Strukturell ist es jedoch nicht dasselbe.

Soll der Rabatt als Rabatt ausgewiesen werden, muss er auch als solcher vorhanden sein. Gleiches gilt für Zuschläge, beispielsweise:

• Mindermengenzuschlag
• Verpackung
• Versicherung
• Bearbeitung
• sonstige Zuschläge

Zusätzlich muss unterschieden werden, ob ein Nachlass auf Positionsebene oder für die gesamte Rechnung gilt.

14. Innergemeinschaftliche Lieferung, Reverse Charge und Export

0 % Umsatzsteuer ist keine vollständige Steuerinformation.

Eine innergemeinschaftliche Lieferung, ein Export, eine steuerfreie Leistung und ein Reverse-Charge-Fall können sämtlich dazu führen, dass keine deutsche Umsatzsteuer berechnet wird.

Steuerlich handelt es sich trotzdem um unterschiedliche Sachverhalte.

Die E-Rechnung benötigt deshalb neben dem Steuersatz die richtige Steuerkategorie und gegebenenfalls einen Befreiungsgrund beziehungsweise die dazugehörige Kennzeichnung.

Ein bestehendes Feld:

Umsatzsteuer = 0 %

reicht nicht.

Die Datenbank muss wissen, warum keine Umsatzsteuer berechnet wird.

15. Serien- und Chargennummern

In bestimmten Branchen müssen zu Rechnungspositionen zusätzliche Informationen gespeichert werden:

• Seriennummern
• Chargennummern
• Fahrzeugidentifikationsnummern
• Gerätenummern
• andere Artikelmerkmale

Besonders schwierig wird es, wenn eine Position mehrere Seriennummern besitzt.

Ein großes Textfeld mit zehn untereinander geschriebenen Nummern funktioniert für das PDF, bildet aber keine echte Datenstruktur ab.

Sauberer ist eine 1:n-Beziehung:

Rechnungsposition → beliebig viele Merkmale beziehungsweise Seriennummern

Damit lassen sich solche Informationen später gezielt in die entsprechenden Strukturen der Rechnung übernehmen.

16. Mehrere Bestellungen, Aufträge oder Lieferscheine

Eine Rechnung kann mehrere Bestellungen enthalten.

Eine Bestellung kann mehrere Lieferscheine besitzen.

Ein Lieferschein kann wiederum nur einen Teil der berechneten Positionen betreffen.

Viele ältere Datenbanken kennen dagegen nur:

Rechnung::Auftragsnummer

Damit ist genau eine Referenz möglich.

Für komplexere Rechnungen wird daraus schnell eine n:m-Beziehung.

Referenzen müssen deshalb dort gespeichert werden, wo sie fachlich hingehören – gegebenenfalls auf Rechnungs- oder Positionsebene.

17. Mengeneinheiten

Eine Mengenangabe ist ohne Einheit häufig wertlos.

10 kann bedeuten:

• 10 Stück
• 10 Stunden
• 10 Meter
• 10 Kilogramm
• 10 Liter

In manchen FileMaker-Systemen ergibt sich die Einheit lediglich aus dem Artikeltext.

Für eine E-Rechnung muss sie dagegen strukturiert vorhanden und mit einem zulässigen Code verknüpft sein.

Idealerweise wird die Mengeneinheit bereits beim Artikel hinterlegt und bei Erstellung der Rechnungsposition als Teil der Rechnungsdaten übernommen.

18. Referenzen müssen fachlich unterschieden werden

Rechnungen enthalten oft zahlreiche Nummern:

• Angebot
• Bestellung des Kunden
• eigener Auftrag
• Vertrag
• Lieferschein
• Projekt
• Kostenstelle
• frühere Rechnung

Für Menschen reicht häufig eine Beschriftung im PDF.

Für eine E-Rechnung muss klar sein, um welche Art von Referenz es sich handelt.

Eine Datenbank mit:

Referenz 1
Referenz 2
Referenz 3

ist deshalb wenig hilfreich.

Besser ist ein Modell aus Referenzart und Referenzwert.

19. Buyer Reference und Leitweg-ID

Besonders häufig kommt es bei der Buyer Reference (BT-10) zu Missverständnissen.

Im deutschen B2G-Bereich kann dort die Leitweg-ID eine wichtige Rolle spielen. Buyer Reference und Leitweg-ID sind jedoch begrifflich nicht grundsätzlich dasselbe.

Entscheidend ist, welche Referenz der Rechnungsempfänger verlangt.

Diese Information kann abhängig sein von:

• Kunde
• Behörde
• Bestellung
• Auftrag
• Organisationseinheit

Es reicht deshalb nicht unbedingt, eine Leitweg-ID dauerhaft beim Kunden zu speichern. Ein großer Auftraggeber kann unterschiedliche Referenzen für verschiedene Niederlassungen oder Bestellvorgänge verwenden.

20. Leistungsdatum und Leistungszeitraum

Der Klassiker im Rechnungstext lautet:

Leistungszeitraum: 01.04.2026 bis 30.04.2026

Wenn dieses Datum nur Bestandteil eines Textfelds ist, besitzt die Datenbank selbst keine Information über Beginn und Ende des Leistungszeitraums.

Besser sind echte Datumsfelder:

Leistungsbeginn
Leistungsende

Bei einer einmaligen Lieferung kann entsprechend ein Liefer- oder Leistungsdatum hinterlegt werden.

Das hat zusätzlich den Vorteil, dass FileMaker die Angaben überprüfen und automatisch für andere Prozesse verwenden kann.

21. Zahlungsziel und Fälligkeit

Auch Zahlungsbedingungen sind häufig nur Text.

Beispielsweise:

Zahlbar ohne Abzug innerhalb von 14 Tagen.

Viel besser ist es, das konkrete Zahlungsziel zu speichern oder aus klar definierten Zahlungsbedingungen zu berechnen.

Dann kennt die Datenbank beispielsweise:

• Rechnungsdatum
• Zahlungsfrist in Tagen
• Fälligkeitsdatum
• Zahlungsbedingung

Damit kann auch geprüft werden, ob Rechnungstext, Fälligkeit und XML tatsächlich übereinstimmen.

22. Anhänge und rechnungsbegründende Unterlagen

Zu einer Rechnung gehören möglicherweise weitere Dokumente:

• Leistungsnachweise
• Stundenzettel
• Prüfprotokolle
• Lieferscheine
• Vertragsunterlagen
• Aufstellungen

Diese Unterlagen sollten nicht einfach irgendwo in einem allgemeinen Containerfeld liegen.

Die Rechnung muss wissen, welches Dokument zu ihr gehört und welche Bedeutung dieses Dokument hat.

Dafür bietet sich beispielsweise eine eigene Dokumententabelle mit Bezug zur Rechnung an.

Je nach Rechnungsformat und Übertragungsweg können unterstützende Dokumente referenziert oder eingebettet werden.

23. Einzelpreis, Menge und Positionsbetrag

Bei einer klassischen FileMaker-Rechnung findet man gelegentlich nur den fertigen Positionsbetrag.

Beispielsweise:

Montagearbeiten: 1.250 €

Für das Layout funktioniert das.

Für eine normale strukturierte Rechnungsposition benötigt man jedoch eine nachvollziehbare Berechnungslogik.

Typischerweise müssen mindestens bekannt sein:

• Menge
• Einheit
• Einzelpreis
• Preiseinheit
• Positionsbetrag

Der XML-Wert darf nicht einfach vom sichtbaren Layoutbetrag abweichen.

Die mathematische Beziehung zwischen den Feldern muss nachvollziehbar sein.

24. Rundung

Einer der häufigsten technischen Fehler einer E-Rechnung beträgt:

0,01 €.

Menschen ignorieren solche Unterschiede meistens.

Validatoren nicht.

Problematisch sind beispielsweise unterschiedliche Berechnungswege:

Variante A

Einzelne Positionen runden und anschließend addieren.

Variante B

Mit ungerundeten Zwischenwerten rechnen und erst die Gesamtsumme runden.

Abhängig von Menge, Einzelpreis und Steuersatz können unterschiedliche Ergebnisse entstehen.

Die E-Rechnung zwingt damit zu einer einheitlichen und reproduzierbaren Rundungslogik.

Gerade FileMaker-Lösungen sollten genau geprüft werden, wenn Berechnungsfelder über viele Jahre verändert oder manuelle Rundungskorrekturen eingebaut wurden.

25. Manuelle Korrekturen

Eine gefährliche Funktion vieler Individualsysteme lautet sinngemäß:

Rechnungssumme überschreiben

Für ein gedrucktes Dokument konnte das früher praktisch sein.

Bei einer strukturierten Rechnung kann es die komplette mathematische Konsistenz zerstören.

Wenn beispielsweise die Positionen 1.000 € ergeben, im Summenfeld aber manuell 999,98 € eingetragen wurden, müssen diese zwei Cent irgendwo fachlich erklärt werden.

Dasselbe gilt für manuell veränderte:

• Einzelpreise
• Nettobeträge
• Steuerbeträge
• Rabatte
• Rechnungssummen

Eine E-Rechnung sollte immer aus nachvollziehbaren Einzelwerten berechnet werden.

26. Textpositionen und Überschriften

In einem FileMaker-Layout erscheinen häufig Dinge als „Position“, die überhaupt keine Rechnungsposition sind.

Zum Beispiel:

Elektroarbeiten

darunter folgen dann fünf echte Positionen.

Oder:

Nachfolgende Leistungen gemäß Angebot:

Solche Überschriften besitzen weder Menge noch Preis und sind wirtschaftlich keine Rechnungspositionen.

Im Datenmodell sollte deshalb unterschieden werden zwischen:

• abrechenbarer Position
• Text
• Überschrift
• Zwischensumme
• Gruppe

Gerade ZUGFeRD/Factur-X EXTENDED bietet inzwischen zusätzliche Möglichkeiten für komplexere Positionsstrukturen. Das bedeutet aber nicht, dass jeder bisherige Layoutdatensatz automatisch zu einer normalen Rechnungsposition werden sollte.

27. Positionen ohne Menge oder Preis

Ein verwandtes Problem sind Pauschalpositionen.

Im PDF steht beispielsweise:

Projektpauschale: 5.000 €

Intern existiert lediglich der Betrag.

Eine strukturierte Rechnungsposition benötigt jedoch eine konsistente Berechnungsgrundlage.

Eine mögliche Modellierung wäre beispielsweise:

Menge: 1
Einheit: Pauschale beziehungsweise geeignete Einheit
Einzelpreis: 5.000 €
Positionsbetrag: 5.000 €

Wichtig ist nicht, eine bestimmte Zahl künstlich einzusetzen, sondern den tatsächlichen fachlichen Sachverhalt richtig abzubilden.

28. Negative Mengen und negative Preise

Negative Werte sind besonders sorgfältig zu betrachten.

Eine negative Rechnungsposition kann beispielsweise entstehen durch:

• Retoure
• Korrektur
• Verrechnung
• Minderung
• Storno einer einzelnen Leistung

Aber was bedeutet:

Menge: -2
Preis: 100 €

im Unterschied zu:

Menge: 2
Preis: -100 €?

Mathematisch ergibt beides denselben Positionsbetrag.

Fachlich muss es deshalb nicht dasselbe bedeuten.

Bevor eine E-Rechnung erzeugt wird, sollte geklärt werden, welche Vorzeichenlogik im bestehenden System verwendet wird und welchen Geschäftsvorfall sie tatsächlich beschreibt.

29. Brutto- und Nettopreise

Auch die Preislogik selbst muss untersucht werden.

Manche Systeme speichern den Nettopreis und berechnen daraus den Bruttopreis.

Andere speichern Bruttopreise und rechnen die enthaltene Umsatzsteuer heraus.

Bei bestimmten Mengen und Steuersätzen entstehen dabei Rundungsdifferenzen.

Besonders problematisch wird es, wenn der im PDF sichtbare Preis ein Bruttopreis ist, während die XML-Struktur mit daraus errechneten Nettopreisen arbeitet.

Vor der Integration sollte deshalb eindeutig festgelegt werden, welcher Preis der führende Wert ist.

30. Preiseinheiten

Ein Einzelpreis muss sich nicht auf genau eine Einheit beziehen.

Beispiele:

4,95 € je Stück

aber auch:

28,00 € je 100 Stück

oder:

350,00 € je 1.000 Stück

Die sogenannte Preiseinheit darf deshalb nicht nur implizit aus der bisherigen Branchenpraxis hervorgehen.

Wird sie ignoriert, kann aus einem Preis von 350 € je 1.000 Stück plötzlich ein Preis von 350 € je Stück werden.

Das wäre zwar möglicherweise syntaktisch perfektes XML – wirtschaftlich aber eine Katastrophe.

31. Steuerliche Kennungen

Umsatzsteuer-Identifikationsnummern und andere Kennungen sind ebenfalls häufig Bestandteil des Rechnungslayouts, ohne tatsächlich in den Rechnungsdaten vorhanden zu sein.

Sie stehen beispielsweise als fest eingetragener Text in der Kopf- oder Fußzeile des FileMaker-Layouts.

Für eine E-Rechnung reicht das nicht.

Die Identifikationen des Verkäufers müssen aus dem tatsächlichen Rechnungsaussteller beziehungsweise Mandanten stammen.

Entsprechendes gilt für weitere Unternehmensidentifikationen und elektronische Adressen, soweit sie für den jeweiligen Anwendungsfall benötigt werden.

32. Mehrere Mandanten oder Rechnungsaussteller

Besonders sorgfältig muss eine Datenbank geprüft werden, wenn mehrere Unternehmen mit derselben FileMaker-Lösung Rechnungen erstellen.

Ein Logo oder Firmenname im Layout entscheidet nicht darüber, wer rechtlich der Verkäufer ist.

Für jede Rechnung müssen eindeutig bestimmbar sein:

• Verkäufer
• Anschrift
• Steuerkennungen
• Bankverbindung
• elektronische Adresse
• gegebenenfalls Handelsregisterinformationen

Diese Daten sollten zum Zeitpunkt der Rechnungserstellung eindeutig dem Beleg zugeordnet werden.

33. Bankverbindungen

Besitzt ein Unternehmen nur ein einziges Konto, fällt dieses Problem kaum auf.

Bei mehreren Bankverbindungen muss jedoch geklärt werden, welche Bankverbindung zu welcher Rechnung gehört.

Mögliche Kriterien sind beispielsweise:

• Mandant
• Währung
• Kunde
• Geschäftsbereich
• Zahlungsart

Auch hier sollte nicht das Layout entscheiden.

Die Zahlungsinformationen müssen Bestandteil des Rechnungsdatensatzes sein.

34. Rechnungsstatus und Unveränderbarkeit

Eine Rechnung durchläuft verschiedene Zustände.

Beispielsweise:

Entwurf → geprüft → erstellt → versendet → bezahlt

Bei einer E-Rechnung wird diese Unterscheidung noch wichtiger.

Solange eine Rechnung Entwurf ist, kann sie geändert werden.

Nach der Ausstellung sollte dagegen nicht einfach eine Position verändert und anschließend eine neue XML-Datei mit derselben Rechnungsnummer erzeugt werden.

Damit könnten zwei unterschiedliche Rechnungen mit identischer Rechnungsnummer existieren.

Nachträgliche Änderungen gehören deshalb in einen kontrollierten Korrekturprozess.

Eine sinnvolle FileMaker-Integration benötigt folglich einen klar definierten Zustand, ab dem die Rechnungsdaten eingefroren werden.

35. Rechnungsnummer und Zeitpunkt der Vergabe

Auch die Vergabe der Rechnungsnummer muss betrachtet werden.

Manche Systeme vergeben sie bereits beim Anlegen des Datensatzes.

Andere erst beim Drucken.

Wieder andere beim Verbuchen.

Mit der E-Rechnung kommt gegebenenfalls noch ein weiterer Schritt hinzu:

XML beziehungsweise ZUGFeRD-Dokument erzeugen.

Deshalb muss eindeutig definiert werden:

Wann wird aus einem Rechnungsentwurf eine tatsächlich ausgestellte Rechnung?

Zu diesem Zeitpunkt sollten Rechnungsnummer, Rechnungsdatum und Rechnungsinhalt feststehen.

PDF und XML dürfen anschließend nicht unabhängig voneinander unterschiedliche Versionsstände enthalten.

36. Versand und Archivierung

Zum Schluss muss festgelegt werden, welches Dokument tatsächlich die Rechnung ist.

Bei einer XRechnung ist dies typischerweise die strukturierte XML-Datei.

Bei einer hybriden ZUGFeRD-/Factur-X-Rechnung befindet sich das strukturierte XML innerhalb der PDF/A-3-Datei.

Damit stellen sich praktische Fragen:

• Welche Datei wird an den Kunden verschickt?
• Wird exakt diese Datei archiviert?
• Wird zusätzlich eine Visualisierung gespeichert?
• Wird das Ergebnis der Validierung dokumentiert?
• Kann eine versandte Rechnung später reproduziert werden?
• Wird verhindert, dass nachträglich eine andere XML-Datei unter derselben Rechnungsnummer entsteht?

Eine elektronische Rechnung sollte nicht Jahre später aus möglicherweise inzwischen geänderten Daten neu erzeugt werden müssen.

Das tatsächlich ausgestellte elektronische Original gehört deshalb in einen nachvollziehbaren Archivierungsprozess.

Die technische XML-Erzeugung ist meistens der einfachere Teil

Die lange Liste zeigt ein grundlegendes Problem:

E-Rechnung bedeutet nicht, aus FileMaker ein paar zusätzliche XML-Tags auszugeben.

Die eigentliche Arbeit besteht darin, das vorhandene Datenmodell mit einem semantischen Rechnungsmodell abzugleichen.

Erst danach lässt sich zuverlässig bestimmen:

Dieses FileMaker-Feld entspricht dieser Information innerhalb von ZUGFeRD beziehungsweise XRechnung.

Genau deshalb unterscheiden sich E-Rechnungsintegrationen bei bestehenden Individualanwendungen erheblich von der Einführung einer Standard-Fakturierungssoftware.

Jede über viele Jahre gewachsene FileMaker-Datenbank besitzt ihre eigene Rechnungslogik.

Und diese Logik muss zunächst verstanden werden.

Validierung gehört von Anfang an zur Entwicklung

Eine erzeugte XML-Datei ist nicht automatisch eine gültige E-Rechnung.

Die Validierung sollte deshalb nicht erst ganz am Ende der Entwicklung erfolgen.

Sinnvoller ist ein iterativer Prozess:

FileMaker-Daten → E-Rechnung erzeugen → validieren → Fehler analysieren → Datenmodell beziehungsweise Mapping korrigieren

Dabei müssen unterschiedliche Ebenen betrachtet werden.

Eine Schema-Prüfung kontrolliert unter anderem, ob die XML-Struktur technisch zulässig ist.

Die Geschäftsregeln prüfen dagegen inhaltliche Zusammenhänge, beispielsweise Berechnungen, Pflichtangaben und Abhängigkeiten zwischen einzelnen Werten.

Bei ZUGFeRD kommt zusätzlich das PDF/A-3-Dokument mit eingebettetem XML hinzu.

Validierung ist damit kein optionaler letzter Test, sondern Bestandteil der eigentlichen E-Rechnungserzeugung.

E-Rechnung ist auch eine Chance für bestehende FileMaker-Lösungen

Das klingt zunächst nach erheblichem Aufwand.

In der Praxis hat die Einführung der E-Rechnung aber einen positiven Nebeneffekt: Sie legt Schwächen offen, die in gewachsenen Rechnungsdatenbanken bereits seit Jahren vorhanden waren.

Plötzlich muss eindeutig definiert werden:

• Was ist eine Gutschrift?
• Was ist eine Rechnungskorrektur?
• Woher stammt die Steuerinformation?
• Welche Bestellung gehört zu welcher Position?
• Wie wird eine Anzahlung verrechnet?
• Was ist der tatsächliche Einzelpreis?
• Wann gilt eine Rechnung als ausgestellt?
• Welche Daten sind nach Ausstellung noch veränderbar?

Die E-Rechnung zwingt damit zu etwas, was bei Individualsoftware ohnehin sinnvoll ist:

Geschäftliche Sachverhalte werden wieder als Daten modelliert und nicht lediglich als Text auf einem Layout dargestellt.

Wenn diese Grundlage geschaffen ist, wird die eigentliche Erzeugung von ZUGFeRD, Factur-X oder XRechnung erheblich einfacher.