در بسیاری از شرکت‌ها، آخرین مرحله تهیه گزارش مالی نه در خود نرم‌افزار حسابداری، بلکه در یک فایل اکسل انجام می‌شود: مانده حساب‌ها از ERP استخراج می‌شود، چند شیت به‌روزرسانی می‌شوند، یک ماکرو اجرا می‌شود و خروجی نهایی به مدیر مالی یا حسابرس تحویل داده می‌شود. تا زمانی که فایل باز می‌شود و اعداد ظاهراً درست‌اند، کمتر کسی می‌پرسد این فرایند به چه نسخه‌ای از اکسل، چه افزونه‌ای و چه تنظیمات امنیتی وابسته است.
۱۳ اکتبر ۲۰۲۶ برای این پرسش یک نقطه کنترل مهم است. بر اساس اطلاعیه رسمی مایکروسافت، پشتیبانی Office LTSC 2021 در این تاریخ پایان می‌یابد. مایکروسافت اعلام کرده پس از پایان پشتیبانی، اصلاحات امنیتی، رفع اشکال و پشتیبانی فنی این محصول را ارائه نمی‌کند. فهرست چرخه عمر این شرکت، Excel 2021 را نیز در همین بازه پایان پشتیبانی قرار داده است. این تاریخ، تاریخ وقوع پایان پشتیبانی است؛ اطلاعیه اولیه مایکروسافت در ۲۳ آوریل ۲۰۲۶ به‌روزرسانی شده بود، نه اینکه امروز برای نخستین بار خبر منتشر شده باشد.
اهمیت موضوع فقط امنیت رایانه نیست. وقتی گزارش‌های مالی به نسخه خاصی از اکسل و افزونه‌های اتصال به ERP وابسته باشند، پایان پشتیبانی می‌تواند ریسک تداوم عملیات، پشتیبانی فروشنده، بازتولید گزارش و کنترل تغییرات را افزایش دهد. البته پایان پشتیبانی به معنی از کار افتادن خودکار اکسل، خراب‌شدن همه فایل‌ها یا نادرست‌شدن ناگهانی ارقام نیست. خطر واقعی از جایی آغاز می‌شود که وابستگی‌های ناشناخته، تغییر نسخه و نبود آزمون سازگاری در کنار یکدیگر قرار می‌گیرند.
یک هشدار عملی از مستندات اوراکل
در مستندات رسمی افزونه Oracle ADF Desktop Integration، شرکت اوراکل صریحاً یادآوری کرده است که با پایان پشتیبانی Excel 2021 در ۱۳ اکتبر ۲۰۲۶، برای تداوم دریافت پشتیبانی این افزونه باید به نسخه پشتیبانی‌شده اکسل، مانند Microsoft 365 Apps، مهاجرت کرد. این توضیح درباره همان افزونه و شرایط پشتیبانی اعلام‌شده توسط اوراکل است؛ نمی‌توان از آن نتیجه گرفت همه محصولات ERP، همه افزونه‌ها یا همه نسخه‌های اکسل در همین روز از کار می‌افتند.
برای مدیر مالی، این مثال نشان می‌دهد مسئله فقط خرید مجوز جدید نیست. شاید فایل بودجه، کاربرگ تسهیم هزینه، گزارش بهای تمام‌شده یا فرم بارگذاری سند به افزونه‌ای متصل باشد که پس از تغییر نسخه رفتار متفاوتی نشان دهد. مهاجرت بدون آزمون می‌تواند به اندازه ادامه کار در محیط پشتیبانی‌نشده مشکل‌ساز باشد.
چهار نوع وابستگی که باید از هم تفکیک شوند
۱. فایل مستقل: یک فایل معمولی XLSX که اطلاعات آن دستی وارد می‌شود و فقط از فرمول‌های استاندارد استفاده می‌کند. ریسک اصلی آن می‌تواند امنیت محیط اجرا، کنترل نسخه و صحت فرمول‌ها باشد؛ صرف تغییر نسخه به معنای تغییر نتیجه نیست.
۲. فایل وابسته به داده خارجی: کاربرگ‌هایی که از CSV، پایگاه داده، Power Query یا اتصال ODBC اطلاعات می‌گیرند. در این حالت باید دسترسی، روش احراز هویت، نام ستون‌ها، نوع داده و زمان آخرین به‌روزرسانی بررسی شود.
۳. فایل دارای ماکرو و افزونه: فایل‌های XLSM، افزونه‌های XLL/COM و کدهای VBA ممکن است به کتابخانه‌ها، مجوزها یا تنظیمات امنیتی وابسته باشند. باید اجرای مجاز، امضای کد، مالک فرایند و رفتار نسخه جدید آزموده شود؛ نباید برای «حل سریع مشکل» حفاظت‌های امنیتی را بی‌ضابطه غیرفعال کرد.
۴. فایل واسط ثبت یا تأیید در ERP: برخی کاربرگ‌ها صرفاً گزارش نیستند؛ اطلاعات را به نرم‌افزار مالی بازمی‌گردانند یا مبنای ثبت سند و پرداخت می‌شوند. برای این گروه، علاوه بر سازگاری، کنترل مجوز ثبت، جلوگیری از ارسال دوباره و تطبیق با دفتر کل ضروری است.
این چهار گروه نباید با یک برچسب کلی «فایل اکسل» مدیریت شوند. شدت ریسک هر فایل به اهمیت فرایند، سطح دسترسی و قابلیت بازسازی آن بستگی دارد.
نمونه آموزشی: گزارش ماهانه‌ای که بعد از ارتقا باید دوباره اثبات شود
فرض کنید شرکت الف هر ماه از ERP، ریز هزینه‌های سه مرکز هزینه را به اکسل منتقل می‌کند. در ماه آزمایشی، مجموع داده‌های مبدأ ۱٬۸۰۰ میلیون ریال است: تولید ۹۰۰، فروش ۵۰۰ و اداری ۴۰۰ میلیون ریال. این اعداد کاملاً فرضی و صرفاً آموزشی هستند.
پس از نصب نسخه جدید اکسل، فایل ظاهراً بدون خطا باز می‌شود، اما خروجی یکی از اتصال‌ها تنها دو مرکز هزینه را برمی‌گرداند. گزارش جدید جمع ۱٬۴۰۰ میلیون ریال نشان می‌دهد؛ یعنی ۴۰۰ میلیون ریال کمتر از منبع. اگر مدیر مالی فقط بازشدن فایل و نبود پیام خطا را کنترل کند، این مغایرت کشف نمی‌شود.
کنترل درست به سه مرحله نیاز دارد: ابتدا تعداد ردیف‌ها و جمع مبلغ در خروجی ERP ثبت شود؛ سپس فایل در محیط جدید با همان داده‌ها اجرا شود؛ و در پایان جمع هر مرکز هزینه، تعداد ردیف‌ها، شناسه اسناد و مجموع کل با خروجی مرجع مقایسه شوند. در این مثال، اختلاف ۴۰۰ میلیون ریالی یک سناریوی طراحی‌شده برای توضیح کنترل است و ادعا نمی‌شود که ارتقای اکسل در عمل چنین خطایی ایجاد می‌کند.
حتی اگر جمع کل دو نسخه یکسان باشد، هنوز باید ردیف‌های جابه‌جا، اسناد تکراری، تغییر علامت بدهکار/بستانکار و اختلاف تاریخ یا واحد پول بررسی شوند. برابری جمع‌ها شرط لازم مفیدی است، نه تضمین کامل‌بودن داده.
هفت کنترل برای تیم مالی و فناوری اطلاعات
۱. فهرست وابستگی‌ها، نه فقط فهرست رایانه‌ها
نسخه نصب‌شده Office/Excel، نوع مجوز، سیستم‌عامل، نام فایل‌های حیاتی، مسیر داده مبدأ، نام افزونه، مالک تجاری و مسئول فنی باید در یک فهرست واحد ثبت شوند. یک فایل روی رایانه مدیر مالی ممکن است به ده‌ها گزارش و فرایند دیگر وابسته باشد.
۲. اولویت‌بندی براساس اثر مالی
کاربرگ‌هایی که به ثبت سند، حقوق و دستمزد، پرداخت، مالیات، بستن حساب یا گزارش رسمی متصل‌اند در اولویت بالاتر قرار می‌گیرند. فایل آموزشی یا تحلیلی کم‌اهمیت می‌تواند در صف آزمون بعدی باشد. «تعداد فایل‌ها» به‌تنهایی معیار اولویت نیست.
۳. حفظ نسخه مرجع و داده آزمون
پیش از مهاجرت، از نسخه مجاز و قابل بازیابی فایل، مشخصات محیط اجرا و خروجی تأییدشده نسخه فعلی نگهداری شود. اطلاعات حساس باید مطابق سیاست دسترسی سازمان محافظت شود. برای آزمون، ترجیحاً از داده ساختگی یا داده حداقلی و مجاز استفاده شود.
۴. آزمون سازگاری در محیط جداگانه
نسخه جدید اکسل و افزونه‌های مورد نیاز ابتدا روی محیط آزمون اجرا شوند. بازشدن فایل، Refresh اتصال‌ها، اجرای ماکرو، چاپ و خروجی PDF، نمایش تاریخ و اعداد فارسی، جداکننده اعشار و سازگاری با ERP جداگانه ارزیابی شوند. آزمون نباید به سیستم عملیاتی ثبت سند متصل شود مگر با مجوز و کنترل مشخص.
۵. تطبیق مستقل با دفتر کل
برای گزارش‌های مالی، تعداد رکورد، مجموع مبالغ، شناسه اسناد، دوره مالی و حساب‌های کلیدی با خروجی مستقل ERP مقایسه شود. اختلاف‌ها باید علت‌یابی و مستند شوند؛ اصلاح دستی بی‌ردپا راه‌حل قابل قبول نیست.
۶. بازگشت‌پذیری و کنترل تغییر
قبل از تغییر گسترده، مسئول تأیید، زمان مهاجرت، نسخه‌های مجاز و سناریوی بازگشت مشخص شود. «بازگشت» نباید به معنای بازگرداندن دائمی یک محیط ناامن باشد؛ ممکن است شامل توقف موقت فرایند، استفاده از گزارش جایگزین کنترل‌شده یا بازیابی نسخه قبلی در محیط ایزوله باشد.
۷. تأیید نهایی توسط مالک فرایند
تیم IT می‌تواند نصب و سازگاری فنی را تأیید کند، اما مسئول مالی باید ثابت کند خروجی جدید از نظر حسابداری همان نتیجه مورد انتظار را تولید می‌کند. برای گزارش‌های بااهمیت، بازبین مستقل و سابقه امضا یا تأیید الکترونیکی لازم است.
هوش مصنوعی دقیقاً چه کمکی می‌کند؟
هوش مصنوعی در این مسئله ابزار کشف و اولویت‌بندی است، نه مرجع قطعی سازگاری. با دسترسی خواندنی و مجاز به فایل‌ها و اطلاعات پیکربندی، می‌توان از آن برای پیشنهاد دسته‌بندی کاربرگ‌ها، استخراج نام اتصال‌های خارجی، شناسایی فرمول‌های ارجاع‌دهنده به فایل‌های دیگر، خلاصه‌سازی کدهای VBA و تهیه نقشه وابستگی کمک گرفت. همچنین می‌توان از مدل برای تولید پیشنهاد آزمون استفاده کرد؛ مثلاً اگر فایلی داده‌های حقوق و دستمزد را از ERP می‌گیرد، آزمون‌های کنترل دوره، تعداد کارکنان، جمع خالص پرداختنی و رکورد تکراری پیشنهاد شود.
اما مدل ممکن است اتصال پنهان را نبیند، معنای یک ماکرو را اشتباه تفسیر کند یا درباره سازگاری افزونه با نسخه جدید حدس بزند. بنابراین نتیجه باید با اسکن فنی، مستندات فروشنده و اجرای واقعی آزمون تأیید شود. هیچ عامل هوشمندی نباید صرفاً بر اساس برداشت خود، ماکروها را فعال، سطح دسترسی را افزایش یا داده‌ای را به ERP ارسال کند.
برای حفاظت از محرمانگی، فایل‌های حقوق، اطلاعات بانکی، اطلاعات مشتری و اسرار تجاری نباید بدون مجوز و ارزیابی قرارداد و محل پردازش به سرویس عمومی AI فرستاده شوند. در نسخه اولیه محصول، پردازش محلی یا محیط سازمانی کنترل‌شده و نگهداری حداقلی داده ترجیح دارد.
فرصت نرم‌افزاری: «نقشه ریسک وابستگی کاربرگ‌های مالی»
برای یک تولیدکننده نرم‌افزار مالی، محصول پیشنهادی می‌تواند یک ماژول مکمل ERP باشد، نه جایگزین اکسل. هدف آن پاسخ به سه سؤال است: کدام فرایند مالی به چه فایل و افزونه‌ای وابسته است؟ با تغییر نسخه چه چیزی باید آزمون شود؟ چه کسی نتیجه را تأیید کرده است؟
نسخه حداقلی محصول می‌تواند پنج قابلیت داشته باشد: ثبت شناسنامه کاربرگ و نسخه محیط اجرا؛ استخراج فراداده و اتصال‌های شناخته‌شده با مجوز خواندنی؛ امتیازدهی ریسک براساس اهمیت فرایند و نوع اتصال؛ تولید چک‌لیست آزمون و تطبیق خروجی؛ و نگهداری پرونده تأیید شامل نسخه، زمان، نتیجه، مغایرت و نام بازبین.
در مرحله بعد، قابلیت مقایسه خروجی‌های قبل و بعد از مهاجرت، تشخیص ناهنجاری در تعداد رکوردها و پیشنهاد علت مغایرت با AI اضافه شود. برای بازار ایران، پشتیبانی از تاریخ شمسی، واحد ریال و تومان، کاراکترهای فارسی/عربی، کدینگ حساب‌ها و خروجی‌های نرم‌افزارهای مالی داخلی اهمیت ویژه‌ای دارد.
این پیشنهاد طراحی محصول است و به معنای موجودبودن چنین ماژولی در سبد فعلی «حسابداران برتر» نیست. هیچ ادعایی درباره نرخ موفقیت، میزان صرفه‌جویی یا قابلیت سازگاری خودکار با همه ERPها مطرح نمی‌شود.
برنامه آزمایشی چهار هفته‌ای
هفته اول: با مشارکت مالی و IT، ۲۰ کاربرگ مهم انتخاب و شناسنامه آن‌ها تکمیل شود. عدد ۲۰ صرفاً اندازه پیشنهادی پایلوت است، نه آمار صنعت.
هفته دوم: فایل‌ها براساس اثر مالی و وابستگی فنی دسته‌بندی شوند؛ نسخه مرجع و خروجی تأییدشده ثبت شود.
هفته سوم: کاربرگ‌ها در محیط مقصد اجرا و خروجی‌ها با داده مبدأ و نسخه مرجع تطبیق شوند؛ همه اختلاف‌ها پرونده داشته باشند.
هفته چهارم: موارد مردود اصلاح و دوباره آزمون شوند؛ مالک فرایند مالی، تصمیم ادامه یا توقف مهاجرت را ثبت کند.
شاخص‌های پایلوت باید شامل درصد فایل‌های دارای شناسنامه کامل، درصد آزمون‌های پذیرفته‌شده، تعداد مغایرت‌های تعیین‌تکلیف‌نشده، پوشش کنترل مستقل خروجی و زمان بازتولید گزارش باشد. هدف عددی باید براساس ریسک و ظرفیت واقعی همان شرکت تعیین شود، نه با وعده‌های عمومی.
مدیر مالی امروز چه تصمیمی بگیرد؟
نخست مشخص کند چه تعداد از گزارش‌های حیاتی هنوز روی Office/Excel 2021 یا افزونه‌های وابسته اجرا می‌شوند. دوم از فروشنده ERP و افزونه‌ها، ماتریس سازگاری نسخه مقصد را درخواست کند. سوم برای گزارش‌های بااهمیت، اجرای موازی و تطبیق قبل از جایگزینی را الزامی کند. چهارم هیچ گزارش مالی را صرفاً به دلیل «بازشدن موفق فایل» تأیید نکند.
پایان پشتیبانی یک نرم‌افزار لزوماً بحران حسابداری نیست؛ اما می‌تواند وابستگی پنهانی را آشکار کند که سال‌ها خارج از کنترل رسمی مالی باقی مانده است. فرصت واقعی هوش مصنوعی در اینجا «تعویض خودکار اکسل» نیست، بلکه قابل‌مشاهده‌کردن وابستگی‌ها، طراحی آزمون و کمک به تصمیم قابل دفاع انسان است.
