تخصیص وجوه دریافتی مشتری؛ کدام فاکتور را تسویه کنیم؟

تخصیص وجوه دریافتی مشتری دقیقاً چه تصمیمی است؟

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

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

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

واریز نامشخص را از وصول تخصیص‌نیافته جدا کنید

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

Oracle در راهنمای نسخه 26B، دریافت فاقد اطلاعات مشتری را unidentified می‌نامد و توضیح می‌دهد که بعضی عملیات تخصیص تا تعیین مشتری غیرفعال‌اند. همان راهنما امکان تخصیص تمام یا بخشی از یک دریافت به یک یا چند قلم را بیان می‌کند. بنابراین وجود دریافت ثبت‌شده و بازماندن بخشی از آن، خودبه‌خود تناقض یا خطای سیستم نیست. ^[۲]

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

برای تطبیق دریافت با فاکتور چه شواهدی کافی است؟

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

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

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

مثال عددی: مانده کل درست است، اما فاکتور اشتباه بسته شده

این یک مثال آموزشی فرضی است، نه تجربه مشتری یا برآورد بازدهی. همه مبالغ میلیون تومان‌اند و برای سادگی، مالیات، ارز، تخفیف و کارمزد جداگانه نداریم. یک مشتری سه فاکتور باز دارد: فاکتور اول ۳۰۰، فاکتور دوم ۲۰۰ و فاکتور سوم ۱۸۰. ترتیب سررسید نیز همین است. بانک دریافت ۴۸۰ را تأیید کرده و اعلامیه معتبر مشتری می‌گوید این پول برای فاکتور اول و سوم است؛ فاکتور دوم فعلاً پرداخت نشده است.

نتیجه درست: ۳۰۰ به اول و ۱۸۰ به سوم تخصیص می‌یابد؛ آن دو بسته می‌شوند و فاکتور دوم با مانده ۲۰۰ باز می‌ماند. اگر اپراتور صرفاً از قدیمی‌ترین قلم شروع کند، اول را می‌بندد و ۱۸۰ را به دوم می‌زند. اکنون دوم ۲۰ و سوم ۱۸۰ مانده دارند. جمع طلب در هر دو حالت ۲۰۰ است؛ پس کنترل جمع حساب مشتری این خطا را کشف نمی‌کند. اما سن بدهی باز، موضوع تماس وصول و شواهد اختلاف با مشتری عوض شده‌اند.

اگر همان مشتری به‌جای ۴۸۰، مبلغ ۴۵۰ بپردازد و اعلام کند ۳۰۰ برای اول و ۱۵۰ برای سوم است، این دو تخصیص را ثبت کنید؛ ۳۰ از سوم و تمام ۲۰۰ از دوم باز می‌ماند. ادعای مشتری درباره تخفیف ۳۰، تا زمان پذیرش و ثبت مجاز آن، نباید خودکار به تسویه کامل تبدیل شود. برعکس، دریافت ۵۰۰ با همان مقصد ۴۸۰، یک اضافه‌پرداخت ۲۰ می‌سازد که مقصد بعدی آن هنوز باید تعیین شود.

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

کدام تطبیق خودکار را بپذیریم و کدام را نگه داریم؟

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

در راهنمای Microsoft برای بازبینی تطبیق خودکار، کاربر می‌تواند ارتباط اشتباه را اصلاح کند، مبلغ را بین اقلام باز همان حساب توزیع کند و پس از بررسی آن را بپذیرد. این مستند میان پیشنهاد سیستم و پذیرش بازبین تمایز می‌گذارد. برای طراحی کنترل، همین تفکیک مهم‌تر از نام یک قابلیت است: چه کسی پیشنهاد را ساخته و چه کسی مسئول پذیرفتن آن بوده است؟ ^[۴]

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

کسری، اضافه‌پرداخت و تخصیص غلط چگونه حل شوند؟

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

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

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

پرونده کنترل روزانه؛ از ردیف بانک تا فاکتور

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

گزارش Unapplied Receipts Register در Oracle، دریافت‌های نامشخص، تخصیص‌نیافته و علی‌الحساب را جداگانه و بر حسب واحد کسب‌وکار، دوره و ارز قابل بررسی می‌کند. این گزارش برای مرور حساب مشتری و کمک به تطبیق دفتر کل طراحی شده است. برداشت اجرایی ما این است که صف استثنا باید به مانده مالی قابل ردیابی باشد، نه فهرست مکاتباتی که هیچ‌کس جمع آن را با حساب‌ها نمی‌سنجد. ^[۵]

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

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

چه چیزی را هر هفته بسنجیم و چه زمانی سیاست را بازبینی کنیم؟

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

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

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

منابع در ۴ مهر ۱۴۰۵ بازبینی شدند: دو صفحه Oracle مربوط به نسخه 26B و فاقد تاریخ انتشار مستقل‌اند؛ راهنمای بازبینی تطبیق خودکار Microsoft در ۷ سپتامبر ۲۰۲۶ و راهنمای تخصیص دستی آن در ۲۱ اوت ۲۰۲۵ به‌روز شده‌اند؛ صفحه Frappe فقط زمان نسبی به‌روزرسانی نشان می‌دهد و برای آن تاریخ دقیق حدس زده نشده است. مستندات، رفتار همان محصولات را توضیح می‌دهند، نه تکلیف شرکت ایرانی یا قابلیت ژرف‌بان را. با تغییر نرم‌افزار، قرارداد پرداخت یا افزایش اصلاحات، قواعد تخصیص و آزمون‌ها را دوباره مرور کنید.