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