پرش به محتوای اصلی

خط پایه تعهدشده بهعلاوه اضافهبار: ASC 606 در واقع چگونه میخواهد درآمد SaaS مبتنی بر مصرف را شناسایی کنید

منتشر شده زمان مطالعه 12 دقیقهMike ThriftMike Thrift
خط پایه تعهدشده بهعلاوه اضافهبار: ASC 606 در واقع چگونه میخواهد درآمد SaaS مبتنی بر مصرف را شناسایی کنید
فهرست مطالب این صفحه

شما همین حالا بزرگترین معامله تاریخ کوتاه شرکتتان را بستهاید: تعهد سالانه ۱۲۰,۰۰۰ دلار، بهعلاوه ۰.۱۰ دلار برای هر فراخوان API مازاد بر سهمیه شاملشده. سیستم صورتوضعیت شما از همین حالا در حال اندازهگیری است، و حسابداری بدیهی به نظر میرسد: «درآمد را وقتی که مشتری از آن استفاده میکند شناسایی کن.» این شهود دقیقاً برای نیمی از این قرارداد درست است — و برای نیمه دیگر بهقدری نادرست که سال آینده برای حسابرس خود یک تعدیل پایان سال به ارمغان میآورد.

قیمتگذاری مبتنی بر مصرف اکنون روش پیشفرض شرکتها برای دریافت هزینه از مشتریان SaaS است، نه یک استثنای عجیب: بیش از ۵۹٪ از کسبوکارهای SaaS در سال ۲۰۲۵ ساختار مبتنی بر مصرف داشتهاند که نسبت به حدود ۴۰٪ دو سال پیش افزایش یافته است. بیشتر این قراردادها کاملاً پرداخت بهازای مصرف (pay-as-you-go) نیستند. آن‌ها ترکیبی‌اند — یک خط پایه تعهدشده که تخفیف می‌خرد، با اضافهبار اندازهگیری‌شده روی آن. تحت ASC 606، همین یک امضا به دو جریان درآمدی با قواعد زمانی متضاد تقسیم میشود. خط پایه یک برآورد ثابت است و صرف‌نظر از اینکه مشتری حتی یک فراخوان API هم استفاده کند یا نه، در طول دوره قرارداد سرشکن میشود. اضافهبار یک برآورد متغیر است و منتظر کنتور میماند. این راهنما توضیح میدهد چرا، همراه با اسناد حسابداری که این کار را پیادهسازی میکنند.

یک قرارداد، دو رویکرد درآمدی​

از ساختار شروع کنید، چون همهچیز از آن نتیجه میشود. یک قرارداد تعهد بهعلاوه اضافهبار سه جزء متحرک دارد:

  • یک حداقل تعهدشده. مشتری ۱۲۰,۰۰۰ دلار برای سال میپردازد، هر چه پیش بیاید. در عوض دسترسی به پلتفرم بهعلاوه یک سهمیه شاملشده دریافت میکند — مثلاً یک میلیون فراخوان API در ماه — با نرخی مؤثر بسیار کمتر از نرخ فهرست.
  • یک کنتور اضافهبار. مصرف بالاتر از سهمیه، با نرخ اضافهبار صورتوضعیت میشود، معمولاً ماهانه و در پایان ماه. در مثال ما، ۰.۱۰ دلار برای هر فراخوان.
  • یک امضا، یک دوره. معمولاً دوازده ماه، اغلب با صورتوضعیت پیشپرداخت یا فصلی، حتی اگر خدمت در طول سال بهتدریج ارائه شود.

ASC 606 این قرارداد را از مدل پنجمرحلهای خود میگذراند — شناسایی قرارداد، شناسایی تعهدات عملکردی، تعیین قیمت معامله، تخصیص آن، شناسایی درآمد هنگام ایفای تعهدات — و به یک حکم دوگانه میرسد. مبلغ تعهدشده ۱۲۰,۰۰۰ دلار یک قیمت معامله ثابت برای خدمتی است که بهطور مداوم در طول دوازده ماه ارائه میشود، بنابراین در طول زمان شناسایی میشود، عموماً بهصورت خط مستقیم ماهانه ۱۰,۰۰۰ دلار. اضافهبار یک برآورد متغیر است: مبلغ آن به مصرف آینده بستگی دارد، بنابراین هنگام وقوع مصرف شناسایی میشود، یا فقط در صورتی که بتوانید از یک آستانه عمداً بالا به نام محدودیت (constraint) عبور کنید، از پیش برآورد میشود. همان مشتری، همان صورتوضعیت، دو ساعت.

نتیجه عملی فوری است. در یک ماه کممصرف که مشتری تنها ۴۰۰,۰۰۰ فراخوان مصرف میکند، شما هنوز کل ۱۰,۰۰۰ دلار درآمد خط پایه را شناسایی میکنید — مشتری یک سال دسترسی خریده است، و یکدوازدهم ژانویه آن ارائه شده است. در یک ماه اوج با ۱.۵ میلیون فراخوان، شما ۱۰,۰۰۰ دلار بهعلاوه ۵۰۰,۰۰۰ فراخوان اضافهبار با نرخ ۰.۱۰ دلار، یعنی ۵۰,۰۰۰ دلار درآمد مصرفی شناسایی میکنید. خط پایه هرگز با مصرف افت نمیکند، و اضافهبار هرگز به ماههایی که هیچ اتفاقی نیفتاده هموار نمیشود.

چرا خط پایه بهصورت خط مستقیم سرشکن میشود​

منطق حسابداری برای خط پایه نیمه آرامتر داستان است. تعهد عملکردی شما «یک میلیون فراخوان API» نیست — بلکه آمادگی همیشگی برای خدمت به مشتری در تمام ماه است، مجموعه‌ای از دوره‌های خدمت روزانه یا ماهانه متمایز که ASC 606 آن‌ها را بهعنوان ایفاشده در طول زمان تلقی میکند. معیار درست پیشرفت، گذر زمان است، و سادهترین الگوی وفادار، خط مستقیم است: یکدوازدهم تعهد در هر ماه.

همه فروشندگان بزرگ مبتنی بر مصرف در این نیمه به یک نتیجه میرسند. گزارش ۱۰-K شرکت Datadog بیان میکند که برای مبلغ قراردادی تعهدشده که بهصورت نسبی تخصیص مییابد، درآمد بهصورت نسبی در طول دوره اشتراک، از زمان در دسترس قرار گرفتن پلتفرم، شناسایی میشود. شرکت Alkami که نرمافزار بانکی مبتنی بر تراکنش با حداقل‌های ماهانه میفروشد، این را حتی واضحتر میگوید: حداقل کارمزدهای تراکنش بهصورت خط مستقیم شناسایی میشوند، در حالی که کارمزد تراکنش‌های بالاتر از حداقل در ماهی که تراکنش‌ها پردازش میشوند شناسایی میشود. حداقل‌ها برای گذر زمان هستند؛ اضافهبارها برای کنتور.

یک مخالف مشهور ارزش دانستن دارد، چون حسابرس شما آن را میداند. Snowflake درآمد را هنگام مصرف محاسبه، ذخیرهسازی و انتقال توسط مشتریان شناسایی میکند — حتی تحت تعهدات ظرفیت چندساله — با این استدلال که مصرف، نه زمان، لحظه انتقال ارزش است. این موضع بهطور برجسته افشا و با حقایق خاص شرکت دفاع میشود. مگر اینکه آماده باشید آن یادداشت را بنویسید و در حسابرسی از آن دفاع کنید، خط پایه را خط مستقیم کنید. این رویکردی است که حسابرسان از یک شرکت SaaS در مرحله اولیه انتظار دارند، و انحراف از آن نیازمند یک موضع مکتوب است، نه یک شانه بالا انداختن.

چرا اضافهبارها منتظر کنتور میمانند​

اضافهبارها برآورد متغیر هستند، و ASC 606 به برآورد متغیر با بدبینی نگاه میکند. شما میتوانید آن را در قیمت معامله لحاظ کنید تنها تا حدی که محتمل باشد هنگام رفع عدم قطعیت، هیچ برگشت مهمی رخ نخواهد داد — همان محدودیت. برای مصرفی که قبلاً رخ داده و اندازهگیری شده است، هیچ عدم قطعیتی باقی نمیماند، بنابراین شناسایی درآمد اضافهبار در ماه مصرف همیشه از آستانه عبور میکند. به همین دلیل «وقتی استفاده میکنند شناسایی کن» رویکرد پیشفرضی است که بیشتر شرکتهای SaaS انتخاب میکنند، و همان چیزی که حسابرسان کمترین اعتراض را به آن دارند.

جایگزین این است که کل اضافهبار سال از پیش برآورد و بهصورت نسبی در کنار خط پایه شناسایی شود. New Relic دقیقاً همین کار را میکند: مصرف بالاتر از تعهد را از دادههای تاریخی بهعلاوه عوامل آیندهنگر پیشبینی میکند، برآورد را تا آنچه انتظار دارد محق آن باشد محدود میکند، و آن مبلغ را در طول دوره شناسایی میکند. این رویکرد منطبق با استاندارد است و درآمد هموارتری تولید میکند — اما توجه کنید چه چیزی میطلبد. شما به تاریخچه کافی برای پیشبینی معتبر، یک روش برآورد مستند، یک تحلیل محدودیت، و یک فرآیند تعدیل (true-up) هنگام انحراف واقعیات نیاز دارید. برای یک استارتاپ با شش ماه داده اندازهگیری و یک مشتری بزرگ که مصرفش هر فصل دو برابر میشود، آن پرونده هنوز وجود ندارد. اضافهبارها را هنگام وقوع شناسایی کنید تا زمانی که تاریخچهتان حق برآورد را برایتان کسب کند.

یک بخش دیگر از استاندارد بیصدا از رویکرد ساده حمایت میکند. چون اشتراک شما مجموعه‌ای از دوره‌های خدمت ماهانه متمایز است، کارمزدهای مصرفی مربوط به یک ماه مشخص میتوانند بهطور کامل به همان ماه تحت استثنای تخصیص برآورد متغیر تخصیص یابند. به زبان ساده: شما نیازی ندارید سال را پیشبینی کنید تا ژانویه را درست ثبت کنید. قرائت کنتور ژانویه متعلق به ژانویه است، تمام.

آخرین تله زمانبندی، اشتباه گرفتن صورتوضعیت با شناسایی است. اگر تعهد ۱۲۰,۰۰۰ دلاری را در ژانویه پیشپرداخت صورتوضعیت کنید، درآمد ژانویه هنوز ۱۰,۰۰۰ دلار است — ۱۱۰,۰۰۰ دلار دیگر در درآمد معوق مینشیند. برعکس، مصرف اضافهبار ارائهشده در ژانویه اما صورتوضعیت‌نشده تا دور صورتوضعیت فوریه، هنوز درآمد ژانویه است؛ در پایان ماه آن را بهعنوان درآمد صورتوضعیت‌نشده یا تعهدی ثبت میکنید. نقدینگی و صورتوضعیت‌ها رویدادهای صورتوضعیت هستند. گذر زمان و کنتور رویدادهای درآمد هستند. چکلیست بستن حساب‌های شما باید این دو را از هم جدا نگه دارد.

اسناد حسابداری، با اعداد واقعی​

این هم معامله نمونه در دفاتر. Acme در ۵ ژانویه امضا میکند: تعهد سالانه ۱۲۰,۰۰۰ دلار، یک میلیون فراخوان شاملشده در ماه، ۰.۱۰ دلار برای هر فراخوان اضافهبار. مصرف ژانویه ۱,۰۲۱,۰۰۰ فراخوان است — ۲۱,۰۰۰ فراتر از سهمیه، یعنی ۲,۱۰۰ دلار. فوریه آرام با ۸۰۰,۰۰۰ فراخوان است، پس هیچ اضافهباری وجود ندارد.

2026-01-05 * "Invoice Acme annual platform commit"
  Assets:Receivable:Acme                120000.00 USD
  Liabilities:Deferred-Revenue:Acme     -120000.00 USD
 
2026-01-31 * "January: release 1/12 of commit"
  Liabilities:Deferred-Revenue:Acme       10000.00 USD
  Income:Subscription-Revenue             -10000.00 USD
 
2026-01-31 * "January overage: 21000 calls over allowance at 0.10"
  Assets:Receivable:Acme                   2100.00 USD
  Income:Usage-Revenue                      -2100.00 USD
 
2026-02-28 * "February: release 1/12 of commit, usage under allowance"
  Liabilities:Deferred-Revenue:Acme       10000.00 USD
  Income:Subscription-Revenue             -10000.00 USD

داستانی را که دفتر کل روایت میکند بخوانید. ژانویه ۱۲,۱۰۰ دلار بر ۱۲۰,۰۰۰ دلار صورتوضعیت‌شده شناسایی میکند — تفاوت ۱۱۰,۰۰۰ دلاری درآمد معوق است، یک بدهی برای خدمت هنوز بدهکار، نه سود. فوریه یک ۱۰,۰۰۰ دلار ثابت شناسایی میکند با وجود افت مصرف به یکپنجم، چون خط پایه بهای دسترسی را میپردازد، نه فراخوان‌ها. و سند اضافهبار فقط در ماههایی وجود دارد که کنتور از سهمیه فراتر میرود. اگر حساب درآمد شما دقیقاً این شکل را نشان نمیدهد — خط پایه ثابت بهعلاوه مصرف پرنوسان — چیزی در بالادست اشتباه سیمکشی شده است.

به حساب‌های درآمد جداگانه توجه کنید. جدا کردن خط پایه اشتراک از درآمد مصرفی تزئینی نیست: این همان چیزی است که به شما اجازه میدهد نرخ حفظ درآمد خالص، نرخ اتصال مصرف، و پوشش تعهد را از دفتر کل گزارش کنید، نه از یک صفحه‌گسترده. هر دو حساب را در روز اول قرارداد راهاندازی کنید، نه در نخستین حسابرسی‌تان.

چهار اشتباه که تعدیل حسابرس را دعوت میکنند​

ثبت تعهد بهعنوان درآمد هنگام امضا. صورتوضعیت ۱۲۰,۰۰۰ دلاری شبیه یک فروش به نظر میرسد، و تیم فروش به شما خواهد گفت که در ژانویه بسته شد. اما شما یک ماه از یک خدمت دوازده‌ماهه را ارائه کرده‌اید. هر چیزی فراتر از ۱۰,۰۰۰ دلار ژانویه، درآمد معوق است. شرکتهایی که کل تعهد را از ابتدا بهعنوان درآمد ثبت میکنند نه فقط یک ماه را اشتباه گزارش میدهند — بلکه یازده ماه درآمد آینده را قرض میگیرند و آن را به شکل یک تجدید ارائه شرمآور بازمیپردازند.

هموار کردن اضافهبارهای پراکنده در ماههای آرام. میانگینگیری اضافهبار ۵۰,۰۰۰ دلاری یک ماه اوج در فصل‌های اطراف مرتب به نظر میرسد و نادرست است، مگر اینکه کل را از پیش برآورد کرده، تحلیل محدودیت را مستند کرده و تعدیل کرده باشید. بدون آن پرونده، قرائت کنتور هر ماه در ماه خودش میماند. حسابرسان این را با مقایسه درآمد مصرفی شناسایی‌شده با مصرف اندازهگیری‌شده به تفکیک دوره آزمایش میکنند؛ یک خط هموار در برابر یک کنتور پرنوسان سریعترین راه شکست در این آزمون است.

اجازه دادن به تقویم صورتوضعیت برای هدایت شناسایی. صورتوضعیت پیشپرداخت سالانه تیمها را وسوسه میکند در تاریخ‌های صورتوضعیت شناسایی کنند. صورتوضعیت‌های تعدیل فصلی آن‌ها را وسوسه میکند اضافهبارها را فقط هنگام صورتوضعیت شناسایی کنند. هر دو جهت قاعده را میشکنند: خط پایه از تقویم خدمت پیروی میکند، اضافهبار از تقویم مصرف پیروی میکند، و هیچکدام از تقویم صورتوضعیت پیروی نمیکند. تعهدی پایان ماه برای مصرف اندازهگیری‌شده اما صورتوضعیت‌نشده همان سندی است که بیشتر تیم‌های مالی جوان جا میاندازند — دفاتر را چند روز پس از پایان ماه ببندید، دقیقاً به این دلیل که کنتور تسویه شده باشد.

فراموش کردن تعهد استفاده‌نشده. اگر Acme سال را ۲ میلیون فراخوان زیر کل سهمیهاش به پایان برساند و قرارداد بگوید استفاده کن یا از دست بده، آن کسری بهطور خودکار درآمد پاداش در دسامبر نیست. مبالغ پیشپرداخت استفاده‌نشده — اصطکاک (breakage) — فقط تحت یک سیاست منضبط شناسایی میشوند: به تناسب مصرف هنگام اعمال حقوق، یا زمانی که احتمال اعمال آن دور از انتظار شود. سیاست را قبل از دسامبر بنویسید، بهطور مداوم اعمال کنید، و افشا کنید. کشف اصطکاک در طول حسابرسی همان چیزی است که اظهارنظر پاک را به تأخیر میاندازد.

چکلیست بستن پایان ماه شما برای تعهد بهعلاوه اضافهبار​

قواعد بالا را به یک بستن تکرارپذیر تبدیل کنید. هر ماه، به این ترتیب:

  1. خروجی کنتور را بکشید و آن را به موتور نرخ‌گذاری متصل کنید. مصرف نرخ‌گذاری‌شده به تفکیک مشتری باید به ورودی‌های صورتوضعیت سیستم صورتوضعیت تا سطح فراخوان تطبیق یابد. قبل از ثبت هر چیزی، شکاف‌ها را بررسی کنید — قطعی اندازه‌گیری یک مشکل کامل بودن درآمد است، نه یک تیکت IT.
  2. خط پایه را آزاد کنید. یکدوازدهم هر تعهد فعال از درآمد معوق به درآمد اشتراک. یک گزارش جریان درآمد معوق که مانده ابتدایی بهعلاوه صورتوضعیت‌های جدید منهای آزادسازی‌ها را به مانده پایانی میرساند، همان کنترلی است که حسابرسان اول از همه میخواهند؛ آن را در Fava فیلترشده به حساب‌های درآمد معوق خود مرور کنید و خطاهای شکل فوراً خودنمایی میکنند.
  3. اضافه‌بارها را از کنتور ثبت کنید، سپس دنباله صورتوضعیت‌نشده را تعهدی کنید. اضافه‌بار صورتوضعیت‌شده حساب‌های دریافتنی را بدهکار میکند؛ مصرف اندازه‌گیری‌شده پس از آخرین دور صورتوضعیت، درآمد تعهدی را بدهکار میکند. هر دو در ماه مصرف، درآمد مصرفی را بستانکار میکنند.
  4. هر برآوردی را تعدیل کنید. اگر اضافه‌بارها را بهصورت نسبی برآورد میکنید، شناسایی‌شده از ابتدای سال تاکنون را با اندازه‌گیری‌شده از ابتدای سال تاکنون مقایسه کنید و سند جبرانی را ثبت کنید. اگر هنگام وقوع شناسایی میکنید، این مرحله بهجای آن یک بررسی معقولیت پنج‌دقیقهای است — یک دلیل دیگر که استارتاپ‌ها باید از آنجا شروع کنند.
  5. پوشش تعهد را مرور کنید. برای هر مشتری، ارزش مصرف تجمعی را با خط پایه تجمعی آزادشده مقایسه کنید. مشتری‌ای که بسیار بالاتر از تعهدش مصرف میکند موضوع گفتگوی گسترش است؛ مشتری‌ای که بسیار پایین‌تر است یک ریسک تمدید و احتمالاً یک سند اصطکاک آینده است. در هر حال، مالی باید آن را قبل از فروش تشخیص دهد.

با خروجی کنتور این ماه شروع کنید: آن را با آنچه دفتر کل شما شناسایی کرده تطبیق دهید، به تفکیک خط پایه و مصرف، و تأیید کنید که دو ساعت مستقل از هم کار میکنند. اگر اینطور است، حسابداری تعهد بهعلاوه اضافهبار شما از قبل از بیشتر شرکت‌های هم‌اندازه شما جلوتر است — و حسابرسی بعدی شما کوتاه‌تر شده است.

منبع: https://beancount.io/fa/blog/2026/11/09/committed-baseline-plus-overage-asc-606-usage-based-revenue-recognition-guide

منتشر شده: ۱۸ آبان ۱۴۰۵

زمان مطالعه 11 دقیقه

شناسایی درآمد برای صورتحساب مبتنی بر مصرف در SaaS: راهنمای بنیانگذاران برای استاندارد ASC 606

طبق استاندارد ASC 606، درآمد مبتنی بر مصرف زمانی شناسایی می‌شود که مشتریان از…

revenue-recognition
saas
زمان مطالعه 12 دقیقه

مشتری صورتحساب اضافه‌مصرف API خود را مورد اعتراض قرار داد: چرا برگشت درآمد اندازه‌گیری‌شده همان صدور بازپرداخت نیست

اعتراض به اضافه‌مصرف، درآمد شناسایی‌شده را به بدهی بازپرداخت برمی‌گرداند — نه…

revenue-recognition
saas
زمان مطالعه 9 دقیقه

صورتحساب‌گیری برای توکن‌ها: راهنمای شناسایی درآمد برای SaaS مبتنی بر مصرف هوش مصنوعی

ASC 606 همچنان بر قیمت‌گذاری مبتنی بر توکن هوش مصنوعی حاکم است، اما برآورد…

revenue-recognition
saas
زمان مطالعه 11 دقیقه

SLA آپ‌تایم SaaS شما فقط یک وعده حقوقی نیست: چرا اعتبارهای قطعی تحت ASC 606 درآمد را کاهش می‌دهند

اعتبارهای قطعی SLA تحت ASC 606 ملاحظه متغیر محسوب می‌شوند — آن‌ها درآمد را کاهش…

saas
revenue-recognition
زمان مطالعه 12 دقیقه

قیمت‌گذاری مبتنی بر نتیجه برای SaaS عاملمحور: نحوه شناسایی درآمد وقتی مشتری به ازای هر نتیجه موفق پرداخت می‌کند

طبق استاندارد ASC 606، قرارداد هوش مصنوعی عاملمحور که به ازای هر نتیجه موفق…

revenue-recognition
saas