حسابداری شرکتهای نرمافزاری فقط ثبت مبلغ قرارداد طراحی سایت یا نرمافزار نیست. حقوق برنامهنویسان، هزینه توسعه محصول، سرور و سرویسهای ابری، قراردادهای پروژهای، اشتراکهای ماهانه، پشتیبانی، لایسنس، مطالبات مشتریان و زمان صرفشده روی هر پروژه باید در یک سیستم منظم کنترل شوند. حسابداری حرفهای کمک میکند مدیر بفهمد هر پروژه، محصول یا مشتری واقعاً چه میزان سود ایجاد کرده است.
حسابداری مالی و مالیاتی شرکتهای فناوری اطلاعات و نرمافزاری؛ از قرارداد پروژه تا سود واقعی
یک شرکت نرمافزاری ممکن است در ظاهر هزینههای زیادی مانند کارخانه، انبار یا ناوگان نداشته باشد.
اما این موضوع به معنی ساده بودن حسابداری آن نیست.
در بسیاری از شرکتهای فناوری، گرانترین دارایی و مهمترین هزینه شرکت چیزی است که بهسادگی در یک فاکتور خرید دیده نمیشود:
زمان نیروی انسانی.
برنامهنویس
طراح UI/UX
مدیر پروژه
کارشناس تست
DevOps
کارشناس پشتیبانی
فروش
تحلیلگر
هر ساعت فعالیت این افراد برای شرکت هزینه دارد.
اگر مشخص نباشد هر تیم روی کدام پروژه، محصول یا مشتری کار کرده است، محاسبه سود واقعی بسیار دشوار میشود.
ممکن است یک پروژه ۵۰۰ میلیون تومان فروخته شده باشد و در ظاهر قرارداد بسیار خوبی به نظر برسد.
اما اگر چندین ماه از زمان تیم را مصرف کرده باشد، بارها تغییر کرده باشد، مشتری درخواستهای خارج از قرارداد داده باشد و بعد از تحویل نیز پشتیبانی گسترده ایجاد کند، ممکن است سود واقعی بسیار کمتر از تصور اولیه باشد.
در مقابل، یک سرویس اشتراکی با فروش اولیه کمتر ممکن است در بلندمدت حاشیه سود بسیار بهتری ایجاد کند.
به همین دلیل حسابداری مالی و مالیاتی شرکتهای نرمافزاری باید پروژه، محصول، زمان، قرارداد، مشتری و درآمدهای دورهای را همزمان کنترل کند.
چرا حسابداری شرکت نرمافزاری متفاوت است؟
در شرکتهای سنتی معمولاً بخش بزرگی از هزینهها قابل مشاهده هستند.
کالا خریداری میشود.
مواد اولیه وارد انبار میشوند.
ماشینآلات وجود دارند.
اما در شرکت نرمافزاری، بخش مهمی از ارزش توسط نیروی انسانی ایجاد میشود.
توسعه یک سیستم ممکن است شش ماه طول بکشد.
در طول این مدت:
حقوق پرداخت میشود.
سرور خریداری میشود.
سرویس خارجی استفاده میشود.
جلسات برگزار میشوند.
طراحی انجام میشود.
تست صورت میگیرد.
اما درآمد پروژه ممکن است چند مرحله بعد وصول شود.
همین اختلاف زمانی میان هزینه و دریافت پول باعث میشود مدیریت نقدینگی نیز اهمیت زیادی داشته باشد.
اولین ستون؛ هر پروژه یک مرکز مالی مستقل
هر پروژه نرمافزاری بهتر است کد مالی مستقل داشته باشد.
برای مثال:
طراحی سایت مشتری A
سامانه سازمانی مشتری B
اپلیکیشن مشتری C
سیستم CRM مشتری D
تمام هزینههای قابل تخصیص باید تا حد امکان به همان پروژه متصل شوند.
مدیر باید بتواند بعد از پایان پروژه ببیند:
مبلغ قرارداد چقدر بوده؟
چقدر از آن وصول شده؟
چند نفر روی پروژه کار کردهاند؟
چند ساعت زمان مصرف شده؟
هزینه زیرساخت چقدر بوده؟
و سود واقعی چقدر است؟
قرارداد پروژه
قرارداد یکی از مهمترین اسناد مالی شرکت نرمافزاری است.
در قرارداد باید موضوعات اصلی شفاف باشند.
مانند:
دامنه پروژه
امکانات
زمان تحویل
مبلغ
مراحل پرداخت
پشتیبانی
تغییرات خارج از قرارداد
مالکیت کد
هزینه سرویسهای جانبی
اگر دامنه پروژه مبهم باشد، سود پروژه میتواند بهشدت آسیب ببیند.
Scope Creep
یکی از بزرگترین مشکلات پروژههای نرمافزاری Scope Creep است.
یعنی مشتری بهتدریج قابلیتهایی درخواست میکند که در قرارداد اولیه وجود نداشتهاند.
هر درخواست ممکن است کوچک به نظر برسد.
اما دهها درخواست کوچک میتوانند صدها ساعت زمان تیم را مصرف کنند.
از نظر مالی باید برای درخواستهای خارج از محدوده پروژه فرآیند مشخص وجود داشته باشد.
مثلاً:
درخواست ثبت شود.
زمان مورد نیاز برآورد شود.
هزینه تعیین شود.
مشتری تأیید کند.
سپس اجرا شود.
اگر این فرآیند وجود نداشته باشد، شرکت عملاً بخشی از خدمات خود را رایگان ارائه خواهد کرد.
دومین ستون؛ زمان تیم
در شرکت نرمافزاری Time Tracking فقط ابزار مدیریت پروژه نیست.
یک ابزار مالی نیز هست.
برای هر پروژه بهتر است بدانیم:
برنامهنویس چند ساعت کار کرده؟
طراح چند ساعت؟
مدیر پروژه چند ساعت؟
تست چند ساعت؟
پشتیبانی چند ساعت؟
وقتی این اطلاعات وجود داشته باشند، میتوان هزینه واقعی پروژه را دقیقتر محاسبه کرد.
هزینه ساعتی نیروی انسانی
فرض کنید مجموع حقوق و مزایای یک برنامهنویس در ماه مشخص است.
برای تحلیل مدیریتی میتوان هزینه تقریبی هر ساعت مؤثر او را محاسبه کرد.
این عدد فقط حقوق پایه نیست.
ممکن است شامل سهمی از:
مزایا
هزینه تجهیزات
دفتر
نرمافزار
مدیریت
سربار
باشد.
وقتی هزینه ساعتی مشخص باشد، قیمتگذاری پروژه بسیار منطقیتر میشود.
ساعات قابل فروش و غیرقابل فروش
تمام ساعات تیم مستقیماً برای مشتری قابل صورتحساب نیستند.
زمانهایی مانند:
جلسات داخلی
آموزش
رفع مشکلات داخلی
تحقیق
توسعه ابزارهای داخلی
وجود دارند.
مدیر باید نسبت ساعات قابل فروش به کل ساعات تیم را بررسی کند.
اگر تیم بسیار مشغول باشد اما درصد کمی از زمان به پروژههای درآمدزا اختصاص داشته باشد، بهرهوری اقتصادی شرکت پایین خواهد بود.
سومین ستون؛ حقوق برنامهنویسان
حقوق معمولاً یکی از بزرگترین هزینههای شرکت نرمافزاری است.
بنابراین باید بهدرستی بین:
پروژهها
محصولات داخلی
پشتیبانی
تحقیق و توسعه
فعالیتهای عمومی
تفکیک شود.
اگر یک برنامهنویس در ماه روی سه پروژه کار کرده باشد، کل هزینه او نباید فقط به یکی از پروژهها تخصیص داده شود.
این تقسیم باید بر اساس اطلاعات واقعی یا یک روش مدیریتی منطقی انجام شود.
چهارمین ستون؛ پروژه Fixed Price
در قرارداد Fixed Price، شرکت مبلغ مشخصی برای کل پروژه دریافت میکند.
در این مدل ریسک افزایش زمان عمدتاً روی شرکت است.
اگر پروژه قرار بوده ۱۰۰۰ ساعت زمان ببرد اما ۱۸۰۰ ساعت مصرف کند، مشتری الزاماً مبلغ بیشتری پرداخت نمیکند.
بنابراین برآورد اولیه در این مدل بسیار مهم است.
برای هر پروژه Fixed Price باید مرتب بررسی شود:
بودجه زمانی چقدر است؟
چقدر مصرف شده؟
چقدر کار باقی مانده؟
آیا پروژه هنوز سودآور است؟
Forecast پروژه
منتظر پایان پروژه نباشید تا متوجه زیان شوید.
مثلاً اگر پروژه ۶۰ درصد پیشرفت دارد ولی ۹۰ درصد بودجه زمانی مصرف شده، یک هشدار جدی وجود دارد.
مدیر باید دلیل را بررسی کند.
شاید:
Scope افزایش یافته.
تخمین اولیه اشتباه بوده.
مشکل فنی ایجاد شده.
تیم بهرهوری کافی نداشته.
یا مشتری فرایند را کند کرده است.
پنجمین ستون؛ قرارداد Time & Material
در مدل Time & Material، مشتری بر اساس زمان یا منابع مصرفشده پرداخت میکند.
در این مدل ثبت دقیق زمان اهمیت بسیار بیشتری دارد.
برای هر صورتحساب باید بتوان نشان داد:
چه کسی کار کرده؟
چند ساعت؟
روی چه کاری؟
با چه نرخ؟
اگر Time Tracking ناقص باشد، بخشی از درآمد شرکت ممکن است از بین برود.
ششمین ستون؛ طراحی سایت
شرکتهای طراحی سایت ممکن است چندین پروژه کوچک و متوسط همزمان داشته باشند.
برای هر پروژه باید هزینههای مربوط به:
طراحی
فرانتاند
بکاند
تولید محتوا
سئو اولیه
سرور
دامنه
پشتیبانی
تفکیک شوند.
اگر تمام پروژهها در یک حساب کلی قرار گیرند، مشخص نمیشود کدام نوع سایت سود بیشتری ایجاد میکند.
هفتمین ستون؛ توسعه نرمافزار اختصاصی
نرمافزار اختصاصی معمولاً پروژه پیچیدهتری است.
نیازمندیها
تحلیل
طراحی
توسعه
تست
استقرار
آموزش
پشتیبانی
همگی هزینه ایجاد میکنند.
قیمتگذاری فقط بر اساس زمان برنامهنویسی میتواند اشتباه باشد.
کل چرخه پروژه باید در برآورد دیده شود.
هشتمین ستون؛ محصول نرمافزاری
بعضی شرکتها به جای پروژه مشتری، محصول خودشان را توسعه میدهند.
مثلاً:
CRM
ERP
نرمافزار حسابداری
پلتفرم آموزشی
سیستم منابع انسانی
در این مدل ممکن است ماهها هزینه توسعه وجود داشته باشد بدون اینکه درآمد قابل توجهی ایجاد شود.
مدیریت باید بداند:
تا امروز چقدر روی محصول هزینه شده؟
درآمد محصول چقدر است؟
هزینه جذب مشتری چقدر است؟
هزینه پشتیبانی چقدر است؟
چه زمانی سرمایه اولیه برمیگردد؟
نهمین ستون؛ SaaS
در مدل SaaS مشتری معمولاً اشتراک ماهانه یا سالانه پرداخت میکند.
در این مدل فقط فروش اولیه مهم نیست.
شاخصهای دیگری اهمیت پیدا میکنند.
مانند:
MRR
ARR
Churn
CAC
LTV
هر کدام دید متفاوتی از سلامت اقتصادی محصول ارائه میکنند.
MRR
Monthly Recurring Revenue درآمد تکرارشونده ماهانه را نشان میدهد.
اگر شرکت ۵۰۰ مشتری اشتراکی داشته باشد، مدیر باید بداند ماه آینده چه میزان درآمد تکرارشونده قابل انتظار است.
افزایش MRR یکی از مهمترین نشانههای رشد پایدار یک کسبوکار SaaS است.
ARR
Annual Recurring Revenue درآمد تکرارشونده سالانه را نشان میدهد.
این شاخص میتواند تصویر بزرگتری از مقیاس محصول ایجاد کند.
اما باید توجه داشت درآمد قراردادی، وصول واقعی و درآمد حسابداری الزاماً همیشه یک عدد واحد نیستند.
Churn
اگر مشتریان اشتراک خود را لغو کنند، شرکت بخشی از درآمد تکرارشونده را از دست میدهد.
نرخ خروج مشتریان باید مرتب بررسی شود.
گاهی شرکت فروش بالایی دارد اما به دلیل Churn زیاد، رشد واقعی آن بسیار محدود است.
دهمین ستون؛ هزینه جذب مشتری
تبلیغات، فروش، کمیسیون و زمان تیم فروش همگی هزینه دارند.
CAC یا Customer Acquisition Cost نشان میدهد جذب هر مشتری تقریباً چه مقدار هزینه ایجاد کرده است.
اگر جذب یک مشتری ۱۰ میلیون تومان هزینه داشته باشد اما مشتری فقط ۵ میلیون تومان سود ایجاد کند، مدل اقتصادی مشکل دارد.
یازدهمین ستون؛ ارزش طول عمر مشتری
LTV نشان میدهد یک مشتری در طول رابطه با شرکت چه میزان ارزش اقتصادی ایجاد میکند.
در کسبوکار اشتراکی، فقط اولین پرداخت مهم نیست.
ممکن است مشتری سه سال اشتراک خود را ادامه دهد.
بنابراین تصمیم تبلیغاتی باید بر اساس سود بلندمدت مشتری نیز بررسی شود.
دوازدهمین ستون؛ پشتیبانی نرمافزار
پشتیبانی میتواند سودآور یا بسیار پرهزینه باشد.
برای قراردادهای پشتیبانی باید مشخص شود:
چه خدماتی شامل قرارداد است؟
ساعت پشتیبانی محدود است یا نامحدود؟
پشتیبانی تلفنی وجود دارد؟
تغییرات نرمافزار شامل قرارداد هستند؟
زمان پاسخ چقدر است؟
اگر تعریف پشتیبانی مبهم باشد، مشتری ممکن است توسعه جدید را بهعنوان پشتیبانی درخواست کند.
این موضوع حاشیه سود قرارداد را کاهش میدهد.
هزینه هر مشتری پشتیبانی
بهتر است زمان تیم پشتیبانی برای مشتریان بزرگ قابل اندازهگیری باشد.
ممکن است مشتری سالانه ۱۰۰ میلیون تومان پرداخت کند اما صدها ساعت زمان تیم را مصرف کند.
در مقابل مشتری دیگری با همان مبلغ، درخواست بسیار کمتری داشته باشد.
درآمد بهتنهایی کیفیت قرارداد را نشان نمیدهد.
سیزدهمین ستون؛ سرور و زیرساخت ابری
سرور، CDN، فضای ذخیرهسازی، دیتابیس، سرویس ایمیل، SMS و API میتوانند هزینه قابل توجهی ایجاد کنند.
بهتر است این هزینهها تا حد امکان به:
پروژه
محصول
مشتری
تخصیص داده شوند.
در سرویسهای ابری، افزایش تعداد کاربران ممکن است هزینه را نیز افزایش دهد.
مدیر باید Gross Margin هر محصول را بعد از هزینه زیرساخت ببیند.
چهاردهمین ستون؛ سرویسهای خارجی
شرکت نرمافزاری ممکن است از دهها ابزار و سرویس استفاده کند.
مثلاً:
Git
مدیریت پروژه
طراحی
هوش مصنوعی
مانیتورینگ
ایمیل
Analytics
گاهی اشتراکهایی وجود دارند که ماهها پرداخت میشوند ولی دیگر استفاده نمیشوند.
بهتر است فهرست تمام Subscriptionهای شرکت دورهای بررسی شود.
پانزدهمین ستون؛ تجهیزات
لپتاپ، مانیتور، سرور و تجهیزات شبکه نیز بخشی از داراییهای شرکت هستند.
برای تجهیزات مهم بهتر است مشخص باشد:
چه زمانی خریداری شده؟
در اختیار چه کسی است؟
قیمت خرید چقدر است؟
وضعیت چیست؟
مدیریت دارایی در شرکتهای در حال رشد اهمیت بیشتری پیدا میکند.
شانزدهمین ستون؛ درآمد مرحلهای پروژه
بسیاری از قراردادهای نرمافزاری پرداخت مرحلهای دارند.
مثلاً:
۳۰ درصد پیشپرداخت
۳۰ درصد بعد از طراحی
۳۰ درصد بعد از توسعه
۱۰ درصد هنگام تحویل
حسابداری باید برای هر پروژه نشان دهد:
مبلغ قرارداد
صورتحسابشده
دریافتشده
مطالبات
مرحله بعدی پرداخت
چه وضعیتی دارند.
پیشپرداخت مشتری
پول دریافتشده در ابتدای پروژه الزاماً به معنی سود همان روز نیست.
شرکت هنوز تعهد دارد خدمات را در آینده ارائه کند.
بنابراین در مدیریت نقدینگی باید تعهدات پروژههای باز نیز دیده شوند.
هفدهمین ستون؛ مطالبات مشتریان
یکی از مشکلات رایج شرکتهای نرمافزاری، تحویل کار قبل از دریافت کامل مطالبات است.
برای هر مشتری باید گزارش مشخص وجود داشته باشد.
مثلاً:
مبلغ قرارداد
صورتحساب
وصول
مانده
سررسید
اگر پرداخت یک مرحله انجام نشده، تصمیم درباره ادامه کار باید بر اساس سیاست مشخص شرکت باشد.
گزارش سنی مطالبات
مطالبات بهتر است به گروههایی مانند:
کمتر از ۳۰ روز
۳۰ تا ۶۰ روز
۶۰ تا ۹۰ روز
بیش از ۹۰ روز
تقسیم شوند.
مطالبات قدیمی ریسک بالاتری دارند و باید سریعتر پیگیری شوند.
هجدهمین ستون؛ قرارداد نگهداری سالانه
بعد از تحویل پروژه میتوان قرارداد نگهداری مستقل داشت.
این قرارداد میتواند درآمد تکرارشونده ایجاد کند.
برای هر قرارداد بهتر است مشخص باشد:
تاریخ شروع
تاریخ پایان
مبلغ
خدمات
هزینه تیم
سود
همچنین قبل از پایان قرارداد باید سیستم یادآوری تمدید داشته باشد.
نوزدهمین ستون؛ پروژه زیانده
یکی از مهمترین گزارشهای مدیریت، شناسایی پروژههایی است که از بودجه خارج شدهاند.
علائم پروژه زیانده میتواند شامل:
ساعات بیش از برآورد
تغییرات زیاد
تأخیر طولانی
پشتیبانی زیاد
مطالبات معوق
هزینه زیرساخت بالا
باشد.
هرچه پروژه زودتر شناسایی شود، امکان اصلاح بیشتر خواهد بود.
بیستمین ستون؛ سود هر پروژه
برای هر پروژه بهتر است گزارشی مانند این وجود داشته باشد:
درآمد قرارداد
منهای هزینه نیروی انسانی
منهای سرور و سرویس
منهای پیمانکار خارجی
منهای هزینه مستقیم
منهای سهمی از سربار
برابر با سود پروژه
بدون چنین گزارشی ممکن است مدیر فقط بر اساس مبلغ قرارداد تصمیم بگیرد.
بیستویکمین ستون؛ سود هر مشتری
برخی مشتریان چند پروژه، پشتیبانی و سرویس مختلف دارند.
در این حالت تحلیل سود مشتری اهمیت بیشتری پیدا میکند.
ممکن است یک مشتری فروش بالایی داشته باشد اما:
تخفیف زیادی گرفته باشد.
پرداخت دیر داشته باشد.
پشتیبانی سنگینی بخواهد.
مدیر باید رابطه مشتری را بر اساس سود واقعی نیز بررسی کند.
بیستودومین ستون؛ پیمانکاران و فریلنسرها
شرکت نرمافزاری ممکن است بخشی از کار را برونسپاری کند.
مثلاً:
طراحی
تولید محتوا
برنامهنویسی
تست
برای هر پیمانکار باید قرارداد و پروژه مرتبط مشخص باشند.
پرداختها نیز باید به پروژه صحیح تخصیص داده شوند.
مدل همکاری و تکالیف مالی مربوط نیز باید بر اساس ماهیت واقعی رابطه و آخرین مقررات بررسی شوند.
بیستوسومین ستون؛ هزینه تحقیق و توسعه
شرکتهای فناوری معمولاً بخشی از زمان تیم را صرف R&D میکنند.
مثلاً:
بررسی فناوری جدید
ساخت Prototype
توسعه محصول
آزمایش معماری جدید
این هزینه باید از پروژه مشتری تفکیک شود.
مدیر باید بداند چه میزان از بودجه شرکت صرف تحقیق و توسعه شده است.
بیستوچهارمین ستون؛ محصول داخلی در مقابل پروژه مشتری
یکی از تصمیمهای مهم شرکت نرمافزاری تخصیص نیروی انسانی است.
آیا برنامهنویس روی پروژهای کار کند که امروز درآمد ایجاد میکند؟
یا روی محصول داخلی که شاید سال آینده درآمد بیشتری ایجاد کند؟
این تصمیم فقط فنی نیست.
یک تصمیم مالی نیز هست.
گزارشهای مدیریتی باید هزینه فرصت این تخصیص را قابل مشاهده کنند.
بیستوپنجمین ستون؛ فروش و کمیسیون
اگر تیم فروش کمیسیون دریافت میکند، فرمول باید شفاف باشد.
کمیسیون بر اساس:
قرارداد امضاشده؟
مبلغ وصولشده؟
سود پروژه؟
محاسبه میشود؟
پرداخت کمیسیون فقط بر اساس مبلغ قرارداد بدون توجه به وصول میتواند نقدینگی شرکت را تحت فشار قرار دهد.
بیستوششمین ستون؛ بازاریابی
هزینههای:
تبلیغات گوگل
سئو
شبکههای اجتماعی
رویداد
تولید محتوا
باید ثبت شوند.
اما فقط مبلغ هزینه کافی نیست.
مدیر باید بداند هر کانال چه مقدار Lead و مشتری ایجاد کرده است.
تحلیل بازاریابی باید با داده مالی ترکیب شود.
بیستوهفتمین ستون؛ نقدینگی
ممکن است شرکت روی کاغذ پروژههای سودآوری داشته باشد ولی پول کافی در حساب بانکی نداشته باشد.
چرا؟
چون حقوق باید ماهانه پرداخت شود اما مشتری شاید چند ماه بعد تسویه کند.
به همین دلیل Forecast نقدینگی ضروری است.
برای ماههای آینده باید مشخص شود:
وصول قراردادها
حقوق
اجاره
سرور
مالیات
پیمانکاران
و سایر تعهدات
چقدر هستند.
Runway
برای شرکتهای محصولمحور یا استارتاپی یکی از شاخصهای مهم Runway است.
یعنی اگر درآمد جدیدی ایجاد نشود، موجودی نقد شرکت چند ماه هزینهها را پوشش میدهد؟
این شاخص به مدیر کمک میکند قبل از بحران نقدینگی تصمیم بگیرد.
بیستوهشتمین ستون؛ حسابداری مالیاتی شرکت نرمافزاری
فعالیت شرکتهای فناوری میتواند شامل انواع مختلفی از درآمد باشد:
طراحی نرمافزار
طراحی سایت
پشتیبانی
اشتراک
فروش لایسنس
خدمات ابری
مشاوره
آموزش
هرکدام باید بر اساس ماهیت واقعی فعالیت و مقررات جاری بررسی شوند.
اما چند اصل عمومی اهمیت زیادی دارند:
درآمدها کامل ثبت شوند.
قراردادها منظم باشند.
اسناد هزینه نگهداری شوند.
تراکنشهای بانکی قابل توضیح باشند.
حقوق و دستمزد منظم باشد.
و صورتحسابها قابل پیگیری باشند.
حقوق و دستمزد
شرکت فناوری معمولاً بخش بزرگی از هزینه خود را به نیروی انسانی اختصاص میدهد.
لیست حقوق، مزایا و اطلاعات کارکنان باید منظم باشد.
تکالیف مرتبط نیز باید بر اساس آخرین مقررات دوره مربوط انجام شوند.
قرارداد فریلنسر
فریلنسر، پیمانکار و نیروی استخدامی الزاماً شرایط یکسانی ندارند.
نوع رابطه باید بر اساس واقعیت همکاری تعیین شود.
استفاده از یک قرارداد یکسان برای تمام مدلهای همکاری میتواند مشکلات بعدی ایجاد کند.
صورتحسابها
صورتحساب پروژه باید با قرارداد و مرحله پروژه هماهنگ باشد.
برای خدمات اشتراکی نیز فرآیند صدور و ثبت باید منظم باشد.
الزامات مربوط به صورتحساب الکترونیکی و سایر فرآیندها باید بر اساس آخرین مقررات رسمی و وضعیت واقعی شرکت بررسی شوند.
ارزش افزوده و نوع خدمت
در حوزه فناوری، نوع خدمت یا محصول میتواند در بررسی مالیاتی اهمیت داشته باشد.
نباید بدون بررسی، تمام درآمدهای شرکت را در یک وضعیت واحد قرار داد.
برای اجرای واقعی باید ماهیت خدمت و آخرین مقررات رسمی بررسی شوند.
بیستونهمین ستون؛ حسابهای بانکی
تمام دریافتها باید به مشتری یا قرارداد مشخص متصل باشند.
اگر مبلغی وارد حساب شده، باید مشخص باشد مربوط به:
پیشپرداخت
قسط پروژه
پشتیبانی
اشتراک
یا موضوع دیگری است.
واریزهای ناشناس نباید برای مدت طولانی بدون تعیین تکلیف باقی بمانند.
سیامین ستون؛ داشبورد مدیریتی
مدیر شرکت نرمافزاری باید فراتر از مانده بانک نگاه کند.
داشبورد مالی میتواند نشان دهد:
فروش ماه
وصول ماه
مطالبات
MRR
هزینه حقوق
هزینه سرور
پروژههای سودآور
پروژههای پرریسک
نقدینگی
این اطلاعات امکان تصمیمگیری سریعتر را فراهم میکنند.
سیویکمین ستون؛ گزارش ظرفیت تیم
مدیر باید بداند ظرفیت تیم چگونه مصرف شده است.
مثلاً:
۶۰ درصد پروژه مشتری
۲۰ درصد محصول داخلی
۱۰ درصد پشتیبانی
۱۰ درصد فعالیت داخلی
این گزارش کمک میکند هزینه نیروی انسانی بهتر مدیریت شود.
سیودومین ستون؛ Utilization Rate
Utilization Rate نشان میدهد چه میزان از ظرفیت تیم برای فعالیتهای قابل فروش یا درآمدزا استفاده میشود.
اگر این عدد بسیار پایین باشد، حتی تیم حرفهای نیز میتواند برای شرکت هزینه زیادی ایجاد کند.
در مقابل استفاده بیش از حد از ظرفیت میتواند فرسودگی، افت کیفیت و تأخیر ایجاد کند.
هدف باید تعادل باشد.
سیوسومین ستون؛ بستن حساب ماهانه
در پایان هر ماه بهتر است بررسی شود:
تمام قراردادها ثبت شدهاند؟
درآمد پروژهها بهروز است؟
مطالبات کنترل شدهاند؟
وصولها ثبت شدهاند؟
ساعات تیم تکمیل شدهاند؟
هزینه پروژهها ثبت شدهاند؟
سرورها و اشتراکها کنترل شدهاند؟
حقوق ثبت شده؟
بانک مغایرتگیری شده؟
پروژههای زیانده شناسایی شدهاند؟
MRR و Churn بهروز شدهاند؟
Forecast نقدینگی اصلاح شده؟
تکالیف مالیاتی بررسی شدهاند؟
این فرآیند باعث میشود مدیریت همیشه اطلاعات نسبتاً بهروز داشته باشد.
اشتباه رایج اول؛ قیمتگذاری فقط بر اساس مبلغ رقبا
هزینه و ظرفیت تیم هر شرکت متفاوت است.
قیمت پروژه باید بر اساس هزینه واقعی، ریسک و حاشیه سود هدف نیز تعیین شود.
اشتباه دوم؛ عدم ثبت زمان
اگر زمان تیم ثبت نشود، محاسبه سود پروژه تقریباً بر اساس حدس انجام خواهد شد.
اشتباه سوم؛ اجرای تغییرات بدون قرارداد اضافه
Scope Creep یکی از مهمترین دلایل کاهش سود پروژه نرمافزاری است.
هر تغییر باید مدیریت شود.
اشتباه چهارم؛ نادیده گرفتن زمان پشتیبانی
پشتیبانی رایگان و نامحدود میتواند ماهها بعد از تحویل پروژه هزینه ایجاد کند.
دامنه پشتیبانی باید مشخص باشد.
اشتباه پنجم؛ ثبت نشدن هزینه سرور برای هر محصول
محصولی با درآمد زیاد ممکن است هزینه زیرساخت بسیار بالایی داشته باشد.
حاشیه سود باید بعد از هزینه Cloud دیده شود.
اشتباه ششم؛ تمرکز بر قرارداد به جای وصول
امضای قرارداد به معنی وجود پول در حساب نیست.
مطالبات باید مرتب کنترل شوند.
اشتباه هفتم؛ اشتباه گرفتن پیشپرداخت با سود
پیشپرداخت مشتری همراه با تعهد انجام پروژه است.
نباید تمام آن بهعنوان پول آزاد شرکت دیده شود.
اشتباه هشتم؛ پرداخت اشتراکهای بدون استفاده
شرکتهای فناوری معمولاً تعداد زیادی Subscription دارند.
بررسی دورهای آنها میتواند هزینههای غیرضروری را کاهش دهد.
اشتباه نهم؛ نداشتن تفکیک پروژه و محصول
هزینه توسعه محصول داخلی نباید در سود پروژه مشتری گم شود.
هر فعالیت باید مرکز مالی مشخص داشته باشد.
اشتباه دهم؛ توجه به مالیات فقط در پایان سال
اطلاعات مالیاتی از قرارداد، حقوق، صورتحساب و تراکنشهای روزانه شکل میگیرند.
کنترل باید در طول سال انجام شود.
نقش حسابدار شرکت نرمافزاری
حسابدار باید بتواند:
قراردادها را کنترل کند.
درآمد پروژهها را ثبت کند.
مطالبات را پیگیری کند.
حقوق را مدیریت کند.
هزینهها را به پروژه تخصیص دهد.
بانک را مغایرتگیری کند.
گزارش سود تهیه کند.
و امور مالیاتی را منظم نگه دارد.
اما در یک شرکت فناوری، شناخت مدل کسبوکار نیز بسیار اهمیت دارد.
نقش مدیر پروژه
مدیر پروژه پل میان تیم فنی و مالی است.
او باید بتواند:
پیشرفت پروژه
ساعات مصرفشده
تغییرات
ریسکها
زمان باقیمانده
را گزارش کند.
بدون این اطلاعات، واحد مالی فقط اتفاقات گذشته را میبیند.
نقش مدیر مالی
مدیر مالی باید بتواند پاسخ دهد:
کدام پروژه سود بیشتری دارد؟
کدام مشتری سودآورتر است؟
هزینه هر ساعت تیم چقدر است؟
چقدر درآمد تکرارشونده داریم؟
نقدینگی چند ماه شرکت را پوشش میدهد؟
آیا محصول داخلی اقتصادی است؟
کدام بخش بیش از بودجه هزینه دارد؟
این اطلاعات برای رشد شرکت ضروری هستند.
نقش مشاور مالیاتی
شرکتهای نرمافزاری ممکن است مدلهای درآمدی و قراردادی متفاوتی داشته باشند.
پروژه، اشتراک، پشتیبانی، لایسنس و خدمات آنلاین الزاماً از نظر اجرایی شرایط کاملاً یکسانی ندارند.
به همین دلیل بررسی تخصصی و دورهای بر اساس آخرین مقررات رسمی اهمیت دارد.
نقش مهرداد رحیمی در حسابداری مالی و مالیاتی شرکتهای نرمافزاری
مهرداد رحیمی در حوزه حسابداری، مدیریت مالی و امور مالیاتی فعالیت میکند و در شرکتهای نرمافزاری، سیستم مالی باید به مدل واقعی کسبوکار متصل شود.
یک سیستم حرفهای باید میان:
قرارداد
پروژه
نیروی انسانی
زمان
سرور
پشتیبانی
اشتراک
مشتری
مطالبات
بانک
و مالیات
ارتباط ایجاد کند.
مدیر باید بتواند از سیستم پاسخ سؤالهای مهم را دریافت کند:
این پروژه واقعاً چقدر سود کرده؟
هزینه هر ساعت تیم چقدر است؟
کدام مشتری بیشترین زمان پشتیبانی را مصرف میکند؟
کدام محصول بیشترین درآمد تکرارشونده را دارد؟
چقدر مطالبات معوق داریم؟
نقدینگی شرکت تا چند ماه هزینهها را پوشش میدهد؟
کدام پروژه از بودجه خارج شده؟
وقتی این اطلاعات منظم باشند، حسابداری از ثبت فاکتور و پرداخت حقوق فراتر میرود و به ابزار واقعی مدیریت شرکت فناوری تبدیل میشود.
جمعبندی
حسابداری مالی و مالیاتی شرکتهای فناوری اطلاعات و نرمافزاری باید بر پایه پروژه، زمان، نیروی انسانی و مدل درآمدی طراحی شود.
مهمترین بخشهای سیستم شامل:
قرارداد
پروژه
حقوق
Time Tracking
پشتیبانی
سرور
اشتراک
MRR
مطالبات
نقدینگی
و امور مالیاتی
هستند.
در این صنعت، زمان یکی از مهمترین منابع اقتصادی شرکت است.
اگر مشخص نباشد تیم روی چه کاری وقت گذاشته، حتی قراردادهای بزرگ نیز ممکن است سود واقعی کمی ایجاد کنند.
تفکیک پروژهها، کنترل Scope، ثبت زمان، محاسبه هزینه تیم، تحلیل درآمد تکرارشونده و پیشبینی نقدینگی میتوانند کیفیت مدیریت مالی شرکت نرمافزاری را به شکل قابل توجهی افزایش دهند.
در امور مالیاتی نیز قوانین و فرآیندهای اجرایی ممکن است تغییر کنند؛ بنابراین تصمیمهای واقعی باید بر اساس آخرین منابع رسمی و شرایط اختصاصی همان شرکت بررسی شوند.
این مقاله اطلاعات عمومی ارائه میکند و جایگزین بررسی اختصاصی اسناد، قراردادها یا پرونده مالی و مالیاتی نیست.
