App Store Connect казва, че сте продали 3 108. Събирате ги, чувствате се добре от 6 580 от Apple, $2 210 от Google. Никой не ви е откраднал. Всеки липсващ долар има име: ДДС, комисионна, възстановявания, удържан данък, валутна конверсия и накрая данък върху дохода. Проблемът не е самият разрив — а това, че повечето независими разработчици нямат счетоводна книга, която да го обясни, така че не могат да отговорят на трите въпроса, които наистина имат значение: Правилно ли е ценообразуването ми? На правилната ли съм комисионна ставка? Реалистичен ли е прогнозният ми паричен поток?
Това ръководство преминава през целия процес от обявената цена до реално полученото, обяснява защо плащането никога не съвпада с отчета и ви дава месечна процедура за съгласуване, която отнема около 30 минути, след като е настроена.
Три числа, три различни отговора
Всеки бизнес с приложения има три числа за приходите и смесването им е точно там, където започва объркването:
- Брутни продажби — това, което клиентите са платили, както е показано в аналитичните табла. Това е числото на суетата. То включва данъка, където магазинът го събира, и обикновено е оценка, която по-късно се коригира.
- Приходи на разработчика — това, което магазинът казва, че сте спечелили, от месечните финансови отчети (Apple) и отчетите за приходи (Google). Това е сумата след приспадане на комисионната, данъка, който магазинът събира и внася, възстановяванията и сторниранията. Това е числото, върху което трябва да е изградено счетоводството ви.
- Плащането — банковият депозит. Приходите минус всякакъв удържан данък, коригирани спрямо валутна конверсия, и подлежащи на минимални прагове за плащане и платежния календар на магазина.
Ако книгите ви записват само банковия депозит, приходите ви са тихо подценени и отложени с месец или повече. Ако записват брутните продажби, приходите са надценени с 30–50% и не съвпадат с никакви пари, които някога получавате. Цялото изкуство на счетоводството за магазини за приложения е да свърже тези три числа, така че всеки месец да приключва с нулева разлика между отчетените приходи и получените пари.
Процесът от обявената цена до реално полученото
Вземете абонамент за €9,99, продаден в държава с 20% ДДС, при стандартна комисионна от 30%. Ето честната версия на това, което се случва:
| Стъпка | Изчисление | Остатък | % от обявената цена |
|---|---|---|---|
| Обявена цена | — | €9,99 | 100% |
| ДДС, събран и внесен от магазина | €9,99 ÷ 6 | €8,33 | 83% |
| Комисионна на магазина (стандартна ставка) | 30% × €8,33 | €5,83 | 58% |
| Възстановявания и сторнирания (приемете 3%) | 3% × €5,83 | €5,65 | 57% |
| Данък върху дохода при ефективни 30% | 30% × €5,65 | €3,96 | 40% |
Приблизително 60% от обявената цена никога не достига до джоба ви. Продажба в САЩ в щат, който не облага цифрови стоки, започва от по-висока база, а разработчик с намалена комисионна ставка запазва значително повече (същата продажба в регион с ДДС при 15% комисионна дава €7,08 преди възстановявания — около 71% от обявената цена). Точният процент зависи от микса ви от продажби, но структурният урок важи навсякъде: брутните приходи не са ваши пари. Те са пари на магазина, които минават през таблото ви.
Нищо от това не е скрито. Условията на програмите на Apple и Google изброяват всяко приспадане. Това, което липсва в повечето независими бизнеси, е проследяването — място, където всеки слой от процеса е записан, проверим факт, вместо месечна изненада.
Комисионната ставка, която всъщност плащате
Най-скъпата грешка, свързана със счетоводството, в тази област е да сте на грешна ставка. И двата магазина намаляват наполовина комисионната си за по-малки разработчици, а записването не е автоматично навсякъде:
Програмата за малък бизнес на App Store на Apple намалява комисионната от 30% на 15% за платени приложения, покупки в приложението и абонаменти. Допустимостта се измерва в приходи — продажби след приспадане на комисионната на Apple и определени данъци и корекции, а не брутни — и изисква да сте спечелили не повече от 1 милион до момента през текущата година. Два детайла объркват разработчиците:
- Ако надхвърлите $1 милион посред годината, стандартната ставка от 30% се прилага за бъдещи продажби — продажбите, вече направени при 15%, не се орязват, и можете да се квалифицирате отново годината след като приходите ви паднат под прага.
- Промените в ставката влизат в сила 15 дни след края на фискалния месец, в който записването ви е одобрено, така че забавеното записване струва реални пари за всяка седмица, в която стои в списъка ви със задачи.
Намаленото ниво на Google Play прилага 15% за първите $1 милион, които печелите всяка календарна година, като ставката от 30% влиза в сила за приходите над това — записвате се, като групирате асоциираните си акаунти в Play Console и приемете условията. Една структурна разлика, която си струва да знаете: в Google всички автоматично подновяеми абонаменти се облагат с 15% такса за услуга от първия ден, независимо от записването в програмата. При стандартната ставка на Apple абонатът плаща 30% за първите си 12 месеца и 15% от втората година нататък — тих аргумент за задържане на клиенти, който има значение само след като излезете от намалената програма.
Ако сте под $1 милион и не сте записани в програмата на Apple, поправянето на това е вероятно десетте минути с най-висока възвръщаемост за годината ви: процесът на записване е в App Store Connect под Споразумения, данъци и банкиране.
Защо депозитът никога не съвпада с отчета
Дори с правилната ставка, приходите и плащанията се разминават по причини, които са чисто механични — и всяка от тях заслужава ред в книгите ви:
Платежните календари не са месечни. Apple плаща в рамките на 45 дни след края на всеки фискален месец, а фискалните ѝ месеци не съвпадат с календарните — фискален месец може да приключи на 27 декември, като плащането пристига на 29 януари. На практика разривът е около 33 дни. Google плаща на 15-о число на следващия месец (прескачайки до следващия работен ден, когато 15-о число е уикенд). Ако използвате счетоводство на принципа на начисляването, приходите от декември са парите от януари или средата на февруари, и книгите ви се нуждаят от разплащателна сметка за плащания, за да свърже двете.
Минималните прагове забавят малки плащания. Apple плаща само когато приходите ви надвишат минимален праг за плащане, който варира според държавата на банкиране и валутата. Бавен месец може да означава никакъв депозит, като балансът се пренася — което изглежда като липсващи $30, освен ако не го проследявате.
Възстановяванията и сторниранията се приспадат преди приходите. Магазините възстановяват цялата транзакция, а процентът ви на възстановявания тихо варира според продукта и региона. Отчетено правилно, това е контра-приход в месеца, в който възстановяването се появява в отчета, а не мистериозно приспадане от депозита.
Данъците преминават през две различни врати. За ДДС и много данъци върху продажбите магазините действат като търговец на запис за данъчни цели — в ЕС, например, Google начислява, събира и внася ДДС, така че приходите ви се изчисляват върху базата без данък и обикновено не подавате декларации за ДДС в тези държави. Отделно, разработчици извън САЩ са изправени пред удържане на американски данък върху всякакви суми с произход от САЩ, което може да бъде плосък процент от 30%, ако не сте подали W-8BEN или W-8BEN-E в App Store Connect (или еквивалента в Play Console). Ставки по данъчни спогодби — или просто фактът, че плащанията често идват от международните субекти на магазините — могат да намалят това до нула. Във всеки случай, удържането се появява като разлика между отчетените приходи и депозита, и обикновено е възстановимо като кредит — ако го запишете.
Валутната конверсия е реален разход. Магазините плащат във валутата на банковото ви споразумение, конвертирайки приходите от всеки регион по пътя. Спредът на валутния курс е разход без фактура, така че единственият начин да го видите е да сравните отчетените приходи по валута с депозита.
Счетоводният въпрос, който повечето независими разработчици решават погрешно
Трябва ли редът за приходите да показва брутни продажби или нетни приходи? За преобладаващото мнозинство от независимите разработчици отговорът е нетни. Съгласно рамките за признаване на приходи, които се прилагат към US GAAP (ASC 606) и IFRS 15, тестът е дали вие сте принципалът в продажбата — дали контролирате стоката или услугата преди прехвърлянето на клиента — или агент, чието задължение за изпълнение е изпълнено, когато магазинът направи продажбата. Когато магазинът е търговец на запис, събира данъка, настройва платежните канали, поема механизмите за възстановявания и ви плаща нетна сума за транзакция, магазинът е принципалът и вашите приходи са вашите приходи (нетни). Отчитането на брутни продажби и показването на комисионната като разход раздува приходите, изкривява всеки марж, който изчислявате, и подвежда данъците, ако някой някога погледне.
Втората грешка е във времето: отчитане на банковия депозит като приход за този месец. Депозитът урежда приходите от миналия месец (или миналия фискален месец). Правилният модел е:
- Начислете приходите, когато продажбите се случат, използвайки оценките на магазина, ако действителните все още не са излезли.
- Коригирайте към действителните, когато месечният финансов отчет пристигне, записвайки разликата между оценката и действителното (почти винаги има такава — валута, възстановявания и късни корекции се погрижат за това).
- Приключете депозита срещу вземането, когато плащането пристигне, като всякакъв остатък отива към удържане, валутни разлики или пренасяне над прага — всяко със собствена сметка.
Последната клауза е цялата игра: когато всеки остатък има поименна сметка, ненулева разлика е невъзможно да бъде пропусната и отнема минути за обяснение.
30-минутен месечен процес на съгласуване
- Изтеглете действителните данни. От App Store Connect изтеглете месечния финансов отчет (подробния, който обхваща всеки регион, с дати на сетълмент). От Play Console изтеглете отчета за приходите. Те — не аналитичните табла — са вашите първични документи.
- Запишете приходите по регион и валута. Един ред за приходи за всеки магазин, с региони и валути, проследявани отдолу. Тук живее одитната следа: в деня, в който трябва да отговорите „защо приходите от ЕС паднаха с 12% през март“, ще искате ДДС, комисионна и възстановявания, разбити, а не едно смесено число.
- Постнете корекцията между оценка и действително. Разликата между това, което таблото е прогнозирало, и това, което отчетът казва: обикновено възстановявания, валута и корекции за масови плащания.
- Запишете възстановяванията и сторниранията като контра-приход в месеца на отчета и следете процента с течение на времето — нарастващ процент на възстановявания е продуктов сигнал, облечен в счетоводен костюм.
- Съгласувайте плащането с вземането. Когато депозитът пристигне, съпоставете го с отчета. Удържането отива в данъчна вземаема сметка (често е кредитируемо); валутните разлики отиват в разход за валута; къс депозит под минималния праг остава в разплащателната сметка до следващия месец.
- Проверявайте комисионната си ставка на тримесечие. Проверете записването си в Small Business Program в App Store Connect и нивото си в Play Console — особено ако се приближавате до $1 милион приходи, където и двата магазина променят ставката за бъдещи продажби. Моделирайте преминаването преди да се случи: преминаването на линията може да преправи цялата ви маржова структура посред годината.
Шест стъпки, едно заседание на месец. Печалбата не е само чисти книги — а това, че ценовите решения, записванията за ставки и прогнозирането на паричния поток започват да работят на база приходи, вместо на суетното число.
Проследявайте целия процес в обикновен текст
Точно това е видът многопластово съгласуване, където счетоводството в обикновен текст показва стойността си. Беанкаунт сметкоплан дава на всеки слой от процеса собствена сметка — income:appstore:ios, income:playstore:android, expenses:refunds, assets:receivable:payouts:apple, assets:tax-withheld — така че месечният запис е обяснението, и всяка цифра се връзва с изтеглен отчет, който можете да пресъздадете години по-късно. Тъй като сметкопланът е текст, отчетите от магазините могат да стоят до него в системата за контрол на версиите, и съгласуването се превръща в диф, вместо проект за археология в електронни таблици. Ако искате механизма за импортиране на банкови извлечения и данни от магазините, документацията разглежда процеса на импортиране в дълбочина.
Опростете финансовото си управление
Приходите от магазини за приложения са най-съгласуваният срещу вас доход, който повечето разработчици ще имат: комисионни, данъци, възстановявания и платежни календари всички вземат своя дял, преди парите да достигнат до вас. Воденето на книги, които отразяват този процес — вместо едно „приходи от приложения“ — е това, което превръща объркващото плащане в прозрачна, проверима система. Beancount.io предлага счетоводство в обикновен текст, което е прозрачно, с контрол на версиите и готово за изкуствен интелект, така че всеки отчет от магазин, корекция и депозит остава проследим. Започнете безплатно и направете реално полученото от вас толкова четливо, колкото кода ви.