Beancount.io LogoBeancount.io

SOC 2 Type II برای استارت‌آپ‌های SaaS: تعیین محدوده، بقا و گذراندن اولین ممیزی مشتری‌محور

زمان مطالعه 15 دقیقهMike ThriftMike Thrift
SOC 2 Type II برای استارت‌آپ‌های SaaS: تعیین محدوده، بقا و گذراندن اولین ممیزی مشتری‌محور

ایمیل ساعت ۴:۴۷ عصر جمعه به صندوق ورودی مشترک شما می‌رسد: «طبق خط‌مشی تدارکات ما، قبل از عقد قرارداد باید گزارش SOC 2 Type II شما را مشاهده کنیم.» مشتری بالقوه شما یک تیم مالی از لیست Fortune 500 است. ارزش معامله در درآمد تکرارپذیر سالانه (ARR) بیشتر از کل راند اول جذب سرمایه (Seed round) شماست. و شما، در خوش‌بینانه‌ترین حالت، عملاً هیچ صفحه‌ای از گزارش SOC 2 ندارید.

این صحنه هر هفته در استارتاپ‌های SaaS تکرار می‌شود. زمانی که یک بنیان‌گذار عبارت "SOC 2 Type II" را می‌شنود، تقریباً همیشه معامله‌ای در میان است — و تقریباً همیشه سوءتفاهمی درباره مدت زمان واقعی این فرآیند وجود دارد. گزارش SOC 2 Type II سندی نیست که سفارش دهید و دریافت کنید. بلکه نظری است که یک حسابرس مستقل درباره این موضوع صادر می‌کند که آیا کنترل‌های امنیتی شما در یک بازه مشاهده چند‌ماهه به طور موثر عمل کرده‌اند یا خیر. شما نمی‌توانید آن بازه زمانی را به صورت عطف به ماسبق ایجاد کنید. فقط می‌توانید آن را شروع کنید.

این راهنما بررسی می‌کند که SOC 2 Type II واقعاً چیست، چگونه آن را محدوده‌بندی کنید تا نقشه راه مهندسی شما را نبلعد، چگونه عادات نظارت مستمری را که حسابرسان در سال ۲۰۲۶ انتظار دارند ایجاد کنید و چگونه در حالی که کارهای انطباق به صورت موازی در حال انجام است، فرآیند فروش را فعال نگه دارید.

SOC 2 Type II واقعاً چه چیزی را آزمایش می‌کند؟

SOC 2 یک چارچوب گزارش‌دهی است که توسط انجمن حسابداران رسمی آمریکا (AICPA) نگهداری می‌شود. این یک «گواهینامه» نیست. هیچ مدرکی برای قاب کردن روی دیوار وجود ندارد. در عوض، یک موسسه حسابرسی (CPA) محیط کنترلی شما را بر اساس «معیارهای خدمات اطمینان» (Trust Services Criteria) بررسی می‌کند، سپس گزارشی صادر می‌کند که مشتریان، شرکا و تیم‌های تدارکات شرکت‌های بزرگ از آن برای ارزیابی این موضوع استفاده می‌کنند که آیا برون‌سپاری بخشی از عملیات‌شان به سرویس شما قابل قبول است یا خیر.

دو نوع وجود دارد:

  • نوع اول (Type I) گزارشی از وضعیت در یک مقطع زمانی خاص است. این گزارش کنترل‌های شما را توصیف کرده و طراحی آن‌ها را در یک تاریخ مشخص آزمایش می‌کند. سریع‌تر و ارزان‌تر است و به این سوال پاسخ می‌دهد: «آیا کنترل‌ها در تاریخ ۱ اکتبر وجود داشتند؟»
  • نوع دوم (Type II) گزارشی در طول یک بازه زمانی است. این گزارش هم طراحی و هم اثربخشی عملیاتی آن کنترل‌ها را در یک بازه مشاهده ۳ تا ۱۲ ماهه آزمایش می‌کند. این گزارش به سوال بسیار سخت‌تری پاسخ می‌دهد: «آیا کنترل‌ها واقعاً در هر روز و در کل دوره کار می‌کردند؟»

خریداران بزرگ تقریباً همیشه نوع دوم را می‌خواهند. نوع اول معمولاً به عنوان مدرکی در نظر گرفته می‌شود که نشان می‌دهد شما در مسیر هستید، نه مدرکی برای اینکه به مقصد رسیده‌اید. اگر یک تیم تدارکات بدون قید و شرط درخواست "SOC 2" کرد، فرض کنید منظور آن‌ها نوع دوم است.

بازه مشاهده بخشی است که بنیان‌گذاران را غافلگیر می‌کند. اگر مشتری بالقوه‌ای نیاز به دیدن گزارشی داشته باشد که بازه ۱ ژانویه تا ۳۰ ژوئن را پوشش می‌دهد و شما کنترل‌های خود را تازه از ۱۵ مارس مستقر کرده باشید، نمی‌توانید آن گزارش را ارائه دهید. شکاف در ماه‌های اولیه، طبق تعریف، یک «یافته» حسابرسی محسوب می‌شود. زمان‌بندی‌های حسابرسی به سرعت کار حسابرس شما بستگی ندارد؛ بلکه به میزان سابقه‌ای که از قبل ایجاد کرده‌اید بستگی دارد.

معیارهای خدمات اطمینان: محدوده خود را با دقت انتخاب کنید

هر گزارش SOC 2 بر اساس یک یا چند معیار از پنج معیار خدمات اطمینان (TSCs) محدوده‌بندی می‌شود:

۱. امنیت (Security) — تنها معیاری که اجباری است. گاهی اوقات «معیارهای مشترک» نامیده می‌شود و کنترل دسترسی، مدیریت تغییر، مدیریت آسیب‌پذیری، پاسخ به حوادث و ساختار حاکمیتی اساسی یک برنامه امنیت اطلاعات را پوشش می‌دهد. ۲. دسترس‌پذیری (Availability) — اگر قراردادهای مشتری شما شامل تعهدات زمان فعالیت یا توافق‌نامه سطح خدمات (SLA) است، این معیار مرتبط است. مواردی مانند برنامه‌ریزی ظرفیت، اقدامات حفاظتی محیطی و تست بازیابی پس از فاجعه را اضافه می‌کند. ۳. یکپارچگی پردازش (Processing Integrity) — اگر سرویس شما تراکنش‌ها یا محاسباتی انجام می‌دهد که صحت آن‌ها حیاتی است (پرداخت‌ها، سیستم‌های دفتر کل، موتورهای صورت‌حساب) مرتبط است. اکثر استارتاپ‌های SaaS می‌توانند در ابتدا از این مورد صرف‌نظر کنند. ۴. محرمانگی (Confidentiality) — اگر با داده‌های مشتری سر و کار دارید که به صورت قراردادی محدود شده‌اند اما لزوماً شخصی نیستند (کد منبع، داده‌های مالی، طرح‌های تجاری) مرتبط است. ۵. حریم خصوصی (Privacy) — اگر اطلاعات شخصی افراد را جمع‌آوری، استفاده، نگهداری یا امحا می‌کنید، مرتبط است. اغلب با تعهدات GDPR و CCPA همپوشانی دارد.

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

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

هزینه و مدت زمان آن چقدر است؟

برای یک شرکت کوچک SaaS در سال ۲۰۲۶، اعداد واقعی به این صورت است:

  • هزینه‌های حسابرس: ۱۰,۰۰۰ تا ۲۵,۰۰۰ دلار برای گزارش نوع دوم «فقط امنیت» از یک موسسه حسابرسی متوسط یا تخصصی. افزودن دسترس‌پذیری و حریم خصوصی می‌تواند این مبلغ را به ۲۵,۰۰۰ تا ۳۰,۰۰۰ دلار برساند. موسسات Big Four چند برابر این مبالغ را دریافت می‌کنند و معمولاً اصلاً با استارتاپ‌های کوچک همکاری نمی‌کنند.
  • پلتفرم GRC: مبلغ ۵,۰۰۰ تا ۱۲,۰۰۰ دلار در سال برای جمع‌آوری خودکار شواهد و مدیریت خط‌مشی‌ها.
  • ارتقای ابزارهای امنیتی: ۳,۰۰۰ تا ۸,۰۰۰ دلار برای رفع شکاف‌ها در بخش‌های MDM، SIEM، اسکن آسیب‌پذیری یا تامین‌کنندگان بررسی سوابق.
  • زمان داخلی: ۱۰۰ تا ۲۰۰ ساعت زمان مهندسی و عملیاتی در طول چرخه آمادگی و حسابرسی.

در مجموع، برای یک شرکت کوچک SaaS که این کار را هوشمندانه انجام می‌دهد، انتظار هزینه‌ای بین ۲۰,۰۰۰ تا ۳۵,۰۰۰ دلار در سال اول را داشته باشید. سال‌های بعد هزینه‌ها به میزان قابل توجهی کاهش می‌یابد زیرا کارهای سنگین مربوط به خط‌مشی‌ها، ابزارها و فرآیندها قبلاً انجام شده است.

زمان‌بندی به بازه مشاهده بستگی دارد:

  • مرحله آمادگی: ۱ تا ۳ ماه برای نوشتن خط‌مشی‌ها، پیاده‌سازی کنترل‌ها، پیکربندی ابزارها و رفع شکاف‌ها. یک ارزیابی آمادگی رسمی از سوی حسابرس آینده شما ۱۰,۰۰۰ تا ۱۷,۰۰۰ دلار هزینه و چند هفته زمان اضافه می‌کند، اما ریسک حسابرسی اصلی را به شدت کاهش می‌دهد.
  • بازه مشاهده: حداقل ۳ ماه برای یک گزارش نوع دوم «بازه کوتاه»، ۶ ماه برای یک گزارش معتبرتر و ۱۲ ماه برای یک چرخه تمدید. پذیرش بازه‌های زمانی در میان خریداران بزرگ متفاوت است. بسیاری از آن‌ها یک گزارش ۳ ماهه نوع دوم را می‌پذیرند، به شرطی که متعهد شوید گزارش ۱۲ ماهه بعدی را نیز ارائه دهید.
  • عملیات میدانی حسابرسی و گزارش: ۲ تا ۴ هفته برای بررسی شواهد، جلسات توضیحی، نمونه‌گیری و تدوین پیش‌نویس گزارش پس از پایان بازه زمانی.

استارتاپی که کارهای آمادگی را در ژانویه شروع کند و یک بازه مشاهده ۳ ماهه را اجرا کند، می‌تواند تا اواخر مه یا اوایل ژوئن گزارش SOC 2 Type II را در دست داشته باشد. این سریع‌ترین مسیر معتبر است. هر کسی که وعده زمانی سریع‌تری می‌دهد، یا در حال فروش نوع اول است یا چیزی را می‌فروشد که بعداً باعث شرمساری شما خواهد شد.

کنترل‌هایی که واقعاً استارتاپ‌ها را به چالش می‌کشند

معیارهای خدمات اعتماد (Trust Services Criteria) منتشر شده شامل ده‌ها معیار مشترک (CC1 تا CC9) و ده‌ها معیار دیگر برای دسته‌های اختیاری است. در عمل، همان تعداد اندک از کنترل‌ها هستند که بیشترین دردسر را ایجاد می‌کنند:

بررسی‌های دسترسی (Access reviews). شما باید دسترسی کاربران به سیستم‌های عملیاتی و داده‌های مشتری را در یک بازه زمانی مشخص - معمولاً فصلی - بازبینی کنید. این کنترل نه به دلیل عدم انجام بررسی، بلکه به دلیل ناقص بودن شواهد شکست می‌خورد: نبود تیکت، نبود تأیید نهایی، یا نبود سابقه حساب‌های حذف شده. اگر نتوانید لیستی امضا شده از اینکه چه کسی، چه چیزی را در چه تاریخی بررسی کرده است نشان دهید، آن بررسی به حساب نمی‌آید.

مدیریت تغییرات (Change management). هر تغییر کدی که با محیط عملیاتی در تماس است به یک درخواست بازبینی (Pull Request)، بازبینی توسط همکار، تست خودکار و یک استقرار (deploy) مستند نیاز دارد. اکثر تیم‌های مهندسی در حال حاضر این کار را انجام می‌دهند. حالت شکست، اصلاحات اضطراری (hotfix) است که خط لوله (pipeline) را دور می‌زند. حسابرسان موارد استقرار را به صورت تصادفی نمونه‌برداری می‌کنند و یک فشار (push) خودسرانه در بازه زمانی مشاهده می‌تواند به یک «یافته» (finding) در گزارش تبدیل شود.

بررسی‌های پیشینه (Background checks). هر کارمندی که به محیط عملیاتی دسترسی دارد، قبل از اعطای آن دسترسی، نیاز به یک بررسی پیشینه مستند دارد. استارتاپ‌ها مکرراً در روز اول دسترسی را می‌دهند و بررسی را «به‌زودی» انجام می‌دهند. این یک یافته حسابرسی است. متن کنترل می‌گوید «پیش از دسترسی» و حسابرسان تاریخ‌ها را چک خواهند کرد.

مدیریت تأمین‌کنندگان (Vendor management). شما به فهرستی از زیرپردازشگران (subprocessors)، شواهدی مبنی بر اینکه وضعیت امنیتی هر یک را بررسی کرده‌اید (معمولاً با جمع‌آوری گزارش SOC 2 آن‌ها) و یک مالک مستند برای این رابطه نیاز دارید. حالت شکست، ابزارهای SaaS سایه‌ای است که یک بخش با کارت اعتباری خریداری کرده و هرگز به کسی در مورد آن نگفته است.

مدیریت آسیب‌پذیری (Vulnerability management). شما به یک بازه زمانی مستند برای اسکن، یک SLA مشخص برای اصلاح بر اساس شدت آسیب‌پذیری، و شواهدی نیاز دارید که نشان دهد واقعاً آن SLAها را رعایت می‌کنید. بسیاری از استارتاپ‌ها خط‌مشی‌ای می‌نویسند که می‌گوید «آسیب‌پذیری‌های بحرانی ظرف ۷ روز وصله می‌شوند» و سپس بی‌سرصدا اجازه می‌دهند یافته‌های بحرانی ۶۰ روز بمانند چون ارائه ویژگی‌های جدید محصول ضروری‌تر بوده است. حسابرس تیکت‌ها را نمونه‌برداری خواهد کرد.

پاسخ به حوادث (Incident response). شما به یک طرح مکتوب پاسخ به حوادث و شواهدی مبنی بر آزمایش آن نیاز دارید. تمرینات رومیزی (Tabletop exercises) پذیرفته هستند. تمرین لازم نیست پیچیده باشد، اما جلسه باید تشکیل شود، همراه با دستور جلسه، لیست حضور و غیاب و صورت‌جلسه.

دسترسی منطقی — MFA، سیاست رمز عبور، زمان انقضای نشست. این‌ها معمولاً در استارتاپ‌های مدرن که از ارائه‌دهندگان هویت مانند Okta یا Google Workspace استفاده می‌کنند مشکلی ندارند، اما جمع‌آوری شواهد آن‌ها دشوار است. شما به اسکرین‌شات از تنظیمات، خروجی گرفتن از سیاست‌ها و اثبات اینکه این کنترل‌ها در کل بازه زمانی مشاهده اعمال شده‌اند، نیاز دارید.

پایش مداوم: در سال ۲۰۲۶ معیارها سخت‌گیرانه‌تر شده است

تغییر تعیین‌کننده در انتظارات SOC 2 طی سه سال گذشته، حرکت از بررسی‌های دوره‌ای تصادفی به سمت پایش مداوم (Continuous Monitoring) است. حسابرسان در سال ۲۰۲۶ به طور فزاینده‌ای انتظار دارند که محیط کنترلی شما هر روز شواهد قابل تأییدی تولید کند - نه اینکه شما در هفته قبل از شروع عملیات میدانی، برای جمع‌آوری آن‌ها دست‌پاچه شوید.

به طور مشخص، این به معنای موارد زیر است:

  • جمع‌آوری خودکار شواهد. پلتفرم‌های GRC مانند Vanta، Drata، Secureframe و Sprinto با ارائه‌دهنده هویت، حساب‌های ابری، مخازن کد، سیستم تیکتینگ و ابزارهای منابع انسانی شما یکپارچه می‌شوند تا شواهد را به صورت مستمر استخراج کنند. آن‌ها نقص کنترل را - مثلاً دسترسی باقی‌مانده یک کارمند خارج شده از شرکت به AWS - به جای ماه‌ها، در عرض چند ساعت شناسایی می‌کنند.
  • داشبوردهای بلادرنگ. شما باید بتوانید به یک صفحه واحد نگاه کنید و وضعیت عملیاتی هر کنترل را ببینید. اگر کنترلی در حال شکست خوردن است، باید ظرف ۴۸ ساعت همراه با مسیری برای اصلاح علامت‌گذاری شود.
  • مستندات حسابرسی بدون وقفه. حسابرسان به دنبال تداوم هستند. اگر در شواهد بررسی دسترسی شما ماه‌هایی وجود داشته باشد که هیچ بررسی‌ای در آن انجام نشده، این یک یافته است. اگر گزارش اسکن آسیب‌پذیری شما یک فصل را جا انداخته باشد، این یک یافته است. استاندارد ضمنی در سال ۲۰۲۶ این است: هر روز از بازه زمانی مشاهده باید شواهدی تولید کند که نشان دهد کنترل در حال اجرا بوده است.

تغییر فرهنگی که این امر می‌طلبد واقعی است. انطباق (Compliance) باید به عادتی تبدیل شود که در نحوه ارائه کد توسط تیم مهندسی، جذب نیروی جدید توسط تیم IT و انتخاب تأمین‌کنندگان توسط تیم مالی شما نهادینه شده است. برخورد با SOC 2 به عنوان یک جلسه فشرده فصلی برای کارهای میدانی، در فضای حسابرسی فعلی، به جای گزارش‌های مقبول، منجر به اظهارنظرهای مشروط (qualified opinions) می‌شود - و زمانی که تیم تدارکات یک سازمان بزرگ آن را می‌خواند، یک گزارش مشروط اغلب بدتر از نداشتن هیچ گزارشی است.

اجرای همزمان حسابرسی و فروش

تضاد اساسی در کارهای SOC 2 مشتری‌محور این است که حسابرسی ماه‌ها طول می‌کشد و معامله منتظر نمی‌ماند. در اینجا نحوه زنده نگه داشتن جریان فروش آمده است:

  1. با گزارش نوع اول (Type I) و یک برنامه اصلاحی شروع کنید. یک گزارش نوع اول می‌تواند ظرف چند هفته پس از تکمیل آمادگی صادر شود. این چیزی نیست که خریداران سازمانی در نهایت می‌خواهند، اما سیگنالی معتبر است که نشان می‌دهد شما محیط کنترلی را برپا کرده‌اید و گزارش نوع دوم (Type II) در جریان است. بسیاری از تیم‌های تدارکات، قرارداد را با یک گزارش نوع اول به همراه تعهد کتبی برای ارائه گزارش نوع دوم ظرف نه ماه امضا می‌کنند.
  2. از الگوی نامه‌ی پل (Bridge letter) استفاده کنید. اگر گزارش نوع دوم قبلی دارید که دوره‌ای را پوشش می‌دهد که اکنون به پایان رسیده است، حسابرس شما می‌تواند یک «نامه‌ی پل» صادر کند که در آن قید شده، تا جایی که آن‌ها اطلاع دارند، هیچ تغییر اساسی بین تاریخ پایان گزارش و امروز رخ نداده است. نامه‌های پل گزارش قدیمی شما را برای معاملات جدید معتبر نگه می‌دارند در حالی که حسابرسی بعدی در جریان است.
  3. مستندات مناسب را تحت NDA به اشتراک بگذارید. برخی از مشتریان بالقوه، خط‌مشی‌های امنیتی مکتوب، خلاصه تست نفوذ و نمودارهای معماری شما را به جای گزارش SOC 2 برای توافق‌نامه‌های اثبات مفهوم (PoC) می‌پذیرند. این مدارک را آماده، به‌روز و بسته‌بندی شده داشته باشید تا پرسش‌نامه‌های امنیتی به یک انحراف چند هفته‌ای برای تیم مهندسی شما تبدیل نشوند.
  4. در مورد زمان‌بندی صادق باشید. قول دادن گزارش نوع دوم در تاریخی که نمی‌توانید به آن برسید، در صورت تأخیر، اعتماد مشتری را از بین می‌برد. ارائه یک جدول زمانی معتبر که توسط یک نامه تعهد با یک موسسه حسابرسی رسمی (CPA) پشتیبانی می‌شود، بسیار پایدارتر است.

استارتاپ‌هایی که این موضوع را به بهترین شکل مدیریت می‌کنند، با SOC 2 نه به عنوان یک تمرین آتش‌نشانی ناشی از یک معامله واحد، بلکه به عنوان زیرساختی بنیادین برخورد می‌کنند که کل یک بخش از مشتریان را برای آن‌ها باز می‌کند. اولین حسابرسی هزینه‌بر و دشوار است. چهارمین مورد، تنها یک ردیف بودجه‌ای آرام است.

جنبه دفترداری هزینه‌های انطباق

برنامه SOC 2 یک مرکز هزینه قابل توجه است و نحوه ثبت آن در پایان سال مالی اهمیت زیادی دارد. هزینه‌های حسابرس، اشتراک‌های پلتفرم GRC، مشاوره آمادگی و ابزارهای امنیتی، همگی از حساب‌های مختلف دفتر کل عبور می‌کنند و اغلب به اشتباه کدگذاری می‌شوند. هزینه‌های حسابرس و مشاوره معمولاً زیرمجموعه خدمات حرفه‌ای قرار می‌گیرند، در حالی که هزینه اشتراک ابزارها در بخش هزینه‌های نرم‌افزار ثبت می‌شود. برخی شرکت‌های نوپا بخشی از کارهای آمادگی را به عنوان بخشی از توسعه نرم‌افزار برای استفاده داخلی تحت استاندارد ASC 350-40 سرمایه‌ای می‌کنند، هرچند آستانه انجام دقیق این کار بسیار محدود است.

فراتر از دسته‌بندی، برنامه انطباق جریانی از هزینه‌های مکرر ایجاد می‌کند — تمدید سالانه حسابرس، هزینه‌های پلتفرم GRC، هزینه‌های تامین‌کننده بررسی پیشینه و قراردادهای تست نفوذ — که باید نسبت به بودجه ردیابی شوند. بسیاری از استارت‌آپ‌ها برای سال دوم بودجه کمی در نظر می‌گیرند، زیرا شوک قیمتی مرحله آمادگی را به یاد دارند اما فراموش می‌کنند که هزینه‌های عملیاتی مکرر نیز مبالغ واقعی هستند. دفترداری تمیز و تحت کنترل نسخه از همان ابتدا، پاسخگویی به سوالات بررسی موشکافانه (due-diligence) دور بعدی سرمایه‌گذاران و پرسشنامه‌های امنیتی مشتریان را بسیار آسان‌تر می‌کند؛ چرا که هر دو درباره محیط کنترلی و انضباط مالی شما در قبال آن سوال خواهند کرد.

سوابق مالی خود را مانند کنترل‌های امنیتی‌تان آماده حسابرسی نگه دارید

چه در حال آماده شدن برای SOC 2 نوع دوم (Type II) یا سری A باشید، و چه صرفاً بخواهید دفاتر مالی را هر ماه به موقع ببندید، یک اصل ثابت وجود دارد: سیستم‌های قابل حسابرسی همیشه بر ثبت دستی سوابق پیروز می‌شوند. Beancount.io حسابداری متن‌ساده‌ای را ارائه می‌دهد که شفاف، تحت کنترل نسخه و آماده برای هوش مصنوعی است — و به بنیان‌گذاران و تیم‌های مالی یک مسیر حسابرسی کامل بدون پیچیدگی‌های مبهم ابزارهای دفترداری قدیمی می‌دهد. به‌صورت رایگان شروع کنید و ببینید چرا توسعه‌دهندگان و متخصصان امور مالی به حسابداری متن‌ساده روی می‌آورند.