Otvorte App Store Connect alebo Google Play Console a uvidíte číslo, ktoré vyzerá ako váš príjem. Minulý mesiac hovorilo 10 000 USD. Na váš bankový účet prišlo 7 000 USD. Ani jedno číslo nie je nesprávne – ale len jedno z nich patrí do vášho výkazu ziskov a strát ako „výnos“ a ak sa v tomto rozhodnutí pomýlite, môže to potichu skresliť vašu hrubú maržu, nesprávne uviesť mieru rastu a poskytnúť veriteľovi alebo investorovi obraz o vašom podnikaní, ktorý nie je pravdivý.
Toto je otázka principal vs agent a podľa štandardu vykazovania výnosov ASC 606 (US GAAP) to nie je voliteľná administratíva – je to pravidlo, ktoré rozhoduje o tom, či vykážete 10 000 USD výnosov a 3 000 USD nákladov na predaj, alebo len 7 000 USD výnosov bez čohokoľvek ďalšieho. Pre nezávislého vývojára predávajúceho cez App Store od Apple alebo Google Play Store odpoveď zvyčajne prekvapí.
Otázka, ktorú si skôr či neskôr položí každý vývojár aplikácií
Spúšťač je takmer vždy rovnaký: zakladateľ pripravuje prezentáciu pre investorov, žiada o úver pre malý podnik, alebo sa len snaží odpovedať na otázku „koľko som vlastne tento štvrťrok zarobil“ a zistí, že celý čas účtoval ako „tržby“ to, čo mu prišlo na bankový účet. Toto číslo je už po odpočítaní provízie Apple alebo Google – čiže už má odpočítaný podiel platformy.
Problém je v tom, že čistenie výnosov o poplatok za platformu nie je vecou štýlu. ASC 606 má pre túto situáciu špecifický test, ktorý sa točí okolo jednej otázky: kto kontroluje vec, ktorá sa predáva, predtým, ako sa dostane k zákazníkovi?
Test kontroly podľa ASC 606, jednoducho povedané
Päťkrokový model výnosov ASC 606 vyžaduje, aby ste identifikovali povinnosti plnenia v zmluve a určili, kto ich plní. Keď je medzi vami a koncovým zákazníkom trhovisko alebo platforma – Apple, Google, Etsy, DoorDash, Uber – účtovné štandardy to nazývajú posúdenie principal vs. agent a príručka o výnosoch od PwC uvádza, že predaj v obchodoch s aplikáciami je učebnicovým príkladom dohôd, ktoré si vyžadujú toto dôkladné posúdenie.
- Principal: kontrolujete tovar alebo službu predtým, ako sa prenesie na zákazníka. Ako výnos vykazujete plnú, hrubú sumu, ktorú zákazník zaplatil, a provízia platformy sa stáva nákladom na predaj (výdavkom), nie znížením výnosu.
- Agent: platforma kontroluje ponuku a vy len zabezpečujete predaj v mene niekoho iného. Ako svoj poplatok vykazujete len čistú sumu, ktorú si ponecháte.
O tom, kým ste, rozhodujú tri indikátory podľa rámcov Deloitte a PwC:
- Zodpovednosť za plnenie – kto je zodpovedný, ak aplikácia nefunguje, predplatné nedodáva službu alebo sa zákazník sťažuje? Zvyčajne ste to vy, vývojár, nie Apple.
- Riziko pred prevodom – kto nesie riziko, že sa „zásoby“ (vaša aplikácia, váš obsah, vaša úroveň predplatného) nepredajú alebo neuspokoja zákazníka? Opäť, zvyčajne vy.
- Právomoc určovať cenu – kto určuje, čo zákazník skutočne zaplatí? Vy si vyberáte cenovú úroveň svojej aplikácie; platforma ju s vami nevyjednáva prípad od prípadu.
Keďže väčšina nezávislých vývojárov kontroluje zážitok z produktu, vlastní vzťah so zákazníkom v oblasti podpory a aktualizácií a stanovuje si vlastné ceny, v teste skončia na strane principála – čo znamená, že správne účtovanie je zaznamenať hrubú sumu, ktorú zákazník zaplatil, ako výnos a podiel Apple alebo Google považovať za nákladovú položku výnosov, nie za neviditeľný odpočet.
Čísla skryté za odpočtom
Vedieť, že ste principal, má zmysel len vtedy, ak viete, čo sa vlastne odpočítava. Štruktúra poplatkov za platformu sa v posledných rokoch výrazne zmenila a väčšina vývojárov stále rozpočtuje na základe zastaraných predpokladov:
| Platforma | Štandardná sadzba | Znížená sadzba | Kto má nárok |
|---|---|---|---|
| App Store od Apple | 30% | 15% (App Store Small Business Program) | Vývojári s ročnými príjmami z App Store ≤ 1 milión USD |
| Predplatné Apple | 30% (1. rok) | 15% (od 2. roka ďalej) | Akékoľvek predplatné po prvých 12 mesiacoch |
| Google Play | 30% | 15% z prvého 1 milióna USD zarobeného ročne | Všetci vývojári, automatické odstupňovanie |
| Predplatné Google Play | 15% paušálne | — | Všetky príjmy z predplatného |
| Apple EÚ (podmienky aktu o digitálnych trhoch) | ~17 % + Core Technology Fee | až ~20 % kombinovane | Vývojári, ktorí sa rozhodli pre alternatívne obchodné podmienky EÚ |
Plus fixné ročné náklady, ktoré väčšina ľudí zabúda niekam priradiť: ročný poplatok pre vývojárov Apple 99 USD a jednorazový registračný poplatok Google 25 USD. Sú malé, ale patria niekam do vášho účtovného rozvrhu – zvyčajne ako všeobecný prevádzkový náklad, nie ako náklad na predaj.
Správne účtovanie: praktický príklad
Povedzme, že si zákazník kúpi predplatné v aplikácii za 9,99 USD cez Apple a vy ste pri štandardnej 30% sadzbe. Apple vyberie od zákazníka 9,99 USD, ponechá si 3,00 USD a nakoniec vám na bankový účet vloží 6,99 USD. Ak zaúčtujete 6,99 USD ako „výnos“, podhodnotíte svoj hrubý príjem o 30 % – čo obrovsky záleží, ak porovnávate mieru rastu s konkurentom, ktorý predáva priamo, alebo vysvetľujete svoje marže veriteľovi.
Správne zápisy vykazujú plný predaj a potom samostatne účtujú províziu ako náklad:
2026-07-18 * "Apple" "iOS predplatné – hrubý predaj"
Aktíva:Pohľadávky:AppStore 9.99 USD
Výnosy:PredajAplikácií -9.99 USD
2026-07-18 * "Apple" "30% provízia App Store"
Náklady:NákladyNaPredaj:PoplatkyZaPlatformu 3.00 USD
Aktíva:Pohľadávky:AppStore -3.00 USD
2026-07-20 * "Apple" "Prijatá platba"
Aktíva:BežnýÚčet 6.99 USD
Aktíva:Pohľadávky:AppStore -6.99 USDVšimnite si, že účet pohľadávok sa po vyrovnaní platby vynuluje, ale váš výkaz ziskov a strát stále ukazuje 9,99 USD výnosov a 3,00 USD nákladov na výnosy – 70% hrubú maržu z tohto predaja, nie záhadne chýbajúcich 30 %. Toto je presne ten typ transakcie, ktorý dobre zvládajú účtovné knihy v plain-text formáte so správou verzií: hrubý predaj, poplatok za platformu a platba sú tri samostatné, auditovateľné udalosti namiesto jedného rozmazaného bankového vkladu.
Prečo číslo na paneli nestačí
Aj keď pravidlo poznáte, jeho manuálne uplatnenie je náročnejšie, než sa zdá. Štandardné zostavy App Store Connect a Play Console zobrazujú agregované súčty, nie podrobnosti na úrovni predplatiteľov alebo transakcií, ktoré ASC 606 technicky vyžaduje – tržby, refundácie a premena mien často prichádzajú v jednej paušálnej sume dni alebo týždne po skutočnom predaji. Práve táto medzera je dôvodom, prečo rastúci počet firiem s predplatnými aplikáciami používa API platforiem alebo nástroje ako RevenueCat na rekonštrukciu podrobností o jednotlivých transakciách, namiesto snahy o spätné inžinierstvo z mesačného súhrnného PDF.
Vynechanie tohto kroku má skutočnú cenu. Jeden často citovaný príklad: vývojár videl na svojom paneli za mesiac 3 400 USD, no po províziách, daniach a iných zrážkach platformy bolo použiteľných len 1 294 USD – rozdiel viac ako 60 % medzi „výnosom“, ktorý si myslel, že má, a tým, čo si podnik v skutočnosti ponechal. Vývojári, ktorí robia rozhodnutia o prijímaní zamestnancov alebo výdavkoch na základe čísla na paneli namiesto zosúladeného údaju, rozpočtujú podľa čísla, ktoré nikdy nebolo skutočné.
Bežné chyby, ktoré skresľujú vaše účtovníctvo
- Účtovanie len čistého vkladu ako výnosu. Toto je najčastejšia chyba a o nej je tento článok – podhodnocuje výnosy aj náklady na predaj, čím robí váš obraz o hrubej marži nezmyselným.
- Ignorovanie refundácií a spätných zúčtovaní. Apple aj Google spracúvajú refundácie zákazníkom vo vašom mene, niekedy týždne po pôvodnom predaji – ak nezosúlaďujete podľa transakcií, vrátené výnosy vám môžu zostať v knihách na neurčito.
- Zmiešanie 99 USD poplatku pre vývojárov Apple alebo 25 USD registračného poplatku Google do nákladov na predaj. Sú to fixné prevádzkové náklady, nie provízie na úrovni transakcií – patria do úplne inej kategórie výdavkov.
- Zabudnutie na samostatný sadzobník poplatkov EÚ. Ak je časť vašej používateľskej základne v EÚ a vy ste sa rozhodli pre alternatívne podmienky Apple, tento príjem má inú štruktúru provízií ako zvyšok vášho podnikania a vyžaduje si vlastný účet.
Udržujte svoje financie organizované, ako rastiete
Či už ste sólový vývojár s jednou aplikáciou v obchode, alebo prevádzkujete malé štúdio s niekoľkými predplatnými produktmi, rozhodnutie o hrubom vs. čistom sa každý mesiac, keď ho robíte zle, znásobuje – keď príde čas na získanie investície alebo žiadosť o financovanie, podhodnotená položka výnosov sa len ťažko vysvetľuje. Beancount.io poskytuje vývojárom účtovnú knihu v plain-text formáte so správou verzií, navrhnutú presne pre tento typ viacstupňových transakcií – hrubý predaj, provízia platformy a platba ako tri samostatné, auditovateľné položky namiesto jedného rozmazaného bankového vkladu. Začnite zadarmo a uvidíte, prečo vývojári, ktorí už premýšľajú v kóde, uprednostňujú účtovníctvo, ktoré funguje rovnako.