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