مقدمه: مشتری قبلاً پول داده، اما فاکتور هنوز کل مبلغ را نشان می‌دهد
یک شرکت طراحی و پیاده‌سازی نرم‌افزار با مشتری خود بر سر پروژه‌ای به مبلغ ۸۰۰ میلیون ریال توافق می‌کند. مشتری در آغاز کار ۲۴۰ میلیون ریال بیعانه می‌پردازد. شرکت پس از اتمام و تحویل معتبر پروژه، صورتحساب نهایی به مبلغ ۸۰۰ میلیون ریال صادر می‌کند. دستیار مالی که فقط مبلغ فاکتور را می‌بیند، به واحد وصول گزارش می‌دهد: «مشتری ۸۰۰ میلیون ریال بدهکار است».
اما مشتری بخشی از همین تعهد را قبلاً پرداخته و پرداخت او به پروژه و قرارداد معین مربوط است. اگر بیعانه واقعاً دریافت شده، قبلاً به قرارداد دیگری تخصیص نیافته و اکنون مطابق شرایط قرارداد قابل اعمال باشد، مانده قابل مطالبه فقط ۵۶۰ میلیون ریال است. مبلغ صورتحساب ۸۰۰ میلیونی درست است؛ مبلغ باقیمانده برای وصول همان ۸۰۰ میلیون نیست.
اشتباه مهم‌تر زمانی رخ می‌دهد که شرکت بیعانه ۲۴۰ میلیونی را در روز دریافت «درآمد فروش» بنامد و سپس هنگام تحویل، کل ۸۰۰ میلیون را بار دیگر درآمد شناسایی کند. در این حالت در مفروضات مثال، درآمد به‌جای ۸۰۰ به ۱٬۰۴۰ میلیون ریال می‌رسد؛ یعنی ۲۴۰ میلیون ریال بیش‌نمایی.
مسئله این مقاله، انتخاب زمان درآمد در قراردادهای چندتعهدی نیست. موضوع اصلی حفظ ارتباط یکتا میان پیشنهاد قیمت، تأیید مشتری، پرداخت اولیه، صورتحساب نهایی و تسویه پیش‌دریافت در نرم‌افزار حسابداری هوشمند است.
رویداد تازه: اتصال امضای پیشنهاد قیمت، بیعانه و فاکتور در QuickBooks
شرکت Intuit در مجموعه به‌روزرسانی‌های پاییز ۲۰۲۶ QuickBooks که از ۲۶ اکتبر ۲۰۲۶ معرفی شد، گردش‌کاری را توضیح می‌دهد که در آن مشتری می‌تواند پیشنهاد قیمت را امضا کند، بیعانه بپردازد و سپس پیشنهاد به فاکتور تبدیل شود؛ بیعانه دریافت‌شده به فاکتور نهایی اعمال می‌شود. اطلاعیه سازنده درباره محصولات و شرایط دسترسی بازارهای پشتیبانی‌شده است و تصریح می‌کند بعضی امکانات بسته به محصول، اشتراک و تاریخ عرضه متفاوت‌اند.
راهنمای رسمی QuickBooks نیز شرح می‌دهد که مبالغ دریافتی بابت پیشنهاد قیمت در حساب بدهی نگهداری می‌شوند و هنگام اتمام کار و تبدیل پیشنهاد به فاکتور به‌عنوان پرداخت جزئی به صورتحساب اعمال می‌گردند. این رفتار یک نمونه اجرایی از تفکیک وجه دریافت‌شده از درآمد تحقق‌یافته است.
این گزارش به معنی وجود چنین خدمت بانکی در ایران، اعتبار حقوقی خودکار امضای دیجیتال خارجی، یا اجرای قطعی همه ویژگی‌ها در همه نسخه‌های QuickBooks نیست. مثال عددی مقاله ساخته تحریریه است؛ هیچ خطایی به محصول سازنده نسبت داده نمی‌شود.
چهار مفهوم که در گزارش مالی نباید مخلوط شوند
پیشنهاد قیمت یا پیش‌فاکتور: بیان مبلغ و شروط پیشنهادی معامله است. وجود پیش‌فاکتور، به‌تنهایی به معنی انتقال خدمت، شناخت درآمد یا ایجاد حساب دریافتنی قطعی نیست. شرایط حقوقی قرارداد و استاندارد گزارشگری تعیین‌کننده‌اند.
دریافت بیعانه یا پیش‌دریافت: ورود وجه به بانک است، اما اگر واحد تجاری هنوز متعهد به ارائه کالا یا خدمت باشد، در شرایط مربوط بدهی ناشی از قرارداد به وجود می‌آورد. دریافت وجه نباید خودکار به فروش قطعی تبدیل شود.
صدور صورتحساب: مبلغ مطالبه و ارجاع به قرارداد را مشخص می‌کند؛ زمان شناخت درآمد ممکن است با صدور فاکتور یکسان یا متفاوت باشد. در مثال، برای سادگی، فرض می‌کنیم خدمت در زمان صدور فاکتور کاملاً انجام شده است.
مانده قابل وصول: حق مطالبه‌ای است که پس از اعمال وجوه قبلی معتبر و سایر تعدیلات مجاز باقی می‌ماند. رقم مبلغ ناخالص صورتحساب با مانده باز صورتحساب یکی نیست.
مثال عددی: ۸۰۰ میلیون قرارداد، ۲۴۰ میلیون پرداخت قبلی، ۵۶۰ میلیون مانده
همه اشخاص و ارقام فرضی‌اند و واحد مبالغ جدول میلیون ریالاست. فرض می‌کنیم قرارداد خدمات تک‌تعهدی به مبلغ ثابت ۸۰۰ وجود دارد، خدمت فقط در زمان تحویل نهایی تحقق می‌یابد، بیعانه ۲۴۰ واقعاً به بانک شرکت رسیده، معامله مشمول مالیات و عوارض جدا در این مثال نیست، هیچ کارمزد درگاه یا تعدیل قیمت نداریم و کل ۲۴۰ میلیون فقط متعلق به همین قرارداد است.
| رویداد | دریافت نقد | درآمد تحقق‌یافته تجمعی | بدهی قرارداد | دریافتنی باز |
|---|---|---|---|---|
| عقد قرارداد و صدور پیشنهاد؛ قبل از پرداخت | صفر | صفر | صفر | صفر |
| دریافت بیعانه از مشتری | ۲۴۰ | صفر | ۲۴۰ | صفر |
| تحویل خدمت و صدور فاکتور ۸۰۰ میلیونی | صفر | ۸۰۰ | پیش از تسویه پیش‌دریافت: ۲۴۰ | ۸۰۰ ناخالص |
| اعمال بیعانه قبلی به همان فاکتور | صفر | ۸۰۰ | صفر | ۵۶۰ |
| وصول مانده نهایی از مشتری | ۵۶۰ | ۸۰۰ | صفر | صفر |
۸۰۰ − ۲۴۰ = ۵۶۰ میلیون ریال مانده قابل وصول پس از اعمال پیش‌دریافت.
۲۴۰ + ۵۶۰ = ۸۰۰ میلیون ریال جمع وجوه نقد دریافتی برای این پروژه پس از تسویه کامل.
درآمد تحقق‌یافته این پروژه در مفروضات مثال ۸۰۰ میلیون ریالاست؛ نه ۲۴۰، نه ۵۶۰ و نه ۱٬۰۴۰ میلیون ریال. دریافت نقد نهایی و درآمد نهایی با هم برابر می‌شوند، ولی زمان وقوع و ماهیت مراحل آنها یکسان نیست.
ثبت حسابداری نمونه در چهار گام
گام اول ـ دریافت وجه پیش از انجام خدمت: بدهکار بانک ۲۴۰؛ بستانکار بدهی ناشی از قرارداد / پیش‌دریافت مشتری ۲۴۰.
گام دوم ـ تحویل کامل خدمت و شناخت درآمد هنگام صدور فاکتور: بدهکار حساب‌های دریافتنی مشتری ۸۰۰؛ بستانکار درآمد ارائه خدمات ۸۰۰.
گام سوم ـ اعمال پیش‌دریافتِ معتبر به فاکتور همان قرارداد:بدهکار بدهی ناشی از قرارداد ۲۴۰؛ بستانکار حساب‌های دریافتنی مشتری ۲۴۰.
گام چهارم ـ دریافت مانده قطعی: بدهکار بانک ۵۶۰؛ بستانکار حساب‌های دریافتنی مشتری ۵۶۰.
در پایان: مجموع دریافت بانک از مشتری ۸۰۰، درآمد تحقق‌یافته ۸۰۰، مانده دریافتنی صفر و مانده پیش‌دریافت صفر است. این ثبت‌ها فقط برای فرض تحویل کامل و ایجاد حق غیرمشروط دریافت وجه در همان تاریخ فاکتور طراحی شده‌اند. اگر درآمد طی زمان شناسایی شود یا فاکتور زودتر از تحقق خدمت صادر شود، ترتیب و سرفصل ثبت‌ها تغییر می‌کند.
خطر اول: بیعانه یک بار در بانک و بار دیگر در درآمد ثبت می‌شود
اگر عامل هوشمند برای وصول ۲۴۰ میلیون ریالی در ابتدای پروژه، «بانک بدهکار، درآمد بستانکار» صادر کند و سپس هنگام تکمیل پروژه درآمد ۸۰۰ میلیونی را هم ثبت کند، درآمد تجمعی پروژه ۱٬۰۴۰ میلیون ریال گزارش می‌شود.
این اشتباه در نگاه نخست ممکن است پنهان بماند؛ زیرا گزارش بانک واقعی است و فاکتور ۸۰۰ میلیونی نیز با قرارداد سازگار است. ایراد در استفاده دوباره از همان جریان اقتصادی است. اصلاح آن باید با شناسایی سند اولیه، وضعیت دوره مالی، مدارک قرارداد و مانده واقعی بدهی ناشی از قرارداد انجام شود؛ نباید صرفاً با یک سند بی‌منشأ، درآمد را ۲۴۰ میلیون ریال کاهش داد.
اگر اصل بیعانه قابل استرداد باشد، یا پروژه لغو شود، تکلیف وجه تابع مفاد قرارداد و تعهدات معتبر است. غیرقابل‌استرداد بودن یک مبلغ نیز به‌تنهایی به معنی امکان شناسایی فوری درآمد نیست؛ باید ماهیت تعهدات عملکردی بررسی شود.
خطر دوم: پیش‌دریافت در حساب بدهی می‌ماند اما مشتری کل فاکتور را بدهکار نشان می‌دهد
حتی اگر حسابدار در ابتدای کار، مبلغ ۲۴۰ را درست در پیش‌دریافت ثبت کند، ممکن است هنگام تبدیل پیش‌فاکتور به صورتحساب، اتصال بین دو سند از بین برود. در آن صورت ERP هم‌زمان ۲۴۰ میلیون ریال بدهی ناشی از قرارداد و ۸۰۰ میلیون ریال حساب دریافتنی مشتری نشان می‌دهد؛ درحالی‌که با فرض امکان اعمال پیش‌دریافت، مانده دریافتنی قابل مطالبه ۵۶۰ است.
این وضعیت، اگر بدون توضیح در داشبورد باقی بماند، می‌تواند سبب صدور یادآوری پرداخت نادرست، توقف اعتبار مشتری یا اشتباه در پیش‌بینی وصول شود. رفع آن الزاماً «تهاتر آزاد تمام مانده‌های مشتری» نیست: باید مشخص باشد بیعانه مربوط به همین قرارداد و همین شخصیت حقوقی است، در شرایط قرارداد اجازه اعمال دارد و قبلاً در فاکتور دیگری مصرف نشده است.
بنابراین کنترل باید در سطح شناسه پرداخت اولیه و رابطه با فاکتور نهایی اجرا شود؛ تطبیق صرفاً بر اساس نام مشتری و مبلغ کافی نیست.
خطر سوم: تأیید پیش‌فاکتور با اثبات ایفای خدمت اشتباه گرفته می‌شود
امضای پیشنهاد قیمت یا قبول پیش‌فاکتور می‌تواند برای اثبات توافق تجاری اهمیت داشته باشد، اما تأیید مشتری با تحویل کالا یا ارائه خدمت یکسان نیست. در محصول خارجی، ممکن است بعد از امضا و دریافت بیعانه، فاکتور اداری به‌صورت خودکار ساخته شود؛ برای گزارشگری مالی باید جدا بررسی کرد که چه مقدار از تعهد عملکردی واقعاً ایفا شده است.
فرض کنید پروژه ۸۰۰ میلیونی هنوز آغاز نشده و ۲۴۰ میلیون ریال دریافت شده است. مطابق مفروضات اصلی، درآمد شناسایی‌شده همچنان صفر و بدهی قرارداد ۲۴۰ است؛ صرف اینکه مشتری پیشنهاد را امضا کرده یا سیستم یک صورتحساب ساخته، باعث شناخت ۸۰۰ میلیون ریال درآمد نمی‌شود.
اگر از قرارداد، حق دریافت وجه پیش از ایفای تعهد ایجاد شده باشد، ارائه بدهی قرارداد و دریافتنی در شرایط خاص می‌تواند پیچیده‌تر شود. در مثال اصلی عمداً فرض کردیم فاکتور نهایی پس از انجام کامل خدمت صادر شده تا مسئله اعمال پیش‌دریافت از مسئله زمان شناخت درآمد جدا بماند.
استاندارد ۴۳ ایران و IFRS 15 چه می‌گویند؟
در استاندارد حسابداری شماره ۴۳ ایران «درآمد عملیاتی حاصل از قرارداد با مشتریان»، اصل تمایز بدهی ناشی از قرارداد از درآمد عملیاتی تحقق‌یافته مطرح است. طبق بند ۱۰۷ متن منتشرشده، اگر قبل از انتقال کالا یا خدمت، مشتری تمام یا بخشی از مابه‌ازا را بپردازد، واحد تجاری در زمان پرداخت بدهی ناشی از قرارداد شناسایی می‌کند. پیوست استاندارد نیز به کاهش بدهی ناشی از قرارداد در زمان ایفای تعهد و شناخت درآمد اشاره دارد.
در چارچوب بین‌المللی، بندهای ۱۰۵ و ۱۰۶ IFRS 15 رابطه بین عملکرد شرکت و پرداخت مشتری، و ارائه بدهی قرارداد هنگام دریافت وجه پیش از انتقال کالا یا خدمت را بیان می‌کنند. وجود یک صورتحساب یا رسید بانک، جانشین ارزیابی تعهد عملکردی نیست.
نکته مهم این است که استفاده از واژه «بیعانه»، «ودیعه»، «پیش‌پرداخت» یا «پیش‌دریافت» در متن قرارداد به‌تنهایی ماهیت حسابداری را تعیین نمی‌کند. اگر وجه ماهیت تضمینی، امانی یا وثیقه داشته باشد، باید تحلیل حقوقی و حسابداری جداگانه صورت گیرد. این مقاله تنها درباره پیش‌دریافت مربوط به بهای خدمات آینده است.
یک گزارش مالی باید پنج عدد را مستقل نشان دهد
در طراحی داشبورد مشتریان، بهتر است برای هر قرارداد این فیلدها مستقل باشند: مبلغ قراردادی تأییدشده، وجه دریافت‌شده پیش از ایفای تعهد، درآمد تحقق‌یافته، مبلغ ناخالص فاکتور صادرشده و مانده باز قابل وصول.
یک ستون با نام کلی «مبلغ فروش» یا «مبلغ پرداختی» این پنج مفهوم را پوشش نمی‌دهد. همچنین وضعیت عملیات باید تاریخ‌دار باشد: «درخواست بیعانه صادر شد» با «بیعانه در بانک وصول شد» و «مبلغ به فاکتور اعمال شد» فرق دارد.
در مثال ما، پس از صدور فاکتور و اعمال بیعانه: مبلغ قرارداد ۸۰۰، وجه وصول‌شده قبلی ۲۴۰، درآمد تحقق‌یافته ۸۰۰، مبلغ ناخالص فاکتور ۸۰۰ و مانده باز ۵۶۰ میلیون ریال است. این فیلدها متناقض نیستند؛ هرکدام مفهوم متفاوتی دارند.
وقتی مشتری قرارداد را تغییر می‌دهد، بیعانه چه می‌شود؟
اگر پس از دریافت ۲۴۰ میلیون ریال، محدوده پروژه کاهش یابد و مبلغ نهایی از ۸۰۰ به ۷۰۰ میلیون ریال برسد، با فرض معتبر بودن تغییر و امکان اعمال کل بیعانه، مانده پس از صدور فاکتور نهایی ۴۶۰ میلیون ریال خواهد بود. این عدد فقط پس از بررسی نسخه معتبر توافق، تصویب تغییر مبلغ و مدارک تحویل قابل اتکاست.
برعکس اگر مبلغ نهایی به ۹۰۰ افزایش یابد، بیعانه قبلی بدون پرداخت مجدد همان ۲۴۰ باقی می‌ماند و مانده فرضی به ۶۶۰ میلیون ریالمی‌رسد. عامل نباید هنگام دریافت نسخه جدید قرارداد، ۲۴۰ میلیون را دوباره «دریافت جدید» ثبت کند.
در راهنمای امضای الکترونیکی پیشنهاد قیمت QuickBooks نیز تغییر بعضی اقلام پس از امضا، می‌تواند موجب نیاز به پذیرش نسخه جدید شود. این یک قاعده و جریان‌کار همان محصول در بازار هدف است و تعیین‌کننده اعتبار امضای دیجیتال در ایران نیست. برای قرارداد داخلی باید مفاد توافق و مقررات مربوط بررسی شوند.
دو پرداخت هم‌مبلغ، دو مشتری متفاوت
مؤسسه ممکن است هم‌زمان برای مشتری «الف» و «ب» قراردادهایی با مبلغ ۸۰۰ میلیون ریال داشته باشد و هر دو ۲۴۰ میلیون ریالبیعانه بپردازند. اگر سیستم صرفاً از مبلغ و تاریخ استفاده کند، ممکن است بیعانه «الف» را به فاکتور «ب» منتقل کند و ظاهراً مانده یکی را کاهش دهد.
کلید تطبیق باید شامل شناسه شخصیت حقوقی مشتری، شناسه قرارداد، شناسه پیش‌فاکتور و نسخه، شناسه رسید پرداخت معتبر و شناسه صورتحساب مقصد باشد. هر ریال پیش‌دریافت، پس از اعمال به فاکتور، باید «مصرف‌شده» تلقی شود و بدون سند اصلاحی معتبر دوباره در قرارداد دیگری قابل استفاده نباشد.
این کنترل با مغایرت‌گیری صرف بانک یا تشخیص مشتری از روی نام واریزکننده فرق دارد؛ ممکن است شخص ثالث به نمایندگی از مشتری پرداخت کند. در این صورت نیز رابطه نمایندگی و حق اعمال وجه به قرارداد باید مستند باشد.
هشت کنترل لازم برای چرخه فروش هوشمند
۱. شناسنامه یکتای قرارداد: پیشنهاد قیمت، امضای مشتری، نسخه تغییر، پروژه و صورتحساب نهایی باید به یک شناسه تجاری معتبر مرتبط باشند.
۲. ثبت مستقل وضعیت پول: درخواست پرداخت، آغاز پرداخت، وصول تأییدشده بانک، برگشت وجه و اعمال به فاکتور، رویدادهایی مستقل‌اند. پیام موفقیت درگاه بدون شواهد کافی، دریافت قطعی نیست.
۳. حساب بدهی برای پیش‌دریافت واجد شرایط: وجه قبل از ایفای تعهد نباید خودکار درآمد شود؛ ماهیت وجه براساس قرارداد و استاندارد تعیین شود.
۴. قفل مصرف یک‌باره بیعانه: هر پرداخت اولیه دارای مبلغ قابل تخصیص، مبلغ اعمال‌شده و مانده آزاد باشد؛ مجموع اعمال‌ها از وجه معتبر بیشتر نشود.
۵. کنترل زمان شناخت درآمد: صدور فاکتور از روی پیش‌فاکتور با تحقق خدمت اشتباه نشود؛ مدارک تحویل یا پیشرفت، جدا بررسی شوند.
۶. تطبیق سه‌طرفه قرارداد، فاکتور و رسید: مبلغ قرارداد و آخرین اصلاح، صورتحساب و وجه واقعی بانک همگی باید به یک پرونده قابل رسیدگی متصل باشند.
۷. تفکیک مجوزها و تغییرات: AI حق آزادسازی اعتبار مشتری، تغییر حساب بانکی، صدور فاکتور قطعی یا استرداد وجه بدون اختیار مصوب نداشته باشد؛ اصلاح نسخه، اثر بر بیعانه را برای تأیید نمایش دهد.
۸. ردپای حسابرسی و گزارش استثنا: بیعانه‌های دریافت‌شده بدون قرارداد، فاکتورهای دارای پیش‌دریافت اعمال‌نشده، مصرف دوباره وجه، اختلاف مانده و برگشت‌های حل‌نشده جدا گزارش شوند.
ایران: پیش‌دریافت با صورتحساب الکترونیکی و مالیات یکسان نیست
در یک پرونده ایرانی، باید ثبت حسابداری پیش‌دریافت را از الزامات صدور و اصلاح صورتحساب الکترونیکی، مالیات بر ارزش افزوده و قواعد زمان تعلق مالیات جدا بررسی کرد. قانون و مقررات معتبر دوره و ماهیت معامله تعیین می‌کنند چه سند قانونی و در چه زمانی لازم است؛ مثال ما هیچ نرخ یا مهلت مالیاتی را مفروض نگرفته است.
صورتحساب ۸۰۰ میلیونی در مثال، مبلغ پایه فرضی پیش از مالیات و عوارض است. اگر معامله واقعی مشمول مالیات، کسور قراردادی، کارمزد یا تسویه چندمرحله‌ای باشد، محاسبه مانده و ثبت‌های قانونی باید براساس همان شرایط بازسازی شود.
همچنین «پیش‌فاکتور»، «پیشنهاد قیمت امضاشده» و «صورتحساب الکترونیکی دارای وضعیت معتبر در سامانه مؤدیان» سه مفهوم حقوقی و فرایندی متفاوت هستند. یک PDF امضاشده در یک نرم‌افزار خارجی، جایگزین خودکار اسناد قانونی لازم‌الاجرا در ایران نیست.
فرصت محصولی برای حسابداران برتر
برای برند تولیدکننده نرم‌افزارهای مالی و راهکارهای AI حسابداران برتر، ماژول پیشنهادی «نگهبان پیش‌دریافت و تسویه هوشمند فاکتور» می‌تواند حلقه میان پیش‌فاکتور، قرارداد، بانک، حساب بدهی قرارداد، صورتحساب نهایی و حساب‌های دریافتنیباشد.
این پیشنهاد توسعه محصول است و وجود فعلی چنین قابلیت یا اتصال بانکی آماده‌ای را در محصولات مجموعه ادعا نمی‌کند.
هسته قطعی ماژول، مانده پیش‌دریافت قابل استفاده، مبلغ مصرف‌شده در هر فاکتور و مانده باز حساب مشتری را محاسبه می‌کند. لایه AI سند صحیح را پیدا می‌کند، موارد فقدان تطبیق را توضیح می‌دهد و به حسابدار می‌گوید: «برای فاکتور ۸۰۰ میلیونی این قرارداد، ۲۴۰ میلیون ریال پیش‌تر دریافت شده؛ پس از اعمال معتبر آن، مانده قابل وصول ۵۶۰ میلیون ریال است.»
برای ایران، پشتیبانی از ریال و تومان، تقویم شمسی، نسخه قرارداد، مشتری چندشعبه‌ای، شناسه واریز یا رسید، اسناد مالیاتی معتبر، سطح دسترسی و تأیید حسابدار ضروری است. کلید اصلی، جدا کردن پیشنهاد AI از ثبت و تسویه قطعیاست.
اجرای آزمایشی چهار هفته‌ای
هفته اول: ۳۰ پروژه یا قرارداد فرضی یا بی‌نام‌سازی‌شده دارای پیشنهاد قیمت و پیش‌دریافت را انتخاب کنید. برای هر مورد، مبلغ قرارداد، نسخه، رسید معتبر بانک، تاریخ ایفای خدمت و فاکتور ثبت شود.
هفته دوم: پرونده‌هایی با بیعانه جزئی، دو مشتری هم‌مبلغ، قرارداد اصلاح‌شده، پروژه لغوشده، برگشت وجه و فاکتور قبل از تحویل بسازید. پاسخ مرجع هر سناریو را حسابدار متخصص تأیید کند.
هفته سوم: مدل تنها ارتباط اسناد و علت مغایرت را پیشنهاد دهد؛ موتور قطعی بازمحاسبه کند که مجموع وجوه اعمال‌شده از وجه معتبر بیشتر نباشد. اجازه صدور سند یا انتقال وجه واقعی فعال نباشد.
هفته چهارم: تعداد بیعانه‌های اعمال‌نشده، مبلغ درآمد زودهنگام یا مضاعف کشف‌شده، موارد مصرف دوباره وجه، فاکتورهای با مانده اشتباه و زمان رسیدگی اندازه‌گیری شود. ارزش پیش‌دریافت‌ها را به‌عنوان «درآمد بیشتر» یا «صرفه‌جویی نقدی» اعلام نکنید.
جمع‌بندی: بیعانه قبلی، فروش دوم نیست
در سناریوی آموزشی، مشتری قرارداد خدمات ۸۰۰ میلیون ریالیداشت، ۲۴۰ میلیون ریال را قبل از اجرای کار پرداخت کرد و پس از تحویل خدمت، صورتحساب کامل صادر شد. با ثبت درست بیعانه به‌عنوان بدهی ناشی از قرارداد و اعمال آن به فاکتور نهایی، مانده قابل وصول ۵۶۰ میلیون ریال باقی ماند.
در پایان تسویه، مجموع نقد دریافت‌شده ۸۰۰ میلیون ریال و درآمد تحقق‌یافته ۸۰۰ میلیون ریال است. اگر ۲۴۰ میلیون بیعانه و ۸۰۰ میلیون فاکتور هر دو درآمد تلقی شوند، در همین مفروضات درآمد ۲۴۰ میلیون ریال بیش‌نمایی می‌شود.
هوش مصنوعی مالی زمانی ارزشمند است که فقط از پیشنهاد قیمت فاکتور نسازد؛ بلکه سابقه پول دریافت‌شده، تحقق خدمت، مجوز اعمال وجه و مانده واقعی مشتری را در یک مسیر قابل حسابرسی به هم متصل کند.
برای آشنایی با راهکارهای نرم‌افزاری و هوشمندسازی حسابداری:
https://hesabdaranebartar.com