Відкрийте App Store Connect або Google Play Console, і ви побачите число, яке відчувається як ваш дохід. Минулого місяця там було 7 000. Жодне з чисел не є неправильним — але лише одне з них належить до вашого звіту про прибутки та збитки як «дохід», і помилка в цьому рішенні може непомітно спотворити вашу валову маржу, викривити темпи зростання та показати кредитору чи інвестору картину вашого бізнесу, яка не відповідає дійсності.
Це питання «принципал проти агента», і згідно зі стандартом визнання доходу ASC 606 (US GAAP), це не необов'язкова паперова робота — це правило, яке визначає, чи звітуєте ви про 3 000 собівартості продажів, чи просто про $7 000 доходу без будь-яких додаткових пояснень. Для незалежного розробника, який продає через App Store від Apple або Google Play Store, відповідь зазвичай дивує людей.
Питання, яке рано чи пізно задає собі кожен розробник додатків
Тригер майже завжди однаковий: засновник готує пітч-дек, подає заявку на кредит для малого бізнесу або просто намагається відповісти на запитання «скільки я насправді заробив цього кварталу» — і усвідомлює, що весь час записував як «продажі» те, що надходило на банківський рахунок. Це число вже є чистим після вирахування комісії Apple або Google — тобто частка платформи вже віднята.
Проблема в тому, що зарахування доходу за мінусом комісії платформи — це не стилістичний вибір. ASC 606 має спеціальний тест саме для такої ситуації, який залежить від одного питання: хто контролює те, що продається, до того, як воно переходить до клієнта?
Тест контролю ASC 606 простою мовою
П'ятикрокова модель доходу ASC 606 вимагає визначити зобов'язання до виконання в контракті та з'ясувати, хто їх виконує. Коли між вами та кінцевим клієнтом знаходиться маркетплейс або платформа — Apple, Google, Etsy, DoorDash, Uber — стандарти бухгалтерського обліку називають це оцінкою «принципал проти агента», і посібник PwC з доходів зазначає, що продажі в магазинах додатків є класичним прикладом угод, які потребують такого ретельного розгляду.
- Принципал: ви контролюєте товар або послугу до моменту її передачі клієнту. Ви визнаєте повну, валову суму, сплачену клієнтом, як дохід, а комісія платформи стає собівартістю продажів (витратою), а не зменшенням доходу.
- Агент: платформа контролює пропозицію, а ви лише організовуєте продаж від імені іншої сторони. Ви визнаєте лише чисту суму, яку ви залишаєте собі як свою винагороду.
Три індикатори визначають, ким ви є, згідно з фреймворками Deloitte та PwC:
- Відповідальність за виконання — хто несе відповідальність, якщо додаток не працює, підписка не надається або клієнт скаржиться? Зазвичай це ви, розробник, а не Apple.
- Ризик до передачі — хто несе ризик того, що «запаси» (ваш додаток, ваш контент, ваш рівень підписки) не продадуться або не задовольнять клієнта? Знову ж таки, зазвичай ви.
- Повноваження встановлювати ціну — хто визначає, скільки насправді платить клієнт? Ви обираєте ціновий рівень вашого додатка; платформа не обговорює його з вами від угоди до угоди.
Оскільки більшість незалежних розробників контролюють досвід використання продукту, володіють відносинами з клієнтами щодо підтримки та оновлень, а також самостійно встановлюють ціни, вони потрапляють на бік принципала за цим тестом — отже, правильний облік полягає в тому, щоб записувати валову суму, сплачену клієнтом, як дохід, а частку Apple або Google розглядати як рядок собівартості доходу, а не як невидиме зрізання.
Цифри, що стоять за відрахуванням
Знання того, що ви принципал, має значення лише тоді, коли ви знаєте, що саме віднімається. Структури комісій платформ суттєво змінилися за останні кілька років, і більшість розробників все ще планують бюджет на основі застарілих припущень:
| Платформа | Стандартна ставка | Знижена ставка | Хто має право |
|---|---|---|---|
| App Store від Apple | 30% | 15% (Програма малого бізнесу App Store) | Розробники з річним доходом у App Store ≤$1M |
| Підписки Apple | 30% (1-й рік) | 15% (з 2-го року) | Будь-яка підписка після перших 12 місяців |
| Google Play | 30% | 15% на перші $1M заробітку на рік | Усі розробники, застосовується автоматично за рівнями |
| Підписки Google Play | 15% фіксована | — | Усі доходи від підписок |
| ЄС Apple (умови Закону про цифрові ринки) | ~17% + Core Technology Fee | до ~20% разом | Розробники, які обрали альтернативні бізнес-умови ЄС |
Плюс щорічні фіксовані витрати, про які більшість забуває кудись віднести: щорічна плата за програму розробника Apple у розмірі 25. Невеликі, але вони теж повинні десь бути у вашому плані рахунків — зазвичай як загальні операційні витрати, а не собівартість продажів.
Правильний запис: приклад
Скажімо, клієнт купує внутрішньододаткову підписку за 9.99 від клієнта, залишає собі 6.99 на ваш банківський рахунок. Запис $6.99 як «доходу» занижує ваш верхній рядок на 30% — що має величезне значення, якщо ви порівнюєте темпи свого зростання з конкурентом, який продає напряму, або пояснюєте свою маржу кредитору.
Правильні проводки визнають повний продаж, а потім окремо обліковують комісію як витрату:
2026-07-18 * "Apple" "Підписка iOS — валовий продаж"
Assets:Receivable:AppStore 9.99 USD
Income:AppSales -9.99 USD
2026-07-18 * "Apple" "Комісія App Store 30%"
Expenses:CostOfRevenue:PlatformFees 3.00 USD
Assets:Receivable:AppStore -3.00 USD
2026-07-20 * "Apple" "Отримано виплату"
Assets:Checking 6.99 USD
Assets:Receivable:AppStore -6.99 USDЗверніть увагу: рахунок дебіторської заборгованості обнуляється після зарахування виплати, але ваш звіт про прибутки та збитки все ще показує 3.00 собівартості доходу — 70% валової маржі від цього продажу, а не таємничо зниклі 30%. Це саме той тип транзакцій, з якими добре справляються прості текстові, версійовані реєстри: валовий продаж, комісія платформи та виплата — це три окремі події, які можна перевірити, а не один розмитий банківський депозит.
Чому цифри на панелі керування недостатньо
Навіть знаючи правило, застосовувати його вручну складніше, ніж здається. Стандартні звіти App Store Connect та Play Console показують агреговані підсумки, а не деталізацію на рівні підписників і транзакцій, яку технічно вимагає ASC 606 — надходження, відшкодування та конвертація валюти часто потрапляють однією сумою через кілька днів або тижнів після фактичного продажу. Саме цей розрив є причиною того, що дедалі більше компаній, що працюють за моделлю підписки, використовують API платформ або інструменти на кшталт RevenueCat для відтворення деталей по кожній транзакції, замість того, щоб намагатися відновити їх із щомісячного PDF-зведення.
Пропуск цього кроку має реальну ціну. Один широко цитований приклад: розробник побачив 1 294 були доступні для витрачання — розрив понад 60% між «доходом», який, на його думку, він мав, і тим, що бізнес насправді отримав. Розробники, які приймають рішення про найм або витрати на основі цифр на панелі керування, а не звірених показників, планують бюджет, виходячи з числа, яке ніколи не було реальним.
Поширені помилки, які спотворюють вашу звітність
- Запис лише чистого депозиту як доходу. Це найпоширеніша помилка, про яку йдеться в цій статті — вона занижує і дохід, і собівартість продажів, роблячи вашу картину валової маржі безглуздою.
- Ігнорування відшкодувань та чарджбеків. Apple і Google обробляють відшкодування клієнтам від вашого імені, іноді через тижні після початкового продажу — якщо ви не звіряєте дані по кожній транзакції, повернутий дохід може невизначено довго висіти у вашому обліку.
- Включення 25 реєстраційної плати Google до собівартості продажів. Це фіксовані операційні витрати, а не комісії на рівні транзакцій — вони належать до окремого відро витрат.
- Забування про окремий графік комісій ЄС. Якщо частина вашої бази користувачів знаходиться в ЄС і ви обрали альтернативні умови Apple, цей дохід має іншу структуру комісій, ніж решта вашого бізнесу, і потребує окремого рахунку.
Тримайте свої фінанси в порядку під час масштабування
Незалежно від того, чи ви самотній розробник з одним додатком у магазині, чи керуєте невеликою студією з кількома продуктами на основі підписки, рішення «валовий чи чистий» накопичується з кожним місяцем, коли ви робите його неправильно — до моменту, коли ви залучаєте інвестиції або подаєте заявку на фінансування, занижений рядок доходу важко пояснити. Beancount.io пропонує розробникам простий текстовий, версійований реєстр, створений саме для таких багатоетапних транзакцій — валовий продаж, комісія платформи та виплата як три окремі, перевірені записи, а не один розмитий банківський депозит. Почніть безкоштовно і побачте, чому розробники, які вже мислять кодом, надають перевагу бухгалтерії, яка працює так само.