مقدمه: تمام هزینه‌های ساخت نرم‌افزار، دارایی نیستند
مدیر مالی شرکت فرضی «فناوری مالی پیشرو» در پایان پروژه اتوماسیون ثبت اسناد و کنترل مغایرت‌ها با مجموع ۳٬۶۰۰ میلیون ریال مخارج مواجه شده است. مدیریت می‌خواهد تمام مبلغ را به‌عنوان دارایی نامشهود منعکس کند، اما بررسی اسناد و تاریخ‌های پروژه نشان می‌دهد فقط مخارج مشخص توسعه که پس از احراز تمام معیارهای شناخت واقع شده‌اند، قابل سرمایه‌ای‌شدن هستند.
در سناریوی آموزشی این مقاله، ۲٬۱۰۰ میلیون ریال به نرم‌افزار ایجادشده اختصاص می‌یابد و ۱٬۵۰۰ میلیون ریال شامل تحقیق، توسعه پیش از احراز معیارها، آموزش و تبلیغات به هزینه دوره منظور می‌شود. نرم‌افزار از اول مهر ۱۴۰۵ آماده استفاده است و استهلاک شش‌ماهه آن تا پایان اسفند ۳۵۰ میلیون ریال خواهد بود. اختلاف فقط انتخاب نام حساب نیست؛ اشتباه در تفکیک هزینه و دارایی می‌تواند هم سود و هم صورت وضعیت مالی را تحریف کند.
یادداشت اعتبارسنجی: این شرکت، ارقام، تاریخ‌های پروژه، نرخ‌ها و عملکرد نرم‌افزار همگی فرضی‌اند. هیچ‌یک از قابلیت‌های فنی ذکرشده به‌عنوان امکانات موجود محصولات حسابداران برتر معرفی نمی‌شوند. تمام ارقام مالی، مگر خلاف آن ذکر شود، به «میلیون ریال» هستند. اجرای واقعی مستلزم بررسی آخرین متن لازم‌الاجرای استاندارد و مستندات پروژه است.
۱. دارایی نامشهود چیست؟
دارایی نامشهود یک دارایی غیرپولی قابل تشخیص بدون ماهیت عینی است. نرم‌افزار داخلی می‌تواند نمونه‌ای از آن باشد، به‌شرط اینکه واحد تجاری بر منافع اقتصادی دارایی کنترل داشته و ضوابط شناخت و اندازه‌گیری بهای آن احراز شود. هر هزینه فاقد شکل فیزیکی، به‌طور خودکار دارایی نامشهود نیست. تبلیغات، آموزش کاربران و تحقیق مقدماتی ممکن است برای موفقیت پروژه ضروری باشند، اما لزوماً یک منبع تحت کنترل و قابل‌شناسایی ایجاد نمی‌کنند. در قراردادهای استفاده از سامانه ابری نیز باید میان مالکیت یا کنترل کد و صرف دریافت خدمت دسترسی تفاوت گذاشت.
۲. استاندارد حسابداری شماره ۱۷ ایران
استاندارد حسابداری شماره ۱۷ «دارایی‌های نامشهود»، نسخه تجدیدنظرشده ۱۳۸۶، قواعد شناخت و اندازه‌گیری این دارایی‌ها را بیان می‌کند. بندهای ۳۸ تا ۵۳ درباره دارایی نامشهود ایجادشده در واحد تجاری‌اند. بر مبنای بند ۳۹، پروژه باید برای ارزیابی مخارج به مرحله تحقیق و مرحله توسعه تقسیم شود. بند ۴۰ می‌گوید اگر این دو مرحله تفکیک‌پذیر نباشند، مخارج پروژه برای این منظور تحقیق تلقی می‌شوند. بند ۴۱ مخارج تحقیق را هزینه دوره و بند ۴۴ سرمایه‌ای‌شدن توسعه را منوط به احراز تمامی شش معیار مقرر می‌داند. برای صدور سند اجرایی، متن معتبر جاری سازمان حسابرسی ملاک است.
۳. تفاوت مرحله تحقیق و مرحله توسعه
در تحقیق، شرکت به دنبال دانش، فناوری یا راه‌حل مناسب است؛ مانند بررسی چند معماری، مقایسه مدل‌های هوش مصنوعی و امکان‌سنجی ابزارهای مختلف. در توسعه، بر پایه راهکار انتخاب‌شده، برنامه‌نویسی، ساخت ماژول‌های مشخص، اتصال سامانه‌ها و آزمون کارکرد انجام می‌شود. بااین‌حال، ورود فنی به توسعه به‌تنهایی کافی نیست: ممکن است نمونه اولیه ساخته شده باشد ولی امکان‌پذیری تکمیل، منافع آتی یا منابع موردنیاز هنوز به‌طور مستند احراز نشده باشند. در چنین وضعیتی مخارج توسعه پیش از آن تاریخ نیز به هزینه منظور می‌شوند.
۴. شش معیار شناخت مخارج توسعه
طبق بند ۴۴ استاندارد ۱۷ و بند ۵۷ IAS 38، شرکت باید هم‌زمان نشان دهد: ۱) تکمیل فنی نرم‌افزار امکان‌پذیر است؛ ۲)قصد تکمیل و استفاده یا فروش دارد؛ ۳) توان استفاده یا فروش آن را دارد؛ ۴) منافع اقتصادی آینده، برای مثال صرفه‌جویی قابل اتکا در هزینه‌های اداری، اثبات‌پذیر است؛ ۵) منابع فنی، مالی و انسانی کافی برای تکمیل موجود است؛ و ۶) مخارج قابل انتساب در دوره توسعه به‌شکل اتکاپذیر اندازه‌گیری می‌شوند. فقدان هر معیار، مانع شناخت مخارج مربوط به‌عنوان دارایی در آن تاریخ است. صورت‌جلسه و مستندات باید تاریخ‌دار باشند؛ صرف تصویب بودجه یا عنوان «پروژه توسعه» کافی نیست.
۵. سناریوی عددی: توسعه نرم‌افزار اتوماسیون مالی
شرکت «فناوری مالی پیشرو» برای دریافت اطلاعات معاملات، پیشنهاد ثبت سند، کنترل مغایرت و گزارش مدیریتی یک نرم‌افزار داخلی می‌سازد. فرض می‌کنیم کنترل کد و منافع اقتصادی آن را در اختیار دارد، نرم‌افزار مستقل از خدمات تأمین‌کننده است و هیچ دارایی جداگانه دیگری با هزینه‌های پروژه خریداری نشده است. تحقیق در فروردین و اردیبهشت، نمونه‌سازی در خرداد، احراز کامل معیارها در اول تیر، توسعه واجد شرایط از تیر تا شهریور و آمادگی برای استفاده در اول مهر ۱۴۰۵ رخ می‌دهد. عمر مفید سه سال، ارزش باقیمانده صفر و روش استهلاک خط مستقیم است؛ مالیات، کاهش ارزش و هزینه تأمین مالی در مثال لحاظ نشده‌اند.
| مشخصه | فرض سناریو |
|---|---|
| تاریخ شروع پروژه | ۱ فروردین ۱۴۰۵ |
| تاریخ احراز شش معیار | ۱ تیر ۱۴۰۵ |
| تاریخ آماده‌شدن برای استفاده | ۱ مهر ۱۴۰۵ |
| عمر مفید نرم‌افزار | ۳ سال |
| روش استهلاک | خط مستقیم |
| ارزش باقیمانده | صفر |
۶. جدول کامل مخارج پروژه
| نوع مخارج | دوره وقوع | مبلغ | برخورد حسابداری |
|---|---|---|---|
| تحقیق و انتخاب راهکار | فروردین و اردیبهشت | ۸۰۰ | هزینه |
| توسعه آزمایشی پیش از احراز معیارها | خرداد | ۴۰۰ | هزینه |
| برنامه‌نویسی مستقیم واجد شرایط | تیر تا شهریور | ۱٬۲۰۰ | دارایی |
| زیرساخت پردازشی مستقیم توسعه | تیر تا شهریور | ۳۵۰ | دارایی، طبق مفروضات |
| ابزار و مجوز مستقیماً مصرف‌شده در توسعه | تیر تا شهریور | ۲۵۰ | دارایی، طبق مفروضات |
| آزمون فنی و امنیتی ضروری پیش از آمادگی | تیر تا شهریور | ۳۰۰ | دارایی |
| آموزش کاربران | مهر | ۱۸۰ | هزینه |
| معرفی و تبلیغات | مهر | ۱۲۰ | هزینه |
| جمع | — | ۳٬۶۰۰ | ۲٬۱۰۰ دارایی + ۱٬۵۰۰ هزینه |
۷. مرحله تحقیق؛ ۸۰۰ میلیون ریال هزینه
هزینه ۸۰۰ مربوط به بررسی فناوری‌ها و انتخاب راه‌حل است. مخارج تحقیق بر اساس استاندارد ۱۷ در زمان وقوع هزینه می‌شوند، حتی اگر نتیجه پژوهش بعداً به نرم‌افزار موفقی منتهی شود. ثبت نمونه: بدهکار «هزینه تحقیق و بررسی نرم‌افزار» ۸۰۰ و بستانکار «بانک» ۸۰۰. خروج وجه نقد واقع شده، اما معیارهای شناخت دارایی هنوز برقرار نیستند.
| حساب | بدهکار | بستانکار |
|---|---|---|
| هزینه تحقیق و بررسی نرم‌افزار | ۸۰۰ | — |
| بانک | — | ۸۰۰ |
۸. توسعه آزمایشی پیش از احراز معیارها؛ ۴۰۰ میلیون ریال
در خرداد نسخه اولیه برای آزمون معماری ساخته می‌شود. فرض می‌کنیم شرکت هنوز نتوانسته امکان‌پذیری فنی نهایی و منافع اقتصادی آتی را با مدارک کافی اثبات کند. بنابراین، ۴۰۰ به هزینه منظور می‌شود: بدهکار «هزینه توسعه فاقد شرایط شناخت» و بستانکار بانک. جمع هزینه تا پایان خرداد ۱٬۲۰۰ = ۸۰۰ + ۴۰۰ است و حتی پس از راه‌اندازی موفق، صرفاً به دلیل موفقیت پروژه به دارایی انتقال نمی‌یابد.
| حساب | بدهکار | بستانکار |
|---|---|---|
| هزینه توسعه قبل از احراز معیارها | ۴۰۰ | — |
| بانک | — | ۴۰۰ |
۹. چرا تاریخ اول تیر اهمیت دارد؟
در اول تیر ۱۴۰۵ کمیته فنی و مالی فرضاً گزارش امکان‌پذیری، مصوبه تکمیل، حقوق کنترل کد، برآورد منافع آتی، تأمین منابع و نظام هزینه‌یابی را تأیید می‌کند. از این تاریخ همه شش معیار بند ۴۴ برقرارند و مخارج جدید واجد شرایط می‌توانند سرمایه‌ای شوند. تاریخ سرمایه‌ای‌کردن نباید به خواست مدیرعامل به ابتدای پروژه برگردانده شود. سند تصویب، آزمون‌های فنی، برنامه مالی و کاربرگ ثبت ساعات باید کنار پرونده حسابداری نگهداری شود.
۱۰. محاسبه مخارج قابل سرمایه‌ای‌شدن
بعد از اول تیر، برنامه‌نویسی مستقیم ۱٬۲۰۰، ظرفیت پردازشی مستقیم ۳۵۰، ابزار و مجوز مصرف‌شده در توسعه ۲۵۰ و آزمون‌های لازم پیش از آماده‌شدن ۳۰۰ ثبت شده‌اند. فرض می‌کنیم تمام این مخارج ضروری، مستند، مستقیم، مربوط به نرم‌افزار تحت کنترل شرکت و پیش از آماده‌شدن برای استفاده واقع شده‌اند؛ به‌ویژه مبلغ پردازشی نباید با هزینه عملیات جاری سرویس SaaS اشتباه شود. جمع بهای تمام‌شده: ۱٬۲۰۰ + ۳۵۰ + ۲۵۰ + ۳۰۰ = ۲٬۱۰۰.
۱۱. ثبت مخارج توسعه واجد شرایط
تا آماده‌شدن محصول، از حساب «دارایی نامشهود در جریان ایجاد» استفاده می‌شود. سند تجمیعی: بدهکار «دارایی نامشهود در جریان ایجاد ـ نرم‌افزار مالی» ۲٬۱۰۰ و بستانکار «بانک» ۲٬۱۰۰. در عمل، هر پرداخت باید با فاکتور، کارکرد کارکنان و پروژه مشخص ثبت شود و ممکن است حساب بستانکار «حقوق پرداختنی» یا «حساب‌های پرداختنی» باشد. ثبت تجمیعی آموزشی جایگزین مدارک تفصیلی نیست.
| حساب | بدهکار | بستانکار |
|---|---|---|
| دارایی نامشهود در جریان ایجاد | ۲٬۱۰۰ | — |
| بانک | — | ۲٬۱۰۰ |
۱۲. چرا آموزش کارکنان دارایی نیست؟
آموزش کاربری و گزارش‌گیری نرم‌افزار در مهر ۱۸۰ هزینه دارد. این مخارج برای بهره‌برداری نیروی انسانی است، نه آماده‌کردن خود نرم‌افزار به‌عنوان یک دارایی نامشهود. طبق بند ۵۳ استاندارد ۱۷، مخارج آموزش کارکنان جهت استفاده عملیاتی در بهای دارایی وارد نمی‌شود. ثبت: بدهکار «هزینه آموزش کارکنان» ۱۸۰ و بستانکار بانک ۱۸۰.
| حساب | بدهکار | بستانکار |
|---|---|---|
| هزینه آموزش کارکنان | ۱۸۰ | — |
| بانک | — | ۱۸۰ |
۱۳. چرا معرفی و تبلیغات هزینه است؟
مبلغ ۱۲۰ بابت اطلاع‌رسانی، معرفی و تبلیغات داخلی یا سازمانی پس از پایان توسعه پرداخت شده است. این مخارج قابلیت عملکردی جدیدی به کد ایجاد نمی‌کند و طبق مفروضات، مستقیم و ضروری برای رساندن دارایی به وضعیت آماده‌استفاده نیست. ثبت: بدهکار «هزینه تبلیغات و معرفی» ۱۲۰ و بستانکار بانک ۱۲۰. در یک پرونده واقعی باید ماهیت هر مخارج را بررسی کرد؛ صرف نام حساب نباید جایگزین شواهد شود.
| حساب | بدهکار | بستانکار |
|---|---|---|
| هزینه معرفی و تبلیغات | ۱۲۰ | — |
| بانک | — | ۱۲۰ |
۱۴. جدول نهایی تفکیک مخارج
| گروه هزینه | کل مبلغ | بخش دارایی | بخش هزینه دوره |
|---|---|---|---|
| تحقیق | ۸۰۰ | — | ۸۰۰ |
| توسعه قبل از احراز معیارها | ۴۰۰ | — | ۴۰۰ |
| برنامه‌نویسی واجد شرایط | ۱٬۲۰۰ | ۱٬۲۰۰ | — |
| پردازش مستقیم توسعه | ۳۵۰ | ۳۵۰ | — |
| مجوز و ابزار توسعه | ۲۵۰ | ۲۵۰ | — |
| آزمون‌های ضروری | ۳۰۰ | ۳۰۰ | — |
| آموزش | ۱۸۰ | — | ۱۸۰ |
| تبلیغات | ۱۲۰ | — | ۱۲۰ |
| جمع | ۳٬۶۰۰ | ۲٬۱۰۰ | ۱٬۵۰۰ |
کنترل ریاضی: ۲٬۱۰۰ + ۱٬۵۰۰ = ۳٬۶۰۰. هیچ مخارجی حذف نشده؛ تنها مبنای گزارشگری آن‌ها متفاوت است.
۱۵. آیا مخارج گذشته بعداً قابل سرمایه‌ای‌شدن است؟
موفقیت پروژه در مهر، مخارج تحقیق ۸۰۰ و نمونه‌سازی قبل از احراز معیارها ۴۰۰ را به دارایی تبدیل نمی‌کند. بند ۵۱ استاندارد ۱۷بهای دارایی داخلی را به مخارج از تاریخ نخستین احراز معیارها محدود می‌کند و بند ۵۷ از افزودن مخارجی که پیش‌تر به‌درستی هزینه شده‌اند جلوگیری می‌کند. اگر واقعاً اشتباه ثبت قبلی کشف شود، بحث اصلاح اشتباه بر اساس استاندارد مربوط مطرح است؛ نه مجوز آزادانه سرمایه‌ای‌کردن هزینه‌های گذشته.
۱۶. انتقال دارایی در جریان ایجاد به نرم‌افزار آماده استفاده
در اول مهر ۱۴۰۵ نرم‌افزار برای عملکرد موردنظر مدیریت آماده است. بهای ۲٬۱۰۰ از حساب «در جریان ایجاد» به «دارایی نامشهود ـ نرم‌افزار اتوماسیون مالی» منتقل می‌شود. ثبت: بدهکار دارایی نامشهود ۲٬۱۰۰ و بستانکار دارایی نامشهود در جریان ایجاد ۲٬۱۰۰. این انتقال هیچ پرداخت نقدی جدید و هیچ سود یا زیان مستقلی ایجاد نمی‌کند.
| حساب | بدهکار | بستانکار |
|---|---|---|
| دارایی نامشهود ـ نرم‌افزار مالی | ۲٬۱۰۰ | — |
| دارایی نامشهود در جریان ایجاد | — | ۲٬۱۰۰ |
۱۷. استهلاک از چه زمانی آغاز می‌شود؟
دارایی نامشهود با عمر مفید معین از زمان آماده‌بودن برای استفاده مستهلک می‌شود، نه از تاریخ آغاز تحقیق یا نخستین استفاده واقعی کارکنان. تاریخ‌های آغاز پروژه، احراز معیارها و آماده‌شدن برای استفاده در مثال به‌ترتیب فروردین، تیر و مهرند و هرکدام اثر متفاوتی دارند. در پرونده واقعی گزارش آزمون پذیرش و تأیید آمادگی سیستم باید تاریخ شروع استهلاک را پشتیبانی کند.
۱۸. عمر مفید نرم‌افزار چگونه تعیین می‌شود؟
شرکت عمر مفید سه سال را براساس سرعت تغییر فناوری، وابستگی به زیرساخت، دوره کنترل حقوق، هزینه نگهداری و برنامه جایگزینی برآورد کرده است. این مقدار فرض آموزشی است؛ نرم‌افزار دیگر ممکن است عمر متفاوتی داشته باشد. به‌ویژه در سامانه‌های مبتنی بر فناوری‌های سریع‌التغییر، بررسی شواهد منسوخ‌شدن اهمیت زیادی دارد. عمر مفید و روش استهلاک باید طبق الزامات مربوط به‌طور دوره‌ای بازبینی شوند.
۱۹. محاسبه استهلاک سالانه و شش‌ماهه
بهای دارایی ۲٬۱۰۰، ارزش باقیمانده صفر و عمر مفید ۳ سال است. بنابراین استهلاک سالانه ۷۰۰ = ۲٬۱۰۰ ÷ ۳، استهلاک ماهانه ۵۸٫۳۳۳ و استهلاک شش‌ماهه مهر تا اسفند ۱۴۰۵ برابر ۳۵۰ = ۷۰۰ × ۶ ÷ ۱۲ میلیون ریال است. محاسبه باید از تاریخ آماده‌استفاده انجام شود. در ثبت‌های عملی، گردکردن ارقام ماهانه نباید به اختلاف غیرمنطقی در جمع کل منجر شود.
۲۰. ثبت استهلاک سال ۱۴۰۵
با فرض استفاده اداری از نرم‌افزار، ثبت پایان سال شامل بدهکار «هزینه استهلاک نرم‌افزار» ۳۵۰ و بستانکار «استهلاک انباشته نرم‌افزار» ۳۵۰ است. در صورتی که نرم‌افزار در تولید موجودی یا ایجاد دارایی دیگری به‌کار رود، محل انعکاس استهلاک ممکن است طبق استاندارد مربوط متفاوت باشد.
| حساب | بدهکار | بستانکار |
|---|---|---|
| هزینه استهلاک نرم‌افزار | ۳۵۰ | — |
| استهلاک انباشته نرم‌افزار | — | ۳۵۰ |
۲۱. مبلغ دفتری پایان سال ۱۴۰۵
بهای اولیه دارایی ۲٬۱۰۰ و استهلاک انباشته پایان سال ۳۵۰ است؛ پس مبلغ دفتری خالص = ۱٬۷۵۰ میلیون ریال. این مبلغ ارزش ثبت‌شده حسابداری است؛ نه ارزش بازار نرم‌افزار یا مجموع صرفه‌جویی آتی آن. در مفروضات این سناریو کاهش ارزشی شناسایی نشده است.
| قلم | میلیون ریال |
|---|---|
| بهای تمام‌شده نرم‌افزار | ۲٬۱۰۰ |
| استهلاک انباشته | (۳۵۰) |
| مبلغ دفتری پایان ۱۴۰۵ | ۱٬۷۵۰ |
۲۲. کل اثر پروژه بر سود سال ۱۴۰۵
هزینه تحقیق ۸۰۰، توسعه قبل از احراز معیارها ۴۰۰، آموزش ۱۸۰ و تبلیغات ۱۲۰ در مجموع ۱٬۵۰۰ است. به‌علاوه، استهلاک شش‌ماهه ۳۵۰، کل اثر کاهنده بر سود سال را به ۱٬۸۵۰ می‌رساند. کنترل نهایی: ۱٬۸۵۰ هزینه شناسایی‌شده + ۱٬۷۵۰ دارایی خالص = ۳٬۶۰۰ مخارج پرداخت‌شده. این تطبیق یکی از کنترل‌های اصلی پرونده پروژه است.
| قلم اثرگذار بر سود ۱۴۰۵ | میلیون ریال |
|---|---|
| تحقیق | ۸۰۰ |
| توسعه پیش از معیارها | ۴۰۰ |
| آموزش | ۱۸۰ |
| تبلیغات | ۱۲۰ |
| استهلاک | ۳۵۰ |
| جمع هزینه در سود و زیان | ۱٬۸۵۰ |
۲۳. برنامه کامل استهلاک سه‌ساله
| سال مالی | هزینه استهلاک | استهلاک انباشته پایان سال | مبلغ دفتری پایان سال |
|---|---|---|---|
| ۱۴۰۵ ـ شش ماه | ۳۵۰ | ۳۵۰ | ۱٬۷۵۰ |
| ۱۴۰۶ | ۷۰۰ | ۱٬۰۵۰ | ۱٬۰۵۰ |
| ۱۴۰۷ | ۷۰۰ | ۱٬۷۵۰ | ۳۵۰ |
| ۱۴۰۸ ـ شش ماه | ۳۵۰ | ۲٬۱۰۰ | صفر |
| جمع | ۲٬۱۰۰ | — | — |
با فرض نبود تغییر برآورد یا کاهش ارزش، دارایی در پایان شهریور ۱۴۰۸ کاملاً مستهلک می‌شود. استهلاک کامل به معنای توقف حتمی استفاده عملیاتی نیست.
۲۴. اگر تمام ۳٬۶۰۰ میلیون ریال سرمایه‌ای شود
در ثبت نادرست، بهای دارایی ۳٬۶۰۰ و استهلاک شش‌ماهه با عمر سه‌ساله ۶۰۰ می‌شود؛ پس مبلغ دفتری پایان ۱۴۰۵ ۳٬۰۰۰ و هزینه سال فقط ۶۰۰ خواهد بود. در روش صحیح، مبلغ دفتری ۱٬۷۵۰ و مجموع هزینه ۱٬۸۵۰ است. بنابراین دارایی و سود پیش از مالیات هرکدام ۱٬۲۵۰ میلیون ریال بیش از واقع گزارش می‌شوند. این خطا یکی از مهم‌ترین ریسک‌های حسابرسی دارایی‌های نامشهود داخلی است.
| شاخص | روش نادرست | روش صحیح |
|---|---|---|
| بهای دارایی | ۳٬۶۰۰ | ۲٬۱۰۰ |
| استهلاک شش‌ماهه | ۶۰۰ | ۳۵۰ |
| سایر هزینه‌های پروژه | صفر | ۱٬۵۰۰ |
| جمع هزینه سال | ۶۰۰ | ۱٬۸۵۰ |
| مبلغ دفتری پایان سال | ۳٬۰۰۰ | ۱٬۷۵۰ |
۲۵. اگر تمام مخارج هزینه شوند
خطای مقابل آن است که شرکت تمام ۳٬۶۰۰ را هزینه سال ۱۴۰۵ بداند، درحالی‌که ۲٬۱۰۰ مخارج توسعه از تاریخ احراز معیارها واجد شرایط بوده‌اند. هزینه صحیح سال با احتساب استهلاک ۱٬۸۵۰است. بنابراین هزینه‌کردن کل مبلغ باعث می‌شود سود و دارایی پایان سال هرکدام ۱٬۷۵۰ میلیون ریال کمتر از مبلغ صحیحگزارش شوند. مدیریت نباید برای احتیاط ظاهری، شناسایی دارایی واجد شرایط را کنار بگذارد.
۲۶. حقوق برنامه‌نویسان همیشه دارایی نیست
کد شغلی «برنامه‌نویس» ماهیت حسابداری مخارج را تعیین نمی‌کند. یک کارمند ممکن است قسمتی از ساعات را صرف تحقیق، نگهداری سامانه قدیمی، پشتیبانی کاربر یا توسعه قابلیت جدید کند. سرمایه‌ای‌شدن تنها به سهم فعالیت مستقیماً قابل انتساب به ایجاد دارایی، پس از احراز معیارها و پیش از آماده‌شدن برای استفاده محدود است. سامانه ثبت ساعات و تأیید مدیر پروژه باید از تخصیص دستوری و فاقد مدرک جلوگیری کند.
۲۷. مخارج نگهداری پس از راه‌اندازی
اصلاح اشکالات معمول، پشتیبانی کاربران، بروزرسانی امنیتی و حفظ سطح عملکرد غالباً ماهیت هزینه جاری دارند. توسعه ماژول جدید فقط در صورت تشخیص یک دارایی واجد شرایط و احراز معیارهای لازم می‌تواند برخورد متفاوتی داشته باشد. شرکت نباید همه مخارج «ارتقای نرم‌افزار» را به‌صورت یکجا دارایی کند. برای هر درخواست تغییر، شرح فنی، منفعت آتی و تاریخ شروع و پایان توسعه باید ثبت شود.
۲۸. پروژه‌های هوش مصنوعی چه تفاوتی دارند؟
وجود مدل زبانی یا الگوریتم هوش مصنوعی، معیارهای IAS 38 و استاندارد ۱۷ را حذف نمی‌کند. آزمایش مدل‌های مختلف، بررسی امکان عملکرد قابل قبول و مقایسه روش استخراج اطلاعات ممکن است مرحله تحقیق باشند؛ در مقابل توسعه رابط اختصاصی تحت کنترل شرکت پس از احراز معیارها می‌تواند بخشی از دارایی قابل شناسایی شود. هزینه مصرف API، تهیه داده، آموزش مدل، رابط نرم‌افزار و آزمون امنیت نیز ماهیت یکسانی ندارند. مالکیت و کنترل نتیجه و تاریخ احراز معیارها باید به‌طور مستقل بررسی شود.
۲۹. تفاوت نرم‌افزار داخلی با اشتراک SaaS
خرید خدمت دسترسی به نرم‌افزار تأمین‌کننده در قرارداد SaaS الزاماً به معنای تملک یا کنترل یک دارایی نرم‌افزاری نیست. کمیته تفسیر IFRS در تصمیم نهایی سال ۲۰۲۱ درباره هزینه‌های پیکربندی و سفارشی‌سازی نرم‌افزار ابری توضیح داده است که دریافت‌کننده خدمت در بسیاری از موارد یک نرم‌افزار تحت کنترل خود ندارد؛ بااین‌حال، ممکن است کد جداگانه تحت کنترل مشتری ایجاد شود که معیارهای دارایی نامشهود را احراز کند. همچنین زمان شناسایی هزینه خدمات ممکن است به متمایزبودن خدمت پیکربندی از دسترسی SaaS وابسته باشد. این موضوع باید قراردادمحور بررسی شود.
۳۰. آیا هزینه سرویس ابری توسعه قابل سرمایه‌ای‌شدن است؟
در مثال، ۳۵۰ بابت ظرفیت پردازشی اختصاص‌یافته به ساخت و آزمون کد تحت کنترل شرکت، بعد از اول تیر و پیش از آماده‌استفاده، مصرف شده است؛ به همین دلیل با فرض انتساب مستقیم و شرایط شناخت در بهای دارایی آمده است. اگر همین مبلغ بابت حق دسترسی به نرم‌افزار شخص ثالث در دوره بهره‌برداری یا اشتراک عمومی ابری بود، ممکن بود به هزینه خدمات یا پیش‌پرداخت مربوط باشد. عنوان «هزینه سرور» برای نتیجه‌گیری کافی نیست و باید قرارداد، زمان وقوع و خروجی تحت کنترل بررسی شوند.
۳۱. اثبات منافع اقتصادی آتی نرم‌افزار
برای نرم‌افزار داخلی، منافع آتی می‌تواند کاهش ساعات ثبت اسناد، کاهش مخارج برون‌سپاری، تسریع بستن حساب‌ها، افزایش ظرفیت ارائه خدمت و کنترل خطاهای پرهزینه باشد. فرض برآورد صرفه‌جویی سالانه ۱٬۰۰۰ میلیون ریال ممکن است یکی از شواهد سودمندی پروژه باشد؛ اما به‌تنهایی برای سرمایه‌ای‌شدن کافی نیست. ضمناً بهای دارایی براساس مخارج واجد شرایط است، نه ارزش فعلی تمام صرفه‌جویی‌های آینده. برآورد منافع باید با معیارهای دیگر و قابلیت اتکای داده‌ها همراه باشد.
۳۲. کاهش ارزش نرم‌افزار
تغییر فناوری، از رده خارج‌شدن زیرساخت، شکست استقرار یا افت منافع آتی ممکن است نشانه کاهش ارزش باشد. پس از شناخت اولیه نیز باید الزامات استاندارد حسابداری شماره ۳۲، تجدیدنظر در عمر مفید و برخورد با تغییر برآورد بررسی شود. ثبت ۲٬۱۰۰به‌عنوان دارایی تضمین نمی‌کند که تمام آن تا پایان سه سال بدون تعدیل در دفاتر بماند. در سناریوی اصلی برای تمرکز بر تقسیم هزینه‌ها، کاهش ارزش صفر فرض شده است.
۳۳. ERP برای مدیریت پروژه‌های نرم‌افزاری
ماژول مدیریت پروژه می‌تواند هزینه‌ها را به پروژه، فعالیت و بازه زمانی متصل کند و حساب «در جریان ایجاد» را پشتیبانی کند. مستندات Microsoft Dynamics 365 درباره Investment Projects نمونه‌ای از گردش مخارج سرمایه‌ای پروژه را نشان می‌دهند؛ بااین‌حال، یک ERP صرفاً با مشاهده نوع پروژه نمی‌تواند داوری استانداردی درباره همه مخارج انجام دهد. کدینگ باید تاریخ احراز معیارها، نوع فعالیت، مجازبودن مخارج و تاریخ آماده‌استفاده را کنترل کند. مجوز ثبت دارایی نیازمند تایید حرفه‌ای و اسناد فنی است.
۳۴. اطلاعات ضروری در پرونده نرم‌افزار
| داده | کاربرد کنترلی |
|---|---|
| شناسه و شرح پروژه | اتصال مخارج به دارایی مشخص |
| تاریخ شروع تحقیق و توسعه | تفکیک مراحل |
| تاریخ احراز شش معیار | تعیین شروع سرمایه‌ای‌کردن |
| مصوبه مدیریت و تأیید فنی | اثبات قصد، منابع و امکان تکمیل |
| مستندات کنترل حقوق نرم‌افزار | تشخیص دارایی نامشهود |
| ساعات کارکنان و فاکتورهای پیمانکار | تخصیص مخارج مستقیم |
| مخارج پردازش و آزمون | تفکیک توسعه از بهره‌برداری |
| هزینه آموزش و تبلیغات | جلوگیری از سرمایه‌ای‌شدن نادرست |
| تاریخ آماده‌استفاده | شروع استهلاک |
| عمر مفید و روش استهلاک | محاسبه دوره‌ای |
| مسئول تأیید و تاریخچه تغییرات | ردپای حسابرسی |
۳۵. کاربرد هوش مصنوعی در کنترل هزینه توسعه
هوش مصنوعی می‌تواند شرح ساعات کارکنان و فاکتورها را برای طبقه‌بندی اولیه تحقیق، توسعه، آموزش و نگهداری بررسی کند؛ هزینه‌های ثبت‌شده پیش از تاریخ مجاز را علامت بزند؛ نبود گزارش امکان‌پذیری یا مصوبه را هشدار دهد؛ و تاریخ تأیید بهره‌برداری را با تاریخ آغاز استهلاک مقایسه کند. این‌ها ابزار پشتیبان‌اند، نه مرجع نهایی تشخیص معیارهای شناخت. تصمیم سرمایه‌ای‌کردن، اعمال اصلاح یا ثبت قطعی باید توسط متخصص مالی با تأیید شواهد فنی انجام شود.
۳۶. معماری پیشنهادی سیستم هوشمند
تعریف پروژه ← ثبت مراحل تحقیق و توسعه ← گردآوری شواهد شش معیار ← تأیید تاریخ احراز ← ثبت ساعات و فاکتورها ← طبقه‌بندی مخارج ← ثبت دارایی در جریان ایجاد ← تأیید آمادگی ← انتقال به دارایی نامشهود ← محاسبه استهلاک ← بازبینی کاهش ارزش ← گزارش و ردپای حسابرسی.
در این تقسیم مسئولیت، فناوری اطلاعات امکان فنی و وضعیت آمادگی را تأیید می‌کند؛ مدیریت منابع و قصد تکمیل را مستند می‌سازد؛ حسابداری معیارهای شناخت و مخارج را بررسی می‌کند؛ و ERP محاسبات و گردش مصوبات را نگهداری می‌کند.
۳۷. هشت کنترل داخلی ضروری
- تفکیک تحقیق از توسعه: شرح فعالیت‌ها و تاریخ‌ها شفاف باشد. ۲. ثبت تاریخ احراز معیارها: صورت‌جلسه و شواهد معتبر نگهداری شود. ۳. کنترل ساعات کارکنان: تخصیص حقوق بر اساس کارکرد واقعی باشد. ۴. حذف مخارج غیرمجاز: آموزش، تبلیغات، نگهداری و مخارج عمومی بدون مبنا به دارایی منتقل نشوند. ۵. منع سرمایه‌ای‌کردن گذشته: موفقیت بعدی مجوز بازگرداندن هزینه‌های قبلاً درست‌شناسایی‌شده نیست. ۶. کنترل تاریخ آماده‌استفاده:آغاز استهلاک دقیق باشد. ۷. بازنگری عمر مفید و کاهش ارزش: تغییرات فناوری رصد شوند. ۸. تطبیق با دفتر کل:جمع مخارج، دارایی در جریان، دارایی نهایی، استهلاک و هزینه‌های دوره با مدارک پروژه تطبیق داشته باشند.
۳۸. فرصت توسعه محصول برای حسابداران برتر
پیشنهاد توسعه محصول: ماژول هوشمند حسابداری تحقیق و توسعه نرم‌افزار. این یک پیشنهاد است و به معنی وجود فعلی چنین قابلیتی در محصولات حسابداران برتر نیست. ماژول پیشنهادی می‌تواند پروژه‌ها و مراحل آن‌ها، شواهد شش معیار، تاریخ شروع سرمایه‌ای‌کردن، ثبت ساعات کارکنان، کنترل مخارج نامجاز، دارایی در جریان ایجاد، تأیید آمادگی برای استفاده، استهلاک، نشانه‌های کاهش ارزش و گزارش حسابرسی را یکپارچه کند.
| شاخص داشبورد پیشنهادی | مبلغ |
|---|---|
| کل مخارج پروژه | ۳٬۶۰۰ |
| تحقیق | ۸۰۰ |
| توسعه قبل از احراز معیارها | ۴۰۰ |
| توسعه واجد شرایط | ۲٬۱۰۰ |
| آموزش و تبلیغات | ۳۰۰ |
| جمع هزینه مستقیم دوره | ۱٬۵۰۰ |
| استهلاک سال ۱۴۰۵ | ۳۵۰ |
| مبلغ دفتری پایان ۱۴۰۵ | ۱٬۷۵۰ |
۳۹. آثار مالیاتی در ایران
نحوه طبقه‌بندی حسابداری به‌تنهایی تعیین نمی‌کند که مبلغ هزینه در محاسبه مالیات عملکرد پذیرفته می‌شود یا استهلاک نرم‌افزار با چه مبنایی قابل قبول است. قراردادها، اسناد پرداخت، مقررات هزینه‌های قابل قبول، ضوابط استهلاک مالیاتی و شرایط مشوق‌های تحقیق و توسعه احتمالی باید جداگانه بررسی شوند. تفاوت مبنای مالیاتی و حسابداری ممکن است موضوع مالیات انتقالی را مطرح کند. در این مقاله هیچ نرخ یا معافیت مالیاتی برای سناریوی فرضی اعمال نشده است.
۴۰. الزامات افشای دارایی نامشهود
مطابق استاندارد ۱۷ باید اطلاعات مهم دارایی نامشهود، از جمله عمر مفید، روش استهلاک، بهای ناخالص، استهلاک انباشته، اضافات، تغییرات دوره و در صورت لزوم کاهش ارزش و دارایی‌های ایجادشده در داخل واحد تجاری در یادداشت‌های توضیحی ارائه شوند. بند ۱۰۲ نیز افشای مخارج تحقیق و توسعه منظورشده به هزینه دوره را مطرح می‌کند. بنابراین، صرف ثبت سند سرمایه‌ای‌شدن برای گزارشگری صحیح کافی نیست.
۴۱. برنامه اجرایی چهار‌هفته‌ای
هفته اول: فهرست پروژه‌های داخلی، خروجی موردانتظار، مالک فرایند و مدارک هزینه را گردآوری کنید. هفته دوم: تحقیق و توسعه را تفکیک کنید و شش معیار و تاریخ نخستین احراز را مستند سازید. هفته سوم: مخارج قبل و بعد از تاریخ مجاز، هزینه‌های مستقیم و هزینه‌های آموزش و تبلیغات را با کاربرگ محاسبه و تطبیق دهید. هفته چهارم: انتقال دارایی در جریان ایجاد، تاریخ آمادگی، عمر مفید، برنامه استهلاک، کنترل کاهش ارزش و تطبیق با دفتر کل را برای تأیید مالی نهایی انجام دهید.
۴۲. جمع‌بندی تخصصی
در پروژه ساخت نرم‌افزار داخلی، تمام مخارج به یک طبقه حسابداری تعلق ندارند. مخارج تحقیق هنگام وقوع هزینه می‌شوند؛ مخارج توسعه نیز تنها از تاریخی که معیارهای شناخت اثبات شده‌اند و فقط در حدود مخارج قابل انتساب، دارایی می‌شوند. آموزش کاربران و تبلیغات، با مفروضات مثال، هزینه دوره‌اند. شرکت فرضی از ۳٬۶۰۰ میلیون ریال کل مخارج، ۲٬۱۰۰ را دارایی و ۱٬۵۰۰ را هزینه مستقیم شناسایی کرده است. نرم‌افزار از اول مهر آماده استفاده است و استهلاک سال نخست ۳۵۰ و مبلغ دفتری پایان سال ۱٬۷۵۰ میلیون ریال است. مجموع اثر بر سود ۱۴۰۵ ۱٬۸۵۰ میلیون ریال هزینه است. سرمایه‌ای‌کردن همه مخارج، دارایی و سود سال را در این مثال ۱٬۲۵۰ بیش از واقع نشان می‌دهد؛ هزینه‌کردن همه مخارج نیز آن‌ها را ۱٬۷۵۰ کمتر از واقع گزارش می‌کند. کنترل کلیدی، تاریخ احراز معیارها + ماهیت مخارج + تاریخ آماده‌استفاده است.