پرداختنیها و تسویه جزئی نسیه
پرونده واقعی بدهی فروشنده، پیشپرداخت، فاکتور و پرداختهای چندمرحلهای
از خرید نسیه تا تسویه: فاکتور تأمینکننده، پیشپرداخت، پرداخت جزئی و سررسید
«امروز کالا خریدیم اما پولش را ماه بعد میدهیم» سه بخش دارد: دریافت کالا، ایجاد بدهی و پرداخت آینده. اگر هر سه را در یک فرم هزینه تکرار کنید، حسابداری و انبار مغایر میشوند. در آناما فاکتور پرداختنی جهت payable دارد، پرداخت درخواست/تأیید/اجرای مستقل دارد و دریافت کالا هم مسیر مجزای انبار است.
مثال کارگاهی با چهار زمان
۱ مهر، ۱۰۰۰ کیلو کالا به ارزش ۶۰ میلیون سفارش میدهید. ۳ مهر کالا را میگیرید و مقدار پذیرفتهشده را قطعی میکنید. ۵ مهر فاکتور فروشنده برای ۶۰ میلیون دریافت میشود. ۲۰ مهر ۲۰ میلیون و ۱۰ آبان ۴۰ میلیون میپردازید. با فرض نبود مالیات و مرجوعی و اینکه ثبت خرید به بدهی معتبر متصل باشد، پس از شناسایی بدهی، مانده فروشنده ۶۰ است؛ پس از پرداخت اول ۴۰ و بعد از پرداخت دوم صفر. مقدار موجودی با پرداخت کم و زیاد نمیشود؛ خرید فیزیکی و فروش/مصرف کالا آن را تغییر میدهند.
| مرحله | اثر وجه نقد | مانده پرداختنی | اثر کالا |
|---|---|---|---|
| سفارش خرید | ۰ | هنوز بدهی قطعی الزامی نیست | ۰ |
| رسید و پذیرش کالا | ۰ | تابع سند خرید/بدهی مرتبط | +۱۰۰۰ کیلو |
| فاکتور بدهی | ۰ | +۶۰ میلیون | ورود فیزیکیِ دوباره ممنوع |
| پرداخت ۲۰ میلیون | −۲۰ میلیون | ۴۰ میلیون مانده | بدون اثر |
| پرداخت ۴۰ میلیون | −۴۰ میلیون | صفر | بدون اثر |
این جدول نتیجه اقتصادی را نشان میدهد، نه اینکه الزاماً همه مراحل با یک سند در نرمافزار انجام شوند.
کدام فرم را انتخاب کنیم؟
اگر هزینه خدماتی یا قبضِ بدون ورود انبار است، مسیر supplier-expense-invoice با شخص، سررسید، سرفصل هزینه و اقلام مناسب است. اگر کالا برای فروش مجدد وارد انبار میشود، مسیر سفارش خرید و رسید کالای پذیرفتهشده را با فاکتور مرتبط نگه دارید. quick-purchase برای خرید ساده مصرفی/دارایی است و بهتنهایی گردش انبار ایجاد نمیکند. اگر بدهی قبلاً ثبت شده، هنگام تسویه بار دیگر هزینه یا موجودی بدهکار نکنید؛ باید حساب پرداختنی تسویه شود.
فیلدهای حساس در درخواست پرداخت
party ذینفع باید با طلبکار فاکتور تطبیق داشته باشد. amount نباید از مانده قابل پرداخت معتبر تجاوز کند مگر سناریو پیشپرداخت جداگانه مجاز باشد. due_on تاریخ برنامهریزی، purpose علت قابل جستوجو و source_account بانک مبدأ است. invoice مرجع بدهی و settlement_account حساب بدهکار برای پرداخت بدون فاکتور است. beneficiary_iban باید با مدارک ذینفع تطبیق داده شود. درخواست تأییدشده الزاماً به معنی انتقال موفق در بانک نیست.
پیشپرداخت به تأمینکننده
قبل از ورود کالا ۱۵ میلیون پرداخت کردهاید. در معنای اقتصادی ابتدا پیشپرداخت/طلب از تأمینکننده ایجاد میشود، نه هزینه مصرفی قطعی. وقتی کالا رسید و فاکتور شناسایی شد، مطابق فرایند مجاز، پیشپرداخت با بدهی تسویه میشود. اگر وجه بیشتری از بدهی پرداخت کردهاید، اضافه را در حساب مناسب پیگیری کنید، نه اینکه هزینه دیگری بسازید.
وقتی فروشنده هم مشتری شماست
ممکن است از آقای الف ۳۰ میلیون کالا بخرید و همزمان ۱۲ میلیون به او بفروشید. این دو مانده مستقلاند. خالصکردن خودکار ۱۸ میلیون بدون توافق معتبر و سند تهاتر ممکن است صورتحساب هر دو سمت را مخدوش کند. هر دو گردش را با تاریخ و مرجع مستقل نگه دارید؛ تهاتر را فقط از مسیر کنترلشده اجرا کنید.
کنترل سررسید و معوق
فاکتور باز، پرداخت جزئی، تسویه و سررسیدگذشته را از یکدیگر تفکیک کنید. برای اولویتبندی نقدینگی، تاریخ سررسید، شرایط قراردادی، جریمه دیرکرد، اهمیت تأمینکننده و موجودی بانک قابل استفاده را کنار هم ببینید. «جمع فاکتور پرداختنی» ممکن است همه بدهیهای دفترکل، وام، مالیات یا حقوق پرداختنی را پوشش ندهد؛ برای کل بدهی از وضعیت مالی همراه با دفترکل استفاده کنید.
خطایابی پرداخت دوم یا پرداخت تکراری
پیش از هر اقدام، وضعیت درخواست، حواله خزانه، شماره مرجع خارجی، ردیف صورتحساب بانک و کاهش حساب پرداختنی را کنترل کنید. اگر بانک دو برداشت دارد ولی یک درخواست، اول واقعیت بانکی را بررسی کنید؛ اگر دو درخواست با یک فاکتور ساخته شده، هر دو را بدون بررسی اجرا نکنید. اسناد قطعی را خام حذف نکنید؛ راه اصلاح با سند برگشتی و مدارک معتبر است.