Чому мої продажі в App Store і Financial Report не збігаються?

Вони вимірюють різні речі за різними годинниками. Sales and Trends це швидка оцінка в USD за ковзним середнім курсом обміну, тоді як Payments and Financial Reports це розрахований бухгалтерський запис за фіскальним календарем Apple 4-4-5, з остаточним курсом обміну. Оскільки фіскальні місяці не є календарними місяцями, а повернення розраховуються пізніше за продаж, обидва підсумки навмисно розходяться. Для всього, що стосується грошей, узгоджуйте з Financial Report.

Як повернення показані в App Store Summary Sales Report?

Повернення з'являється як окремий рядок із від'ємними Units і від'ємною Customer Price. Звіт не очищений від повернень, тож рядки повернень стоять поруч із рядками продажів, а не гасять їх. Розпізнавайте повернення за від'ємними Units і підсумовуйте ці рядки окремо, бо підсумовування стовпця на око порахує ваші повернення неправильно.

Чому мій сервер показує більше сповіщень REFUND, ніж мій звіт продажів?

Бо ці двоє рахують різні моменти. Ваш сервер чує подію повернення в реальному часі, тоді як звіт продажів фіксує розрахований рядок пізніше, а часткові чи повторно подані повернення можуть згенерувати більше ніж одне сповіщення. Щоб розв'язати різницю, візьміть transaction id, які бачив ваш сервер, і пропустіть їх через ендпоінт Get Refund History в App Store Server API, який повертає власний запис Apple про те, що насправді повернуто.

Яку цифру повернень мені використовувати для бухгалтерії?

Payments and Financial Reports від Apple і earnings report від Google Play. Це розраховані записи бухгалтерського рівня. Sales and Trends від Apple і estimated sales report від Google це швидка аналітика, яку обидва магазини радять не використовувати для бухгалтерії, а сповіщення вашого сервера призначені для контролю доступу, а не для обліку доходу.

Чи з'являється повернення в тому самому місяці, що й первісний продаж?

Зазвичай ні. Повернення в обох магазинах приписується до дати розрахунку, а не до дати первісної покупки. Березневий продаж, повернутий у квітні, зменшує ваші квітневі підсумки, тож зіставлення двох місяців за їхніми мітками змусить повернення виглядати так, ніби воно зникло з одного місяця і з'явилося в іншому. Натомість зіставляйте за transaction id.

Усі статті

Playbook17 серпня 2026 р.8 хв читання

Ваші звіти про повернення ніколи не збігаються між Apple, Google та вашим сервером, ось як їх узгодити

Apple показує повернення у двох звітах, Google у ще двох, а ваш сервер бачить четвертий. Жодна з цифр не збігається, і розбіжності закладені навмисно. Ось чому кожна поверхня приписує повернення по-різному і як узгодити звіти про повернення з вашими власними записами, транзакція за транзакцією.

Стіл бухгалтера з трьома окремими стосами роздрукованих фінансових звітів і лупою, що ілюструє, наскільки важко узгодити звіти про повернення між Apple і Google

Головне

Apple розподіляє звітність про повернення між двома інструментами, які навмисно ніколи не збігаються. Sales and Trends швидко оцінює повернення в USD, а Payments and Financial Reports розраховує їх пізніше за фіскальним календарем Apple. Сповіщення REFUND з вашого сервера це третій, реального часу, погляд на ту саму подію.
У Summary Sales Report від Apple повернення це окремий рядок із від'ємними Units і від'ємною Customer Price, і звіт не очищений від повернень. Якщо підсумуєте стовпець на око, порахуєте неправильно, бо рядки повернень стоять поруч із рядками продажів, а не гасять їх.
Фінансові звіти Apple працюють за фіскальним календарем 4-4-5, а не за календарними місяцями, і звіт за фіскальний місяць доступний до першої п'ятниці наступного фіскального місяця. Будь-яка сума повернень, яку ви порівнюєте зі звичайним календарним місяцем, буде хибною ще до початку.
Google Play розділяє повернення так само. earnings report перелічує Charge refund і Google fee refund як окремі типи транзакцій, кожен позначений як Full або Partial, тоді як estimated sales report це аналітика з низькою затримкою, яка, за словами Google, не призначена для бухгалтерії.
Повернення приписується до дати розрахунку, а не до дати первісного продажу, тож повернення березневої покупки потрапляє у ваші квітневі цифри в обох магазинах. Узгоджуйте повернення за transaction id, ніколи через зіставлення місячних підсумків.
Розробники регулярно знаходять більше сповіщень REFUND, ніж рядків повернень у Summary Sales Report за той самий період, бо ці двоє рахують різні моменти. Ендпоінт Get Refund History в App Store Server API є достовірним джерелом узгодження, по одному transaction id за раз.
Лише дві з цих поверхонь створені для бухгалтерії: Financial Report від Apple і earnings report від Google. Узгоджуйте гроші з ними, узгоджуйте доступ зі сповіщеннями сервера, і ніколи не змушуйте одну цифру виконувати роботу іншої.

Візьміть кількість повернень з App Store Connect, потім візьміть її з вашого сервера, і ці дві цифри не збіжаться. Візьміть третю з вашого Financial Report, і вона не збіжиться з жодною. Це не помилка в чиїйсь системі. Apple і Google звітують про повернення кожен через більш ніж одну поверхню, кожна поверхня рахує інший момент у житті повернення, а ваш сервер бачить четвертий. Якщо ви колись намагалися узгодити звіти про повернення і здалися, бо підсумки розходяться, ось чому вони розходяться, якій цифрі довіряти для якого завдання і як вирівняти їх за транзакцією, а не за місяцем.

Чому одне повернення з'являється як три різні цифри

Одне повернення проходить через кілька систем, перш ніж воно розраховане, і кожна система записує його в іншу мить. Ваш сервер чує про нього першим, як подію. Швидкий аналітичний звіт оцінює його наступним. Бухгалтерський звіт фіксує його останнім, коли гроші фактично перемістилися. Те саме повернення, три часові позначки, три підсумки. Помилка в тому, щоб трактувати будь-які два з них так, ніби вони мають бути рівними того самого дня.

Apple дає вам дві родини звітів, плюс ваш webhook

Apple звітує про повернення у двох місцях, які не є тим самим інструментом і не призначені сходитися певного дня. Sales and Trends це швидкий, оцінний погляд: денні звіти надходять наступного дня, тижневі по понеділках, місячні приблизно через п'ять днів після кінця місяця, зазвичай до 8 a.m. Pacific. Він оцінює продажі й надходження в USD за ковзним середнім курсів обміну попереднього місяця, що робить його добрим для помічання тренду і хибним для узгодження виплати. Payments and Financial Reports це розрахований погляд: генерується раз на місяць за фіскальним календарем Apple, доступний до першої п'ятниці поточного фіскального місяця за попередній фіскальний місяць, і генерується лише якщо в тому періоді були покупки чи повернення. Він використовує остаточний курс обміну, застосований до вашої виплати. Той звіт є бухгалтерським записом. Поряд з обома ваш сервер отримує App Store Server Notification REFUND у мить, коли Apple надає повернення, прив'язане до одного transaction id.

Google розділяє так само

Google Play віддзеркалює цей розподіл. earnings report є бухгалтерським записом, генерується щомісяця і зазвичай доступний до 5-го числа наступного місяця, і він перелічує повернення як окремі типи транзакцій: Charge refund за гроші, повернуті покупцеві, і Google fee refund за сервісний збір, який Google віддає, кожен позначений як Full або Partial. estimated sales report це аналітичний погляд з низькою затримкою, що показує, скільки покупці заплатили до податків і зборів, і Google прямо каже, що він придатний для аналітики й не рекомендований для бухгалтерії. На боці сервера ви отримуєте Real-time Developer Notification у реальному часі і можете зчитати повернення з Voided Purchases API.

Як Apple показує повернення всередині звіту, і пастка від'ємного рядка

Відкрийте Summary Sales Report, і повернення не віднімається тихо від продажу. Воно з'являється як окремий рядок. Units і Customer Price у тому рядку від'ємні, за чим ви взагалі впізнаєте повернення, а показник Developer Proceeds поводиться не так, як ціна. Звіт за своєю природою не очищений від повернень. Він перелічує рядки повернень поряд із рядками продажів, і ваше завдання їх розсортувати. Підсумуйте стовпець Units на око, і ви або порахуєте подвійно, або зовсім пропустите повернення, бо рядок повернення мінус один стоїть у тому самому стовпці, що й ваші додатні продажі.

Практичне правило просте: знаходьте повернення за від'ємними Units, додавайте ці рядки окремо і ніколи не припускайте, що звіт уже зарахував їх за вас. Придатна для featured snippet кількість ваших повернень це кількість рядків із від'ємними Units, а не арифметична сума стовпця.

Поверхня Apple	Для чого вона	Коли оновлюється	Як з'являється повернення
Sales and Trends	Швидка оцінка тренду, не бухгалтерія	Щодня наступного дня, щомісяця приблизно за 5 днів після кінця місяця	Від'ємні units у тренді, оцінені в USD
Summary Sales Report	Деталі для завантаження за Sales and Trends	Той самий ритм, що й Sales and Trends	Окремий рядок, від'ємні Units і від'ємна Customer Price
Payments and Financial Reports	Запис бухгалтерії та виплат	Щомісяця за фіскальним календарем Apple, до першої п'ятниці	Розрахований відрахунок від надходжень того фіскального місяця
Сповіщення сервера REFUND	Контроль доступу в реальному часі	Мить, коли Apple надає повернення	Одна подія, один transaction id

Фіскальний календар це причина, чому ваші місячні підсумки ніколи не сходяться

Ось найбільша окрема причина, чому ретельна таблиця все одно відмовляється зводитися. Фінансові звіти Apple не працюють за календарними місяцями. Вони працюють за фіскальним календарем 4-4-5, де більшість фіскальних місяців мають чотири тижні, а кожен третій п'ять тижнів. Розробник, який порівнює Financial Report зі звичайним вікном від січня до січня, порівнює два різні проміжки днів, тож підсумки повернень не можуть збігатися, навіть коли кожна базова цифра правильна. Розробники на власних форумах Apple спостерігали, як цифри Sales і цифри Financial Report розходилися на тисячі доларів саме з цієї причини, а розрив зростав щомісяця, поки вони давали йому накопичуватися.

earnings report від Google щомісячний, але він несе власний час і власний часовий пояс, і жоден з них не є годинником UTC вашого сервера. Глибша пастка спільна для обох магазинів: повернення приписується до дати розрахунку, а не до дати первісного продажу. Поверніть березневу покупку на початку квітня, і вона зменшить ваші квітневі цифри, а не березневі. Зіставте два місяці за їхніми мітками, і повернення здасться таким, що зникло з одного і матеріалізувалося в іншому.

Дві роздруковані таблиці, покладені поруч, поки рука проводить один рядок через обидві, ілюструючи узгодження звітів про повернення за transaction id

Скільки коштує повернення, і в якому звіті його читати

Узгодження це насправді бухгалтерське питання, тож ідіть за грошима. При поверненні магазин повертає власну комісію, що означає, що сума, яка справді залишає ваш рахунок, це ваша частка від продажу, а не повна ціна, яку клієнт бачить повернутою. У Google Play це повернення є видимим рядком: тип транзакції Google fee refund у вашому earnings report це сервісний збір, що повертається до вас, поруч із Charge refund, який пішов покупцеві. В App Store Apple віднімає ваші надходження після комісії й повертає свою комісію тим самим рухом, тож Financial Report показує відрахунок за вирахуванням частки Apple.

Час руху грошових коштів це те, де розробники бувають заскочені зненацька. У Google Play, якщо ви повертаєте замовлення до того, як Google вам за нього заплатив, ви просто ніколи не отримаєте цю суму. Якщо ви повертаєте після виплати, Google віднімає її з майбутньої виплати. А якщо хвиля повернень штовхає ваш баланс у мінус і він залишається від'ємним щонайменше 48 годин, Google спише з банківського рахунку, який зазвичай отримує ваші виплати, суму нестачі. Chargeback це різкіша версія тієї самої події: у Google Play для замовлень, розміщених 3 серпня 2026 або пізніше, chargeback переносить ціну покупки плюс збори банку на розробника, і воно потрапляє у звіт за пізніший місяць, ніж продаж.

При поверненні	App Store	Google Play
Що залишає ваш рахунок	Ваші надходження після комісії	Ціна покупки мінус сервісний збір Play
Що магазин повертає	Комісію Apple	Сервісний збір, як рядок Google fee refund
З яким звітом узгоджувати	Payments and Financial Reports	Earnings report
Коли розраховується	Фіскальний місяць, у якому оброблено, до першої п'ятниці після	Віднімається від виплати за той період або наступний
Поворот із chargeback	Apple бере на себе механіку картового спору	З 3 сер 2026 ціна плюс банківські збори переходять на вас

Як узгодити ваші звіти про повернення, крок за кроком

Завдання стає простим, щойно ви перестанете намагатися зрівняти кожну цифру і натомість призначите кожній цифрі питання, на яке вона відповідає. Є лише два питання: скільки грошей перемістилося і хто досі має доступ.

Визначте питання, перш ніж відкривати звіт. Для грошей відповідь у Financial Report від Apple і earnings report від Google, крапка. Для доступу відповідь у сповіщеннях вашого сервера. Ніколи не узгоджуйте одне з іншим.
Оберіть transaction id як ваш ключ з'єднання на всіх чотирьох поверхнях. Це те єдине поле, яке спільне для продажу, його повернення, звітів і вашого webhook.
Для Apple, коли Summary Sales Report і ваш webhook не збігаються, викличте ендпоінт Get Refund History в App Store Server API за адресою /inApps/v2/refund/lookup/{transactionId}. Він повертає підписані повернені транзакції для клієнта, з revocationDate і revocationReason, по одному transaction id за раз, і гортає їхню історію. Той ендпоінт є вирішальним.
Для Google звірте рядки Charge refund у earnings report з тим, що Voided Purchases API повідомляє для тих самих замовлень, і пам'ятайте, що часткове повернення позначене як Partial і не обнулить первісне списання.
Вирівнюйтеся за годинником звіту, а не за вашим. Годинник Apple це фіскальний місяць за часом Pacific. earnings report від Google має власний місяць і часовий пояс. Ваші логи майже напевно в UTC. Переведіть у календар звіту, перш ніж порівнювати, інакше самі лише межі днів створять фантомні розбіжності.
Очікуйте, що оцінка змінюватиметься. Sales and Trends це оцінка, і вона й далі зсуватиметься, поки транзакції розраховуються. Узгоджуйте з Financial Report, ніколи з оцінкою, і ніколи зі вчорашнім знімком оцінки.

Коли ваш сервер показує більше повернень, ніж звіт

Найпоширеніша паніка це виявити більше сповіщень REFUND на вашому сервері, ніж рядків повернень у звіті продажів за той самий період. Зазвичай це не втрачені гроші. Ці дві поверхні рахують різні моменти, сповіщення може випереджати рядок звіту на дні, а часткове повернення чи повторно поданий запит може породити більше ніж одну подію. Розробники повідомляли саме про таку форму, тисячі сповіщень REFUND проти меншої кількості рядків із від'ємними Units за той самий місяць. Вирішуйте це щоразу однаково: візьміть transaction id, які бачив ваш сервер, пропустіть їх через Get Refund History і дайте власному запису Apple визначити, які насправді повернуто і на скільки.

Коротка версія

Ви не змусите оцінку Apple, Financial Report від Apple, earnings report від Google і ваш webhook усі показати той самий підсумок повернень того самого дня, і вам слід перестати намагатися. Читайте кожен з них за тим, що він створений вам сказати. Довіряйте Financial Report і earnings report щодо грошей, довіряйте сповіщенням сервера щодо доступу, а коли дві поверхні сперечаються, з'єднайте їх за transaction id і дайте пошуку Get Refund History чи Voided Purchases розв'язати суперечку. Узгоджені повернення це не зіставлені підсумки. Це зіставлені транзакції.

Поширені запитання

Чому мої продажі в App Store і Financial Report не збігаються?: Вони вимірюють різні речі за різними годинниками. Sales and Trends це швидка оцінка в USD за ковзним середнім курсом обміну, тоді як Payments and Financial Reports це розрахований бухгалтерський запис за фіскальним календарем Apple 4-4-5, з остаточним курсом обміну. Оскільки фіскальні місяці не є календарними місяцями, а повернення розраховуються пізніше за продаж, обидва підсумки навмисно розходяться. Для всього, що стосується грошей, узгоджуйте з Financial Report.
Як повернення показані в App Store Summary Sales Report?: Повернення з'являється як окремий рядок із від'ємними Units і від'ємною Customer Price. Звіт не очищений від повернень, тож рядки повернень стоять поруч із рядками продажів, а не гасять їх. Розпізнавайте повернення за від'ємними Units і підсумовуйте ці рядки окремо, бо підсумовування стовпця на око порахує ваші повернення неправильно.
Коли повернення з'являються в earnings report Google Play?: earnings report генерується щомісяця і зазвичай доступний до 5-го числа наступного місяця. Повернення з'являється як два типи транзакцій, Charge refund за гроші, повернуті покупцеві, і Google fee refund за сервісний збір, який Google повертає вам, кожен позначений як Full або Partial. Якщо ви повернули до того, як Google вам заплатив, ви ніколи не отримаєте цю суму; якщо після, вона віднімається від майбутньої виплати.
Чому мій сервер показує більше сповіщень REFUND, ніж мій звіт продажів?: Бо ці двоє рахують різні моменти. Ваш сервер чує подію повернення в реальному часі, тоді як звіт продажів фіксує розрахований рядок пізніше, а часткові чи повторно подані повернення можуть згенерувати більше ніж одне сповіщення. Щоб розв'язати різницю, візьміть transaction id, які бачив ваш сервер, і пропустіть їх через ендпоінт Get Refund History в App Store Server API, який повертає власний запис Apple про те, що насправді повернуто.
Яку цифру повернень мені використовувати для бухгалтерії?: Payments and Financial Reports від Apple і earnings report від Google Play. Це розраховані записи бухгалтерського рівня. Sales and Trends від Apple і estimated sales report від Google це швидка аналітика, яку обидва магазини радять не використовувати для бухгалтерії, а сповіщення вашого сервера призначені для контролю доступу, а не для обліку доходу.
Чи з'являється повернення в тому самому місяці, що й первісний продаж?: Зазвичай ні. Повернення в обох магазинах приписується до дати розрахунку, а не до дати первісної покупки. Березневий продаж, повернутий у квітні, зменшує ваші квітневі підсумки, тож зіставлення двох місяців за їхніми мітками змусить повернення виглядати так, ніби воно зникло з одного місяця і з'явилося в іншому. Натомість зіставляйте за transaction id.

Джерела та додаткове читання

RefundHalt

Автопілот повернень для App Store і Google Play

Читайте далі

Playbook7 хв читання

Google Play дозволяє вам самостійно оформити частковий повернення коштів, а App Store залишає кожне повернення за Apple

У Google Play ви можете повернути частину замовлення з Console, у відсотках або сумою, і поділити збиток з комісією Google. В App Store ви не можете оформити жодного повернення. Ось як працює часткове повернення в кожному магазині і скільки воно вам коштує.

Deep dive9 хв читання

Здоровий показник повернень коштів у додатку становить від 2 до 5 відсотків, тут ти знайдеш свій і дізнаєшся, скільки він насправді коштує

Більшість мобільних додатків повертають кошти за від 2 до 5 відсотків платних транзакцій, але Apple і Google тримають цю цифру в різних панелях. Тут ти дізнаєшся, де знайти показник повернень свого додатка, що вважається нормою залежно від плану і категорії, і скільки насправді коштує кожне повернення після комісій.