Öffnen Sie App Store Connect oder die Google Play Console, und Sie sehen eine Zahl, die sich wie Ihr Umsatz anfühlt. Letzten Monat stand dort 10.000 €. Ihr Bankkonto hat 7.000 € erhalten. Keine der Zahlen ist falsch – aber nur eine von ihnen gehört in Ihre Gewinn- und Verlustrechnung als „Umsatz“, und wenn Sie diese Entscheidung falsch treffen, kann dies leise Ihre Bruttomarge verzerren, Ihre Wachstumsrate falsch darstellen und einem Kreditgeber oder Investor ein Bild Ihres Unternehmens vermitteln, das nicht der Wahrheit entspricht.
Dies ist die Frage nach Prinzipal versus Agent, und nach dem US-GAAP-Standard ASC 606 zur Umsatzrealisierung ist sie kein optionales Papier – sie ist die Regel, die entscheidet, ob Sie 10.000 € Umsatz und 3.000 € Kosten der umsatzgenerierung ausweisen oder nur 7.000 € Umsatz ohne weitere Angaben. Für einen Indie-Entwickler, der über den Apple App Store oder den Google Play Store verkauft, überrascht die Antwort die meisten Leute.
Die Frage, die sich jeder App-Entwickler irgendwann stellt
Der Auslöser ist fast immer derselbe: Ein Gründer erstellt einen Pitch Deck, beantragt einen Kleinunternehmenskredit oder versucht nur zu beantworten „Wie viel habe ich in diesem Quartal eigentlich verdient?“, und stellt fest, dass er bisher immer das als „Umsatz“ verbucht hat, was auf seinem Bankkonto gelandet ist. Diese Zahl ist bereits netto von Apples oder Googles Provision – das heißt, der Anteil der Plattform wurde bereits abgezogen.
Das Problem ist, dass die Nettodarstellung Ihres Umsatzes gegen eine Plattformgebühr keine stilistische Wahl ist. ASC 606 hat einen spezifischen Test genau für diese Situation, und er hängt von einer Frage ab: Wer kontrolliert die verkaufte Sache, bevor sie den Besitzer zum Kunden wechselt?
Der ASC 606-Kontrolltest, einfach erklärt
Das Fünf-Schritte-Umsatzmodell von ASC 606 verlangt, dass Sie die Leistungsverpflichtungen in einem Vertrag identifizieren und bestimmen, wer sie erfüllt. Wenn ein Marktplatz oder eine Plattform zwischen Ihnen und dem Endkunden steht – Apple, Google, Etsy, DoorDash, Uber – nennen die Rechnungslegungsstandards dies die Prinzipal-versus-Agent-Bewertung, und PwCs Umsatzleitfaden stellt fest, dass App-Store-Verkäufe ein Lehrbuchbeispiel für Vereinbarungen sind, die diese sorgfältige Prüfung erfordern.
- Prinzipal: Sie kontrollieren die Ware oder Dienstleistung, bevor sie auf den Kunden übergeht. Sie erkennen den vollen, Bruttobetrag, den der Kunde gezahlt hat, als Umsatz, und die Provision der Plattform wird zu einem Kosten der umsatzgenerierung (einem Aufwand), nicht zu einer Minderung des Umsatzes.
- Agent: Die Plattform kontrolliert das Angebot, und Sie vermitteln lediglich den Verkauf im Namen eines anderen. Sie erkennen nur den Nettobetrag, den Sie als Ihre Gebühr behalten, als Umsatz.
Drei Indikatoren entscheiden, welcher Sie sind, gemäß den Rahmenwerken von Deloitte und PwC:
- Verantwortung für die Erfüllung – Wer ist verantwortlich, wenn die App nicht funktioniert, das Abonnement nicht geliefert wird oder ein Kunde sich beschwert? Das sind normalerweise Sie, der Entwickler, nicht Apple.
- Risiko vor dem Übergang – Wer trägt das Risiko, dass das „Inventar“ (Ihre App, Ihre Inhalte, Ihre Abonnementstufe) sich nicht verkauft oder den Kunden nicht zufriedenstellt? Auch hier normalerweise Sie.
- Preisgestaltungsspielraum – Wer legt fest, was der Kunde tatsächlich zahlt? Sie wählen die Preisstufe Ihrer App; die Plattform verhandelt diese nicht mit Ihnen von Fall zu Fall.
Da die meisten Indie-Entwickler das Produkterlebnis kontrollieren, die Kundenbeziehung für Support und Updates besitzen und ihre eigenen Preise festlegen, landen sie auf der Prinzipal-Seite des Tests – was bedeutet, dass die korrekte Buchhaltung darin besteht, den Bruttobetrag, den der Kunde gezahlt hat, als Umsatz zu erfassen und Apples oder Googles Anteil als Kosten der umsatzgenerierung zu behandeln, nicht als unsichtbaren Abschlag.
Die Zahlen hinter dem Abschlag
Zu wissen, dass Sie der Prinzipal sind, hilft nur, wenn Sie wissen, was tatsächlich abgezogen wird. Die Strukturen der Plattformgebühren haben sich in den letzten Jahren erheblich verändert, und die meisten Entwickler budgetieren immer noch auf Basis veralteter Annahmen:
| Plattform | Standardsatz | Ermäßigter Satz | Wer qualifiziert sich |
|---|---|---|---|
| Apple App Store | 30 % | 15 % (App Store Small Business Program) | Entwickler mit ≤ 1 Mio. € jährlichen App-Store-Einnahmen |
| Apple-Abonnements | 30 % (Jahr 1) | 15 % (Jahr 2 und folgende) | Jedes Abonnement nach den ersten 12 Monaten |
| Google Play | 30 % | 15 % auf die ersten 1 Mio. € pro Jahr verdient | Alle Entwickler, automatisch gestaffelt |
| Google Play-Abonnements | 15 % pauschal | — | Alle Abonnement-Einnahmen |
| Apple EU (Bedingungen des Digital Markets Act) | ~17 % + Core Technology Fee | bis zu ~20 % insgesamt | Entwickler, die sich für die alternativen EU-Geschäftsbedingungen entscheiden |
Hinzu kommen jährliche Pauschalbeträge, die die meisten Leute vergessen, irgendwo zuzuordnen: Apples jährliche Entwicklerprogrammgebühr von 99 € und Googles einmalige Registrierungsgebühr von 25 €. Klein, aber sie gehören auch irgendwo in Ihren Kontenplan – normalerweise als allgemeine Betriebsausgaben, nicht als Kosten der umsatzgenerierung.
Korrekte Verbuchung: Ein durchgerechnetes Beispiel
Angenommen, ein Kunde kauft ein In-App-Abonnement für 9,99 € über Apple, und Sie unterliegen dem Standardsatz von 30 %. Apple kassiert die 9,99 € vom Kunden, behält 3,00 € und zahlt schließlich 6,99 € auf Ihr Bankkonto ein. Die Verbuchung von 6,99 € als „Umsatz“ würde Ihre oberste Linie um 30 % unterbewerten – was enorm wichtig ist, wenn Sie Ihre Wachstumsrate mit einem Wettbewerber vergleichen, der direkt verkauft, oder Ihre Margen einem Kreditgeber erklären.
Die korrekten Buchungen erfassen den vollen Verkauf und buchen dann die Provision separat als Aufwand:
2026-07-18 * "Apple" "iOS-Abonnement — Bruttoverkauf"
Assets:Receivable:AppStore 9.99 USD
Income:AppSales -9.99 USD
2026-07-18 * "Apple" "30 % App Store Provision"
Expenses:CostOfRevenue:PlatformFees 3.00 USD
Assets:Receivable:AppStore -3.00 USD
2026-07-20 * "Apple" "Auszahlung erhalten"
Assets:Checking 6.99 USD
Assets:Receivable:AppStore -6.99 USDBeachten Sie, dass sich das Forderungskonto auf Null saldiert, sobald die Auszahlung abgewickelt ist, aber Ihre Gewinn- und Verlustrechnung zeigt weiterhin 9,99 € Umsatz und 3,00 € Kosten der umsatzgenerierung – eine Bruttomarge von 70 % bei diesem Verkauf, nicht eine mysteriös verschwundene 30 %. Dies ist genau die Art von Transaktion, die Klartext-, versionskontrollierte Hauptbücher gut handhaben: Der Bruttoverkauf, die Plattformgebühr und die Auszahlung sind drei separate, prüfbare Ereignisse anstelle einer einzigen verschwommenen Bankeinzahlung.
Warum die Dashboard-Zahl nicht ausreicht
Selbst wenn Sie die Regel kennen, ist die manuelle Anwendung schwieriger, als es klingt. Standardmäßige App Store Connect- und Play Console-Berichte zeigen aggregierte Summen, nicht die Abonnenten- und Transaktionsdetails, die ASC 606 technisch verlangt – Erlöse, Rückerstattungen und Währungsumrechnungen landen oft als einzelner Pauschalbetrag Tage oder Wochen nach dem tatsächlichen Verkauf. Diese Lücke ist genau der Grund, warum eine wachsende Zahl von Abonnement-App-Unternehmen Plattform-APIs oder Tools wie RevenueCat verwenden, um Transaktionsdetails zu rekonstruieren, anstatt zu versuchen, sie aus einer monatlichen Zusammenfassungs-PDF zurückzuentwickeln.
Diesen Schritt zu überspringen, hat reale Kosten. Ein vielzitiertes Beispiel: Ein Entwickler sah 3.400 € in seinem Dashboard für den Monat, und nach Provisionen, Steuern und anderen Plattformabzügen waren nur 1.294 € verfügbar – eine Lücke von über 60 % zwischen dem „Umsatz“, den er zu haben glaubte, und dem, was das Unternehmen tatsächlich behielt. Entwickler, die Einstellungs- oder Ausgabenentscheidungen auf Basis der Dashboard-Zahl treffen, anstatt der abgeglichenen Zahl, budgetieren gegen eine Zahl, die nie real war.
Häufige Fehler, die Ihre Bücher verzerren
- Nur die Nettoeinzahlung als Umsatz verbuchen. Dies ist der häufigste Fehler und der, um den es in diesem Artikel geht – er unterbewertet sowohl den Umsatz als auch die Kosten der umsatzgenerierung und macht Ihre Bruttomargendarstellung bedeutungslos.
- Rückerstattungen und Rückbuchungen ignorieren. Apple und Google wickeln beide Kundenrückerstattungen in Ihrem Namen ab, manchmal Wochen nach dem ursprünglichen Verkauf – wenn Sie nicht transaktionsbezogen abgleichen, können rückerstattete Umsätze unbegrenzt in Ihren Büchern bleiben.
- Die 99-€-Apple-Entwicklergebühr oder die 25-€-Google-Registrierungsgebühr in die Kosten der umsatzgenerierung mischen. Dies sind fixe Betriebskosten, keine transaktionsbezogenen Provisionen – sie gehören in einen völlig anderen Aufwandsposten.
- Das separate EU-Gebührensystem vergessen. Wenn ein Teil Ihrer Nutzerbasis in der EU ist und Sie sich für Apples alternative Bedingungen entschieden haben, haben diese Einnahmen eine andere Provisionsstruktur als der Rest Ihres Geschäfts und benötigen ein eigenes Konto.
Halten Sie Ihre Finanzen organisiert, während Sie wachsen
Egal, ob Sie ein Solo-Entwickler mit einer einzigen App im Store sind oder ein kleines Studio mit ein paar Abonnementprodukten betreiben, die Brutto-vs.-Netto-Entscheidung summiert sich jeden Monat, den Sie sie falsch machen – wenn Sie eine Finanzierungsrunde aufnehmen oder einen Kredit beantragen, ist eine unterbewertete Umsatzlinie schwer zu erklären. Beancount.io bietet Entwicklern ein Klartext-, versionskontrolliertes Hauptbuch, das genau für diese Art von mehrstufigen Transaktionen entwickelt wurde – Bruttoverkauf, Plattformprovision und Auszahlung als drei separate, prüfbare Einträge anstelle einer einzigen verschwommenen Bankeinzahlung. Starten Sie kostenlos und sehen Sie, warum Entwickler, die bereits in Code denken, eine Buchhaltung bevorzugen, die auf die gleiche Weise funktioniert.