سفارش خرید و رسید انبار با فاکتور ۲۰۰ میلیون ریالی تطبیق دارد؛ چرا ۱۰ میلیون ریال هنوز باید بررسی شود؟
مقدمه: سه سند همخواناند، اما قیمت ممکن است درست نباشد
در واحد حسابهای پرداختنی یک شرکت تولیدی، فاکتور تأمینکننده برای ۴۰ واحد قطعه به مبلغ ۲۰۰ میلیون ریال دریافت میشود. سفارش خرید نیز همان ۴۰ واحد با نرخ هر واحد ۵ میلیون ریال را نشان میدهد؛ انبار هم دریافت کامل هر ۴۰ واحد را تأیید کرده است. نتیجه کنترل سهطرفه (Three-Way Match) ظاهراً بینقص است: مقدار سفارش = مقدار تحویل = مقدار فاکتور و مبلغ سفارش = مبلغ فاکتور.

اما در قرارداد تجاری، پس از خرید تجمعی ۱۰۰ واحد در دوره توافقشده، قیمت واحدهای بعدی از ۵ به ۴٫۵ میلیون ریال کاهش پیدا میکند. شرکت پیش از سفارش جدید، ۸۰ واحد تحویل گرفته بود. بنابراین از ۴۰ واحد سفارش جدید، ۲۰ واحد هنوز در پله اول و ۲۰ واحد در پله دوم قرار میگیرند. جمع قراردادی، مشروط به احراز همه مفروضات، ۱۹۰ میلیون ریال است؛ نه ۲۰۰ میلیون ریال.
چک سهطرفه میگوید فاکتور با سفارش و رسید انبار سازگار است؛ الزاماً نمیگوید خودِ قیمت سفارش با قرارداد درست است. این نقطه دقیقاً جایی است که کنترل هوشمند «قرارداد به فاکتور» باید به گردش حسابهای پرداختنی اضافه شود.
خبر تازه ۲۲ اکتبر ۲۰۲۶: کنترل قرارداد پیش از پرداخت
شرکت آمریکایی FlexTecs در ۲۲ اکتبر ۲۰۲۶ ماژول Invoice Compliance را در پلتفرم FlexTrap معرفی کرد؛ رسانه تخصصی CPA Practice Advisor خبر را در ۲۳ اکتبر پوشش داد.

طبق توضیح رسمی سازنده، این ماژول فاکتور تأمینکنندگان منتخب را با نرخهای مذاکرهشده، کارت نرخ، تخفیفها، شروط پرداخت و هزینههای جانبی قرارداد مقایسه میکند و اختلاف را پیش از پرداخت برای بررسی نمایش میدهد.
نکته مهم این معرفی، تفاوت «صحت فرایندی» و «صحت تجاری» است. سازنده تصریح میکند کنترل سهطرفه، مطابقت فاکتور با سفارش و رسید را میسنجد؛ اما الزاماً کنترل نمیکند سفارش با قیمت اصلی قرارداد مطابقت داشته است یا نه.
محصول برای همه تأمینکنندگان بهطور پیشفرض فعال نیست؛ سازمان قراردادهای حساس را برای پایش انتخاب میکند.
همچنین براساس توضیح FlexTrap، اتصال به ERP فقطخواندنی است و سامانه بهطور مستقل اسناد را اصلاح یا پرداخت را مسدود نمیکند؛ نتیجه باید در گردش تصمیم مجاز واحد مالی اعمال شود.
این خبر درباره فناوری خارجی است؛ ادعای اتصال آن به نرمافزار یا سامانه بانکی ایران، الزام قانونی جدید و تضمین کشف همه خطاها نیست. اعداد مقاله نیز داده واقعی FlexTecs نیستند؛ مثال آموزشی ساختگیاند.
چرا تطبیق سهطرفه کافی نیست؟
سهطرفهسازی عموماً سه پرسش را پاسخ میدهد: «چه چیزی سفارش دادهایم؟»، «چه چیزی دریافت شده است؟» و «فروشنده بابت همان سفارش چه مطالبه کرده است؟».
این کنترل برای جلوگیری از پرداخت بابت کالای تحویلنشده، مقدار اضافی و برخی اختلافهای مبلغی مفید است.
ولی اگر مسئول خرید هنگام ایجاد سفارش، نرخ قدیمی یا نسخه اشتباه قرارداد را انتخاب کرده باشد، فاکتور و رسید میتوانند با همان سفارش غلط منطبق باشند.
در واقع خطا از نقطهای بالادست وارد زنجیره شده و همه اسناد پاییندست بهظاهر آن را تأیید میکنند.
به همین علت یک کنترل چهارم لازم است: نسخه معتبر قرارداد + پله قیمت + مقدار مصرف تجمعی + شرایط دامنه قرارداد.
در این مرحله AI میتواند بند نرخ پلکانی را از اسناد مجاز استخراج یا تطبیقهای احتمالی را پیشنهاد کند، اما محاسبه باید قابل بازتولید و نتیجهگیری وابسته به تأیید مسئول قرارداد باشد.
مثال عددی: ۴۰ واحد خرید جدید چگونه ۲۰۰ را به ۱۹۰ میلیون ریال میرساند؟
فرض میکنیم شرکت «الف» در قراردادی با تأمینکننده «ب» توافق کرده است که در یک دوره قراردادی مشخص، تعداد واحدهای ۱ تا ۱۰۰ هر کدام ۵ میلیون ریال و از واحد ۱۰۱ به بعد هر کدام ۴٫۵ میلیون ریال محاسبه شوند.

قرارداد همچنین صریحاً روش پلکانیِ افزایشی (Marginal/Incremental) دارد؛ یعنی کاهش نرخ فقط روی واحدهای واردشده به پله دوم اعمال میشود، نه روی همه خریدهای قبلی.
همه مبالغ این بخش میلیون ریال و پیش از مالیات و عوارض فرضی هستند.
پیش از خرید جدید، ۸۰ واحد از همین کالا برای همین شرکت و همین دوره قرارداد تأیید و دریافت شده است.
سفارش تازه برای ۴۰ واحد صادر میشود، اما کارمند خرید بهاشتباه نرخ ثابت ۵ را برای تمام ۴۰ واحد از کاتالوگ قدیمی انتخاب میکند.
محاسبه سفارش براساس نرخ قدیمی:
۴۰ × ۵ = ۲۰۰ میلیون ریال
محاسبه براساس قرارداد فرضی:
۲۰ × ۵ + ۲۰ × ۴٫۵ = ۱۹۰ میلیون ریال
اختلاف اولیه:
۲۰۰ − ۱۹۰ = ۱۰ میلیون ریال
نسبت اختلاف به فاکتور:
۱۰ ÷ ۲۰۰ × ۱۰۰ = ۵٪
حتی پس از افزودن سفارش جدید، جمع ارزش قراردادی خریدهای دوره در این مثال ۴۰۰ + ۱۹۰ = ۵۹۰ میلیون ریال است؛ در حالی که جمع فاکتورها با نرخ اشتباه ۴۰۰ + ۲۰۰ = ۶۰۰ میلیون ریال خواهد شد.
این محاسبه فقط در صورت صحت مقدار تجمعی ۸۰ واحد، دامنه قرارداد، نسخه نرخ و روش پلکانی معتبر است.
ده میلیون ریال، «اختلاف بالقوه قرارداد» است؛ نه لزوماً اضافهپرداخت تحققیافته، تقلب یا هزینه قطعی.
فروشنده ممکن است الحاقیه معتبر افزایش نرخ داشته باشد، ممکن است شمارش تجمعی متفاوت باشد، یا کالاها در دو قرارداد مستقل باشند.
تا پایان بررسی باید وضعیت را «نیازمند رسیدگی» نگه داشت.
اگر قرارداد روش «نرخ کل خرید پس از عبور از پله» داشته باشد چه؟
قیمتگذاری پلهای همیشه از یک فرمول پیروی نمیکند.

بعضی قراردادها پلکانی افزایشی هستند، بعضی پس از رسیدن به یک حد، قیمت کاهشیافته را بر تمام واحدهای مشمول اعمال میکنند و ممکن است برای خریدهای قبلی بستانکار یا تعدیل تعریف کنند؛ برخی نیز قیمت پله جدید را صرفاً روی سفارشهای بعدی اعمال میکنند، نه روی باقیمانده سفارش عبورکننده از مرز.
اگر نرمافزار بدون خواندن عبارت دقیق قرارداد، روش دوم را بهجای اول انتخاب کند، ممکن است اختلاف ظاهری بسیار بزرگتری بسازد.
پس موتور محاسبه باید نوع پله، نقطه شروع، زمان اثر، دامنه کالا، سیاست برگشت و رفتار هنگام عبور از آستانه را بهصورت فیلد ساختیافته ذخیره کند.
خواندن قرارداد با AI مفید است، ولی اگر متن مبهم باشد، سیستم باید ابهام را نمایش دهد و از محاسبه قطعی خودداری کند.
هیچ نرخ هوشمندی جای تفسیر حقوقی و تجاری مسئول مجاز را نمیگیرد.
چهار نکته که میتوانند «۸۰ واحد خرید قبلی» را تغییر دهند
اول ـ دامنه شخصیت حقوقی: خرید شرکت تابعه دیگری ممکن است طبق قرارداد در حجم تجمعی این شرکت حساب نشود. یکی بودن نام گروه اقتصادی کافی نیست.

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

این هشدار برای یافتن موارد نامعمول مفید است، اما افزایش مبلغ ممکن است کاملاً مشروع باشد.
در کنترل انطباق قراردادی، پرسش متفاوت است: «آیا مبلغِ هر ردیف با نرخ و شروط مصوبِ نافذ در زمان معامله هماهنگ است؟»
حتی فاکتور کوچک و کاملاً معمولی میتواند ده میلیون ریال خطای قیمت داشته باشد.
این دو کنترل مکملاند، نه جایگزین یکدیگر.
همچنین کنترل کرایه حمل و خدمات جانبی با نرخ حملونقل از بررسی نرخ پلهای کالای انبارشده متمایز است.
هشت کنترل نرمافزاری برای ماژول تطبیق نرخ قرارداد
۱. شناسنامه قرارداد و کارت نرخ معتبر: شناسه قرارداد، فروشنده، خریدار حقوقی، کد کالا، واحد اندازهگیری، ارز، نسخه و تاریخ اثر برای هر نرخ ثبت شود.

۲. انطباق مستقل سفارش خرید با قرارداد: پیش از تأیید PO، نرخ سفارش با کارت نرخ معتبر تطبیق داده شود؛ کنترل سهطرفه پس از آن باقی بماند.
۳. شمارنده تجمعی قابل رسیدگی: مقدار تحویلهای معتبر، اصلاحیهها، برگشتها و مرز دوره با یک موتور قطعی حساب شود؛ شمارنده فقط از متن یادداشتهای AI ساخته نشود.
۴. موتور پله و تخفیف نسخهدار: روش پلکانی افزایشی، همهواحدی یا سفارش بعدی صریح انتخاب و با آزمون مرزی اجرا شود.
۵. تفکیک نرخ، تعداد و هزینه جانبی: اختلاف قیمت واحد، اختلاف مقدار، کرایه و کارمزد جدا گزارش شوند تا یک اختلاف چند بار شمرده نشود.
۶. گردش رسیدگی بدون ادعای اقدام خودکار: ابزار فقطخواندنی میتواند هشدار بدهد؛ تعلیق پرداخت، اصلاح سفارش، درخواست بستانکار و تصویب مبلغ با نقشهای مجاز ERP و مسئولان مالی انجام شوند.
۷. شواهد و دفتر تصمیم: هر هشدار باید بند قرارداد، شمارش واحدهای قبلی، نسخه PO، رسید انبار، فرمول و تصمیم بازبین را بهصورت قابل بازیابی پیوند دهد.
۸. کنترل تکرار و پایش فروشنده: اختلافی که در چند فاکتور همان قرارداد تکرار میشود با شناسه ریشه واحد پیگیری شود؛ رقم باز، رقم تأییدشده و مبلغ واقعاً بازیافتشده در داشبورد از هم جدا باشند.
شش آزمون پذیرش قبل از استقرار
آزمون ۱ ـ مرز پله: ۸۰ واحد قبلی و سفارش ۴۰ واحدی؛ محاسبه درست سفارش جدید ۱۹۰ میلیون ریال باشد و فاکتور ۲۰۰ میلیون ریالی پرچمگذاری شود.
آزمون ۲ ـ برگشت معتبر: از خرید قبلی ۱۰ واحد مطابق قرارداد برگشت خورده؛ مقدار مبنا ۷۰ باشد و جمع سفارش تازه ۱۹۵ میلیون ریال محاسبه شود.
آزمون ۳ ـ دو شرکت حقوقی: ۸۰ واحد خرید قبلی متعلق به شرکت دیگری است و قرارداد تجمیع شرکتها را مجاز نکرده؛ سامانه نباید مقدار آن را در آستانه شرکت فعلی دخیل کند.
آزمون ۴ ـ پله همهواحدی: متن قرارداد، نرخگذاری همه واحدها را از تاریخ مشخص تعریف کرده؛ سیستم نباید فرمول افزایشی مثال را بدون بررسی اجرا کند.
آزمون ۵ ـ الحاقیه معتبر: نسخه جدید نرخ قبل از سفارش لازمالاجرا شده؛ سیستم باید نرخ مؤثر همان تاریخ و شرکت را انتخاب کند و نسخه پیشین را برای حسابرسی نگه دارد.
آزمون ۶ ـ ابهام در سند: بند قرارداد یا واحد اندازهگیری نامشخص باشد؛ AI باید پرونده ابهام بسازد، نه اختلاف قطعی یا دستور پرداخت.
پاسخ مرجع آزمونها پیش از اجرای عامل، توسط خرید و حسابداری تهیه شود.
موفقیت، صرفاً تعداد هشدارهای زیاد نیست؛ درستبودن مبلغ قراردادی، کمبودن هشدار بیمورد و رعایت مجوز در اقدامات بعدی اهمیت دارد.
برنامه آزمایشی چهار هفتهای
هفته نخست: یک تأمینکننده دارای نرخ پلکانی را انتخاب کنید و قرارداد، الحاقیهها، کارت نرخ، POها، رسیدهای انبار و برگشتهای مجاز را در محیط آموزشی جمعآوری کنید.

هفته دوم: شمارنده تجمعی و موتور محاسبه نرخ را بسازید. خروجی برای هر فاکتور شامل بند قرارداد، مقدار در هر پله، نرخ و اختلاف باشد.
هفته سوم: سناریوهای مرز پله، بازگشت کالا، تغییر نسخه، چندشرکتی بودن، مالیات و واحد اندازهگیری را با پاسخ مرجع کنترل کنید. نقش AI محدود به استخراج بند و توضیح اختلاف باشد.
هفته چهارم: پرونده استثنا را به گردش تأیید خرید و حسابداری وصل کنید. شاخصهای مبلغ بالقوه، مبلغ تأییدشده، فاکتورهای در انتظار تصمیم و مبلغ بازیافتشده را جدا گزارش دهید.
فرصت محصولی برای حسابداران برتر
پیشنهاد توسعه «بازبین هوشمند نرخ قراردادی و تخفیف پلکانی خرید» است؛ ماژولی میان قرارداد، سفارش خرید، انبار، حسابهای پرداختنی و ابزارهای AI.
هسته قطعی محصول کارت نرخ و نسخه قرارداد، شمارنده تجمعی، فرمول پلهها و اختیار تصویب را مدیریت میکند.
لایه AI میتواند بند مرتبط را پیدا کند، تفاوت دو نسخه را توضیح دهد، شواهد ناقص را مشخص کند و پیشنویس درخواست اصلاح فاکتور را به مسئول ارائه دهد.
این پیشنهاد برای بازار ایران باید از ریال و تومان، تقویم شمسی، واحدهای سنجش گوناگون، چندشرکتیبودن، قراردادهای خرید داخلی، حقوق دسترسی و اسناد اصلاحی مطابق مقررات معتبر پشتیبانی کند.
این ایده پیشنهاد توسعه است؛ نه ادعای وجود قابلیت در محصولات فعلی حسابداران برتر یا اتصال عملیاتی FlexTrap به ایران.
جمعبندی: تطبیق کامل سه سند، آخر خط کنترل نیست
در مثال، سفارش خرید، رسید انبار و فاکتور هر سه روی ۴۰ واحد و ۲۰۰ میلیون ریال توافق داشتند.
اما پس از بررسی قراردادِ پلکانیِ افزایشی و ۸۰ واحد خرید قبلی، مبلغ قراردادی سفارش جدید ۱۹۰ میلیون ریال شد و ۱۰ میلیون ریال اختلاف اولیه پدید آمد.
این ده میلیون ریال تا پیش از احراز نسخه قرارداد، میزان خرید تجمعی، برگشتها و سایر شرایط، مبلغ قطعی اضافهپرداخت محسوب نمیشود.
رویکرد درست چنین است:
قرارداد معتبر ← شمارش مقدار تجمعی ← محاسبه نرخ پلکانی ← تأیید PO ← تطبیق سهطرفه ← رسیدگی به اختلاف ← تصمیم انسانی درباره اصلاح و پرداخت.
هوش مصنوعی بررسی و کمک میکند؛ حسابدار کنترل، تحلیل و قضاوت میکند.
برای مشاهده مطالب تخصصی حسابداری هوشمند و راهکارهای مالی حسابداران برتر، به جمع اعضای مجموعه بپیوندید.

