Протягом тринадцяти років кожен долар, зароблений iOS-додатком від американського клієнта, проходив через єдиний канал: систему внутрішньо-програмних покупок Apple, де Apple забирала свою частку, перш ніж розробник взагалі бачив гроші. Це змінилося у квітні 2025 року, коли федеральний суддя визнав Apple неповагою до оригінальної заборони Epic v. Apple і наказав припинити стягувати будь-яку комісію за покупки, здійснені через зовнішні платіжні посилання. Потім це змінилося знову у грудні 2025 року, коли Дев'ятий окружний апеляційний суд погодився, що Apple зрештою може стягувати щось — просто не штрафну ставку в 27%, яку вона спробувала спочатку. І це може змінитися ще раз, оскільки 2 липня 2026 року Верховний суд погодився розглянути апеляцію Apple щодо всього цього безладу.
Якщо ви продаєте цифрові товари або підписки через iOS-додаток, у вас тепер є два активні канали доходу з двома різними наборами податкових зобов'язань, двома різними merchants of record та — станом на сьогодні — двома різними ставками комісії. Ось що насправді змінилося, що досі не вирішено, і як вести облік, поки юристи закінчують судові суперечки.
Як ми сюди потрапили, простою мовою
Коротка версія п'ятирічної судової саги:
- 2021 рік: Суддя Івонн Гонсалес Роджерс постановила, що правила Apple щодо "заборони перенаправлення" (які забороняли додаткам навіть повідомляти користувачам, що вони можуть платити поза додатком) порушують Каліфорнійський закон про недобросовісну конкуренцію. Вона наказала Apple дозволити зовнішні посилання на покупки.
- 2024 рік: Apple формально виконала вимогу, але прив'язала 27% комісію до будь-якого продажу, здійсненого протягом семи днів після того, як користувач натиснув зовнішнє посилання — плюс контрактні умови, які, на думку Epic, були розроблені, щоб зробити зовнішні посилання комерційно безглуздими.
- Квітень 2025 року: Суддя Роджерс визнала Apple неповагою до суду, назвала 27% комісію "штрафною", а не компенсаційною, і наказала Apple негайно припинити стягувати будь-яку комісію за покупки через зовнішні посилання в США.
- Грудень 2025 року: Дев'ятий окружний апеляційний суд в основному підтримав висновок про неповагу, але повернув питання комісії до окружного суду, постановивши, що Apple зрештою може стягувати плату "на основі витрат, які є справді та обґрунтовано необхідними для координації зовнішніх посилань... але не більше" — прямо виключивши витрати на безпеку та конфіденційність, які Apple намагалася включити.
- Квітень 2026 року: Дев'ятий окружний апеляційний суд зняв призупинення, дозволивши процедурі повернення справи продовжитися.
- 2 липня 2026 року: Верховний суд прийняв до розгляду апеляцію Apple (certiorari).
Як це виглядає сьогодні: Американські розробники можуть додавати зовнішні посилання на покупки з 0% комісією Apple, оскільки жоден суд ще не затвердив конкретну заміну ставки. Це може змінитися, щойно окружний суд встановить нову ставку, або якщо остаточне рішення Верховного суду переформатує всю структуру. Не будуйте постійну стратегію ціноутворення на сьогоднішньому числі — будуйте систему бухгалтерського обліку, достатньо гнучку, щоб поглинути будь-яку наступну ставку.
Що ви насправді можете зробити зараз
Якщо ви розробник, зареєстрований у США, з iOS-додатком, ви можете подати заявку на право зовнішнього посилання на покупку (External Purchase Link Entitlement) від Apple, що дозволяє вам:
- Додати посилання або кнопку всередині додатку, яка направляє користувачів на веб-сторінку для завершення покупки
- Повідомляти про ціни та акції, пов'язані з цією зовнішньою покупкою (раніше заборонено старими правилами заборони перенаправлення)
- Обробляти цю транзакцію повністю поза системою внутрішньо-програмних покупок Apple — через Stripe, Paddle, власний merchant-рахунок або будь-який інший процесор на ваш вибір
Ви все ще зобов'язані звітувати Apple про відповідні зовнішні транзакції, зазвичай протягом 15 днів, щоб Apple могла відстежувати дотримання вимог, навіть поки вона стягує $0. Пропустіть це — і ви ризикуєте позбавленням права, тому це має бути у вашому регулярному бухгалтерському контрольному списку, а не просто завдання на день запуску.
Два винятки, про які варто знати: розробники в Програмі об'ємних покупок (VPP) та Програмі новинних партнерів (NPP) від Apple все ще можуть мати обмеження щодо зовнішніх посилань, а ЄС діє за зовсім окремою структурою комісій (правила Digital Markets Act з багаторівневою Core Technology Commission, Initial Acquisition Fee та платою за магазинні послуги), яка не має нічого спільного з вищезгаданим судовим процесом у США. Якщо ви продаєте на обох ринках, вам потрібні два різні бухгалтерські підходи, а не один.
Чому це бухгалтерська проблема, а не лише юридична
До появи зовнішніх посилань бухгалтерія App Store була майже механічно простою: Apple була merchant of record, Apple збирала податок з продажів та ПДВ, Apple відраховувала свою комісію в 15% або 30%, і ви обліковували один чистий депозит за платіжний період, часто звіряючись з єдиним 1099-K або 1099-MISC у січні.
Продажі через зовнішні посилання розбивають це на другий, структурно інший потік доходу:
| Внутрішньо-програмна покупка | Покупка через зовнішнє посилання | |
|---|---|---|
| Merchant of record | Apple | Ви (або ваш платіжний процесор) |
| Збір податку з продажів / ПДВ | Відповідальність Apple | Ваша відповідальність |
| Комісія сьогодні (США) | 30% стандарт / 15% Small Business Program | 0% (очікує рішення окружного суду) |
| Час виплати | Стандартний графік Apple | Встановлюється вашим процесором |
| Податкова форма | 1099-K або 1099-MISC від Apple | 1099-K від вашого процесора, якщо досягнуто порогів |
| Обробка повернень | Через App Store | Через ваш власний процес підтримки |
Останній рядок важливіший, ніж здається. Коли відбувається повернення за внутрішньо-програмною покупкою, Apple скасовує транзакцію та коригує звітні дані для вас. Коли відбувається повернення за зовнішньою покупкою, ви повинні його обробити, і воно взагалі не потрапляє в облік Apple — це означає, що ваші записи доходів і повернень для двох каналів не збігатимуться один з одним, і їх не слід примусово зводити.
Налаштування вашого обліку для двох каналів доходу
Кілька конкретних кроків, які допоможуть уникнути січневого сюрпризу:
1. Розділіть рахунок доходу. Не об'єднуйте "Дохід від App Store" в один рядок у головній книзі. Створіть окремі рахунки (або принаймні окремі теги/категорії) для доходу від внутрішньо-програмних покупок та доходу від зовнішніх посилань. Коли ставка комісії за зовнішні посилання врешті-решт буде встановлена — 5%, 12% або будь-яка інша, яку вибере окружний суд — ви матимете історичні дані про обсяг цього каналу для моделювання впливу до того, як він набуде чинності.
2. Обліковуйте дохід за вирахуванням комісії, але відстежуйте валовий дохід окремо. Стандартна практика для програмного доходу згідно з ASC 606 полягає у визнанні суми, на яку ви фактично мали право — за вирахуванням частки Apple — як доходу, оскільки комісія ніколи вам не належала. Але для звірки та майбутнього моделювання зберігайте валовий обсяг транзакцій у полі примітки або тегу для звітності. Він знадобиться вам у день оголошення ставки комісії, щоб негайно оцінити вплив.
3. Розглядайте збір податку з продажів як новий пасивний рахунок. Якщо ви тепер merchant of record для продажів через зовнішні посилання, ви (або ваш платіжний процесор) відповідаєте за збір та сплату податку з продажів у кожному штаті, де у вас є податковий зв'язок (nexus) — обов'язок, який Apple мовчки виконувала за вас у додатку. Якщо ваш процесор не обробляє податки автоматично (Stripe Tax та merchant-of-record модель Paddle пропонують це по-різному — перевірте, який варіант у вашого процесора), це найлегше місце, де можна непомітно недозбирати податки місяцями, поки аудит не виявить це.
4. Звіряйте дві форми 1099, а не одну. У січні ви, швидше за все, отримаєте 1099-K або 1099-MISC від Apple за дохід у додатку та окремий 1099-K від процесора, який обробляв ваші продажі через зовнішні посилання (як тільки ви перетнете федеральний поріг у $600 — у деяких штатах нижче). Звірте обидві форми з вашою внутрішньою головною книгою до подання звітності; невідповідність між тим, що повідомляє процесор, і тим, що ви записали, є однією з найпоширеніших причин для повідомлення від IRS.
5. Зафіксуйте 15-денний графік звітності. Вимога Apple щодо звітності про зовнішні транзакції — це завдання з дотримання норм із реальними наслідками (позбавлення права) у разі його порушення, тому воно має бути в тій системі, яку ви використовуєте для відстеження регулярних бухгалтерських завдань, а не просто в "усній традиції".
Структура, якій байдуже, яким буде рішення
Оскільки ставка комісії все ще не визначена — і може бути знову переглянута після рішення Верховного суду — фактичне завдання тут не "будувати для 0%". Воно полягає у створенні плану рахунків та структури звітності, яка розглядає ставку комісії як змінну, а не константу. Текстові, керовані версіями бухгалтерські книги роблять цю конкретну проблему простішою, ніж облік на основі електронних таблиць: ви можете позначити кожну зовнішню транзакцію її каналом та ставкою комісії на момент продажу, а потім повторно запустити звіт, щойно буде підтверджено нову ставку, не торкаючись історичних записів і не ламаючи формули на три вкладки глибше в робочій книзі.
Зберігайте дохід від додатка в порядку з першого дня
Розподіл доходу між внутрішньо-програмними покупками App Store, зовнішніми платіжними посиланнями та структурою комісій ЄС, яка діє за зовсім іншими правилами — це саме той вид багатоканальної складності, який перетворює податковий сезон на метушню. Beancount.io пропонує вам текстовий, керований версіями бухгалтерський облік, де кожну транзакцію можна позначити за каналом, ставкою комісії та юрисдикцією — повністю прозоро та з можливістю запитів, без прив'язки до постачальника. Почніть безкоштовно і тримайте фінанси свого додатка такими ж чистими, як ваш код.