مقدمه: فاکتور درست است، اما جای مبلغ‌ها در دفتر اشتباه است
مدیر مالی شرکتی خدماتی، فاکتور ۳۰۰ میلیون ریالی یک تأمین‌کننده فناوری را می‌بیند. فاکتور تأیید شده، نام فروشنده معتبر است و جمع ردیف‌ها با مبلغ قابل پرداخت تطبیق دارد. دستیار هوش مصنوعی با تکیه بر سوابق فروشنده، تمام ۳۰۰ میلیون ریال را در حساب «هزینه خدمات فناوری ـ دفتر مرکزی» ثبت می‌کند. از نظر جمع بدهکار و بستانکار، سند مشکلی ندارد.
اما رسیدگی ردیفی سه واقعیت متفاوت را آشکار می‌کند: ۱۵۰ میلیون ریال خدمات تعمیر شبکه که بین دو شعبه مصرف شده است؛ ۹۰ میلیون ریال اشتراک شش‌ماهه پایش شبکه که در پایان ماه اول، تنها یک ماه آن دریافت شده؛ و ۶۰ میلیون ریال قطعات مصرفی شبکه که تحویل انبار شده اما هنوز مصرف نشده است. در مفروضات این مثال، هزینه واقعی دوره فقط ۱۶۵ میلیون ریال است، نه ۳۰۰ میلیون ریال. ۱۳۵ میلیون ریال باقیمانده به دو نوع دارایی جاری مربوط است.
مسئله، تقلب تأمین‌کننده یا اشتباه مبلغ فاکتور نیست. مسئله طبقه‌بندی، دوره شناسایی و مرکز هزینه است. اگر این سه محور کنترل نشوند، گزارش مدیریت ممکن است هم سود شرکت را کمتر و هم هزینه دفتر مرکزی را بیش از واقع نشان دهد؛ در حالی که بانک و حساب‌های پرداختنی هیچ مغایرتی ندارند.
خبر فناوری اکتبر ۲۰۲۶: ورود AI به کدینگ ردیفی فاکتورهای بدون PO
شرکت نرم‌افزاری Yooz در اطلاعیه رسمی ۲۱ اکتبر ۲۰۲۶ از قابلیت Agentic AI Allocation خبر داد. طبق توضیح شرکت، این قابلیت برای فاکتورهایی طراحی شده که سفارش خرید (Purchase Order یا PO) ندارند و همچنان نیازمند تعیین حساب، تخصیص تحلیلی و دسته‌بندی هر ردیف هستند. رسانه CPA Practice Advisor نیز در ۳۰ اکتبر ۲۰۲۶ گزارش مستقلی از معرفی این قابلیت منتشر کرد.
به گفته سازنده، ابزار می‌تواند بر مبنای میزان اطمینان، بعضی تخصیص‌ها را خودکار تکمیل کند، در موارد دیگر پیشنهاد بدهد یا تصمیم را به کاربر واگذار کند. این توصیف، بیان قابلیت‌های اعلام‌شده توسط تولیدکننده است؛ نه تضمین دقت همه تصمیم‌های حسابداری یا مدرک وجود اتصال مستقیم به نرم‌افزارها و مقررات ایران. مثال عددی این مقاله نیز ساختگی است و وقوع این خطا را به محصول Yooz نسبت نمی‌دهد.
نکته عملی برای حسابداران ایرانی این است که شناخت فروشنده و جمع فاکتور کافی نیست. خودکارسازی قابل اعتماد باید بتواند برای هر ردیف، ماهیت اقتصادی، دوره انتفاع، واحد استفاده‌کننده و مدارک تحویل را بررسی کند.
فاکتور بدون سفارش خرید یعنی چه؟
در فرایند خرید دارای PO، معمولاً سفارش خرید، رسید کالا یا تأیید خدمت و فاکتور برای کنترل با هم مقایسه می‌شوند. در مقابل، فاکتور بدون PO ممکن است مربوط به هزینه‌های دوره‌ای، خدمات فوری، قراردادهای اشتراکی یا خریدهایی باشد که فرایند سازمان برای آنها سفارش خرید مستقل پیش‌بینی نکرده است.
نبود PO لزوماً به معنی معامله غیرمجاز، بدهی نامعتبر یا فاکتور جعلی نیست؛ اما نبود یک سند کنترلی ساختاریافته باعث می‌شود نقش قرارداد، تأیید خدمت، رسید انبار، کدینگ حسابداری و مجوز صاحب بودجه پررنگ‌تر شود. برای همین، مدل نباید به دلیل سابقه ثبت ده فاکتور از یک فروشنده در حساب «هزینه فناوری»، فاکتور یازدهم را بدون بررسی همان‌جا بفرستد.
اگر یک فاکتور شامل چند ردیف باشد، سطح درست تصمیم‌گیری ردیف معامله است، نه سربرگ فاکتور. حتی یک ردیف نیز ممکن است نیازمند تقسیم بین چند مرکز هزینه یا دوره زمانی باشد.
مثال عددی: سه ردیف، چهار مقصد حسابداری
تمام اشخاص، خدمات، مبلغ‌ها و زمان‌بندی‌های این مثال فرضی هستند. واحد مبالغ، میلیون ریال است. فرض می‌کنیم فاکتور در پایان نخستین ماه از یک دوره شش‌ماهه رسیدگی شده، خدمات تعمیر به‌طور کامل در همین ماه ارائه و تأیید شده، قطعات مصرفی معمول شبکه تحویل انبار و تحت کنترل شرکت قرار گرفته اما هنوز استفاده نشده‌اند، و اشتراک پایش شبکه از ابتدای ماه جاری شروع شده است. هیچ مالیات و عوارض، کارمزد، تخفیف، کاهش ارزش، جزء دارایی ثابت یا اختلاف قراردادی در مثال وجود ندارد.
حاصل کنترل روشن است:
۱۵۰ + ۱۵ + ۷۵ + ۶۰ = ۳۰۰
مبلغ بدهی به فروشنده در این مثال تغییری نمی‌کند؛ فقط بدهکارهای سند به‌درستی تفکیک می‌شوند.
در مورد اشتراک شش‌ماهه، ۹۰ ÷ ۶ = ۱۵ میلیون ریال هزینه هر ماه است؛ بنابراین با فرض دریافت یکنواخت خدمت، ۱۵ میلیون ریال هزینه ماه اول و ۷۵ میلیون ریال پیش‌پرداخت مربوط به پنج ماه باقیمانده خواهد بود.
اگر دوره خدمات هنوز شروع نشده بود، کل ۹۰ می‌توانست پیش‌پرداخت باشد؛ اگر خدمت به‌صورت غیریکنواخت ارائه شود، الگوی تخصیص باید با واقعیت قرارداد تطبیق یابد.
خطای ۱۳۵ میلیون ریالی چگونه سود را تغییر می‌دهد؟
ثبت اشتباه پیشنهادی عامل:
بدهکار هزینه خدمات فناوری دفتر مرکزی ۳۰۰؛ بستانکار حساب‌های پرداختنی فروشنده ۳۰۰.
ثبت نمونه صحیح در مفروضات مقاله:
بدهکار هزینه تعمیرات شعب ۱۵۰، بدهکار هزینه پایش شبکه ماه جاری ۱۵، بدهکار پیش‌پرداخت خدمات ۷۵، بدهکار موجودی قطعات مصرفی ۶۰؛ بستانکار حساب‌های پرداختنی فروشنده ۳۰۰.
در پایان این ماه و قبل از آثار مالیات بر درآمد یا تعدیلات دیگر، اگر خطا اصلاح نشود، هزینه دوره ۱۳۵ میلیون ریال بیش از مقدار صحیح و سود قبل از مالیات ۱۳۵ میلیون ریال کمتر نمایش داده می‌شود. جمع دارایی‌های جاری مربوط نیز ۱۳۵ میلیون ریال کمتر خواهد بود.
این عدد، اختلاف گزارشگری در سناریوی آموزشی است؛ نه وجه نقد ازدست‌رفته یا اضافه‌پرداخت به تأمین‌کننده.
بعد از اصلاح، می‌توان یک سند تعدیلی نمونه ثبت کرد: بدهکار پیش‌پرداخت خدمات ۷۵ و بدهکار موجودی ملزومات ۶۰؛ بستانکار هزینه خدمات فناوری ۱۳۵.
اما این سند به‌تنهایی مشکل مراکز هزینه را رفع نمی‌کند و بسته به کدینگ اولیه، ممکن است جابه‌جایی هزینه بین مراکز لازم باشد. در سامانه‌های واقعی، روش اصلاح باید با وضعیت بسته‌بودن دوره، کنترل‌های ثبت و اسناد منشأ هماهنگ شود.
اشتباه دوم: دفتر مرکزی ۲۸۵ میلیون ریال بیش از سهم خود هزینه می‌بیند
فرض کنیم قرارداد تعمیر شبکه نشان می‌دهد ۹۰ میلیون ریال مربوط به شعبه الف و ۶۰ میلیون ریال مربوط به شعبه ب است. هزینه اشتراک ماه نخست ۱۵ میلیون ریال نیز طبق استفاده واقعی به دفتر مرکزی تعلق دارد. قطعات انباری هنوز به هیچ واحدی مصرف نشده‌اند.
در این صورت، گزارش درست مراکز هزینه برای این فاکتور در ماه جاری چنین است:
اگر کل ۳۰۰ میلیون ریال به مرکز هزینه دفتر مرکزی رفته باشد، هزینه دفتر مرکزی از ۱۵ به ۳۰۰ رسیده؛ یعنی ۲۸۵ میلیون ریال بیش از سهم واقعی آن. در مقابل، هزینه شعبه الف ۹۰ و شعبه ب ۶۰ کمتر از واقع است.
پس ۲۸۵ میلیون ریال مغایرت مرکز هزینه را نباید با ۱۳۵ میلیون ریال بیش‌نمایی هزینه کل شرکت اشتباه گرفت. اولی اختلاف انتساب مدیریتی است؛ دومی اثر خالص طبقه‌بندی بر هزینه و سود.
این تمایز برای مدیر مالی حیاتی است: ممکن است جمع هزینه دفتر کل پس از اصلاح درست شود، ولی گزارش عملکرد شعب همچنان نامعتبر بماند.
چرا «اعتماد بالا»ی مدل الزاماً به معنی صحت کدینگ نیست؟
مدل هوشمند ممکن است در ده‌ها فاکتور قبلی همین تأمین‌کننده، کد «هزینه فناوری دفتر مرکزی» را دیده باشد و با اطمینان بالا همان کد را برای فاکتور جدید پیشنهاد کند. ولی اطمینان آماری مدل درباره الگوی گذشته با درستی ماهیت اقتصادی ردیف حاضر یکسان نیست.
خطاهای تاریخی نیز می‌توانند به مدل منتقل شوند. اگر در سال قبل، پیش‌پرداخت‌های اشتراک به‌اشتباه یکجا هزینه شده باشند، یادگیری از آن اسناد ممکن است همان اشتباه را تکرار کند.
بنابراین داده آموزشی باید نسخه‌های اصلاح‌شده، نتیجه رسیدگی حسابدار و سیاست مصوب فعلی را از ثبت‌های صرفاً انجام‌شده تفکیک کند.
میزان اطمینان می‌تواند به اولویت بازبینی کمک کند، اما قواعد توقف قطعی لازم است: اگر دوره خدمت بیش از دوره مالی است، اگر کالا هنوز مصرف نشده، اگر ردیف چند مرکز هزینه دارد یا اگر مدرک تحویل در دسترس نیست، سامانه باید پرونده را برای رسیدگی مناسب ارجاع دهد؛ نه اینکه فقط به عدد اطمینان دل ببندد.
پیش‌پرداخت و موجودی؛ مرز شناسایی چیست؟
در مثال ما، مبلغ ۷۵ میلیون ریال به خدمات آتی‌ای تعلق دارد که شرکت حق دریافت آنها را دارد. با فرض احراز شرایط مربوط، این حق می‌تواند به‌عنوان پیش‌پرداخت خدمات در صورت وضعیت مالی باقی بماند و با دریافت خدمات طی ماه‌های آینده به هزینه منتقل شود.
قطعات معمول شبکه نیز فقط در صورتی موجودی مواد و ملزومات هستند که ماهیت مصرفی آنها، کنترل شرکت بر کالا، بهای قابل اندازه‌گیری و شرایط شناخت مطابق مبنای حسابداری احراز شده باشد.
استاندارد حسابداری شماره ۸ ایران در تعریف موجودی، اقلام مصرفی و ملزومات مورد استفاده در فعالیت واحد تجاری را پوشش می‌دهد؛ اما اقلام یدکی عمده یا تجهیزاتی با ماهیت دارایی ثابت، ممکن است نیازمند بررسی جداگانه طبق استاندارد شماره ۱۱ باشند.
در مقابل، اگر قطعات شبکه هنگام رسیدن فوراً روی تجهیزات نصب و در تعمیرات جاری مصرف شده باشند، با مفروضات متفاوت ممکن است بخش یا تمام آن مبلغ هزینه همان دوره شود.
بنابراین «وجود کلمه قطعه در فاکتور» به‌تنهایی اثبات موجودی بودن آن نیست؛ رسید انبار و وضعیت مصرف نیز باید بررسی شوند.
فاکتور بدون PO نباید کنترل مجوز خرید را دور بزند
عدم وجود سفارش خرید سیستماتیک به معنی حذف کنترل خرید نیست. ممکن است قرارداد چارچوبی، مجوز خرید فوری، بودجه مصوب یا تأیید انجام کار وجود داشته باشد.
برعکس، ممکن است فاکتوری فاقد مجوز کافی باشد و صرفاً از روی سابقه فروشنده نباید برای پرداخت آزاد شود.
سامانه بهتر است دو سؤال را جدا پاسخ دهد:
آیا معامله واقعاً رخ داده و بدهی طبق مبنای گزارشگری ایجاد شده است؟
آیا تعهد و پرداخت از نظر مقررات داخلی شرکت مجاز و تأییدشده‌اند؟
این دو همیشه در یک زمان یا با یک پاسخ حل نمی‌شوند. نبود مجوز داخلی ممکن است مسئله کنترل و مسئولیت ایجاد کند، ولی لزوماً واقعیت دریافت کالا یا خدمت و تکلیف شناسایی بدهی را از بین نمی‌برد.
برای جلوگیری از دور زدن کنترل، تأییدکننده فاکتور، مالک بودجه، مسئول دریافت خدمت و شخص مجاز پرداخت باید مشخص باشند. AI نباید این نام‌ها را از فاکتورهای قدیمی حدس بزند.
هشت کنترل اجرایی برای تخصیص هوشمند ردیف‌ها
۱. استخراج ردیف و منشأ: هر مبلغ، شرح، تاریخ خدمت، تعداد، واحد و دوره پوشش باید به بخش مشخصی از فاکتور یا قرارداد متصل شود. اگر فاکتور فقط یک مبلغ کلی دارد، تقسیم آن بدون مدرک مجاز نیست.
۲. کنترل کامل‌بودن جمع: مجموع تمام ردیف‌ها و تخصیص‌ها باید دقیقاً با مبلغ پایه فاکتور پس از تعدیلات معتبر برابر باشد. مالیات و عوارض در صورت شمول باید جدا نگهداری شود.
۳. تفکیک حساب، مرکز هزینه و دوره: هر ردیف سه تصمیم مجزا دارد: ماهیت حسابداری، واحد استفاده‌کننده و زمان انتفاع. درست‌بودن یکی، دو مورد دیگر را ثابت نمی‌کند.
۴. اتصال به مدرک دریافت: برای تعمیر و خدمات، صورت‌جلسه انجام کار؛ برای قطعات، رسید انبار و وضعیت مصرف؛ و برای اشتراک، قرارداد، تاریخ شروع و پوشش خدمت الزامی است.
۵. آزمون سوابق اصلاحی: آموزش یا پیشنهاد بر اساس ثبت‌های قبلی باید با اسناد برگشتی، اصلاحات حسابرسی و رویه‌های مصوب فعلی تطبیق شود؛ خطاهای تاریخی به «قاعده» تبدیل نشوند.
۶. توقف در موارد مبهم: نبود PO، فقدان تأیید، شرح عمومی، دوره نامعلوم، تناقض مرکز هزینه یا ماهیت غیرعادی کالا باید استثنای قابل بررسی ایجاد کند؛ نه اجازه ثبت خودکار.
۷. کنترل جداگانه پرداخت: طبقه‌بندی صحیح فاکتور به‌خودی‌خود مجوز پرداخت نیست. هویت فروشنده، شماره حساب، سررسید، سقف اختیار و عدم تکرار پرداخت باید مستقل بررسی شود.
۸. ثبت ردپای تصمیم: پیشنهاد اولیه AI، شواهد، تغییر کاربر، نسخه قاعده، کدینگ نهایی، زمان تأیید و آثار اصلاح در دفتر کل برای رسیدگی بعدی حفظ شوند.
تفاوت با مقررات ایران و سامانه مؤدیان
قابلیت معرفی‌شده Yooz برای بازارهای هدف خود طراحی شده و دلالتی بر اتصال مستقیم به سامانه مؤدیان ایران ندارد.
در ایران، ماهیت مالی و نحوه ثبت فاکتور باید از اعتبار قانونی صورتحساب، مقررات مالیات بر ارزش افزوده، وضعیت معامله و مدارک متناسب با دوره مستقل ارزیابی شود.
برای مثال، تبدیل بخشی از مبلغ فاکتور به پیش‌پرداخت خدمات یا موجودی انبار در دفتر حسابداری، به‌تنهایی نوع صورتحساب الکترونیکی یا زمان پذیرش اعتبار مالیاتی را تعیین نمی‌کند.
هر اصلاح فروشنده یا تغییر مبلغ معامله باید بر اساس قوانین و دستورالعمل‌های معتبر دوره بررسی شود. همچنین برای مالیات عملکرد، «هزینه ثبت‌شده در دفاتر» و «هزینه قابل قبول مالیاتی» دو بررسی متفاوت‌اند.
در این مقاله عمداً هیچ نرخ یا مهلت مالیاتی تعیین نشده است؛ هدف درستی تخصیص داخلی و شناسایی در صورت‌های مالی است.
فرصت محصولی برای حسابداران برتر: «بازبین ردیفی فاکتورهای بدون سفارش خرید»
برای تولیدکننده نرم‌افزار مالی حسابداران برتر، یک مسیر توسعه می‌تواند ماژول پیشنهادی «بازبین هوشمند ردیفی فاکتورهای بدون سفارش خرید» باشد.
این پیشنهاد ایده محصول است، نه ادعای وجود کنونی چنین ماژولی در محصولات مجموعه.
در نسخه اولیه، ابزار فاکتور و اسناد مرتبط را از مسیر مجاز دریافت می‌کند؛ ردیف‌ها را به حساب پیشنهادی، مرکز هزینه و دوره خدمت متصل می‌سازد؛ در صورت نبود مدرک، استثنا ایجاد می‌کند؛ و سپس پیش‌نویس سند چندسطری را برای تأیید حسابدار آماده می‌کند.
هسته قطعی نرم‌افزار باید جمع مبالغ، جدول تخصیص ماهانه، کدینگ مجاز، سقف بودجه و عدم دوباره‌ثبت را کنترل کند.
لایه AI نقش استخراج و توضیح دارد؛ حق تغییر اطلاعات بانکی فروشنده، صدور پرداخت یا دور زدن کنترل‌های داخلی را ندارد.
برای بازار ایران، تقویم شمسی، ریال و تومان، ساختار چندشرکتی، مراکز هزینه، انبار، قراردادهای خدماتی، استانداردهای حسابداری، اطلاعات صورتحساب الکترونیکی و سطح دسترسی باید با معماری حقوقی و عملیاتی واقعی سازگار شوند.
پایلوت چهار هفته‌ای
هفته اول: ۵۰ فاکتور فاقد PO را از چند نوع خدمت و کالا به‌صورت بی‌نام‌سازی‌شده یا ساختگی گردآوری کنید. برای هر فاکتور، قرارداد، رسید انبار یا تأیید خدمات، دوره پوشش و مرکز هزینه را تهیه کنید. پاسخ صحیح حسابدار ارشد باید مستقل از AI ثبت شود.
هفته دوم: نمونه‌ها را به گروه‌های تک‌ردیفی، چندردیفی، چندمرکز هزینه، اشتراک چندماهه، کالای انباری، فاکتور فاقد مدرک و ترکیب موارد فوق تقسیم کنید. برای هر گروه قواعد توقف و حداقل مستندات را مشخص کنید.
هفته سوم: مدل فقط اطلاعات را استخراج و کدینگ را پیشنهاد دهد؛ موتور محاسبه مستقل جمع ردیف‌ها و تخصیص دوره‌ای را کنترل کند. ثبت قطعی و پرداخت واقعی در محیط آزمایشی غیرفعال باشد.
هفته چهارم: دقت طبقه‌بندی در سطح ردیف، مبلغ هزینه اشتباه، اختلاف مراکز هزینه، درصد پرونده‌های بدون مدرک، زمان رسیدگی، نرخ هشدار کاذب و تعداد اصلاحات پس از تأیید را بسنجید. «تعداد ردیف‌های خودکار» به‌تنهایی معیار موفقیت نیست.
جمع‌بندی: فاکتور ۳۰۰ میلیونی، هزینه ۳۰۰ میلیونی نیست
در مثال آموزشی، یک فاکتور فاقد سفارش خرید به مبلغ ۳۰۰ میلیون ریال از نظر مبلغ و طرف حساب معتبر بود. ولی پس از بررسی ردیفی معلوم شد تنها ۱۵۰ میلیون ریال تعمیرات شعب و ۱۵ میلیون ریال خدمت ماه جاری هزینه دوره‌اند. ۷۵ میلیون ریال به خدمات ماه‌های آتی و ۶۰ میلیون ریال به قطعات مصرفی موجود در انبار تعلق داشت.
در مفروضات این مثال، ثبت یکجای ۳۰۰ میلیون ریال به هزینه، ۱۳۵ میلیون ریال بیش‌نمایی هزینه و کم‌نمایی سود ایجاد می‌کرد.
در عین حال، نسبت‌دادن کل مبلغ به دفتر مرکزی، ۲۸۵ میلیون ریال اختلاف مرکز هزینه نسبت به سهم واقعی دفتر مرکزی ایجاد می‌کرد. این دو مغایرت از یک جنس نیستند و نباید با هم جمع شوند.
هوش مصنوعی مالی زمانی ارزشمند است که فراتر از تشخیص نام فروشنده، برای هر ردیف روشن کند چه چیزی دریافت شده، کدام واحد استفاده کرده و منفعت آن متعلق به چه دوره‌ای است.
پیشنهاد مدل باید قابل توضیح باشد، محاسبه با قواعد قطعی کنترل شود و ثبت نهایی به تأیید حسابدار مسئول برسد.
برای آشنایی با راهکارهای نرم‌افزاری و هوشمندسازی حسابداری:
https://hesabdaranebartar.com
عضویت و دسترسی به آموزش‌ها
برای مشاهده طرح‌های اشتراک و مسیر ثبت‌نام، از صفحه رسمی اشتراک‌ها استفاده کنید.