App Store Connect یا Google Play Console را باز کنید و عددی را میبینید که حس درآمد شما را القا میکند. ماه گذشته ۱۰۰۰۰ دلار نشان میداد. حساب بانکی شما ۷۰۰۰ دلار دریافت کرد. هیچکدام از این اعداد اشتباه نیستند – اما فقط یکی از آنها به عنوان "درآمد" در صورت سود و زیان شما قرار میگیرد و اشتباه گرفتن این تصمیم میتواند به طور نامحسوس حاشیه سود ناخالص شما را مخدوش کند، نرخ رشد شما را نادرست نشان دهد، و تصویری از کسبوکارتان به وامدهنده یا سرمایهگذار ارائه دهد که واقعی نیست.
این پرسش اصلی در مقابل نماینده است و طبق استاندارد شناسایی درآمد ASC 606 تحت GAAP ایالات متحده، این یک کار اداری اختیاری نیست – بلکه قانونی است که تعیین میکند آیا شما ۱۰۰۰۰ دلار درآمد و ۳۰۰۰ دلار بهای تمام شده فروش گزارش میدهید، یا فقط ۷۰۰۰ دلار درآمد و نه چیز دیگر. برای یک توسعهدهنده مستقل که از طریق فروشگاه اپلیکیشن اپل یا فروشگاه Google Play میفروشد، پاسخ معمولاً افراد را شگفتزده میکند.
پرسشی که هر توسعهدهنده اپلیکیشن سرانجام میپرسد
علت تقریباً همیشه یکسان است: یک بنیانگذار در حال آمادهسازی یک دک ارائه برای سرمایهگذاری است، برای وام کسبوکار کوچک درخواست میدهد، یا فقط سعی میکند به این سوال پاسخ دهد که "در این سهماهه واقعاً چقدر درآمد داشتهام" و متوجه میشود که هر مبلغی که به حساب بانکیاش واریز شده را به عنوان "فروش" ثبت کرده است. این عدد خالص از کمیسیون اپل یا گوگل است – یعنی سهم پلتفرم قبلاً از آن کم شده است.
مشکل این است که خالص کردن درآمدتان در برابر هزینه پلتفرم یک انتخاب سبکی نیست. ASC 606 یک آزمون خاص برای دقیقاً این موقعیت دارد و به یک سوال بستگی دارد: چه کسی چیزی را که فروخته میشود قبل از اینکه به دست مشتری برسد، کنترل میکند؟
آزمون کنترل ASC 606، به زبان ساده
مدل پنج مرحلهای درآمد ASC 606 از شما میخواهد که تعهدات عملکردی در یک قرارداد را شناسایی کرده و تعیین کنید چه کسی آنها را انجام میدهد. وقتی یک بازارگاه یا پلتفرم بین شما و مشتری نهایی قرار میگیرد – اپل، گوگل، Etsy، DoorDash، Uber – استانداردهای حسابداری این را ارزیابی اصلی در مقابل نماینده مینامند و راهنمای درآمد PwC خاطرنشان میکند که فروش فروشگاه اپلیکیشن یک مثال کلاسیک از ترتیباتی است که نیاز به این بررسی دقیق دارند.
- اصلی (Principal): شما کالا یا خدمات را قبل از انتقال به مشتری کنترل میکنید. شما مبلغ کامل و ناخالص پرداخت شده توسط مشتری را به عنوان درآمد شناسایی میکنید و کمیسیون پلتفرم به عنوان بهای تمام شده فروش (یک هزینه) ثبت میشود، نه کاهشی در درآمد.
- نماینده (Agent): پلتفرم عرضه را کنترل میکند و شما فقط فروش را از طرف شخص دیگری ترتیب میدهید. شما فقط مبلغ خالصی را که به عنوان کارمزد خود نگه میدارید، شناسایی میکنید.
سه شاخص تعیین میکند که شما کدام یک هستید، مطابق با چارچوبهای Deloitte و PwC:
- مسئولیت اجرا – چه کسی در صورت کار نکردن اپلیکیشن، تحویل ندادن اشتراک، یا شکایت مشتری، مسئول است؟ معمولاً این شما هستید، توسعهدهنده، نه اپل.
- ریسک قبل از انتقال – چه کسی ریسک عدم فروش یا عدم رضایت مشتری از "موجودی" (اپلیکیشن، محتوا، رده اشتراک شما) را متحمل میشود؟ باز هم، معمولاً شما.
- اختیار قیمتگذاری – چه کسی تعیین میکند که مشتری واقعاً چقدر بپردازد؟ شما رده قیمتی اپلیکیشن خود را انتخاب میکنید؛ پلتفرم آن را مورد به مورد با شما مذاکره نمیکند.
از آنجایی که اکثر توسعهدهندگان مستقل تجربه محصول را کنترل میکنند، مالک رابطه با مشتری برای پشتیبانی و بهروزرسانی هستند، و قیمتگذاری خود را تعیین میکنند، در سمت اصلی آزمون قرار میگیرند – یعنی حسابداری صحیح این است که مبلغ ناخالص پرداخت شده توسط مشتری را به عنوان درآمد ثبت کنید و سهم اپل یا گوگل را به عنوان یک ردیف بهای تمام شده درآمد در نظر بگیرید، نه یک کسر نامرئی.
اعداد پشت کسر
دانستن اینکه شما اصلی هستید تنها زمانی اهمیت دارد که بدانید چه چیزی واقعاً کسر میشود. ساختار هزینههای پلتفرم در چند سال گذشته به طور قابل توجهی تغییر کرده است و اکثر توسعهدهندگان هنوز بر اساس مفروضات قدیمی بودجهبندی میکنند:
| پلتفرم | نرخ استاندارد | نرخ کاهشیافته | چه کسانی واجد شرایط هستند |
|---|---|---|---|
| فروشگاه اپلیکیشن اپل | ۳۰٪ | ۱۵٪ (برنامه کسبوکار کوچک فروشگاه اپلیکیشن) | توسعهدهندگانی با درآمد سالانه ≤ ۱ میلیون دلار از فروشگاه اپلیکیشن |
| اشتراکهای اپل | ۳۰٪ (سال اول) | ۱۵٪ (سال دوم به بعد) | هر اشتراکی که از ۱۲ ماه اول خود گذشته باشد |
| Google Play | ۳۰٪ | ۱۵٪ برای اولین ۱ میلیون دلار درآمد سالانه | همه توسعهدهندگان، به صورت خودکار طبقهبندی شده |
| اشتراکهای Google Play | ۱۵٪ ثابت | — | تمام درآمد حاصل از اشتراک |
| اپل اتحادیه اروپا (شرایط قانون بازارهای دیجیتال) | ~۱۷٪ + هزینه فناوری اصلی | تا حدود ۲۰٪ ترکیبی | توسعهدهندگانی که شرایط تجاری جایگزین اتحادیه اروپا را انتخاب میکنند |
به علاوه هزینههای سالانه ثابتی که اکثر افراد فراموش میکنند در جایی تخصیص دهند: هزینه برنامه توسعهدهنده ۹۹ دلار در سال اپل و هزینه ثبتنام یکباره ۲۵ دلاری گوگل. کوچک هستند، اما جایی در فهرست حسابهای شما نیز دارند – معمولاً به عنوان یک هزینه عملیاتی عمومی، نه بهای تمام شده فروش.
ثبت صحیح آن: یک مثال عملی
فرض کنید یک مشتری یک اشتراک درونبرنامهای ۹.۹۹ دلاری را از طریق اپل خریداری میکند و شما تحت نرخ استاندارد ۳۰٪ هستید. اپل ۹.۹۹ دلار را از مشتری دریافت میکند، ۳.۰۰ دلار را نگه میدارد و در نهایت ۶.۹۹ دلار را به حساب بانکی شما واریز میکند. ثبت ۶.۹۹ دلار به عنوان "درآمد" خط بالای صورت سود و زیان شما را ۳۰٪ کمتر از واقع نشان میدهد – که اگر نرخ رشد خود را با رقیبی مقایسه کنید که مستقیماً میفروشد، یا حاشیه سود خود را برای یک وامدهنده توضیح میدهید، بسیار مهم است.
ثبتهای صحیح فروش کامل را شناسایی کرده و سپس کمیسیون را به طور جداگانه به عنوان یک هزینه ثبت میکنند:
2026-07-18 * "Apple" "اشتراک iOS — فروش ناخالص"
Assets:Receivable:AppStore 9.99 USD
Income:AppSales -9.99 USD
2026-07-18 * "Apple" "کمیسیون ۳۰٪ فروشگاه اپلیکیشن"
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توجه کنید که حساب دریافتنی پس از تسویه واریز به صفر میرسد، اما صورت سود و زیان شما همچنان ۹.۹۹ دلار درآمد و ۳.۰۰ دلار بهای تمام شده درآمد را نشان میدهد – یک حاشیه سود ناخالص ۷۰٪ برای آن فروش، نه یک ۳۰٪ گمشده مرموز. این دقیقاً نوع تراکنشی است که دفترهای متنمحور با کنترل نسخه به خوبی مدیریت میکنند: فروش ناخالص، هزینه پلتفرم و واریز، سه رویداد مجزا و قابل حسابرسی به جای یک واریز بانکی مبهم.
چرا عدد داشبورد کافی نیست
حتی وقتی قانون را میدانید، اعمال دستی آن سختتر از چیزی است که به نظر میرسد. گزارشهای معمول App Store Connect و Play Console مجموعهای تجمیعشده را نشان میدهند، نه جزئیات سطح مشترک و سطح تراکنشی که ASC 606 از نظر فنی میخواهد – درآمدها، بازپرداختها و تبدیل ارز اغلب روزها یا هفتهها پس از فروش واقعی در یک مبلغ یکجا قرار میگیرند. این شکاف دقیقاً دلیلی است که تعداد فزایندهای از کسبوکارهای اپلیکیشن اشتراکی از APIهای پلتفرم یا ابزارهایی مانند RevenueCat برای بازسازی جزئیات هر تراکنش استفاده میکنند، به جای تلاش برای مهندسی معکوس آن از یک PDF خلاصه ماهانه.
رد کردن این مرحله هزینه واقعی دارد. یک مثال که به طور گسترده ذکر شده است: یک توسعهدهنده به ۳۴۰۰ دلار نشان داده شده در داشبورد خود برای یک ماه نگاه کرد و پس از کمیسیونها، مالیاتها و سایر کسورات پلتفرم، تنها ۱۲۹۴ دلار قابل خرج کردن بود – یک شکاف ۶۰٪+ بین "درآمدی" که فکر میکرد دارند و آنچه کسبوکار واقعاً نگه داشته بود. توسعهدهندگانی که تصمیمات استخدامی یا هزینهای را بر اساس عدد داشبورد به جای رقم تطبیقشده میگیرند، در حال بودجهبندی علیه عددی هستند که هرگز واقعی نبوده است.
اشتباهات رایجی که کتابهای شما را مخدوش میکنند
- ثبت فقط واریز خالص به عنوان درآمد. این رایجترین اشتباه است و موضوع این مقاله است – هم درآمد و هم بهای تمام شده فروش را کمتر از واقع نشان میدهد و تصویر حاشیه سود ناخالص شما را به چیزی بیمعنی تبدیل میکند.
- نادیده گرفتن بازپرداختها و برگشتوجهها. اپل و گوگل هر دو بازپرداخت مشتری را از طرف شما پردازش میکنند، گاهی هفتهها پس از فروش اصلی – اگر تراکنش به تراکنش تطبیق ندهید، درآمد بازپرداخت شده میتواند به طور نامحدود در کتابهای شما باقی بماند.
- قرار دادن هزینه ۹۹ دلاری توسعهدهنده اپل یا هزینه ثبتنام ۲۵ دلاری گوگل در بهای تمام شده فروش. اینها هزینههای عملیاتی ثابت هستند، نه کمیسیونهای سطح تراکنش – آنها به یک سطل هزینه کاملاً متفاوت تعلق دارند.
- فراموش کردن برنامه هزینه مجزای اتحادیه اروپا. اگر هر بخشی از پایگاه کاربران شما در اتحادیه اروپا است و شما شرایط جایگزین اپل را انتخاب کردهاید، آن درآمد ساختار کمیسیون متفاوتی نسبت به بقیه کسبوکار شما دارد و به حساب خود نیاز دارد.
با رشد، امور مالی خود را سازماندهی کنید
چه یک توسعهدهنده انفرادی با یک اپلیکیشن در فروشگاه باشید و چه یک استودیوی کوچک با چند محصول اشتراکی داشته باشید، تصمیم ناخالص در مقابل خالص هر ماه که آن را اشتباه میگیرید، اثر مرکب دارد – تا زمانی که برای یک دور سرمایهگذاری یا درخواست تأمین مالی اقدام میکنید، یک ردیف درآمد کمتر از واقع، چیزی است که توضیح آن دشوار است. Beancount.io یک دفتر متنمحور با کنترل نسخه را به توسعهدهندگان ارائه میدهد که دقیقاً برای این نوع تراکنش چند مرحلهای ساخته شده است – فروش ناخالص، کمیسیون پلتفرم و واریز به عنوان سه ورودی مجزا و قابل حسابرسی به جای یک واریز بانکی مبهم. به صورت رایگان شروع کنید و ببینید چرا توسعهدهندگانی که قبلاً به کد فکر میکنند، حسابداری را ترجیح میدهند که به همین شکل کار کند.