تازه ۱۸۰,۰۰۰ دلار برای ساخت نرم‌افزار سفارشی کسب‌وکارتان خرج کرده‌اید. برنامه‌نویس شما آن را سرمایه‌گذاری می‌نامد. حسابدارتان آن را هزینه می‌نامد. مشاور مالیاتی‌تان می‌گوید پاسخ «هر دو، در اظهارنامه‌های متفاوت» است. هر سه می‌توانند همزمان درست باشند — و انتخاب شیوه‌ی نادرست می‌تواند سود شما را تا شش رقم بیش‌نمایی کند، موجب تعدیل در حسابرسی شود، یا به‌طور خاموش پیمان وام را نقض کند.
تصمیم سرمایه‌ای‌کردن در مقابل هزینه‌کردن یکی از پرریسک‌ترین قضاوت‌های حسابداری در کسب‌وکارهای کوچک است. هزینه‌ای را سرمایه‌ای کنید و به‌عنوان دارایی روی ترازنامه می‌نشیند، سپس در طول چند سال به‌صورت استهلاک به صورت سود و زیان سرازیر می‌شود. آن را هزینه کنید و کل مبلغ بی‌درنگ بر سود امسال اثر می‌گذارد. همان خروج نقدینگی، اما صورت‌های مالی کاملاً متفاوت.
این راهنما قواعد حاکم بر هزینه‌های توسعه نرم‌افزار، اشتراک‌های SaaS و زیرساخت ابری را بررسی می‌کند — ASC 350-40، ASC 985-20 و راهنمای رایانش ابری — و همچنین جاهایی که قوانین مالیاتی از دفاتر شما فاصله می‌گیرند.
چرا این تصمیم تا این اندازه بر اعداد شما اثر می‌گذارد
سرمایه‌ای‌کردن، شناسایی هزینه را به آینده می‌اندازد. هزینه‌کردن، آن را همین حالا شناسایی می‌کند. این تفاوت زمانی در همه‌چیزهایی که خواننده‌ی صورت‌های مالی شما به آن اهمیت می‌دهد موج می‌اندازد:
- سود و EBITDA. سرمایه‌ای‌کردن ۱۸۰,۰۰۰ دلار هزینه‌ی توسعه به‌جای هزینه‌کردن آن، ۱۸۰,۰۰۰ دلار به سود پیش از مالیات امسال می‌افزاید (منهای یک هزینه‌ی استهلاک کوچک سال اول). EBITDA تقریباً به اندازه‌ی کل مبلغ بالا می‌رود، چون استهلاک به آن بازگردانده می‌شود.
- پیمان‌های وام. بسیاری از قراردادهای اعتباری کسب‌وکارهای کوچک نسبت‌های حداقلی پوشش بدهی یا سودآوری را تعیین می‌کنند. سرمایه‌ای‌کردن تهاجمی می‌تواند وام‌گیرنده‌ی در تنگنا را منطبق با شرایط نشان دهد — تا زمانی که بازبینی بانک آن را کشف کند.
- ارزش‌گذاری. خریداران و سرمایه‌گذاران سود را برای نرم‌افزار سرمایه‌ای‌شده تعدیل می‌کنند. رویه‌های ناهمگون در جریان بررسی‌های لازم، تخفیف در قیمت خرید را دعوت می‌کنند.
- مالیات. دفاتر شما و اظهارنامه‌ی مالیاتی‌تان در اینجا از دو مجموعه‌قواعد متفاوت پیروی می‌کنند. شکاف میان آن‌ها دارایی‌ها و بدهی‌های مالیاتی معوقی ایجاد می‌کند که باید پیگیری کنید، و اشتباه در سمت مالیات به جریمه‌ی کم‌پرداختی می‌انجامد.
هیچ‌یک از این‌ها دلیلی برای ترس از این تصمیم نیست. دلیلی است برای اینکه آن را آگاهانه بگیرید، مستند کنید و به‌طور یکدست اعمال کنید.
سه مسیر حسابداری برای هزینه‌های نرم‌افزار
اصول پذیرفته‌شده‌ی حسابداری آمریکا (GAAP) یک قاعده‌ی واحد برای نرم‌افزار ندارد. سه قاعده دارد، و نخستین گام تشخیص این است که هزینه‌ی شما در کدام مسیر قرار می‌گیرد.
مسیر ۱: نرم‌افزار استفاده‌ی داخلی (ASC 350-40)
نرم‌افزاری که برای اداره‌ی کسبوکار خودتان می‌سازید یا می‌خرید — یک داشبورد داخلی، سیستم سفارش‌گیری سفارشی، اسکریپت‌های خودکارسازی، یک پورتال کارکنان — مشمول ASC 350-40 است. این همان مسیری است که بیشتر کسب‌وکارهای کوچک در آن قرار می‌گیرند. حتی نرم‌افزاری که به‌عنوان سرویس میزبانی‌شده (SaaS) به مشتریان می‌فروشید، عموماً به‌عنوان نرم‌افزار استفاده‌ی داخلی حساب می‌شود، چون مشتری هرگز مالکیت کد را به دست نمی‌آورد.
ASC 350-40 هر پروژه را به سه مرحله تقسیم می‌کند، و مرحله تعیین‌کننده‌ی شیوه‌ی برخورد است:
مرحله ۱ — مرحله‌ی مقدماتی پروژه: همه‌چیز هزینه می‌شود. ارزیابی فروشندگان، مقایسه‌ی گزینه‌های ساخت در مقابل خرید، انتخاب فناوری و کارهای امکان‌سنجی همه در زمان تحمل هزینه می‌شوند. اگر ۱۵,۰۰۰ دلار به مشاوری بپردازید تا پروژه را تعریف کند و یک بستر را توصیه کند، آن ۱۵,۰۰۰ دلار هزینه است، تمام.
مرحله ۲ — مرحله‌ی توسعه‌ی برنامه: هزینه‌های واجد شرایط سرمایه‌ای می‌شوند. پس از پایان مرحله‌ی مقدماتی، زمانی که مدیریت متعهد به تأمین مالی پروژه شده و تکمیل آن محتمل است، سرمایه‌ای‌کردن آغاز می‌شود. هزینه‌های قابل سرمایه‌ای‌کردن شامل این موارد است:
- حقوق و هزینه‌های مرتبط با حقوق کارکنانی که مستقیماً روی پروژه کار می‌کنند (به نسبت زمان صرف‌شده)
- کارمزد پرداختی به توسعه‌دهندگان و پیمانکاران بیرونی برای طراحی، کدنویسی، پیکربندی و آزمون
- هزینه‌ی نرم‌افزارهایی که به‌طور خاص برای پروژه خریداری می‌شوند
- هزینه‌های تبدیل داده، زمانی که تبدیل توسط نرم‌افزار توسعه‌یافته برای این منظور انجام شود
- هزینه‌های بهره‌ی تحمل‌شده در طول توسعه‌ی نرم‌افزار، در صورت بااهمیت بودن
هزینه‌های آموزش همیشه هزینه می‌شوند، حتی اگر در طول این مرحله تحمل شوند. سربازان عمومی اداری و هزینه‌هایی که نمی‌توان آن‌ها را به‌شکلی معقول به پروژه نسبت داد نیز همین‌طور.
مرحله ۳ — پس از پیاده‌سازی و بهره‌برداری: دوباره همه‌چیز هزینه می‌شود. آموزش، نگهداری، رفع اشکالات جزئی و پشتیبانی مستمر پس از راه‌اندازی نرم‌افزار هزینه می‌شوند. استثنا: ارتقا یا بهبودی که قابلیت جدیدی می‌افزاید می‌تواند سرمایه‌ای‌کردن را برای آن کار جدید از سر بگیرد، با پیروی از همان تحلیل سه‌مرحله‌ای.
نرم‌افزار استفاده‌ی داخلی سرمایه‌ای‌شده در طول عمر مفیدش مستهلک می‌شود — معمولاً سه تا پنج سال برای بیشتر برنامه‌های کسبوکار — و این کار از زمانی آغاز می‌شود که نرم‌افزار برای استفاده‌ی موردنظر آماده باشد.
مسیر ۲: نرم‌افزار برای فروش، اجاره یا بازاریابی (ASC 985-20)
اگر نرم‌افزاری می‌سازید که به‌عنوان محصول می‌فروشید — یک اپلیکیشن قابل دانلود، نرم‌افزار دارای مجوز در محل، یک بازی — در این صورت ASC 985-20 اعمال می‌شود. اینجا خط تقسیم یک نقطه‌عیب واحد است: امکان‌پذیری فناورانه. همه‌ی هزینه‌های پیش از این نقطه تحقیق و توسعه‌اند و در زمان تحمل هزینه می‌شوند. هزینه‌های پس از امکان‌پذیری اما پیش از عرضه‌ی عمومی سرمایه‌ای می‌شوند. نگهداری پس از عرضه هزینه می‌شود.
در عمل، بسیاری از تیم‌های چابک خیلی دیر به امکان‌پذیری فناورانه می‌رسند — گاهی با یک مدل کارآمد که چند روز پیش از عرضه پدیدار می‌شود — بنابراین چیز زیادی برای سرمایه‌ای‌کردن باقی نمی‌ماند. این یک نتیجه‌ی مشروع است، نه ناکامی در سرمایه‌ای‌کردن. فشردن هزینه‌ها به‌زور درون یک دارایی، وقتی امکان‌پذیری هرگز به‌روشنی احراز نشده، یکی از رایج‌ترین عوامل بازنگری صورت‌های مالی در شرکت‌های نرم‌افزاری است.
مسیر ۳: ترتیبات رایانش ابری (ASU 2018-15)
معاملات ابری دو گونه‌اند، و حسابداری حول یک پرسش می‌چرخد: آیا قرارداد شامل مجوز نرم‌افزار است، یا صرفاً یک خدمت است؟
- ترتیب شامل مجوز است (می‌توانستید نرم‌افزار را تصاحب کنید و خودتان اجرا کنید): مجوز را به‌عنوان نرم‌افزار استفاده‌ی داخلی طبق ASC 350-40 حساب کنید، و هزینه‌های مرتبط را طبق الگوی سه‌مرحله‌ای هزینه یا سرمایه‌ای کنید.
- قرارداد خدمت محض (ترتیبات معمول SaaS، میزبانی و زیرساخت): هزینه‌های اشتراک و مصرف هزینه‌های عملیاتی‌اند. اما هزینه‌های پیاده‌سازی — پیکربندی، سفارشی‌سازی، کار یکپارچه‌سازی، انتقال داده — به‌صورت قیاسی طبق ASC 350-40 ارزیابی می‌شوند. کار پیاده‌سازی در مرحله‌ی توسعه‌ی برنامه سرمایه‌ای می‌شود و در طول دوره‌ی میزبانی (شامل تمدیدهای نسبتاً مطمئن) مستهلک می‌شود. ارزیابی مرحله‌ی مقدماتی و پشتیبانی پس از پیاده‌سازی هزینه می‌شوند.
این موضوع بسیاری از کسب‌وکارها را در هر دو جهت غافلگیر می‌کند. برخی ۶۰,۰۰۰ دلار پیاده‌سازی ERP را هزینه می‌کنند در حالی که قواعد می‌گویند باید سرمایه‌ای شود. برخی دیگر سه سال هزینه‌ی اشتراک SaaS را سرمایه‌ای می‌کنند که آشکارا هزینه‌های عملیاتی‌اند. کارمزدها تقریباً هرگز دارایی نیستند؛ اما کار یک‌باره‌ی راه‌اندازی سیستم اغلب دارایی است.
تکلیف اشتراک‌ها و قبوض زیرساخت ابری چه می‌شود؟
چارچوب بالا را بر اقلام یک فاکتور فناوری معمولی اعمال کنید:
| هزینه | شیوه‌ی معمول | چرا |
|---|---|---|
| اشتراک ماهانه‌ی SaaS (بدون مجوز) | هزینه | قرارداد خدمت؛ شما بابت دسترسی می‌پردازید، نه یک دارایی |
| هزینه‌های مصرف AWS، Azure یا میزبانی | هزینه | مصرف خدمت به‌صورت پرداخت به‌ازای مصرف |
| پیاده‌سازی و پیکربندی ERP یا SaaS | اغلب سرمایه‌ای می‌شود | کار مرحله‌ی توسعه‌ی برنامه طبق ASU 2018-15 |
| یکپارچه‌سازی‌های سفارشی و اتصال‌دهنده‌های API که می‌سازید | اغلب سرمایه‌ای می‌شود | توسعه‌ی نرم‌افزار استفاده‌ی داخلی |
| اسکریپت‌نویسی انتقال داده | اگر نرم‌افزارمحور باشد سرمایه‌ای می‌شود | قاعده‌ی تبدیل داده‌ی ASC 350-40 |
| آموزش کارکنان روی سیستم جدید | هزینه | آموزش همیشه هزینه می‌شود |
| برنامه‌های پشتیبانی و نگهداری مستمر | هزینه | مرحله‌ی پس از پیاده‌سازی |
| ماژول جدیدی که یک سال بعد قابلیت می‌افزاید | کار جدید سرمایه‌ای می‌شود | بهبود، تحلیل مرحله‌ای را از سر می‌گیرد |
دو منطقه‌ی خاکستری نیازمند دقت بیشتری‌اند. نخست، پیکربندی در مقابل سفارشی‌سازی: تغییر تنظیمات در پنل مدیریت SaaS به‌ندرت قابل سرمایه‌ای‌کردن است، در حالی که نوشتن کد سفارشی یا اسکریپت‌های یکپارچه‌سازی پیچیده معمولاً چنین است. مستند کنید کدام ساعت‌ها کدام بوده‌اند. دوم، دوره‌ی میزبانی برای استهلاک: هزینه‌های پیاده‌سازی سرمایه‌ای‌شده را در طول دوره‌ای مستهلک کنید که انتظار دارید از خدمت استفاده کنید، شامل تمدیدهایی که نسبتاً مطمئن به انجامشان هستید — نه در طول یک عمر نرم‌افزاری نظری.
به‌روزرسانی ۲۰۲۵ که مراحل را تغییر می‌دهد
در سپتامبر ۲۰۲۵، FASB استاندارد ASU 2025-06 را منتشر کرد که برچسب‌های سه‌مرحله‌ای برای نرم‌افزار استفاده‌ی داخلی را کنار می‌گذارد و به‌جای آن یک آستانه‌ی واحد می‌نشاند: هزینه‌ها را زمانی سرمایه‌ای کنید که مدیریت متعهد به تأمین مالی پروژه شده و تکمیل آن محتمل است. این به‌روزرسانی برای دوره‌های سالانه‌ای که پس از ۱۵ دسامبر ۲۰۲۷ آغاز می‌شوند اجباری است، و پذیرش زودهنگام مجاز است.
برای بیشتر کسب‌وکارهای کوچک، اثر عملی اندک است — خط تقسیم تقریباً همان‌جا می‌افتد که امروز مرز مقدماتی در مقابل توسعه قرار دارد — اما استاندارد جدید نشان می‌دهد که هزینه‌های توسعه‌ی چابک‌تر و تکرارشونده‌ی بیشتری واجد شرایط خواهند بود. اگر تیم شما به‌صورت اسپرینتی و نه فازهای آبشاری می‌سازد، با حسابدار رسمی خود درباره‌ی پذیرش زودهنگام صحبت کنید. تا آن زمان، همچنان الگوی سه‌مرحله‌ای را اعمال کنید و مستندات مرحله‌ای را که حسابرس‌تان انتظار دارد نگه دارید.
اظهارنامه‌ی مالیاتی شما با قواعد متفاوتی بازی می‌کند
اینجا جایی است که صاحبان کسبوکار می‌سوزند: شیوه‌ی GAAP در دفاتر شما و شیوه‌ی مالیاتی در اظهارنامه‌ی شما توسط دو مجموعه‌قواعد کاملاً جدا اداره می‌شوند و اغلب با هم اختلاف دارند.
برای سال‌های مالیاتی آغازشده پس از ۳۱ دسامبر ۲۰۲۱، قانون کاهش مالیات و مشاغل، کسب‌وکارها را ملزم کرد هزینه‌های تحقیق و آزمایش داخلی — که صراحتاً شامل توسعه‌ی نرم‌افزار می‌شود — را سرمایه‌ای کنند و آن‌ها را در طول پنج سال مستهلک کنند (پانزده سال برای تحقیق خارجی). این، «۲۰۰,۰۰۰ دلار برای توسعه‌دهندگان خرج کردیم» را از یک کسر جاری به یک کسر ۲۰,۰۰۰ دلاری سال اول تبدیل کرد و باقی در طول پنج سال تراوش می‌شود.
قانون «یک لایحه‌ی بزرگ و زیبا»، که در ۲۰۲۵ امضا شد، هزینه‌کردن فوری هزینه‌های تحقیق و آزمایش داخلی را بازگرداند، با اثر قهقرایی برای سال‌های مالیاتی آغازشده در ۲۰۲۵، و روشن کرد که توسعه‌ی نرم‌افزار به حساب می‌آید. کسب‌وکارهای کوچک عموماً گزینه‌های انتقالی برای مانده‌های مستهلک‌نشده‌ی ۲۰۲۲ تا ۲۰۲۴ دارند — شتاب بخشیدن به باقی‌مانده یا ادامه‌ی استهلاک آن. هزینه‌های تحقیق خارجی همچنان در برنامه‌ی پانزده‌ساله باقی می‌مانند.
پیامدهای عملی:
- شما تفاوت‌های دفتری-مالیاتی خواهید داشت. GAAP ممکن است سرمایه‌ای‌کردن هزینه‌های پیاده‌سازی را الزامی کند که اظهارنامه‌ی مالیاتی‌تان بی‌درنگ هزینه می‌کند، یا برعکس. هر دو شیوه را کنار هم پیگیری کنید؛ ذخیره‌ی مالیاتی و برنامه‌ی M-1 شما به آن وابسته است.
- هماهنگی ایالتی متفاوت است. هر ایالتی تبعیت از بازگردانی فدرال را دنبال نمی‌کند، بنابراین هزینه‌ای که فدرال هزینه شده ممکن است برای اهداف ایالتی همچنان مستهلک شود.
- مستندسازی به دو ارباب خدمت می‌کند. ردیابی زمان بر اساس مرحله‌ی پروژه همزمان از تحلیل مرحله‌ای GAAP شما و ادعای اعتبار تحقیقاتی ماده ۴۱ شما پشتیبانی می‌کند. یک سیستم خوب هر دو را تغذیه می‌کند.
قانون مالیات آن‌قدر سریع حرکت می‌کند که هر راهنمایی مثل این یکی، یک عکس لحظه‌ای است. قواعد سال جاری را پیش از تسلیم با مشاور خود تأیید کنید — و هرگز نگذارید دم مالیات سگ GAAP را بتکانَد. صورت‌های مالی شما باید صرف‌نظر از آنچه اظهارنامه‌ی مالیاتی انجام می‌دهد، از GAAP پیروی کنند.
پنج اشتباهی که موجب تعدیل می‌شوند
- سرمایه‌ای‌کردن مرحله‌ی ارزیابی. نمایش‌های فروشندگان، درخواست‌های پیشنهاد (RFP) و مشاوره‌ی «بسازیم یا بخریم» هزینه‌های مرحله‌ی مقدماتی‌اند. هزینه‌کردن آن‌ها اختیاری نیست.
- سرمایه‌ای‌کردن آموزش. هر استانداردی صریح است: آموزش هزینه می‌شود، حتی در طول توسعه‌ی برنامه. آن را از فاکتورهای پیاده‌سازی جدا کنید.
- فراموش‌کردن توقف. سرمایه‌ای‌کردن زمانی پایان می‌یابد که نرم‌افزار برای استفاده‌ی موردنظر آماده باشد — نه وقتی آخرین فاکتور می‌رسد. ساعت‌های پیمانکار پس از راه‌اندازی تا زمانی که بهبود واقعی آغاز نشود، نگهداری‌اند.
- سرمایه‌ای‌کردن هزینه‌های اشتراک. یک قرارداد SaaS پیش‌پرداخت سه‌ساله، هزینه‌ی پیش‌پرداخت‌شده‌ای است که با مصرف خدمت مستهلک می‌شود، نه یک دارایی نرم‌افزاری. آن را از ASC 350-40 عبور ندهید.
- نبود سوابق زمانی. حقوق سرمایه‌ای‌شده بدون ردیابی زمانی همزمان بر اساس پروژه و مرحله، نخستین چیزی است که حسابرس یا بازرس رد می‌کند. تخمین‌های بازسازی‌شده در پایان سال به‌ندرت از موشکافی جان سالم به‌در می‌برند.
یک چک‌لیست عملی سرمایه‌ای‌کردن
پیش از اینکه هر هزینه‌ی نرم‌افزاری را به‌عنوان دارایی ثبت کنید، به این پرسش‌ها کتباً پاسخ دهید و یادداشت را با سوابق پروژه بایگانی کنید:
- کدام مسیر اعمال می‌شود — استفاده‌ی داخلی (350-40)، نرم‌افزار برای فروش (985-20)، یا قرارداد خدمت ابری؟
- آیا مرحله‌ی مقدماتی پایان یافته — آیا تأمین مالی متعهد شده و تکمیل محتمل است؟
- آیا نرم‌افزار اساساً کامل و آماده‌ی استفاده است؟ اگر بله، سرمایه‌ای‌کردن پایان یافته است.
- آیا این هزینه آموزش، نگهداری، ورود داده یا سرباز عمومی است؟ اگر بله، آن را هزینه کنید.
- آیا می‌توانید هر دلار سرمایه‌ای‌شده را به یک برگه‌ی زمان، فاکتور یا صورت‌کار پیمانکار نسبت دهید؟
- کدام دوره‌ی استهلاک، عمر مفید موردانتظار (یا دوره‌ی میزبانی برای هزینه‌های پیاده‌سازی) را بازتاب می‌دهد؟
- آیا شیوه‌ی مالیاتی را به‌طور جداگانه ثبت کرده‌اید، شامل هر تفاوت دفتری-مالیاتی؟
نوشتن یادداشتی کوتاه که به این هفت پرسش پاسخ دهد بیست دقیقه وقت می‌گیرد و می‌تواند هفته‌ها بحث با حسابرس، بازرس بانک یا سازمان امور مالیاتی را صرفه‌جویی کند.
هزینه‌های نرم‌افزاری خود را آماده‌ی حسابرسی نگه دارید
هر فاکتوری از توسعه‌دهندگان، فروشندگان SaaS و ارائه‌دهنده‌ی ابری شما، یک تصمیم طبقه‌بندی است که در انتظار وقوع است. کسب‌وکارهایی که این کار را درست انجام می‌دهند یک عادت مشترک دارند: هزینه‌های نرم‌افزار را بر اساس پروژه و مرحله در همان زمان که پول خارج می‌شود پیگیری می‌کنند، نه وقتی که حسابدار رسمی دوازده ماه بعد می‌پرسد. ساعت‌های پیاده‌سازی را از ساعت‌های پشتیبانی جدا برچسب بزنید، آموزش را از صورت‌کار فروشندگان جدا کنید، و یادداشتی جاری از مرحله‌ی هر پروژه نگه دارید.
سوابق پاکیزه، تفکیک دفتری-مالیاتی را نیز قابل مدیریت می‌کند. وقتی دفتر کل شما از قبل توسعه‌ی سرمایه‌ای‌شده را از اشتراک‌های هزینه‌شده جدا می‌کند، آماده‌سازی اظهارنامه — و دفاع از آن — به کشیدن یک گزارش تبدیل می‌شود، نه بازسازی یک سال.
Beancount.io حسابداری متن‌ساده را در اختیار شما می‌گذارد که هر یک از این طبقه‌بندی‌ها را شفاف، نسخه‌بندی‌شده و آماده‌ی هوش مصنوعی نگه می‌دارد — تا سیاست سرمایه‌ای‌کردن شما در دفاترتان زندگی کند، نه در صفحه‌گسترده‌ای که هیچ‌کس نمی‌تواند پیدا کند. رایگان شروع کنید و ببینید چرا توسعه‌دهندگان و متخصصان مالی به حسابداری متن‌ساده روی می‌آورند.
