환불 리포트는 Apple, Google, 그리고 여러분의 서버에서 절대 일치하지 않는다, 이를 대조하는 방법

App Store Connect 에서 환불 건수를 뽑고, 그다음 여러분의 서버에서 뽑으면 두 숫자는 일치하지 않는다. financial report 에서 세 번째를 뽑아도 앞의 두 숫자 어느 것과도 일치하지 않는다. 이것은 누군가의 시스템 버그가 아니다. Apple 과 Google 은 각각 하나 이상의 창구로 환불을 보고하고, 각 창구는 환불의 생애에서 서로 다른 순간을 세며, 여러분의 서버는 네 번째를 본다. 환불 리포트를 대조하려다가 합계가 벌어져서 포기한 적이 있다면, 여기서 왜 벌어지는지, 어떤 숫자를 어떤 용도에 신뢰해야 하는지, 그리고 월이 아니라 거래로 맞추는 방법을 설명한다.

왜 하나의 환불이 세 개의 서로 다른 숫자로 나타나는가

하나의 환불은 정산되기 전에 여러 시스템을 거치며, 각 시스템은 그것을 서로 다른 순간에 기록한다. 여러분의 서버가 그것을 이벤트로 가장 먼저 듣는다. 다음으로 빠른 분석 리포트가 그것을 추정한다. 회계 리포트는 돈이 실제로 움직인 뒤, 마지막에 그것을 기록한다. 같은 환불, 세 개의 타임스탬프, 세 개의 합계. 실수는 그중 어느 두 개를 같은 날에 같아야 하는 것처럼 다루는 것이다.

Apple 은 두 종류의 리포트에 더해 여러분의 webhook 을 준다

Apple 은 환불을 두 곳에서 보고하는데, 이들은 같은 도구가 아니며 특정 날에 맞아떨어지도록 의도된 것도 아니다. Sales and Trends 는 빠른 추정 관점이다. 일간 리포트는 다음 날, 주간 리포트는 월요일, 월간 리포트는 월말 약 5 일 후, 일반적으로 Pacific 시간 8 a.m. 까지 도착한다. 전월 환율의 이동 평균을 사용해 판매와 수익을 USD 로 추정하므로, 추세를 파악하기에는 좋지만 지급액을 맞추기에는 부적합하다. Payments and Financial Reports 는 정산된 관점이다. Apple 의 회계 달력에 따라 월 1 회 생성되고, 현재 회계월의 첫 번째 금요일까지 이전 회계월 분을 받아볼 수 있으며, 그 기간에 구매나 환불이 있었을 때만 생성된다. 여러분의 지급액에 적용되는 확정 환율을 사용한다. 그 리포트가 회계 기록이다. 이 둘과 나란히, 여러분의 서버는 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 를 열어도 환불이 판매에서 조용히 자신을 빼주지는 않는다. 그것은 별도의 한 행으로 나타난다. 그 행의 Units 와 Customer Price 는 음수이며, 이것이 애초에 환불을 알아보는 방법이고, Developer Proceeds 값은 가격과는 다르게 움직인다. 이 리포트는 본질적으로 환불을 차감한 순액이 아니다. 환불 행을 판매 행 옆에 나열할 뿐이며, 그것들을 분류하는 것은 여러분의 몫이다. Units 열을 눈으로 합산하면 이중으로 세거나 환불을 통째로 놓치게 되는데, 마이너스 1 짜리 환불 행이 여러분의 양수 판매와 같은 열에 있기 때문이다.

실용적인 규칙은 단순하다. 음수 Units 로 환불을 찾고, 그 행들만 따로 더하며, 리포트가 이미 여러분을 위해 그것들을 차감해 두었다고 결코 가정하지 말라. 여러분 환불 건수의 간단한 답은 음수 Unit 행의 개수이지, 어느 열의 산술 합계가 아니다.

회계 달력이야말로 여러분의 월별 합계가 결코 맞아떨어지지 않는 이유다

꼼꼼한 스프레드시트가 그래도 맞아떨어지기를 거부하는 가장 큰 단일 이유가 이것이다. Apple 의 재무 리포트는 달력 월로 돌아가지 않는다. 4-4-5 회계 달력으로 돌아가는데, 대부분의 회계월은 4 주이고 세 번째마다 5 주다. Financial Report 를 평범한 1 월부터 1 월까지의 구간과 비교하는 개발자는 서로 다른 일수의 두 기간을 비교하는 것이므로, 밑바탕의 모든 숫자가 맞더라도 환불 합계는 일치할 수 없다. Apple 자체 포럼의 개발자들은 바로 이 이유로 Sales 숫자와 Financial Report 숫자가 수천 달러씩 벌어지는 것을 지켜봤고, 그대로 두면 그 격차는 매달 커졌다.

Google 의 earnings report 는 월간이지만, 자체 시점과 자체 시간대를 가지며, 둘 다 여러분 서버의 UTC 시계가 아니다. 더 깊은 함정은 두 스토어에 공통된다. 환불은 원래 판매 날짜가 아니라 정산되는 날짜에 귀속된다. 3 월 구매를 4 월 초에 환불하면 그것은 3 월이 아니라 4 월 숫자를 줄인다. 두 달을 라벨로 맞추면 환불은 한쪽에서 사라지고 다른 쪽에서 나타난 것처럼 보인다.

환불에 얼마가 드는가, 그리고 어느 리포트에서 읽어야 하는가

대조는 사실 회계 문제이므로 돈을 따라가라. 환불에서 스토어는 자신의 수수료를 돌려주며, 이는 실제로 여러분 계좌에서 나가는 금액이 고객이 돌려받는 것으로 보이는 전액이 아니라 그 판매에서의 여러분 몫이라는 뜻이다. Google Play 에서 그 반환은 눈에 보이는 한 줄이다. earnings report 의 Google fee refund 거래 유형은 여러분에게 돌아오는 수수료이며, 구매자에게 간 Charge refund 옆에 놓인다. App Store 에서는 Apple 이 수수료 차감 후 여러분 수익을 빼고 같은 동작으로 자신의 수수료를 돌려주므로, financial report 에는 Apple 몫을 뺀 후의 차감이 표시된다.

개발자가 놀라는 지점은 현금 흐름의 시점이다. Google Play 에서 Google 이 그 주문에 대해 여러분에게 지급하기 전에 환불하면, 여러분은 그 금액을 아예 받지 못한다. 지급 후에 환불하면 Google 은 향후 지급액에서 그것을 차감한다. 그리고 환불의 물결이 여러분 잔액을 마이너스로 밀어넣고 그것이 최소 48 시간 동안 마이너스로 유지되면, Google 은 평소 여러분 지급액을 받는 은행 계좌에서 부족분을 인출한다. 지불 거절은 같은 사건의 더 날카로운 버전이다. Google Play 에서 2026 년 8 월 3 일 당일 또는 그 이후에 이루어진 주문의 경우, 지불 거절은 구매 가격에 은행 수수료를 더한 금액을 개발자에게 넘기며, 그것은 판매보다 나중 달의 리포트에 잡힌다.

환불 리포트를 대조하는 방법, 단계별로

모든 숫자를 같게 만들려는 시도를 멈추고 대신 각 숫자를 그것이 답하는 질문에 배정하면 이 일은 단순해진다. 질문은 둘뿐이다. 얼마의 돈이 움직였는가, 그리고 누가 여전히 접근 권한을 가지는가.

• 리포트를 열기 전에 질문을 정하라. 금액이라면 답은 Apple 의 financial report 와 Google 의 earnings report 에 있다, 그게 전부다. 접근 권한이라면 답은 여러분의 서버 알림에 있다. 결코 한쪽을 다른 쪽과 대조하지 말라.
• 네 창구 모두를 관통하는 조인 키로 transaction id 를 골라라. 그것은 판매, 그 환불, 리포트들, 그리고 여러분의 webhook 이 모두 공유하는 유일한 필드다.
• Apple 의 경우, Summary Sales Report 와 여러분의 webhook 이 어긋날 때 App Store Server API Get Refund History 엔드포인트 /inApps/v2/refund/lookup/{transactionId} 를 호출하라. 그것은 고객의 서명된 환불 거래를 revocationDate 와 revocationReason 과 함께, transaction id 를 한 번에 하나씩 반환하며 그 이력을 페이지로 넘긴다. 그 엔드포인트가 승부를 가른다.
• Google 의 경우, earnings report 의 Charge refund 행을 같은 주문에 대해 Voided Purchases API 가 보고하는 내용과 교차 확인하고, 부분 환불은 Partial 로 태그되며 원래 청구를 0 으로 만들지 않는다는 점을 기억하라.
• 여러분의 시계가 아니라 리포트의 시계에 맞춰라. Apple 의 것은 Pacific 시간의 회계월이다. Google 의 earnings report 는 자체 월과 시간대를 가진다. 여러분의 로그는 거의 확실히 UTC 다. 비교하기 전에 리포트의 달력으로 변환하라, 그러지 않으면 날짜 경계만으로도 유령 같은 불일치가 생긴다.
• 추정치가 움직일 것을 예상하라. Sales and Trends 는 추정치이며 거래가 정산됨에 따라 계속 변한다. financial report 와 대조하고, 결코 추정치와 대조하지 말며, 어제 찍은 추정치의 스냅샷과도 결코 대조하지 말라.

서버가 리포트보다 더 많은 환불을 보여줄 때

가장 흔한 당황은 같은 기간에 대해 서버의 REFUND 알림이 판매 리포트의 환불 행보다 많다는 것을 발견하는 일이다. 대개 돈이 사라진 것은 아니다. 두 창구는 서로 다른 순간을 세고, 알림은 리포트 행보다 며칠 앞설 수 있으며, 부분 환불이나 재제출된 요청은 둘 이상의 이벤트를 만들 수 있다. 개발자들은 바로 이런 형태를 보고해 왔다. 같은 달에 대해 수천 건의 REFUND 알림 대 더 적은 수의 음수 Unit 행. 매번 같은 방식으로 해결하라. 서버가 본 transaction id 를 가져다 Get Refund History 에 통과시키고, 실제로 어느 것이 환불되었고 얼마가 환불되었는지 Apple 자체 기록이 결정하게 하라.

짧은 버전

Apple 의 추정치, Apple 의 financial report, Google 의 earnings report, 그리고 여러분의 webhook 모두가 같은 날 같은 환불 합계를 보여주게 할 수는 없으니, 그만 시도하는 편이 낫다. 각각을 그것이 알려주도록 만들어진 바에 따라 읽어라. 금액은 financial report 와 earnings report 를 신뢰하고, 접근 권한은 서버 알림을 신뢰하며, 두 창구가 다툴 때는 transaction id 로 그것들을 조인하고 Get Refund History 나 Voided Purchases 조회가 승부를 가르게 하라. 대조된 환불은 맞춰진 합계가 아니다. 그것은 맞춰진 거래다.