طراحی کدینگ حساب‌ها که گزارش درست بدهد

کدینگ حساب‌ها تصمیمی است که یک بار گرفته می‌شود و سال‌ها با شما می‌ماند. اگر درست طراحی شود، گزارش سود هر محصول یا هر شعبه با دو کلیک بیرون می‌آید؛ اگر بد طراحی شود، هر گزارش مدیریتی به یک پروژه اکسل تبدیل می‌شود. در این نوشته ساختار چهارسطحی، الزامات مالیاتی و مسیر بازطراحی را مرور می‌کنم.

چهار سطح و کاری که هرکدام انجام می‌دهد

ساختار متداول در نرم‌افزارهای ایرانی چهار سطح دارد:

• گروه: بالاترین سطح طبقه‌بندی که مستقیماً به صورت‌های مالی وصل می‌شود (دارایی جاری، بدهی جاری، درآمد و…).
• کل: سرفصل‌های اصلی هر گروه، مثل موجودی نقد، حساب‌های دریافتنی، موجودی کالا.
• معین: سطحی که واقعاً ماهیت رویداد را مشخص می‌کند؛ مثلاً بانک ریالی، بانک ارزی، تنخواه.
• تفصیلی: طرف حساب‌ها؛ مشتریان، تأمین‌کنندگان، کارکنان، پروژه‌ها، مراکز هزینه.

قاعده طلایی این است: سطوح بالا ثابت و کم‌تعداد، سطح تفصیلی شناور و بی‌نهایت. هر بار که وسوسه شدید برای یک مشتری جدید معین بسازید، بدانید در حال خراب کردن ساختار گزارشگری خود هستید.

ساختار پیشنهادی گروه‌ها

این تقسیم‌بندی تنها گزینه نیست، اما مزیتش این است که با ساختار صورت‌های مالی متعارف می‌خواند و تهیه ترازنامه و سود و زیان را به یک عملیات جمع‌بندی ساده تبدیل می‌کند. راهنمای خواندن خروجی نهایی را در صورت‌های مالی و تحلیل آن آورده‌ام.

حساب‌هایی که تکالیف مالیاتی را ممکن می‌کنند

طراحی کدینگ فقط یک تصمیم حسابداری نیست؛ اگر این حساب‌ها را از ابتدا جدا نکنید، هر فصل و هر پایان سال هزینه می‌دهید:

1. مالیات و عوارض ارزش افزوده خرید جدا از مالیات و عوارض فروش، تا اظهارنامه دوره‌ای بدون بازسازی دستی تهیه شود.
2. مالیات تکلیفی کسرشده در حسابی مستقل، تفکیک‌شده بر اساس نوع پرداخت.
3. مالیات و بیمه حقوق پرداختنی جدا از سایر بدهی‌های پرسنلی.
4. هزینه‌های غیرقابل قبول در معین‌های جداگانه (جرائم، هدایا، پذیرایی مازاد)، تا کاربرگ تعدیلات به‌سادگی ساخته شود.
5. برداشت مالک یا حساب جاری شرکا جدا از هزینه‌های شرکت.
6. پیش‌پرداخت مالیات و مالیات علی‌الحساب پرداختی در حساب‌های مستقل.

تفصیلی شناور، مرکز هزینه و پروژه

نرم‌افزارهای امروزی اجازه می‌دهند یک حساب معین را به چند «سطح شناور» وصل کنید؛ مثلاً هزینه حمل را هم‌زمان به تفصیلی «تأمین‌کننده» و «مرکز هزینه» و «پروژه» ببندید. این قابلیت را جدی بگیرید:

• مرکز هزینه برای تفکیک واحدهای سازمانی: تولید، فروش، اداری، انبار.
• پروژه یا قرارداد برای پیمانکاران و شرکت‌هایی که کار سفارشی انجام می‌دهند؛ بدون آن، تحلیل سودآوری هر قرارداد ممکن نیست. رابطه آن با شناسایی درآمد را در حسابداری پیمانکاری توضیح داده‌ام.
• شعبه یا فروشگاه برای کسب‌وکارهای چندمکانی.

اگر تولیدی هستید، ساختار حساب‌های بهای تمام‌شده باید امکان تفکیک مواد مستقیم، دستمزد مستقیم و سربار را بدهد، وگرنه محاسبه بهای تمام‌شده به تخمین تبدیل می‌شود؛ موضوعی که در بهای تمام‌شده تولید مفصل بررسی شده است.

چقدر عمیق برویم

پرسش همیشگی این است که سطح معین باید چقدر ریز باشد. معیار عملی من ساده است: یک حساب معین وقتی ارزش ساختن دارد که کسی قرار باشد بر اساس مانده یا گردش آن تصمیم بگیرد یا گزارشی تهیه کند. اگر هزینه «آب» و «برق» و «گاز» هیچ‌گاه جداگانه تحلیل نمی‌شوند، یک معین «انرژی و آب‌بها» کافی است. برعکس، اگر مدیرعامل هر ماه هزینه حمل را جدا می‌خواهد، آن حساب باید مستقل باشد حتی اگر مبلغش کوچک است.

اشتباه رایج دیگر، ساختن معین بر اساس مبلغ به‌جای ماهیت است؛ مثلاً «هزینه‌های خرد» در برابر «هزینه‌های عمده». چنین تفکیکی هیچ گزارشی تولید نمی‌کند و فقط ثبت را دشوار می‌سازد.

شماره‌گذاری؛ چند قاعده ساده

1. طول کد را از ابتدا ثابت کنید (مثلاً ۱ رقم گروه، ۲ رقم کل، ۲ رقم معین) و در تمام دوره حفظ کنید.
2. فاصله بگذارید؛ اگر معین‌ها را ۱۰، ۲۰، ۳۰ شماره‌گذاری کنید، افزودن حساب جدید بعداً ساختار را به هم نمی‌ریزد.
3. یک منطق واحد برای همه گروه‌ها به کار ببرید؛ کد ۰۱ در همه سرفصل‌ها به یک نوع مفهوم اشاره کند.
4. از کد تکراری با معنای متفاوت در دو گروه پرهیز کنید.
5. عنوان حساب را کوتاه، بدون مخفف شخصی و بدون نام افراد بنویسید.
6. برای هر معین یک تعریف یک‌خطی مکتوب کنید؛ همین سند کوتاه از دوباره‌کاری حسابدار بعدی جلوگیری می‌کند.

نکته آخر درباره عنوان‌گذاری: عنوان حساب باید برای کسی که سه سال بعد وارد شرکت می‌شود هم معنا داشته باشد. عنوان‌هایی مثل «حساب واسط ۲» یا «موقت انبار قدیم» معمولاً یادگار یک راه‌حل عجولانه‌اند و سال‌ها در تراز باقی می‌مانند بدون آنکه کسی جرئت کند مانده‌شان را تعیین تکلیف کند. اگر چنین حساب‌هایی دارید، همین امسال ریشه هر مانده را پیدا و آن را ببندید.

اشتباهات پرتکرار

کدینگ و گزارش مدیریتی

کدینگ خوب را می‌توان با یک آزمون سنجید: آیا می‌توانید بدون کار دستی، سود ناخالص هر خط محصول، هزینه هر واحد سازمانی و مانده هر مشتری را از سیستم بگیرید؟ اگر پاسخ منفی است، مشکل معمولاً در نبود ابعاد تحلیلی است، نه در کمبود سرفصل. افزودن یک بُعد «مرکز هزینه» به همان ساختار فعلی، اغلب بیش از ساختن بیست معین جدید کارساز است.

بازطراحی بدون از دست دادن تاریخچه

اگر کدینگ فعلی شما از کنترل خارج شده، بازطراحی را به ابتدای سال مالی موکول کنید و این ترتیب را رعایت کنید:

1. تراز آزمایشی چهار سطح فعلی را استخراج و حساب‌های بی‌گردش را علامت بزنید.
2. ساختار جدید را روی کاغذ طراحی و با گزارش‌های موردنیاز مدیریت تطبیق دهید.
3. جدول نگاشت حساب قدیم به جدید بسازید؛ هر حساب قدیمی باید دقیقاً یک مقصد داشته باشد.
4. تفصیلی‌ها را پاک‌سازی کنید: طرف حساب‌های تکراری را ادغام و اطلاعات هویتی را کامل کنید.
5. مانده‌ها را با سند افتتاحیه جدید منتقل و با صورت‌های مالی سال قبل تطبیق دهید.
6. گزارش‌های کلیدی را روی داده جدید تست بگیرید، پیش از آنکه ثبت‌های جاری شروع شود.
7. مستند کدینگ را در اختیار تیم بگذارید و برای تعریف حساب جدید یک فرآیند تأیید بگذارید.

نکات انتقال داده میان نرم‌افزارها را در انتقال اطلاعات به نرم‌افزار جدید آورده‌ام؛ پیش از هر بازطراحی، مطمئن شوید نرم‌افزار فعلی از تعداد سطوح و ابعاد شناور موردنیاز شما پشتیبانی می‌کند.

جمع‌بندی

• سطوح بالای کدینگ را ثابت و کم‌تعداد نگه دارید و طرف حساب‌ها را به تفصیلی شناور بسپارید.
• حساب‌های مالیاتی را از روز اول جدا کنید؛ این کار هر فصل به شما وقت برمی‌گرداند.
• مرکز هزینه و پروژه، تفاوت میان گزارش مدیریتی واقعی و حدس زدن است.
• در شماره‌گذاری فاصله بگذارید تا رشد آینده ساختار را نشکند.
• بازطراحی کدینگ را فقط با جدول نگاشت و در ابتدای سال مالی انجام دهید.