Rechnung in Fremdwährung

Eine Rechnung in GBP, deren Steuerbetrag zusätzlich in EUR ausgewiesen wird – samt Umrechnungskurs und Kursdatum. Dazu Steuervertreter, abweichender Zahlungsempfänger, Abrechnungszeitraum, Anzahlung und Abschläge auf Positionsebene.

Grundlage ist die offizielle Beispielrechnung X07_01_Fremdwaehrung aus der Factur-X-/ZUGFeRD-Dokumentation (FeRD-Beispielpaket, ZUGFeRD 2.5.0, Profil EXTENDED). Der Code unten erzeugt genau diesen Beleg, Feld für Feld und in derselben Reihenfolge.

Einige Verweise auf dieser Seite führen in die vertiefende Dokumentation im Kunden-Bereich und verlangen eine Anmeldung.

Das ist der anspruchsvollste der drei Beispielbelege: Er bringt in einem einzigen Dokument zusammen, was sonst über viele Seiten verstreut ist. Wenn Sie zum ersten Mal einen EXTENDED-Beleg aufbauen, ist die Erweiterte Warenrechnung der bessere Einstieg; hier geht es um die Sonderfälle.

Was dieses Beispiel zeigt

  • Zwei Währungen: Rechnungswährung GBP (BT-5), Buchungswährung EUR (BT-6)
  • Steuerbetrag doppelt – einmal je Währung (BT-110 und BT-111) – plus Umrechnungskurs (BG-X-41)
  • Steuervertreter des Verkäufers (BG-11) und abweichender Zahlungsempfänger (BG-10)
  • Abschläge auf Positionsebene als SpecifiedTradeAllowanceCharge
  • Abrechnungszeitraum (BT-73/BT-74) und Anzahlung (BT-113)

1. Rechnungskopf und die zwei Währungen

Die entscheidende Zeile ist invoice.TaxCurrency. Alle Beträge im Beleg stehen in der Rechnungswährung BT-5, hier GBP; die Buchungswährung BT-6 betrifft ausschließlich den zusätzlich ausgewiesenen Steuerbetrag.

2. Freitexte

Der Code TXD (steuerliche Information) erklärt dem menschlichen Leser, warum überhaupt zwei Währungen im Dokument auftauchen – eine sinnvolle Ergänzung zu den strukturierten Feldern weiter unten.

Zeilenumbrüche und Einrückungen innerhalb einer Notiz sind im XML signifikant. Die Tabulatoren im ersten Aufruf stehen nicht zur Zierde da – sie stammen zeichengenau aus der Referenzdatei, und ohne sie meldet die Gegenprobe einen Unterschied.

3. Verkäufer und Steuervertreter

Der Steuervertreter (BG-11) ist eine eigenständige Partei mit eigener USt-IdNr. – typisch, wenn ein ausländischer Lieferant im Inland durch einen Fiskalvertreter auftritt. Er wird wie eine normale Partei gesetzt, seine Steuernummer aber über eine eigene Methode.

4. Käufer

Zwei Kleinigkeiten, die oft gesucht werden: street2 füllt ram:LineTwo, also die zweite Adresszeile, und die elektronische Adresse des Käufers (BT-49) nimmt hier eine Leitweg-ID auf.

5. Lieferung und Abrechnungszeitraum

Auch der Warenempfänger trägt eine elektronische Adresse. Anders als bei Verkäufer und Käufer gibt es dafür keine Set…-Methode: Das Feld ElectronicAddress hängt direkt an der Partei und wird nur im EXTENDED-Profil geschrieben.

6. Zahlungsempfänger und Bankverbindung

Bezahlt wird nicht an den Verkäufer, sondern an dessen Finanzdienstleister (BG-10). Die Bankverbindung wird getrennt davon über AddCreditorFinancialAccount gesetzt.

7. Position mit Abschlägen

Eine einzige Position, aber mit dem Unterschied, der in der Praxis am häufigsten verwechselt wird: Es gibt zwei verschiedene Rabattarten auf Positionsebene.

Methode XML-Element Wirkung
AddTradeAllowance ram:AppliedTradeAllowanceCharge
(innerhalb des Bruttopreises)		 Betrag pro Einheit. Senkt den Nettopreis. So arbeitet die Warenrechnung.
AddSpecifiedTradeAllowance ram:SpecifiedTradeAllowanceCharge
(im Positions-Settlement)		 Betrag für die gesamte Position. Senkt die Positionssumme, der Preis bleibt unverändert. Dieser Weg wird hier genutzt.

Konkret: Der Stückpreis bleibt bei 100 GBP, die Positionssumme fällt durch die beiden Abschläge von 1.000 auf 850 GBP.

8. Zu- und Abschläge auf Dokumentenebene

Ein Zuschlag für Einwegverpackung und ein prozentualer Stammkundenrabatt. Beide teilen sich im XML dasselbe Element ram:SpecifiedTradeAllowanceCharge und werden nur über ram:ChargeIndicator unterschieden. Der Writer schreibt sie in der Reihenfolge, in der sie hinzugefügt werden – deshalb steht der Zuschlag im Code zuerst.

9. Umsatzsteuer in Rechnungswährung

Zunächst ganz normal, in GBP: 850,00 + 30,00 − 21,25 = 858,75, davon 19 % = 163,1625 → 163,16 GBP.

10. Steuerbetrag in Buchungswährung und Umrechnungskurs

Für die Umsatzsteuer-Meldung beim Finanzamt reicht der Steuerbetrag in Fremdwährung nicht: Art. 230 der EU-Mehrwertsteuer-Systemrichtlinie (2006/112/EG) verlangt den Betrag zusätzlich in der Landeswährung des Verkäufers. Dafür gibt es drei zusammengehörige Angaben:

Code Feld Bedeutung
BT-6 TaxCurrency Die Buchungswährung selbst, hier EUR.
BT-111 TaxTotalAmountInAccountingCurrency Derselbe Steuerbetrag, in BT-6 umgerechnet: 183,14 EUR.
BG-X-41 TaxCurrencyExchange (Gruppe) Der Kurs, mit dem umgerechnet wurde.
BT-X-258 SourceCurrency Rechnungswährung, also BT-5 (GBP). Leitet FactoorSharp automatisch ab.
BT-X-259 TargetCurrency Buchungswährung, also BT-6 (EUR).
BT-X-260 ConversionRate Der eigentliche Kurs, hier 1,12244.
BT-X-261 ConversionRateTimestamp Kursdatum, optional. Hier der Tag der Lieferung, 25.11.2025.

Ohne BG-X-41 stünde nur das Ergebnis im Beleg, nicht der Weg dorthin – für eine Buchhaltung, die den Betrag nachrechnen oder gegen den Tageskurs prüfen will, ist genau das die fehlende Angabe.

Warum eine Methode für drei Business Terms? Weil die EN 16931-Geschäftsregel BR-53 fordert: Ist BT-6 vorhanden, muss BT-111 mitgeliefert werden. Und der Kurs in BG-X-41 ist die Rechtfertigung für den Wert in BT-111. Getrennte Setter hätten es erlaubt, einen Steuerbetrag in Buchungswährung zu setzen, ohne je zu sagen, mit welchem Kurs er entstanden ist – oder umgekehrt einen Kurs zu hinterlegen, der zu keinem gemeldeten Betrag passt.

Die frühere Methode SetTaxTotalInAccountingCurrency setzte nur BT-111 und BT-6, ohne Kurs. Sie wurde mit Version 20.0 entfernt; verwenden Sie SetTaxCurrencyExchange.

Zum Kurs selbst: BT-X-260 ist im Schema als reines xs:decimal ohne Stellenbegrenzung definiert, und die FeRD-Referenz schreibt fünf Nachkommastellen. Der Writer rundet deshalb adaptiv – auf zwei Stellen, wenn das verlustfrei möglich ist, sonst auf bis zu fünf – und gibt 1,12244 exakt wieder. Das Kursdatum steht wie alle Datumsfelder im UN/CEFACT-Format 102 (JJJJMMTT).

BG-X-41 gibt es nur im Profil EXTENDED und ausschließlich CII-seitig. UBL kennt mit cac:TaxExchangeRate zwar ein strukturell vergleichbares Element, das liegt aber außerhalb der EN 16931-CIUS und wird von FactoorSharp daher nicht bedient – siehe UBL vs. CII.

11. Zahlungsbedingungen

Zwei Stufen, hier bewusst als reiner Freitext mit Datum. Wie ein Skonto stattdessen maschinell auswertbar wird, zeigt die Warenrechnung.

12. Gesamtsummen

Alle Summen stehen in GBP. Neu gegenüber den anderen Beispielen ist die Anzahlung (BT-113), die vom Bruttobetrag abgezogen wird:

BT-Code Parameter Rechenweg (GBP)
BT-106 lineTotalAmount 850,00 (Positionssumme nach den beiden Abschlägen)
BT-108 chargeTotalAmount 30,00 (Einwegverpackung)
BT-107 allowanceTotalAmount 21,25 (Stammkundenrabatt)
BT-109 taxBasisAmount 850,00 + 30,00 − 21,25 = 858,75
BT-110 taxTotalAmount 858,75 × 19 % = 163,16
BT-112 grandTotalAmount 858,75 + 163,16 = 1.021,91
BT-113 totalPrepaidAmount 500,00. Wie einzelne Abschläge aufgeschlüsselt werden, steht unter Anzahlungen.
BT-115 duePayableAmount 1.021,91 − 500,00 = 521,91

13. Speichern und prüfen

Das Ergebnis muss dieselbe Baumstruktur haben wie X07_01_Fremdwaehrung.xml aus dem FeRD-Beispielpaket. Ob der Beleg darüber hinaus dem Regelwerk entspricht, prüfen Sie entweder im Browser oder direkt aus Ihrem Code heraus.

Ein Befund ist dabei erwartbar und stammt nicht aus dem Nachbau: Die FeRD-Referenz trägt als Leitweg-ID 04011000-1234512345-35, und deren Prüfziffer ist falsch. Der Wert ist zeichengenau aus der Vorlage übernommen, der Befund trifft die Vorlage also genauso. Wer die Rechnung als eigenen Beleg verwendet, setzt an dieser Stelle eine gültige Leitweg-ID ein.

Eine Lesefassung für Menschen erzeugt der Visualizer; wie daraus ein PDF/A-3 mit eingebettetem XML wird, steht unter Umgang mit PDF-Dateien.