از یک مدیر مهندسی نرمافزار بپرسید یک پروژه چه زمانی «شروع» شده است، پاسخی که میگیرید شماره یک اسپرینت خواهد بود. همان سؤال را از کنترلر مالی شرکت بپرسید؛ طبق قواعد حسابداریای که از سال 1998 بر نرمافزارهای مورد استفاده داخلی حاکم بوده، پاسخ باید از یک چکلیست سختگیرانه سهمرحلهای میآمد که فرض میکند تا زمانی که الزامات نهایی نشده باشند، هیچکس کدی نمینویسد. هر کسی که در دهه گذشته نرمافزاری را عرضه کرده باشد میداند که دیگر اینطور کار نمیکند — و در سپتامبر 2025، FASB نیز سرانجام همین را پذیرفت.
بهروزرسانی استانداردهای حسابداری (ASU) 2025-06 با عنوان رسمی Intangibles—Goodwill and Other—Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software، آزمون قدیمیِ مبتنی بر مرحله را بهطور کامل کنار میگذارد و آن را با یک پرسش واحد و مبتنی بر قضاوت حرفهای جایگزین میکند: آیا احتمال دارد این نرمافزار واقعاً تکمیل شود و کاری را که قرار است انجام دهد، انجام دهد؟ برای هر شرکتی که نرمافزار را درونسازمانی توسعه میدهد — و بهویژه برای تیمهای اجایلی که قاعده قدیمی هرگز برای آنها طراحی نشده بود — این تغییر مشخص میکند هزینههای توسعه چه زمانی و به چه میزان از صورت سود و زیان به ترازنامه منتقل میشوند.
مشکل: کتاب قواعدی از سال 1998 برای توسعه آبشاری
رهنمودی که ASU 2025-06 جایگزین آن میشود، یعنی ASC 350-40 (که در ابتدا SOP 98-1 نام داشت)، زمانی نوشته شد که «توسعه نرمافزار» به معنای یک فرآیند خطی و آبشاری بود. این استاندارد هر پروژه نرمافزار مورد استفاده داخلی را به سه مرحله متوالی تقسیم میکرد:
- مرحله مقدماتی پروژه — تدوین مفهومی، ارزیابی گزینهها، انتخاب تأمینکننده. تمام هزینههای این مرحله در همان زمان وقوع بهعنوان هزینه شناسایی میشوند.
- مرحله توسعه اپلیکیشن — کدنویسی، پیکربندی و آزمایش واقعی. هزینههای این مرحله سرمایهای میشوند.
- مرحله پس از پیادهسازی — آموزش و نگهداری. دوباره بهعنوان هزینه شناسایی میشود.
این چارچوب زمانی خوب کار میکند که یک تیم سه ماه صرف نوشتن سند الزامات کند، تأییدیه بگیرد و سپس ساخت را آغاز کند. اما به محض اینکه تیمی اسپرینتهای دوهفتهای اجرا میکند، نسخههای افزایشی عرضه میکند و در هر جلسه بازنگری (رترو) دامنه کار را اصلاح میکند، این چارچوب از هم میپاشد. در محیط اجایل، «مرحله مقدماتی» و «توسعه اپلیکیشن» فازهای متوالی نیستند — بلکه در هم تنیدهاند، گاهی حتی در یک اسپرینت واحد. شرکتها و حسابرسانشان سالها بر سر اینکه یک اسپرینت دوهفتهای مشخص واقعاً به کدام مرحله تعلق دارد بحث کردهاند، و پاسخ صادقانه اغلب این بود: «ترکیبی از هر دو، داریم حدس میزنیم.» بررسیهای خود FASB نشان داد که ذینفعان بهطور مداوم این موضوع را یکی از دشوارترین بخشهای عملیاتیِ GAAP برای اجرای یکدست معرفی میکنند.
راهحل: یک آزمون، نه سه مرحله
ASU 2025-06 هرگونه ارجاع به مراحل قدیمی پروژه را حذف میکند. به جای آن، یک آستانه شناسایی واحد به نام «احتمال تکمیل» تعیین میکند. طبق رهنمود جدید، یک شرکت زمانی هزینههای نرمافزار مورد استفاده داخلی را سرمایهای میکند که هر دوی شرایط زیر بهطور همزمان برقرار باشند:
- مدیریت پروژه را مجاز شمرده و به تأمین مالی آن متعهد شده است. این مفهوم جدیدی نیست — در رهنمود قدیمی نیز وجود داشت — اما اکنون بهعنوان یکی از تنها دو شرط دروازهای نقش پررنگتری ایفا میکند، به جای اینکه در میان تحلیل مرحلهای گم شود.
- محتمل است که پروژه تکمیل شود و نرمافزار برای انجام کارکرد مورد نظرش مورد استفاده قرار گیرد. این بخش واقعاً تازه است و همان جایی است که قضاوت حرفهای نقشآفرینی میکند.
معیار دوم مستلزم ارزیابی این است که آیا عدم قطعیت قابلتوجه در توسعه همچنان وجود دارد یا خیر. FASB به دو منبع اصلی این عدم قطعیت اشاره میکند:
- فناوری اثباتنشده یا عملکرد نوآورانهای که امکانپذیری آن هنوز از طریق کدنویسی و آزمایش واقعی نشان داده نشده است — نه یک سند طراحی، نه یک اسپک، بلکه اثبات عملی و کارکرد واقعی.
- الزامات عملکردی نامشخص یا همچنان در حال تغییر — استاندارد اینها را اینگونه تعریف میکند: «آنچه یک واحد تجاری از نرمافزار میخواهد انجام دهد، برای مثال توابع یا ویژگیها.» اگر تیم هنوز بهطور جدی درباره اینکه محصول باید چه کاری انجام دهد بحث میکند، آن عدم قطعیت هنوز برطرف نشده است.
در عمل، این به این معناست که زمانبندی سرمایهایسازی اکنون بر اساس شواهد امکانپذیری تعیین میشود، نه فاز تقویمی. تیمی که یک ویژگی از نظر فنی نوآورانه را طی دو اسپرینت بهصورت اکتشافی (spike) بررسی میکند پیش از آنکه متعهد به ساخت جدی آن شود، هزینههای آن اسپرینتهای اکتشافی را بهعنوان هزینه شناسایی خواهد کرد — چرا که عدم قطعیت درباره اینکه اصلاً امکان ساخت آن وجود دارد یا نه، هنوز برطرف نشده است. به محض اینکه اسپایک امکانپذیری را اثبات کند و مدیریت بودجه ساخت کامل را متعهد شود، آستانه «احتمال تکمیل» برآورده میشود و هزینههای توسعه پس از آن، صرفنظر از تشریفات اجایل، سرمایهای میشوند.
چرا FASB میگوید سرمایهایسازی چندان تغییر نمیکند — بهجز برای SaaS
انتظار خود FASB این است که برای اکثر نرمافزارهای مورد استفاده داخلیِ درونسازمانی (on-premises) یا مبتنی بر مجوز (license-based)، این اصلاحیهها نتایج سرمایهایسازی را بهطور چشمگیری تغییر نخواهند داد — شرکتها از قبل نیز به محض شروع کدنویسی واقعی، هزینهها را سرمایهای میکردند، و آزمون جدید تقریباً به همان نتیجه میرسد، فقط بدون تمرین برچسبگذاری مرحلهای.
نرمافزاری که برای ارائه از طریق SaaS یا در قالب یک قرارداد ابری توسعه مییابد، داستان متفاوتی دارد. FASB بهصراحت انتظار دارد سرمایهایسازی برای این پروژهها کاهش یابد. دلیل آن این است: محصولات SaaS، بهطور ذاتی، بهصورت پیوسته ساخته و بازسازی میشوند، در حالی که عدم قطعیت فنی و محصولی قابلتوجهی تا اعماق جدول زمانی توسعه باقی میماند — گاهی درست تا نزدیک شدن یک ویژگی به زمان انتشار. طبق آزمون احتمال تکمیل، این عدم قطعیت مداوم به این معناست که بسیاری از هزینههای توسعه SaaS تا مراحل بسیار دیرتری از ساخت، نسبت به آنچه مدل مرحلهای قدیمی نشان میداد، از آستانه سرمایهایسازی عبور نخواهند کرد. نتیجه خالص این است: بخش بزرگتری از حقوق و دستمزد مهندسی برای یک محصول SaaS بهعنوان هزینه تحقیق و توسعه دوره جاری ثبت میشود، نه یک دارایی مستهلکشونده چندساله. این یک تغییر معنادار در EBITDA گزارششده و پایه دارایی هر شرکت SaaS است، حتی پیش از آنکه حتی یک خط از کد واقعی تغییر کند.
یک مثال عینی: دو تیم، دو نتیجه
فرض کنید یک شرکت SaaS با 40 نفر پرسنل تصمیم میگیرد یک ماژول پیشبینی مبتنی بر هوش مصنوعی برای محصول خود بسازد. در ادامه میبینیم قواعد قدیمی و جدید چگونه یک پروژه هشتماهه یکسان را متفاوت در نظر میگیرند.
تحت مدل مرحلهای قدیمی، تیم مالی تلاش میکرد یک خط مرزی ترسیم کند: شش هفته اول جمعآوری الزامات و ارزیابی تأمینکننده «مقدماتی» (هزینه) بود، و هر آنچه پس از جلسه آغازین (kickoff) اتفاق میافتاد «توسعه اپلیکیشن» (سرمایهای) محسوب میشد — حتی با وجود اینکه تیم مهندسی دو ماه بعدی را صرف اجرای اسپرینتهای اکتشافی کرد تا مشخص کند آیا رویکرد پیشبینی انتخابی آنها میتواند در حجم دادههای محیط تولید به دقت قابلقبولی برسد یا نه. طبق متن دقیق قاعده قدیمی، به محض اینکه «مرحله» تغییر میکرد، آن اسپرینتهای اکتشافی نیز اغلب سرمایهای میشدند، چون از نظر فنی پس از جلسه آغازین رخ داده بودند.
تحت ASU 2025-06، تیم مالی در عوض این سؤال را میپرسد: چه زمانی محتمل شد که این ویژگی تکمیل شود و آنگونه که مورد نظر است کار کند؟ اگر رویکرد دقت در دو ماه اول همچنان اثباتنشده بود — تیم در حال آزمایش سه رویکرد مدلسازی متفاوت بود و نمیدانست کدامیک از آستانه عبور میکند — کل آن دوره اکتشاف، صرفنظر از اینکه در تقویم به کدام «مرحله» تعلق داشت، بهعنوان هزینه شناسایی میشود. سرمایهایسازی تنها زمانی آغاز میشود که تیم یک رویکرد اعتبارسنجیشده را انتخاب کند و مدیریت بودجه ساخت کامل آن را متعهد شود، که در این مثال ممکن است ماه سوم باشد، نه ماه دوم. نتیجه: دارایی سرمایهای کوچکتر، هزینه تحقیق و توسعه دوره جاری بزرگتر، و — نکته مهم — عددی که مدیر ارشد مالی (CFO) واقعاً میتواند در یک ممیزی از آن دفاع کند، چون به یک نقطه تصمیم مشخص و مستندشده گره خورده است، نه یک برچسب مرحلهای که پس از واقعه اعمال شده باشد.
این دقیقاً همان تغییری است که FASB در سراسر بخش SaaS انتظار دارد: کمتر «آن را توسعه اپلیکیشن نامیدیم چون بعد از تماس آغازین بود» و بیشتر «میتوانیم دقیقاً اسپرینتی را نشان دهیم که ریسک فنی در آن برطرف شد.»
تاریخهای اجرا و دوره گذار
ASU 2025-06 برای همه واحدهای تجاری — سهامی عام و خصوصی — برای دورههای گزارشگری سالانهای که پس از 15 دسامبر 2027 آغاز میشوند و همچنین دورههای میاندورهای درون آن سالها، لازمالاجراست. اجرای زودهنگام برای هر واحد تجاری، در هر دوره میاندورهای یا سالانه، به محض صدور استاندارد مجاز است.
واحدهای تجاری میتوانند اصلاحیهها را با استفاده از یکی از سه رویکرد گذار اعمال کنند: بهصورت آتینگر فقط برای هزینههای نرمافزار جدیدی که پس از تاریخ اجرا رخ میدهند، بهصورت آتینگر برای هزینههایی که در یا پس از آغاز سال پذیرش رخ میدهند، یا بهصورت گذشتهنگر برای تمام دورههای ارائهشده. این انعطافپذیری اهمیت دارد — شرکتی که در میانه بازنویسی یک پلتفرم اصلی است، در زمان اجرایی شدن این قاعده مجبور نیست سالها تاریخچه هزینههای سرمایهایشده را باز کند، مگر اینکه گزینه گذشتهنگر را انتخاب کند.
اکنون شرکتهای نرمافزاری کوچک و متوسط چه باید بکنند
دسامبر 2027 دور به نظر میرسد، اما آمادهسازی عملی یک کار مربوط به سهماهه آخر نیست، بهویژه برای شرکتهایی که با تیمهای مالی کوچک و بدون واحد اختصاصی حسابداری فنی فعالیت میکنند.
مستندسازی قضاوت حرفهای «احتمال تکمیل» را همین حالا و بهصورت آنی آغاز کنید، نه پس از واقعه. مدل مرحلهای قدیمی مکانیکی بود — میشد ماهها بعد از روی تاریخهای اسپرینت بازسازی کرد که پروژه در کدام مرحله بوده است. آزمون جدید این سؤال را میپرسد که چه زمانی عدم قطعیت فنی ما پایان یافت، که یک قضاوت حرفهای است و بازسازی آن پس از واقعه بسیار دشوارتر است. همین حالا یک عادت سبک ایجاد کنید: زمانی که رهبری مهندسی و تیم مالی توافق میکنند یک ویژگی از مرحله اکتشاف فنی عبور کرده و برای ساخت متعهد شده است، آن تاریخ را ثبت کنید. این ثبت، تاریخ شروع سرمایهایسازی شما و مستندات پشتیبان ممیزی شما خواهد شد.
اگر هنوز این کار را نکردهاید، کار «اکتشاف» را از کار «ساخت متعهدشده» در سیستم ردیابی زمان یا کدهای پروژه خود جدا کنید. چه این کار با یک پرچم epic در Jira باشد، چه یک کد مرکز هزینه جداگانه، یا صرفاً یک برچسب در ابزار ردیابی زمان شما، داشتن یک ردپای داده تمیز برای اینکه چه زمانی یک ویژگی از اسپایک/نمونه اولیه به توسعه متعهدشده منتقل شده است، اعمال استاندارد جدید را بهمراتب کمدردسرتر از تلاش برای بازسازی آن از حافظه در جریان یک ممیزی خواهد کرد.
پیش از انتخاب یکی از گزینههای گذار، هر دو را مدلسازی کنید. اگر شرکت شما تحت چارچوب مرحلهای قدیمی بهطور تهاجمی هزینههای توسعه SaaS را سرمایهای کرده است، اعمال گذشتهنگر میتواند منجر به یک کاهش ارزش یکباره در داراییهای سرمایهایشده قبلی شود، زیرا آن هزینهها گویی از ابتدا هزینه شناسایی شده بودند، طبقهبندی مجدد میشوند. رویکرد آتینگر از آن تجدید ارائه صورتهای مالی جلوگیری میکند، اما به این معناست که صورت سود و زیان شما تا شروع پروژههای جدید پس از پذیرش، روش جدید را منعکس نخواهد کرد. پیش از آنکه کمیته ممیزی شما مجبور به این کار شود، اعداد را تحت هر دو گزینه محاسبه کنید.
زودتر با حسابرس خود صحبت کنید، بهویژه اگر یک شرکت SaaS هستید. با توجه به انتظار خود FASB مبنی بر کاهش سرمایهایسازی برای توسعه SaaS، حسابرسان احتمالاً قضاوتهای «احتمال تکمیل» را با دقت بیشتری نسبت به طبقهبندیهای مرحلهای تحت قاعده قدیمی بررسی خواهند کرد — دقیقاً به این دلیل که ذهنیتر (subjective) است. شرکتی که با یک چارچوب مستند و همزمان با رویداد برای اتخاذ این تصمیم وارد ممیزی سال 2028 خود شود، گفتوگویی بسیار سادهتر از شرکتی خواهد داشت که آن را پس از واقعه بازسازی میکند.
دفاتر تمیز، دفاع از قضاوتهای حرفهای را آسانتر میکنند
هر قضاوت حسابداری — و «احتمال تکمیل» دقیقاً یک قضاوت حرفهای است — تنها به اندازه مدارک پشتیبان آن قابل دفاع است. اگر جدول حسابهای شما از قبل هزینههای تحقیق و توسعه را بر اساس پروژه تفکیک کرده باشد، و ثبتهای دفتر کل شما نسخهبندیشده و قابل ممیزی باشند نه پراکنده در صفحاتگسترده جدا از هم، اعمال استانداردی مانند ASU 2025-06 به یک موضوع برچسبگذاری دادههای موجود تبدیل میشود، نه بازسازی تاریخچه از رشتههای پیام Slack. حسابداری متنساده Beancount.io بهصورت پیشفرض چنین دفتر کلی شفاف و نسخهبندیشده با git در اختیار شما میگذارد — هر ثبت قابل ردیابی، هر تغییر قابل بازبینی، بدون وابستگی به یک تأمینکننده خاص. رایگان شروع کنید و دفاتری بسازید که چه سؤال از سوی یک حسابرس بیاید، چه یک خریدار، یا چه بهروزرسانی بعدی FASB، همچنان معتبر بمانند.