مقدمه: پولی که به مشتریِ مشتری می‌رسد، همیشه هزینه تبلیغات نیست
یک پلتفرم نرم‌افزاری در پایان ماه بابت خدمات ارائه‌شده به فروشگاهی طرف قرارداد، ۱٬۰۰۰ میلیون ریال درآمد قراردادی اولیه در کاربرگ فروش دارد. برای افزایش خرید از همان فروشگاه، پلتفرم مطابق توافق تجاری به خریداران نهایی فروشگاه ۸۰ میلیون ریال اعتبار خرید اختصاص می‌دهد.
حسابدار پرداخت ۸۰ میلیونی را می‌بیند و آن را زیر عنوان «هزینه تبلیغات» قرار می‌دهد؛ داشبورد همچنان درآمد را ۱٬۰۰۰ میلیون ریال نمایش می‌دهد.
اما مدیر گزارشگری می‌پرسد: این پرداخت واقعاً بهای یک خدمت تبلیغاتی مجزا برای پلتفرم است، یا بخشی از تخفیف اقتصادی مرتبط با فروش خدمت به فروشگاه؟
گیرنده اعتبار، مشتری مستقیم پلتفرم نیست؛ مشتریِ فروشگاهِ طرف قرارداد است.
پاسخ، تنها با نام «کمپین»، «اعتبار هدیه» یا «پاداش وفاداری» مشخص نمی‌شود.
در صورت تحقق مفروضات مشخص این مقاله، پرداخت ۸۰ میلیونی ممکن است کاهنده قیمت معامله و درآمد باشد. در آن صورت درآمد ارائه‌شده ۹۲۰ میلیون ریال است، نه یک میلیارد.
این رقم در مثال آموزشی، نتیجه یک تحلیل فرضی است؛ نه تعیین تکلیف قطعی هر پرداخت واقعی یا یک حکم تازه برای شرکت‌های ایرانی.
خبر ۲۲ اکتبر ۲۰۲۶: پیشنهاد FASB درباره پرداخت به مشتریِ مشتری
هیئت استانداردهای حسابداری مالی آمریکا (FASB) در ۲۲ اکتبر ۲۰۲۶ پیش‌نویس یک به‌روزرسانی استاندارد حسابداری درباره Consideration Payable to a Customer در چارچوب ASC 606 — درآمد ناشی از قرارداد با مشتریان منتشر کرد.
مهلت ارائه دیدگاه‌ها تا ۲۳ نوامبر ۲۰۲۶ اعلام شده است.
طبق توضیح رسمی FASB، موضوع قابل‌بحث فقط پرداخت مستقیم فروشنده به مشتری خودش نیست: بعضی بنگاه‌ها برای مشتریانِ مشتری خود، یا از جانب مشتری، اعتبار، یارانه یا تخفیف تأمین می‌کنند.
پیش‌نویس می‌کوشد روشن کند در چه شرایطی چنین پرداخت‌هایی در ارتباط با ایفای تعهد نسبت به مشتری، مابه‌ازای پرداختنی به مشتری محسوب می‌شوند؛ برای مثال وقتی بنگاه پرداخت را صریحاً وعده داده یا مشتری انتظار معقول ناشی از وعده ضمنی یا تخفیف ماهوی دارد.
در چارچوب فعلی Topic 606، مابه‌ازای پرداختنی به مشتری اصولاً قیمت معامله و درآمد را کاهش می‌دهد، مگر پرداخت در برابر کالا یا خدمت متمایز و قابل تشخیص دریافتی از مشتری باشد.
پیشنهاد جدید عمدتاً مرز شناسایی بعضی گیرندگان خارج از زنجیره مستقیم فروش را روشن می‌کند و قاعده عمومی خدمت متمایز را کنار نمی‌گذارد.
مهم: تا تاریخ تهیه مقاله، این تغییر پیشنهادی است و نباید به‌عنوان الزام نهایی مصوب آمریکا یا قانونی لازم‌الاجرا در ایران معرفی شود.
بحث برای مدیران مالی ایرانی، بررسی یک مسئله اقتصادی مشترک و طراحی کنترل‌های نرم‌افزاری است. برای گزارشگری ایران، استاندارد حسابداری ۴۳، قرارداد واقعی و تفسیر حرفه‌ای الزامات قابل‌اعمال مرجع رسیدگی‌اند.
سه بازیگر را جدا کنیم: پلتفرم، فروشگاه و خریدار نهایی
در مثال فرضی، «پلتفرم الف» خدمت نرم‌افزاری و بازاریابی قراردادی را به «فروشگاه ب» می‌فروشد.
مشتری مستقیم پلتفرم، فروشگاه ب است.
«خریدار ج» از فروشگاه ب کالا می‌خرد و اعتبار ۸۰ میلیون ریالی را طبق یک برنامه ترویجی دریافت می‌کند.
جریان خدمت: پلتفرم ← فروشگاه ب.
جریان اعتبار تشویقی: پلتفرم ← خریداران نهایی فروشگاه ب.
اگر مدیر مالی فقط گیرنده وجه را بخواند، ممکن است نتیجه بگیرد چون پرداخت مستقیماً به مشتری خود شرکت انجام نشده، پس حتماً هزینه تبلیغات است.
اما برای این نتیجه‌گیری، هدف اقتصادی پرداخت، متن وعده و ارتباط آن با تعهد قراردادی نیز اهمیت دارد.
همچنین هر مبلغی که به خریدار نهایی داده می‌شود، خودکار کاهنده درآمد نیست. ممکن است شرکت از دریافت‌کننده یا فروشگاه، خدمت تبلیغاتی مستقل و قابل سنجشی دریافت کرده باشد.
تفاوت را باید با سند و نه نام حساب تصمیم گرفت.
مثال عددی اصلی: یک میلیارد درآمد اسمی، ۸۰ میلیون اعتبار خرید
تمام نام‌ها، قراردادها، ارقام و زمان‌بندی‌های این مثال آموزشی و ساختگی است.
ارقام برحسب میلیون ریال و پیش از مالیات و عوارض فرض می‌شوند.
فرض می‌کنیم خدمت پلتفرم به فروشگاه مطابق قرارداد ارائه شده، مبالغ قابل اتکاست، اختلاف دوره یا وصول وجود ندارد و شرایط مرتبط با کاهش قیمت معامله در تحلیل آموزشی احراز شده است.
محاسبه اصلی:
۱٬۰۰۰ − ۸۰ = ۹۲۰ میلیون ریال
نسبت اعتبار به قیمت اولیه:
۸۰ ÷ ۱٬۰۰۰ × ۱۰۰ = ۸٪
این ۸ درصد نرخ قانونی، مالیاتی یا نرخ عمومی تخفیف نیست؛ فقط نسبت دو مبلغ فرضی این پرونده است.
آنچه در این مثال به‌عنوان ۹۲۰ نشان داده می‌شود درآمد پس از تحلیل ماهیت پرداخت است، نه الزاماً مبلغ خالص واریزشده به حساب بانکی.
حالت دوم: اگر بخشی از ۸۰ میلیون، خرید یک خدمت متمایز باشد چه؟
اکنون فرض کنیم از همان ۸۰ میلیون ریال، مبلغ ۵۰ میلیون ریال واقعاً بابت یک خدمت تبلیغاتی مستقل است که فروشگاه ب به پلتفرم می‌دهد: خدماتی مشخص، دارای خروجی قابل تحویل و ارزش منصفانه قابل برآورد.
۳۰ میلیون ریال باقی‌مانده نیز طبق فرض پرونده، اعتبار ترویجی مرتبط با قرارداد فروشگاه به خریداران نهایی است.
این بار دو جزء جدا داریم: خرید خدمت از فروشگاه و اعتبار تشویقی مرتبط با معامله.
تحت مفروضات نمونه، درآمد ۹۷۰ میلیون ریال و هزینه خدمت تبلیغاتی ۵۰ میلیون ریال نمایش داده می‌شود.
حالت اول: ۹۲۰ − ۶۰۰ = ۳۲۰
حالت دوم: ۹۷۰ − ۶۰۰ − ۵۰ = ۳۲۰
در این مقایسه محدود، سود عملیاتی یکسان است؛ اما درآمد، سود ناخالص و حاشیه سود ناخالص یکسان نیستند.
اگر مدیر فقط به درآمد یا حاشیه سود ناخالص نگاه کند، دو گزارش می‌توانند تصویر متفاوتی از کسب‌وکار بدهند، درحالی‌که تفاوت در طبقه‌بندی و ماهیت مستند پرداخت است.
این دو حالت دو مجموعه مفروضات متفاوت هستند؛ نمی‌توان بدون قرارداد و مدرک ارزش منصفانه، به دلخواه از یکی به دیگری تغییر وضعیت داد.
چهار سؤال پیش از طبقه‌بندی پرداخت
یک ـ مشتری واقعی شرکت کیست؟
نام فروشگاه، خریدار نهایی و سایر واسطه‌ها باید با نقش اقتصادی‌شان در قرارداد مشخص شود. هر گیرنده وجهی مشتری مستقیم فروشنده نیست.
دو ـ آیا پرداخت صریحاً وعده داده شده است؟
اگر در قرارداد یا کمپین مورد توافق آمده که شرکت برای مشتریان فروشگاه اعتبار پرداخت می‌کند، این تعهد و ارتباطش با قرارداد فروش باید بررسی شود.
در شرایطی هم رفتار تجاری گذشته می‌تواند انتظار معقول ایجاد کند؛ تشخیص آن نیازمند شاهد است.
سه ـ آیا دریافت‌کننده یا طرف قرارداد در برابر پرداخت، خدمت مستقلی تحویل می‌دهد؟
صرف نوشتن عبارت «بازاریابی» روی یک فاکتور، اثبات خدمت متمایز نیست.
نوع خدمت، خروجی، استقلال آن و ارزش منصفانه قابل اتکا بررسی شود.
چهار ـ آیا پرداخت اساساً با ایفای تعهد شرکت نسبت به مشتری مرتبط است؟
اگر پرداخت مربوط به قرارداد دیگری یا خدمت مستقلی خارج از این رابطه باشد، طبقه‌بندی می‌تواند تغییر کند.
AI می‌تواند بندها و مدارک را بیابد، طرف‌های مرتبط را در یک نمودار نشان دهد و سناریوها را محاسبه کند؛ ولی تشخیص ماهیت اقتصادی و تصویب ارائه مالی باید با مسئول گزارشگری باشد.
زمان شناخت هم مهم است، نه فقط عنوان حساب
در چارچوب مرتبط با مابه‌ازای پرداختنی به مشتری، تاریخ ایجاد وعده، تاریخ ایفای تعهد و زمان شناخت درآمد ممکن است متفاوت باشند.
نتیجه را نباید فقط در روز انتقال وجه نقد ثبت کرد.
در استانداردهای مبتنی بر IFRS 15، در حالت کاهش قیمت معامله، زمان شناسایی کاهش درآمد با رابطه‌ای میان شناسایی درآمد مربوط و پرداخت یا وعده پرداخت مابه‌ازا سنجیده می‌شود.
برای واحد ایرانی، بندها و نسخه معتبر استاندارد حسابداری ۴۳ باید همراه قرارداد بررسی شوند.
در مثال ما فرض شده دو رویداد برای دوره مورد بحث قابل اعمال‌اند تا تمرکز بر طبقه‌بندی باشد.
مثال، پیشنهاد صدور سند برای تمام پرونده‌های مشابه در یک تاریخ واحد نیست.
ارتباط با ایران: استاندارد ۴۳، نه انتقال خودکار پیش‌نویس آمریکایی
تذکر تطبیقی: در متن استاندارد ۴۳، بند ۷۱ به برخی اشخاصی اشاره دارد که کالا یا خدمات واحد تجاری را از مشتری خریداری می‌کنند. خریدار فروشگاه در مثال ممکن است کالاهای خود فروشگاه را بخرد، نه خدمت پلتفرم را؛ بنابراین شمول دقیق این بند بر گیرنده اعتبار، نیازمند بررسی مستقل رابطه قراردادی است.
استاندارد حسابداری شماره ۴۳ ایران با موضوع «درآمد عملیاتی حاصل از قرارداد با مشتریان» چارچوب مرتبطی برای ارزیابی ماهیت این پرداخت‌ها دارد.
در متون منتشرشده استاندارد، پرداخت به مشتری، کالا یا خدمت متمایز و اثر بر قیمت معامله مطرح شده است.
بااین‌حال پیش‌نویس جدید FASB اصلاحیه‌ای به استاندارد ایران نیست.
برای پرداخت به شخصی بیرون از زنجیره مستقیم مشتری باید دامنه دقیق مقررات ایران و ماهیت قرارداد جداگانه تحلیل شود؛ نمی‌توان نتیجه پیشنهادی ASC 606 را بی‌واسطه الزام داخلی فرض کرد.
نکته دیگر آن است که کاهش درآمد در صورت‌های مالی، الزاماً تکلیف صدور یا اصلاح صورتحساب الکترونیکی، مالیات بر ارزش افزوده یا مالیات عملکرد را تعیین نمی‌کند.
این آثار تحت مقررات و اسناد معتبر روز و با نظر متخصص مالیاتی بررسی می‌شوند.
هوش مصنوعی چگونه می‌تواند مسئله را قبل از ثبت پیدا کند؟
در نرم‌افزار مالی، پرداخت‌های مرتبط با مشتری ممکن است زیر نام‌هایی مثل «اعتبار کیف پول»، «کد تخفیف»، «یارانه خرید اقساطی»، «کمک‌هزینه تبلیغات» یا «هزینه جذب مشتری» پراکنده باشند.
بسیاری از این پرداخت‌ها فقط در حسابداری هزینه دیده می‌شوند و به قرارداد درآمد متصل نیستند.
یک عامل هوشمند می‌تواند طرف‌های معامله، قرارداد فروش، بند تعهد تشویقی، شناسه کمپین، گیرنده نهایی، مبلغ پرداختی و شواهد خدمت متمایز را در یک پرونده گردآوری کند.
سپس یک موتور قطعی، پس از تعیین دسته‌بندی مصوب، سه خروجی جدا بسازد:
درآمد کاهنده‌شده، هزینه خدمت متمایز و موارد مبهم در انتظار رسیدگی.
مدل نباید از عبارت «هدیه»، «آفر» یا «مارکتینگ» به‌تنهایی درباره حساب مالی تصمیم بگیرد و نباید بدون تأیید حرفه‌ای، صورت سود و زیان نهایی را بازنویسی کند.
هشت کنترل نرم‌افزاری ضروری برای اعتبارها و پاداش‌های پرداختی
۱. شناسنامه زنجیره طرف‌های قرارداد
فروشنده، مشتری مستقیم، مشتریِ مشتری و گیرنده نهایی هر پرداخت با شناسه حقوقی یا عملیاتی معتبر ثبت شوند؛ دو اسم مشابه نباید یکی فرض شوند.
۲. پیوند پرداخت به قرارداد درآمد
هر اعتبار ترویجی شناسه کمپین، قرارداد مرتبط، دوره و بند وعده پرداخت داشته باشد. نبود پیوند، استثنا ایجاد کند.
۳. تفکیک اعتبار تشویقی از خدمت متمایز
اطلاعات مربوط به تحویل خدمت، استقلال آن و مبنای ارزش منصفانه از برچسب تبلیغاتی جدا نگهداری شود.
۴. موتور قطعی محاسبه و سناریو
مجموع اعتبارها، سقف برنامه، سهم کاهنده درآمد و سهم هزینه مستقل براساس مفروضات تأییدشده محاسبه شود؛ نه با جمع‌زدن آزاد مدل زبانی.
۵. کنترل تاریخ و نسخه سیاست
زمان قرارداد، تحقق خدمت، وعده پرداخت، تخصیص اعتبار و اصلاحات بعدی جدا باشند. سیاست‌های دوره جدید بی‌اجازه به معاملات قبلی سرایت نکنند.
۶. عدم‌تکرار اعتبارها
اعتبار خریدی که هم در پلتفرم، هم در گزارش فروشگاه و هم در درگاه تسویه دیده می‌شود، سه بار کاهنده درآمد یا هزینه ثبت نشود.
۷. کنترل آثار گزارشگری و مالیات مستقل
پیشنهاد طبقه‌بندی حسابداری، نحوه صدور سند، صورتحساب الکترونیکی و تحلیل مالیاتی چهار گام قابل بررسی‌اند؛ یک خروجی AI نباید همه آن‌ها را قطعی اعلام کند.
۸. امضای مسئول و دفتر شواهد
طبقه‌بندی، استدلال، سند قرارداد، مبلغ، کاربر تصویب‌کننده و تاریخ در یک پرونده نسخه‌دار ثبت شود.
شش آزمون پذیرش قبل از راه‌اندازی ماژول
آزمون نخست ـ وعده صریح: در قرارداد پلتفرم و فروشگاه پرداخت ۸۰ میلیون ریال اعتبار مرتبط با فروش خدمت پیش‌بینی شده و خدمت متمایز وجود ندارد؛ سامانه باید برای بررسی و تحت مفروضات حسابداری معتبر سناریوی ۹۲۰ میلیون ریالی را بسازد.
آزمون دوم ـ خدمت متمایز: از پرداخت ۸۰ میلیونی، ۵۰ میلیون ریال بابت خدمت مستقل دارای مدارک و ارزش منصفانه قابل اتکا و ۳۰ میلیون بابت اعتبار است؛ سناریوی ۹۷۰ درآمد و ۵۰ هزینه مستقل تولید شود.
آزمون سوم ـ خدمت ادعایی بدون مدرک: نام پرداخت «هزینه تبلیغات» است، اما خروجی خدمت و ارزش آن احراز نشده؛ سیستم نباید بر اساس نام حساب، کل ۸۰ را هزینه جداگانه قطعی اعلام کند.
آزمون چهارم ـ پرداخت خارج از قرارداد: اعتبار به گیرنده‌ای نامرتبط با فروشگاه یا قرارداد تعلق دارد؛ نباید خودکار درآمد قرارداد فروشگاه کاهش یابد.
آزمون پنجم ـ اعتبار تکراری: گزارش کیف پول و گزارش تسویه یک اعتبار واحد را با دو شناسه فنی نشان می‌دهند؛ مبلغ اقتصادی پرداخت دوبار شمارش نشود.
آزمون ششم ـ تفاوت مقررات: کاربر نسخه پیشنهادی ASU آمریکا را به‌عنوان قانون ایران انتخاب می‌کند؛ سامانه باید هشدار «دامنه مقررات و وضعیت پیشنهادی» نمایش دهد و تصمیم نهایی را به متخصص واگذار کند.
در هر آزمون، جواب مرجع، مدارک و نقش تصویب‌کننده باید پیش از فعال‌سازی عامل مشخص شده باشد.
برنامه اجرای آزمایشی چهار هفته‌ای
هفته نخست: قراردادهای دارای اعتبار خرید، تخفیف مصرف‌کننده، پاداش وفاداری یا یارانه پرداخت را از میان داده‌های مجاز انتخاب کنید. زنجیره طرف‌های هر قرارداد را مستند سازید.
هفته دوم: برای هر کمپین، مبلغ، تاریخ، دریافت‌کننده، وعده صریح یا ضمنی، شواهد خدمت متمایز و مبنای ارزش‌گذاری را ثبت کنید. از داده‌های واقعی محرمانه در محیط آزمایش عمومی استفاده نکنید.
هفته سوم: موتور محاسبه سناریوهای کاهش درآمد، هزینه مستقل و پرداخت‌های مبهم را با داده ساختگی آزمون کنید. بررسی کنید مجموع پرداخت‌ها دقیقاً یک‌بار در خروجی لحاظ شده باشد.
هفته چهارم: داشبورد «درآمد پایه، اعتبار پرداختی، کاهنده درآمد، هزینه مستقل، موارد معلق و رأی بازبین» را تهیه و به گزارشگری مالی متصل کنید؛ آثار قوانین و استانداردهای داخلی فقط پس از بررسی متخصص در محیط واقعی اعمال شوند.
فرصت توسعه نرم‌افزاری برای حسابداران برتر
پیشنهاد توسعه «بازبین هوشمند اعتبارهای مشتری و اثر آن بر درآمد» است؛ ماژولی بین نرم‌افزار قرارداد، فروش، برنامه‌های وفاداری، کیف پول مشتری، حسابداری و گزارش‌ساز مالی.
هسته قطعی باید شناسه طرف‌ها، سند تعهد، ارزش اعتبار، تاریخ اثر، کنترل تکرار و منطق طبقه‌بندی مصوب را مدیریت کند.
لایه AI می‌تواند بندهای مرتبط را پیدا کند، روابط میان پلتفرم و فروشگاه و خریدار نهایی را ترسیم کند، شواهد ناقص را مشخص و سناریوهای مالی را توضیح دهد.
برای ایران، ریال و تومان، تقویم شمسی، قراردادهای چندطرفه، شناسه مشتری و کسب‌وکار، تفکیک مالیات و درآمد و سطوح اختیار تأیید باید براساس الزامات معتبر روز طراحی شوند.
این پیشنهاد محصول است، نه ادعای وجود فعلی آن در سامانه حسابداران برتر یا عرضه محصولات FASB در ایران.
جمع‌بندی: گیرنده وجه مهم است، اما ماهیت قرارداد مهم‌تر است
در مثال ساختگی، پلتفرم از فروشگاه ۱٬۰۰۰ میلیون ریال قیمت اولیه خدمت دارد و طبق تعهد مرتبط، ۸۰ میلیون ریال اعتبار برای خریداران فروشگاه در نظر گرفته است.
اگر پرداخت تحت تحلیل مربوط، کاهنده قیمت معامله محسوب شود و خدمت مستقلی در مقابل آن دریافت نشده باشد، درآمد نمونه ۹۲۰ میلیون ریال است.
اگر از ۸۰ میلیون، ۵۰ میلیون ریال خدمت تبلیغاتی مستقل با شاهد معتبر باشد و ۳۰ میلیون ریال باقی‌مانده کاهنده درآمد، درآمد نمونه ۹۷۰ میلیون ریال و هزینه مستقل ۵۰ میلیون ریال خواهد بود.
در این مثال ساده‌شده سود عملیاتی هر دو حالت ۳۲۰ میلیون ریال است، اما درآمد و سود ناخالص متفاوت‌اند.
این ارقام فقط پس از بررسی قرارداد، ماهیت خدمت، وعده پرداخت، تاریخ و استاندارد قابل‌اعمال معنی پیدا می‌کنند.
تازه‌ترین پیشنهاد FASB، موضوعی مهم برای تحلیل است، اما هنوز حکم نهایی یا قانون ایران نیست.
زنجیره قابل دفاع:
قرارداد و طرف‌ها ← تعهد پرداخت و خدمت متمایز ← دسته‌بندی مستند ← محاسبه قطعی ← بازبینی استاندارد و مالیات ← تأیید حسابدار ← ارائه مالی قابل ردیابی.
هوش مصنوعی بررسی و کمک می‌کند؛ حسابدار کنترل، تحلیل و قضاوت می‌کند.
برای مشاهده مقالات و راهکارهای نرم‌افزاری و عضویت، از https://hesabdaranebartar.com/ بازدید کنید.
عضویت در حسابداران برتر
برای مطالعه نمونه‌های واقعی طراحی کنترل مالی و کاربرد هوش مصنوعی در حسابداری، از بخش عضویت مجموعه استفاده کنید.