پروژه ۷۰ درصد پیشرفت کرده؛ چرا هوش مصنوعی نباید ضمانت‌نامه ۱٫۲ میلیارد ریالی را به ۳۶۰ میلیون ریال کاهش دهد؟
مقدمه: پیشرفت عملیات با کاهش تعهد بانک یکی نیست
مدیر پروژه اعلام می‌کند ۷۰ درصد عملیات قرارداد انجام شده است. واحد مالی در داشبورد هوشمند می‌بیند ضمانت‌نامه یا ابزار تضمین بانکی پروژه در ابتدا ۱٬۲۰۰ میلیون ریال بوده است.
دستیار هوش مصنوعی با محاسبه‌ای ساده می‌گوید:
«۳۰ درصد قرارداد باقی است؛ پس تضمین موردنیاز باید ۳۶۰ میلیون ریال باشد.»
این پاسخ از نظر ضرب و تقسیم اشتباه نیست؛ اما از نظر مبنای حقوقی، قراردادی و کنترل ریسک ممکن است کاملاً نامعتبر باشد.
پیشرفت پروژه لزوماً باعث نمی‌شود تعهد مستقل بانک نیز به همان نسبت کاهش یابد. باید متن خود ابزار تضمین، شرایط اصلاح مبلغ، رضایت لازم ذی‌نفع، مستند رسمی بانک و تاریخ مؤثر تغییر بررسی شود.
هوش مصنوعی باید اختلاف بین مبلغ پیشنهادی بر اساس پیشرفت پروژه و مبلغ معتبر ابزار بانکی را نشان دهد؛ نه اینکه پیشنهاد را جای تعهد بالفعل بانک ثبت کند.
خبر فناوری: Finastra StandbyX و دیجیتالی‌کردن فرایند ابزار تضمین
شرکت Finastra در ۱۹ اکتبر ۲۰۲۶ راهکار StandbyX را معرفی کرد؛ راهکاری ابری برای بانک‌های آمریکا که می‌خواهند فرایند رسیدگی به Standby Letter of Credit (SBLC) را دیجیتالی کنند، بدون آنکه یک سامانه کامل تأمین مالی تجارت راه‌اندازی کنند.
به گفته سازنده، محصول از قابلیت‌های ماژول SBLC در مجموعه Trade Innovation بهره می‌برد و برای بانک‌های دارای حجم عملیات کم تا متوسط طراحی شده است.
نکته مهم این است که اطلاعیه رسمی Finastra مدعی نیست StandbyX یک عامل هوش مصنوعی برای محاسبه خودکار کاهش ضمانت‌نامه پیمانکاران است. پیوند این خبر با AI در این مقاله، پیشنهاد مهندسی برای شرکت‌های استفاده‌کننده از ابزارهای تضمین و نرم‌افزارهای مالی است؛ نه توصیف قابلیت محصول سازنده.
اعتبار اسنادی تضمینی و ضمانت‌نامه عندالمطالبه ممکن است از نظر کارکرد اقتصادی شبیه باشند، اما از نظر متن، قواعد حاکم و فرایند مطالبه لزوماً یک ابزار حقوقی واحد نیستند.
در هر پرونده باید مشخص شود ابزار تابع چه قواعد و قانونی است؛ برای مثال ممکن است ISP98 برای اعتبارات اسنادی تضمینی یا URDG 758 برای ضمانت‌نامه عندالمطالبه در متن ابزار انتخاب شده باشد.
مثال عددی: ۱٬۲۰۰ میلیون ریال تضمین، ۷۰ درصد پیشرفت و ۸۴۰ میلیون ریال اختلاف
تمام عددها، شرکت‌ها و قراردادهای این بخش کاملاً ساختگی و آموزشی هستند.
فرض کنید شرکت «الف» برای اجرای یک پروژه، ابزار تضمین بانکی به نفع کارفرما دارد. مبلغ اسمی آن ۱٬۲۰۰ میلیون ریال است و هنوز سند معتبر و مؤثری درباره کاهش مبلغ از بانک دریافت نشده است.
محاسبه پیشنهاد داخلی:
۱٬۲۰۰ × (۱ − ۷۰٪) = ۳۶۰ میلیون ریال
فاصله آن با وضعیت بانکی فعلی در فرض مثال:
۱٬۲۰۰ − ۳۶۰ = ۸۴۰ میلیون ریال
این ۸۴۰ میلیون ریال اضافه‌پرداخت، بدهی شناسایی‌شده یا تقلب نیست.
این عدد صرفاً نشان می‌دهد موتور گزارش نباید پیشرفت عملیات را به‌جای کاهش معتبر تعهد بانکی بنشاند.
در چه شرایطی کاهش مبلغ می‌تواند معتبر شود؟
پاسخ وابسته به متن سند و قواعد لازم‌الاجراست.
برای نمونه در URDG 758، کاهش مبلغ می‌تواند تحت شرایط مشخص ابزار و تحقق رویدادی که به نحو مقرر احراز شده است صورت گیرد، یا از مسیر آزادسازی جزئی امضاشده از سوی ذی‌نفع تحقق یابد.
اصلاحیه‌ای که بدون موافقت ذی‌نفع صادر شده، لزوماً در برابر او الزام‌آور نیست.
بنابراین «درخواست اصلاح» و «اصلاح مؤثر» دو وضعیت جدا هستند.
در ISP98 نیز تعهد اعتبار اسنادی تضمینی ماهیت مستقل و اسنادی دارد و اصلاح یا لغو آن تابع شرایط ابزار و قواعد حاکم است.
پایان یافتن بخشی از کار به‌تنهایی جایگزین اصلاح معتبر تعهد صادرکننده نمی‌شود.
ممکن است برنامه مدیریت پروژه برای محاسبه نیاز آتی تضمین از نرخ پیشرفت استفاده کند؛ اما ماژول ثبت وضعیت تضمین باید تا دریافت شاهد معتبر بانکی و بررسی قواعد، رقم مؤثر را جداگانه حفظ کند.
چهار سطح داده که باید جدا نگهداری شوند
مبلغ اسمی سند بانک: آخرین سند معتبر صادرشده، همراه شماره مرجع، ذی‌نفع و تاریخ.
مبلغ اصلاحی پیشنهادی شرکت: محاسبه داخلی درباره میزان تضمین موردنیاز، بدون اثر قطعی در ابزار.
مبلغ درخواست‌شده برای اصلاح: مبلغی که واحد مجاز برای بانک یا ذی‌نفع درخواست کرده و هنوز ممکن است در انتظار پاسخ باشد.
مبلغ مؤثر تأییدشده: نتیجه اصلاحیه یا رخداد معتبر کاهنده طبق متن سند، با مستند و تاریخ لازم‌الاجرا.
اگر شواهد کافی نیست، سیستم باید وضعیت را «نیازمند بررسی» اعلام کند.
وجه مسدودشده با مبلغ تضمین یکسان نیست
فرض کنید بانک برای ابزار تضمین ۱٬۲۰۰ میلیونی، براساس شرایط قرارداد بانکی ۲۴۰ میلیون ریال وجه نقد را به‌عنوان سپرده یا وثیقه محدود کرده است.
این نسبت ۲۰ درصدی فقط فرض مثال است و نرخ قانونی عمومی محسوب نمی‌شود.
همچنین فرض کنید موجودی گزارش‌شده حساب‌های مجاز شرکت ۱٬۰۰۰ میلیون ریال است که ۲۴۰ میلیون ریال وجه محدودشده داخل آن قرار دارد.
وجه نقد آزاد پیش از سایر تعهدها = ۱٬۰۰۰ − ۲۴۰ = ۷۶۰ میلیون ریال
اگر داشبورد AI همه یک میلیارد ریال را «نقد قابل استفاده» نشان دهد، وجه محدودشده را نادیده گرفته است.
برعکس، اگر ۲۴۰ میلیون ریال از قبل از مانده گزارش بانکی خارج شده باشد و سیستم دوباره آن را کسر کند، نقد آزاد را کمتر از واقع نشان می‌دهد.
از منظر حسابداری، سپرده مسدودشده ممکن است با توجه به حق برداشت، ماهیت حساب، دوره محدودیت و استاندارد قابل‌اعمال، طبقه‌بندی و افشای متفاوتی داشته باشد.
صرف محدودشدن وجه به معنی شناسایی هزینه ۲۴۰ میلیون ریالی نیست.
همچنین مبلغ اسمی ۱٬۲۰۰ میلیونی تضمین به‌طور خودکار بدهی پرداختنی یا هزینه شناسایی‌شده شرکت نمی‌شود.
اگر اصلاحیه صادر شود، آیا وثیقه خودکار آزاد می‌شود؟
خیر.
حتی اگر مبلغ ابزار بانکی به‌صورت معتبر از ۱٬۲۰۰ به ۳۶۰ میلیون ریال کاهش یابد، آزادسازی سپرده وثیقه یک رویداد بانکی و قراردادی مستقل است.
باید بررسی کرد آیا بانک با کاهش وثیقه موافقت کرده، مبلغ آزادشده چقدر بوده، چه زمانی در حساب قابل برداشت شده و آیا تعهد دیگری مانع آزادی وجه نیست.
برای مثال، اگر بانک در قرارداد فرضی نسبت وثیقه ۲۰ درصدی را برای مانده ۳۶۰ میلیونی نیز حفظ کند، وثیقه محاسباتی جدید ۷۲ میلیون ریال خواهد بود:
۳۶۰ × ۲۰٪ = ۷۲ میلیون ریال
اختلاف بالقوه وثیقه:
۲۴۰ − ۷۲ = ۱۶۸ میلیون ریال
اما این ۱۶۸ میلیون ریال وجه آزادشده قطعی نیست؛ صرفاً رقم قابل بررسی برای درخواست آزادسازی است.
تا زمانی که بانک اثر واقعی را تأیید نکرده و وجه در دسترس قرار نگرفته، نباید وارد نقد آزاد شود.
اثر کارمزد تضمین: انگیزه اقتصادی بدون دستکاری تعهد
فرض کنید کارمزد بانک برای دوره باقی‌مانده به‌صورت ساده ۱ درصد سالانه نسبت به مبلغ تضمین تعیین شود.
این نرخ و روش صرفاً مفروضات قرارداد مثال‌اند و نرخ تعرفه بانکی ایران نیستند.
اگر شش ماه از دوره باقی مانده باشد، هزینه فرضی روی مبلغ اولیه چنین است:
۱٬۲۰۰ × ۱٪ × ۶/۱۲ = ۶ میلیون ریال
اگر اصلاح ۳۶۰ میلیونی واقعاً مؤثر شود و بانک از همان تاریخ، کارمزد باقی‌مانده را بر مبنای مبلغ جدید بازقیمت‌گذاری کند:
۳۶۰ × ۱٪ × ۶/۱۲ = ۱٫۸ میلیون ریال
صرفه‌جویی بالقوه = ۶ − ۱٫۸ = ۴٫۲ میلیون ریال
این ۴٫۲ میلیون ریال صرفه‌جویی تحقق‌یافته نیست.
برای تحقق آن باید شرایط کارمزد، تاریخ مؤثر اصلاحیه و سیاست استرداد یا تعدیل کارمزد بانک تأیید شود.
بسیاری از کارمزدهای پرداخت‌شده ممکن است قابل استرداد نباشند؛ AI نباید چنین منفعتی را بدون شاهد در صورت‌های مالی ثبت کند.
ابزار تضمین با ذخیره حسابداری یکسان نیست
برای حسابدار، سه مفهوم از هم جداست: حد اسمی تعهد بانکی، پیش‌بینی جریان نقد و سپرده محدودشده، و شناسایی یا افشای اثر حسابداری.
طبق توضیح رسمی IFRS درباره IAS 37، شناخت ذخیره زمانی مطرح است که شرایط مربوط به تعهد فعلی، خروج منابع و برآورد معتبر بررسی شود.
اما تمام تضمین‌ها زیر یک استاندارد حسابداری واحد قرار نمی‌گیرند.
بنیاد IFRS در توضیح سال ۲۰۲۵ درباره ضمانت‌های صادرشده تصریح می‌کند که طبقه‌بندی به محتوای قرارداد بستگی دارد و برخی از انواع ضمانت‌های مالی می‌توانند مشمول IFRS 9 باشند.
نکته مهم این است که ضمانت‌نامه‌ای که بانک به درخواست شرکت صادر می‌کند، با ضمانت مالی‌ای که خود شرکت برای بدهی شخص دیگری صادر می‌کند، دو قرارداد با طرف‌ها و آثار متفاوت‌اند.
نباید الزامات ثبت ضمانت صادرکننده را بدون بررسی به دفاتر متقاضی تضمین منتقل کرد.
این مقاله ثبت روزنامه یکسان یا الزام عمومی برای ابزارهای تضمین پیشنهاد نمی‌کند.
اثر هر مورد باید براساس قراردادهای بانک و ذی‌نفع، رویدادهای واقعی، استاندارد حسابداری شرکت و قوانین قابل اعمال ایران بررسی شود.
هشت کنترل نرم‌افزاری برای ماژول هوشمند تضامین
۱. شناسنامه یکتا برای هر ابزار
شماره سند، نوع تضمین، بانک صادرکننده، ذی‌نفع، متقاضی، ارز، مبلغ اسمی، تاریخ شروع و تاریخ انقضا ثبت شود.
۲. تعیین قواعد حاکم
متن تعهد و قواعد انتخاب‌شده مانند ISP98 یا URDG 758 در صورت شمول مشخص باشند. تطبیق خودکار دو نوع ابزار بدون بررسی ممنوع باشد.
۳. تفکیک پیشرفت پروژه و مبلغ مؤثر
درصد پیشرفت، صورت‌وضعیت و پیشنهاد کاهش در یک لایه بماند؛ مبلغ معتبر بانکی فقط از سند و رخداد واجد اثر تغییر کند.
۴. نسخه‌بندی اصلاحیه‌ها
درخواست کاهش، موافقت ذی‌نفع، صدور اصلاحیه، تأیید بانک و تاریخ مؤثر هر مرحله ثبت شوند.
سندی که صرفاً درخواست شده، مبنای کاهش قطعی نباشد.
۵. کنترل انقضا و ادعاهای باز
سررسید سند، قواعد ارائه مطالبه، تمدید و پایان تعهد مطابق مفاد سند بررسی شوند.
رسیدن یک تاریخ در تقویم پروژه کافی نیست.
۶. تطبیق وثیقه و نقد آزاد
سپرده محدودشده با مانده بانکی و شرایط آزادسازی تطبیق داده شود.
وجه هنوز آزاد نشده به نقد قابل استفاده اضافه نشود.
۷. محاسبه و کنترل کارمزد
قرارداد معتبر، مبنای مبلغ، دوره، تعدیل یا عدم تعدیل کارمزد و زمان اثر تغییر در موتور محاسبات قطعی نگهداری شوند.
۸. تأیید انسانی و ردپای حسابرسی
AI می‌تواند خلاصه کند کدام تضمین نیازمند اصلاح یا استعلام است.
اما صدور درخواست بانکی، تغییر مبلغ مؤثر در سیستم مرجع و آزادسازی وثیقه باید با مجوز مستند انجام شود.
شش آزمون پذیرش قبل از استقرار
آزمون اول: پروژه ۷۰ درصد پیش رفته ولی اصلاحیه بانکی ندارد.
سامانه باید ۱٬۲۰۰ میلیون ریال مبلغ معتبر و ۳۶۰ میلیون ریال پیشنهاد داخلی را جدا نشان دهد.
آزمون دوم: درخواست کاهش به ۳۶۰ صادر شده ولی شرایط حقوقی و بانکی لازم هنوز تکمیل نشده‌اند.
سامانه نباید مبلغ را قطعی کاهش دهد.
آزمون سوم: اصلاحیه مؤثر و معتبر دریافت شده است.
سامانه باید نسخه قبلی را حفظ و مبلغ جدید را از تاریخ صحیح نشان دهد.
آزمون چهارم: مبلغ ابزار کاهش پیدا کرده ولی سپرده بانکی هنوز مسدود است.
نقد آزاد نباید بر مبنای وثیقه فرضی کاهش‌یافته بیشتر گزارش شود.
آزمون پنجم: ابزار در وضعیت مطالبه، تمدید یا رسیدگی است و تاریخ پروژه گذشته است.
ابزار نباید بدون تحلیل قواعد، آن را آزادشده تلقی کند.
آزمون ششم: کارمزد دوره از قبل پرداخت شده و طبق قرارداد قابل استرداد نیست.
موتور نباید صرفه‌جویی بالقوه را درآمد یا وجه دریافتی گزارش کند.
معیار پذیرش شامل صحت وضعیت، منشأ هر مبلغ، تطبیق اسناد حقوقی، تاریخ مؤثر و امکان بازسازی تصمیم برای حسابرس و مدیر مالی است؛ نه فقط خوانابودن توضیح AI.
برنامه اجرای آزمایشی چهار هفته‌ای
هفته اول: فهرست تضامین و ابزارهای بانکی مجاز، شماره اسناد، قراردادها، بانک‌های مرتبط، وثیقه‌ها و مسئول بازبینی را گردآوری کنید.
هفته دوم: داده ساختگی برای صدور، درخواست کاهش، اصلاحیه، تمدید، مطالبه و آزادسازی بسازید. قواعد حقوقی هر گروه را با نظر متخصص مستند کنید.
هفته سوم: موتور محاسبات و کنترل وضعیت را مستقل از مدل زبانی اجرا کنید. AI فقط تطبیق متن قرارداد، پیشنهاد اسناد لازم و توضیح استثنا را انجام دهد.
هفته چهارم: داشبورد «مبلغ معتبر، مبلغ پیشنهادی، وضعیت اصلاح، وثیقه محدودشده، هزینه آتی و مسئول پیگیری» را راه‌اندازی آزمایشی کنید و نتایج را با مدارک مرجع تطبیق دهید.
فرصت نرم‌افزاری برای حسابداران برتر
پیشنهاد توسعه «رادار هوشمند ضمانت‌نامه و وثیقه قرارداد» است؛ ماژولی بین سیستم قرارداد و پروژه، خزانه‌داری، اسناد بانکی و گزارشگری مالی.
موتور قطعی باید مبلغ معتبر و تاریخ اثر، گردش اصلاحیه، وثیقه‌های محدودشده و شرایط کارمزد را با داده نسخه‌دار مدیریت کند.
لایه AI می‌تواند بندهای مربوط را از متن مجاز استخراج کند، اختلاف پیشرفت و وضعیت بانکی را توضیح دهد و برای استعلام یا آزادسازی پرونده آماده سازد.
برای بازار ایران، تقویم شمسی، ریال و تومان، چندشرکتی‌بودن، انواع ضمانت‌نامه بانکی، مرجع اصالت‌سنجی رسمی، سطوح اختیار امضا و مقررات جاری بانک مرکزی باید با متن معتبر روز و نظر متخصص بررسی و در محصول تعبیه شوند.
این پیشنهاد محصول است؛ نه ادعای وجود قابلیت در نرم‌افزارهای فعلی مجموعه یا سازگاری StandbyX با بانک‌های ایرانی.
جمع‌بندی: ضمانت از مسیر بانک کاهش می‌یابد، نه از یک درصد پیشرفت
در مثال آموزشی، پروژه ۷۰ درصد پیشرفت داشت و محاسبه داخلی مانده فرضی تضمین را ۳۶۰ میلیون ریال نشان می‌داد.
اما تا زمان احراز رخداد یا اصلاحیه مؤثر، مبلغ اسمی معتبر سند بانکی همچنان ۱٬۲۰۰ میلیون ریال بود.
اختلاف ۸۴۰ میلیون ریالی نه پرداخت قطعی بود، نه زیان و نه بدهی شناسایی‌شده؛ بلکه یک مغایرت وضعیت حقوقی و عملیاتی بود که باید مستند حل شود.
همچنین ۲۴۰ میلیون ریال وثیقه محدودشده با مبلغ اسمی تضمین متفاوت بود و آزادسازی احتمالی ۱۶۸ میلیون ریال از آن، بدون تأیید بانک وارد نقد آزاد نمی‌شد.
زنجیره قابل دفاع:
قرارداد و پیشرفت تأییدشده ← سند معتبر تضمین ← شرایط حقوقی کاهش یا انقضا ← اصلاحیه یا آزادسازی مؤثر ← تطبیق وثیقه و کارمزد ← گزارش مالی و تأیید انسانی.
هوش مصنوعی بررسی و کمک می‌کند؛ حسابدار، خزانه‌دار و متخصص حقوقی کنترل و قضاوت می‌کنند.
برای مطالعه راهکارهای هوشمند حسابداری و مالی و عضویت در مجموعه، به سایت حسابداران برتر مراجعه کنید:
برای مطالعه منابع تخصصی و راهکارهای هوشمند مالی، از بخش عضویت حسابداران برتر استفاده کنید.
برای دریافت مطالب کاربردی حسابداری، مدیریت مالی و ابزارهای هوشمند به جمع مخاطبان حسابداران برتر بپیوندید.