Wer in der DACH-Region mit Shopify verkauft, kennt das Problem: Die Bestellung kommt in Euro rein, die Auszahlung landet als Sammelbetrag auf dem Bankkonto, und irgendwo dazwischen verschwindet eine Währungsumrechnung. Bislang ließ sich dieser Vorgang in der GraphQL Admin API nur indirekt rekonstruieren — über Balance Transacts, Payouts und den Abgleich mehrerer Felder, die zusammen einen Umrechnungsvorgang ergaben, ohne ihn je beim Namen zu nennen. Mit API-Version 2026-10 ändert sich das: Der Enum ShopifyPaymentsTransactionType enthält jetzt den Wert CURRENCY_CONVERSION.
Klingt nach einem Detail für Entwickler. Ist es aber nicht. Denn der neue Typ legt offen, was viele Händler bisher nur geschätzt haben: wie viel Geld Shopify Payments bei jeder Fremdwährungsbestellung tatsächlich einbehält — und wo diese Kosten in der Buchhaltung auftauchen.
Warum war die Umrechnung bisher ein blinder Fleck?
Shopify Payments bündelt Auszahlungen. Ein Händler mit Bestellungen in Schweizer Franken, US-Dollar und Euro erhält am Ende einen Payout in seiner Auszahlungswährung — meist Euro. Die einzelnen Umrechnungen wurden in der Balance Transaction-Historie als Ereignisse geführt, aber nicht als eigener, klar benannter Transaktionstyp ausgewiesen.
Das führte zu einem bekannten Rechnungslegungs-Problem. Buchhalter mussten Umrechnungsverluste aus einer Mischung aus Kursdifferenzen, Gebührenfeldern und Payout-Deltas rekonstruieren. Wer eine saubere Debitoren- und Kreditorenbuchhaltung nach SKR03 oder SKR04 fährt, weiß, wie unangenehm das ist: Jede Fremdwährungstransaktion muss korrekt in Berichtswährung abgebildet werden, und Kursgewinne wie Kursverluste gehören auf getrennte Konten.
Mit CURRENCY_CONVERSION lässt sich nun jeder Umrechnungsvorgang direkt über die Admin API abfragen, filtern und einer Bestellung oder einem Payout zuordnen. Statt Indizien zu sammeln, gibt es einen expliziten Typ.
Wie funktioniert der neue Typ in der Praxis?
Der Zugriff läuft über die übliche Balance-Transaktion-Struktur. Händler und Agenturen, die die GraphQL Admin API nutzen, können Transaktionen künftig nach type: CURRENCY_CONVERSION filtern und erhalten die Rechengrößen für den Umrechnungsvorgang: den Ursprungsbetrag, den Zielbetrag und — je nach Feldsatz — den impliziten Kurs über das Verhältnis beider Werte.
Für Integratoren ist das der entscheidende Hebel. Wer beispielsweise ein Reporting-Tool für DACH-Händler baut, kann Umrechnungsverluste jetzt zeilenweise ausweisen statt als Sammelposten. Ein Muster: Bestellung in CHF, Auszahlung in EUR, dazwischen ein CURRENCY_CONVERSION-Datensatz. Der Kurs ergibt sich aus Ziel- dividiert durch Ursprungsbetrag — exakt der Wert, den die Buchhaltung für die Umrechnung braucht.
Wer die Umrechnung nicht trennt, kennt seinen Deckungsbeitrag im Ausland nicht — er kennt nur die Marge nach einem Sammelabzug.
Interessant ist der Typ auch für Händler, die selbst in mehreren Währungen abwickeln. Wer in der Schweiz, in Österreich und in Deutschland mit lokalen Preisen arbeitet, erzeugt zwangsläufig Währungspaare. Ohne saubere Trennung der Umrechnungsvorgänge bleibt der wahre Preis der Internationalisierung unsichtbar.
Was bedeutet das für DACH-Händler konkret?
Die drei Länder der Region sind unterschiedlich betroffen. Deutschland mit Euro als Auszahlungswährung spürt den Effekt vor allem bei Bestellungen in USD, GBP oder CHF. Österreich und die Schweiz haben es härter: Der Schweizer Franken ist keine Euro-Währung, und wer aus der Schweiz in die EU verkauft, trägt jede Umrechnung doppelt — einmal beim Kunden in EUR, einmal bei der eigenen Auszahlung in CHF.
Relevant wird das auch für die Mehrwertsteuerlogik. Die Umrechnung innerhalb von Shopify Payments hat nichts mit der steuerlichen Umrechnung für die Umsatzsteuer zu tun — aber beide Vorgänge müssen in der Buchhaltung getrennt abgebildet werden. Ein sauber benannter Transaktionstyp erleichtert diese Trennung erheblich, weil er im Journal klar von steuerlichen Umrechnungen unterscheidbar ist.
- Reporting: Umrechnungsverluste lassen sich pro Währungspaar und Zeitraum aggregieren, statt als undifferenzierter Gebührenblock zu erscheinen.
- Preisgestaltung: Wer weiß, was die Umrechnung kostet, kann Fremdwährungspreise bewusst kalkulieren — statt sie als Rundungsfehler zu behandeln.
Ein Hinweis für alle, die automatisierte Auszahlungs- oder Rechnungsstellungssysteme betreiben: Bestehende Skripte, die den Transaktionstyp filtern, dürfen den neuen Wert nicht als unbekanntes Feld behandeln. Zwar ist das Hinzufügen eines Enum-Werts grundsätzlich rückwärtskompatibel, aber Anwendungen, die einen erschöpfenden Switch über bekannte Typen führen und bei Unbekanntem einen Fehler werfen, brechen. Das ist ein klassisches Integrationsrisiko bei Schema-Erweiterungen.
Ein Detail, das mehr ist als ein Detail
Shopify erweitert die Payments-API seit Jahren in kleinen Schritten. Ein neuer Enum-Wert wirkt unspektakulär. Aber er schließt eine Lücke, die gerade für internationale Händler teuer war: die fehlende Transparenz über Währungsumrechnungen.
Wer im DACH-Raum über Grenzen verkauft, sollte jetzt prüfen, ob die eigene Finanz- und Reportinglogik den neuen Typ bereits nutzt — oder ob sie weiter mit Schätzungen arbeitet. Auf Shopify.dev ist der Typ dokumentiert; die Umstellung ist kein großer Eingriff, aber ein wichtiger. Wer die Umrechnung nicht sichtbar macht, verliert Geld im Blindflug. Wer sie sichtbar macht, kann international kalkulieren.