Laporan refund Anda tidak pernah cocok antara Apple, Google, dan server Anda, begini cara merekonsiliasinya

Tarik jumlah refund dari App Store Connect, lalu tarik dari server Anda, dan kedua angka itu tidak akan cocok. Tarik yang ketiga dari laporan keuangan Anda dan itu juga tidak akan cocok dengan keduanya. Ini bukan bug di sistem siapa pun. Apple dan Google masing-masing melaporkan refund melalui lebih dari satu permukaan, setiap permukaan menghitung momen yang berbeda dalam hidup sebuah refund, dan server Anda melihat yang keempat. Jika Anda pernah mencoba merekonsiliasi laporan refund dan menyerah karena totalnya berpencar, inilah alasan mereka berpencar, angka mana yang harus dipercaya untuk pekerjaan mana, dan cara menyejajarkannya per transaksi alih-alih per bulan.

Mengapa satu refund muncul sebagai tiga angka berbeda

Satu refund melewati beberapa sistem sebelum diselesaikan, dan setiap sistem mencatatnya pada saat yang berbeda. Server Anda mendengarnya lebih dulu, sebagai sebuah peristiwa. Laporan analitik cepat mengestimasinya berikutnya. Laporan akuntansi mencatatnya terakhir, setelah uang benar-benar berpindah. Refund yang sama, tiga cap waktu, tiga total. Kesalahannya adalah memperlakukan dua di antaranya seolah harus sama pada hari yang sama.

Apple memberi Anda dua keluarga laporan, plus webhook Anda

Apple melaporkan refund di dua tempat yang bukan alat yang sama dan tidak dimaksudkan untuk cocok pada hari tertentu. Sales and Trends adalah tampilan cepat dan estimasi: laporan harian tiba keesokan harinya, laporan mingguan pada hari Senin, laporan bulanan sekitar lima hari setelah bulan berakhir, umumnya pukul 8 pagi waktu Pacific. Ia mengestimasi penjualan dan pendapatan dalam USD memakai rata-rata bergerak kurs bulan sebelumnya, yang membuatnya bagus untuk menangkap tren dan keliru untuk mencocokkan pembayaran. Payments and Financial Reports adalah tampilan terselesaikan: dibuat sekali sebulan pada kalender fiskal Apple, tersedia paling lambat Jumat pertama bulan fiskal berjalan untuk bulan fiskal sebelumnya, dan dibuat hanya jika ada pembelian atau refund pada periode itu. Ia memakai kurs final yang diterapkan pada pembayaran Anda. Laporan itu adalah catatan akuntansi. Bersamaan dengan keduanya, server Anda menerima App Store Server Notification REFUND pada saat Apple memberikan refund, terkait dengan satu transaction id.

Google terbagi dengan cara yang sama

Google Play mencerminkan pembagian yang sama. Earnings report adalah catatan akuntansi, dibuat bulanan dan biasanya tersedia paling lambat tanggal 5 bulan berikutnya, dan ia mencantumkan refund sebagai jenis transaksinya sendiri: Charge refund untuk uang yang dikembalikan ke pembeli dan Google fee refund untuk biaya layanan yang Google kembalikan, masing-masing ditandai Full atau Partial. Estimated sales report adalah tampilan analitik berlatensi rendah yang menunjukkan apa yang dibayar pembeli sebelum pajak dan biaya, dan Google menyatakan terus terang bahwa itu cocok untuk analitik dan tidak disarankan untuk akuntansi. Di sisi server Anda memperoleh Real-time Developer Notification secara real-time dan dapat membaca kembali sebuah refund dari Voided Purchases API.

Bagaimana Apple menampilkan refund di dalam laporan, dan jebakan baris negatif

Buka Summary Sales Report dan sebuah refund tidak diam-diam mengurangi dirinya dari sebuah penjualan. Ia muncul sebagai barisnya sendiri. Units dan Customer Price pada baris itu negatif, itulah cara Anda mengenali sebuah refund sama sekali, dan angka Developer Proceeds tidak berperilaku seperti harga. Laporan itu pada dasarnya tidak dikurangi refund. Ia mencantumkan baris refund di samping baris penjualan, dan tugas Andalah mengelompokkannya. Jumlahkan kolom Units dengan mata dan Anda akan menghitung ganda atau melewatkan refund sepenuhnya, karena baris refund minus satu berada di kolom yang sama dengan penjualan positif Anda.

Aturan praktisnya sederhana: temukan refund lewat Units negatif, jumlahkan baris-baris itu sendiri, dan jangan pernah berasumsi laporan sudah mengurangkannya untuk Anda. Jumlah refund Anda untuk featured snippet adalah banyaknya baris ber-Units negatif, bukan jumlah aritmetika sebuah kolom.

Kalender fiskal adalah alasan total bulanan Anda tidak pernah sejajar

Inilah alasan tunggal terbesar mengapa spreadsheet yang teliti pun tetap menolak seimbang. Laporan keuangan Apple tidak berjalan pada bulan kalender. Ia berjalan pada kalender fiskal 4-4-5, di mana sebagian besar bulan fiskal berdurasi empat minggu dan setiap bulan ketiga berdurasi lima minggu. Seorang pengembang yang membandingkan Financial Report dengan jendela Januari-ke-Januari biasa sedang membandingkan dua rentang hari yang berbeda, jadi total refund tidak mungkin cocok bahkan ketika setiap angka dasarnya benar. Pengembang di forum Apple sendiri telah menyaksikan angka Sales dan angka Financial Report berpencar ribuan dolar persis karena alasan ini, dengan selisih melebar setiap bulan mereka membiarkannya menumpuk.

Earnings report Google bersifat bulanan, tetapi ia membawa penentuan waktunya sendiri dan zona waktunya sendiri, dan keduanya bukan jam UTC server Anda. Jebakan yang lebih dalam berlaku di kedua toko: sebuah refund diatribusikan ke tanggal penyelesaiannya, bukan tanggal penjualan awal. Refund sebuah pembelian Maret di awal April dan itu mengurangi angka April Anda, bukan angka Maret Anda. Sejajarkan dua bulan berdasarkan labelnya dan refund itu tampak lenyap dari satu bulan dan muncul di bulan lain.

Berapa biaya sebuah refund, dan di laporan mana membacanya

Rekonsiliasi sebenarnya adalah pertanyaan akuntansi, jadi ikuti uangnya. Pada sebuah refund, toko mengembalikan komisinya sendiri, artinya jumlah yang benar-benar keluar dari akun Anda adalah bagian Anda dari penjualan, bukan harga penuh yang pelanggan lihat dikembalikan. Di Google Play pengembalian itu adalah baris yang terlihat: jenis transaksi Google fee refund di earnings report Anda adalah biaya layanan yang kembali kepada Anda, berdampingan dengan Charge refund yang pergi ke pembeli. Di App Store, Apple memotong pendapatan Anda setelah komisi dan mengembalikan komisinya dalam gerakan yang sama, jadi laporan keuangan menampilkan pengurangan setelah dikurangi bagian Apple.

Penentuan waktu arus kas adalah tempat pengembang terkejut. Di Google Play, jika Anda merefund sebuah pesanan sebelum Google membayar Anda untuknya, Anda sama sekali tidak menerima jumlah itu. Jika Anda merefund setelah pembayaran, Google memotongnya dari pembayaran mendatang. Dan jika gelombang refund mendorong saldo Anda negatif dan tetap negatif setidaknya 48 jam, Google akan mendebit rekening bank yang biasanya menerima pembayaran Anda untuk kekurangan itu. Chargeback adalah versi lebih tajam dari peristiwa yang sama: di Google Play, untuk pesanan yang dilakukan pada atau setelah 3 Agustus 2026, chargeback memindahkan harga pembelian ditambah biaya bank ke pengembang, dan itu jatuh pada laporan bulan yang lebih akhir daripada penjualannya.

Cara merekonsiliasi laporan refund Anda, langkah demi langkah

Pekerjaan ini jadi sederhana begitu Anda berhenti mencoba menyamakan setiap angka dan alih-alih menetapkan setiap angka ke pertanyaan yang dijawabnya. Hanya ada dua pertanyaan: berapa banyak uang yang berpindah, dan siapa yang masih punya akses.

• Putuskan pertanyaannya sebelum membuka laporan. Untuk uang, jawabannya ada di laporan keuangan Apple dan earnings report Google, titik. Untuk akses, jawabannya ada di notifikasi server Anda. Jangan pernah merekonsiliasi yang satu terhadap yang lain.
• Pilih transaction id sebagai kunci gabung Anda di keempat permukaan. Itu satu-satunya bidang yang dibagi bersama oleh sebuah penjualan, refundnya, laporan-laporannya, dan webhook Anda.
• Untuk Apple, ketika Summary Sales Report dan webhook Anda tidak sepakat, panggil endpoint Get Refund History App Store Server API di /inApps/v2/refund/lookup/{transactionId}. Ia mengembalikan transaksi yang direfund dan ditandatangani untuk seorang pelanggan, dengan revocationDate dan revocationReason, satu transaction id per waktu, dan menelusuri riwayatnya per halaman. Endpoint itu adalah penentu.
• Untuk Google, periksa silang baris Charge refund di earnings report terhadap apa yang dilaporkan Voided Purchases API untuk pesanan yang sama, dan ingat sebuah refund parsial ditandai Partial dan tidak akan menolkan tagihan aslinya.
• Selaraskan dengan jam laporan, bukan jam Anda. Milik Apple adalah bulan fiskal dalam waktu Pacific. Earnings report Google punya bulan dan zona waktunya sendiri. Log Anda hampir pasti UTC. Konversikan ke kalender laporan sebelum membandingkan, atau batas hari saja akan menciptakan ketidakcocokan hantu.
• Harapkan estimasi bergerak. Sales and Trends adalah estimasi dan akan terus bergeser seiring transaksi diselesaikan. Rekonsiliasi terhadap laporan keuangan, jangan pernah terhadap estimasi, dan jangan pernah terhadap snapshot estimasi kemarin.

Ketika server Anda menampilkan lebih banyak refund daripada laporan

Kepanikan paling umum adalah menemukan lebih banyak notifikasi REFUND di server Anda daripada baris refund di laporan penjualan untuk rentang yang sama. Biasanya itu bukan uang yang hilang. Kedua permukaan menghitung momen yang berbeda, sebuah notifikasi bisa mendahului baris laporan beberapa hari, dan sebuah refund parsial atau permintaan yang dikirim ulang dapat menghasilkan lebih dari satu peristiwa. Pengembang telah melaporkan bentuk persis ini, ribuan notifikasi REFUND melawan jumlah baris ber-Units negatif yang lebih kecil untuk bulan yang sama. Selesaikan dengan cara sama setiap kali: ambil transaction id yang dilihat server Anda, jalankan melalui Get Refund History, dan biarkan catatan Apple sendiri memutuskan mana yang benar-benar direfund dan untuk berapa banyak.

Versi singkatnya

Anda tidak bisa membuat estimasi Apple, laporan keuangan Apple, earnings report Google, dan webhook Anda semuanya menampilkan total refund yang sama pada hari yang sama, dan Anda sebaiknya berhenti mencoba. Baca masing-masing untuk apa yang dibangun untuk diberitahukannya. Percayai laporan keuangan dan earnings report untuk uang, percayai notifikasi server Anda untuk akses, dan ketika dua permukaan berselisih, gabungkan berdasarkan transaction id dan biarkan pencarian Get Refund History atau Voided Purchases memutus selisihnya. Refund yang terekonsiliasi bukanlah total yang cocok. Melainkan transaksi yang cocok.