شما یک محصول API اندازهگیری شده را عرضه کردهاید. مشتریان ۵۰۰ دلار اعتبار شارژ میکنند، طی شش هفته با فراخوانی endpoint شما آن را مصرف میکنند و شما پیشپرداخت دریافت میکنید. ساده به نظر میرسد، درست است؟ سپس حسابدار شما میپرسد: «در ماه مارس واقعاً چقدر درآمد کسب کردهاید؟»
اگر پاسخ شما «۵۰۰ دلار است، چون این مبلغ وارد حساب بانکی شده است» باشد، شما یک مشکل دارید - و مشکل کوچکی هم نیست. قیمتگذاری مبتنی بر مصرف و مصرفی به الگوی رایج برای محصولات API، ابزارهای هوش مصنوعی و استارتآپهای زیرساختی تبدیل شده است، اما قوانین حسابداری برای شناسایی آن درآمد به همین سادگی که مدل صورتحساب انعطافپذیرتر شده است، سادهتر نشده است. اگر این کار را اشتباه انجام دهید، نه تنها مالیات را نادرست ثبت میکنید، بلکه مسیر رشد خود را اشتباه میخوانید، سرمایهگذاران را گمراه میکنید و زمینه را برای یک بازبینی پرهزینه در آینده فراهم میکنید.
در اینجا توضیح داده میشود که چه چیزی واقعاً حاکم بر این موضوع است و چگونه میتوانید دفاتر حسابداری خود را طوری تنظیم کنید که اعداد از همان ابتدا درست باشند.
چرا «دریافت نقدی» به معنای «درآمد تحصیل شده» نیست
طبق اصول حسابداری پذیرفتهشده عمومی آمریکا (US GAAP)، شناسایی درآمد توسط ASC 606، یک چارچوب پنج مرحلهای، اداره میشود:
- شناسایی قرارداد با مشتری
- شناسایی تعهدات عملکرد در قرارداد
- تعیین قیمت معامله
- تخصیص قیمت معامله به تعهدات عملکرد
- شناسایی درآمد زمانی که (یا به همان ترتیبی که) هر تعهد عملکرد انجام میشود
برای یک اشتراک سالانه با نرخ ثابت، این کار آسان است - درآمد به طور یکنواخت طی ۱۲ ماه توزیع میشود، صرف نظر از اینکه فاکتور چه زمانی پرداخت شده است. برای صورتحساب مبتنی بر مصرف، مرحله ۵ جایی است که اوضاع واقعاً پیچیده میشود: شما درآمد را زمانی شناسایی میکنید که مشتری از خدمات استفاده میکند، نه زمانی که به شما پرداخت میکند.
همین یک جمله ریشه تقریباً تمام اشتباهات حسابداری مبتنی بر مصرف است. مشتری که ۵۰۰ دلار برای اعتبارات API پیشپرداخت میکند، ۵۰۰ دلار درآمد به شما نداده است - او ۵۰۰ دلار وجه نقد و یک بدهی به شما داده است. شما یا باید خدمات را به او ارائه دهید یا پول را برگردانید. تنها زمانی که آنها تماسها، ذخیرهسازی یا محاسبات را مصرف میکنند، شما میتوانید آن بدهی را به درآمد شناسایی شده منتقل کنید.
تعهد آمادهباش، به زبان ساده
حسابداران اصطلاحی برای آنچه که در واقع در یک مدل مبتنی بر مصرف میفروشید دارند: تعهد آمادهباش. شما فقط قول پردازش تماسهای API را نمیدهید - شما قول میدهید که در دسترس باشید تا آنها را به صورت درخواستی، هر زمان که مشتری بخواهد و تا هر حجمی که نیاز دارد، پردازش کنید.
این موضوع مهم است زیرا میتواند درآمد شما را به دو بخش مفهومی متفاوت تقسیم کند:
- جزء دسترسی - ارزش صرفاً در دسترس بودن (گاهی اوقات به صورت خطی در طول دوره قرارداد شناسایی میشود)
- جزء مصرف - ارزش ارائه شده به ازای هر واحد از مصرف واقعی (همانطور که مصرف رخ میدهد شناسایی میشود)
بیشتر محصولات خالص پرداخت به ازای هر تماس (بدون هزینه پایه، بدون تعهد حداقل) این را فقط به جزء مصرف تقلیل میدهند - که خبر خوبی است، زیرا این سادهترین حالت برای حسابداری است.
ملاحظات متغیر: چرا نمیتوانید فقط صبر کنید و ببینید
از آنجایی که مبلغ نهایی فاکتور به مصرفی بستگی دارد که هیچ کس در زمان امضای قرارداد نمیتواند پیشبینی کند، ASC 606 هزینههای مبتنی بر مصرف را به عنوان ملاحظات متغیر در نظر میگیرد. در تئوری، این بدان معناست که شما باید قیمت معامله را از قبل تخمین بزنید، با استفاده از یکی از روشهای زیر:
- روش ارزش مورد انتظار - میانگین وزنی احتمال نتایج ممکن، یا
- روش محتملترین مبلغ - بهترین حدس شما
و نکته مهم این است که شما فقط میتوانید یک تخمین را در درآمد شناسایی شده خود تا جایی که برگشت قابل توجهی بعداً رخ ندهد (پس از مشخص شدن مصرف واقعی) لحاظ کنید. این «محدودیت» به طور خاص وجود دارد تا شرکتها را از ثبت زودهنگام درآمد خوشبینانه و مجبور شدن به پسگرفتن آن بعداً باز دارد - الگویی که تنظیمکنندگان بارها در حسابرسیهای نرمافزاری به آن اشاره کردهاند.
برای یک توسعهدهنده مستقل که کار خود را به صورت چابک اداره میکند، ساختن پیشبینیهای مصرف وزنی بر اساس احتمال هر ماه کار اضافی است. خوشبختانه، یک میانبر وجود دارد.
روش تسهیلی که تقریباً هر کسبوکار API باید از آن استفاده کند
ASC 606 شامل یک روش تسهیلی «حق صدور فاکتور» است: اگر مبلغی که شما مجاز به صدور فاکتور برای آن در یک دوره معین هستید مستقیماً با ارزشی که در آن دوره تحویل دادهاید مطابقت داشته باشد، میتوانید از کل فرآیند تخمین صرفنظر کنید و فقط با وقوع مصرف، به میزان مبلغی که حق صدور فاکتور آن را دارید، درآمد را شناسایی کنید.
این الگوی استاندارد برای قیمتگذاری خالص به ازای هر تماس، هر توکن یا هر تراکنش است: اگر به ازای هر تماس API ۰.۰۰۱ دلار بدون تخفیف حجمی یا تعهد حداقل دریافت میکنید، مبلغی که میتوانید برای تماسهای یک روز خاص فاکتور کنید، همان ارزش تحویل داده شده در آن روز است. نیازی به تخمین نیست - شما با وقوع تماسها درآمد را شناسایی میکنید، نقطه سر خط.
جایی که این روش تسهیلی از کار میافتد قیمتگذاری پلکانی یا تجمعی بر اساس حجم است، جایی که نرخ هر واحد در دوره دوم به میزان مصرف مشتری در دوره اول بستگی دارد (مثلاً: «۱۰۰ هزار تماس اول با نرخ ۰.۰۰۲ دلار، هر چیزی بالاتر از آن با نرخ ۰.۰۰۱ دلار»). در آنجا، مبلغ فاکتور شده در هر دوره واحد به طور تمیز با ارزش آن دوره مطابقت ندارد و ممکن است به جای آن به تخمین مناسب نیاز داشته باشید. اگر قیمتگذاری شما دارای پلههای حجمی است، قبل از اینکه فرض کنید این میانبر قابل اجرا است، ارزش دارد با یک حسابدار در این مورد صحبت کنید.
یک راهنمای عملی
فرض کنید محصول API شما دارای هزینه پایه ۲۰۰ دلار در ماه است که شامل ۲۰۰,۰۰۰ تماس میشود، و مصرف اضافه با نرخ ۰.۰۰۱ دلار به ازای هر تماس، با همان نرخ مؤثر تماسهای شامل شده، صورتحساب میشود:
- پایه + مصرف شامل شده: از آنجایی که نرخ مصرف اضافه با نرخ مؤثر شامل شده مطابقت دارد، کل هزینه - پایه به اضافه مصرف اضافه - معمولاً واجد شرایط روش تسهیلی فاکتور است. شما ۲۰۰ دلار را به طور یکنواخت با مصرف ۲۰۰,۰۰۰ تماس شامل شده و همچنین ۰.۰۰۱ دلار به ازای هر تماس اضافه در زمان وقوع آن شناسایی میکنید.
- بستههای اعتبار پیشپرداخت: یک مشتری در ژانویه ۱,۰۰۰ دلار اعتبار میخرد. شما بدهکار وجه نقد، بستانکار درآمد معوق به مبلغ ۱,۰۰۰ دلار میکنید. همانطور که آنها در فوریه با نرخ ۰.۰۰۲ دلار به ازای هر تماس اعتبار مصرف میکنند، شما بدهکار درآمد معوق و بستانکار درآمد شناسایی شده را به صورت تماس به تماس ثبت میکنید. اگر ۳۰۰ دلار از اعتبارات تا پایان ماه استفاده نشده باقی بماند، ۳۰۰ دلار به عنوان یک بدهی در ترازنامه شما باقی میماند - نه درآمد، مهم نیست که مارس چقدر خوب به نظر برسد.
- مصرف صورتحساب نشده در پایان ماه: چرخه صورتحساب شما از اول تا اول ماه است، اما مصرف دسامبر یک مشتری تا ۲ ژانویه فاکتور نمیشود. این شکاف همچنان نیاز به یک ثبت حسابداری دارد: بدهکار دریافتنیهای صورتحساب نشده (یک دارایی)، بستانکار درآمد، به ارزش تماسهای انجام شده در دسامبر اما هنوز صورتحساب نشده. وقتی فاکتور واقعاً صادر میشود، شما از دریافتنیهای صورتحساب نشده به حسابهای دریافتنی استاندارد طبقهبندی مجدد میکنید - درآمد قبلاً ثبت شده است.
مالیات بر مبنای نقدی در مقابل دفاتر حسابداری تعهدی
اینجا جایی است که بسیاری از بنیانگذاران انفرادی گیج میشوند: اظهارنامه مالیاتی شما و شناسایی درآمد شما لازم نیست بر اساس یک مبنای یکسان باشند و اغلب نباید هم باشند. اکثر کسبوکارهای کوچک میتوانند مالیات را بر مبنای نقدی ثبت کنند - درآمد زمانی مشمول مالیات است که دریافت میشود، هزینهها زمانی قابل کسر هستند که پرداخت میشوند - صرف نظر از آنچه ASC 606 در مورد زمان «تحصیل» درآمد میگوید. یک LLC تکعضوی که اعتبارات API میفروشد، میتواند به طور قانونی مالیات را بر مبلغ ۱,۰۰۰ دلار پیشپرداخت در سالی که به حساب بانکی واریز میشود بپردازد، حتی در حالی که دفاتر داخلی آن فقط ۷۰۰ دلار را به عنوان درآمد شناسایی شده و ۳۰۰ دلار را به عنوان درآمد معوق نشان میدهد.
تله این است که این دو دیدگاه را قابل تعویض در نظر بگیرید و فقط یک مجموعه از اعداد را نگه دارید. اگر فقط مجموعهای مبتنی بر نقدی را پیگیری کنید، زمانی که یک خریدار بالقوه، سرمایهگذار یا وامدهنده در طول فرآیند بررسی دقیق (diligence) درخواست درآمد مبتنی بر اصول حسابداری پذیرفتهشده عمومی (GAAP) کند، پاسخ قابل دفاعی نخواهید داشت - و آن زمان برای بازسازی ماهها تاریخچه مصرف بسیار دیر است. از همان ابتدا هر دو دیدگاه را در دفتر کل خود نگه دارید: یک جریان نقدی که میتوانید به حسابدار مالیاتی خود تحویل دهید، و یک دیدگاه تعهدی با درآمد معوق و دریافتنیهای صورتحساب نشده که به طور صریح پیگیری میشوند، به طوری که بتوان به هر دو سوال از یک منبع واحد حقیقت پاسخ داد، نه یک صفحه گسترده که تحت فشار ضربالاجل ساخته شده است.
اشتباهاتی که واقعاً آسیب میزنند
صحبت با تیمهایی که این مراحل را پشت سر گذاشتهاند، نشان میدهد که شکستها حول تعداد انگشتشماری از الگوهای تکراری متمرکز هستند:
- انحراف اندازهگیری. اگر خط لوله ردیابی مصرف شما تماسها را نسبت به آنچه واقعاً صورتحساب میکنید، کمتر یا بیشتر شمارش کند، دفتر درآمد و سیستم صورتحساب شما بیصدا از هم فاصله میگیرند - و هیچ کس تا زمان تطبیق متوجه نمیشود، که برای یک تیم خودگردان ممکن است «هر زمان که حسابدار بپرسد چرا اعداد مطابقت ندارند» باشد.
- تغییرات طرح در اواسط چرخه بدون منطق تسعیر. یک مشتری در روز ۱۵ از یک چرخه ۳۰ روزه به سطح بالاتری ارتقا مییابد. اگر سیستم شما مصرف و قیمتگذاری آن دوره را به درستی تقسیم نکند، درآمد آن مشتری را در آن ماه بیش از حد یا کمتر از حد شناسایی خواهید کرد.
- عدم تفکیک بین منطق صورتحساب و منطق شناسایی درآمد. وسوسهانگیز است که «آنچه را فاکتور کردهایم» را به عنوان «آنچه به دست آوردهایم» در نظر بگیریم. برای اشتراکهای ثابت، این اعداد به سرعت همگرا میشوند. برای قیمتگذاری مبتنی بر مصرف، آنها اغلب اینطور نیستند - به خصوص با اعتبارات پیشپرداخت یا حداقلهای سالانه.
- درمان اختلافات و اعتبارات به عنوان یک موضوع حاشیهای. اگر یک مشتری با هزینه مصرف اضافه مخالفت کند و شما یک اعتبار صادر کنید، آن اعتبار باید از طریق دفتر درآمد شما بازگردد، نه فقط سیستم صورتحساب شما، در غیر این صورت درآمد را برای دورهای که از آن زمان آن را برگرداندهاید، بیش از حد نشان خواهید داد.
ساختن این ساختار در دفاتر حسابداری خود از روز اول
هیچ یک از این موارد زمانی که کوچک هستید به نرمافزار حسابداری سازمانی نیاز ندارد. آنچه نیاز دارد این است که رویدادهای مصرف خود را به عنوان یک مصنوع حسابداری واقعی در نظر بگیرید، نه فقط یک ورودی صورتحساب:
- یک گزارش حسابرسیپذیر از رویدادهای مصرف (زمان، مقدار، نرخ اعمال شده) جدا از سیستم صورتحساب خود نگه دارید - برای بازسازی درآمد بر اساس دوره و برای دفاع از اعداد در صورت حسابرسی یا جذب سرمایه به آن نیاز خواهید داشت.
- درآمد معوق و دریافتنیهای صورتحساب نشده را به عنوان حسابهای دفتر کل صریح پیگیری کنید، نه فرضیات ضمنی. اگر یک مشتری پیشپرداخت کرده و همه آن را استفاده نکرده است، آن مانده باید در دفاتر شما قابل مشاهده باشد، نه در یک داشبورد صورتحساب که هیچ کس جز فروش به آن نگاه نمیکند.
- سیستم صورتحساب خود را به طور برنامهریزی شده با دفتر درآمد خود تطبیق دهید - حداقل ماهانه - تا انحراف اندازهگیری در عرض هفتهها، نه فصلها، شناسایی شود.
این دقیقاً همان نوع ساختاری است که حسابداری متنمحور و تحت کنترل نسخه در آن خوب عمل میکند. هنگامی که نمودار حسابهای شما در یک دفتر کل تحت ردیابی Git به جای یک داشبورد SaaS جعبه سیاه قرار دارد، «درآمد معوق تا تاریخ ۱ مارس را به من نشان بده» و «هر ورودی درآمد مبتنی بر مصرف را برای این مشتری از زمان ثبتنام به من نشان بده» فقط کوئریهایی علیه یک فایل هستند که میتوانید واقعاً بخوانید - نه یک تیکت پشتیبانی به فروشنده صورتحساب خود.
درآمد مبتنی بر مصرف خود را صادقانه نگه دارید
قیمتگذاری مبتنی بر مصرف واقعاً برای مشتریان بهتر است و اغلب برای رشد بهتر است - اما پیچیدگی حسابداری واقعی را به بنیانگذارانی تحمیل میکند که ترجیح میدهند محصول را عرضه کنند. Beancount.io به شما حسابداری دوطرفه متنمحور میدهد که درآمد معوق، دریافتنیهای صورتحساب نشده و شناسایی مبتنی بر مصرف را شفاف و قابل حسابرسی میکند، به جای اینکه در داخل SaaS شخص دیگری پنهان شود. همین حالا به صورت رایگان شروع کنید و دفاتر خود را به اندازه خط لوله اندازهگیری خود دقیق نگه دارید.