عامل هوش مصنوعی شما میتواند ۱۰٬۰۰۰ بار در یک ماه تلاش کند و همچنان تحت قرارداد هیچ درآمدی کسب نکرده باشد، اگر تنها ۷٬۲۰۰ بار تعریف مشتری از موفقیت برآورده شود. این تنش حسابداری پشت قیمتگذاری مبتنی بر نتیجه است: مدل ممکن است دائماً مشغول باشد، اما تعهدی که فروختهاید ممکن است بر اساس نتایج تکمیلشده سنجیده شود.
همانطور که نرمافزارهای عاملمحور از پاسخ به سوالات به حل اختلافات، پردازش فاکتورها، جلوگیری از کلاهبرداری و تکمیل سایر گردشکارها حرکت میکنند، قراردادهای SaaS بیشتری هزینهها را به آنچه سیستم به دست میآورد گره میزنند. این مدل تجاری میتواند قیمت را با ارزش مشتری هماهنگ کند. همچنین میتواند شناسایی درآمد، تطبیق صورتحساب و پیشبینی را بسیار دشوارتر کند.
سوال کلیدی طبق ASC 606 صرفاً این نیست که «عامل چند بار اجرا شد؟» بلکه این است که «قرارداد چه تعهدی به مشتری داده است و آن تعهد چه زمانی منتقل شد؟»
با تعهد شروع کنید، نه با متر
قیمتگذاری مبتنی بر نتیجه میتواند ترتیبات مختلفی را توصیف کند. دو قرارداد ممکن است هر دو به ازای هر تراکنش موفق هزینه بگیرند در حالی که به نتایج حسابداری متفاوتی نیاز دارند.
تعهد آماده برای ارائه خدمت
در یک ترتیب آماده برای ارائه خدمت، فروشنده متعهد میشود که سرویس هوش مصنوعی را در طول یک دوره در دسترس قرار دهد. مشتری از داشتن این قابلیت در زمانی که نیاز دارد بهرهمند میشود، خواه درخواستهای زیادی برسد یا نه. هزینه ماهانه پلتفرم، دسترسی نامحدود، یا استفادهای که عمدتاً توسط کاربران نهایی مشتری هدایت میشود، اغلب به این سمت اشاره میکند.
درآمد برای خدمات اصلی اغلب در طول زمان شناسایی میشود، با استفاده از معیار پیشرفت مبتنی بر زمان، زمانی که خدمات به طور یکنواخت در طول مدت ارائه میشود. هزینه به ازای هر نتیجه ممکن است همچنان ملاحظات متغیر باشد، اما این به طور خودکار به این معنی نیست که فقط زمانی که پول نقد دریافت میشود شناسایی میشود.
مقدار مشخصی از نتایج
در یک ترتیب مصرفی، تعهد نزدیکتر به «تحویل ۲۵٬۰۰۰ نتیجه تکمیلشده» است. هر نتیجه واجد شرایط، حق باقیمانده مشتری را کاهش میدهد. پس از تحویل مقدار خریداریشده، مشتری برای ظرفیت بیشتر تصمیم خرید جدیدی میگیرد.
این ساختار میتواند از روش خروجی پشتیبانی کند: قیمت اختصاصیافته به هر نتیجه موفق را به محض انتقال توسط فروشنده شناسایی کنید. تلاشهای ناموفق، حق باقیمانده مشتری را مصرف نمیکنند، زمانی که قرارداد بیان میکند مشتری برای تلاشهای ناموفق خدمتی دریافت نمیکند.
تعهد ترکیبی
بسیاری از قراردادهای واقعی هر دو مدل را ترکیب میکنند. مشتری ممکن است هزینه ماهانه ثابتی برای دسترسی به پلتفرم میزبانیشده و مبلغی جداگانه برای هر فاکتور تکراری تأییدشدهای که جلوگیری شده است بپردازد. هزینه دسترسی و هزینه نتیجه نباید صرفاً به این دلیل که در یک صورتحساب ظاهر میشوند، در یک الگوی شناسایی قرار گیرند.
تعهد دسترسی ثابت ممکن است در طول دوره خدمت شناسایی شود. هزینه نتیجه ممکن است زمانی شناسایی شود که معیارهای موفقیت برآورده شوند، اگر قرارداد از آن نتیجه حمایت کند و ملاحظات متغیر بتواند به دوره یا نتیجه مربوطه تخصیص یابد.
PwC همین تمایز عملی را در راهنمای SaaS خود描述 میکند: مدل اشتراک به طور کلی دسترسی مستمر فراهم میکند، در حالی که مدل مصرف، وظیفه مشخصی را انجام میدهد یا خروجی خاصی را در ازای هزینه ارائه میدهد. برچسبها در ارائه قیمتگذاری تعیینکننده نیستند. حقوق، تعهدات و منفعت مشتری در قرارداد اجراشده تعیینکننده هستند.
درخت تصمیم ASC 606
این توالی را برای هر قرارداد بااهمیت استفاده کنید. نتیجه را مستند کنید به جای تکیه بر برنامه پیشفرض سیستم صورتحساب.
۱. تعریف نتیجه موفق
«موفقیت» باید به اندازه کافی عینی باشد که هر دو طرف بتوانند تعیین کنند فروشنده چه زمانی مستحق دریافت هزینه شده است. برای عامل پردازش فاکتور، قرارداد ممکن است همه موارد زیر را الزام کند:
- فاکتور دریافت و با سفارش خرید مربوطه مطابقت داده شود.
- کنترلهای لازم بدون ارجاع انسانی تکمیل شود.
- ثبت حسابداری در سیستم تعیینشده مشتری انجام شود.
- تراکنش در طول دوره بازبینی مشخصی برگشت نخورد.
اگر موفقیت به عبارتی نامشخص مانند «اتوماسیون رضایتبخش» بستگی دارد، فروشنده ممکن است مبنای قابل اتکایی برای ثبت هزینه نتیجه نداشته باشد. تست را قبل از نوشتن ثبت دفتر روزنامه بنویسید.
۲. شناسایی آنچه مشتری دریافت میکند
بپرسید آیا مشتری دریافت میکند:
- دسترسی مستمر به یک عامل در یک دوره مشخص؛
- تعداد محدودی نتیجه تکمیلشده؛
- حقوق فزاینده برای استفاده از یک پلتفرم؛ یا
- ترکیبی از دسترسی، پیادهسازی، پشتیبانی و نتایج.
این سوال تعهد عملکرد است. همان عامل میتواند در یک قرارداد خدمت آماده و در قرارداد دیگر خدمت با خروجی مشخص باشد، زیرا تعهدات و حقوق مشتری متفاوت است.
۳. تعیین اینکه آیا ترتیب یک سری است
خدمت SaaS آماده معمولاً به عنوان سری از خدمات روزانه یا ماهانه متمایز که اساساً یکسان هستند و الگوی انتقال یکسانی دارند، ارزیابی میشود. اگر هزینه نتیجه مربوط به یک دوره مشخص در آن سری باشد، استثنای تخصیص ملاحظات متغیر ممکن است شناسایی در آن دوره را که نتایج واجد شرایط رخ میدهند، مجاز کند.
به عنوان مثال، خدمتی میتواند دسترسی نامحدود به مدت ۱۲ ماه فراهم کند و برای هر مداخله موفق کلاهبرداری در ماهی که مداخله رخ میدهد، ۳ دلار هزینه بگیرد. اگر نرخ ثابت باشد، تعریف موفقیت قابل اندازهگیری باشد و هزینه مربوط به خدمت آن ماه باشد، شناسایی هزینه نتیجه هنگام وقوع مداخلات واجد شرایط ممکن است انتقال را به طور صادقانه نمایش دهد.
نتیجه زمانی کمتر سرراست میشود که هزینه به عملکرد تجمعی سالانه، تخفیفهای ایجادی، تعدیلهای بین دورهای یا حداقل سالانه بستگی دارد. آن ویژگیها میتوانند مانع انتساب هزینه به یک دوره خدمت مشخص شوند.
۴. آزمون تسهیل عملی صورتحساب
تسهیل عملی صورتحساب میتواند شناسایی درآمد را به مبلغی که فروشنده حق صورتحساب دارد، زمانی که آن مبلغ مستقیماً با ارزش منتقلشده به مشتری تا تاریخ مربوطه مطابقت دارد، مجاز کند. برای ترتیب آماده واجد شرایط، مبلغ ثابت به ازای هر نتیجه موفق که هنگام وقوع هر نتیجه صورتحساب میشود، ممکن است آن الگو را برآورده کند.
تسهیل را به عنوان میانبری برای هر قرارداد مبتنی بر استفاده تلقی نکنید. احتمال اعمال آن کمتر است زمانی که قرارداد شامل هزینه ثابت، حداقل ماهانه قابل توجه، نرخهای متغیر بر اساس حجم، یا هزینههای اولیه یا نهایی قابل توجه باشد. پیشپرداخت بزرگ نیز ممکن است با ارزش منتقلشده در تاریخ صورتحساب مطابقت نداشته باشد.
۵. اعمال محدودیت ملاحظات متغیر
زمانی که نه تسهیل صورتحساب و نه استثنای تخصیص، موضوع را حل نمیکند، ملاحظات متغیر را تخمین بزنید و فقط مبلغی را لحاظ کنید که به احتمال زیاد (در سطح احتمال زیاد) برگشت قابل توجهی در درآمد شناساییشده ایجاد نخواهد کرد. آن تخمین را هر دوره گزارشگری بهروز کنید.
محصولات هوش مصنوعی در مراحل اولیه اغلب سابقه کافی برای پیشبینی مطمئن نرخ موفقیت، نرخ استثنا، پذیرش مشتری و برگشتها ندارند. این عدم اطمینان یک واقعیت حسابداری است، نه دلیلی برای شناسایی خوشبینانه. تخمین مستند را از دادههای قرارداد فعلی، گردشکارهای مشابه، نتایج آزمایشی و حالتهای خرابی شناختهشده بسازید، سپس با عملکرد محصول آن را بازبینی کنید.
مثال عملی: دسترسی ثابت به علاوه نتایج تأییدشده
فرض کنید فروشنده قرارداد ۱۲ ماههای با این شرایط امضا میکند:
- هزینه ماهانه پلتفرم ۱۰٬۰۰۰ دلار برای دسترسی میزبانیشده، نظارت و پشتیبانی.
- ۱۲ دلار برای هر فاکتوری که عامل از ابتدا تا انتها پردازش کند، به درستی ثبت کند و بررسی برگشت ۳۰ روزه را پشت سر بگذارد.
- بدون حداقل تعداد فاکتور.
- صورتحساب ماهانه بر اساس گزارش نتایج تأییدشده.
هزینه پلتفرم خدمت آماده را توصیف میکند. اگر مشتری به طور یکنواخت در طول سال به سرویس دسترسی داشته باشد، فروشنده هر ماه ۱۰٬۰۰۰ دلار درآمد ثبت میکند، مگر اینکه واقعیت دیگری نتیجه را تغییر دهد.
مبلغ ۱۲ دلار ملاحظات متغیر مبتنی بر نتیجه است. اگر معیارهای موفقیت قرارداد واضح باشد، نرخ ثابت باشد و مبلغ مربوط به خدمت آن ماه باشد، فروشنده ممکن است ۱۲ دلار را هنگام تکمیل هر نتیجه واجد شرایط شناسایی کند. نتیجهای که هنوز در پنجره بازبینی ۳۰ روزه است ممکن است به تصمیم خط مشی نیاز داشته باشد: قرارداد ممکن است موفقیت را در زمان ثبت، پذیرش یا فقط پس از بسته شدن پنجره برگشت تعریف کند. رویداد قراردادی را به طور مداوم استفاده کنید.
اگر ۸۰۰ نتیجه در ماه مارس واجد شرایط شوند، درآمد نتیجه ۹٬۶۰۰ دلار است. بنابراین درآمد ماه مارس قبل از مالیات، برگشتها، اعتبارات یا سایر شرایط قرارداد، ۱۹٬۶۰۰ دلار است. واریز بانکی ممکن است در آوریل انجام شود؛ زمان نقدی، درآمد مارس را به آوریل منتقل نمیکند.
برای قرارداد پیشپرداخت با نتایج محدود، ثبت اولیه متفاوت خواهد بود. اگر مشتری ۱۲۰٬۰۰۰ دلار برای ۱۰٬۰۰۰ نتیجه موفق پیشپرداخت کند، وجه نقد و بدهی قرارداد را هنگام دریافت پرداخت ثبت کنید. با انتقال هر نتیجه واجد شرایط، ۱۲ دلار درآمد شناسایی کرده و بدهی را کاهش دهید. اگر نتایج استفادهنشده منقضی شوند، شکست (breakage) را طبق قرارداد و خط مشی درآمد مربوطه ارزیابی کنید، نه اینکه صرفاً به دلیل پایان دوره، کل مانده را آزاد کنید.
به زبان ساده:
مشتری برای ۱۰٬۰۰۰ نتیجه موفق پیشپرداخت میکند
بدهکار وجه نقد $۱۲۰,۰۰۰
بستانکار بدهی قرارداد $۱۲۰,۰۰۰
۸۰۰ نتیجه به ازای هر کدام ۱۲ دلار واجد شرایط میشوند
بدهکار بدهی قرارداد $۹,۶۰۰
بستانکار درآمد مبتنی بر نتیجه $۹,۶۰۰نام دقیق حسابها و زمانبندی باید با خط مشی حسابداری و تحلیل قرارداد فروشنده مطابقت داشته باشد. انضباط مهم این است که پیشپرداخت، تولید تأییدشده، صورتحساب و تسویه بانکی را به عنوان رویدادهای جداگانه قابل مشاهده نگه دارید.
دادههایی که برای بستن دفاتر نیاز دارید
درآمد مبتنی بر نتیجه را نمیتوان فقط از روی صورتگرفته بانکی بست. یک بسته شواهد ماهانه ایجاد کنید که قرارداد را به دفتر کل پیوند میدهد.
شرایط قرارداد
شرایط امضاشده، قیمت هر نتیجه، تعریف موفقیت، مدت، حقوق تمدید و انتقال، حداقلها، قوانین انقضا، مقررات برگشت، پنجرههای پذیرش و هر سطح نرخ را ذخیره کنید. اصلاحات را به عنوان نسخههای تاریخدار ثبت کنید، نه بازنویسی شرایط اصلی.
دفتر نتایج
برای هر نتیجه قابل صورتحساب، شناسه پایدار، مشتری، عامل یا گردشکار، زمان تلاش، زمان تکمیل، وضعیت موفقیت، دلیل شکست، وضعیت ارجاع انسانی، وضعیت برگشت یا اختلاف، نرخ مربوطه و ارجاع سیستم مبدأ را حفظ کنید. هدف جمعآوری تلهمتری بیشتر به خاطر خودش نیست. هدف اثبات این است که کدام رویداد قراردادی حق دریافت وجه را ایجاد کرده است.
لایههای تطبیق
به این ترتیب تطبیق دهید:
۱. گزارش رویداد عامل با گزارش استفاده یا نتایج رو به مشتری. ۲. گزارش نتایج با صورتحساب. ۳. صورتحساب با حسابهای دریافتنی. ۴. حسابهای دریافتنی و اعتبارات با تسویه بانکی. ۵. درآمد شناساییشده و بدهی قرارداد با برنامه درآمد.
تفاوتها را بررسی کنید به جای اینکه به درآمد وصل کنید. یک گردشکار ناموفق ممکن است از خروجی صورتحساب حذف شود در حالی که در گزارشهای زیرساخت باقی بماند. یک نتیجه تکراری ممکن است دو بار صورتحساب شود اما یک بار پرداخت شود. برگشت پس از صدور صورتحساب ممکن است به یادداشت بستانکار و تعدیل درآمد نیاز داشته باشد. هر تفاوت باید مالک و یادداشت حلوفصل داشته باشد.
اقتصاد واحد در کنار درآمد
شناسایی درآمد به شما میگوید چه زمانی هزینه را گزارش کنید؛ به شما نمیگوید آیا گردشکار سودآور است یا نه. هزینههای مدل و زیرساخت، هماهنگسازی، بررسی انسانی، پشتیبانی مشتری، اختلافات و دوبارهکاری را بر اساس نوع نتیجه پیگیری کنید. تحلیلهای اخیر گردشکارهای عاملمحور برجسته کردهاند که نظارت انسانی میتواند در برخی گردشکارهای پرخطر، هزینه متغیر بزرگتری نسبت به توکنهای مدل باشد. اگر قیمت شما بر اساس نتیجه موفق است، گزارش حاشیه سود شما باید از همان واحد نتیجه موفق استفاده کند.
اشتباهات رایج که باید اجتناب کنید
تلقی هر تلاش به عنوان درآمد
یک تلاش، بسته توکن، فراخوانی API یا شروع گردشکار لزوماً خدمت وعدهدادهشده نیست. اگر مشتری فقط برای نتیجه تأییدشده پرداخت میکند، تلاشها تا زمان وقوع رویداد موفقیت قراردادی، متعلق به معیارهای عملیاتی هستند.
ثبت صورتحساب به عنوان درآمد
صورتحساب بسته به حقوق و عملکرد قبلاً ارائهشده میتواند حساب دریافتنی، بدهی قرارداد یا درآمد ایجاد کند. مانده پیشپرداخت به طور خودکار درآمد کسبشده نیست. برنامههای صورتحساب و برنامههای درآمد را حتی زمانی که سیستمها یکپارچه هستند، جدا نگه دارید.
نادیده گرفتن پیادهسازی و راهاندازی
نگاشت داده، یکپارچهسازیها، پیکربندی و طراحی گردشکار ممکن است فعالیتهایی باشند که به فروشنده در انجام تعهد SaaS کمک میکنند، یا ممکن است خدمت جداگانهای را به مشتری منتقل کنند. فرض نکنید «پیادهسازی رایگان» هیچ پیامد حسابداری ندارد. مشخص کنید آیا مشتری میتواند به طور مستقل از کار بهرهمند شود و آیا کار از خدمت میزبانیشده متمایز است یا نه.
استفاده از یک نرخ موفقیت واحد برای هر گردشکار
عاملی که فاکتورها را طبقهبندی میکند، اختلافات را حل میکند و از پرداختهای تکراری جلوگیری میکند، ممکن است تعاریف متفاوتی از موفقیت، قیمتها، بار بازبینی و الگوهای برگشت داشته باشد. انواع نتایج را در جایی که قرارداد و اقتصاد جدا هستند، جدا نگه دارید. ادغام آنها میتواند یک گردشکار زیانده را پنهان کند و برآورد ملاحظات متغیر را تضعیف کند.
فراموش کردن حقوق داده مشتری
قرارداد ممکن است بگوید فروشنده میتواند از داده مشتری برای بهبود سرویس استفاده کند. حقوق واقعی مهم هستند. حقوق محدودی که فقط برای انجام خدمت قراردادی استفاده میشوند ممکن است بخشی از انجام تعهد باشند، در حالی که حقوق گستردهتر میتوانند سوالات جداگانهای درباره ملاحظات غیرنقدی، استفاده از داده، حریم خصوصی و وعدههای قراردادی ایجاد کنند. بندهای داده غیرعادی را قبل از راهاندازی به بازبینان حسابداری و حقوقی ارسال کنید.
الگوی خط مشی عملی
قبل از راهاندازی یک طرح جدید مبتنی بر نتیجه، به این سوالات در یک یادداشت حسابداری کوتاه پاسخ دهید:
- خدمت دقیق وعدهدادهشده چیست؟
- چه رویدادی انتقال موفق را اثبات میکند؟
- آیا تعهد آماده است، مقدار مشخصی از نتایج است یا ترکیبی؟
- آیا خدمات سری با الگوی انتقال یکسان هستند؟
- آیا مبلغ صورتحساب مستقیماً با ارزش منتقلشده مطابقت دارد؟
- آیا استثنای تخصیص ملاحظات متغیر قابل اعمال است؟
- اگر نه، چه تخمین و محدودیتی از قیمت تراکنش حمایت میکند؟
- آیا پیادهسازی، پشتیبانی، حقوق داده، گزینه تمدید یا حداقلها موضوعات جداگانه هستند؟
- کدام سیستم عملیاتی برای شمارش نتایج مرجع معتبر است؟
- گزارش ماهانه چگونه با صورتحسابها، حسابهای دریافتنی، بدهیهای قرارداد و وجه نقد تطبیق میشود؟
قبل از انتشار صفحه قیمتگذاری، از موافقت مالی، محصول، مهندسی، عملیات فروش و حقوقی در مورد تعاریف اطمینان حاصل کنید. قراردادی که صورتحساب آن آسان است، لزوماً قراردادی نیست که حسابداری آن آسان باشد.
مدیریت مالی خود را ساده کنید
قیمتگذاری مبتنی بر نتیجه، ثبتهای تمیز و نسخهبندیشده را به ویژه ارزشمند میکند: قرارداد، رویدادهای واجد شرایط، برنامه درآمد و فعالیت بانکی باید داستان یکسانی را روایت کنند. Beancount.io حسابداری متنساده را ارائه میدهد که شفاف، تحت کنترل نسخه و آماده هوش مصنوعی است و به تیم شما مسیر حسابرسی پایداری میدهد در حالی که مدلهای قیمتگذاری تکامل مییابند. همین حالا به صورت رایگان شروع کنید و منطق مالی را از قرارداد تا بستن دفاتر قابل مشاهده نگه دارید.