App-Käufe, In-App-Käufe und Umsatzsteuer

Digitale Produkte werden selten noch „direkt“ vom Entwickler an Endkunden verkauft. In App-Ökosystemen steht fast immer ein App-Store zwischen Entwickler und Nutzer: Er stellt die Oberfläche bereit, kuratiert Inhalte, verwaltet Kundenkonten, wickelt Zahlungen ab und erlässt Nutzungsbedingungen. Umsatzsteuerlich ist das nicht bloß Dekor. Entscheidend ist die Frage, wer gegenüber dem Endkunden als Leistender gilt und wo die Leistung steuerlich stattfindet. Genau hier setzt die jüngste Rechtsprechung des EuGH zur Dienstleistungskommission/Leistungskette an – und zwar nicht nur für die Zeit ab 2015 (seit Einführung von Art. 9a MwStVO und § 3 Abs. 11a UStG), sondern ausdrücklich auch für Altjahre vor dem 1. Januar 2015.

Für die Praxis kleiner Studios, Indie-Entwickler und App-/Games-Anbieter bringt das Urteil eine klare Orientierungslinie: Tritt der App-Store im Kaufprozess im eigenen Namen auf und steuert/autorisiert er die Zahlung, wird der Store umsatzsteuerlich als Anbieter fingiert. Der Entwickler erbringt seine Leistung in diesem Fall an den App-Store (B2B), der Store an den Endkunden (B2C). Das ist der Kern der Leistungskette – und der Grund, weshalb Rechnungsstellung, Leistungsort, Steuerlast und AGB-Architektur anders verlaufen als beim Direktverkauf.

Die alte Rechtslage bis 31.12.2014: Art. 28 MwStSystRL und § 3 Abs. 11 UStG

Schon vor 2015 galt der Grundsatz der Dienstleistungskommission (im Umsatzsteuerrecht üblicherweise „Leistungskette“): Handelt ein Unternehmer im eigenen Namen, aber für Rechnung eines anderen, wird steuerlich fingiert, dass zwei gleichartige Leistungen vorliegen. Zivilrechtlich vermittelt der Store ggf. „nur“ – steuerrechtlich kauft und verkauft er.

Die Systematik:

• Erster Umsatz: Entwickler (Kommittent) → App-Store (Kommissionär).
• Zweiter Umsatz: App-Store (Kommissionär) → Endkunde.

Jede dieser beiden fingierten Leistungen folgt eigenständig den allgemeinen Regeln (Leistungsort, Zeitpunkt, Bemessungsgrundlage, Steuerschuldnerschaft). Bei Services gilt für den ersten Umsatz (Entwickler → Store) regelmäßig die B2B-Grundregel: Leistungsort ist der Sitz des App-Stores; es greift also typischerweise Art. 44 MwStSystRL/§ 3a Abs. 2 UStG (Reverse-Charge-Logik bzw. Ortsverlagerung). Der zweite Umsatz (Store → Endkunde) wird dort besteuert, wo der Endkunde sitzt (B2C-Regime für elektronisch erbrachte Leistungen).

Der Knackpunkt in der Vor-2015-Rechtslage lag häufig in der Abgrenzung: tritt der Store im eigenen oder im fremden Namen auf? Und: reichen spätere Hinweise (z. B. in Bestellbestätigungen) aus, um ein fremdes Namenhandeln anzunehmen? Diese Unsicherheiten prägten viele Verfahren – und wurden im „Xyrality“-Fall vom EuGH aufgegriffen und bereinigt.

EuGH „Xyrality“ (C-101/24): Konsequente Anwendung der Leistungskette auch für Altjahre

Im Ausgangsfall (Streitjahre 2012–2014) wurde die App kostenfrei über einen irischen App-Store verteilt; In-App-Käufe (digitale Inhalte) wurden innerhalb der App über ein Store-Popup mit Store-Logo initiiert, die Zahlung lief vollständig über den App-Store, und der Store zog das Entgelt ein. Erst nach Abschluss erhielten Endkunden E-Mails, in denen die Entwicklerin als Leistende benannt und (fälschlich) deutsche Umsatzsteuer ausgewiesen wurde.

Der EuGH bestätigt drei praxistragende Punkte:

1. Leistungskette bejaht: Der App-Store gilt als Leistender gegenüber dem Endkunden, wenn er im Zeitpunkt der Leistungsausführung nicht ausdrücklich im fremden Namen handelt. Ein nachträglicher Hinweis in der Bestellbestätigung auf den Entwickler genügt nicht, um ein fremdes Namenhandeln zu begründen. Die Kundenwahrnehmung im Checkout und die Faktensouveränität über Zahlung/Abrechnung sind entscheidend.
2. Leistungsort B2B: Die fingierte Entwickler→Store-Leistung bleibt B2B. Der Leistungsort richtet sich nach Art. 44 MwStSystRL/§ 3a Abs. 2 UStG – also grundsätzlich am Sitz des Stores. Damit fällt für diesen Umsatz regelmäßig keine deutsche USt an, wenn der Store im EU-Ausland/Drittland sitzt.
3. § 14c UStG/Art. 203 MwStSystRL: Der fehlerhafte USt-Ausweis in den an Privatkunden gesandten Bestätigungen begründet keine Steuerschuld kraft Rechnung, weil keine Gefährdung des Steueraufkommens entsteht (Privatkunden haben keinen Vorsteuerabzug). Ob die Bestätigungen überhaupt Rechnungen i. S. d. Vorschrift sind, konnte dahinstehen; entscheidend ist der fehlende fiskalische Schaden.

Bemerkenswert ist die Brücke zur Zeit ab 2015: Der EuGH betont, dass Art. 9a MwStVO (seit 1. 1. 2015) kein neues Konzept ist, sondern den Inhalt von Art. 28 MwStSystRL verdeutlicht. Mit anderen Worten: Auch vor 2015 war bei Plattform-Zwischenschaltung und eigenem Auftreten des Stores im Kaufprozess die Leistungskette anzuwenden – genau das trägt die Entscheidung.

Die Rechtslage seit 1.1.2015: Art. 9a MwStVO und § 3 Abs. 11a UStG

Seit 2015 greift für elektronische Dienstleistungen über Schnittstellen/Portale (App-Stores, digitale Marktplätze) eine klare Fiktion: Die Plattform gilt als Leistender, wenn sie in die Erbringung der Dienstleistung eingeschaltet ist und typischerweise Zahlungsautorisierung/Abrechnung kontrolliert. Praktisch ist damit in B2C-Konstellationen nahezu immer der Store als Anbieter anzusehen – es sei denn, die Plattform tritt nachweisbar und deutlich „im fremden Namen“ auf und überlässt dem Entwickler den Vertragsschluss und die Zahlungsabwicklung.

Für Entwickler bedeutet dies:

• Standardfall bei Apple/Google: Store ist B2C-Anbieter; Entwickler erbringt B2B an den Store. Rechnung an den Store üblicherweise netto; keine deutsche USt, wenn Leistungsort am Store-Sitz liegt (Art. 44/§ 3a Abs. 2).
• Direktverkauf/Externe Zahlung (z. B. über eigene Website/Payment-Link): Entwickler wird selbst Anbieter gegenüber Endkunden; dann gelten die OSS/MOSS-Mechanismen und nationalen B2C-Regeln (Bestimmungslandprinzip für E-Services), inklusive Pflicht zu ordnungsgemäßen Belegen und USt-Abführung im Mitgliedstaat des Verbrauchs.

Kurz: Kontrolliert die Plattform den Checkout, wird sie steuerlicher Anbieter; kontrolliert der Entwickler den Checkout, wird er steuerlicher Anbieter. Dazwischen gibt es kaum „Hybridmodelle“, ohne dass Rollen, Vertragswerk und Nutzerführung vollkommen eindeutig ausgerichtet sind.

„Im eigenen oder im fremden Namen“ – was wirklich zählt

Ob ein Store im eigenen oder im fremden Namen auftritt, erschließt sich nicht aus späteren Dokumenten, sondern aus dem Kaufprozess selbst: Wer ist für den Kunden erkennbar Vertragspartner? Wer autorisiert die Zahlung? Wer stellt die Allgemeinen Bedingungen der Leistungserbringung? Wer entscheidet über Refunds und Fraud? Wer ermöglicht oder verweigert den Zugang zum digitalen Inhalt?

Die Praxis zeigt ein Muster:

• Store-Eigenauftreten liegt nahe, wenn der Nutzer zunächst ein Store-Konto benötigt, Store-AGB akzeptiert, Store-UI im Checkout dominiert und Store-Payment nutzt. Ein nachträglicher Hinweis „Leistender: Entwickler X“ ändert daran nichts – es fehlt die zeitgleiche Außendarstellung im Zeitpunkt der Leistung.
• Fremdnamens-Auftreten setzt voraus, dass bereits im Checkout erkennbar der Entwickler Vertragspartner wird, dessen AGB gelten, und dessen Zahlungskanal (Kasse/Rechnung) genutzt wird. Die Plattform ist dann – juristisch – eher technische Infrastruktur (z. B. Listing/Distribution), nicht aber Anbieter.

Die Schwelle für „im fremden Namen“ ist hoch. Es genügt nicht, in E-Mails oder PDFs später den Entwickler zu erwähnen. Maßgeblich ist die Erstkommunikation im Kaufmoment.

Folgen für Entwickler und kleine App-Unternehmen: Rechnungen, Steuer, Organisation

Rechnungsstellung:

• Bei Store-Eigenauftreten stellt der Store gegenüber dem Endkunden seine Rechnung/Beleg aus und führt die Umsatzsteuer im Käuferland ab. Der Entwickler rechnet gegenüber dem Store ab (Abrechnung/Settlement; ggf. eigene Rechnung an den Store ohne deutsche USt, mit Hinweis auf B2B/Art. 44).
• Beim Direktverkauf (eigene Kasse/externes Payment) stellt der Entwickler die Endkundenbelege aus, berücksichtigt das Bestimmungslandprinzip (OSS) und dokumentiert den Leistungsort.

Leistungsort/Steuerschuld:

• Entwickler→Store (B2B): Art. 44/§ 3a Abs. 2; regelmäßig kein deutscher USt-Ausweis.
• Store→Endkunde (B2C): Bestimmungsland; Store führt lokale USt/MwSt ab.
• § 14c UStG/Art. 203 MwStSystRL: Ein irrtümlicher deutscher USt-Ausweis in Belegen an Privatkunden begründet keine Steuerschuld, solange kein Vorsteuerrisiko besteht.

Vertrags/AGB-Architektur:

• Bei Store-Eigenauftreten müssen Entwickler-AGB klar auf B2B-Leistung an den Store ausgerichtet sein (Leistungsbeschreibung, Nutzungsrechte/Keys/API-Calls, Termination/Chargebacks, Abtretung/Inkasso, Reporting/Audit).
• Beim Direktverkauf braucht es Endkunden-AGB (B2C/B2B), Geo-Steuerlogik (OSS), Rechnungs-/Beleg-Pflichten, Widerrufs-/Digitale-Inhalte-Regeln, Kundendienst und Refund-Prozesse in eigener Regie.

Buchhaltung/Compliance:

• Store-only-Modelle sind steuerlich schlank (Abführung beim Store), erfordern aber saubere Verbuchung der Nettoerlöse (nach Provision und Steuerabzug).
• Hybrid/Direktmodelle verlangen USt-Know-how (OSS, Drittlandsumsätze, B2B-Abgrenzung), Systeme zur Belegausstellung und Geo-Preissteuerung.

Apple App Store & Google Play – wie die großen Stores das lösen

Apple und Google fungieren selbst als Anbieter im Endkundengeschäft, wenn Services über ihre Kassen laufen. Preis- und Steueranzeige erfolgen brutto; die Stores führen die zutreffende USt/MwSt im Käuferland ab und rechnen netto (abzgl. Provision) mit Entwicklern ab. Das reduziert die Steuer- und Rechnungsbelastung auf Entwicklerseite, verschiebt aber Vertrags- und Haftungsfragen (Refunds, Betrug, Chargebacks, AGB-Hoheit, Delistings) in Richtung Plattform.

Wird hingegen ein externer Zahlungsweg (z. B. „Kauf über Website des Entwicklers“) eröffnet, wechselt die umsatzsteuerliche Rolle: Der Entwickler wird gegenüber dem Endkunden selbst zum Anbieter – mit OSS-Pflichten und Belegerstellung. Entsprechend benötigen AGB, Checkout-Texte und Kundenkommunikation klare Rollenbilder: Wer verkauft? Wessen AGB? Wessen Rechnung? Je uneindeutiger, desto höher das Risiko, dass Steuer- und Zivilrollen auseinanderfallen.

Praxisleitfaden: Die wichtigsten Weichenstellungen

Ablauf festlegen: Wer kontrolliert die Kasse? Wer autorisiert die Zahlung? Wer stellt die Leistungsbedingungen? Antwortet man dreimal „Store“, ist die Wahrscheinlichkeit hoch, dass eine Leistungskette vorliegt und der Store steuerlicher Anbieter ist.

Kommunikation im Checkout: Eindeutige, frühzeitige Benennung des Vertragspartners ist Pflicht. Ein „Verstecken“ des Entwicklers/Stores bis zur Bestellmail schafft kein fremdes Namenhandeln.

AGB und Verträge synchronisieren: Entwickler-AGB für B2B-Leistung an den Store vs. Endkunden-AGB beim Direktverkauf. In Store-AGB darauf achten, dass Rechteketten (Lizenzen, Keys, DLC, virtuelle Währung) vollständig an den Store übertragen/nutzbar gemacht werden.

Rechnungslogik:

• Store-Eigenauftreten: Entwickler erstellt B2B-Belege an den Store (häufig nur Abrechnungsbelege des Stores, ggf. eigene Rechnung ohne USt; Art. 44).
• Direktverkauf: Endkundenbeleg mit OSS-Logik (z. B. USt-Sätze pro Mitgliedstaat, Nachweis der Kundenlokation).

§ 14c-Kontrolle: Bei falschem USt-Ausweis an Privatkunden – kein Automatismus zur Steuerschuld; dennoch Dokumentation und Korrektur vorsehen, um spätere Diskussionen zu vermeiden.

Technik & Beweisführung: Store-UI, Zahlungs-Flows, AGB-Screens und Checkout-Screens beweisbar archivieren. In Streitfällen zählt der Kaufzeitpunkt – nicht nachgereichte PDF-Hinweise.

Zusätzlicher Praxisabschnitt (≈ 500 Wörter): Plattformanbieter ohne Zwangs-Payment

Nicht jede Plattform ist Apple/Google. Viele digitale Marktplätze – etwa SaaS-Hubs, App-Stores für Shop-Systeme (z. B. Themes/Plugins), Add-on-Marktplätze für Tools, CMS oder Game-Mods – zwingen Entwickler nicht in ein zentrales Payment. Daraus folgt: Die umsatzsteuerliche Rolle ist gestaltbar, aber auch fehleranfällig.

Zielbild 1: Reiner Vermittler (Listing-/Discovery-Plattform)
Will eine Plattform nicht als steuerlicher Anbieter gelten, muss sie konsequent die Rolle eines reinen Vermittlers leben:

• Checkout-Ownership beim Entwickler: Der gesamte Zahlungsvorgang läuft außerhalb der Plattform – etwa über eine externe Kasse des Entwicklers oder einen direkten Zahlungslink. Die Plattform stellt kein eigenes Wallet/Kreditsystem bereit.
• Klarer Fremdnamens-Auftritt: Vor der Zahlung muss ersichtlich sein, dass der Entwickler Vertragspartner wird: Dessen AGB, Datenschutzhinweise und Widerrufsbelehrungen werden angezeigt; die Plattform weist deutlich auf reine Vermittlung hin.
• Kein faktisches Beherrschen der Leistung: Die Plattform autorisiert nicht die Zahlung, prüft keine Refunds im eigenen Namen, genehmigt nicht die Erbringung und legt nicht die allgemeinen Bedingungen der Leistungserbringung fest. Wo Moderation/Qualitätssicherung unabdingbar ist, sollte die Plattform prozessual dokumentieren, dass dies keine Anbieterrolle begründet (etwa rein kuratorisch, ohne Einfluss auf Preis, Steuer oder Lieferpflicht).
• Abrechnung: Die Plattform bezieht nur die Vermittlungsgebühr vom Entwickler (B2B). Der Entwickler fakturiert den Endkunden direkt (B2C/B2B) – inklusive OSS/USt im Bestimmungsland.

Zielbild 2: „Light-Reseller“ (mischt mit, will aber nicht der Verkäufer sein)
Viele Marktplätze möchten Kontroll- oder Komfortfunktionen (z. B. one-click buy, einheitliche Refund-Policy, „Käuferschutz“), ohne steuerlicher Anbieter zu werden. Gefahr: Je mehr die Plattform den Checkout „besitzt“, Zahlungen autorisiert, Nutzungsbedingungen vorgibt oder Lieferungen freigibt, desto eher liegt Eigenauftreten vor – und damit die Leistungskette zu Lasten der Plattform (sie gilt dann als Anbieter). Wer diesen Mittelweg wählt, muss streng trennen:

• Payments als reine PSP-Durchleitung mit technischem Pass-Through und eindeutiger Rechnung im Namen des Entwicklers.
• AGB: Plattform-AGB regeln nur Marktplatzregeln (z. B. Zulassung, Listing, Support-Standards), nicht die Leistungsbedingungen zwischen Entwickler und Endkunde.
• UX-Texte: Im Checkout steht sichtbar: „Vertragspartner: [Entwickler]“. Plattform-Logo darf präsent sein, aber nicht als Verkäufer erscheinen.
• Refunds/Chargebacks: Werden im Namen des Entwicklers abgewickelt; die Plattform entscheidet nicht „final“ über Leistungsstörungen.

Zielbild 3: Voll-Reseller (bewusst Anbieter)
Wer – aus Komfort, Trust oder Monetarisierung – bewusst als Anbieter auftreten will (z. B. um einheitliche Rechnungen zu stellen), sollte die Rolle aktiv annehmen:

• Eigenes Checkout, eigene Rechnungen an Endkunden, USt-Abführung im Käuferland (OSS).
• B2B-Einkauf beim Entwickler (Entwickler→Plattform: Art. 44/§ 3a Abs. 2), klare Reseller-Klauseln (Lizenzen, Gewährleistung, IP-Zuweisung, Export-Kontrollen).
• Steuer-Engine für B2C/B2B (Validierung USt-IdNr., Ortsbestimmung, Sätze/Exemptions), E-Rechnungspflichten beachten.

Fallstricke und To-dos:

• Grauzonen vermeiden: Mischmodelle („Manchmal Reseller, manchmal Vermittler“) sind möglich, aber pro Produkt/Verkaufsvorgang glasklar zu trennen. Inkonsistente UX-Texte („Jetzt bei [Plattform] kaufen“ vs. Rechnung durch Entwickler) laden zu Steuerrisikofeststellungen ein.
• Dokumentation: Checkout-Screens, AGB-Zustimmungen, Zahlungsflüsse, Refund-Policies revisionssicher archivieren. Die Frage „Wer war im Zeitpunkt des Kaufs erkennbar Verkäufer?“ entscheidet den Fall.
• § 14c/Art. 203-Risiko: Falscher USt-Ausweis gegenüber Unternehmern kann – anders als bei reinen Privatkundenfällen – sehr wohl zu Steuerschuld führen. Bei B2B-Ökosystemen sind saubere Rechnungen unverzichtbar (korrekte Sätze, korrekte Aussteller, Reverse-Charge-Hinweise).
• Preisgestaltung & Provision: Bei Reseller-Modellen ist die Bemessungsgrundlage der Endkundenumsatz (abzüglich Preisbestandteile nach Gesetz, nicht „Provisionen nach Belieben“).
• AGB-Kohärenz: Plattform-AGB (Marktplatzregeln) vs. Endkunden-AGB (Vertragspartner). Bei Vermittlung: Endkunden-AGB des Entwicklers sichtbar; bei Resale: Endkunden-AGB der Plattform.

Bottom line: Wer keinen Apple/Google-ähnlichen „Kassen-Monolithen“ betreibt, kann die steuerliche Rolle steuern – aber nur mit konsistenter Rollenentscheidung, klaren AGB, eindeutiger UX und belegbarer Zahlungslogik.

Häufige Missverständnisse – kurz entkräftet

• „Wenn der Entwickler irgendwo genannt ist, verkauft er doch auch?“ – Nein. Entscheidend ist die Außenwirkung im Kaufmoment. Spätere Hinweise sind irrelevant.
• „Art. 9a MwStVO gilt erst seit 2015, also davor keine Leistungskette.“ – Falsch. Der EuGH ordnet Art. 9a systematisch ein: Er verdeutlicht nur, was in Art. 28 MwStSystRL steckt.
• „Fehlerhafter deutscher USt-Ausweis führt immer zu § 14c-Schulden.“ – Nicht gegenüber Privatkunden ohne Vorsteuerabzug. Vorsicht aber bei B2B.
• „Reseller vs. Vermittler ist Geschmackssache.“ – Steuerlich ist es Folge der tatsächlichen Gestaltung. Die UI, die Kasse, die AGB und die faktische Kontrolle entscheiden – nicht das Label.

Umsetzungsschritte für Entwickler (App/Games)

1. Modell festlegen: Nur Store-Kasse oder zusätzliche externe Zahlung? Jedes Modell braucht eigene AGB/Steuer- und Beleglogik.
2. AGB aktualisieren:
   • Store-Modell: B2B-Leistung an den Store (Lizenz- und IP-Ketten, Haftung, Abrechnung, Prüf- und Auditklauseln).
   • Direktverkauf: Endkunden-AGB (digitale Inhalte, Updates, Gewährleistung, Widerruf/„digital content“), USt-Regeln (OSS) und Rechnungs-/E-Rechnungspflichten.
3. Rechnung & Buchung: Store-Abrechnungen sauber als B2B-Umsatz verbuchen (Provisionsabzug, Gebühren, Währungsumrechnung, Zeitpunkt).
4. Beweisführung: Checkout-Flows und Screens fotografieren/archivieren. Im Zweifel entscheidet der Screenshot.
5. § 14c-Krisenplan: Verfahren zur Belegkorrektur und Kommunikation (Kundenservice) definieren, sollte irgendwo eine falsche USt auftauchen.

Fazit

Die Leistungskette ist im digitalen Vertrieb kein Nischenthema, sondern die Regel, sobald eine Plattform sichtbar den Kaufprozess beherrscht. Das EuGH-Urteil „Xyrality“ bestätigt für Altjahre und aktuelle Fälle gleichermaßen: Wer im eigenen Namen auftritt und die Kasse kontrolliert, gilt als Leistender. Für Entwickler heißt das: Mit Store-Kasse wird B2B an den Store abgerechnet; bei eigenem Checkout ist die eigene USt-Engine Pflicht. Plattformanbieter außerhalb des Apple/Google-Modells können die Rolle gestalten – aber nur, wenn Checkout, AGB und Abrechnung konsistent beweisen, dass der Entwickler (und nicht der Marktplatz) der Verkäufer ist. Eine klare Entscheidung für Reseller oder Vermittler spart Diskussionen mit der Finanzverwaltung, schützt vor § 14c-Risiken und schafft belastbare Prozesse – in Games, Apps, SaaS-Ökosystemen und darüber hinaus.

Author: Marian Härtel

Marian Härtel ist Rechtsanwalt und Fachanwalt für IT-Recht mit einer über 25-jährigen Erfahrung als Unternehmer und Berater in den Bereichen Games, E-Sport, Blockchain, SaaS und Künstliche Intelligenz. Seine Beratungsschwerpunkte umfassen neben dem IT-Recht insbesondere das Urheberrecht, Medienrecht sowie Wettbewerbsrecht. Er betreut schwerpunktmäßig Start-ups, Agenturen und Influencer, die er in strategischen Fragen, komplexen Vertragsangelegenheiten sowie bei Investitionsprojekten begleitet. Dabei zeichnet sich seine Beratung durch einen interdisziplinären Ansatz aus, der juristische Expertise und langjährige unternehmerische Erfahrung miteinander verbindet. Ziel seiner Tätigkeit ist stets, Mandanten praxisorientierte Lösungen anzubieten und rechtlich fundierte Unterstützung bei der Umsetzung innovativer Geschäftsmodelle zu gewährleisten.