از یک بنیانگذار SaaS در سال ۲۰۲۲ بپرسید که این ماه چقدر درآمد ثبت میکنند، پاسخ یک فرمول صفحهگسترده بود: تعداد کاربر ضربدر قیمت، با محاسبه تناسبی برای روزهای باقیمانده از قرارداد. امروز از یک بنیانگذار بومی هوش مصنوعی همین سوال را بپرسید، و پاسخ صادقانه این است که "بستگی دارد مشتریان ما چقدر از مدل استفاده کردهاند." مصرف توکن میتواند در یک هفته دو برابر شود وقتی مشتری یک ویژگی را وارد مرحله تولید میکند، یا وقتی یک آزمایش را متوقف میکند، ثابت بماند. هیچ تعداد کاربر ثابتی برای اتکا در پیشبینی وجود ندارد.
این تغییر از اشتراک به مصرف فقط یک تصمیمگیری مربوط به قیمتگذاری نیست. این یک مشکل حسابداری است و دقیقاً در ASC 606 قرار میگیرد — همان استاندارد شناخت درآمد که از سال ۲۰۱۸ بر SaaS حاکم بوده است، فقط با ورودی بسیار کمتر قابل پیشبینی اعمال میشود. اگر اشتباه کنید، با یک خطای گرد کردن مواجه نیستید؛ بلکه با یک سال مالی بازنگریشده در طول فرآیند بررسی دقیق مواجه میشوید، درست زمانی که کمترین توانایی را برای آن دارید.
چرا قیمتگذاری مبتنی بر توکن، رویکرد قدیمی را از بین میبرد
شناخت درآمد سنتی SaaS به نسبت انعطافپذیرتر است. مشتری ۱۲,۰۰۰ دلار برای یک برنامه سالانه پرداخت میکند، شما ماهی ۱,۰۰۰ دلار شناسایی میکنید، و بزرگترین تصمیمگیری این است که آیا تغییر قرارداد نیاز به تخصیص مجدد دارد یا خیر. مبلغ قرارداد ثابت است. تعهد عملکرد — دسترسی به نرمافزار در طول زمان — ساده است. حسابرسان هزاران قرارداد مشابه این را دیدهاند.
هوش مصنوعی و قیمتگذاری مبتنی بر مصرف، بخش ثابت را حذف میکند. مشتریان برای توکنهای پردازششده، تماسهای API انجامشده، اجراهای استنتاج تکمیلشده، یا ثانیههای محاسبات مصرفشده پرداخت میکنند. این مبلغ ذاتاً متغیر است و ASC 606 بخش کاملی — راهنمای "مبلغ متغیر" در ASC 606-10-32-11 تا 32-13 — را دقیقاً به این مشکل اختصاص داده است. چالش اصلی فلسفی نیست، بلکه عملی است: چقدر درآمد را در دورهای شناسایی میکنید که در لحظه بستن دفاتر خود، واقعاً نمیدانید یک مشتری دقیقاً چقدر بدهکار خواهد بود؟
برای یک شرکت هوش مصنوعی در مراحل اولیه، این موضوع قبل از اینکه آسان شود، دشوارتر میشود. یک کسبوکار SaaS بالغ میتواند به سالها سابقه مصرف برای برآورد مطمئن تکیه کند. شرکتی که مدل قیمتگذاری مبتنی بر توکن خود را هشت ماه پیش عرضه کرده است، چنین مقایسههایی ندارد. مصرف میتواند به شدت نوسان کند زیرا مشتریان از مرحله آزمایشی به تولید میروند، و الگوی سه ماهه گذشته ممکن است اطلاعات کمی در مورد سه ماهه جاری داشته باشد.
دو شکل قرارداد که همه چیز را تعیین میکنند
قبل از اینکه بتوانید یک دلار درآمد مبتنی بر مصرف را به درستی شناسایی کنید، باید بدانید در واقع در کدام یک از این دو ساختار قرار دارید — زیرا حسابداری آنها متفاوت است.
مصرف خالص، بدون حداقل تعهد. مشتری یک بسته اعتباری خریداری میکند یا موافقت میکند که به ازای هر واحد مصرفشده پرداخت کند، بدون هیچ سقفی. اگر این ترتیب یک سرویس ساده باشد (شما دسترسی به یک مدل میزبانی شده را فراهم میکنید، نه مجوز IP که مشتری به طور مستقل از آن بهرهبرداری میکند)، عموماً نمیتوانید از استثنای محدود "حق امتیاز مبتنی بر مصرف برای IP" در ASC 606-10-55-65 استفاده کنید — این برای ترتیبات صدور مجوز مانند حق امتیاز بر روی یک ثبت اختراع طراحی شده است، نه برای یک API میزبانی شده. در عوض، شما مبلغ متغیر را با استفاده از روش ارزش مورد انتظار یا محتملترین مبلغ برآورد میکنید، با این قید که نباید مبالغی را شناسایی کنید که "برگشت قابل توجهی" پس از رفع ابهام، محتمل باشد.
حداقل تعهد به علاوه اضافه مصرف. مشتری متعهد میشود، مثلاً، به ۲,۰۰۰ دلار مصرف در ماه و در صورت تجاوز از آن، بیشتر پرداخت میکند. در اینجا حداقل تعهد مانند مبلغ ثابت عمل میکند — آن را به صورت منظم شناسایی کنید زیرا مشتری ارزش را دریافت میکند — در حالی که هر چیزی بالاتر از حداقل، مبلغ متغیر است و مشمول همان قوانین برآورد و محدودیت میشود. این ترکیب هیبریدی به طور مداوم در قیمتگذاری هوش مصنوعی ظاهر میشود: یک هزینه پلتفرم پایه به علاوه استنتاج اندازهگیریشده در بالا.
دانستن اینکه در کدام شکل قرار دارید، ورودیهای دفتر روزنامه، یادداشتهای افشاگری، و میزان نگرانی حسابرس شما را در مورد برآوردهایتان تغییر میدهد.
راه حل عملی که اکثر شرکتهای هوش مصنوعی واقعاً استفاده میکنند
خبر خوب اینجاست: ASC 606 یک میانبر برای دقیقاً همین موقعیت دارد، و اکثر قراردادهای مبتنی بر مصرف که به خوبی ساختار یافتهاند، واجد شرایط آن هستند.
"حق صورتحساب" (right to invoice) که یک راه حل عملی است (ASC 606-10-55-18) به شما اجازه میدهد تا از برآورد کل مبلغ قرارداد صرفنظر کنید. اگر آنچه در هر دوره صورتحساب میکنید مستقیماً با ارزشی که مشتری در آن دوره دریافت کرده است مطابقت داشته باشد — شما ۰.۰۰۲ دلار به ازای هر ۱,۰۰۰ توکن شارژ کردید، مشتری ۴ میلیون توکن استفاده کرد، شما ۸ دلار صورتحساب میدهید — میتوانید به سادگی آن ۸ دلار را به عنوان درآمد در دورهای که کسب شده است شناسایی کنید. بدون پیشبینی، بدون تحلیل محدودیت، بدون برآورد مجدد در هر زمان بستن حساب.
نکته اصلی در عبارت "مستقیماً مطابقت دارد" است. اگر قیمتگذاری شما دارای لایههایی باشد که نرخ هر واحد با افزایش حجم کاهش مییابد، یا تخفیفهای بستهای که به طور تمیز به دورهای که مصرف در آن رخ داده است، مرتبط نیستند، این راه حل عملی میتواند از بین برود — مبلغ صورتحساب دیگر نماینده ارزش آن دوره نیست، و شما دوباره به برآورد کامل مبلغ متغیر باز میگردید. ساختار قیمتگذاری خود را با در نظر گرفتن این آزمایش به طور خاص بررسی کنید قبل از اینکه فرض کنید این راه حل عملی به طور یکنواخت در کل کتاب قراردادهای شما اعمال میشود.
اکثر قراردادهای هوش مصنوعی مبتنی بر مصرف نیز واجد شرایط معاملات سریالی تحت ASC 606-10-25-14 هستند: به جای حسابداری هر تماس API به عنوان یک تعهد عملکرد خرد مجزا، شما کل جریان مصرف را به عنوان یک تعهد عملکرد واحد در طول زمان برآورده شده در نظر میگیرید. این همان چیزی است که راه حل عملی صورتحساب را از نظر اداری قابل اجرا میکند — شما هزاران تعهد فردی را پیگیری نمیکنید، شما یک سرویس مداوم را با قیمت متغیر پیگیری میکنید.
اعتبارات پیشپرداخت شده: درآمد معوق و مشکل شکست
بسیاری از پلتفرمهای هوش مصنوعی بستههای اعتباری پیشپرداختشده میفروشند — ۵۰۰ دلار توکن را از قبل بخرید و طی ماههای آینده از آنها استفاده کنید. این ساختار محبوب است زیرا جریان نقدی را بهبود میبخشد و تعهد را تثبیت میکند، اما دو تعهد حسابداری را معرفی میکند که بنیانگذاران معمولاً از آنها غافل میشوند.
درآمد معوق بر موجودی استفادهنشده. لحظهای که وجه نقد برای یک بسته پیشپرداخت شده دریافت میشود، هیچکدام از آن هنوز درآمد نیست. این یک بدهی است — شما به مشتری یا خدمت یا بازپرداخت بدهکار هستید. درآمد تنها زمانی که توکنها واقعاً مصرف میشوند، از خط درآمد معوق به صورت سود و زیان منتقل میشود. بنیانگذاری که کل ۵۰۰ دلار را در روز جمعآوری ثبت میکند، درآمد را بیش از حد گزارش کرده و باید آن را تصحیح کند، معمولاً در بدترین زمان ممکن: در طول بررسی دقیق جمعآوری سرمایه، زمانی که یک حسابرس برنامه را بازسازی میکند و تفاوت را از دورهای که قبلاً به سرمایهگذاران ارائه شده است، خارج میکند.
شکست بر اعتباراتی که هرگز استفاده نمیشوند. برخی مشتریان یک بسته اعتباری میخرند و هرگز قبل از انقضا، تمام آن را استفاده نمیکنند. آن موجودی استفادهنشده — شکست — صرفاً پول رایگانی نیست که در روز انقضای اعتبارات شناسایی کنید. طبق ASC 606، انتظار میرود نرخ شکست را از الگوهای بازخرید تاریخی تخمین بزنید و آن شکست تخمینزده شده را به صورت تناسبی، به عنوان افزایشی کوچک به درآمد در کنار استفاده واقعی، شناسایی کنید، نه اینکه منتظر انقضا بمانید تا همه آن را یکباره ثبت کنید. اگر هنوز سابقه بازخرید ندارید (که در برنامههای اعتباری جدید رایج است)، رویکرد محافظهکارانه این است که تا زمان جمعآوری سابقه صبر کنید و در این مدت، شکست را تنها هنگام انقضا شناسایی کنید و پس از داشتن چند گروه از دادهها، سیاست را بازبینی کنید.
جایی که انضباط محدودیت واقعاً اهمیت دارد
«محدودیت» بر مابهازای متغیر تا زمانی که یک فصلی را تجربه نکردهاید که استفاده یک مشتری بزرگ ۴ برابر افزایش یافته و سپس بازگشته است، انتزاعی به نظر میرسد. ASC 606 از شما میخواهد که مابهازای متغیر را در برآورد درآمد خود فقط تا حدی لحاظ کنید که احتمال زیادی وجود داشته باشد که برگشت قابل توجهی بعداً لازم نخواهد بود. در عمل، این به معنای:
- سال اول یک مدل قیمتگذاری جدید: رویکرد محافظهکارانه در پیش بگیرید. حداقلهای متعهدشده و موارد واقعی را با اطمینان شناسایی کنید؛ هر چیزی را که فراتر از استفاده فاکتورشده/واقعی پیشبینی میشود، با تردید واقعی در نظر بگیرید، زیرا هیچ قرارداد قابل مقایسهای برای معیار قرار دادن ندارید.
- با انباشت تاریخچه استفاده: محدودیت شما میتواند کمتر شود، زیرا اکنون یک مبنای قابل دفاع (استفاده این مشتری برای شش ماه متوالی بین X و Y متغیر بوده است) برای برآورد دقیقتر دارید.
- در هر زمان بستن حسابها: مجدداً برآورد کنید. مابهازای متغیر یک عدد «ثابت و فراموشکردنی» نیست — هر دوره گزارشدهی با ورود اطلاعات جدید بازبینی میشود، و تعدیل انباشته جبرانی از طریق دوره جاری اعمال میشود.
برای یک تیم مالی که این موضوع را در صدها یا هزاران قرارداد مدیریت میکند، راهحل عملی این است که سیستم صورتحسابنویسی و دفتر ثبت شناسایی درآمد خود را قبل از بستن حسابها، و نه بعد از آن، هماهنگ کنید — به طوری که دادههای استفاده به طور خودکار تطبیق داده شوند به جای اینکه هر پایان ماه نیاز به یک ردپای حسابرسی دستی داشته باشد.
چرا این موضوع حتی اگر کوچک باشید اهمیت دارد
اگر شما یک استارتاپ دو نفره ابزارهای هوش مصنوعی هستید که به تعداد انگشتشماری از مشتریان بر اساس توکن صورتحساب میدهید، وسوسهانگیز است که همه اینها را «موضوعی که وقتی سرمایه سری A جمع کردیم با آن سروکار خواهیم داشت» تلقی کنید. این یک ریسک واقعی است. خطاهای شناسایی درآمد یکی از رایجترین یافتهها در بررسی دقیق جمعآوری سرمایه در SaaS هستند، و قیمتگذاری مبتنی بر استفاده، تعداد قضاوتهایی را که یک حسابرس مایل است مستند شده ببیند، افزایش میدهد: کدام قراردادها از روش صورتحسابنویسی سریع استفاده میکنند، کدام نرخ شکست را فرض کردهاید و چرا، و چگونه با فصلی که استفاده مشتری به اوج خود رسید، برخورد کردید.
انجام صحیح مکانیسمها از روز اول — حتی در مقیاس کوچک — به این معنی است که شما بعدها تحت فشار مهلت زمانی، هجده ماه تاریخچه درآمد را بازسازی نمیکنید. همچنین به این معنی است که اعدادی که داخلی برای تصمیمگیری در مورد قیمتگذاری و استخدام استفاده میکنید، واقعاً دقیق هستند، نه اینکه توسط درآمد معوق شناسایینشدهای که نباید در آنجا باشد، باد شده باشند.
دفاتر خود را به شفافیت مدل قیمتگذاریتان نگه دارید
قیمتگذاری مبتنی بر استفاده و توکن، واقعاً پیچیدهتر از یک اشتراک ماهانه ثابت برای حسابداری است، اما این پیچیدگی قابل حسابرسی است — فقط نیاز به مستندسازی ساختار قرارداد، منطق محدودیت، و فرضیات شکست شما در طول زمان دارد، نه اینکه بعداً آنها را بازسازی کنید. حسابداری متنساده Beancount.io این مسیر مستندسازی را صریح میکند: هر ورودی شناسایی درآمد، موجودی درآمد معوق، و تعدیل شکست در متنی با کنترل نسخه قرار دارد که شما (یا حسابرس شما) میتوانید خط به خط آن را ردیابی کنید، نه اینکه در یک پلتفرم صورتحسابنویسی جعبه سیاه پنهان شود. به صورت رایگان شروع کنید و دفتر خود را به شفافیت مدل قیمتگذاری که بر پایه آن میسازید، نگه دارید.