مقدمه: دسترسی به پورتال، مجوز پرداخت تمام فاکتورها نیست
حسابدار دو فاکتور یک فروشنده را بررسی و پرداخت مجموع ۵۴۰ میلیون ریال را تأیید کرده است. عامل هوش مصنوعی برای تکمیل ورود اطلاعات وارد پورتال فروشنده می‌شود؛ اما دکمه «تسویه همه» سه فاکتور به جمع ۶۱۰ میلیون ریال را نشان می‌دهد.
فاکتور سوم شاید بدهی واقعی باشد، ولی در این نوبت مجوز پرداخت ندارد. هویت معتبر عامل نشان می‌دهد چه موجودیتی وارد درگاه شده است؛ دامنه دستور خریدار تعیین می‌کند کدام شناسه فاکتور، مبلغ، ارز و ذی‌نفع مجازند. عامل نباید صرفاً برای سرعت‌دادن به کار روی «تسویه همه» کلیک کند.
خبر ۲۰ اکتبر ۲۰۲۶: پایلوت Visa، BILL و Billtrust چه می‌گوید؟
در ۲۰ اکتبر ۲۰۲۶ سه شرکت Visa، BILL و Billtrust راه‌اندازی یک پایلوت عملیاتی برای پرداخت فاکتورهای ازپیش‌تأییدشده خریدار از طریق پورتال فروشنده را اعلام کردند. در این جریان، عامل BILL با پروتکل Visa Trusted Agent و اعتبار پرداخت توکنی‌شده شناسایی می‌شود و Billtrust در سمت پذیرنده امکان احراز هویت و اجرای پرداخت در مسیر مصوب را فراهم می‌کند.
طبق اطلاعیه شرکت‌ها، عامل اجازه ندارد درباره اصل تصویب فاکتور تصمیم جدید بگیرد؛ فقط پرداخت واجد شرایطی را اجرا می‌کند که خریدار قبلاً پذیرفته است. پایلوت با مشارکت‌کنندگان منتخب در محیط زنده اجرا می‌شود و استفاده مستقیم از آن در شبکه بانکی ایران ادعا نشده است. خبر رسمی Visa
مثال عددی: سه فاکتور در پورتال، فقط دو مجوز پرداخت
تمام ارقام و شناسه‌های این بخش ساختگی و آموزشی هستند و واحد ارقام میلیون ریال است. وضعیت فاکتورها به‌جای یک جدول عریض، در کارت‌های مجزا نمایش داده شده تا روی موبایل کامل خوانده شوند.
جمع مجاز = ۳۰۰ + ۲۴۰ = ۵۴۰ میلیون ریال. جمع موجود در پورتال ۶۱۰ میلیون ریال و اختلاف ۷۰ میلیون ریال است؛ یعنی انتخاب همه فاکتورها ۱۲٫۹۶٪ بیش از مبلغ مصوب این نوبت خواهد بود.
این ۷۰ میلیون ریال لزوماً فاکتور جعلی یا اضافه‌پرداخت قطعی نیست. اگر درگاه اجازه انتخاب ردیف‌ها را می‌دهد، عامل فقط دو فاکتور مصوب را انتخاب کند؛ در غیر این صورت عملیات را متوقف و برای بازبین انسانی ثبت کند.
آزمون کارمزد: حتی پرداخت ۵۴۰ میلیونی ممکن است خارج از سقف باشد
در سناریویی مستقل فرض کنید هنگام پرداخت کارتی ۲٪ کارمزد بر عهده خریدار قرار گیرد. این فرض آموزشی به پایلوت واقعی Visa نسبت داده نمی‌شود. مبلغ کارمزد ۱۰٫۸ میلیون ریال و کل برداشت ۵۵۰٫۸ میلیون ریال خواهد بود: ۵۴۰ × ۲٪ = ۱۰٫۸ و ۵۴۰ + ۱۰٫۸ = ۵۵۰٫۸.
اگر مجوز فقط برای برداشت ۵۴۰ میلیون ریال صادر شده باشد، عامل نباید کارمزد اضافه را خودکار بپذیرد. نرم‌افزار باید «مبلغ تسویه بدهی فروشنده» و «حداکثر وجه مجاز برای برداشت از خریدار» را دو کنترل مستقل بداند.
احراز هویت عامل با اختیار خرج‌کردن متفاوت است
پروتکل‌های شناسایی عامل کمک می‌کنند پورتال بداند درخواست از عامل معتبر آمده و پیام دستکاری نشده است؛ اما معتبر بودن عامل، تأیید هر تراکنش نیست. بسته دستور پرداخت باید شامل خریدار، فروشنده، شناسه فاکتور، مبلغ هر ردیف، ارز، سقف کل برداشت، ابزار پرداخت و مهلت اعتبار باشد.
اگر فروشنده، رقم نهایی، شناسه فاکتور یا هزینه جدید نسبت به دستور مصوب تغییر کرد، تأیید قبلی برای عملیات تغییریافته کافی نیست و عامل باید طبق سیاست سازمان توقف یا ارجاع دهد.
پیام «درخواست دریافت شد» به معنی تسویه قطعی نیست
فرایند پرداخت می‌تواند مراحل دستور مصوب، ارسال درخواست، پذیرش پورتال، مجوز شبکه پرداخت، قطعی‌شدن یا برگشت عملیات و تطبیق در دفاتر را طی کند. یک پیام موفقیت ظاهری در صفحه، به‌تنهایی وقوع همه این مراحل را اثبات نمی‌کند.
کاهش حساب پرداختنی و ثبت خروج وجه باید براساس شواهد بانکی و مبنای حسابداری قابل اعمال انجام شود. شماره مرجع، تاریخ و وضعیت هر مرحله برای حسابرسی داخلی حفظ شوند.
قطع اتصال و خطر پرداخت دوباره
اگر عامل پس از ارسال دستور ۵۴۰ میلیونی پاسخ قطعی دریافت نکرد، نباید فوراً دوباره پرداخت کند. ابتدا باید نتیجه تلاش قبلی از مسیر معتبر استعلام شود. کلید عدم‌تکرار یا Idempotency در بعضی رابط‌های پرداخت از اجرای ناخواسته دو عملیات در تلاش مجدد جلوگیری می‌کند؛ مستندات Stripe یک نمونه فنی روشن است.
این قابلیت فقط وقتی قابل اتکاست که سامانه پرداخت مقصد واقعاً از آن پشتیبانی کند. اگر وضعیت نامعلوم مانده، عبارت درست «نیازمند استعلام» است، نه «شکست قطعی».
چرا تطبیق پرداخت در سمت فروشنده هم ضروری است؟
فرض کنید ۵۴۰ میلیون ریال پرداخت شده اما فروشنده آن را صرفاً با عنوان «دریافت از مشتری» ثبت کند؛ در این حالت ممکن است وجه به فاکتور نادرست تخصیص داده شود. اطلاعات همراه پرداخت باید در حد مجاز و ضروری، شناسه خریدار، A-501 و A-502، مبلغ تخصیص‌یافته هر کدام و مرجع تراکنش را همراه داشته باشد.
پرداخت موفق سه شرط دارد: انطباق با دستور خریدار، نتیجه معتبر مسیر پرداخت و تخصیص صحیح در حساب‌های دریافتنی فروشنده. سبزشدن یک علامت در پورتال کافی نیست.
هشت کنترل نرم‌افزاری ضروری برای عامل پرداخت
- بسته دستور نسخه‌دار: مجوز روی فاکتورها، مبالغ و ذی‌نفع مشخص صادر شود، نه دستور کلی «تسویه تأمین‌کننده».
- هویت مستقل عامل: ورود با اعتبارنامه توکنی‌شده یا امضای قابل بررسی، بدون اشتراک‌گذاری پیش‌فرض رمز پورتال.
- تطبیق نهایی ردیف‌ها: هر ردیف و جمع پورتال پیش از پرداخت با دستور تأییدشده مقایسه شود.
- کنترل کارمزد و سقف برداشت: مبلغ بدهی و کل وجه برداشت‌شده جدا کنترل شوند.
- عدم‌تکرار پرداخت: شناسه دستور، تلاش پرداخت و مرجع درگاه نگهداری شود و تلاش مجدد ایمن باشد.
- ثبت وضعیت واقعی: درخواست، پذیرش، پردازش، برگشت و تسویه تفکیک شوند.
- تخصیص دوطرفه: پرداخت خریدار با فاکتورهای تسویه‌شده در سیستم فروشنده تطبیق شود.
- توقف و بازبینی انسانی: تغییر ذی‌نفع، دستور منقضی یا نتیجه نامعلوم مانع اجرای خودکار شود.
شش آزمون پذیرش پیش از اتصال به پرداخت واقعی
- نمایش جمع ۶۱۰ در پورتال با وجود مجوز ۵۴۰؛ «تسویه همه» باید رد شود.
- اضافه‌شدن کارمزد ۱۰٫۸ و نبود اختیار برداشت بیش از ۵۴۰؛ عملیات باید متوقف شود.
- تفاوت شناسه حقوقی فروشنده با پرونده مصوب؛ شباهت اسم کافی نیست.
- قطع ارتباط پس از ارسال دستور؛ تلاش مجدد نباید برداشت دوم بسازد.
- پیام «درخواست دریافت شد» بدون تأیید نتیجه نهایی؛ ثبت تسویه قطعی ممنوع است.
- دریافت ۵۴۰ در سمت فروشنده با تخصیص به شناسه فاکتور اشتباه؛ مغایرت باید کشف شود.
خروجی مرجع آزمون را پیش از اجرای AI حسابدار و مسئول امنیت یا خزانه‌داری تصویب کنند. سرعت بیشتر تنها در کنار رعایت اختیار و قابلیت بازسازی تصمیم ارزشمند است.
برنامه آزمایشی چهار هفته‌ای
- هفته اول: فاکتورهای مصوب، پورتال‌ها و دامنه دسترسی عامل را مستندسازی کنید.
- هفته دوم: اتصال آزمایشی بدون انتقال وجه، با داده ساختگی و کنترل قطعی شناسه و مبلغ بسازید.
- هفته سوم: تغییر ردیف، کارمزد، ذی‌نفع، قطع اتصال و پرداخت تکراری را آزمایش کنید.
- هفته چهارم: وضعیت خریدار، درگاه و تخصیص فروشنده را در یک کاربرگ یکپارچه تطبیق دهید.
پیش از اتصال به پرداخت واقعی، بررسی حقوقی، امنیتی، بانکی و مجوزهای سازمانی لازم است.
فرصت توسعه محصول برای حسابداران برتر
پیشنهاد توسعه «دروازه کنترل پرداخت عامل‌های هوشمند بین ERP و پورتال تأمین‌کننده» است؛ ماژولی که بسته دستور نسخه‌دار، انتخاب فاکتور، سقف برداشت، عدم‌تکرار، وضعیت پرداخت و تخصیص دوطرفه را کنترل می‌کند. AI می‌تواند اختلاف‌ها را شرح دهد، اما تصویب پرداخت و انتقال وجه بدون اختیار مستقل انجام نمی‌شود.
برای کاربرد در ایران، پشتیبانی از ریال و تومان، تقویم شمسی، شناسه ملی فروشنده، چندشرکتی‌بودن، سطوح امضا و فقط مسیرهای بانکی مجاز لازم است. این پیشنهاد محصول است، نه ادعای وجود آن در نرم‌افزارهای فعلی برند یا قابلیت استفاده مستقیم از پایلوت خارجی.
جمع‌بندی: عامل مجاز می‌تواند با پرداخت غیرمجاز مواجه شود
فاکتورهای ۵۴۰ میلیون ریالی مصوب‌اند، ولی پورتال ۶۱۰ میلیون ریال نشان می‌دهد. اختلاف ۷۰ میلیون ریال ممکن است بدهی واقعی باشد اما مجوز پرداخت این نوبت را ندارد. حتی پرداخت همان دو فاکتور، در صورت کارمزد بدون مجوز، می‌تواند سقف برداشت را نقض کند.
مسیر دفاع‌پذیر چنین است: تأیید فاکتور ← دستور محدود ← احراز هویت عامل ← تطبیق ردیف و مبلغ ← کنترل کارمزد و سقف ← پرداخت تکرارایمن ← تأیید وضعیت ← تطبیق دوطرفه. هوش مصنوعی باید کار دستی را کم کند، نه مرز اختیار مالی را.