تقلب باید قبل از خروج پول متوقف شود
فرض کنید یک شرکت روزانه صدها فاکتور از فروشندگان مختلف دریافت می‌کند. یکی از فاکتورها کاملاً عادی به نظر می‌رسد؛ نام فروشنده درست است، مبلغ از سقف تأیید مدیر پایین‌تر است و اطلاعات بانکی نیز داخل سیستم ثبت شده است. اما وقتی فروشنده تازه ایجاد شده، حساب بانکی او به‌تازگی تغییر کرده و چند فاکتور مشابه نیز طی چند روز ثبت شده‌اند، ترکیب این نشانه‌ها می‌تواند سؤال مهمی ایجاد کند: آیا کسی عمداً پرداخت‌ها را طوری طراحی کرده که از کنترل‌های شرکت عبور کنند؟ اینجا هوش مصنوعی می‌تواند پیش از خروج وجه، ریسک را شناسایی و پرداخت را برای بررسی انسانی متوقف کند.
فروشنده صوری چگونه شکل می‌گیرد؟
در بسیاری از سیستم‌های سنتی، تقلب زمانی کشف می‌شود که پول از شرکت خارج شده است. حسابرس داخلی تراکنش را بررسی می‌کند، مغایرتی پیدا می‌شود و سپس تحقیقات آغاز می‌شود. در Accounts Payable هدف مؤثرتر، Preventive Fraud Detection است؛ یعنی سیستم قبل از آزادشدن وجه بگوید این پرداخت نیازمند بررسی انسانی است. تفاوت این دو رویکرد، تفاوت میان کشف زیان و جلوگیری از زیان است.
هوش مصنوعی چه داده‌هایی را کنار هم می‌گذارد؟
یکی از سناریوهای کلاسیک، ایجاد Ghost Vendor یا فروشنده صوری است. فردی که به Vendor Master دسترسی دارد می‌تواند فروشنده جدیدی با نام حرفه‌ای ایجاد کند، اطلاعات بانکی وارد کند و سپس برای خدماتی که واقعاً ارائه نشده‌اند فاکتور ثبت کند. اگر مسیر تأیید نیز دور زده شود، هر تراکنش ممکن است به‌تنهایی عادی به نظر برسد. قدرت Analytics زمانی آشکار می‌شود که رابطه میان فروشنده، فاکتور، تأییدکننده و حساب بانکی در کنار هم دیده شود.
تغییر ناگهانی حساب بانکی فروشنده
یک سیستم هوشمند می‌تواند Vendor Master را با تاریخچه تراکنش‌ها ترکیب کند و بپرسد فروشنده چه زمانی ایجاد شده، چه کسی آن را ساخته، اولین فاکتور چند روز بعد ثبت شده، اطلاعات بانکی چند بار تغییر کرده، آدرس و اطلاعات تماس چه الگویی دارند، آیا با فروشنده دیگری مشترک‌اند و چه کسی معمولاً فاکتورهای او را تأیید می‌کند. وقتی این اطلاعات کنار یکدیگر قرار می‌گیرند، الگوهایی آشکار می‌شوند که با بررسی یک فاکتور به‌تنهایی قابل مشاهده نیستند.
تأیید مستقل تغییر اطلاعات بانکی
یکی از حساس‌ترین تغییرات در Vendor Master، تغییر اطلاعات بانکی است. فرض کنید شرکتی پنج سال با یک تأمین‌کننده کار کرده و ناگهان شماره حساب او تغییر می‌کند و دو روز بعد یک پرداخت بزرگ در صف قرار می‌گیرد. این تغییر می‌تواند کاملاً قانونی باشد، اما ترکیب Bank Account Change، High-value Payment و Short Time Interval ارزش بررسی زیادی دارد. سیستم می‌تواند چنین پرداختی را برای Verification مستقل علامت‌گذاری کند.
کشف فاکتور تکراری و شبه‌تکراری
اگر درخواست تغییر حساب بانکی از طریق ایمیل دریافت شده باشد، پاسخ‌دادن به همان ایمیل برای تأیید تغییر الزاماً کنترل مؤثری نیست؛ زیرا ممکن است خود حساب ایمیل فروشنده Compromise شده باشد. کنترل قوی‌تر می‌تواند شامل تماس با فروشنده از طریق اطلاعاتی باشد که از قبل در Vendor Master معتبر ثبت شده است. AI Trigger را ایجاد می‌کند، اما Verification نهایی در پرداخت‌های حساس باید از کانال مستقلی انجام شود.
تقسیم فاکتور برای دورزدن سقف تأیید
Duplicate Invoice یکی از مشکلات کلاسیک Accounts Payable است. کنترل ساده فقط شماره فاکتور تکراری را پیدا می‌کند، اما متقلب می‌تواند شماره را کمی تغییر دهد. سیستم پیشرفته‌تر می‌تواند شباهت میان Vendor، Amount، Date، Description، Purchase Order و Invoice Number را بررسی کند و Near-Duplicateهایی را نیز که دقیقاً یکسان نیستند برای بررسی پیدا کند.
فروشنده تازه‌ساخته‌شده و پرداخت سریع
اگر سیاست شرکت بگوید پرداخت‌های بالاتر از ۵۰۰ میلیون تومان نیازمند تأیید مدیر ارشد هستند، تقسیم یک فاکتور ۵۸۰ میلیونی به دو فاکتور ۲۹۰ میلیونی می‌تواند راهی برای دورزدن سقف تأیید باشد. Analytics می‌تواند تمام فاکتورهای یک فروشنده را در یک Window زمانی بررسی و شباهت شرح، PO، Cost Center، درخواست‌کننده و Approver را تحلیل کند. اگر چند فاکتور دائماً درست زیر آستانه مجاز قرار گیرند، Risk Score افزایش می‌یابد.
چند فروشنده با یک حساب بانکی
Vendor Age نیز می‌تواند یکی از Featureهای Risk Scoring باشد. فروشنده‌ای که امروز ایجاد شده و چند روز بعد اولین پرداخت بزرگ خود را دریافت می‌کند الزاماً متقلب نیست؛ ممکن است خرید اضطراری رخ داده باشد. اما وقتی سن کم فروشنده با مبلغ بالا، نبود PO و حساب بانکی جدید ترکیب شود، سطح ریسک تغییر می‌کند.
رابطه احتمالی کارمند و فروشنده
اگر چند Vendor با نام‌های متفاوت یک شماره حساب بانکی، شماره تماس، آدرس، ایمیل یا Tax ID مشابه داشته باشند، موضوع نیازمند بررسی است. اینجا Entity Resolution اهمیت پیدا می‌کند؛ سیستم تلاش می‌کند بفهمد چند رکورد ظاهراً متفاوت در واقع به یک موجودیت یا شبکه مرتبط‌اند. این قابلیت می‌تواند حلقه‌های فروشنده صوری یا ارتباطات پنهان را بهتر آشکار کند.
فاکتور بدون سفارش خرید
تحلیل شبکه می‌تواند روابط غیرمعمول میان Employee، Vendor، Invoice، Approver و Bank Account را نشان دهد. شباهت آدرس یا شماره تماس، الگوی تأییدکننده مشترک یا تمرکز غیرعادی فاکتورها روی یک کارمند می‌تواند سیگنال ریسک باشد. هیچ‌کدام به‌تنهایی اثبات تبانی نیستند، اما در کنار سایر نشانه‌ها ارزش بررسی بیشتری پیدا می‌کنند.
تغییر غیرعادی الگوی مبلغ
در سازمان‌هایی که سیاست No PO, No Pay دارند، Invoice بدون Purchase Order می‌تواند Exception باشد. بااین‌حال همه استثناها یکسان نیستند؛ ممکن است برخی خدمات طبق سیاست شرکت نیازی به PO نداشته باشند. AI باید Context را در نظر بگیرد. فاکتور بدون PO از یک Vendor قدیمی برای خدمت مجاز شاید عادی باشد، اما همان فاکتور از Vendor جدید، با مبلغ بالا و تأییدکننده غیرمعمول می‌تواند Risk Score بالاتری داشته باشد.
متن فاکتور هم یک منبع داده است
مبلغ باید در زمینه همان فروشنده تحلیل شود. اگر تأمین‌کننده‌ای معمولاً ماهانه بین ۱۰۰ تا ۱۵۰ میلیون تومان صورتحساب صادر می‌کند و ناگهان مبلغ به ۱٫۸ میلیارد تومان می‌رسد، سیستم می‌تواند این جهش را به‌عنوان Vendor-specific Anomaly علامت‌گذاری کند. ممکن است مبلغ یک میلیارد برای Vendor A عادی و مبلغ ۲۰۰ میلیون برای Vendor B کاملاً غیرعادی باشد.
تطبیق سه‌طرفه هوشمند
متن فاکتور نیز داده است. شرح‌های بسیار کلی مانند «خدمات مشاوره»، «هزینه پروژه» یا «طبق توافق» برای مبالغ بزرگ می‌توانند نیازمند بررسی باشند. مدل زبانی می‌تواند متن Invoice، قرارداد و PO را مقایسه و ناسازگاری‌های احتمالی را برای Review مشخص کند. اما تحلیل متن نباید به‌تنهایی مبنای نتیجه‌گیری باشد.
امتیاز ریسک قبل از پرداخت
یکی از کنترل‌های مهم خرید، تطبیق سه‌طرفه Purchase Order، Goods Receipt و Invoice است: چه چیزی سفارش داده شد، چه چیزی تحویل گرفته شد و فروشنده بابت چه چیزی فاکتور صادر کرده است. سیستم‌های سنتی این تطبیق را با قواعد مشخص انجام می‌دهند و AI می‌تواند در موارد پیچیده‌تر مانند اختلاف شرح، واحد اندازه‌گیری یا اسناد غیرساختاریافته به شناسایی استثنا کمک کند. Matchهای قطعی همچنان باید با منطق Deterministic انجام شوند.
حضور انسان در حلقه تصمیم
تصور کنید فاکتوری از Vendor جدید باشد، حساب بانکی آن سه روز قبل تغییر کرده، مبلغ درست زیر Approval Limit است، PO ندارد، شرح بسیار کلی است و Approver معمول نیز فرد دیگری است. هر عامل به‌تنهایی شاید توضیح قانونی داشته باشد، اما ترکیب آن‌ها می‌تواند پرداخت را در دسته High Risk قرار دهد. بهترین اقدام AI این نیست که بگوید «این تقلب است»، بلکه باید بگوید «پرداخت را متوقف کن و برای بررسی انسانی ارسال کن.»
هشدار زیاد، کنترل خوب نیست
هرچه تصمیم به خروج پول نزدیک‌تر باشد، Human-in-the-loop اهمیت بیشتری پیدا می‌کند. معماری مناسب می‌تواند چنین باشد: Invoice دریافت می‌شود، اطلاعات استخراج می‌شوند، کنترل‌های Rule-based اجرا می‌شوند، AI الگوهای غیرعادی را بررسی می‌کند، Risk Score تولید می‌شود، موارد پرریسک Hold می‌شوند و سپس حسابدار یا Controller مدارک را بررسی می‌کند. اگر سیستم هر روز صدها هشدار کاذب ایجاد کند، Alert Fatigue رخ می‌دهد؛ بنابراین Threshold باید با اهمیت مبلغ و زمینه کسب‌وکار تنظیم شود.
تفکیک وظایف برای Agent هم الزامی است
اصل Segregation of Duties با آمدن AI از بین نمی‌رود. Agent نباید هم بتواند Vendor Master را تغییر دهد و هم همان پرداخت را تأیید یا آزاد کند. هر عامل باید مانند یک User سیستمی Role، Permission و محدودیت مشخص داشته باشد. همچنین تغییر اطلاعات Vendor Master، ایجاد Invoice و Release Payment نباید در یک اختیار نامحدود جمع شوند. AI می‌تواند تضادهای دسترسی را شناسایی کند، اما جایگزین طراحی صحیح کنترل داخلی نیست.
پایش مستمر پرداخت‌ها
مرحله بعدی این فناوری، Continuous Controls Monitoring است. برخی Risk Indicatorها می‌توانند پیش از پرداخت و به‌صورت مداوم اجرا شوند. Ruleها، مدل‌ها و Thresholdها نیز باید با Incidentهای جدید و تغییر رفتار کسب‌وکار به‌روزرسانی شوند. آینده Fraud Detection فقط پیدا کردن تقلب پس از وقوع نیست؛ هدف مهم‌تر این است که سیستم پیش از خروج پول بپرسد: «آیا مطمئن هستیم باید این پرداخت انجام شود؟» در این مدل، نقش حسابدار از ثبت صرف فاکتور به Review حرفه‌ای، Vendor Verification و Escalation موارد پرریسک گسترش پیدا می‌کند.
سؤالات متداول
فروشنده صوری چیست؟
فروشنده صوری یا Ghost Vendor رکورد فروشنده‌ای است که ممکن است برای ایجاد پرداخت‌های غیرمجاز یا متقلبانه استفاده شود. وجود Vendor جدید به‌تنهایی به معنای صوری بودن آن نیست و نیاز به بررسی شواهد دارد.
AI چگونه فاکتور تکراری را تشخیص می‌دهد؟
علاوه بر شماره فاکتور، سیستم می‌تواند مبلغ، تاریخ، Vendor، PO و سایر ویژگی‌ها را مقایسه کند تا Near-Duplicateهایی را که دقیقاً یکسان نیستند نیز برای بررسی پیدا کند.
Invoice Splitting چیست؟
تقسیم یک خرید یا صورتحساب به چند تراکنش کوچک‌تر، به‌خصوص زمانی که هدف آن دورزدن Approval Threshold یا سایر کنترل‌ها باشد، Invoice Splitting نامیده می‌شود.
آیا تغییر شماره حساب فروشنده باید پرداخت را متوقف کند؟
تغییر حساب بانکی الزاماً نشانه تقلب نیست، اما در پرداخت‌های حساس می‌تواند Trigger مناسبی برای Verification مستقل باشد؛ مخصوصاً اگر درست قبل از یک پرداخت بزرگ انجام شده باشد.
آیا AI باید اجازه تأیید نهایی پرداخت داشته باشد؟
در فرایندهای حساس مالی، سطح اختیار Agent باید براساس ریسک، تفکیک وظایف و سیاست سازمان تعیین شود. تغییر Vendor Master، تأیید Invoice و Release Payment نباید بدون طراحی کنترل مناسب در یک اختیار نامحدود جمع شوند.
عضویت در حسابداران برتر
برای دسترسی به آموزش‌های تخصصی حسابداری، حسابرسی، کنترل داخلی و هوش مصنوعی، وارد بخش عضویت در حسابداران برتر شوید.