返金レポートは Apple、Google、そしてあなたのサーバーの間で決して一致しない、その突き合わせ方

App Store Connect から返金件数を取り出し、次にあなたのサーバーから取り出すと、2 つの数字は一致しない。3 つ目を financial report から取り出しても、どちらとも一致しない。これは誰かのシステムのバグではない。Apple も Google もそれぞれ複数のチャネルで返金を報告し、各チャネルは返金の生涯の異なる瞬間を数え、あなたのサーバーは 4 つ目を見る。返金レポートを突き合わせようとして、合計が食い違うために諦めたことがあるなら、なぜ食い違うのか、どの数字をどの用途で信頼すべきか、そして月ではなく取引で揃える方法をここで説明する。

なぜ 1 件の返金が 3 つの異なる数字として現れるのか

1 件の返金は確定するまでにいくつものシステムを通り、各システムはそれを異なる瞬間に記録する。あなたのサーバーが最初にそれをイベントとして聞く。次に高速な分析レポートがそれを見積もる。会計レポートが最後に、お金が実際に動いた後で記録する。同じ返金、3 つのタイムスタンプ、3 つの合計。誤りは、そのうちの任意の 2 つを同じ日に等しくあるべきものとして扱うことだ。

Apple は 2 つのレポート群と、あなたの webhook を与える

Apple は返金を 2 つの場所で報告する。それらは同じツールではなく、ある日に一致させることを意図してもいない。Sales and Trends は高速な見積もりの視点だ。日次レポートは翌日、週次レポートは月曜日、月次レポートは月末のおよそ 5 日後、通常は Pacific 時間の 8 a.m. までに届く。前月の為替レートの移動平均を使って売上と収益を USD で見積もるため、傾向をつかむには向くが、支払いを突き合わせるには不向きだ。Payments and Financial Reports は確定後の視点だ。Apple の会計カレンダーで月に一度生成され、当会計月の最初の金曜日までに前会計月分が入手でき、その期間に購入または返金があった場合のみ生成される。あなたの支払いに適用される確定為替レートを使う。そのレポートが会計の記録だ。この両者に加えて、あなたのサーバーは Apple が返金を認めたその瞬間に、単一の transaction id をキーとする App Store Server Notification REFUND を受け取る。

Google も同じように分かれる

Google Play もこの分割を映し出す。earnings report は会計の記録で、月次で生成され、通常は翌月の 5 日までに入手でき、返金をそれぞれ独立した取引タイプとして並べる。買い手に返される金額は Charge refund、Google が返す手数料は Google fee refund で、いずれも Full か Partial のタグが付く。estimated sales report は低遅延の分析の視点で、買い手が税や手数料の前に支払った額を示す。Google はそれが分析に適し、会計には推奨しないとはっきり述べている。サーバー側では、リアルタイムの Real-time Developer Notification を受け取り、Voided Purchases API から返金を読み戻せる。

Apple がレポート内で返金をどう示すか、そしてマイナス行の罠

Summary Sales Report を開いても、返金は売上から静かに自分を差し引いたりしない。それは独立した 1 行として現れる。その行の Units と Customer Price はマイナスで、これがそもそも返金を見分ける手がかりであり、Developer Proceeds の数値は価格とは違う振る舞いをする。このレポートは本質的に返金を差し引いた純額ではない。返金行を売上行の隣に並べるだけで、それらを分類するのはあなたの仕事だ。Units 列を目視で合計すると、二重に数えるか、返金を丸ごと見落とすかのどちらかになる。マイナス 1 の返金行が、あなたのプラスの売上と同じ列にあるからだ。

実用的なルールは単純だ。マイナスの Units で返金を見つけ、それらの行だけを合計し、レポートがすでにあなたのために差し引き済みだと決して思い込まないこと。あなたの返金件数の端的な答えは、マイナス Unit の行の数であって、ある列の算術的な合計ではない。

会計カレンダーこそ、あなたの月次合計が決して揃わない理由だ

入念なスプレッドシートでもなお釣り合わないことの、最大にして唯一の理由がこれだ。Apple の財務レポートはカレンダー月では動かない。4-4-5 の会計カレンダーで動き、ほとんどの会計月は 4 週間、3 か月ごとに 5 週間になる。Financial Report を普通の 1 月から 1 月までの区間と比べる開発者は、異なる日数の 2 つの期間を比べているのであり、根底のどの数字が正しくても返金合計は一致しえない。Apple 自身のフォーラムの開発者たちは、まさにこの理由で Sales の数字と Financial Report の数字が数千ドル食い違うのを目にしてきた。放っておくほど毎月その差は広がっていった。

Google の earnings report は月次だが、独自のタイミングと独自のタイムゾーンを持ち、どちらもあなたのサーバーの UTC 時計ではない。より深い罠は両ストアに共通する。返金は元の売上の日付ではなく、確定した日付に帰属する。3 月の購入を 4 月初めに返金すると、それは 3 月ではなく 4 月の数字を減らす。2 つの月をラベルで揃えると、返金は一方から消えてもう一方に現れたように見える。

返金にいくらかかるのか、そしてどのレポートで読むべきか

突き合わせは本質的に会計の問題なので、お金を追う。返金ではストアが自らの手数料を返すので、実際にあなたの口座から出ていく額は、顧客が返されたと見る全額ではなく、その売上におけるあなたの取り分だ。Google Play ではその返しは目に見える 1 行だ。earnings report 上の Google fee refund の取引タイプはあなたに戻ってくる手数料であり、買い手に渡った Charge refund の隣に並ぶ。App Store では、Apple は手数料控除後のあなたの収益を差し引き、同じ動作で自らの手数料を返すので、financial report には Apple の取り分を差し引いた後の控除が表示される。

開発者が驚くのはキャッシュフローのタイミングだ。Google Play では、Google がその注文の分をあなたに支払う前に返金すると、あなたはその額を受け取らない。支払い後に返金すると、Google は将来の支払いから差し引く。そして返金の波で残高がマイナスになり、少なくとも 48 時間マイナスのままだと、Google は通常あなたの支払いを受け取る銀行口座から不足分を引き落とす。チャージバックは同じ出来事のより鋭い版だ。Google Play では、2026 年 8 月 3 日以降に行われた注文について、チャージバックは購入価格に銀行の手数料を加えた分を開発者に移し、売上よりも後の月のレポートに載る。

返金レポートを突き合わせる手順

すべての数字を等しくしようとするのをやめ、代わりに各数字をそれが答える問いに割り当てれば、この作業は単純になる。問いは 2 つだけだ。いくら金が動いたか、そして誰がまだアクセス権を持っているか。

• レポートを開く前に問いを決める。金額なら、答えは Apple の financial report と Google の earnings report にある。それだけだ。アクセスなら、答えはあなたのサーバー通知にある。一方をもう一方と突き合わせては決してならない。
• 4 つすべてのチャネルにまたがる結合キーとして transaction id を選ぶ。それは売上、その返金、各レポート、そしてあなたの webhook がすべて共有する唯一のフィールドだ。
• Apple では、Summary Sales Report とあなたの webhook が食い違うとき、App Store Server API の Get Refund History エンドポイント /inApps/v2/refund/lookup/{transactionId} を呼び出す。それは顧客の署名済み返金取引を revocationDate と revocationReason 付きで返し、transaction id を 1 件ずつ、その履歴をページ送りで返す。そのエンドポイントが決着をつける。
• Google では、earnings report 上の Charge refund の行を、同じ注文について Voided Purchases API が報告する内容と突き合わせ、部分返金は Partial とタグ付けされ、元の請求をゼロにしないことを覚えておく。
• 自分のではなく、レポートの時計に揃える。Apple のものは Pacific 時間の会計月だ。Google の earnings report には独自の月とタイムゾーンがある。あなたのログはほぼ確実に UTC だ。比べる前にレポートのカレンダーに変換する。さもないと日付の境界だけで幻の不一致が生まれる。
• 見積もりが動くことを見込む。Sales and Trends は見積もりであり、取引が確定するにつれて変わり続ける。financial report と突き合わせること。見積もりとは決して突き合わせず、昨日の見積もりのスナップショットとも決して突き合わせない。

サーバーがレポートより多くの返金を示すとき

最もよくある慌ては、同じ期間について、サーバー上の REFUND 通知が売上レポートの返金行より多いと気づくことだ。たいていお金が失われたわけではない。2 つのチャネルは異なる瞬間を数え、通知はレポートの行より数日早いことがあり、部分返金や再送信された要求は複数のイベントを生みうる。開発者はまさにこの形を報告してきた。同じ月について、数千件の REFUND 通知に対し、より少ない数のマイナス Unit の行だ。毎回同じ方法で解決する。サーバーが見た transaction id を取り、Get Refund History に通し、実際にどれが返金され、いくら返金されたかを Apple 自身の記録に決めさせる。

短い版

Apple の見積もり、Apple の financial report、Google の earnings report、そしてあなたの webhook のすべてを、同じ日に同じ返金合計にすることはできない。だからやめるべきだ。それぞれを、それが伝えるために作られたことのために読む。金額は financial report と earnings report を信頼し、アクセスはサーバー通知を信頼し、2 つのチャネルが争うときは transaction id で結合し、Get Refund History か Voided Purchases の照会に決着をつけさせる。突き合わせた返金とは、一致した合計のことではない。一致した取引のことだ。