Deine Refund-Berichte stimmen bei Apple, Google und deinem Server nie überein, so gleichst du sie ab

Ziehe die Refund-Zahl aus App Store Connect, ziehe sie dann von deinem Server, und die beiden Zahlen werden nicht übereinstimmen. Ziehe eine dritte aus deinem Financial Report, und sie passt zu keiner der beiden. Das ist kein Fehler in irgendjemandes System. Apple und Google berichten Rückerstattungen jeweils über mehr als eine Oberfläche, jede Oberfläche zählt einen anderen Moment im Leben der Rückerstattung, und dein Server sieht einen vierten. Wenn du je versucht hast, Refund-Berichte abzugleichen, und aufgegeben hast, weil die Summen auseinanderdriften, hier ist, warum sie driften, welcher Zahl du für welche Aufgabe vertraust und wie du sie transaktionsweise statt monatsweise ausrichtest.

Warum eine Rückerstattung als drei verschiedene Zahlen erscheint

Eine einzelne Rückerstattung durchläuft mehrere Systeme, bevor sie abgerechnet ist, und jedes System schreibt sie zu einem anderen Zeitpunkt nieder. Dein Server hört zuerst davon, als Ereignis. Ein schneller Analysebericht schätzt sie als Nächstes. Der Buchhaltungsbericht erfasst sie zuletzt, sobald das Geld tatsächlich geflossen ist. Dieselbe Rückerstattung, drei Zeitstempel, drei Summen. Der Fehler besteht darin, zwei von ihnen so zu behandeln, als müssten sie am selben Tag gleich sein.

Apple gibt dir zwei Berichtsfamilien, plus deinen Webhook

Apple berichtet Rückerstattungen an zwei Stellen, die nicht dasselbe Werkzeug sind und nicht dazu gedacht sind, an einem bestimmten Tag übereinzustimmen. Sales and Trends ist die schnelle, geschätzte Sicht: Tagesberichte kommen am Folgetag, Wochenberichte montags, Monatsberichte etwa fünf Tage nach Monatsende, in der Regel bis 8 a.m. Pacific. Es schätzt Umsatz und Erlöse in USD anhand eines gleitenden Durchschnitts der Wechselkurse des Vormonats, was gut ist, um einen Trend zu erkennen, und falsch, um eine Auszahlung abzustimmen. Payments and Financial Reports ist die abgerechnete Sicht: einmal im Monat nach Apples Geschäftskalender erzeugt, bis zum ersten Freitag des laufenden Geschäftsmonats für den vorherigen Geschäftsmonat verfügbar, und nur erzeugt, wenn es in diesem Zeitraum Käufe oder Rückerstattungen gab. Er verwendet den finalisierten Wechselkurs, der auf deine Auszahlung angewendet wird. Dieser Bericht ist die Buchhaltungsaufzeichnung. Neben beiden empfängt dein Server die App Store Server Notification REFUND in dem Moment, in dem Apple eine Rückerstattung gewährt, gebunden an eine einzelne transaction id.

Google teilt genauso auf

Google Play spiegelt die Aufteilung. Der earnings report ist die Buchhaltungsaufzeichnung, monatlich erzeugt und typischerweise bis zum 5. des Folgemonats verfügbar, und er führt Rückerstattungen als eigene Transaktionsarten auf: Charge refund für das an den Käufer zurückgegebene Geld und Google fee refund für die Servicegebühr, die Google zurückgibt, jeweils als Full oder Partial gekennzeichnet. Der estimated sales report ist die latenzarme Analysesicht, die zeigt, was Käufer vor Steuern und Gebühren bezahlt haben, und Google sagt klar, er eignet sich für Analysen und wird nicht für die Buchhaltung empfohlen. Auf der Serverseite erhältst du die Real-time Developer Notification in Echtzeit und kannst eine Rückerstattung über die Voided Purchases API zurücklesen.

Wie Apple eine Rückerstattung im Bericht zeigt, und die Negativzeilen-Falle

Öffne den Summary Sales Report, und eine Rückerstattung zieht sich nicht stillschweigend von einem Verkauf ab. Sie erscheint als eigene Zeile. Die Units und der Customer Price in dieser Zeile sind negativ, woran du eine Rückerstattung überhaupt erst erkennst, und die Developer Proceeds verhalten sich nicht so wie der Preis. Der Bericht ist nicht von Natur aus um Rückerstattungen bereinigt. Er listet Refund-Zeilen neben Verkaufszeilen, und es ist deine Aufgabe, sie zu sortieren. Summierst du die Units-Spalte nach Augenmaß, zählst du entweder doppelt oder verpasst die Rückerstattungen ganz, denn eine Minus-eins-Refund-Zeile steht in derselben Spalte wie deine positiven Verkäufe.

Die praktische Regel ist einfach: Finde Rückerstattungen über die negativen Units, addiere diese Zeilen für sich, und nimm nie an, der Bericht habe sie bereits für dich verrechnet. Eine als Featured Snippet taugliche Zählung deiner Rückerstattungen ist die Anzahl der Zeilen mit negativen Units, nicht die arithmetische Summe einer Spalte.

Der Geschäftskalender ist der Grund, warum deine Monatssummen nie zusammenpassen

Hier ist der wichtigste einzelne Grund, warum sich eine sorgfältige Tabelle dennoch weigert, aufzugehen. Apples Finanzberichte laufen nicht nach Kalendermonaten. Sie laufen nach einem 4-4-5-Geschäftskalender, in dem die meisten Geschäftsmonate vier Wochen haben und jeder dritte fünf Wochen. Ein Entwickler, der einen Financial Report mit einem schlichten Fenster von Januar zu Januar vergleicht, vergleicht zwei verschiedene Spannen von Tagen, sodass die Refund-Summen nicht übereinstimmen können, selbst wenn jede zugrunde liegende Zahl korrekt ist. Entwickler in Apples eigenen Foren haben beobachtet, wie Sales-Zahlen und Financial-Report-Zahlen genau aus diesem Grund um Tausende von Dollar auseinandergingen, wobei die Lücke jeden Monat größer wurde, in dem sie sich aufsummieren durfte.

Googles earnings report ist monatlich, aber er trägt sein eigenes Timing und seine eigene Zeitzone, und keines davon ist die UTC-Uhr deines Servers. Die tiefere Falle teilen sich beide Stores: Eine Rückerstattung wird dem Datum der Abrechnung zugeordnet, nicht dem Datum des ursprünglichen Verkaufs. Erstatte einen März-Kauf Anfang April zurück, und er senkt deine April-Zahlen, nicht deine März-Zahlen. Richte zwei Monate anhand ihrer Labels aus, und die Rückerstattung scheint aus dem einen verschwunden und im anderen aufgetaucht zu sein.

Was eine Rückerstattung kostet, und in welchem Bericht du sie liest

Der Abgleich ist im Kern eine Buchhaltungsfrage, also folge dem Geld. Bei einer Rückerstattung gibt der Store seine eigene Provision zurück, was bedeutet, dass der Betrag, der tatsächlich dein Konto verlässt, dein Anteil am Verkauf ist, nicht der volle Preis, den der Kunde zurückerstattet sieht. Bei Google Play ist diese Rückgabe eine sichtbare Zeile: Die Transaktionsart Google fee refund in deinem earnings report ist die an dich zurückkommende Servicegebühr, die neben dem Charge refund steht, der an den Käufer ging. Im App Store zieht Apple deine Erlöse nach Provision ab und gibt seine Provision in derselben Bewegung zurück, sodass der Financial Report den Abzug abzüglich Apples Anteil zeigt.

Beim Cashflow-Timing werden Entwickler überrascht. Bei Google Play erhältst du den Betrag schlicht nie, wenn du eine Bestellung erstattest, bevor Google dich dafür bezahlt hat. Erstattest du nach der Auszahlung, zieht Google ihn von einer künftigen Auszahlung ab. Und wenn eine Welle von Rückerstattungen deinen Saldo ins Negative drückt und er mindestens 48 Stunden negativ bleibt, belastet Google das Bankkonto, das normalerweise deine Auszahlungen empfängt, mit dem Fehlbetrag. Eine Rückbuchung ist die schärfere Version desselben Ereignisses: Bei Google Play verschiebt die Rückbuchung für Bestellungen ab dem 3. August 2026 den Kaufpreis plus die Gebühren der Bank auf den Entwickler, und sie landet auf dem Bericht eines späteren Monats als der Verkauf.

So gleichst du deine Refund-Berichte ab, Schritt für Schritt

Die Aufgabe wird einfach, sobald du aufhörst, jede Zahl gleich machen zu wollen, und stattdessen jede Zahl der Frage zuordnest, die sie beantwortet. Es gibt nur zwei Fragen: wie viel Geld sich bewegt hat und wer noch Zugriff hat.

• Entscheide die Frage, bevor du einen Bericht öffnest. Für Geld liegt die Antwort in Apples Financial Report und Googles earnings report, Punkt. Für Zugriff liegt die Antwort in deinen Server-Benachrichtigungen. Gleiche nie das eine gegen das andere ab.
• Wähle die transaction id als deinen Join-Schlüssel über alle vier Oberflächen. Sie ist das eine Feld, das ein Verkauf, seine Rückerstattung, die Berichte und dein Webhook alle teilen.
• Rufe bei Apple, wenn der Summary Sales Report und dein Webhook nicht übereinstimmen, den Get Refund History Endpunkt der App Store Server API unter /inApps/v2/refund/lookup/{transactionId} auf. Er gibt die signierten erstatteten Transaktionen für einen Kunden zurück, mit revocationDate und revocationReason, eine transaction id nach der anderen, und blättert durch ihre Historie. Dieser Endpunkt ist der Stichentscheid.
• Gleiche bei Google die Charge refund Zeilen im earnings report mit dem ab, was die Voided Purchases API für dieselben Bestellungen meldet, und denke daran, dass eine Teilrückerstattung als Partial gekennzeichnet ist und die ursprüngliche Abbuchung nicht auf null bringt.
• Richte dich nach der Uhr des Berichts, nicht nach deiner. Apples ist ein Geschäftsmonat in Pacific-Zeit. Googles earnings report hat seinen eigenen Monat und seine eigene Zeitzone. Deine Logs sind fast sicher UTC. Rechne auf den Kalender des Berichts um, bevor du vergleichst, sonst erzeugen schon die Tagesgrenzen allein Phantom-Abweichungen.
• Erwarte, dass sich die Schätzung bewegt. Sales and Trends ist eine Schätzung und verschiebt sich weiter, während Transaktionen abgerechnet werden. Gleiche gegen den Financial Report ab, nie gegen die Schätzung und nie gegen den gestrigen Schnappschuss der Schätzung.

Wenn dein Server mehr Rückerstattungen zeigt als der Bericht

Die häufigste Panik ist, mehr REFUND-Benachrichtigungen auf deinem Server zu finden als Refund-Zeilen im Verkaufsbericht für denselben Zeitraum. Es ist meist kein verlorenes Geld. Die beiden Oberflächen zählen verschiedene Momente, eine Benachrichtigung kann der Berichtszeile um Tage vorausgehen, und eine Teilrückerstattung oder eine erneut eingereichte Anfrage kann mehr als ein Ereignis erzeugen. Entwickler haben genau dieses Muster berichtet, Tausende von REFUND-Benachrichtigungen gegen eine geringere Zahl von Zeilen mit negativen Units für denselben Monat. Löse es jedes Mal gleich: Nimm die transaction ids, die dein Server gesehen hat, führe sie durch Get Refund History, und lass Apples eigene Aufzeichnung klären, welche tatsächlich erstattet wurden und um wie viel.

Die Kurzfassung

Du kannst Apples Schätzung, Apples Financial Report, Googles earnings report und deinen Webhook nicht dazu bringen, am selben Tag dieselbe Refund-Summe zu zeigen, und du solltest aufhören, es zu versuchen. Lies jeden für das, was er dir sagen soll. Vertraue dem Financial Report und dem earnings report für Geld, vertraue deinen Server-Benachrichtigungen für Zugriff, und wenn zwei Oberflächen streiten, verbinde sie über die transaction id und lass den Get Refund History oder Voided Purchases Lookup den Stichentscheid fällen. Abgeglichene Rückerstattungen sind keine übereinstimmenden Summen. Es sind übereinstimmende Transaktionen.