Báo cáo hoàn tiền của bạn không bao giờ khớp giữa Apple, Google và máy chủ của bạn, đây là cách đối chiếu chúng

Lấy số lượng hoàn tiền từ App Store Connect, rồi lấy nó từ máy chủ của bạn, và hai con số sẽ không khớp. Lấy con số thứ ba từ báo cáo tài chính và nó cũng sẽ không khớp với cái nào. Đây không phải lỗi trong hệ thống của ai cả. Apple và Google mỗi bên báo cáo hoàn tiền qua nhiều hơn một bề mặt, mỗi bề mặt đếm một thời điểm khác nhau trong vòng đời của khoản hoàn tiền, và máy chủ của bạn thấy cái thứ tư. Nếu bạn từng cố đối chiếu báo cáo hoàn tiền rồi bỏ cuộc vì các tổng cứ trôi xa nhau, đây là lý do chúng trôi xa, con số nào đáng tin cho công việc nào, và cách xếp thẳng hàng chúng theo giao dịch thay vì theo tháng.

Vì sao một khoản hoàn tiền hiện ra thành ba con số khác nhau

Một khoản hoàn tiền đi qua vài hệ thống trước khi được quyết toán, và mỗi hệ thống ghi lại nó vào một thời điểm khác. Máy chủ của bạn nghe về nó trước tiên, dưới dạng một sự kiện. Một báo cáo phân tích nhanh ước tính nó tiếp theo. Báo cáo kế toán ghi nhận nó sau cùng, một khi tiền thực sự đã chuyển. Cùng một khoản hoàn tiền, ba dấu thời gian, ba tổng. Sai lầm là coi bất kỳ hai trong số đó như thể chúng phải bằng nhau trong cùng một ngày.

Apple cho bạn hai họ báo cáo, cộng thêm webhook của bạn

Apple báo cáo hoàn tiền ở hai nơi vốn không phải cùng một công cụ và không nhằm khớp nhau vào một ngày nhất định. Sales and Trends là góc nhìn nhanh, ước tính: báo cáo hàng ngày về vào ngày hôm sau, báo cáo hàng tuần vào thứ Hai, báo cáo hàng tháng khoảng năm ngày sau khi tháng kết thúc, thường trước 8 giờ sáng giờ Pacific. Nó ước tính doanh số và doanh thu bằng USD dùng trung bình trượt của tỷ giá tháng trước, điều này khiến nó tốt để nhận ra một xu hướng và sai để khớp một khoản chi trả. Payments and Financial Reports là góc nhìn đã quyết toán: được tạo mỗi tháng một lần theo lịch tài khóa của Apple, có sẵn trước thứ Sáu đầu tiên của tháng tài khóa hiện tại cho tháng tài khóa trước đó, và chỉ được tạo nếu có mua hoặc hoàn tiền trong kỳ đó. Nó dùng tỷ giá cuối cùng áp cho khoản chi trả của bạn. Báo cáo đó là hồ sơ kế toán. Song song với cả hai, máy chủ của bạn nhận App Store Server Notification REFUND ngay khoảnh khắc Apple cấp một khoản hoàn tiền, gắn với một transaction id duy nhất.

Google chia theo cùng cách

Google Play phản chiếu sự phân chia đó. Earnings report là hồ sơ kế toán, được tạo hàng tháng và thường có sẵn trước ngày 5 của tháng kế tiếp, và nó liệt kê hoàn tiền là các loại giao dịch riêng: Charge refund cho tiền trả lại người mua và Google fee refund cho phí dịch vụ mà Google trả lại, mỗi loại được gắn nhãn Full hoặc Partial. Estimated sales report là góc nhìn phân tích độ trễ thấp cho thấy người mua đã trả bao nhiêu trước thuế và phí, và Google nói thẳng rằng nó phù hợp cho phân tích và không được khuyến nghị cho kế toán. Về phía máy chủ, bạn nhận Real-time Developer Notification theo thời gian thực và có thể đọc lại một khoản hoàn tiền từ Voided Purchases API.

Cách Apple hiển thị một khoản hoàn tiền bên trong báo cáo, và cái bẫy dòng âm

Mở Summary Sales Report và một khoản hoàn tiền không lặng lẽ tự trừ mình khỏi một giao dịch bán. Nó xuất hiện như một dòng riêng. Units và Customer Price trên dòng đó là âm, đó chính là cách bạn nhận ra một khoản hoàn tiền, và chỉ số Developer Proceeds không hành xử như giá. Báo cáo về bản chất không trừ sẵn hoàn tiền. Nó liệt kê các dòng hoàn tiền cạnh các dòng bán hàng, và nhiệm vụ của bạn là gom chúng vào các nhóm. Cộng cột Units bằng mắt và bạn sẽ hoặc đếm gấp đôi hoặc bỏ sót hoàn tiền hoàn toàn, vì một dòng hoàn tiền âm một đơn vị nằm trong cùng cột với các giao dịch bán dương của bạn.

Quy tắc thực dụng thì đơn giản: tìm hoàn tiền qua Units âm, cộng riêng các dòng đó, và đừng bao giờ giả định báo cáo đã trừ chúng sẵn cho bạn. Số lượng hoàn tiền cho một featured snippet là số dòng có Units âm, không phải tổng số học của một cột.

Lịch tài khóa là lý do các tổng hàng tháng của bạn không bao giờ thẳng hàng

Đây là lý do lớn nhất khiến một bảng tính cẩn thận vẫn từ chối cân bằng. Báo cáo tài chính của Apple không chạy theo tháng dương lịch. Chúng chạy theo lịch tài khóa 4-4-5, trong đó hầu hết tháng tài khóa dài bốn tuần và cứ tháng thứ ba dài năm tuần. Một nhà phát triển so một Financial Report với một khung từ tháng Một đến tháng Một thông thường đang so hai khoảng ngày khác nhau, nên các tổng hoàn tiền không thể khớp ngay cả khi mọi con số nền tảng đều đúng. Các nhà phát triển trên chính diễn đàn của Apple đã chứng kiến con số Sales và con số Financial Report lệch nhau hàng nghìn đô la đúng vì lý do này, với khoảng cách rộng ra mỗi tháng họ để nó tích lũy.

Earnings report của Google là hàng tháng, nhưng nó mang thời điểm riêng và múi giờ riêng, và cả hai đều không phải đồng hồ UTC của máy chủ bạn. Cái bẫy sâu hơn là chung cho cả hai cửa hàng: một khoản hoàn tiền được quy về ngày nó được quyết toán, không phải ngày bán ban đầu. Hoàn một giao dịch mua tháng Ba vào đầu tháng Tư và nó làm giảm các con số tháng Tư của bạn, không phải tháng Ba. Xếp thẳng hàng hai tháng theo nhãn của chúng và khoản hoàn tiền dường như biến mất khỏi tháng này và hiện ra ở tháng kia.

Một khoản hoàn tiền tốn bao nhiêu, và đọc nó trong báo cáo nào

Đối chiếu thực ra là một câu hỏi kế toán, nên hãy đi theo dòng tiền. Khi hoàn tiền, cửa hàng trả lại hoa hồng của chính nó, nghĩa là số tiền thực sự rời khỏi tài khoản của bạn là phần của bạn trong giao dịch bán, không phải toàn bộ giá mà khách hàng thấy được trả lại. Trên Google Play khoản trả lại đó là một dòng nhìn thấy được: loại giao dịch Google fee refund trong earnings report của bạn là phí dịch vụ quay lại với bạn, nằm cạnh Charge refund đã đi tới người mua. Trên App Store, Apple trừ doanh thu sau hoa hồng của bạn và trả lại hoa hồng của nó trong cùng một động tác, nên báo cáo tài chính hiển thị khoản trừ đã tính sau phần của Apple.

Thời điểm dòng tiền là nơi các nhà phát triển bị bất ngờ. Trên Google Play, nếu bạn hoàn một đơn hàng trước khi Google trả tiền cho bạn về nó, bạn đơn giản là không bao giờ nhận được số tiền đó. Nếu bạn hoàn sau khi đã chi trả, Google trừ nó khỏi một khoản chi trả tương lai. Và nếu một làn sóng hoàn tiền đẩy số dư của bạn xuống âm và nó giữ âm ít nhất 48 giờ, Google sẽ ghi nợ tài khoản ngân hàng thường nhận các khoản chi trả của bạn cho phần thiếu hụt. Một chargeback là phiên bản gay gắt hơn của cùng sự kiện: trên Google Play, với các đơn hàng được đặt vào hoặc sau ngày 3 tháng 8 năm 2026, chargeback chuyển giá mua cộng với phí của ngân hàng sang nhà phát triển, và nó rơi vào báo cáo của một tháng muộn hơn tháng bán.

Cách đối chiếu báo cáo hoàn tiền của bạn, từng bước một

Công việc trở nên đơn giản một khi bạn ngừng cố làm cho mọi con số bằng nhau và thay vào đó gán mỗi con số cho câu hỏi mà nó trả lời. Chỉ có hai câu hỏi: bao nhiêu tiền đã chuyển, và ai vẫn còn quyền truy cập.

• Quyết định câu hỏi trước khi bạn mở một báo cáo. Về tiền, câu trả lời nằm trong báo cáo tài chính của Apple và earnings report của Google, hết. Về truy cập, câu trả lời nằm trong thông báo máy chủ của bạn. Đừng bao giờ đối chiếu cái này với cái kia.
• Chọn transaction id làm khóa nối của bạn trên cả bốn bề mặt. Nó là trường duy nhất mà một giao dịch bán, khoản hoàn tiền của nó, các báo cáo và webhook của bạn đều chia sẻ.
• Với Apple, khi Summary Sales Report và webhook của bạn bất đồng, hãy gọi endpoint Get Refund History của App Store Server API tại /inApps/v2/refund/lookup/{transactionId}. Nó trả về các giao dịch đã hoàn tiền có chữ ký cho một khách hàng, kèm revocationDate và revocationReason, mỗi lần một transaction id, và phân trang qua lịch sử của họ. Endpoint đó là bên phân định.
• Với Google, đối chiếu chéo các dòng Charge refund trên earnings report với những gì Voided Purchases API báo cáo cho cùng các đơn hàng, và nhớ rằng một khoản hoàn tiền một phần được gắn nhãn Partial và sẽ không đưa khoản tính phí gốc về không.
• Căn theo đồng hồ của báo cáo, không phải của bạn. Của Apple là một tháng tài khóa theo giờ Pacific. Earnings report của Google có tháng và múi giờ riêng. Nhật ký của bạn gần như chắc chắn là UTC. Chuyển sang lịch của báo cáo trước khi so sánh, nếu không riêng ranh giới ngày sẽ tạo ra những chênh lệch ma.
• Hãy chờ đợi ước tính dịch chuyển. Sales and Trends là một ước tính và sẽ tiếp tục dịch chuyển khi các giao dịch được quyết toán. Đối chiếu với báo cáo tài chính, đừng bao giờ với ước tính, và đừng bao giờ với ảnh chụp của ước tính hôm qua.

Khi máy chủ của bạn hiển thị nhiều hoàn tiền hơn báo cáo

Nỗi hoảng phổ biến nhất là tìm thấy nhiều thông báo REFUND trên máy chủ của bạn hơn số dòng hoàn tiền trong báo cáo bán hàng cho cùng khoảng thời gian. Thường thì đó không phải là tiền bị mất. Hai bề mặt đếm những thời điểm khác nhau, một thông báo có thể đi trước dòng báo cáo vài ngày, và một khoản hoàn tiền một phần hoặc một yêu cầu gửi lại có thể tạo ra nhiều hơn một sự kiện. Các nhà phát triển đã báo cáo đúng hình dạng này, hàng nghìn thông báo REFUND đối lại một số dòng có Units âm nhỏ hơn cho cùng một tháng. Hãy giải quyết nó theo cùng cách mỗi lần: lấy các transaction id mà máy chủ của bạn đã thấy, chạy chúng qua Get Refund History, và để chính hồ sơ của Apple quyết định cái nào thực sự đã hoàn tiền và hoàn bao nhiêu.

Phiên bản ngắn gọn

Bạn không thể làm cho ước tính của Apple, báo cáo tài chính của Apple, earnings report của Google và webhook của bạn đều hiển thị cùng một tổng hoàn tiền trong cùng một ngày, và bạn nên ngừng cố. Đọc mỗi cái theo đúng điều nó được xây để nói cho bạn. Tin báo cáo tài chính và earnings report về tiền, tin thông báo máy chủ của bạn về truy cập, và khi hai bề mặt xung đột, hãy nối chúng theo transaction id và để việc tra cứu Get Refund History hoặc Voided Purchases phân định. Hoàn tiền đã đối chiếu không phải là các tổng khớp nhau. Chúng là các giao dịch khớp nhau.