Розпізнавання рахунків легко сприйняти за автоматизацію розрахунків із постачальниками. Але розпізнаний рахунок доводить лише одне: поля з документа витягнуто. Він не доводить, що вибрано правильного постачальника, що рахунок відповідає погодженій закупівлі і що його дозволено проводити.
Тому до вибору інструмента для розпізнавання варто описати весь шлях рахунку: від вхідного листа до запису в обліковій системі. Нижче розберемо, на які стани його розділити, які рішення можна віддати правилам, де допомагає AI і які випадки має вирішувати людина. Той самий підхід працює і для звірки банківської виписки.
Одне застереження. Правила зіставлення, допустимі розбіжності й порядок погодження встановлює ваша фінансова служба. Тут ідеться про побудову процесу, а не про облікову політику.
П’ять станів рахунку
Розділіть шлях рахунку на стани, які неможливо сплутати між собою:
- Розпізнаний. Поля витягнуто, кожне має посилання на початковий файл. Більше цей стан нічого не означає.
- Зіставлений. Рахунок пов’язано з постачальником, замовленням і, якщо цього вимагають ваші правила, з фактичним прийманням. Підставу зв’язку збережено.
- Виняток. Знайдено розбіжність або бракує даних. Рахунок чекає на розбір.
- Затверджений. Людина або правило, що мають такі повноваження, дозволили провести рахунок.
- Проведений. Облікова система підтвердила запис, і його номер збережено поруч із рахунком.
Оплати в цьому списку навмисно немає. Для неї потрібні окремий процес і окремі права: рахунок, затверджений до проведення, ще не означає дозволу платити.
Для кожного переходу запишіть дві речі: яка потрібна підстава і хто має право перевести рахунок далі — правило чи конкретна роль. Наприклад: «з „зіставлений“ у „затверджений“ переводить правило, якщо сума й кількість збігаються із замовленням; в інших випадках вирішує керівник, який відповідає за цей бюджет». Доки такого запису немає, автоматизувати перехід зарано: незрозуміло, що саме автоматизується.
Рахунок із замовленням і рахунок без замовлення
Якщо рахунок має замовлення на закупівлю, перевірте, якого зіставлення вимагають ваші правила. Іноді достатньо порівняти рахунок із замовленням. Іноді треба звірити ще й кількість із документом приймання — таке зіставлення називають тристороннім.
Умовний приклад. Замовили 100 коробок, на склад прийняли 60, а рахунок прийшов на всі 100. Порівняння лише із замовленням покаже повний збіг. Порівняння з прийманням покаже розбіжність, яку має розібрати людина.
Рахунок без замовлення — за оренду, разову послугу, підписку — немає з чим зіставити. Для нього потрібен явний маршрут погодження. Найгірше — прив’язати такий рахунок до першого схожого замовлення лише для того, щоб перевірка пройшла.
Правила, AI і людина: хто що вирішує
Однозначне закривають правила
Якщо рівно один кандидат підходить за всіма ознаками — постачальник, номер замовлення, сума в погоджених межах, валюта, період, — збіг підтверджує правило. Його рішення можна пояснити й повторити. Саме такі випадки й варто закривати без участі людей.
AI пропонує кандидатів
AI корисний там, де дані записано недбало: номер рахунку стоїть у коментарі, назву постачальника скорочено, у призначенні платежу написано «оплата за рах. 15 за вересень», один платіж закриває кілька рахунків. Модель може розібрати такий текст і запропонувати кандидатів, пояснивши, чому вибрала саме їх.
Пропозиція — ще не рішення. Оцінка впевненості моделі — корисний сигнал, але не дозвіл пропустити перевірку.
Спірне вирішує людина
Якщо підходять кілька кандидатів, суми розходяться або підстави немає, випадок лишається відкритим, доки його не розбере відповідальний співробітник за погодженим правилом. Якщо просто взяти першого кандидата, що підходить, звіт стане охайнішим, а звірка — менш надійною.
Збіг сум — підказка, а не доказ. Два платежі одному постачальнику на ту саму суму в одному місяці, банківська комісія, сторно, часткова оплата — будь-що з цього змінює рішення. Поруч із кожним запропонованим збігом зберігайте початкові записи й причину, з якої його запропоновано.
Чому звірка виписки підходить для першого проєкту
Для першого проєкту з AI у фінансах потрібна вузька задача, у якій кожне рішення можна перевірити. Зіставлення рядків банківської виписки з проведеними операціями підходить: кожен рядок має зрозумілий підсумок — збіг знайдено, не знайдено або потрібен розбір.
Спершу визначте межі: який банківський рахунок, яка юридична особа, яка валюта, який період і які правила зіставлення ухвалила фінансова команда. Без цього не вийде відрізнити помилку системи від розбіжностей у поглядах усередині самої команди.
Винятки — це теж процес
Кожна розбіжність повинна мати причину, відповідального й наступну дію. Причину зручніше вибирати з короткого погодженого списку: «немає приймання», «сума не збігається із замовленням», «можливий дублікат», «немає погодження». Тоді видно, які причини повторюються.
Причина, що повторюється, — привід щось змінити. Якщо постачальник завжди пише номер замовлення в коментарі, можна доповнити правило або домовитися з постачальником. А якщо черга винятків лише зростає, це та сама ручна робота, просто перенесена на інший екран.
Пілот без запису в облікову систему
Перший пілот має лише пропонувати: збіги, переходи між станами, чернетки записів. В облікову систему він нічого не пише. Команда працює як зазвичай, а пропозиції порівнюють із її перевіреними рішеннями.
Рахуйте три речі:
- помилково прийняті збіги — кожен розбирайте окремо;
- випадки, передані на розбір людині;
- час, витрачений на їхній розбір.
Зазначайте, які документи ввійшли до вибірки і за який період. Висока частка закритих випадків сама собою нічого не каже: за нею можуть ховатися хибні збіги. Нерозв’язаний випадок видно одразу, а помилково прийнятий виглядає закритим, тому він коштує дорожче.
Перш ніж розширювати охоплення, проженіть складні випадки: часткове приймання, той самий рахунок, що надійшов двічі (листом і сканом), відсутність погодження, два правдоподібні кандидати. Окремо перевірте обрив з’єднання після того, як облікова система вже зберегла документ: повторне створення без перевірки дасть дублікат. Як безпечно повторювати запис, ми розбирали в статті про заявки, які не доходять до CRM, — механіка тут та сама. Якщо ви вибираєте готове рішення, попросіть постачальника показати, як воно відновлюється після кожної з цих ситуацій.
Чек-лист перед запуском
- Описано шлях рахунку від отримання до запису в обліковій системі.
- Стани «розпізнаний», «зіставлений», «виняток», «затверджений», «проведений» розділено, оплату винесено в окремий процес.
- Для кожного переходу відомі підстава і той, хто має право його виконати.
- Фінансова служба затвердила правила зіставлення й допустимі розбіжності.
- Для рахунків без замовлення є власний маршрут погодження.
- Правила закривають лише випадки з єдиним кандидатом, що підходить.
- Пропозиції AI зберігаються разом із початковими записами й причиною.
- Випадок із кількома кандидатами лишається відкритим до рішення людини.
- Кожен виняток має причину зі списку, відповідального й наступний крок.
- Пілот не пише в облікову систему.
- Помилково прийняті збіги рахують і розбирають окремо, вибірку й період зазначено.
- Перевірено часткове приймання, дублікат рахунку, відсутність погодження й обрив з’єднання після збереження.
З чого почати
Виберіть один потік: наприклад, рахунки із замовленнями від однієї групи постачальників або виписку за одним банківським рахунком за місяць. Зберіть минулі випадки, які команда вже розібрала, і обов’язково додайте складні. Запустіть пілот у режимі пропозицій і разом із фінансовою службою розберіть кожен помилково прийнятий збіг. Лише після цього вирішуйте, які переходи автоматизувати. Як оцінити, чи окупиться такий проєкт, ми описали в статті про ROI AI-автоматизації.
Якщо хочете розібрати один такий процес, опишіть його нам у Telegram (@infracortex_studio) або через сторінку автоматизації процесів: для першої розмови вистачить опису кроків, без внутрішніх документів і персональних даних.