تطبیق سه‌طرفه خرید؛ چه زمانی فاکتور تأمین‌کننده را پرداخت کنیم؟

تطبیق سه‌طرفه خرید دقیقاً کدام تصمیم را کنترل می‌کند؟

تصمیم این راهنما روشن است: پیش از ورود فاکتور تأمین‌کننده به دستور پرداخت، مدیر مالی باید آن را «آزاد»، «متوقف برای اصلاح» یا «ارجاع برای استثنای مستند» کند. تطبیق سه‌طرفه خرید سه شاهد را در سطح ردیف کنار هم می‌گذارد: سفارش خرید می‌گوید چه چیزی با چه قیمت و اختیاری تعهد شده؛ رسید کالا یا تأیید خدمت می‌گوید چه چیزی واقعاً تحویل و پذیرفته شده؛ فاکتور می‌گوید فروشنده بابت چه مقدار و مبلغی طلب دارد. راهنمای HMRC چرخه خرید تا پرداخت را از درخواست و سفارش تا دریافت، فاکتور، پرداخت و دفتر کل دنبال می‌کند و تطبیق دو یا سه‌طرفه را یک نقطه کنترل در حساب‌های پرداختنی می‌داند. ^[۱]

در مستندات Microsoft، تطبیق دوطرفه قیمت فاکتور را با سفارش مقایسه می‌کند و تطبیق سه‌طرفه علاوه بر قیمت، مقدار فاکتور را با مقدار رسیدشده می‌سنجد. Oracle سطح چهارطرفه را نیز تعریف می‌کند: سفارش، رسید، مقدار پذیرفته‌شده پس از بازرسی و فاکتور باید در حدود تحمل سیاست هم‌خوان باشند. این‌ها توصیف رفتار کنترل در سامانه‌های مشخص‌اند، نه قانون عمومی یا الزام نرم‌افزاری برای هر شرکت؛ اما اجزای تصمیم را دقیق و قابل آزمون می‌کنند. ^{[۲] [۵]}

تطبیق، اصالت معامله را به‌تنهایی ثابت نمی‌کند. سه سند می‌توانند با هم برابر باشند اما تأمین‌کننده صوری، سفارش پس از دریافت ساخته شده، رسید را همان درخواست‌کننده ثبت کرده یا شماره حساب پرداخت بدون کنترل تغییر کرده باشد. همچنین برابری مبلغ، صحت مالیات یا دوره ثبت را تضمین نمی‌کند. پس این کنترل باید کنار تأیید تأمین‌کننده، کنترل تکراری‌نبودن فاکتور، تفکیک وظایف، اعتبارسنجی اطلاعات بانکی و بازبینی مالیاتی کار کند؛ جای آن‌ها را نمی‌گیرد. ^{[۱] [۸]}

منابع این مقاله از بریتانیا، آمریکا و مستندات محصولات بین‌المللی‌اند. از آن‌ها برای طراحی فرایند و کنترل استفاده شده است، نه برای بیان حکم مالیاتی، قانونی یا قراردادی ایران. نوع صورتحساب معتبر، زمان شناسایی مالیات، شرایط پذیرش کالا و اختیار امضا باید با مقررات جاری ایران، قرارداد واقعی و رویه مصوب شرکت جداگانه بررسی شود. تفسیر ژرف‌بان این است که پرسش درست «آیا سه عدد برابرند؟» نیست؛ پرسش این است که آیا سه شاهد مستقل و به‌موقع، حق پرداخت همین مبلغ را ایجاد کرده‌اند؟

سیاست تطبیق سه‌طرفه خرید را برای کدام معامله سخت‌گیرانه‌تر کنیم؟

یک سیاست واحد برای همه خریدها یا صف را فلج می‌کند یا کنترل را نمایشی. خرید کالای استاندارد و پرتکرار با سفارش و رسید ساختاریافته می‌تواند سه‌طرفه و تا حدی خودکار باشد. خدمت ماهانه، اجاره، آب و برق یا حق اشتراک ممکن است رسید کالایی نداشته باشد؛ HMRC پیشنهاد می‌کند در خریدهای بدون سفارش، فاکتور با مفاد قرارداد سنجیده و مسیر ارجاع روشن تعریف شود. برای قلمی که کیفیت پیش از مصرف تعیین‌کننده است، رسید فیزیکی کافی نیست و کنترل چهارطرفه تا ثبت پذیرش فنی مناسب‌تر است. ^{[۱] [۵]}

ماتریس را با چهار محرک بسازید: امکان سفارش پیشینی، امکان اثبات دریافت، حساسیت کیفیت و پیامد پرداخت اشتباه. مبلغ تنها محرک نیست. قطعه کم‌مبلغ روی خط تولید، ماده دارای مشخصات ایمنی یا خدمت دسترسی‌دار می‌تواند ریسک عملیاتی بیشتری از یک خرید اداری بزرگ داشته باشد. در مقابل، افزودن بازرسی چهارم به کالای کم‌ریسک و استاندارد ممکن است فقط زمان چرخه را زیاد کند. چارچوب GAO می‌گوید کنترل باید از ارزیابی ریسک بیاید، در سیاست و رویه مستند شود و به‌طور دوره‌ای بازبینی شود؛ بنابراین سخت‌گیری باید دلیل قابل دفاع داشته باشد. ^[۸]

سطح کنترل را پیش از دیدن فاکتور به دسته خرید، تأمین‌کننده و نوع سفارش وصل کنید. اگر کاربر بتواند پس از مشاهده مغایرت، سیاست همان سفارش را از سه‌طرفه به دوطرفه تغییر دهد، کنترل نتیجه را دنبال کرده است. HMRC بر ایجاد سفارش پیش از دریافت و ردیابی یا مسدودکردن تغییرات پس از دریافت یا فاکتور تأکید می‌کند. نسخه سیاست، تاریخ اثر و دلیل هر تغییر باید کنار سفارش بماند تا یک استثنا به کاهش دائمی کنترل تبدیل نشود. ^[۱]

• دوطرفه: خدمت یا هزینه‌ای که دریافت آن با قرارداد، صورت‌جلسه یا تأیید دوره اثبات می‌شود؛ قیمت و شرایط فاکتور با سفارش یا قرارداد سنجیده شود.
• سه‌طرفه: کالای قابل شمارش یا خدمت مرحله‌ای؛ قیمت با سفارش و مقدار با رسید یا تأیید خدمت تطبیق یابد.
• چهارطرفه: کالای حساس به کیفیت یا بازرسی؛ علاوه بر سفارش، رسید و فاکتور، فقط مقدار پذیرفته‌شده مجاز به پرداخت باشد.
• بدون سفارش: فقط برای دسته‌های از پیش مجاز؛ قرارداد، بودجه، مالک هزینه و تأیید مستقل جای خالی سفارش را پوشش دهند، نه یک توضیح آزاد بعد از فاکتور.
• توقف مطلق: تأمین‌کننده یا حساب بانکی تأییدنشده، سفارش پسینی، رسید ثبت‌شده توسط ذی‌نفع همان خرید یا فاکتور تکراری؛ حتی اگر اعداد برابر باشند.

قیمت، مقدار و آستانه مغایرت را چگونه تعریف کنیم؟

تطبیق را در سطح ردیف انجام دهید و جمع فاکتور را نیز جدا کنترل کنید. Microsoft توضیح می‌دهد که قیمت واحد خالص، مبلغ خالص ردیف، هزینه‌های جانبی و جمع فاکتور می‌توانند کنترل‌های متفاوت داشته باشند. اگر فقط جمع نهایی برابر باشد، افزایش قیمت یک قلم ممکن است با کاهش یا حذف قلم دیگر پنهان شود. اگر فقط درصد قیمت واحد دیده شود، چند فاکتور جزئی می‌توانند در مجموع از سقف سفارش عبور کنند. شناسه سفارش، ردیف، کالا یا خدمت، واحد سنجش، ارز، مقدار، قیمت، تخفیف، هزینه جانبی و مالیات باید قابل نگاشت باشند. ^{[۲] [۳]}

برای قیمت، هم درصد و هم مبلغ مطلق بگذارید و عبور از هرکدام را مغایرت بدانید. پنج درصد روی خرید کوچک شاید بی‌اهمیت باشد اما همان درصد روی سفارش بزرگ می‌تواند از اختیار مدیر واحد فراتر رود. برعکس، مبلغ ثابت روی کالای ارزان می‌تواند درصد بزرگی از حاشیه را ببلعد. مستندات Microsoft امکان کنترل هم‌زمان درصد و مبلغ «بیشینه مجاز» را نشان می‌دهد و در تطبیق مبلغ تجمعی، فاکتورهای قبلی و جاری یک ردیف سفارش را کنار هم می‌گذارد. ^{[۲] [۳]}

برای مقدار، پیش‌فرض امن این است که فاکتور بیش از مقدار پذیرفته‌شده آزاد نشود. تحویل جزئی باید به فاکتور جزئی یا ردیف قابل تفکیک برسد؛ تطبیق با کل سفارش، کالای هنوز تحویل‌نشده را مشروع نمی‌کند. در خدمات، «مقدار» را از ابتدا تعریف کنید: ساعت تأییدشده، خروجی تحویل‌گرفته، درصد مرحله یا دوره استفاده. SAP در توضیح تأیید فاکتور، قیمت و شرایط را با سفارش و مقدار را با رسید واقعی مقایسه می‌کند؛ Microsoft نیز برای تطبیق خودکار رسید، وضعیت انتظار، تکمیل و شکست را جدا نگه می‌دارد. ^{[۶] [۴]}

تحمل به معنی نادیده‌گرفتن اختلاف نیست؛ مسیر رسیدگی را تعیین می‌کند. اختلاف زیر آستانه می‌تواند خودکار آزاد شود اما همچنان در داده تحلیل بماند. اختلاف بالای آستانه باید متوقف شود تا یکی از سه نتیجه رخ دهد: اصلاح فاکتور یا سفارش با مجوز معتبر، ثبت رسید یا پذیرش جامانده با مدرک واقعی، یا تصویب استثنا توسط فرد مستقل. تغییر مستقیم مقدار فاکتور برای برابرکردن ظاهر اسناد، علت را پاک می‌کند و ممکن است بدهی واقعی با سند ثبت‌شده متفاوت شود.

• قیمت ردیف: آستانه درصدی و سقف مبلغ مطلق؛ کنترل روی قیمت واحد و مبلغ تجمعی همه فاکتورهای همان ردیف.
• مقدار: فاکتور بیش از رسید یا پذیرش آزاد نشود؛ مرجوعی، ابطال رسید و تحویل جزئی در مقدار قابل پرداخت اثر کند.
• هزینه جانبی: کرایه، بیمه، بسته‌بندی و تعدیل قیمت فقط اگر در سفارش یا استثنای مصوب پیش‌بینی شده‌اند.
• جمع فاکتور: جمع ردیف، تخفیف، هزینه، مالیات و گردکردن با محاسبه مستقل سامانه تطبیق شود.
• کیفیت داده: واحد خرید و مصرف، ضریب بسته‌بندی، ارز و تاریخ تبدیل، شناسه تأمین‌کننده و شماره یکتای فاکتور پیش از خودکارسازی تثبیت شوند.

مثال عددی: چرا یک اختلاف ظاهراً کوچک باید پرداخت را نگه دارد؟

این مثال فرضی است و تجربه یا نرخ یک شرکت واقعی نیست. سفارش برای ۱۰ قطعه حساس تولیدی، هرکدام ۴۸۰ میلیون ریال، در مجموع ۴٫۸ میلیارد ریال صادر شده است. تا تاریخ برش، انبار دریافت ۸ قطعه را ثبت کرده اما کنترل کیفیت فقط ۷ قطعه را پذیرفته است. فروشنده برای هر ۱۰ قطعه با قیمت ۴۹۲ میلیون ریال فاکتور می‌فرستد و ۱۲۰ میلیون ریال کرایه نیز اضافه می‌کند؛ جمع فاکتور ۵٫۰۴ میلیارد ریال است. ^[۵]

سیاست فرضی شرکت برای این دسته چهارطرفه است: اختلاف مقدار صفر؛ اختلاف قیمت حداکثر ۳ درصد و حداکثر ۵۰ میلیون ریال در مجموع؛ هزینه پیش‌بینی‌نشده صفر. افزایش قیمت واحد ۲٫۵ درصد است و در نگاه اول از حد درصدی عبور نمی‌کند، اما اثر آن روی ۱۰ قطعه ۱۲۰ میلیون ریال و بالاتر از سقف مبلغی است. دو قطعه هنوز نرسیده، یک قطعه رسیده اما پذیرفته نشده و کرایه در سفارش نیست. بنابراین چهار علامت مستقل توقف وجود دارد؛ امضای مدیر خرید نباید آن‌ها را به یک «تأیید کلی» تبدیل کند. ^{[۲] [۳] [۵]}

مسیر درست این نیست که حسابدار مقدار فاکتور را موقتاً ۷ ثبت و بعداً برگرداند. شرکت می‌تواند از فروشنده فاکتور اصلاحی برای ۷ قطعه پذیرفته‌شده بخواهد، درباره افزایش قیمت و کرایه با مالک بودجه تصمیم جدا بگیرد و قطعه ردشده را به فرایند مرجوعی یا رفع نقص وصل کند. اگر قرارداد پرداخت جزئی را منع کرده باشد، کل فاکتور تا اصلاح متوقف می‌ماند. اگر افزایش قیمت طبق بند معتبر قرارداد بوده اما سفارش به‌موقع به‌روزرسانی نشده است، استثنا باید دلیل، سند قرارداد، مسئول تأخیر و اثر بودجه را ثبت کند؛ سپس سفارش از مسیر مجاز اصلاح شود. ^[۱]

این مثال نشان می‌دهد «قبولی تطبیق» یک بیت ساده نیست. ممکن است قیمت درصدی قبول و مبلغ تجمعی رد باشد؛ رسید فیزیکی وجود داشته باشد اما پذیرش کیفی ناقص باشد؛ یا اصل خرید معتبر اما هزینه جانبی خارج از اختیار باشد. خروجی باید کد علت در سطح ردیف بدهد تا مسئول مناسب—خرید، انبار، کنترل کیفیت، مالک بودجه یا تأمین‌کننده—مسئله را حل کند. صفی که همه اختلاف‌ها را به مدیر مالی می‌فرستد، کنترل نیست؛ انتقال کار بدون تشخیص است.

استثنا، تفکیک وظایف و رد ممیزی را چگونه طراحی کنیم؟

نقش‌ها را بر اساس شواهد جدا کنید. درخواست‌کننده نیاز را تعریف می‌کند؛ مالک بودجه اختیار هزینه را می‌دهد؛ خرید تأمین‌کننده و شرایط سفارش را نهایی می‌کند؛ انبار یا مالک خدمت دریافت را ثبت می‌کند؛ کنترل کیفیت پذیرش را می‌دهد؛ حساب‌های پرداختنی فاکتور و تطبیق را اجرا می‌کند؛ تصویب‌کننده استثنا ریسک را می‌پذیرد؛ خزانه فقط فاکتور آزادشده را وارد پرداخت می‌کند. GAO تفکیک وظایف را یک ملاحظه صریح در طراحی کنترل می‌داند. در تیم کوچک، بازبینی پس از رویداد، سقف پایین‌تر، گزارش استثنا و تأیید دوره‌ای مدیر ارشد کنترل جبرانی‌اند؛ یک کاربر با چند نام نقش، تفکیک واقعی نیست. ^[۸]

هر استثنا حداقل شش جزء دارد: کد مغایرت، مقدار و مبلغ اثر، سند پشتیبان، مالک رفع، تصویب‌کننده مستقل و تاریخ انقضا. علاوه بر آن بنویسید آیا پرداخت کامل، پرداخت جزئی یا توقف انتخاب شده و چه اصلاحی باید در داده پایه یا قرارداد رخ دهد. تصویب‌کننده نباید همان کسی باشد که سفارش یا رسید مورد اختلاف را ساخته است. توضیح «طبق دستور مدیریت» بدون نام اختیار، دلیل و مدرک، رد ممیزی نیست. ^{[۸] [۱]}

استثناهای تکرارشونده را از صف روزانه به مسئله طراحی منتقل کنید. اگر کرایه همیشه خارج از سفارش است، الگوی سفارش یا قرارداد ناقص است. اگر رسید خدمات دیر ثبت می‌شود، مالک و تقویم پذیرش روشن نیست. اگر افزایش قیمت‌ها مرتب زیر آستانه می‌مانند اما در مجموع بودجه را می‌شکنند، کنترل تجمعی کم است. اگر یک تأمین‌کننده بیشترین تغییر پس از دریافت را دارد، فرایند یا رفتار او به بازبینی نیاز دارد. آستانه نباید به فروشنده آموزش دهد اختلاف را به قطعات کوچک تقسیم کند. ^{[۲] [۱]}

خودکارسازی را پس از تثبیت داده و اختیار شروع کنید. Microsoft فرایندی را شرح می‌دهد که رسیدها را در پس‌زمینه با ردیف فاکتور تطبیق می‌دهد و فقط فاکتور تکمیل‌شده را به گردش کار می‌فرستد؛ همچنین وضعیت انتظار و شکست را نگه می‌دارد. این الگو مفید است، اما استخراج هوشمند فاکتور یا پیشنهاد تطبیق نباید منبع شاهد را بسازد. خروجی خودکار باید به سفارش و رسید واقعی متصل، قابل بازبینی و قابل توقف باشد؛ اطمینان OCR یا شباهت شرح کالا جای شناسه و مدرک تحویل را نمی‌گیرد. ^[۴]

• آزادسازی خودکار: همه کنترل‌های لازم قبول، سندها پیشینی و معتبر، هیچ تغییر پرریسک یا هشدار تکراری وجود ندارد.
• اصلاح در مبدأ: رسید جامانده، واحد اشتباه، فاکتور تکراری یا مبلغ نادرست؛ سازنده داده با مدرک اصلاح کند و تطبیق دوباره اجرا شود.
• استثنای موردی: علت تجاری معتبر اما خارج از سیاست؛ تصویب مستقل، سقف، انقضا و اقدام ریشه‌ای لازم است.
• ارجاع فوری: تغییر حساب بانکی، تأمین‌کننده تأییدنشده، سفارش پسینی، دست‌کاری رسید، تقسیم فاکتور یا تعارض نقش؛ پرداخت تا بررسی جدا متوقف بماند.

در ۳۰ روز چه چیزی بسازیم و بعد چه شاخصی را رصد کنیم؟

هفته اول را به نقشه جریان واقعی اختصاص دهید: از سه خرید اخیر—یک کالای استاندارد، یک خدمت و یک استثنا—مسیر درخواست تا دفتر کل و بانک را بدون توضیح شفاهی بازسازی کنید. نقاطی را که سفارش بعد از فاکتور ساخته می‌شود، رسید گروهی ثبت می‌شود، واحدها نگاشت ندارند یا تصویب فقط در پیام‌رسان مانده علامت بزنید. هدف خرید سامانه نیست؛ تعیین منبع معتبر هر فیلد، نقش مالک و لحظه‌ای است که حق پرداخت ایجاد می‌شود. ^[۱]

هفته دوم ماتریس سیاست را روی دسته‌های خرید بنویسید: سطح دو، سه یا چهارطرفه؛ آستانه قیمت درصدی و مبلغی؛ تحمل مقدار؛ هزینه‌های مجاز؛ مسیر بدون سفارش؛ اختیار استثنا و مدارک لازم. هفته سوم همان سه پرونده و سه حالت شکست عمدی را در سامانه یا کاربرگ کنترل اجرا کنید: فاکتور بیش از رسید، قیمت زیر درصد اما بالای مبلغ، و ابطال رسید پس از فاکتور. نتیجه باید فاکتور را نگه دارد، کد علت بدهد و تغییر بعدی را ثبت کند. ^{[۳] [۱]}

هفته چهارم اجرای محدود را با یک دسته پرتکرار و کم‌پیچیدگی شروع کنید. پنج شاخص پایه کافی است: نرخ تطبیق کامل بدون لمس، نرخ فاکتور بدون سفارش، تعداد و مبلغ استثنا به تفکیک علت، میانه عمر صف مغایرت و مبلغ فاکتور بیش از رسید یا پذیرش. SAP در محتوای فرایندکاوی خود نرخ سه‌طرفه و «درست در بار اول» را معیار فرایند معرفی می‌کند؛ این دو برای شروع مفیدند، اما هدف ۱۰۰ درصدی کور می‌تواند کارکنان را به ساخت رسید صوری یا تغییر سفارش تشویق کند. شاخص کیفیت شاهد و نتیجه بازبینی نمونه‌ای باید کنار سرعت بماند. ^[۷]

ماهانه سه برش را بررسی کنید: استثنا بر حسب تأمین‌کننده و کاربر، مصرف آستانه نزدیک حد، و تغییرات سفارش یا رسید پس از فاکتور. فاکتورهایی که دقیقاً کمی پایین‌تر از سقف می‌مانند، استثناهای تمدیدشده و تأمین‌کنندگانی که پیوسته کرایه یا مقدار اضافه دارند علامت بازطراحی‌اند. هر فصل آستانه را با زیان‌های کشف‌شده، تأخیر پرداخت، حجم کار و تغییر قیمت بازتنظیم کنید؛ افزایش تورم دلیل حذف کنترل نیست، بلکه شاید نیاز به بازنگری سریع‌تر سفارش و سقف مبلغی را نشان دهد. ^{[۸] [۲]}

تصمیم نهایی مدیر مالی باید قابل بازسازی باشد: این فاکتور با کدام نسخه سیاست، بر اساس کدام سفارش، رسید یا پذیرش، در چه آستانه‌ای و به تأیید چه کسی آزاد شد؟ اگر پاسخ فقط «سامانه سبز نشان داد» یا «مدیر تأیید کرد» است، کنترل هنوز تصمیم‌پذیر نیست. ابتدا یک دسته خرید را به این سطح برسانید؛ سپس خودکارسازی را گسترش دهید. پوشش کمتر با شاهد واقعی، از پوشش ظاهراً کامل با استثنای بی‌ردپا ارزشمندتر است.