سرمایه‌گذاری هزینه‌های نرم‌افزار تحت استاندارد ASC 350-40: راهنمای عملی برای تصمیم‌گیری بین ثبت به عنوان دارایی یا هزینه

یک نظرسنجی گارتنر در سال ۲۰۲۴ نشان داد که ۶۳٪ از بنیان‌گذاران مراحل اولیه SaaS، هزینه‌های توسعه نرم‌افزار را به اشتباه طبقه‌بندی می‌کنند. این اشتباه از دو جهت برای آن‌ها هزینه دارد: سرمایه‌گذاران زمانی که طبقه‌بندی‌ها نامنظم به نظر می‌رسد، ارزش صورت‌های مالی آن‌ها را کمتر برآورد می‌کنند و حسابرسان در طول فرآیند راستی‌آزمایی (due diligence) این موضوع را علامت‌گذاری می‌کنند که می‌تواند راندهای جذب سرمایه یا فرآیندهای فروش را ماه‌ها به تأخیر بیندازد.

سرمایه‌گذاری هزینه‌های نرم‌افزار صرفاً یک بحث فنی حسابداری نیست؛ بلکه مستقیماً بر EBITDA (سود قبل از بهره، مالیات، استهلاک و افت ارزش)، ترازنامه و دیدگاه وام‌دهندگان، سرمایه‌گذاران و خریداران نسبت به کسب‌وکار شما تأثیر می‌گذارد. قوانین تحت استاندارد ASC 350-40 — و به‌روزرسانی مهم سال ۲۰۲۵ — تعیین می‌کنند که کدام هزینه‌ها بلافافاصله در صورت سود و زیان ثبت شوند و کدام هزینه‌ها در طول چندین سال سرشکن گردند.

این راهنما آنچه را که استاندارد می‌طلبد، اصلاحات اخیر ASU 2025-06، هزینه‌هایی که می‌توانید سرمایه‌گذاری کنید، هزینه‌هایی که نمی‌توانید و پیامدهای درست انجام دادن آن در صورت‌های مالی را بررسی می‌کند.

آنچه ASC 350-40 پوشش می‌دهد

استاندارد ASC 350-40، استاندارد FASB برای نرم‌افزارهای مورد استفاده داخلی است — نرم‌افزاری که شرکت شما برای عملیات خود می‌سازد یا می‌خرد، نه برای اینکه آن را به عنوان محصول اصلی به مشتریان بفروشد. مثال‌ها عبارتند از:

• سیستم‌های داخلی CRM، ERP، منابع انسانی (HR) یا حسابداری
• ابزارهای زیرساخت ابری و پلتفرم‌های DevOps
• یک پلتفرم SaaS که برای مشتریان اجرا می‌کنید (مشتری به آن به عنوان یک سرویس دسترسی دارد، نه به عنوان نرم‌افزار دارای مجوزی که نصب می‌کند)
• خطوط لوله داده‌های داخلی (Data pipelines)، داشبوردها و ابزارهای تحلیلی
• خودکارسازی جریان کار سفارشی یا بخش بک‌آفیس

اگر نرم‌افزار دارای مجوزی می‌فروشید که مشتریان روی دستگاه‌های خود نصب می‌کنند، آن نرم‌افزار تحت استاندارد ASC 985-20 (نرم‌افزار برای فروش خارجی) قرار می‌گیرد که قوانین متفاوتی دارد. اکثر شرکت‌های مدرن SaaS تحت ASC 350-40 قرار می‌گیرند زیرا مشتریان نرم‌افزار را به عنوان یک سرویس میزبانی شده مصرف می‌کنند.

سوال اصلی که این استاندارد به آن پاسخ می‌دهد این است: وقتی پولی را صرف ساخت نرم‌افزار می‌کنید، آیا آن هزینه باید بلافاصله به عنوان هزینه ثبت شود یا به عنوان یک دارایی نامشهود سرمایه‌گذاری شده و در دوره‌های آتی مستهلک شود؟

مدل قدیمی سه مرحله‌ای (پیش از ASU 2025-06)

برای دهه‌ها، ASC 350-40 از یک چارچوب مبتنی بر مرحله استفاده می‌کرد. طبق دستورالعمل‌های قدیمی که هنوز برای اکثر گزارش‌دهندگان تا سال ۲۰۲۷ معتبر است، توسعه نرم‌افزار به سه فاز مجزا تقسیم می‌شود.

مرحله ۱: مرحله مقدماتی پروژه

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

فعالیت‌های این مرحله شامل:

• تدوین مفهومی و طراحی گزینه‌های جایگزین
• مشاهده دموهای فروشندگان و ارزیابی‌های فناوری
• تحلیل‌های هزینه-فایده و مطالعات امکان‌سنجی
• انتخاب نهایی یک رویکرد یا فروشنده

مرحله ۲: مرحله توسعه اپلیکیشن

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

هزینه‌های قابل سرمایه‌گذاری در این مرحله معمولاً شامل:

• حقوق و مزایای توسعه‌دهندگان، مهندسان تضمین کیفیت (QA) و مدیران پروژه (فقط زمانی که مستقیماً به کدنویسی، تست و پیکربندی نرم‌افزار اختصاص یافته است)
• هزینه‌های مشاوره خارجی برای کارهای توسعه
• مجوزهای نرم‌افزاری و ابزارهای مورد استفاده برای ساخت اپلیکیشن
• هزینه‌های مستقیم مواد و خدماتی که در توسعه مصرف شده‌اند
• هزینه‌های بهره (در موارد محدود)

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

مرحله ۳: مرحله پس از اجرا

پس از شروع به کار (Go-live)، هزینه‌های جاری دوباره به عنوان هزینه ثبت می‌شوند. آموزش، نگهداری، رفع باگ‌ها و پشتیبانی معمول همگی هزینه هستند. استثنا: بهبودهایی که عملکردهای جدیدی اضافه می‌کنند (نه فقط رفع ایراد یا نگهداری عملکردهای موجود) می‌توانند با استفاده از همان معیارهای مرحله ۲ سرمایه‌گذاری شوند.

به‌روزرسانی بزرگ ۲۰۲۵: ASU 2025-06

در ۱۸ سپتامبر ۲۰۲۵، FASB استاندارد ASU 2025-06 را صادر کرد که ASC 350-40 را به میزان قابل توجهی مدرن می‌کند. این به‌روزرسانی برای دوره‌های سالانه که پس از ۱۵ دسامبر ۲۰۲۷ شروع می‌شوند الزامی است و پذیرش زودهنگام آن مجاز است.

این تغییر ساختاری است: مدل سه مرحله‌ای حذف شده است. FASB صراحتاً تمام ارجاعات به مراحل پروژه را حذف کرد زیرا چارچوب قدیمی با روش‌های توسعه چابک (Agile) و تکرارشونده مدرن، که در آن‌ها نیازمندی‌ها تکامل می‌یابند و "مراحل" همپوشانی دارند یا به صورت موازی اجرا می‌شوند، همخوانی نداشت.

آستانه جدید مبتنی بر اصول

طبق استاندارد اصلاح‌شده، شما هزینه‌های نرم‌افزار را تنها زمانی سرمایه‌گذاری می‌کنید که هر دو شرط زیر برقرار باشد:

۱. تأیید مدیریت: مدیریت پروژه را تأیید کرده و به تأمین بودجه آن متعهد شده است. ۲. آستانه احتمال تکمیل: محتمل باشد که پروژه تکمیل شود و نرم‌افزار عملکرد مورد نظر خود را انجام دهد.

شرط دوم بسیار تعیین‌کننده است. FASB مفهومی به نام عدم قطعیت قابل توجه در توسعه را برای ارزیابی احتمال تکمیل معرفی کرده است. شما باید ارزیابی کنید:

• آیا نرم‌افزار شامل ویژگی‌های بدیع یا اثبات‌نشده‌ای است که هنوز از طریق کدنویسی یا تست تأیید نشده‌اند
• آیا نیازمندی‌های عملکردی هنوز نامشخص هستند یا در معرض بازنگری اساسی قرار دارند

اگر عدم قطعیت قابل توجهی وجود داشته باشد، سرمایه‌گذاری باید تا زمان رفع عدم قطعیت به تعویق بیفتد. FASB سیگنال داده است که انتظار دارد قانون جدید منجر به هزینه شدنِ بیشترِ مخارج نرم‌افزاری شود، به ویژه در شرکت‌های SaaS که نیازمندی‌ها به طور مداوم تکرار می‌شوند.

این در عمل چه معنایی دارد

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

چه مواردی را می‌توانید سرمایه‌ای کنید و چه مواردی را نه: یک چک‌لیست کاربردی

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

مخارجی که عموماً قابل سرمایه‌ای شدن هستند

• هزینه‌های مستقیم دستمزد برای توسعه‌دهندگان، طراحان و تیم تضمین کیفیت (QA) در طول مرحله ساخت
• مالیات بر حقوق و مزایای تخصیص‌یافته برای این کارکنان
• هزینه‌های مشاوره خارجی و پیمانکاران برای کارهای توسعه
• هزینه‌های نرم‌افزار، ابزارها و زیرساخت‌های ابری که مستقیماً در توسعه مصرف می‌شوند
• هزینه‌های توسعه قابلیت‌های جدید پس از راه‌اندازی (بهبودهایی که توانمندی‌ها را به طور مادی گسترش می‌دهند)
• هزینه‌های توسعه نرم‌افزار تبدیل (نرم‌افزاری که داده‌های قدیمی را به جدید منتقل می‌کند)، در مقابل خودِ فعالیت تبدیل داده‌ها

مخارجی که عموماً به عنوان هزینه شناسایی می‌شوند

• تحقیقات مقدماتی، انتخاب تامین‌کننده و تحلیل امکان‌سنجی
• آموزش کارکنان در مورد سیستم جدید
• پاکسازی داده‌ها، مغایرت‌گیری و انتقال سوابق
• نگهداری روتین، رفع باگ و بازنگری‌های جزئی کد (Refactoring)
• هزینه‌های نرم‌افزاری متحمل شده در دوره‌هایی که عدم قطعیت قابل‌توجهی در توسعه وجود دارد
• هزینه‌های عمومی و اداری که مستقیماً به توسعه مرتبط نیستند
• فعالیت‌های بازاریابی، پشتیبانی و موفقیت مشتری پس از راه‌اندازی

مشکل ردیابی زمان

بزرگترین چالش عملی، تخصیص زمان مهندسی است. بعید است یک مهندس ارشد که ۴۰ ساعت در هفته وقت می‌گذارد، ۱۰۰٪ کار قابل سرمایه‌ای شدن انجام دهد — آن‌ها همچنین در حال رفع اشکال در محیط عملیاتی، راهنمایی هم‌تیمی‌ها، شرکت در جلسات روزانه (Standups) و بررسی درخواست‌های بازبینی کد (Pull Requests) برای سیستم‌های قدیمی هستند. بدون یک روش دفاع‌پذیر برای ردیابی زمان (تیکت‌های مهندسی برچسب‌گذاری شده بر اساس پروژه، نرم‌افزار ردیابی زمان یا نظرسنجی‌های تخصیص رسمی)، برآوردهای سرمایه‌ای شدن در بررسی‌های حسابرسی شکست خواهند خورد.

تأثیر بر صورت‌های مالی

سرمایه‌ای کردن در مقابل هزینه‌کردنِ همان یک دلار، صورت‌های مالی بسیار متفاوتی ایجاد می‌کند.

تأثیر بر صورت سود و زیان

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

به همین دلیل است که سرمایه‌ای کردن مخارج باعث بهبود EBITDA می‌شود. استهلاک، طبق تعریف، از EBITDA حذف می‌شود — بنابراین سرمایه‌ای کردن بیشترِ مخارج توسعه، مبالغ را از مخارج عملیاتی (که EBITDA را کاهش می‌دهد) به استهلاک (که تأثیری بر آن ندارد) منتقل می‌کند. سرمایه‌گذارانی که شاخص‌های SaaS را به دقت بررسی می‌کنند، اغلب به "EBITDA قبل از تحقیق و توسعه سرمایه‌ای شده" یا محاسبات "قانون ۴۰" با استفاده از تحقیق و توسعه نقدی نگاه می‌کنند تا متوجه این پویایی شوند.

تأثیر بر ترازنامه

نرم‌افزار سرمایه‌ای شده به عنوان یک دارایی نامشهود بلندمدت ظاهر می‌شود که اغلب با عنوان "مخارج سرمایه‌ای توسعه نرم‌افزار" یا عناوین مشابه برچسب‌گذاری می‌شود. این موضوع:

• مجموع دارایی‌ها و حقوق صاحبان سهام را افزایش می‌دهد
• بازده دارایی‌ها (ROA) را تنها در صورتی بهبود می‌بخشد که سود سریع‌تر از پایه دارایی رشد کند
• دارایی‌ای ایجاد می‌کند که در صورت رها شدن پروژه یا کاهش ارزش آن، باید از نظر کاهش ارزش (Impairment) آزمایش شود

اگر پروژه‌ای در میانه توسعه رها شود، هزینه‌هایی که قبلاً سرمایه‌ای شده‌اند باید حذف (Write-off) شوند — که منجر به ضرری ناگهانی و اغلب مادی می‌شود. این یکی از دلایلی است که استاندارد جدید ASU 2025-06 تا این حد بر آستانه "احتمال تکمیل" تأکید دارد.

تأثیر بر صورت جریان وجوه نقد

هزینه‌های توسعه سرمایه‌ای شده معمولاً در طبقه فعالیت‌های سرمایه‌گذاری (و نه عملیاتی) قرار می‌گیرند که باعث می‌شود جریان نقد عملیاتی قوی‌تر به نظر برسد. سرمایه‌گذاران باهوش هنگام مقایسه شرکت‌ها این مورد را تعدیل می‌کنند — اما رقم اصلی همچنان از این موضوع نفع می‌برد.

اشتباهات رایجی که شرکت‌ها را به دردسر می‌اندازد

حسابرسان و خریداران شرکت‌ها اشتباهات مشابهی را بارها و بارها می‌بینند.

سرمایه‌ای کردن هزینه‌های پیش از تایید

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

نبود مستندات در سطح پروژه

اگر یک نهاد نظارتی یا حسابرس بپرسد "پروژه‌هایی را که سرمایه‌ای کرده‌اید به من نشان دهید" و شما فقط بتوانید به هزینه‌های عمومی مهندسی اشاره کنید، شکست خواهید خورد. شما به سوابق پروژه به پروژه نیاز دارید: محدوده، تاریخ تایید، بودجه، وضعیت و زمان ثبت شده.

در نظر گرفتن تمام زمان مهندسی به عنوان مخارج قابل سرمایه‌ای شدن

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

تداوم سرمایه‌ای کردن پس از عرضه

به محض اینکه نرم‌افزار برای استفاده مورد نظر آماده شد، فرآیند سرمایه‌ای کردن متوقف می‌شود. رفع باگ‌ها، تنظیم عملکرد و بهبودهای جزئی پس از آن نقطه، جزو هزینه‌های عملیاتی محسوب می‌شوند. ویژگی‌های جدید با محدوده کاری مجزا می‌توانند دوره سرمایه‌ای کردن جدیدی را آغاز کنند — اما کارهای روتین پس از عرضه نمی‌توانند.

فراموش کردن تست کاهش ارزش

نرم‌افزار سرمایه‌ای شده یک دارایی است و دارایی‌ها در صورت افت ارزش باید با کاهش ارزش (Impairment) مواجه شوند. اگر محصولی را بایگانی کنید، ویژگی خاصی را متوقف کنید یا سیستم را به طور اساسی بازنویسی کنید، باید مجدداً ارزیابی کرده و احتمالاً مانده قبلی را از حساب‌ها خارج کنید (Write off).

نحوه راه‌اندازی یک فرآیند قابل دفاع

اگر تصمیم گرفتید که سرمایه‌ای کردن برای شرکت شما مناسب است، فرآیند کار به اندازه خط‌مشی (Policy) اهمیت دارد.

1. یک خط‌مشی سرمایه‌ای کردن نرم‌افزار بنویسید. مشخص کنید کدام پروژه‌ها واجد شرایط هستند، فرآیند تایید شما چگونه است، تخمین عمر مفید چقدر است و چگونه زمان را تخصیص می‌دهید. تاییدیه مدیر مالی (CFO) یا کمیته حسابرسی را دریافت کنید.

2. زمان مهندسی را در سطح پروژه رهگیری کنید. این ورودی بنیادین کار است. چه از برچسب‌های Jira استفاده کنید، چه تگ‌های سفارشی در سیستم رهگیری پروژه یا تایم‌شیت‌های رسمی، باید بتوانید دفاع کنید که «مهندس X مقدار Y٪ از زمان خود را صرف کارهای قابل سرمایه‌ای کردن در پروژه Z کرده است».

3. مستندسازی تایید مدیریت. هر پروژه قابل سرمایه‌ای کردن نیاز به شواهدی از تایید دارد — تاییدیه کتبی تاریخ‌دار، صورت‌جلسات هیئت مدیره یا منشوری از پروژه که توسط مدیریت امضا شده باشد.

4. عدم اطمینان قابل توجه را به طور منظم مجدداً ارزیابی کنید. طبق قوانین جدید، باید نظارت کنید که آیا ویژگی‌ها هنوز نوظهور یا اثبات‌نشده هستند و آیا الزامات در حال تثبیت می‌باشند یا خیر. بررسی‌های فصلی با رهبری مهندسی منطقی است.

5. جداول استهلاک را برای هر پروژه ایجاد کنید. هر پروژه سرمایه‌ای شده زمانی که آماده استفاده شد، مستهلک شدن را آغاز می‌کند و شما باید بهای تمام شده آن دارایی، استهلاک انباشته و عمر باقی‌مانده را رهگیری کنید.

6. در صورت تغییر پروژه‌ها، تست کاهش ارزش انجام دهید. هر زمان که کاری را که سرمایه‌ای شده رها کردید، به طور اساسی بازنویسی کردید یا متوقف نمودید، تحلیل کاهش ارزش را اجرا کرده و در صورت نیاز کاهش ارزش را در دفاتر ثبت کنید.

چرا این موضوع برای دفترداری اهمیت دارد

سرمایه‌ای کردن نرم‌افزار یکی از آن حوزه‌هایی است که نظم و انضباط دفترداری از روز اول، سال‌ها بعد نتیجه می‌دهد. سرمایه‌گذاران در طول جذب سرمایه سری B، تراز آزمایشی شما را بررسی می‌کنند؛ خریداران در فرآیند فروش، تراکنش‌ها را تا اسناد روزنامه ردیابی می‌کنند؛ اداره مالیات ممکن است نحوه برخورد GAAP شما را با نحوه برخورد مالیاتی تحقیق و توسعه (R&D) تحت بخش ۱۷۴ مقایسه کند که قوانین خاص خود را دارد. اگر دفاتر شما پروژه‌های سرمایه‌ای را از هزینه‌های عملیاتی جدا نکنند، نتوانند هزینه‌های زمانی مهندسی را به پروژه‌های خاص مرتبط کنند یا جداول استهلاک منظمی نداشته باشند، هر چرخه حسابرسی و بررسی دقیق (Diligence) دردناک خواهد بود.

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

حسابداری نرم‌افزار خود را آماده حسابرسی نگه دارید

چه در حال سرمایه‌ای کردن اولین پلتفرم داخلی خود باشید و چه در حال اجرای جداول استهلاک برای ده‌ها پروژه، سوابق مالی شفاف سنگ بنای کار است. Beancount.io حسابداری متن-ساده (Plain-text accounting) را ارائه می‌دهد که به شما دفاتری شفاف و دارای کنترل نسخه (Version-controlled) می‌دهد — هر ثبت قابل ردیابی، هر حساب قابل حسابرسی و هر گزارش قابل بازتولید است. برای شرکت‌های نرم‌افزاری که توسعه‌های سرمایه‌ای شده را در پروژه‌های متعدد رهگیری می‌کنند، داشتن دفاتری که مانند کد خوانده می‌شوند، یک مزیت جدی است. رایگان شروع کنید و ببینید چرا توسعه‌دهندگان و متخصصان مالی به حسابداری متن-ساده روی می‌آورند.