ASC 350-40 — موضوع تدوینشدهای که جستجوگران اغلب آن را به صورت 350/40 تایپ میکنند — قانون FASB برای نرمافزار داخلی است: زمانی که هزینه توسعه در حال حاضر هزینه میشود در مقابل زمانی که به عنوان دارایی نامشهود سرمایهگذاری شده و بعداً مستهلک میشود. تحت مدل سهمرحلهای قدیمی (که هنوز اکثر گزارشدهندگان تا تاریخ اجباری ASU 2025-06 از آن استفاده میکنند)، پاسخ در یک جدول جا میگیرد:
| مرحله | چه اتفاقی میافتد | سرمایهگذاری یا هزینه؟ |
|---|---|---|
| پروژه مقدماتی | نیازمندیها، نمایشهای فروشنده، امکانسنجی، ساخت در مقابل خرید | هزینه طبق وقوع |
| توسعه برنامه | کدنویسی، پیکربندی، آزمایش، یکپارچهسازی پس از تعهد مدیریت | سرمایهگذاری هزینههای مستقیم ساخت |
| پس از پیادهسازی | آموزش، نگهداری، رفع اشکالات پس از راهاندازی | هزینه (عملکرد جدید میتواند سرمایهگذاری را دوباره شروع کند) |
ASU 2025-06 (صادر شده در ۱۸ سپتامبر ۲۰۲۵؛ الزامی برای دورههای سالانه آغاز شده پس از ۱۵ دسامبر ۲۰۲۷) آن برچسبهای مرحلهای را برای یک آستانه احتمال-تکمیل بازنشسته میکند و نشان میدهد که هزینههای بیشتری هزینه خواهند شد. بخشهای زیر پوشش میدهند که ASC 350-40 شامل چه چیزهایی است، جزئیات مرحله، بهروزرسانی ۲۰۲۵، چکلیست سرمایهگذاری/هزینه، و اینکه چگونه انتخاب بر EBITDA و ترازنامه تأثیر میگذارد.
ASC 350-40 چه چیزی را پوشش میدهد
ASC 350-40 استاندارد FASB برای نرمافزار داخلی است — نرمافزاری که شرکت شما برای عملیات خودش میسازد یا میخرد، نه برای فروش به مشتریان به عنوان محصول اصلی. مثالها عبارتند از:
- سیستمهای داخلی CRM، ERP، HR یا حسابداری
- ابزارهای زیرساخت ابری و پلتفرمهای DevOps
- پلتفرم SaaS که برای مشتریان اجرا میکنید (مشتری به آن به عنوان سرویس دسترسی دارد، نه به عنوان نرمافزار دارای مجوز که نصب میکنند)
- خطوط لوله داده، داشبوردها و ابزارهای تحلیل داخلی
- اتوماسیون جریان کار سفارشی یا دفتر پشتیبان
اگر نرمافزار دارای مجوزی میفروشید که مشتریان روی ماشینهای خودشان نصب میکنند، این تحت ASC 985-20 (نرمافزار برای فروش خارجی) قرار میگیرد که قوانین متفاوتی دارد. اکثر شرکتهای SaaS مدرن تحت ASC 350-40 قرار میگیرند زیرا مشتریان نرمافزار را به عنوان سرویس میزبانی شده مصرف میکنند.
سؤال اصلی که استاندارد پاسخ میدهد: وقتی برای ساخت نرمافزار پول خرج میکنید، آیا آن هزینه باید فوراً هزینه شود یا به عنوان دارایی نامشهود سرمایهگذاری شده و در دورههای آینده مستهلک شود؟
مدل سهمرحلهای قدیمی (پیش از ASU 2025-06)
برای دههها، ASC 350-40 از یک چارچوب مبتنی بر مرحله استفاده میکرد. تحت راهنمای قدیمی که هنوز برای اکثر گزارشدهندگان تا سال ۲۰۲۷ اعمال میشود، توسعه نرمافزار به سه مرحله مجزا تقسیم میشود.
مرحله ۱: مرحله پروژه مقدماتی
این مرحله اکتشافی است — تعریف نیازمندیها، ارزیابی فناوریها، دریافت نمایش از فروشندگان، و تصمیمگیری برای ساخت، خرید یا رد کردن. تمام هزینههای این مرحله طبق وقوع هزینه میشوند، مشابه هزینههای تحقیق. دلیلش: تا زمانی که مدیریت تعهد ندهد، هنوز دارایی احتمالی ندارید.
فعالیتهای اینجا شامل:
- فرمولبندی مفهومی و گزینههای طراحی
- نمایشهای فروشنده و ارزیابیهای فناوری
- تحلیلهای هزینه-فایده و مطالعات امکانسنجی
- انتخاب نهایی یک رویکرد یا فروشنده
مرحله ۲: مرحله توسعه برنامه
سرمایهگذاری زمانی آغاز میشود که مدیریت پروژه را مجاز کند، بودجه را تعهد کند و تکمیل محتمل باشد. این مرحله ساخت واقعی را پوشش میدهد — کدنویسی، آزمایش، پیکربندی، یکپارچهسازی و نصب.
هزینههای قابل سرمایهگذاری در این مرحله معمولاً شامل:
- حقوق و مزایای توسعهدهندگان، مهندسان QA و مدیران پروژه (فقط زمانی که مستقیماً به کدنویسی، آزمایش و پیکربندی نرمافزار اختصاص دارد)
- هزینههای مشاوره خارجی برای کار توسعه
- مجوزهای نرمافزاری و ابزارهای مورد استفاده برای ساخت برنامه
- هزینههای مستقیم مواد و خدمات مصرفشده در توسعه
- هزینههای بهره (در موارد محدود)
سرمایهگذاری زمانی متوقف میشود که نرمافزار به طور قابل توجهی کامل و آماده استفاده موردنظر باشد — معمولاً زمانی که آزمایش تمام شده و سیستم به تولید مستقر شده است، حتی اگر عرضه تدریجی باشد.
مرحله ۳: مرحله پس از پیادهسازی
پس از راهاندازی، هزینههای جاری به رفتار هزینه برمیگردند. آموزش، نگهداری، رفع اشکالات و پشتیبانی معمول همگی هزینه میشوند. استثنا: بهبودهایی که عملکرد جدید اضافه میکنند (نه فقط رفع یا نگهداری عملکرد موجود) میتوانند با استفاده از همان معیارهای مرحله ۲ سرمایهگذاری شوند.
بهروزرسانی بزرگ ۲۰۲۵: ASU 2025-06
در ۱۸ سپتامبر ۲۰۲۵، FASB ASU 2025-06 را صادر کرد که به طور قابل توجهی ASC 350-40 را مدرن میکند. این بهروزرسانی برای دورههای سالانه آغاز شده پس از ۱۵ دسامبر ۲۰۲۷ الزامی است و اتخاذ زودهنگام مجاز است.
تغییر ساختاری است: مدل سهمرحلهای حذف شده است. FASB به صراحت تمام ارجاعات به مراحل پروژه را حذف کرد زیرا چارچوب قدیمی با شیوههای توسعه چابک و تکراری مدرن همخوانی نداشت، جایی که نیازمندیها تکامل مییابند و "مراحل" همپوشانی دارند یا به صورت موازی اجرا میشوند.
آستانه جدید مبتنی بر اصول
تحت استاندارد تجدیدنظر شده، فقط زمانی هزینههای نرمافزار را سرمایهگذاری میکنید که هر دو این شرایط برآورده شوند:
۱. مجوز مدیریت: مدیریت پروژه را مجاز کرده و به تأمین بودجه آن تعهد داده است. ۲. آستانه احتمال-تکمیل: محتمل است که پروژه تکمیل شود و نرمافزار عملکرد موردنظر خود را انجام دهد.
آن آزمون دوم کار واقعی انجام میدهد. FASB مفهومی به نام عدم قطعیت قابل توجه توسعه معرفی کرده است تا ارزیابی کند آیا تکمیل محتمل است. شما باید ارزیابی کنید:
- آیا نرمافزار شامل ویژگیهای جدید یا اثباتنشده است که از طریق کدنویسی یا آزمایش اعتبارسنجی نشدهاند
- آیا الزامات عملکرد هنوز تعییننشده یا در معرض تجدیدنظر اساسی هستند
اگر عدم قطعیت قابل توجه وجود داشته باشد، سرمایهگذاری باید به تعویق بیفتد تا زمانی که عدم قطعیت برطرف شود. FASB نشان داده که انتظار دارد قانون جدید منجر به هزینهکردن هزینههای نرمافزاری بیشتری شود، به ویژه در شرکتهای SaaS که نیازمندیها به طور مداوم تکرار میشوند.
این در عمل چه معنایی دارد
برای یک استارتاپ که چیزی واقعاً جدید میسازد — یک پلتفرم عامل هوش مصنوعی، یک موتور اتوماسیون نوآورانه — قانون جدید ممکن است هزینههای بیشتری را زودتر به هزینههای عملیاتی سوق دهد. برای شرکتهای بالغ که سیستمهای خوب تعریفشده را بهبود میبخشند، تأثیر عملی کمتر خواهد بود. در هر صورت، حرکت از یک بررسی مکانیکی مرحله به یک آستانه مبتنی بر قضاوت به این معناست که شرکتها به مستندات واضحتری از تصمیمات مدیریت، امکانسنجی فنی و وضعیت پروژه نیاز دارند.
چه چیزی میتوانید سرمایهگذاری کنید و چه چیزی نمیتوانید: یک چکلیست عملی
چه مدل مرحلهای قدیمی را اعمال کنید یا آزمون جدید مبتنی بر اصول، مرز بین هزینههای قابل سرمایهگذاری و قابل هزینهکردن از نظر روح مشابه است. در اینجا یک چکلیست کاری است.
عموماً قابل سرمایهگذاری
- هزینههای نیروی کار مستقیم برای توسعهدهندگان، طراحان و QA در طول مرحله ساخت
- مالیاتهای حقوق و دستمزد و مزایای تخصیصیافته برای آن کارمندان
- هزینههای مشاوره و پیمانکار خارجی برای کار توسعه
- هزینههای نرمافزار، ابزار و زیرساخت ابری که مستقیماً در توسعه مصرف میشوند
- هزینههای توسعه عملکرد جدید پس از راهاندازی (بهبودهایی که قابلیتها را به طور قابل توجهی گسترش میدهند)
- هزینههای توسعه نرمافزار تبدیل (نرمافزاری که دادههای قدیمی را به جدید منتقل میکند)، در مقابل خود فعالیت تبدیل داده
عموماً هزینهشده
- تحقیق مقدماتی، انتخاب فروشنده و تحلیل امکانسنجی
- آموزش کارمندان در سیستم جدید
- پاکسازی داده، تطبیق و انتقال سوابق
- نگهداری معمول، رفع اشکالات و بازسازی جزئی
- هزینههای نرمافزاری در دورههای عدم قطعیت قابل توجه توسعه
- سربار اداری عمومی که مستقیماً به توسعه مرتبط نیست
- فعالیتهای بازاریابی، پشتیبانی و موفقیت مشتری پس از راهاندازی
مشکل ردیابی زمان
بزرگترین چالش عملی تخصیص زمان مهندسی است. یک مهندس ارشد که ۴۰ ساعت در هفته کار میکند بعید است که ۱۰۰٪ کار قابل سرمایهگذاری انجام دهد — آنها همچنین در حال رفع اشکال تولید، راهنمایی همتیمیها، شرکت در جلسات ایستاده و بررسی درخواستهای کشش برای سیستمهای قدیمی هستند. بدون یک روش ردیابی زمان قابل دفاع (تیکتهای مهندسی برچسبخورده بر اساس پروژه، نرمافزار ردیابی زمان، یا نظرسنجیهای تخصیص رسمی)، برآوردهای سرمایهگذاری در بررسی حسابرسی شکست میخورند.
تأثیر صورتهای مالی
سرمایهگذاری در مقابل هزینهکردن همان دلار، صورتهای مالی کاملاً متفاوتی تولید میکند.
تأثیر صورت سود
یک هزینه سرمایهگذاریشده در دوره صرفشده به صورت سود نمیخورد. در عوض، مستهلک میشود — معمولاً خط مستقیم در طول سه تا پنج سال برای نرمافزار داخلی. بنابراین ۱ میلیون دلار هزینه مهندسی سرمایهگذاریشده در سال ۱ ممکن است فقط ۲۰۰ تا ۳۳۳ هزار دلار هزینه استهلاک در هر سال ایجاد کند و سود عملیاتی سال ۱ را به طور قابل توجهی بالاتر بگذارد.
برای همین است که EBITDA از سرمایهگذاری تقویت میشود. استهلاک، طبق تعریف، از EBITDA حذف میشود — بنابراین سرمایهگذاری بیشتر هزینه توسعه، دلارها را از هزینه عملیاتی (که EBITDA را کاهش میدهد) به استهلاک (که این کار را نمیکند) منتقل میکند. سرمایهگذارانی که معیارهای SaaS را دقیق بررسی میکنند اغلب به "EBITDA قبل از R&D سرمایهگذاریشده" یا محاسبات قانون-۴۰ با استفاده از R&D نقدی نگاه میکنند تا این پویایی را ببینند.
تأثیر ترازنامه
نرمافزار سرمایهگذاریشده به عنوان دارایی نامشهود بلندمدت ظاهر میشود، اغلب با برچسب "هزینههای توسعه نرمافزار سرمایهگذاریشده" یا مشابه. این:
- کل داراییها و حقوق صاحبان سهام را افزایش میدهد
- بازده داراییها (ROA) را فقط اگر سود سریعتر از پایه دارایی رشد کند بهبود میبخشد
- دارایی ایجاد میکند که اگر پروژه رها شود یا ارزشش کاهش یابد باید برای کاهش ارزش آزمایش شود
اگر پروژه در وسط توسعه رها شود، هزینههای قبلاً سرمایهگذاریشده باید نوشته شوند — که زیان ناگهانی و اغلب بااهمیت تولید میکند. این یکی از دلایلی است که ASU 2025-06 جدید این همه بر آستانه احتمال-تکمیل تأکید میکند.
تأثیر صورت جریان نقدی
هزینههای توسعه سرمایهگذاریشده معمولاً به عنوان فعالیتهای سرمایهگذاری (نه عملیاتی) طبقهبندی میشوند، که جریان نقدی عملیاتی را قویتر نشان میدهد. سرمایهگذاران پیچیده هنگام مقایسه شرکتها این را تعدیل میکنند — اما عدد سرفصل همچنان سود میبرد.
اشتباهات رایج که شرکتها را به دردسر میاندازد
حسابرسان و خریداران همان خطاها را بارها و بارها میبینند.
سرمایهگذاری هزینههای پیش از مجوز
اشتباه کلاسیک سرمایهگذاری زمان مهندسی صرفشده قبل از تأیید رسمی پروژه توسط مدیریت است. بدون مجوز مستند و تعهد بودجه، آن هزینهها باید هزینه میشدند. مطمئن شوید صورتجلسات، تأییدیههای هیئت مدیره یا امضاهای کتبی دارید که مشخص میکند مدیریت چه زمانی تعهد داد.
بدون مستندات سطح پروژه
اگر یک تنظیمکننده یا حسابرس بپرسد "پروژههایی که سرمایهگذاری کردهاید را به من نشان دهید" و شما فقط میتوانید به هزینه مهندسی کلی اشاره کنید، بازنده خواهید شد. به سوابق پروژه به پروژه نیاز دارید: محدوده، تاریخ مجوز، بودجه، وضعیت و زمان شارژشده.
درمان تمام زمان مهندسی به عنوان قابل سرمایهگذاری
مهندسان ارشد اشکالات را رفع میکنند، کد را بررسی میکنند، در جلسات شرکت میکنند و به حوادث پاسخ میدهند. هیچ کدام از اینها قابل سرمایهگذاری نیست. شرکتهایی که به سادگی حقوق تیم مهندسی را در درصدی ضرب میکنند به ندرت از حسابرسی جان سالم به در میبرند.
ادامه سرمایهگذاری پس از راهاندازی
لحظهای که نرمافزار برای استفاده موردنظر آماده است، سرمایهگذاری متوقف میشود. رفع اشکالات، تنظیم عملکرد و بهبودهای جزئی پس از آن نقطه هزینههای عملیاتی هستند. ویژگیهای جدید و جداگانه میتوانند دوره سرمایهگذاری جدیدی شروع کنند — اما کار معمول پس از راهاندازی نمیتواند.
فراموش کردن آزمایش کاهش ارزش
نرمافزار سرمایهگذاریشده یک دارایی است و داراییها اگر ارزششان کاهش یابد باید کاهش ارزش شوند. اگر محصولی را به حال خود رها کنید، ویژگیای را متوقف کنید یا سیستم را اساساً بازنویسی کنید، باید دوباره ارزیابی کنید و احتمالاً موجودی قبلی را بنویسید.
چگونه یک فرآیند قابل دفاع راهاندازی کنید
اگر تصمیم میگیرید سرمایهگذاری برای شرکت شما درست است، فرآیند به اندازه سیاست مهم است.
۱. سیاست سرمایهگذاری نرمافزار بنویسید. تعریف کنید کدام پروژهها واجد شرایط هستند، فرآیند مجوز شما، برآورد عمر مفید شما و چگونه زمان را تخصیص میدهید. تأیید CFO یا کمیته حسابرسی را بگیرید.
۲. زمان مهندسی را در سطح پروژه ردیابی کنید. این ورودی بنیادی است. چه از برچسبهای Jira، برچسبهای سفارشی در ردیاب پروژه یا برگههای زمانی رسمی استفاده کنید، باید دفاع کنید که "مهندس X درصد Y از زمان خود را روی کار قابل سرمایهگذاری در پروژه Z صرف کرده است."
۳. تأیید مدیریت را مستند کنید. هر پروژه قابل سرمایهگذاری به شواهد مجوز نیاز دارد — تأییدیه کتبی تاریخدار، صورتجلسات هیئت مدیره یا منشور پروژه امضاشده توسط رهبری.
۴. عدم قطعیت قابل توجه را مرتباً بازبینی کنید. تحت قانون جدید، باید نظارت کنید که آیا ویژگیها هنوز جدید یا اثباتنشده هستند و آیا نیازمندیها در حال تثبیت هستند. بازبینیهای فصلی با رهبری مهندسی معقول است.
۵. برنامههای استهلاک به ازای هر پروژه بسازید. هر پروژه سرمایهگذاریشده زمانی که آماده استفاده است شروع به استهلاک میکند و باید پایه هزینه آن دارایی، استهلاک انباشته و عمر باقیمانده را ردیابی کنید.
۶. وقتی پروژهها تغییر میکنند برای کاهش ارزش آزمایش کنید. هر زمان که کار سرمایهگذاریشده را رها میکنید، به طور اساسی بازنویسی میکنید یا متوقف میکنید، تحلیل کاهش ارزش اجرا کنید و نوشتنها را طبق نیاز ثبت کنید.
چرا این برای دفترداری مهم است
سرمایهگذاری نرمافزار یکی از آن حوزههایی است که انضباط دفترداری روز اول سالها بعد نتیجه میدهد. سرمایهگذاران در جریان افزایش سرمایه سری B تراز آزمایشی شما را میکشند؛ خریداران در فرآیند فروش تراکنشها را به ورودیهای دفتر روزنامه ردیابی میکنند؛ IRS ممکن است رفتار GAAP شما را با رفتار مالیاتی R&D بخش ۱۷۴ مقایسه کند، که قوانین خودش را دارد. اگر کتابهای شما پروژههای سرمایهگذاریشده را از هزینههای عملیاتی جدا نکنند، نمیتوانند هزینههای زمان مهندسی را به پروژههای خاص متصل کنند، یا برنامههای استهلاک تمیز نگه ندارند، هر چرخه حسابرسی و دقتبینی دردناک میشود.
راهحل در مفهوم ساده است: ساختار حساب تمیز نگه دارید، زمان را در سطح پروژه ردیابی کنید و تصمیمات پشت هر ورودی سرمایهگذاری را مستند کنید. انجام این از ابتدا از پاکسازیهای پرهزینه بعدی جلوگیری میکند.
حسابداری نرمافزار خود را آماده حسابرسی نگه دارید
چه اولین پلتفرم داخلی را سرمایهگذاری میکنید یا برنامههای استهلاک را در دهها پروژه اجرا میکنید، سوابق مالی تمیز پایه و اساس است. Beancount.io حسابداری متن ساده ارائه میدهد که به شما کتابهای شفاف و نسخهکنترلشده میدهد — هر ورودی قابل ردیابی، هر حساب قابل حسابرسی، هر گزارش قابل تکرار. برای شرکتهای نرمافزاری که توسعه سرمایهگذاریشده را در چند پروژه ردیابی میکنند، داشتن کتابهایی که مانند کد خوانده میشوند یک مزیت جدی است. رایگان شروع کنید و ببینید چرا توسعهدهندگان و حرفهایهای مالی به حسابداری متن ساده روی میآورند.
