مقدمه: جمع هزینه درست است، اما سهم هر پروژه چطور؟
مدیر مالی یک شرکت خدمات مهندسی در پایان ماه گزارش بهای تمام‌شده دو پروژه را دریافت می‌کند. جمع هزینه‌های مشترک دفتر کل ۳۰۰ میلیون ریال است؛ سامانه هوشمند نیز دقیقاً همین مبلغ را میان دو پروژه توزیع کرده است. جمع ستون‌ها درست است و هیچ هزینه‌ای از دفتر کل حذف نشده. با این حال، مدیر پروژه «الف» می‌گوید هزینه منتسب به پروژه او ۶۰ میلیون ریال بیش از سهم قابل دفاع است.
منشأ اختلاف، فرمول جمع‌زدن نیست؛ انتخاب مبنای تسهیم سربار است. نرم‌افزار درآمد قراردادها را معیار تقسیم قرار داده، اما ماهیت هزینه‌های مشترک مورد بحث، طبق سیاست مستند و متناسب با فعالیت همان شرکت، تخصیص بر اساس ساعات کار مستقیم را ایجاب می‌کند. این تفاوت، هزینه کل شرکت را تغییر نمی‌دهد؛ ولی سودآوری پروژه، مبلغ قابل مطالبه تحت برخی قراردادها، ارزیابی عملکرد مدیران و حتی تصمیم ادامه یک کار را جابه‌جا می‌کند.
پرسش بنیادین برای حسابدار صنعتی این است: آیا موتور محاسباتی فقط عددی را تقسیم کرده، یا می‌تواند نشان دهد چرا همین مبنا، برای همین هزینه‌ها، همین دوره و همین قرارداد معتبر بوده است؟
تحول جدید: از تراز آزمایشی تا پرونده مستند نرخ هزینه غیرمستقیم
در اکتبر ۲۰۲۶، تجربه تازه‌ای از تهیه خودکار پرونده پیشنهاد نرخ هزینه‌های غیرمستقیم در یک بستر نرم‌افزاری گزارش شد. در اطلاعیه‌ای که در بازنشرهای ۲۷ و ۲۸ اکتبر ۲۰۲۶ منتشر شد، سازنده اعلام کرد که یک پرونده تولیدشده از تراز آزمایشی حسابرسی‌شده و مستندات پشتیبان توسط مرجع بررسی دریافت و پذیرفته شده است. این اعلام به معنای «تأیید قطعی نرخ قابل دریافت در هر قرارداد» یا اثبات مستقل تمام ادعاهای صرفه‌جویی نیست.
فناوری محوری لزوماً مدل زبانیِ تولیدکننده متن نیست. ارزش اصلی در اتصال کد حساب، ماهیت هزینه، مخزن هزینه غیرمستقیم، مبنای تخصیص، محاسبات عددی و شواهد تأیید است؛ به شکلی که یک کاربرگ بتواند از رقم نهایی تا سند اولیه قابل ردیابی باشد.
برای ایران، درس قابل استفاده نه کپی مقررات قراردادهای فدرال آمریکاست و نه ادعای وجود همان محصول در کشور. فرصت، ساخت یک موتور تسهیم سربار نسخه‌دار، قابل رسیدگی و مرتبط با قرارداد برای پیمانکاران، شرکت‌های پروژه‌محور، مؤسسات خدماتی و واحدهای تولیدی است.
مثال عددی: دو پروژه و اختلاف ۶۰ میلیون ریالی
تمام مبالغ این مثال فرضی و آموزشی هستند؛ واحد مبالغ، میلیون ریال است. شرکت دو پروژه «الف» و «ب» دارد و فرض می‌کنیم ۳۰۰ میلیون ریال هزینه مشترک مربوط به پشتیبانی عملیاتی هر دو پروژه، پس از حذف اقلام نامرتبط، در یک مخزن هزینه معتبر قرار گرفته است. در این سناریوی آموزشی، طبق تحلیل ماهیت فعالیت و سیاست مصوب شرکت، ساعات کار مستقیمِ تأییدشده مبنای مناسب تخصیص این مخزن است.
نرخ جذب بر مبنای ساعت برابر ۳۰۰ میلیون ریال ÷ ۱٬۰۰۰ ساعت = ۰٫۳ میلیون ریال برای هر ساعت است. ازاین‌رو سهم پروژه الف ۶۰۰ × ۰٫۳ = ۱۸۰ و سهم پروژه ب ۴۰۰ × ۰٫۳ = ۱۲۰ میلیون ریال خواهد بود.
اما اگر عامل هوشمند، صرفاً به دلیل اینکه اطلاعات درآمد در ERP آماده‌تر بوده، سهم درآمد را مبنا بگیرد، ۸۰ درصد مخزن یعنی ۲۴۰ میلیون ریال را به الف و ۲۰ درصد یعنی ۶۰ میلیون را به ب نسبت می‌دهد.
نتیجه مهم: جمع سربار شرکت در هر دو روش ۳۰۰ میلیون ریال است. پس گزارش دفتر کل ممکن است کاملاً تراز بماند؛ بااین‌حال ۶۰ میلیون ریال جابه‌جایی میان پروژه‌ها رخ داده است. این رقم، هزینه اضافی واقعی برای کل شرکت یا زیان اثبات‌شده نیست؛ اختلاف تخصیص مدیریتی تحت مفروضات مثال است.
سودآوری پروژه چگونه تغییر می‌کند؟
برای نشان دادن اثر، فرض کنیم هزینه‌های مستقیم پروژه الف ۴۰۰ میلیون ریال و پروژه ب ۱۰۰ میلیون ریال است؛ این دو عدد نیز فرضی‌اند. هیچ هزینه دیگری در مثال نداریم.
در هر دو روش، جمع مازاد دو پروژه پیش از سایر اقلام ۲۰۰ میلیون ریال است. اما روش نامناسب، پروژه الف را ۶۰ میلیون ریال ضعیف‌تر و پروژه ب را ۶۰ میلیون ریال بهتر نشان می‌دهد. چنین تحلیلی می‌تواند درباره قیمت‌گذاری، تمدید قرارداد، پاداش عملکرد یا ادامه پروژه، تصمیم نادرست ایجاد کند.
البته در دنیای واقعی، ممکن است ساعات کار مبنای مناسبی برای یک مخزن هزینه و نامناسب برای مخزن دیگر باشد. مثلاً هزینه برق تجهیزات ممکن است بیشتر با ساعت کار ماشین‌آلات ارتباط داشته باشد و هزینه منابع انسانی پشتیبانی با تعداد کارکنان یا ساعات خدمات. درست بودن مبنا باید برای هر مخزن هزینه احراز شود؛ نه اینکه ساعات کار به‌عنوان نسخه همیشگی معرفی شود.
چهار نوع اشتباه که تقسیم عددیِ درست را بی‌اعتبار می‌کند
اول؛ مخزن هزینه نامعتبر. حسابدار ممکن است اجاره دفتر مرکزی، هزینه تعمیر تجهیزات پروژه اختصاصی و خرید نرم‌افزار برای یک واحد را بدون تحلیل، در یک مخزن واحد قرار دهد. فرمول تسهیم هرقدر دقیق باشد، ترکیب هزینه‌های نامتجانس نتیجه را قابل دفاع نمی‌کند.
دوم؛ دوباره‌احتساب هزینه مستقیم. هزینه‌ای که مستقیم به پروژه الف تخصیص یافته نباید برای همان ماهیت و شرایط، بار دیگر داخل مخزن سربار مشترک قرار گیرد. این خطا از تغییر مبنا خطرناک‌تر است، چون می‌تواند جمع هزینه منتسب به پروژه‌ها را نیز بیش از هزینه واقعی کند.
سوم؛ مبنای نامتناسب یا ناقص. اگر ساعات برخی کارکنان ثبت نشده باشد، یا درآمد یکی از پروژه‌ها از دوره دیگری آمده باشد، تقسیم کردن هزینه به داده ناقص دقت ظاهری ایجاد می‌کند.
چهارم؛ استفاده از نسخه اشتباه سیاست و قرارداد. ممکن است در ابتدای سال یک مبنا تصویب شده و برای دوره بعد تغییر کرده باشد. الگوریتم باید تاریخ اثر، دامنه قرارداد و مجوز تغییر را تشخیص دهد؛ «آخرین فایل اکسل» الزاماً «سیاست لازم‌الاجرا برای همه ماه‌ها» نیست.
آیا سربار منتسب به پروژه، همان مبلغ قابل مطالبه از کارفرماست؟
خیر، لزوماً نه. این تمایز برای پروژه‌های پیمانکاری اهمیت ویژه‌ای دارد. یک مبلغ ممکن است در حسابداری مدیریت به پروژه اختصاص یابد، اما قرارداد اجازه مطالبه همان مبلغ از کارفرما را ندهد. بعضی قراردادها هزینه‌های غیرمستقیم را با نرخ، سقف یا مدارک مشخص می‌پذیرند؛ بعضی قیمت مقطوع دارند و هزینه واقعی مبنای دریافت وجه نیست.
در مثال بالا فرض کنید قرارداد پروژه الف صرفاً به‌طور فرضی، بازپرداخت هزینه‌های غیرمستقیم را تا سقف ۱۸۰ میلیون ریال و پس از احراز شرایط اسناد مجاز می‌داند. اگر عامل هوشمند ۲۴۰ میلیون ریال را از روی مبنای درآمد وارد پیش‌نویس صورت‌وضعیت کند، ۶۰ میلیون ریال بیش از این سقف فرضی پیشنهاد شده است. این رقم «مطالبه بالقوه نامعتبر» است؛ نه درآمد شناسایی‌شده، جریمه قطعی یا زیان تحقق‌یافته.
در مقابل، در قرارداد قیمت مقطوع ممکن است کل این تحلیل برای سودآوری داخلی ضروری باشد اما اصلاً تغییری در مبلغ صورتحساب قراردادی ایجاد نکند. بنابراین نرم‌افزار باید خروجی «سهم هزینه پروژه»، «هزینه قابل مطالبه طبق قرارداد» و «درآمد شناسایی‌شده طبق مبنای حسابداری» را از هم جدا نگه دارد.
چرا تراز آزمایشی به‌تنهایی کافی نیست؟
تراز آزمایشی می‌گوید کدام حساب‌ها چه مانده‌ای دارند؛ اما لزوماً به پرسش‌های چه کسی از هزینه منتفع شده، کدام بخش مستقیم است، چه مبنایی انتخاب شده و قرارداد چه اجازه‌ای می‌دهد پاسخ نمی‌دهد. برای تولید کاربرگ قابل رسیدگی باید حداقل داده‌های زیر به صورت کنترل‌شده به هم متصل شوند:
- کد حساب و سند مبدأ: مبلغ، تاریخ، شخصیت حقوقی، مرکز هزینه و سند پشتیبان؛
- شناسنامه مخزن: نام، ماهیت و اقلام مجاز هزینه مشترک؛
- مبنای تخصیص: ساعت مستقیم، ساعت ماشین، تعداد کارکنان یا شاخص مستند دیگر با تعریف واحد؛
- نسخه سیاست: تاریخ اثر، تصویب‌کننده، استثناها و دوره اعتبار؛
- دامنه قرارداد: پروژه‌های مشمول، هزینه‌های قابل مطالبه، سقف و شرایط مدرک؛
- ردپای محاسبه: فرمول، ورودی، خروجی، اختلاف‌ها و تأیید نهایی.
تراز آزمایشی حسابرسی‌شده، کیفیت یک منبع را تقویت می‌کند؛ اما به‌تنهایی تضمین‌کننده درستی همه طبقه‌بندی‌ها، مبانی تسهیم یا ادعاهای قراردادی نیست.
نقش AI و موتور محاسباتی قطعی باید جدا باشد
عامل هوشمند برای خواندن قراردادها، پیدا کردن اسناد، پیشنهاد طبقه‌بندی هزینه، شناسایی تغییرات نسبت به ماه قبل و توضیح مغایرت‌ها مفید است. اما عدد نهایی نرخ و سهم پروژه باید با موتور قابل آزمون محاسبه شود.
در الگوی عملی، AI از روی شرح سند ممکن است پیشنهاد کند «هزینه نگهداری مشترک تجهیزات» به مخزن هزینه پشتیبانی تعلق دارد. متخصص مالی باید این طبقه‌بندی را تأیید یا قاعده‌ای مصوب برای آن تعریف کند. سپس موتور قطعی با نرخ و مبنای معتبر، محاسبه را انجام دهد؛ خروجی به همراه سند مبدأ، نسخه قاعده و علت انتخاب مبنا ذخیره شود.
اگر دسترسی به قرارداد، اطلاعات ساعات کار یا تأییدیه هزینه ناقص باشد، نتیجه باید برچسب «در انتظار بررسی» بگیرد، نه اینکه سیستم برای پر کردن جای خالی ارقام یا مقررات تازه اختراع کند.
هشت کنترل ضروری برای اتوماسیون نرخ سربار
۱. تفکیک مستقیم و غیرمستقیم: یک هزینه با ماهیت یکسان در شرایط مشابه، هم مستقیم و هم داخل مخزن سربار تکرار نشود.
۲. مخزن‌های همگن و هدفمند: هزینه‌هایی که محرک متفاوت دارند بی‌دلیل در یک نرخ واحد ترکیب نشوند.
۳. مبنای قابل دفاع: تناسب مبنا با منفعت یا مصرف منابع مستند شود؛ انتخاب مبنا تنها از روی در دسترس‌بودن یک ستون ERP انجام نشود.
۴. پوشش کامل جامعه: جمع ساعت‌ها یا شاخص مبنا از منابع معتبر و برای همان دوره و شخصیت حقوقی کنترل شود؛ حذف یک پروژه از مخرج نرخ باید دلیل مصوب داشته باشد.
۵. قواعد نسخه‌دار: سیاست، استثنا، تاریخ اثر و شرایط قرارداد کنار هر اجرای محاسبه ثبت شود.
۶. کنترل جمع و یکتایی: جمع سهم پروژه‌ها باید با مخزن قابل تخصیص و تعدیلات مجاز تطبیق کند؛ یک سند در دو مخزن هم‌پوشان دوباره منظور نشود.
۷. تفکیک مدیریت و مطالبه: سهم هزینه، هزینه واجد شرایط قرارداد و صورت‌وضعیت پیشنهادی، فیلدها و مجوزهای جدا داشته باشند.
۸. تأیید و امکان بازاجرا: حسابدار بتواند با همان نسخه داده و قاعده، دقیقاً همان نرخ و تخصیص را دوباره تولید کند و تغییرهای بعدی بی‌ردپا روی پرونده قبلی ننشینند.
یک نکته مهم درباره مقررات خارجی و بازار ایران
رویداد بین‌المللی مبنای این پژوهش مربوط به تهیه پیشنهاد نرخ هزینه غیرمستقیم برای دریافت منابع از برنامه‌های فدرال آمریکاست. الزامات آن به چارچوب‌هایی مانند ۲ CFR ۲۰۰ و پیوست‌های مرتبط وابسته‌اند. این مقررات قانون ایران نیستند و حتی در آمریکا نیز ارائه یا پذیرش یک بسته محاسباتی را نباید با نهایی‌شدن نرخ‌های توافقی یا تأیید تمام هزینه‌های قابل بازپرداخت یکسان گرفت.
در ایران، امکان مطالبه سربار به نوع قرارداد، ضوابط اختصاصی پروژه، شرایط عمومی یا خصوصی پیمان، روش قیمت‌گذاری، قواعد مالی و استانداردهای حسابداری لازم‌الاجرا بستگی دارد. هزینه سربار کارخانه، سربار پروژه خدماتی و هزینه عمومی دفتر مرکزی ممکن است در تصمیم‌گیری مدیریتی یا گزارشگری مالی قواعد متفاوتی داشته باشند.
این مقاله نرخ قانونی عمومی، درصد ثابت «سربار مجاز» یا دستور صدور سند برای همه پیمانکاران ارائه نمی‌کند. ارقام مثال و سقف مطالبه کاملاً فرضی‌اند. همچنین تسهیم داخلی هزینه، به‌صورت خودکار به معنی شناسایی درآمد یا ایجاد طلب قابل وصول نیست.
فرصت نرم‌افزاری برای حسابداران برتر: «موتور نرخ سربار قابل دفاع»
در حوزه محصولات «حسابداران برتر»، می‌توان یک ماژول پیشنهادی با عنوان «موتور هوشمند نرخ جذب و تسهیم سربار پروژه» طراحی کرد؛ این یک فرصت توسعه است، نه ادعای وجود یا عرضه کنونی محصول.
این ماژول می‌تواند کدینگ حساب‌ها، گردش هزینه مراکز، ساعات کارکرد، ساختار پروژه و شروط قرارداد را با اجازه کاربر دریافت کند. هسته محاسباتی، مخزن‌ها و مبانی مصوب را اجرا کند و دو خروجی مجزا بسازد: یک گزارش بهای تمام‌شده و سودآوری داخلی، و یک کاربرگ هزینه قابل مطالبه طبق قرارداد در صورت مجازبودن.
لایه AI باید موارد مشکوک مانند هزینه دوباره‌احتساب‌شده، تغییر مبنای بی‌مصوبه، سند فاقد مرکز هزینه یا اختلاف دوره را پیدا کند و پیش‌نویس توضیح حسابداری بنویسد. تأیید مبنا، تغییر سیاست یا ارسال صورت‌وضعیت باید نزد انسان مجاز باقی بماند.
پشتیبانی از ریال و تومان، تقویم شمسی، چندشرکتی، چندپروژه‌ای، قراردادهای چندمرحله‌ای، داده‌های ناقص کارکرد و سطوح دسترسی برای نسخه قابل استفاده در ایران ضرورت عملی دارد. اتصال به سامانه‌های مالیاتی یا بانکی نیز تنها با وجود نیاز و رابط مجاز تعریف شود.
یک پایلوت چهارمرحله‌ای برای حسابدار صنعتی
گام اول ـ تعریف دامنه: سه مرکز هزینه مشترک و دو تا پنج پروژه را انتخاب کنید. قبل از استفاده از AI، حسابدار صنعتی ماهیت مخزن‌ها، اقلام مستقیم و مبنای مجاز هر مخزن را مستند کند.
گام دوم ـ ساخت پاسخ مرجع: برای حداقل ۲۰ سند آزمایشی، طبقه‌بندی صحیح و سهم پروژه‌ها را دستی یا با یک محاسبه مستقل تعیین کنید. چند سند تکراری، خارج از دوره، فاقد مرکز و با تغییر سیاست در مجموعه قرار دهید.
گام سوم ـ اجرای کنترل‌شده: هوش مصنوعی فقط طبقه‌بندی پیشنهادی و دلیل آن را ارائه کند؛ محاسبه نرخ، اعمال سقف و کنترل جمع با کد قابل بازآزمایی انجام شود. هیچ صورتحساب واقعی خودکار صادر نشود.
گام چهارم ـ سنجش: درصد طبقه‌بندی درست، شمار هزینه‌های دوباره‌احتساب‌شده، اختلاف نرخ نسبت به پاسخ مرجع، زمان آماده‌سازی کاربرگ و موارد فاقد سند را گزارش کنید. هیچ درصد صرفه‌جویی یا افزایش سودی بدون اندازه‌گیری واقعی اعلام نشود.
جمع‌بندی: سرعت محاسبه جای دفاع‌پذیری محاسبه را نمی‌گیرد
در مثال این مقاله، مخزن سربار شرکت در هر دو روش ۳۰۰ میلیون ریال بود. انتخاب مبنای درآمد به جای مبنای ساعات کار مصوب، ۶۰ میلیون ریال هزینه بیشتر به پروژه الف و ۶۰ میلیون کمتر به پروژه ب نسبت داد؛ بدون اینکه جمع هزینه شرکت تغییر کند. اگر همین عدد مستقیماً وارد یک ادعای قراردادی شود، خطر تازه‌ای در صورتحساب و وصول نیز پدید می‌آید.
ارزش نسل تازه نرم‌افزار مالی در «تقسیم‌کردن سریع ۳۰۰ میلیون» نیست؛ در این است که نشان دهد چه هزینه‌ای، با چه مبنایی، به کدام پروژه، در چه دوره‌ای و با استناد به کدام مجوز تخصیص یافته است. هوش مصنوعی می‌تواند مسیر شواهد را کوتاه کند؛ اما قاعده مصوب، محاسبه قابل تکرار و قضاوت حسابدار باید معیار نهایی باقی بمانند.