یک ابزار هوش مصنوعی میتواند تراکنشهای یک ماه را در چند دقیقه دستهبندی کند. همچنین میتواند یک توصیف مبهم بانکی را به ورودیای تبدیل کند که مطمئن به نظر میرسد و پیش از آنکه کسی متوجه شود، در سه گزارش باقی میماند. ریسک این نیست که اتوماسیون اشتباه میکند؛ هر فرآیند حسابداری اینگونه است. ریسک این است که یک حدس بازبینِینشده به تاریخچه مالی کسبوکار تبدیل شود.
کسبوکارهای کوچک در حال حاضر در حال آزمایش هوش مصنوعی در کارهای مالی و عملیاتی هستند. تحلیل اخیر فدرال رزرو نشان داد که نزدیک به ۴۰٪ از کسبوکارهای کوچک بررسیشده از هوش مصنوعی استفاده میکنند یا بهزودی قصد استفاده از آن را دارند، در حالی که سایر معیارها نشان میدهند که میزان پذیرش بسته به اینکه نظرسنجی شرکتها، کارمندان یا استفاده برنامهریزیشده را شمارش کند، بهطور قابلتوجهی متفاوت است. این تنوع یک هشدار مفید است: «ما از هوش مصنوعی استفاده میکنیم» توصیف نمیکند که ابزار مجاز به انجام چه کاری است، چه دادهای میبیند، یا چه کسی کار آن را بررسی میکند.
پاسخ این نیست که اتوماسیون را ممنوع کنیم یا هر پیشنهادی را بهصورت دستی تأیید کنیم. پاسخ این است که کنترلهایی بر تصمیمهایی که مهم هستند قرار دهیم. این راهنما نشان میدهد چگونه محدودیتهای تأیید را تنظیم کنید، اسناد منبع را حفظ کنید، خروجیهای هوش مصنوعی را آزمایش کنید، و مسیر حسابرسی را حفظ کنید که حسابدار، مالک، وامدهنده یا حسابرس بتواند آن را دنبال کند.
با تصمیم شروع کنید، نه ابزار
«حسابداری با هوش مصنوعی» میتواند چند فعالیت بسیار متفاوت را شامل شود:
- استخراج تاریخ، فروشنده، مبلغ یا شماره فاکتور از یک سند
- پیشنهاد حساب، رفتار مالیاتی، کلاس، پروژه یا مشتری
- تطبیق پرداخت با فاکتور یا تراکنش بانکی با ورودی موجود
- تهیه پیشنویس توضیح تسویهحساب یا گزارش مدیریتی
- ایجاد، ویرایش یا ثبت یک تراکنش
- شروع پرداخت، تغییر مشخصات بانکی فروشنده، یا ثبت اظهارنامه
این استفادهها ریسک یکسانی ندارند. پیشنهادی که یک فاکتور نرمافزاری به یک حساب هزینه موجود تعلق دارد، بهراحتی قابل بازبینی و معکوسسازی است. پیشنهادی که حقوق و دستمزد، مالیات فروش، برنامه شناسایی درآمد یا حساب بانکی فروشنده را تغییر میدهد، به کنترل بسیار قویتری نیاز دارد.
قبل از فعالسازی یک یکپارچهسازی، یک جمله درباره وظیفه مجاز آن بنویسید:
سیستم ممکن است دستهای برای تراکنشهای زیر ۵۰۰ دلار پیشنهاد دهد، مشروط بر اینکه سند منبع پیوست شده باشد؛ هر چیزی که در دفتر کل ثبت میشود باید توسط انسان تأیید شود.
این جمله مرز را تعریف میکند. همچنین وقتی فروشنده ویژگی جدیدی اضافه میکند، یک سؤال قابل آزمایش به شما میدهد: آیا رفتار جدید در محدوده وظیفه تأییدشده باقی میماند، یا سیستم بیصدا از توصیه به اجرا منتقل شده است؟
از نردبان مجوز چهارسطحی استفاده کنید
یک مدل کنترل مؤثر خواندن، پیشنهاد، ثبت و انتقال پول را جدا میکند. میتوانید مبالغ دلاری را با کسبوکار خود تطبیق دهید، اما تمایز باید قابل مشاهده بماند.
سطح ۱: تحلیل فقطخواندنی
سیستم میتواند یک مجموعه داده کنترلشده را بازرسی و خلاصهای تولید کند. نمیتواند دفتر کل را ویرایش کند، پیامهایی به مشتریان ارسال کند یا پرداختها را فعال کند. مثالها شامل شناسایی تراکنشهای دستهبندینشده، یافتن شماره فاکتورهای تکراری و برجستهکردن تغییرات غیرعادی ماهبهماه است.
این امنترین مکان برای شروع است، زیرا خروجی یک صف کاری است نه یک رویداد مالی. میتوانید قبل از اعطای دسترسی نوشتن، مفید بودن و الگوهای خطا را ارزیابی کنید.
سطح ۲: پیشنهادهای پیشنویس
سیستم ممکن است یک تراکنش پیشنهادی، تطبیق تسویهحساب، ثبت دفتر روزنامه یا پیشنهاد کدگذاری ایجاد کند. باید ورودی اصلی را حفظ کند و منتظر یک بازبین نامگذاریشده بماند. بازبین باید بتواند بدون بازنویسی دادههای زیرین، پیشنهاد را بپذیرد، تغییر دهد یا رد کند.
از وضعیت عمومی «تأییدشده توسط سیستم» استفاده نکنید. ثبت کنید چه کسی آن را تأیید کرده، چه زمانی، چه چیزی تأیید شده و آیا بازبین هر فیلدی را تغییر داده است. یک پیشنهاد تغییر داده شده داده آزمایشی ارزشمندی است: به شما میگوید مدل یا قاعده در کجا نیاز به بهبود دارد.
سطح ۳: ثبت خودکار کمریسک
ثبت خودکار فقط برای تراکنشهای باریک و تکراری با یک جایگزین تعریفشده مناسب است. به عنوان مثال، یک کارمزد بانکی تکراری ممکن است بهصورت خودکار ثبت شود وقتی حساب بانکی، محدوده مبلغ، الگوی توضیحات، ارز و حساب همه با یک قاعده ثابت مطابقت داشته باشند.
سقفی هم برای مبلغ و هم برای پیامد تعیین کنید. یک تراکنش ۲۰۰ دلاری همچنان میتواند پرریسک باشد اگر بر مالیات حقوق و دستمزد، صندوق محدود، طرف مرتبط یا سپرده مشتری تأثیر بگذارد. محدودیت دلاری کم کافی نیست؛ حسابها و انواع تراکنشهای مستثنیشده را نیز تعریف کنید.
هر مورد ثبتشده بهصورت خودکار باید بهراحتی نمونهبرداری، معکوس و ردیابی به منبع آن باشد. اتوماسیون فقط زمانی کنترل میشود که بازبین بتواند بدون اتکا به رابط فعلی ابزار، ببیند چه اتفاقی افتاده است.
سطح ۴: اقدامات خارجی
پرداختها، بازپرداختها، ارائههای حقوق و دستمزد، ثبت اظهارنامه مالیاتی، تغییرات مشخصات فروشنده و ارتباط با مشتری باید به تأیید صریح انسانی نیاز داشته باشند. یک مدل میتواند دسته را آماده کند یا استثناها را شناسایی کند، اما اقدام نهایی باید از تحلیلی که آن را تولید کرده جدا باشد.
برای پرداختهای با ارزش بالا و هر تغییری در مشخصات بانکی گیرنده، از تأیید دو نفره استفاده کنید. نفر دوم باید درخواست را از طریق یک کانال شناختهشده تأیید کند، نه با پاسخ به همان ایمیل یا چتی که حاوی تغییر بود.
ماتریس تأییدی بسازید که مردم واقعاً بتوانند از آن استفاده کنند
یک خطمشـی تأیید زمانی عملی میشود که به چهار سؤال برای هر گردش کار پاسخ دهد:
۱. سیستم چه چیزی میتواند بخواند؟ ۲. چه چیزی میتواند پیشنهاد یا تغییر دهد؟ ۳. چه چیزی به یک بازبین نیاز دارد یا دو بازبین؟ ۴. چه شواهدی باید قبل از نهاییشدن اقدام وجود داشته باشد؟
به عنوان مثال، یک شرکت خدمات کوچک ممکن است از ماتریسی مانند این استفاده کند:
| گردش کار | هوش مصنوعی ممکن است انجام دهد | کنترل انسانی | شواهد مورد نیاز |
|---|---|---|---|
| دستهبندی خوراک بانکی | پیشنهاد حساب زیر ۵۰۰ دلار | حسابدار تأیید میکند؛ استثناها باز میمانند | خط بانکی، دلیل، حساب نهایی |
| استخراج فاکتور | خواندن فیلدها و تهیه پیشنویس قبض | بازبین تأمینکننده، مبلغ، مالیات و وضعیت تکراری را بررسی میکند | فاکتور اصلی و تاریخچه تغییر فیلد |
| تطبیق پرداخت مشتری | پیشنهاد تطبیق فاکتور | بازبین پرداختهای جزئی، دستهای یا مورد اختلاف را حل میکند | حواله، فاکتورهای تطبیقشده، یادداشت استثنا |
| بستن پایان ماه | تهیه پیشنویس سؤالات انحراف | کنترلکننده تنظیمات و انحرافات بااهمیت را تأیید میکند | نسخه گزارش، پاسخها، ورودیهای پشتیبان |
| ثبت حقوق و دستمزد یا مالیات | تهیه بسته بازبینی | شخص مجاز پس از بازبینی مستقل ارائه میکند | نسخه ثبت، تأیید، اثبات پرداخت |
| تغییر بانک فروشنده | علامتگذاری درخواست و آمادهسازی کار | تأیید تماس دو نفره | درخواست، سابقه تأیید، تاریخ اجرا |
ماتریس باید یک مالک را نام ببرد، نه فقط یک دپارتمان را. «مالی» نمیتواند یک استثنا را ساعت ۴:۵۵ بعدازظهر تأیید کند؛ یک شخص با دسترسی مناسب باید مالک آن باشد. هر زمان کسبوکار یک منبع داده اضافه میکند، فرآیند پرداخت را تغییر میدهد یا یک ویژگی هوش مصنوعی جدید متصل میکند، ماتریس را بازبینی کنید.
زنجیره شواهد را حفظ کنید
یک عدد تولیدشده توسط هوش مصنوعی سند منبع نیست. این تفسیری از یک یا چند ورودی است. سوابق شما باید امکان حرکت به عقب از یک ورودی ثبتشده به شواهد و به جلو از شواهد به تصمیم نهایی را فراهم کند.
برای هر مورد خودکار یا با کمک هوش مصنوعی، موارد زیر را در صورت لزوم حفظ کنید:
- فاکتور اصلی، رسید، خط بانکی، قرارداد، صورتحساب یا منبع دیگر
- شناسه پایدار فایل منبع و تاریخ دریافت
- نسخه گردش کار یا مدلی که پیشنهاد را تولید کرده است
- فیلدهای ورودی یا مجموعه تراکنشهای استفادهشده برای تصمیم
- خروجی پیشنهادی، شامل وضعیت اطمینان یا استثنا در صورت وجود
- خروجی نهایی پس از ویرایشهای انسانی
- هویت بازبین، زمان تأیید و اقدام تأیید
- هر تصحیح، معکوسسازی یا توضیح پیگیری
به یک اسکرینشات از داشبورد به عنوان سوابق کامل تکیه نکنید. اسکرینشاتها میتوانند برای زمینه مفید باشند، اما اغلب ورودی، نسخه، مجوزها و تاریخچه تغییر را حذف میکنند. در صورت امکان، سوابق قابل خواندن توسط ماشین را صادر کنید و آنها را با همان سیاست نگهداری مانند اوراق کاری حسابداری زیرین ذخیره کنید.
اینجا جایی است که طراحی دفتر کل شما اهمیت دارد. یک سوابق متنی و نسخهکنترلشده میتواند خط دقیقی را که تغییر کرده، زمینه commit یا بازبینی، و رابطه بین یک تنظیم و فایل پشتیبان آن را نشان دهد. هدف این نیست که هر مالک یک مهندس نرمافزار شود. هدف این است که تاریخچه مالی قابل بازرسی باقی بماند حتی اگر فروشنده رابط خود را تغییر دهد یا یک ویژگی را بازنشسته کند.
خروجیها را قبل از اعتماد آزمایش کنید
کیفیت هوش مصنوعی باید در برابر حالتهای خطای واقعی کسبوکار سنجیده شود، نه فقط در برابر دمو فروشنده. یک مجموعه آزمایشی از تراکنشهای تاریخی ایجاد کنید و عمداً موارد دشوار را شامل شود:
- نامهای مشابه فروشنده و روابط شرکت مادر/زیرمجموعه
- فاکتورهای تقسیمشده و قبضهای با چند نرخ مالیات
- اعتبارات، بازپرداختها، باطلسازیها و پرداختهای معکوس
- مبالغ و کارمزدهای ارز خارجی
- سپردههای مشتری، پیشپرداختها، کارتهای هدیه و سایر بدهیها
- خریدهای سرمایهای که شبیه لوازم معمولی هستند
- پرداختهای پیمانکار که نیاز به رفتار گزارشگری متفاوت دارند
- تراکنشهای طرفهای مرتبط و دفترهای روزنامه دستی غیرعادی
نتیجه مورد انتظار را قبل از نشان دادن به سیستم برچسبگذاری کنید. سپس حداقل چهار مورد را اندازهگیری کنید:
۱. دقت فیلد: آیا تاریخها، مبالغ، ارزها، فروشندگان و شماره فاکتورها بهدرستی استخراج شدهاند؟ ۲. دقت تصمیم: آیا حساب، کد مالیاتی، مشتری، پروژه یا تطبیق درست بوده است؟ ۳. کیفیت استثنا: آیا سیستم در صورت مبهم بودن مورد متوقف شد، یا حدس مطمئنی تولید کرد؟ ۴. تلاش بازبین: چند بار یک شخص نیاز به ویرایش، رد یا بررسی پیشنهاد داشت؟
خطاهای جدی را میانگین نکنید. نرخ دستهبندی ۹۸٪ ممکن است قوی به نظر برسد تا زمانی که ۲٪ باقیمانده شامل هر انتقال وجه نقد محدود یا ورودی مالیات حقوق و دستمزد باشد. تحملهای جداگانهای برای هزینههای عادی، درآمد، بدهیها، مالیات، حقوق و دستمزد و پرداختها تعیین کنید.
پس از یک تغییر بااهمیت دوباره آزمایش کنید: مدل جدید، prompt، یکپارچهسازی، نمودار حسابها، خوراک فروشنده یا چیدمان سند. نتایج قبل و بعد را نگه دارید. کنترل این نیست که «مدل یک بار آزمایش شد»؛ این یک فرآیند مستمر است که به شما میگوید چه زمانی عملکرد تغییر کرده است.
مدیریت مواجهه داده و نگهداری
سوابق مالی بیشتر از مبالغ هستند. فاکتورها میتوانند نام مشتری، آدرس، مشخصات بانکی، قیمتگذاری، برنامههای محصول و اطلاعات کارمندان را آشکار کنند. قبل از ارسال داده به یک سرویس هوش مصنوعی، شناسایی کنید که سرویس چه چیزی دریافت میکند، کجا پردازش میشود، چه مدت نگهداری میشود، آیا برای آموزش مدل استفاده میشود و چه کسی میتواند آن را بازیابی کند.
هر جا گردش کار اجازه دهد از حداقلسازی داده استفاده کنید. یک کار دستهبندی ممکن است به توضیحات فروشنده، مبلغ و سابقه حساب نیاز داشته باشد، اما نه به شماره کامل حساب بانکی مشتری. اطلاعات شخصی نامرتبط را پنهان یا حذف کنید. اعتبارنامههای تولید را از اعتبارنامههای آزمایشی جدا کنید و فقط محدودههایی را که نیاز دارد به یک یکپارچهسازی بدهید.
یک فهرست بهروز از گردش کارهای با کمک هوش مصنوعی با این فیلدها نگه دارید:
- مالک کسبوکار و مالک فنی
- هدف و اقدام مجاز
- کلاسهای داده و سیستمهای دسترسییافته
- نقاط تأیید انسانی
- نسخه مدل یا ارائهدهنده
- رفتار نگهداری و حذف
- محدودیتهای شناختهشده و موارد مستثنی
- آخرین تاریخ آزمایش و تاریخ بازبینی بعدی
- رویه حادثه و بازگشت
فهرست به اندازهای کوچک است که یک کسبوکار کوچک بتواند آن را در یک صفحه گسترده یا فایل متنی نسخهکنترلشده نگه دارد. ارزش آن بوروکراسی نیست؛ از تبدیل آزمایشهای «موقت» به زیرساخت تولید نامرئی جلوگیری میکند.
طراحی برای شکست و اصلاح
فرض کنید یک خوراک منبع ناقص خواهد بود، یک سند خواندنی نخواهد بود، یک مدل تغییر خواهد کرد و یک کاربر پیشنهاد اشتباه را تأیید خواهد کرد. از قبل تصمیم بگیرید چه اتفاقی بعد از آن میافتد.
جایگزین شما باید به این سؤالات پاسخ دهد:
- آیا مورد در صف انتظار باقی میماند یا رد میشود؟
- چه کسی مطلع میشود و با چه سرعتی؟
- آیا میتوان آخرین قاعده یا مدل شناختهشده خوب را بازیابی کرد؟
- آیا میتوان همه ورودیهای متأثر را با نسخه گردش کار یا شناسه دسته شناسایی کرد؟
- چه کسی میتواند ورودیها را بدون از بین بردن تاریخچه اصلی معکوس کند؟
- چه زمانی مشکل به یک حادثه تبدیل میشود که نیاز به اطلاع مدیریت دارد؟
هرگز یک خطای خودکار را با بازنویسی ورودی اصلی و حذف ردپا «اصلاح» نکنید. یک ورودی تصحیحی یا معکوس ثبت کنید، آن را به اصلی پیوند دهید و دلیل را مستند کنید. این به شما ماندههای دقیق فعلی میدهد بدون اینکه نحوه وقوع خطا پاک شود.
گزارشهای استثنا دورهای را اجرا کنید حتی وقتی هیچکس شکایت نکرده است. به دنبال تغییرات ناگهانی در توزیع دستهها، نرخهای ثبت خودکار غیرعادی بالا، تراکنشهای تطبیقنشده، بازنویسیهای مکرر بازبین، اسناد تکراری و ورودیهای ثبتشده خارج از الگوهای عادی کسبوکار باشید. این سیگنالها اغلب انحراف را زودتر از یک تسویهحساب بانکی آشکار میکنند.
برنامه اجرایی ۳۰ روزه
میتوانید بدون انتظار برای یک پروژه سیستم بزرگ، یک پایه معنیدار ایجاد کنید.
هفته ۱: نقشه گردش کارها
هر جایی که هوش مصنوعی اطلاعات مالی را لمس میکند فهرست کنید، از جمله ویژگیهای تعبیهشده در ابزارهای حقوق و دستمزد، صدور صورتحساب، بانکی، هزینه و حسابداری. با افرادی که کار را انجام میدهند مصاحبه کنید؛ استفاده مستندنشده در یک چتبات رایگان همچنان یک ریسک جریان داده است.
هفته ۲: تعیین مرزها
به هر گردش کار یک سطح مجوز، آستانه مبلغ، انواع تراکنش مستثنی، مالک انسانی و جایگزین اختصاص دهید. دسترسی نوشتن یا پرداخت را غیرفعال کنید تا زمانی که مالک و الزامات شواهد صریح باشند.
هفته ۳: ایجاد شواهد و مجموعه آزمایش
تراکنشهای نماینده را جمعآوری کنید، نتایج مورد انتظار را برچسبگذاری کنید و فیلدهایی را که باید حفظ شوند تعریف کنید. گردش کار را در حالت پیشنویس اجرا کنید و تصحیحات، استثناها و زمان بازبین را ثبت کنید.
هفته ۴: اجرای محدود
فقط کمریسکترین مورد استفاده که اهداف دقت و شواهد را برآورده میکند فعال کنید. درصد ثابتی از موارد خودکار را نمونهبرداری کنید، همه استثناها را بازبینی کنید و یک بررسی ۳۰ روزه برنامهریزی کنید. فقط زمانی دامنه را گسترش دهید که دادهها از گسترش حمایت کنند.
حسابداری دقیق سطح کنترل این کل برنامه است. حسابهای بانکی و پرداخت را تسویه کنید، اسناد منبع را پیوست کنید، بدهیها را از درآمد جدا نگه دارید و از نامهای حساب سازگار استفاده کنید قبل از اینکه از هوش مصنوعی بخواهید کار را خودکار کند. ورودیهای تمیز شناسایی خطاها را آسانتر میکنند؛ ورودیهای شلوغ به اتوماسیون فرصتهای بیشتری برای پنهانکردن آنها میدهند.
مدیریت مالی خود را ساده کنید
اتوماسیون هوش مصنوعی زمانی آسانتر قابل کنترل است که سوابق مالی زیرین شفاف، قابل بازبینی و آسان برای تغییر بدون از دست دادن تاریخچه باشد. Beancount.io حسابداری متنی را ارائه میدهد که شفاف، نسخهکنترلشده و آماده هوش مصنوعی است، و پایهای روشنتر برای اتوماسیون کنترلشده به تیم شما میدهد.