مقدمه: جمع رسیدها ۱۸۰ است، اما طلب کارمند ۱۸۰ نیست
کارمندی پس از انجام مأموریت و خریدهای مجاز شرکت، مجموعه‌ای از رسیدهای هزینه را با ارزش اسمی ۱۸۰ میلیون ریال در سامانه بارگذاری می‌کند. دستیار هوش مصنوعی نام فروشنده، تاریخ و مبلغ همه تصاویر را می‌خواند و با یک دکمه پیشنهاد می‌دهد: «۱۸۰ میلیون ریال هزینه مأموریت ثبت و همان مبلغ برای کارمند پرداخت شود.» در ظاهر، جمع فایل‌ها درست و سرعت پردازش بالا است. اما رسیدِ اسکن‌شده به‌تنهایی به معنی طلب کارمند از شرکت نیست.
از مجموع رسیدها، تنها ۱۲۶ میلیون ریال مخارجی است که واقعاً با پول شخصی کارمند پرداخت شده، با مأموریت مربوط است و طبق مفروضات شرکت به تأیید بازپرداخت رسیده است. ۲۴ میلیون ریال خرید با کارت سازمانی انجام شده و شرکت بدهی یا پرداخت آن را از مسیر کارت مدیریت می‌کند. ۲۰ میلیون ریال مربوط به خرید شخصی و خارج از دامنه مصوب مأموریت است. برای ۱۰ میلیون ریال دیگر هنوز مدرک یا تأیید کافی وجود ندارد و پرونده باز است.
تازه این پایان محاسبه نیست. شرکت پیش از مأموریت ۷۰ میلیون ریال مساعده نقدی به همان کارمند پرداخت کرده و این مبلغ در حساب پیش‌پرداخت/مطالبات از کارکنان ثبت شده است. پس در فرض اینکه مساعده دقیقاً قابل تسویه با همین هزینه‌ها است، فقط ۵۶ میلیون ریال دیگر باید به کارمند پرداخت شود:
۱۲۶ − ۷۰ = ۵۶ میلیون ریال.
اگر سیستم ۱۸۰ را پرداخت کند، ۱۲۴ میلیون ریال بیش از مانده قابل پرداخت در این پرونده وجه خارج می‌شود. این تفاوت، ریسک فرضی تصمیم پرداخت است؛ نه زیان تحقق‌یافته یا ادعای تخلف کارمند. نکته مقاله این است که استخراج درست مبلغ رسید با محاسبه درست مانده تسویه کارمند یکسان نیست.
رویداد تازه ۳ نوامبر ۲۰۲۶: عامل AI برای خواندن رسیدهای مخارج
شرکت Coupa در اطلاعیه ۳ نوامبر ۲۰۲۶ درباره رشد راهکارهای Invoice-to-Pay و عامل‌های هوش مصنوعی مالی خود، از عملکرد Expense Receipt Parsing Agent نام برده است. طبق اعلام سازنده، یکی از مشتریان بزرگ در صنعت بیمه در کمتر از سه ماه حدود ۵۰٬۷۰۰ رسید را پردازش کرده و شرکت آن را معادل صرفه‌جویی ۲۱۱ روز کاری برای کاربران خود گزارش می‌کند. Coupa در همان اطلاعیه از عامل ساخت دسته‌های پرداخت فاکتور و توسعه گردش‌کارهای حساب‌های پرداختنی نیز سخن گفته است.
این اعداد گزارش عملکرد اعلام‌شده از سوی تولیدکننده هستند؛ ممیزی مستقل میزان صرفه‌جویی یا اثبات اینکه تمام ۵۰٬۷۰۰ رسید از نظر سیاست، مالیات و حسابداری صحیح بوده‌اند نیستند. همچنین «پردازش و خواندن رسید» را نباید به معنی «تأیید خودکار ماهیت هزینه» یا «مجوز صدور پرداخت به کارمند» دانست. مثال ۱۸۰ میلیونی حاضر کاملاً فرضی است و خطایی را به Coupa نسبت نمی‌دهد.
برای شرکت‌های ایرانی، پیام فناوری این است: پس از OCR یا خواندن تصویر، سامانه باید پرداخت‌کننده واقعی، مأموریت، مجوز، پیش‌پرداخت قبلی، وضعیت تسویه کارت و اسناد مالیاتی را نیز بررسی کند. در غیر این صورت شاید هزاران فایل سریع‌تر خوانده شوند، اما مانده قابل پرداخت همچنان اشتباه باشد.
چرا جمع رسیدها با مبلغ قابل بازپرداخت فرق می‌کند؟
هر سند هزینه حداقل چهار پرسش دارد: چه کالایی یا خدمتی دریافت شده؟ چه کسی آن را پرداخت کرده؟ آیا مخارج برای کار شرکت و مطابق مجوز بوده؟ آیا قبلاً بابت همان رویداد وجهی به شخص پرداخت شده است؟
دو رسید هم‌مبلغ ممکن است کاملاً معتبر و مستقل باشند؛ یک فاکتور نیز ممکن است با دو ابزار پرداخت تسویه شده باشد. بنابراین مبلغ و نام فروشگاه، به‌تنهایی برای تعیین طلب کارمند کافی نیست. رسید کارت سازمانی معمولاً نشان‌دهنده رویدادی است که باید در مسیر کارت/ارائه‌دهنده کارت و دفتر کل کنترل شود، نه اینکه همان وجه بار دوم به کارمند بازپرداخت شود.
همچنین یک خرید شخصی می‌تواند در بسته اسناد مأموریت ظاهر شود، بدون اینکه شرکت متعهد به جبران آن باشد. از سوی دیگر، نبود تصویر رسید همیشه اثبات نمی‌کند هیچ هزینه‌ای در شرکت واقع نشده است؛ ممکن است کالا یا خدمت دریافت شده باشد و شناسایی حسابداری آن نیازمند بررسی مستقل باشد، در حالی که بازپرداخت به کارمند تا تکمیل مدارک یا مجوز متوقف می‌ماند.
مثال عددی: پنج عدد که باید به یکدیگر متصل شوند
تمام اعداد، کارکنان و پرداخت‌ها فرضی‌اند؛ واحد جدول میلیون ریالاست. فرض می‌کنیم مبالغ فاقد مالیات و عوارض تفکیکی هستند، هیچ ارز خارجی و هزینه سرمایه‌ای وجود ندارد، تمام مخارج تأییدشده مربوط به هزینه جاری همین دوره هستند، و مساعده قبلی ۷۰ میلیونی به همین مأموریت تخصیص یافته است. بازپرداخت شخصیِ واقعی با مدارک بانکی تأیید شده و اقلام کارت سازمانی نیز در زیرسیستم آن کارت جدا کنترل می‌شوند.
| گروه رسید | مبلغ | وضعیت | اثر بر بازپرداخت به کارمند |
|---|---|---|---|
| مخارج کاریِ پرداخت‌شده از جیب کارمند و تأییدشده | ۱۲۶ | قابل بازپرداخت | ۱۲۶+ |
| مخارج کاری پرداخت‌شده با کارت سازمانی | ۲۴ | در مسیر کارت و حسابداری شرکت | صفر |
| مخارج شخصی خارج از دامنه توافق و سیاست | ۲۰ | در این مثال غیرقابل بازپرداخت | صفر |
| اقلام در انتظار بررسی سند، مصرف یا مجوز | ۱۰ | تصمیم معلق | فعلاً صفر |
| جمع ارزش اسمی رسیدهای بارگذاری‌شده | ۱۸۰ | — | ۱۲۶ قابل بازپرداخت تأییدشده |
| مساعده قبلی کارمند برای همین مأموریت | ۷۰ | قبلاً پرداخت و هنوز تسویه‌نشده | ۷۰− |
| مانده قابل پرداخت فعلی به کارمند | — | پس از تهاتر/تخصیص معتبر مساعده | ۵۶ |
۱۲۶ + ۲۴ + ۲۰ + ۱۰ = ۱۸۰، اما ۱۸۰ − ۱۲۴ = ۵۶ مانده بازپرداخت است. این ۱۲۴ میلیون از ۵۴ میلیون رسیدِ غیروارد در بازپرداخت فعلی (۲۴ کارت + ۲۰ شخصی + ۱۰ معلق) و ۷۰ میلیون مساعده قبلی تشکیل می‌شود. این دو گروه، از نظر حسابداری هم‌جنس نیستند: ۵۴ میلیون بخشی از مبلغ ادعایی است که فعلاً در طلب کارمند وارد نشده؛ ۷۰ میلیون وجهی است که کارمند قبلاً دریافت کرده و از ۱۲۶ میلیون طلب مصوب کسر می‌شود.
در این مثال هزینه دوره شرکت از محل مخارج تأییدشده شخصی کارمند ۱۲۶ میلیون ریال است. اگر ۲۴ میلیون ریال کارت سازمانی هم ماهیت هزینه جاری و مدارک معتبر داشته باشد، هزینه دوره مربوط به دو مسیر جمعاً ۱۵۰ میلیون ریال می‌شود. ۲۰ میلیون مخارج شخصی هزینه شرکت نیست؛ تکلیف ۱۰ میلیون مبهم نیز هنوز نیازمند بررسی است. جمع هزینه شرکت، مبلغ بازپرداخت به کارمند و جمع رسیدها سه شاخص مجزا هستند.
ثبت مرحله اول: مساعده ۷۰ میلیونی از بانک خارج شد
در آغاز مأموریت، شرکت ۷۰ میلیون ریال به کارمند پرداخت می‌کند؛ فرض می‌کنیم این مبلغ مساعده قابل تسویه بابت مخارج آتی است، نه حقوق، پاداش، مزایای قطعی یا هزینه خودِ مأموریت در زمان پرداخت. ثبت آموزشی:
| حساب | بدهکار | بستانکار |
|---|---|---|
| جمع | ۷۰ | ۷۰ |
| مساعده / پیش‌پرداخت کارکنان | ۷۰ | — |
| بانک | — | ۷۰ |
در این مرحله، صرف خروج وجه نقد از بانک، هزینه قطعی ۷۰ میلیونی ایجاد نمی‌کند؛ شرکت حق دارد کارکنان در برابر وجه دریافت‌شده پاسخ‌گو باشند و اسناد مأموریت یا مانده مازاد را تسویه کنند. طبقه‌بندی دقیق می‌تواند با آیین‌نامه تنخواه، قرارداد استخدام و ماهیت پرداخت متفاوت باشد. اگر وجه، فوق‌العاده مأموریت با ماهیت مزدی یا حق قطعی کارمند باشد، ثبت آن الزاماً از این مدل پیروی نمی‌کند.
نکته نرم‌افزاری: مساعده دارای شناسه کارمند، شناسه مأموریت، تاریخ پرداخت، حساب بانکی، وضعیت تسویه و مانده باقی‌مانده باشد. نباید صرفاً از روی یک واریزی قدیمی با مبلغ مشابه، مساعده به پرونده جدید اعمال شود.
ثبت مرحله دوم: ۱۲۶ میلیون هزینه معتبر از جیب کارمند
پس از بررسی رسیدها و احراز ماهیت هزینه جاری در دوره، شرکت ۱۲۶ میلیون ریال مخارج کاری را می‌پذیرد. یک ثبت ساده‌شده می‌تواند چنین باشد:
| حساب | بدهکار | بستانکار |
|---|---|---|
| جمع | ۱۲۶ | ۱۲۶ |
| هزینه‌های مأموریت / فعالیت مربوط | ۱۲۶ | — |
| حساب‌های پرداختنی به کارکنان | — | ۱۲۶ |
اگر بخشی از هزینه مربوط به چند مرکز هزینه یا پروژه باشد، باید همین مبلغ طبق مدرک و سیاست تخصیص در سطرهای مستقل ثبت شود. فرض نکرده‌ایم هر ۱۲۶ میلیون در سرفصل «هزینه سفر» یکجا قرار می‌گیرد: ممکن است حمل‌ونقل، اقامت، هزینه اینترنت یا مصرف قطعات عادی باشد.
در پرونده واقعی، بعضی خریدها ممکن است دارایی، پیش‌پرداخت خدمت، موجودی یا هزینه دوره بعد محسوب شوند. در آن صورت نباید همه را بدون بررسی به هزینه دوره برد. مثال حاضر برای تمرکز بر تسویه کارکنان، این پیچیدگی‌ها را کنار گذاشته است.
ثبت مرحله سوم: مساعده با بدهی به کارمند تسویه می‌شود
پس از تأیید اینکه مساعده قبلی ۷۰ میلیون ریال دقیقاً به همین مأموریت و همین کارمند مربوط است و مانع حقوقی یا قراردادی برای اعمال آن وجود ندارد، ثبت آموزشی تسویه حساب داخلی:
| حساب | بدهکار | بستانکار |
|---|---|---|
| جمع | ۷۰ | ۷۰ |
| حساب‌های پرداختنی به کارکنان | ۷۰ | — |
| مساعده / پیش‌پرداخت کارکنان | — | ۷۰ |
اکنون مانده بدهی شرکت به کارمند ۵۶ میلیون ریال است. اگر در نرم‌افزار، مساعده قبلاً به هزینه منظور شده باشد، باید ابتدا رویداد اصلی و ثبت‌های اصلاحی آن بررسی شود؛ انتقال صوریِ مانده بدون پاک‌کردن ثبت مضاعف، مشکل را حل نمی‌کند.
این اعمال مساعده یک گردش غیرنقدی تسویه مانده‌های حسابداریاست؛ نباید در همین مرحله خروج جدید وجه بانک ثبت شود. وجه ۷۰ میلیون ریالی در آغاز مأموریت پرداخت شده و ثبت پرداخت مجدد آن، بانک را دوباره کاهش می‌دهد.
ثبت مرحله چهارم: فقط ۵۶ میلیون ریال دیگر پرداخت می‌شود
اگر واحد مالی صحت مجوز، هویت کارمند، عدم وجود مانع و مانده نهایی را تأیید و بانک پرداخت را انجام دهد، ثبت نمونه:
| حساب | بدهکار | بستانکار |
|---|---|---|
| جمع | ۵۶ | ۵۶ |
| حساب‌های پرداختنی کارکنان | ۵۶ | — |
| بانک | — | ۵۶ |
پس از تسویه، در مفروضات اصلی:
- مانده مساعده این مأموریت: صفر؛
- مانده بدهی قابل پرداخت به کارمند از ردیف‌های تأییدشده: صفر؛
- هزینه جاری شناسایی‌شده از پرداخت‌های شخصی کارکنان: ۱۲۶ میلیون؛
- جمع وجه پرداخت‌شده مستقیم به کارمند برای این پرونده: ۱۲۶ میلیون (۷۰ در ابتدا و ۵۶ در پایان)؛
- مخارج کارت سازمانی: ۲۴ میلیون با مسیر حسابداری و تسویه مجزا؛
- پرونده ۱۰ میلیونی: هنوز باز و به‌دلیل کمبود مدارک لزوماً به معنی نبود تعهد اقتصادی نیست.
این پنج شاخص باید جدا گزارش شوند. اگر سامانه فقط یک ستون با عنوان «هزینه کارکنان پرداخت‌شده» داشته باشد، ممکن است ۱۲۶ میلیون هزینه را با ۷۰ میلیون مساعده قبلی و ۲۴ میلیون کارت سازمانی اشتباه جمع کند.
تکلیف ۲۴ میلیون ریال کارت سازمانی چیست؟
فرض کنیم مبلغ ۲۴ میلیون ریال در یک خرید کاری با کارت شرکت پرداخت شده است. اگر خرید واقعاً هزینه جاری شرکت باشد و تراکنش قطعی و معتبر باشد، ثبت آن می‌تواند بدهکار هزینه مربوط ۲۴؛ بستانکار بدهی به صادرکننده کارت یا حساب واسط ۲۴ باشد؛ پرداخت نهایی به صادرکننده کارت به وضعیت واقعی قرارداد کارت وابسته است.
ولی خود کارمند نباید صرف ارائه تصویر رسید، مجدداً مبلغ ۲۴ را نقداً دریافت کند. اگر شرکت قبلاً گردش کارت را ثبت کرده، ثبت دوباره هزینه یا بدهی به کارمند می‌تواند اضافه‌شماری ایجاد کند.
مقاله شماره ۲۵۷ حسابداران برتر درباره تطبیق تصاویر رسید با تراکنش کارت سازمانی و صحت ثبت آن بود. مقاله حاضر مسئله متفاوتی دارد: تسویه مساعده قبلی با مطالبات مورد تأیید کارمند در یک پرونده متشکل از چند روش پرداخت. تطبیق کارت، یکی از ورودی‌های این تسویه است، نه تمام موضوع.
۲۰ میلیون مخارج شخصی و ۱۰ میلیون در انتظار بررسی چه می‌شوند؟
برای ۲۰ میلیون ریال، فرض مقاله این است که خرید شخصی و خارج از دامنه تعهد کارفرما بوده است. بنابراین صرف بارگذاری سند، نه بدهی به کارمند ایجاد می‌کند و نه هزینه شرکت. در دنیای واقعی اگر مقررات کار، قرارداد، توافق قبلی یا سیاست مصوب برای برخی اقلام حق بازپرداخت ایجاد کرده باشد، باید مطابق همان شرایط تصمیم گرفت؛ AI نباید بدون سند، اقلام را «شخصی» یا «متقلبانه» بنامد.
۱۰ میلیون ریال دیگر در انتظار بررسی است. در سیستم بازپرداخت این مبلغ فعلاً به لیست پرداخت کارمند وارد نمی‌شود. اما در دفتر کل ممکن است اگر شرکت واقعاً کالا یا خدمت را دریافت کرده و تعهد قابل شناسایی وجود دارد، لازم باشد حسابدار درباره ثبت تعهدی، بدهی یا هزینه تصمیم بگیرد؛ فقدان تأیید بازپرداخت به‌تنهایی مجوز نادیده‌گرفتن تعهد اقتصادی نیست.
این مرز از مهم‌ترین کنترل‌های حسابداری است: عدم پرداختِ فوری به کارمند، لزوماً برابر با عدم شناساییِ هزینه شرکت نیست. برعکس، وجود رسید و پرداخت نقدی هم خودکار به معنی هزینه قابل قبول یا بدهی به کارمند نیست.
تفاوت بازپرداخت مجاز، شناسایی حسابداری و پذیرش مالیاتی
برای یک هزینه مأموریت سه نوع تصمیم جدا وجود دارد:
اول، استحقاق و بازپرداخت به کارمند: آیا براساس قرارداد استخدام، حکم مأموریت، آیین‌نامه مصوب و شواهد، کارمند حق دریافت وجه دارد؟ این تصمیم گاهی با احکام حمایتی قانون کار نیز مرتبط است.
دوم، شناسایی در دفاتر شرکت: آیا هزینه، دارایی یا بدهی اقتصادی طبق مبنای گزارشگری ایجاد شده و به کدام دوره مربوط است؟ پرداخت‌شدن یا نبودن رسید به‌تنهایی پاسخ کافی نیست.
سوم، پذیرش مالیاتی: آیا هزینه با قواعد مواد ۱۴۷ و ۱۴۸ قانون مالیات‌های مستقیم و سایر احکام لازم‌الاجرا سازگار است؟ ماده ۱۴۷ به متعارف‌بودن، اتکا به مدارک و ارتباط با تحصیل درآمد در دوره مربوط اشاره دارد. ماده ۱۴۸ برخی اقلام، از جمله هزینه سفر و فوق‌العاده مسافرت را در چارچوب شرایط خود مطرح می‌کند.
بخشنامه شماره ۲۰۰/۱۴۰۴/۶۱ مورخ ۳۰ شهریور ۱۴۰۴ سازمان امور مالیاتی نیز درباره شرایط مستندبودن هزینه‌های متکی به صورتحساب‌های الکترونیکی توضیح داده است. بااین‌حال این بخشنامه «هر تصویر رسید بارگذاری‌شده» را معادل صورتحساب الکترونیکی واجد شرایط نمی‌داند؛ نبود بعضی شرایط مذکور نیز طبق تبصره آن به‌تنهایی حکم رد همه هزینه‌ها نیست. باید وضعیت خاص معامله و مقررات دوره سنجیده شود.
بنابراین خواندن تصویر رسید با AI و تصویب داخلی بازپرداخت، معادل تأیید اعتبار مالیاتی یا هزینه قابل قبول مالیاتی در ایران نیست.
تفاوت هزینه مأموریت و فوق‌العاده مأموریت
اگر کارمند مشمول قانون کار ایران باشد، طبق ماده ۴۶ قانون کار، برای مأموریت‌های مشمول شرایط مقرر، فوق‌العاده مأموریت و تأمین وسیله یا هزینه رفت‌وبرگشت مطرح است. این حقوق قانونی را نمی‌توان صرفاً به دلیل نبود یک تصویر رسید در داشبورد بازپرداخت، کنار گذاشت.
برای مثال، مبلغی که شرکت به‌عنوان فوق‌العاده مأموریت قانونی به کارگر بدهکار است، لزوماً از همان جنس بازپرداخت یک فاکتور اقامت که کارمند با پول شخصی پرداخت کرده نیست. سیاست نرم‌افزاری باید این اقلام را جدا نگه دارد تا هم تعهدات قانونی فراموش نشوند و هم یک هزینه از دو مسیر تکرار نگردد.
سناریوی ۱۸۰ میلیونی ما فقط مخارج ادعاییِ دارای رسید و مساعده قابل تسویه را بررسی می‌کند و هیچ عددی برای فوق‌العاده مأموریت قانونی، حد نصاب مالیاتی یا حق بیمه تعیین نکرده است. در پرونده واقعی، عنوان و ماهیت هر پرداخت باید با اسناد استخدامی و مقررات قابل اعمال بررسی شود.
AI در خواندن رسید دقیقاً چه کاری باید انجام دهد؟
مدل هوشمند می‌تواند نام فروشنده، تاریخ، مبلغ، ارز، شناسه فاکتور، شرح کالا و چند ردیف مبلغ را از تصویر استخراج کند؛ رسیدهای تکراری یا مشابه را معرفی کند؛ رابطه احتمالی با مأموریت، تراکنش کارت یا سند خرید را پیشنهاد دهد؛ و فقدان مدارک را برای کاربر توضیح دهد.
اما نتیجه OCR یک گزاره درباره متن تصویر است، نه حکم درباره حق مالی. حتی اگر مبلغ را با اطمینان ۹۹ درصد خوانده باشد، ممکن است ندانَد رسید با کارت شرکتی پرداخت شده یا کارمند قبلاً مساعده گرفته است. اگر کاربر عکس را در دو مأموریت بارگذاری کند، استفاده مجدد از یک سند نیز باید با شناسه‌های اقتصادی کنترل شود؛ هش یکسان فایل فقط قرینه است، نه اثبات قطعی خرید تکراری.
بهترین تقسیم کار: مدل برای استخراج و کشف رابطه، موتور قواعد برای جمع‌ها و سقف‌ها، حسابدار برای ماهیت اقتصادی و شخص مجاز برای بازپرداخت. این الگو سرعت را با پاسخ‌گویی و قابلیت رسیدگی جمع می‌کند.
خطر کارت شخصی، کارت سازمانی و پرداخت نقدی مشترک
فرض کنید کارمند هزینه ۳۰ میلیونی را در دو مرحله پرداخته است: ۱۸ میلیون با کارت سازمانی و ۱۲ میلیون با حساب شخصی. یک تصویر فاکتور به مبلغ ۳۰ میلیون وجود دارد. اگر ابزار فقط نوع کارت نخست را بخواند و کل ۳۰ را در کارت شرکت ثبت کند، بازپرداخت ۱۲ میلیون شخصی از قلم می‌افتد. اگر کل ۳۰ را به کارمند بدهکار شود، ۱۸ میلیون اضافه‌پرداخت احتمالی ایجاد می‌کند.
برای چنین مواردی باید تخصیص چند شیوه پرداخت به یک سندپشتیبانی شود و جمع بخش‌های پرداخت‌شده از مبلغ صورتحساب بیشتر نشود. در مثال اصلی، برای ساده‌سازی هر ردیف به یک شیوه پرداخت تعلق داشت؛ ولی نرم‌افزار واقعی باید حالت‌های ترکیبی را نیز پوشش دهد.
همچنین برخی خریدها ممکن است یک بار به‌عنوان هزینه کارت و بار دیگر از طریق صندوق تنخواه مرکزی ثبت شده باشند. پیش از تصویب پرداخت، باید بانک، کارت، تنخواه، حساب مساعده و سوابق بازپرداخت در کنار یکدیگر بررسی شوند.
هشت کنترل پیشنهادی برای سامانه تسویه هوشمند کارکنان
۱. شناسنامه مأموریت: هر پرونده شناسه مأموریت، فرد، تاریخ، شرکت حقوقی، مرکز هزینه و مسئول تأیید داشته باشد. شباهت نام اشخاص کافی نیست.
۲. ثبت مستقل منبع پرداخت: در هر ردیف مشخص شود وجه با کارت شخصی، کارت سازمانی، وجه نقد، تنخواه یا روش ترکیبی پرداخت شده است. نوع ابزار از روی ظاهر فروشنده حدس زده نشود.
۳. دفتر مساعده و مانده باز: هر پرداخت مقدماتی با شناسه بانکی، تاریخ، کارمند و مأموریت نگهداری شود؛ تخصیص یک مساعده به چند پرونده نباید بیش از مبلغ واقعی آن شود.
۴. تفکیک وضعیت چهارگانه: «رسید خوانده شد»، «هزینه اقتصادی احراز شد»، «بازپرداخت مجاز شد» و «وجه پرداخت شد» چهار رویداد جدا باشند.
۵. کنترل ضدتکرار: شماره فاکتور، فروشنده، مبلغ، تاریخ، تصویر، شناسه تراکنش و سوابق تخصیص بررسی شوند؛ شباهت‌ها هشدار ایجاد کنند، نه حذف یا اتهام خودکار.
۶. کنترل محاسبات قطعی: جمع مخارج تأییدشده، وجه کارت شرکت، اقلام معلق، مساعده مصرف‌شده و مانده بازپرداخت با فرمول قابل آزمون محاسبه شود. در مثال، خروجی باید دقیقاً ۵۶ میلیون ریال باشد.
۷. جداسازی احکام ایران: سیاست بازپرداخت داخلی، شناسایی دفاتر، مالیات، تکالیف قانون کار و شرایط صورتحساب الکترونیکی، موتور قواعد و پاسخ‌گوی جدا داشته باشند.
۸. مجوز پرداخت و ردپای حسابرسی: AI پیش‌نویس دهد؛ تغییر حساب بانکی کارمند، رد هزینه، اعمال مساعده، تصویب پرداخت و دستور بانک تنها توسط نقش مجاز انجام شود و سند هر تصمیم قابل بازیابی باشد.
فرصت محصولی برای حسابداران برتر: «تسویه‌یار هوشمند مساعده و رسید کارکنان»
برای برند تولیدکننده نرم‌افزارهای مالی، اداری و راهکارهای AI حسابداران برتر می‌توان ماژول پیشنهادی «تسویه‌یار هوشمند مساعده و رسید کارکنان» را طراحی کرد. این نام پیشنهاد توسعه محصول است؛ نه ادعای عرضه فعلی قابلیت یا اتصال آماده به بانک‌ها و کارت‌های سازمانی ایران.
کارمند تصاویر رسید و شناسه مأموریت را در محیط مجاز ثبت می‌کند. سامانه از سیستم حسابداری، وجوه قبلی، کارت‌های شرکت و سیاست‌های مجاز را دریافت می‌کند. AI اطلاعات اسناد را استخراج و مغایرت احتمالی را شرح می‌دهد. موتور قطعی مبلغ قابل بازپرداخت و مانده مساعده را محاسبه می‌کند. مسئول مالی مدارک و ارتباط با هزینه یا دارایی را تأیید می‌کند و مقام مجاز دستور پرداخت را تصویب می‌کند.
خروجی مناسب برای مثال حاضر چنین است: «از ۱۸۰ میلیون ریال اسناد ارائه‌شده، ۱۲۶ میلیون مخارج پرداخت‌شده با وجه شخصی و تأییدشده، ۲۴ میلیون مخارج کارت سازمانی، ۲۰ میلیون مخارج خارج از سیاست و ۱۰ میلیون در انتظار بررسی است. ۷۰ میلیون مساعده قبلیبا ۱۲۶ میلیون قابل تسویه بوده و ۵۶ میلیون ریال مانده پرداخت فعلیاست.»
برای شرکت‌های ایرانی، ریال و تومان، تقویم شمسی، شناسه ملی و پرسنلی، چندشرکتی، مراکز هزینه، اسناد مأموریت، تفکیک حقوق قانونی و هزینه‌های واقعی، وضعیت سامانه مؤدیان و محدودیت دسترسی باید در طراحی لحاظ شوند. داده‌های شخصی و مالی کارکنان نیز نباید بی‌دلیل به مدل بیرونی ارسال شوند.
پایلوت چهار هفته‌ای: چه چیزی را اندازه بگیریم؟
هفته نخست: ۴۰ پرونده مأموریت فرضی یا بی‌نام‌سازی‌شده تهیه کنید؛ برای هر پرونده، تصویر اسناد، منبع پرداخت، تاریخ، مبلغ، مساعده قبلی، تأیید کارمند و مسئول مالی مشخص باشد. پاسخ مرجع را مستقل از AI ثبت کنید.
هفته دوم: موارد مرزی بسازید: یک فاکتور با دو روش پرداخت، مساعده مربوط به مأموریت دیگر، رسید تکراری، تصویر ناخوانا، کارمند هم‌نام، هزینه شخصی در بسته مخارج کاری، و مدرک خدماتی که هنوز تأیید نشده است. آزمون اصلی: هیچ مساعده یا رسید بیش از یک بار مصرف نشود.
هفته سوم: مدل صرفاً خواندن تصویر و پیشنهاد ارتباط را انجام دهد. موتور قواعد، جمع و تفریق‌ها را محاسبه کند. پرداخت واقعی در محیط آزمون غیرفعال و تأیید انسانی اجباری باشد.
هفته چهارم: میزان درست‌خواندن مبلغ و تاریخ، دقت تشخیص منبع پرداخت، نرخ اختلاف با مانده مرجع، موارد تکراری، پرونده‌های معلق، زمان بررسی و تعداد تلاش برای بازپرداخت نامجاز را اندازه بگیرید. مبلغی که جلوی پرداخت اشتباه آن گرفته شده، صرفه‌جویی تحقق‌یافته قطعینیست مگر پیامد اقتصادی واقعی اثبات شود.
جمع‌بندی: ۱۸۰ میلیون رسید، ۱۲۶ میلیون طلب مصوب و ۵۶ میلیون پرداخت نهایی
در مثال مقاله، کارمند ۱۸۰ میلیون ریال رسید ارائه کرد. پس از رسیدگی، ۱۲۶ میلیون ریال هزینه پرداخت‌شده از منابع شخصی و قابل بازپرداخت تأیید شد. ۲۴ میلیون ریال از مسیر کارت سازمانی پرداخت شده بود؛ ۲۰ میلیون ریال خرید شخصی در مفروضات پرونده بود و ۱۰ میلیون ریالدر انتظار مدارک بیشتر ماند.
از ۱۲۶ میلیون ریال طلب مصوب، کارمند ۷۰ میلیون ریال را قبلاً به صورت مساعده دریافت کرده بود. بنابراین تنها ۵۶ میلیون ریال مانده پرداخت داشت. در این سناریو، پرداخت ۱۸۰ میلیونی به جای ۵۶ میلیونی می‌توانست ۱۲۴ میلیون ریال اضافه‌خروج وجه نسبت به مانده مصوب ایجاد کند.
کار هوش مصنوعی مالی با خواندن همه رسیدها تمام نمی‌شود؛ سامانه باید مشخص کند چه کسی هزینه را پرداخت کرده، آیا شرکت موظف به جبران آن است، چه مبلغی قبلاً تسویه شده و اکنون دقیقاً چه مانده‌ای قابل پرداخت است.
برای آشنایی با راهکارهای نرم‌افزاری مالی و هوشمندسازی حسابداری حسابداران برتر:
https://hesabdaranebartar.com