کنترل داخلی مجموعهای از سیاستها و اقدامهاست که به شرکت کمک میکند عملیات را درست انجام دهد، اطلاعات قابل اتکا تهیه کند و الزامات مربوط را رعایت کند. نرمافزار میتواند بخشی از این کنترلها را اجرا یا مستند کند، اما نصب یک محصول بهتنهایی نظام کنترل داخلی ایجاد نمیکند.
برای شرکت کوچک، هدف ساختن فرایندی پیچیده و اداری نیست. باید ریسکهای مهم شناسایی شوند، مسئولیت روشن باشد، عملیات حساس تایید مناسب داشته باشند و خطا پیش از تبدیلشدن به گزارش نادرست دیده شود.
کنترل از هدف و ریسک شروع میشود
چارچوب کنترل داخلی کمیته سازمانهای حامی کمیسیون تردوی کنترل موثر را فراتر از انطباق و گزارشگری بیرونی میداند و بر اعتماد به انواع داده و اطلاعات تاکید میکند. کتاب سبز دفتر پاسخگویی دولت آمریکا نیز کنترل داخلی را فرایندی برای کمک به دستیابی به اهداف عملیات، گزارش و رعایت الزامات معرفی میکند.
در شرکت، ابتدا هدف را بنویسید: مثلاً «هیچ پرداختی بدون مدرک و تایید مجاز انجام نشود». سپس ریسک را مشخص کنید: پرداخت تکراری، حساب بانکی اشتباه یا تایید توسط فرد ذینفع. بعد کنترل مناسب انتخاب شود.
کنترلی که به ریسک مشخص وصل نیست معمولاً فقط کار اضافه ایجاد میکند.
پنج لایه عملی کنترل
برای طراحی ساده میتوان کنترلها را در پنج لایه دید:
- محیط و مسئولیت: مدیران چه رفتاری را مجاز میدانند و مالک هر فرایند کیست؟
- ارزیابی ریسک: کدام خطا یا سوءاستفاده بیشترین اثر و احتمال را دارد؟
- فعالیت کنترلی: تایید، محدودیت دسترسی، تطبیق یا کنترل سیستمی چگونه اجرا میشود؟
- اطلاعات و ارتباط: کاربر خطا، وظیفه و تغییر سیاست را چگونه میفهمد؟
- پایش: چه کسی بررسی میکند کنترل واقعاً اجرا شده و هنوز موثر است؟
نرمافزار بیشتر در لایه فعالیت، اطلاعات و پایش کمک میکند. ضعف مدیریت یا شرح وظیفه را نمیتوان فقط با یک گزینه تنظیمات حل کرد.
کنترل پیشگیرانه و کشفکننده
کنترل پیشگیرانه تلاش میکند خطا رخ ندهد؛ مانند جلوگیری از قطعیسازی سند نامتوازن. کنترل کشفکننده خطای رخداده را پیدا میکند؛ مانند گزارش مانده نامتعارف یا مغایرت بانکی.
هر دو لازماند. محدودیت بیش از حد میتواند عملیات را متوقف کند و گزارش بدون مسئول پیگیری نیز بیاثر است.
نمونهها:
| ریسک | کنترل پیشگیرانه | کنترل کشفکننده |
|---|---|---|
| سند نامتوازن | منع قطعیسازی | گزارش اسناد پیشنویس و خطادار |
| پرداخت تکراری | کنترل شناسه و مرجع | گزارش پرداختهای مشابه |
| تغییر پس از بستن | قفل دوره | گزارش بازگشایی و ثبت پس از برش |
| دسترسی بیش از نیاز | نقش استاندارد | بازبینی دورهای مجوزها |
| اختلاف بانک | تطبیق هنگام ثبت | گزارش اقلام تطبیقنشده |
برای هر کنترل، مالک و تناوب اجرای آن را تعیین کنید.
تفکیک وظایف در تیم کوچک
تفکیک وظایف یعنی یک فرد بهتنهایی تمام مراحل ایجاد، تایید و پنهانکردن اثر عملیات را در اختیار نداشته باشد. در شرکت کوچک ممکن است افراد کافی نباشند. در این حالت کنترل جبرانی لازم است.
مثلاً حسابدار پرداخت را آماده میکند و مدیرعامل آن را تایید میکند. اگر همین فرد باید ثبت و تایید را انجام دهد، گزارش روزانه پرداختها و بازبینی مستقل صورتحساب بانکی میتواند بخشی از ریسک را جبران کند.
ترکیبهای پرریسک:
- ایجاد تامینکننده و تایید پرداخت او؛
- ثبت فروش و حذف یا ابطال آزاد همان فروش؛
- نگهداری صندوق و تطبیق مستقل آن؛
- مدیریت نقشها و تایید عملیات مالی؛
- ثبت تعدیل انبار و تایید اثر مالی.
مقاله طراحی سطح دسترسی حسابداری چندکاربره روش تبدیل این تفکیک به نقش و مجوز را توضیح میدهد.
کنترل سند حسابداری
چرخه سند باید وضعیت روشن داشته باشد. ثبتکننده سند را آماده میکند، کنترلهای سیستمی توازن و دوره را میسنجند و فرد مجاز آن را قطعی میکند.
کنترلهای مهم:
- حساب و تفصیل معتبر و فعال باشند؛
- جمع بدهکار و بستانکار برابر باشد؛
- تاریخ در دوره باز قرار گیرد؛
- شرح و مدرک برای ثبتهای حساس وجود داشته باشد؛
- سند مبدأ با ثبت مالی مرتبط بماند؛
- اصلاح سند قطعی با مسیر ثبتشده انجام شود؛
- ابطال دلیل و مجوز داشته باشد.
ویرایش مستقیم سندی که از فروش، خرید یا خزانه آمده میتواند مغایرت ایجاد کند. سیستم باید کاربر را به مبدأ صحیح هدایت کند یا رابطه اصلاح را حفظ کند.
کنترل دوره مالی
قفل دوره مانع تغییر عادی داده پس از تایید گزارش میشود. این کنترل زمانی موثر است که فرایند بستن ماه انجام شده و مجوز بازکردن دوره محدود باشد.
بازکردن دوره باید شامل درخواست، دلیل، تایید و سابقه باشد. پس از اصلاح، گزارشهای متاثر دوباره تهیه و نسخه قبلی حفظ شود. دسترسی دائم چند کاربر به بازکردن دوره، اثر کنترل را از بین میبرد.
چکلیست بستن ماه مالی ترتیب کنترل عملیات تا قفل را ارائه میکند.
کنترل طرف حساب و اطلاعات بانکی
تغییر شماره حساب یا شبا میتواند مستقیماً به پرداخت اشتباه منجر شود. ایجاد و اصلاح اطلاعات حساس باید محدود و قابل بازبینی باشد.
رویه مناسب:
- دریافت درخواست و مدرک معتبر؛
- ثبت توسط کاربر مجاز؛
- تایید مستقل برای تغییر حساس؛
- نگهداری سابقه مقدار قبلی و جدید؛
- هشدار در اولین پرداخت پس از تغییر؛
- تطبیق نام صاحب حساب طبق رویه شرکت.
نرمافزار نباید اطلاعات بانکی یا شناسه حساس را بدون نیاز در گزارش عمومی نمایش دهد.
کنترل پرداخت و خزانه
برای پرداخت، وجود درخواست معتبر، ذینفع درست، مبلغ، سررسید و تایید لازم بررسی شود. سقف تایید براساس مبلغ میتواند برای شرکت کوچک عملی باشد.
کنترلهای پیشنهادی:
- شماره مرجع یکتا برای جلوگیری از ثبت تکراری؛
- جداسازی تهیهکننده و تاییدکننده در مبالغ مهم؛
- اتصال پرداخت به بدهی یا مدرک؛
- کنترل حساب بانکی مقصد؛
- ثبت وضعیت رد یا ابطال؛
- تطبیق بعدی با صورتحساب بانک.
رد پرداخت باید دلیل داشته باشد و رکورد نباید بیصدا حذف شود.
کنترل تغییرات و سابقه رویداد
سابقه رویداد باید رکورد، کاربر، زمان و نوع عمل را نشان دهد. برای تغییر حساس، مقدار پیشین و جدید یا دستکم خلاصه قابل فهم لازم است.
اما سابقه بهتنهایی کنترل نیست. اگر هیچکس گزارش رویدادها را بازبینی نکند، فقط آرشیوی از خطاها ساخته میشود. رویدادهای بازکردن دوره، تغییر نقش، ابطال سند و تغییر اطلاعات بانکی باید بازبینی دورهای داشته باشند.
نگهداری رمز، توکن یا اطلاعات محرمانه در متن رخداد ممنوع است. دسترسی به گزارش رخداد نیز باید محدود باشد.
کنترلهای خودکار را کورکورانه نپذیرید
ثبت خودکار سند، تطبیق بانکی و پیشنهاد حساب میتوانند سرعت را افزایش دهند. بااینحال، قاعده خودکار باید نسخه، مالک و دامنه داشته باشد و خطای آن قابل مشاهده باشد.
برای هر خودکارسازی بپرسید:
- ورودی و شرط اجرا چیست؟
- اگر بخشی نامعتبر باشد کل عملیات متوقف میشود یا ناقص ثبت میشود؟
- نتیجه قبل از قطعیشدن بازبینی میشود؟
- تغییر قاعده روی ثبتهای قبلی اثر میگذارد؟
- کاربر میتواند از سند به قاعده و مبدأ برسد؟
خطای مخفی در خودکارسازی ممکن است در حجم بالا تکرار شود؛ توقف روشن بهتر از ثبت ناقص است.
آزمون کنترل
برای هر کنترل یک آزمون مثبت و منفی تعریف کنید. آزمون مثبت نشان میدهد کاربر مجاز میتواند عملیات صحیح را انجام دهد؛ آزمون منفی ثابت میکند عملیات غیرمجاز یا داده نامعتبر رد میشود.
نمونه برای قفل دوره:
- حسابدار در دوره باز سند معتبر ثبت کند؛
- پس از قفل، همان کاربر نتواند سند جدید ثبت کند؛
- مدیر مجاز با دلیل دوره را باز کند؛
- سابقه بازگشایی ثبت شود؛
- پس از اصلاح، دوره دوباره قفل و گزارش بازتولید شود.
نتیجه آزمون، تاریخ و مسئول آن نگهداری شود. نمایش تنظیمات بدون اجرای رفتار واقعی مدرک کافی نیست.
پایش و بهبود
کنترلها با رشد شرکت یا تغییر فرایند قدیمی میشوند. شاخصهایی مانند تعداد اصلاح پس از قفل، پرداخت ردشده، دسترسی منقضی، سند بدون مبدأ و اختلاف بانکی باز را ماهانه بررسی کنید.
افزایش یک شاخص الزاماً به معنی تقلب نیست؛ ممکن است آموزش، طراحی فرم یا قاعده خودکار مشکل داشته باشد. هدف پایش، یافتن علت و اصلاح عمومی فرایند است، نه سرزنش یک کاربر.
خطاهای رایج
- ساخت کنترل بدون تعیین ریسک؛
- دادن نقش مدیر برای رفع مانع روزانه؛
- اتکا به تایید شفاهی بدون سابقه؛
- اصلاح مستقیم رکورد مالی مبدأدار؛
- قفل دوره بدون تکمیل چکلیست؛
- ثبت رخداد بدون بازبینی؛
- خودکارسازی بدون مسیر خطا و بازگشت؛
- کنترل یک داده خاص بهجای رفع علت عمومی.
جمعبندی
کنترل داخلی موثر، ریسک را به اقدام قابل آزمون تبدیل میکند. نقش و مجوز، تایید، قفل دوره، تطبیق، سابقه رویداد و گزارش استثنا ابزارند؛ مسئولیت و پایش انسانی همچنان لازم است.
صفحه امنیت و کنترل دسترسی دامنه عمومی کنترلهای سامانه را توضیح میدهد. برای دیدن هسته مالی، تصاویر واقعی و وضعیت نسخه آزمایشی، معرفی نرمافزار حسابداری آنلاین سیسلینک را بررسی و کنترلهای حیاتی شرکت را در دمو اجرا کنید.
گفتوگوی حرفهای
دیدگاهها و تجربههای خوانندگان
دیدگاه شما پس از بررسی منتشر میشود. نام نمایشی الزامی است؛ ایمیل اختیاری است و در سایت نمایش داده نمیشود.
بخش دیدگاهها در حال آمادهسازی است.