مشتری ۵۰۰ میلیون ریال پرداخت کرده؛ چرا فقط ۴۹۰ میلیون ریال به حساب شرکت واریز شده است؟
مقدمه: فاکتور تسویه شده، بانک کمتر واریز کرده است
مدیر فروش به حسابدار می‌گوید سه مشتری فاکتورهای خود را کامل پرداخت کرده‌اند. در پورتال جدید دریافت وجه، هر سه فاکتور وضعیت «پرداخت‌شده» دارند و جمع پرداخت‌های ثبت‌شده ۵۰۰ میلیون ریال است. اما یک واریز ۴۹۰ میلیون ریالی در صورتحساب بانکی دیده می‌شود.
آیا مشتریان ده میلیون ریال کمتر پرداخت کرده‌اند؟ آیا سیستم حساب‌های دریافتنی باید ده میلیون ریال بدهی باقی بگذارد؟ آیا درآمد واقعی شرکت ۴۹۰ میلیون ریال بوده است؟
هیچ‌یک از این نتیجه‌ها بدون دیدن ریزتراکنش‌ها و صورتحساب تسویه مجاز نیست.
ممکن است پردازشگر پرداخت، کارمزدی را از مبلغ وصول‌شده کسر کرده باشد. همچنین ممکن است وجه بخشی از معاملات هنوز تسویه نشده، مبلغی برگشت خورده یا چند پرداخت در یک دسته دیگر قرار گرفته باشد.
مسئله اصلی، تفکیک مبلغ ناخالص پرداخت مشتری، کارمزد پردازش، مبلغ خالص تسویه بانکی و وضعیت واقعی مانده حساب دریافتنی است.
خبر تازه ۲۱ و ۲۲ اکتبر: خدمات پرداخت در دل پلتفرم مؤسسه حسابداری
شرکت Xero در ۲۱ اکتبر ۲۰۲۶ از همکاری با Bookkeeper360 برای یکپارچه‌کردن قابلیت‌های حساب‌های پرداختنی و دریافتنی Melio در پلتفرم Bookkeeper360 خبر داد؛ توضیحات تکمیلی در وبلاگ Xero در ۲۲ اکتبر منتشر شد.
این راهکار به مؤسسات اجازه می‌دهد تجربه دریافت و پرداخت وجه را با برند خود درون نرم‌افزارشان عرضه کنند. از منظر خریدار، کاربر لازم نیست الزاماً از یک پورتال جداگانه وارد شود.
این خبر اثبات وجود خطای ۱۰ میلیون ریالی در محصولات Xero، Melio یا Bookkeeper360 نیست و در خبر رسمی نیز کارمزد مشخص یا نحوه ثبت حسابداری سناریوی ما اعلام نشده است.
آنچه برای تولیدکننده نرم‌افزار حسابداری اهمیت دارد این است که با افزایش خدمات پرداختِ تعبیه‌شده (Embedded Payments)، یک نرم‌افزار ممکن است هم‌زمان وضعیت فاکتور، تراکنش پردازشگر و واریز بانک را نشان دهد؛ اما این سه داده در یک لحظه و با یک مبلغ به‌روزرسانی نشوند.
مثال آموزشی: سه فاکتور جمعاً ۵۰۰، تسویه بانکی ۴۹۰
همه اعداد، نام‌ها و قراردادهای این بخش فرضی و بر حسب میلیون ریال هستند.
فرض می‌کنیم فاکتورها از قبل به‌درستی صادر و مطالبات مربوط شناسایی شده‌اند؛ هیچ مالیات، برگشت وجه، تسویه قبلی یا اختلاف ارزی در نمونه وجود ندارد.
همچنین پردازشگر مطابق توافق، کارمزد ۲ درصد مبلغ ناخالص را از وجوه قابل تسویه کسر می‌کند و ریز کارمزد و تسویه آن در دسترس است.
کارمزد مستند فرضی = ۵۰۰ × ۲٪ = ۱۰ میلیون ریال
واریز خالص فرضی = ۵۰۰ − ۱۰ = ۴۹۰ میلیون ریال
در این سناریوی محدود، اختلاف ده میلیون ریالی بدهی باقی‌مانده مشتری نیست؛ چون فرض کرده‌ایم مشتریان تمام ۵۰۰ میلیون ریال را به نحو معتبر پرداخت کرده‌اند و ده میلیون ریال طبق قرارداد بر عهده شرکت پذیرنده است.
در این وضعیت، کم‌کردن ده میلیون ریال از فروش یا باز گذاشتن ده میلیون ریال از حساب‌های دریافتنی بدون بررسی مبنای قراردادی و حسابداری اشتباه است.
اما اگر قرارداد مقرر کند کارمزد بر عهده مشتری باشد، یا پرداخت فقط مجوز موقت گرفته و هنوز قطعی نشده باشد، نتیجه می‌تواند متفاوت باشد.
مدرک پردازشگر و مفاد قرارداد تعیین‌کننده‌اند، نه صرف برابری عددی اختلاف با یک درصد آشنا.
صورت‌بندی حسابداری: از حساب دریافتنی تا حساب واسط تسویه
برای شفافیت، تحت مفروضات خاص همین مثال، حسابدار می‌تواند یک حساب واسط وجوه نزد پردازشگر تعریف کند.
این نمایش، یک الگوی آموزشی است و سند قطعی قابل استفاده برای همه شرکت‌ها، بانک‌ها و استانداردها نیست.
هنگام تأیید وصول معتبر مشتریان:
هنگام احراز تسویه و کارمزد طبق صورتحساب معتبر:
با این دو مرحله، حساب واسط در مفروضات مثال صفر می‌شود:
۵۰۰ بدهکار − ۴۹۰ بستانکار − ۱۰ بستانکار = صفر
هم‌زمان دریافتنی مشتریان ۵۰۰ میلیون ریال تسویه می‌شود و هزینه پردازش، جدا از فروش ثبت می‌گردد.
در پیاده‌سازی واقعی، سندها باید با تاریخ مؤثر، ماهیت تعهد پردازشگر، سیاست شناسایی وجه، قرارداد کارمزد، مستندات مالیاتی و چارچوب حسابداری شرکت هماهنگ باشند.
این مثال به معنی مجازبودن ثبت خودکار صرفاً بر اساس پیام «Paid» نیست.
چرا کنترل جمع ساده کافی نیست؟
۱. چند پرداخت، یک واریز
ممکن است پردازشگر تراکنش‌های چند مشتری یا چند روز را در یک دسته (Batch) تجمیع کند؛ بنابراین مقایسه مستقیم یک واریز بانک با یک فاکتور، همیشه تطبیق درستی نیست.
۲. تفاوت زمان
موفقیت پرداخت مشتری، ایجاد مانده نزد پردازشگر، ایجاد دستور تسویه و ثبت مبلغ در بانک می‌توانند زمان‌های متفاوت داشته باشند.
اختلاف موقت زمان به معنی کمبود دائمی نیست.
۳. کارمزد جداگانه یا تجمیعی
بعضی سامانه‌ها کارمزد را از هر تراکنش و بعضی در گزارش جداگانه یا دوره‌ای نمایش می‌دهند.
نباید برای یک کارمزد، دو ثبت هزینه ایجاد شود.
۴. برگشت وجه یا اختلاف پرداخت
اگر بعداً برگشت وجه، اعتراض یا اصلاح انجام شود، وضعیت وصول و حساب واسط باید با رویداد و مدرک جدید بازبینی شود؛ قاعده یکسان برای همه بازگشت‌ها وجود ندارد.
۵. شرکت و حساب اشتباه
در مؤسسه دارای چند مشتری یا چند شخصیت حقوقی، تسویه ۴۹۰ میلیون ریالی نباید صرفاً به دلیل شباهت مبلغ به شرکت دیگری تخصیص یابد.
مرز مالکیت وجوه مهم‌تر از شکل یکپارچه پورتال است.
منبع رسمی برای تفکیک ناخالص، کارمزد و خالص
در مستند فنی Stripe Balance Transaction، فیلدهای amount، fee و net مستقل‌اند و اثر خالص طبق فرمول amount − fee نمایش داده می‌شود.
این توضیح، شاهدی بر ضرورت طراحی سه مؤلفه جدا در مدل داده است؛ اما به معنی آن نیست که تمام پردازشگران دقیقاً همین API یا همین روش کارمزد را دارند.
راهنمای رسمی Intuit QuickBooks نیز برای ثبت کارمزد سرویس پرداخت شخص ثالث توضیح می‌دهد که به علت کسر کارمزد، مبلغ دریافت‌شده در بانک ممکن است با مبلغ پرداخت ثبت‌شده برابر نباشد و لازم باشد کارمزد در سرفصل مناسب به‌صورت مستقل لحاظ شود.
این منابع مربوط به محصولات و رویه‌های بین‌المللی‌اند و هیچ‌کدام نرخ کارمزد یا دستورالعمل مالیاتی اجباری برای پرداخت‌یارهای ایران تعیین نمی‌کنند.
هشت کنترل نرم‌افزاری برای حسابداری پرداخت تعبیه‌شده
۱. شناسه پایدار تراکنش و فاکتور
برای هر دریافت، شناسه پردازشگر، شناسه فاکتور، شرکت حقوقی و مشتری معتبر نگهداری شود؛ صرف شباهت مبلغ کافی نیست.
۲. تفکیک چهار وضعیت
«پرداخت آغاز شد»، «پرداخت تأیید شد»، «مانده نزد پردازشگر ایجاد شد» و «واریز بانکی تطبیق یافت» به‌عنوان وضعیت‌های متمایز و قابل پشتیبانی نگهداری شوند.
۳. حساب واسط نسخه‌دار
حرکت وجوه بین دریافتنی، پردازشگر و بانک بر اساس رویداد مستند انجام شود؛ مانده باز واسط باید در گزارش پایان روز توضیح داشته باشد.
۴. محاسبه کارمزد با منبع معتبر
موتور از قرارداد و ریزتراکنش پردازشگر استفاده کند؛ AI فقط اختلاف و سند احتمالی را معرفی کند.
درصد تخمینی نباید جای کارمزد قطعی بنشیند.
۵. کنترل عدم تکرار
اجرای دوباره وب‌هوک یا به‌روزرسانی هم‌زمان دو اتصال، نباید دریافت مشتری یا هزینه کارمزد را دوبار ثبت کند.
۶. انطباق تسویه دسته‌ای
جمع وجوه ناخالصِ تعلق‌گرفته به یک Batch، منهای اقلام مستندِ کاهنده و به‌علاوه یا منهای تعدیلات معتبر، باید با خالص قابل تسویه و سپس با واریز بانک قابل آشتی باشد.
۷. حفظ مرز مشتری و شرکت
دسترسی مؤسسه حسابداری به چند پرونده، مجوز جابه‌جایی پول یا تخصیص دریافت یک شرکت به دیگری نیست؛ کنترل مالکیت حساب و شناسه سازمان الزامی است.
۸. کنترل‌های انسانی و حسابرسی
مغایرت حل‌نشده نباید بی‌صدا به هزینه کارمزد تبدیل شود.
تغییر وضعیت حساب دریافتنی، ثبت هزینه و آزادسازی سند قطعی نیازمند نقش مجاز و ردپای قابل رسیدگی است.
پنج آزمون پذیرش با اعداد ساختگی
آزمون اول — کارمزد واقعی
سه وصول معتبر جمعاً ۵۰۰ و کارمزد مستند ۱۰ باشد؛ سیستم باید ۴۹۰ را با بانک تطبیق دهد و دریافتنی را مطابق مستندات تسویه کند.
آزمون دوم — داده کارمزد مفقود
۴۹۰ به بانک برسد ولی هیچ گزارش معتبر درباره ده میلیون اختلاف موجود نباشد؛ سیستم نباید خودکار «هزینه کارمزد» ثبت کند و باید پرونده باز بسازد.
آزمون سوم — یک واریز از دو روز
پرداخت‌ها در روزهای جدا رخ دهند ولی در یک Batch واریز شوند؛ تطبیق باید بر اساس شناسه دسته و اقلام آن باشد، نه برابری تاریخ.
آزمون چهارم — وب‌هوک تکراری
یک تراکنش با یک شناسه دو بار دریافت شود؛ جمع وصول و اسناد مالی نباید دوبل شوند.
آزمون پنجم — شرکت اشتباه
واریز متعلق به شرکت «الف» به اشتباه در صفحه مشتری شرکت «ب» ظاهر شود؛ سیستم باید پیش از تخصیص، اختلاف مالکیت را متوقف کند.
برنامه چهار هفته‌ای برای استقرار آزمایشی
هفته اول: جریان دریافت وجه از فاکتور تا بانک را در یک شرکت و یک پردازشگر مستند کنید. داده‌های مورد نیاز و مالک هر شناسه را مشخص کنید.
هفته دوم: حساب واسط، شناسه Batch، قواعد کارمزد، کنترل دوره و وضعیت‌های پرداخت را در محیط آزمایشی طراحی کنید.
هفته سوم: نمونه‌های کارمزد، برگشت وجه، تأخیر، داده ناقص و رویداد تکراری را با پاسخ مرجع متخصص مالی آزمایش کنید. اجازه ندهید مدل زبانی به‌تنهایی سند قطعی صادر کند.
هفته چهارم: داشبورد «وصول ناخالص، هزینه پردازش، تسویه خالص، مانده باز واسط، اقلام حل‌نشده و واریز بانک» را بسازید و با اسناد واقعی مجاز مقایسه کنید.
فرصت محصولی برای حسابداران برتر
پیشنهاد توسعه «رادار هوشمند تسویه ناخالص و خالص درگاه‌های پرداخت» است؛ لایه‌ای بین سامانه صدور فاکتور، حساب‌های دریافتنی، API پردازشگر، صورتحساب بانک و دفتر کل.
هسته قطعی باید مالکیت وجوه، تاریخچه پرداخت، شناسه دسته تسویه، فرمول کارمزد، ریز اسناد و تطبیق بانک را کنترل کند.
لایه AI فقط دسته‌بندی علت مغایرت، اولویت‌بندی موارد و توضیح شواهد را به حسابدار کمک کند.
برای بازار ایران، پشتیبانی از ریال و تومان، تقویم شمسی، چندشرکتی‌بودن، مستندات تسویه پرداخت‌یارها، مجوز دسترسی بانک و ثبت‌های مالیاتی مطابق مقررات معتبر روز ضروری است.
خبر Xero/Melio ادعای اتصال مستقیم محصولات خارجی به شبکه پرداخت ایران یا وجود این ماژول در محصولات کنونی حسابداران برتر نیست.
جمع‌بندی: کسری واریز همیشه کسری پرداخت مشتری نیست
در مثال، سه مشتری ۵۰۰ میلیون ریال پرداخت کرده‌اند و ۴۹۰ میلیون ریال به بانک شرکت رسیده است.
اگر طبق قرارداد و ریزتراکنش معتبر، ۱۰ میلیون ریال کارمزد پردازش کسر شده باشد، این اختلاف دلیلی برای باز نگه‌داشتن ده میلیون ریال از بدهی مشتری یا کاهش خودکار رقم فروش نیست.
اما بدون سند معتبر نیز نباید هر اختلافی را «کارمزد» نامید.
مسیر قابل دفاع:
فاکتور صادرشده ← وصول معتبر مشتری ← شناسایی مبلغ ناخالص ← کارمزد و تعدیلات مستند ← مانده واسط ← تسویه دسته‌ای ← واریز بانک ← بازبینی و ثبت قطعی.
هوش مصنوعی بررسی و کمک می‌کند؛ حسابدار کنترل، تحلیل و قضاوت می‌کند.
برای مطالعه راهکارهای مالی هوشمند و عضویت، از لینک «عضویت در حسابداران برتر» در بخش بعدی استفاده کنید.
عضویت در حسابداران برتر
برای آشنایی با راهکارهای نرم‌افزاری، کنترل‌های هوشمند مالی و تازه‌ترین مطالب حسابداری، به حسابداران برتر بپیوندید.