هوش مصنوعی گفت فروش شرکت یک میلیارد ریال است؛ پس چرا حسابدار فقط ۸۵۰ میلیون ریال درآمد گزارش کرده؟
مقدمه: دو عدد درست که پاسخ یک سؤال نیستند
مدیرعامل از دستیار هوش مصنوعی می‌پرسد: «فروش این ماه چقدر بود؟» دستیار جدول فروش ناخالص را جمع می‌زند و با اطمینان می‌گوید یک میلیارد ریال. مدیر مالی در همان جلسه، رقم ۸۵۰ میلیون ریال را از گزارش درآمد خالص ارائه می‌کند. آیا یکی اشتباه کرده است؟
ممکن است هر دو عدد از نظر جمع و تفریق درست باشند؛ اما دو شاخص متفاوت را اندازه بگیرند. یکی فروش پیش از برگشت و تخفیف است و دیگری درآمد خالص پس از تعدیلات مربوط. مشکل زمانی ایجاد می‌شود که هر دو را بدون قید «فروش» بنامیم و بر اساس آنها درباره بودجه، پاداش و سودآوری تصمیم بگیریم.
در عصر دستیارهای مالی، کنترل فقط این نیست که AI به جدول صحیح متصل شود؛ باید مطمئن شویم واژه‌های سؤال به شاخص، دوره، واحد پول و فرمول مورد تأیید واحد مالی تبدیل شده‌اند. مدلی که حساب را درست انجام می‌دهد، هنوز ممکن است سؤال اشتباه را پاسخ دهد.
مبنای خبر: لایه معنایی مشترک برای پاسخ‌های AI
در ۱۵ اکتبر ۲۰۲۶، شرکت AtScale از مجموعه AtScale for AI رونمایی کرد. در توضیح رسمی آن، پرسش ساده «درآمد فصل گذشته چقدر بود؟» ممکن است به ارزش قراردادها، سفارش‌های منعقدشده یا درآمد شناسایی‌شده اشاره کند؛ مدل زبانی بدون تعریف سازمانی، مجاز نیست خودسرانه یکی را انتخاب کند.
طبق خبر رسمی، بخش Ava به روشن‌کردن معنای شاخص در پرسش کمک می‌کند و موتور ACE محاسبه را با منطق تعریف‌شده روی داده سازمان اجرا می‌کند. دو بخش CoModel برای ایجاد و نگهداری مدل معنایی و Canary برای آزمون پاسخ‌ها معرفی شده‌اند، اما در زمان انتشار اطلاعیه هنوز به‌صورت عمومی عرضه نشده بودند؛ فقط Ava و ACE در دسترس اعلام شده‌اند.
این توصیف، اعلام شرکت سازنده است و اثبات مستقل عملکرد همه قابلیت‌ها در تمام محیط‌ها نیست. با این حال، اصل طراحی برای حسابدار ایرانی روشن است: یک KPI مالی باید یک تعریف مصوب داشته باشد که همه گزارش‌سازها و عامل‌های AI به آن رجوع کنند.
مثال آموزشی: یک میلیارد فروش ناخالص، ۸۵۰ میلیون درآمد خالص
فرض کنید شرکتی در یک ماه کالا فروخته و تحت مفروضات آموزشی، شواهد تحویل و معیارهای شناسایی درآمد مربوط احراز شده است. همه ارقام به میلیون ریال و کاملاً ساختگی هستند. مالیات، عوارض و سایر تعدیلات برای ساده‌سازی کنار گذاشته شده‌اند.
محاسبه درآمد خالص:
۱٬۰۰۰ − ۹۰ − ۶۰ = ۸۵۰ میلیون ریال
بنابراین پاسخ یک میلیارد ریالی برای «فروش ناخالص» درست و برای «درآمد خالص» نامتناسب است؛ اختلاف ۱۵۰ میلیون ریال از تفاوت معنای دو شاخص ناشی می‌شود و خودبه‌خود نشانه خطای دفاتر یا تقلب نیست.
وصول ۷۰۰ میلیون ریالی نیز شاخص جداگانه‌ای است. در دنیای واقعی، وجوه دریافتی می‌توانند به بدهی دوره‌های قبل یا پیش‌دریافت مربوط باشند؛ در این مثال فرض کرده‌ایم همه ۷۰۰ میلیون ریال متعلق به همین مجموعه فروش است. هیچ‌یک از این فروض را نباید بدون بررسی به عملیات یک شرکت واقعی تعمیم داد.
وقتی AI مخرج اشتباه را انتخاب می‌کند، سود هم ظاهراً تغییر می‌کند
اگر دستیار هوشمند بهای تمام‌شده ۵۱۰ میلیون ریالی را صحیح بخواند، ولی به‌جای درآمد خالص ۸۵۰، رقم فروش ناخالص ۱٬۰۰۰ را در فرمول حاشیه قرار دهد، محاسبات به‌ظاهر منظم چنین می‌شوند:
سود ناخالص نادرست در این تعریف = ۱٬۰۰۰ − ۵۱۰ = ۴۹۰ میلیون ریال
حاشیه حاصل از تعریف ناسازگار = ۴۹۰ ÷ ۱٬۰۰۰ = ۴۹٪
در حالی که تحت فرض‌های مصوب مثال، سود ناخالص ۳۴۰ میلیون ریال و حاشیه ۴۰ درصد است؛ اختلاف ۹ واحد درصد خواهد بود.
این عدد ممکن است مبنای توصیه برای افزایش هزینه بازاریابی یا پرداخت پاداش شود. اما منشأ اختلاف، نه یک خطای ضرب و جمع، بلکه ترکیب صورت و مخرج از دو تعریف ناسازگار است.
اگر سازمان واقعاً شاخص مدیریتی دیگری مانند «نسبت سود به فروش پیش از تخفیف» دارد، می‌تواند آن را جدا تعریف کند؛ فقط نباید همان نام و معنای حاشیه سود ناخالص گزارشگری را روی آن بگذارد.
فرهنگ‌نامه مالی چه چیزی فراتر از یک فایل اکسل دارد؟
به‌جای اینکه هر تیم فرمولی جدا بنویسد، برای هر شاخص یک «شناسنامه معنایی» ثبت کنید. نمونه برای درآمد خالص چنین است:
اگر کاربر بگوید «فروش»، سامانه می‌تواند بپرسد: «فروش ناخالص قبل از برگشتی‌ها مدنظر شماست یا درآمد خالص شناسایی‌شده؟» یک پرسش روشن‌کننده از صدور گزارش پرخطای مطمئن بهتر است.
سه دام محاسباتی: دوره، ارز و تجمیع
دام اول، تاریخ است. «فصل گذشته» در یک شرکت می‌تواند فصل تقویم شمسی یا دوره مالی دیگری باشد. تاریخ فاکتور نیز الزاماً زمان شناخت درآمد نیست. پاسخ AI باید بازه، زمان قطع داده و وضعیت اصلاحات دیررس را همراه عدد نمایش دهد.
دام دوم، واحد پول است. اگر سرفصل‌ها به ریال و تومان یا چند ارز نگهداری می‌شوند، جمع خام آنها بی‌معناست. شناسنامه شاخص باید سیاست تبدیل، تاریخ نرخ و واحد نمایش را مشخص کند.
دام سوم، جمع‌پذیری شاخص است. مبلغ درآمد خالص در بسیاری از موارد پس از کنترل معاملات درون‌گروهی و واحد پول قابل جمع است؛ اما درصد حاشیه سود را نباید بی‌قاعده جمع یا میانگین ساده کرد.
مثلاً در مثال آموزشی مستقلی، شعبه الف درآمد ۸۰۰ و سود ناخالص ۴۰۰ میلیون ریال دارد؛ حاشیه آن ۵۰٪ است. شعبه ب درآمد ۲۰۰ و سود ۲۰ میلیون ریال دارد؛ حاشیه آن ۱۰٪ است. میانگین ساده این دو حاشیه ۳۰٪ می‌شود؛ ولی حاشیه تجمیعی صحیح با فرض نبود تعدیلات دیگر چنین است:
(۴۰۰ + ۲۰) ÷ (۸۰۰ + ۲۰۰) = ۴۲٪
بنابراین موتور شاخص باید برای KPIهای نسبتی، جمع صورت و مخرج معتبر را انجام دهد؛ نه اینکه ستون درصد را به‌طور مکانیکی میانگین بگیرد. همین منطق برای «میانگین قیمت»، «نرخ وصول» و بسیاری از شاخص‌های مدیریتی نیز اهمیت دارد.
چرا صحت SQL به‌تنهایی کافی نیست؟
حتی اگر کوئری SQL بدون خطا اجرا شود و تمام ردیف‌ها را انتخاب کند، پاسخ ممکن است اشتباه باشد؛ مثلاً فیلد مبلغ پیش از تخفیف را به‌جای درآمد خالص انتخاب کرده باشد. دو عامل AI ممکن است روی یک انبار داده، دو کوئری کاملاً معتبر اما با تعریف متفاوت بنویسند.
در این شرایط، کنترل بهتر آن است که AI پرسش را به شناسه KPI مصوب نگاشت کند و محاسبه توسط موتور قابل آزمون صورت گیرد. در خروجی باید معلوم باشد که عدد با کدام نسخه تعریف، از چه داده‌ای و برای چه بازه‌ای محاسبه شده است.
این راهکار جای کنترل کیفیت داده، تطبیق دفاتر و استانداردهای شناخت درآمد را نمی‌گیرد؛ فقط یک حلقه مهم دیگر یعنی ثبات تعریف و محاسبه شاخص را اضافه می‌کند.
هشت کنترل نرم‌افزاری برای پاسخ‌های مالی قابل دفاع
۱. فهرست شاخص‌های رسمی: برای درآمد خالص، فروش ناخالص، حاشیه سود، مطالبات و نقدینگی شناسه، تعریف، فرمول، مالک و وضعیت تأیید مشخص کنید.
۲. رفع ابهام پیش از محاسبه: عباراتی مانند «فروش»، «رشد»، «سود» و «مشتری فعال» در صورت چندمعنایی باید سؤال تکمیلی یا انتخاب واضح ایجاد کنند؛ نه پاسخ دلخواه مدل.
۳. موتور محاسبه قطعی: AI نقش تشخیص نیت و توضیح خروجی داشته باشد، درحالی‌که فرمول KPI و قواعد تجمیع با منطق تأییدشده و بازتولیدپذیر اجرا شوند.
۴. نسخه‌بندی و زمان اثر: تغییر روش کسر تخفیف یا تعریف مشتری فعال باید با نسخه جدید، مسئول تصویب و زمان اثر ثبت شود؛ گزارش‌های تاریخی بدون مجوز بازنویسی نشوند.
۵. قواعد تجمیع: شاخص‌ها با برچسب جمع‌پذیر، نسبتی، مانده در یک تاریخ یا دوره‌ای تعریف شوند. نسبت گروه از صورت و مخرج مناسب محاسبه شود و مانده‌های نقطه‌ای به‌غلط در طول زمان جمع نشوند.
۶. کنترل دسترسی: کسی که مجاز است رقم فروش واحد خود را ببیند، الزاماً مجاز به مشاهده فاکتور مشتری دیگر نیست. دسترسی به مقدار تجمیعی و ریزتراکنش باید جدا کنترل شود.
۷. آزمون مقابل مرجع مستقل: برای KPIهای حساس، پاسخ سیستم با کاربرگ مالی مورد تأیید و سناریوهای مرزی مقایسه و اختلاف به گروه‌های «داده، دوره، تعریف، دسترسی، محاسبه» طبقه‌بندی شود.
۸. شناسنامه پاسخ و کنترل انسانی: نتیجه باید شناسه و نسخه شاخص، زمان داده، واحد، دامنه و وضعیت اعتبار را نشان دهد. تصمیم درباره اصلاح سیاست قیمت‌گذاری یا بودجه همچنان با انسان دارای اختیار است.
چگونه دو دستیار AI را به یک پاسخ برسانیم؟
آزمون مطلوب این نیست که دو چت‌بات متن مشابه تولید کنند. هر دو باید سؤال «حاشیه سود ناخالص شعبه الف در مهر» را به یک KPI واحد، بازه مشخص و موتور محاسبه مصوب متصل کنند.
اگر پاسخ‌ها متفاوت باشند، بازبین باید بتواند تشخیص دهد اختلاف از انتخاب شاخص دیگر، زمان متفاوت، نسخه تعریف قدیمی، اختلال داده یا روش تجمیع ناشی شده است. یکسان بودن دو پاسخ اشتباه نیز به معنی موفقیت نیست؛ ملاک نهایی، مقایسه با نتیجه مستقل تأییدشده است.
آزمون‌های پذیرش پیش از حضور AI در جلسه مدیران
برای آزمون، پرسش‌هایی با جواب از پیش تعیین‌شده بسازید: «فروش این ماه» با ابهام ناخالص/خالص؛ «درآمد خالص» همراه با برگشت و تخفیف؛ «حاشیه گروه» با دو شعبه نابرابر؛ «مانده بانک سه ماه اخیر» که نباید مانده پایان ماه‌ها به‌طور ناموجه جمع شود؛ «مطالبات معوق» با سند اصلاحی؛ «درآمد به تومان» بر اساس داده ریالی؛ «فروش دو شرکت» برای کاربر مجاز فقط به یکی؛ و «همان شاخص پارسال» پس از تغییر نسخه تعریف.
پیش از اجرای AI، متخصص مالی برای هر پرسش تعریف درست و پاسخ مرجع را مشخص کند. سپس نرخ انتخاب صحیح KPI، خطای عددی، تعداد پرسش‌های رفع ابهام، رعایت مجوزها و قابلیت بازسازی محاسبه اندازه‌گیری شود.
برنامه اجرای آزمایشی چهار هفته‌ای
هفته اول: ده سؤال پرتکرار مدیرعامل و CFO را جمع کنید. مشخص کنید هر سؤال اکنون در ERP، Excel و گزارش مدیریتی با چه فرمولی پاسخ داده می‌شود و اختلاف تعریف‌ها کجاست.
هفته دوم: فرهنگ‌نامه شاخص‌ها، مالک، نسخه، دوره، واحد، منبع، دامنه، سطح دسترسی و قواعد تجمیع را تصویب کنید. این کار، تصمیم حرفه‌ای حسابدار است نه کار مستقل مدل.
هفته سوم: موتور محاسبه در محیط آزمایشی و اتصال مجاز به داده را پیاده کنید. AI فقط سؤال را به شاخص مصوب پیوند دهد و ابهام را روشن کند؛ محاسبه با فرمول‌های آزمون‌پذیر انجام شود.
هفته چهارم: پرسش‌های مرجع را از دو ابزار گزارش/AI اجرا و نتیجه را با کاربرگ مستقل تطبیق کنید. موارد مشکوک یا اختلاف‌دار تا رسیدگی و تأیید، برای تصمیم نهایی قابل اتکا اعلام نشوند.
فرصت محصولی برای حسابداران برتر
پیشنهاد توسعه «فرهنگ‌نامه هوشمند شاخص مالی و موتور پاسخ قابل‌ممیزی» است؛ لایه‌ای مشترک میان نرم‌افزار مالی، گزارش‌سازها و عامل‌های هوش مصنوعی.
هسته قطعی محصول، فهرست KPI نسخه‌دار، محاسبه بازتولیدپذیر، قواعد زمان و ارز، کنترل دسترسی، آزمون جمع‌پذیری و سوابق پاسخ را نگهداری کند. لایه AI می‌تواند اصطلاح مبهم را تشخیص دهد، تعریف مناسب را برای تأیید پیشنهاد کند و علت اختلاف دو گزارش را توضیح دهد.
برای بازار ایران، ریال/تومان، تقویم شمسی، کدینگ حساب، چندشرکتی‌بودن، دوره مالی، مجوز مشاهده ریزاسناد و تمایز شاخص مدیریتی از اقلام گزارش رسمی اهمیت دارد. این پیشنهاد توسعه محصول است، نه ادعای وجود آن در محصولات کنونی مجموعه.
جمع‌بندی: پیش از جواب دادن، معنی شاخص را مشخص کنید
ممکن است هوش مصنوعی عدد یک میلیارد ریال را بدون کوچک‌ترین خطای ریاضی محاسبه کند و باز هم به سؤال مدیر مالی پاسخ نامناسب بدهد. برای اطمینان از گزارش، زنجیره زیر لازم است:
پرسش کاربر ← رفع ابهام شاخص ← تعریف و نسخه مصوب ← داده معتبر و مجاز ← محاسبه آزمون‌پذیر ← شناسنامه پاسخ ← بررسی انسانی تصمیم
هوش مصنوعی باید معنا را روشن و اختلاف را توضیح دهد؛ حسابدار تعریف شاخص، صحت گزارش و تصمیم حرفه‌ای را کنترل و تأیید می‌کند.
