Ручна робота закінчується не після OCR, а після керованої передачі правильних даних у правильну систему
Розпізнати номер і суму рахунку — лише одна операція. Повноцінний процес має отримати документ із різних каналів, визначити його тип, перевірити обов’язкові поля, знайти дубль, звірити дані із замовленням і довідниками, передати винятки людині, а підтверджений результат — в ERP.
Де насправді ховається ручна робота
На схемі процес часто виглядає просто: «отримали документ — внесли в систему». У реальності між цими двома точками бухгалтер відкриває лист або сервіс електронного документообігу, завантажує файл, визначає юридичну особу, шукає постачальника, перевіряє реквізити, зіставляє документ із замовленням, уточнює розбіжності, створює запис в ERP і повертається до файла, якщо інтеграція завершилася помилкою.
Багато каналів
Email, Вчасно, M.E.Doc, EDIN, папки, скани та вкладення без єдиного реєстру.
Правила в голові
Обов’язкові поля, договори, замовлення та допуски перевіряються вручну.
Повторне перенесення
Ті самі дані копіюються між документом, Excel, ERP і системою погодження.
Невидимі зависання
Команда не бачить, де документ зупинився і хто має зробити наступну дію.
Автоматизувати потрібно не введення реквізитів, а весь життєвий цикл документа. Інакше ручна робота просто переміщується з одного екрана на інший.
Який вигляд має наскрізний потік
У production-процесі документ рухається через послідовні контрольні точки. Кожен етап має вхід, результат, причину відмови та відповідального за виняток.
- 01ОтриматиEmail, ЕДО, API, папка
- 02ЗареєструватиID, джерело, час, статус
- 03РозділитиДокументи й сторінки
- 04РозпізнатиТип і реквізити
- 05ПеревіритиПравила, дубль, довідники
- 06ПогодитиЛише якщо це потрібно
- 07ПередатиSAP, BAS/1C, Business Central
- 08ПідтвердитиERP ID, статус, аудит
Починайте з єдиного вхідного контуру
Якщо документи залишаються в окремих поштових скриньках і кабінетах, наступні етапи неможливо контролювати. Intake-рівень має забрати файл, зберегти джерело, зафіксувати час отримання, створити унікальний ідентифікатор та передати документ далі без втрати вкладень.
| Що фіксуємо | Навіщо | Що перевіряємо |
|---|---|---|
| Джерело та відправник | Маршрутизація і аудит | Дозволений канал, контрагент, юридична особа |
| Оригінальний файл | Незмінність і повторна обробка | Формат, розмір, шифрування, пошкодження |
| Час та ідентифікатор | SLA і відстеження | Чи не був файл зареєстрований раніше |
| Склад пакета | Коректне розділення | Кількість документів, сторінок і вкладень |
Класифікація й розпізнавання — окремі задачі
Спочатку система має зрозуміти, з яким документом працює: рахунком, актом, видатковою накладною, ТТН або коригуванням. Лише після цього застосовуються відповідний набір полів і бізнес-правил. Якщо в одному PDF кілька документів, їх потрібно розділити до вилучення даних.
Модель визначає
- межі окремих документів;
- тип кожної сторінки та документа;
- номер, дату, суму, ПДВ і контрагента;
- табличні позиції, кількість і ціну;
- рівень впевненості для кожного поля.
Процес визначає
- які поля є обов’язковими;
- коли потрібна ручна перевірка;
- який довідник використати;
- куди маршрутизувати документ;
- коли результат можна передати в ERP.
Впевненість моделі не дорівнює правильності бізнес-операції. Сума може бути прочитана точно, але не відповідати замовленню або умовам договору.
Які перевірки мають відбутися до ERP
Після розпізнавання дані проходять детерміновані бізнес-перевірки. Їх результати зрозумілі користувачу: «постачальника не знайдено», «сума відрізняється від замовлення», «цей документ уже оброблявся».
Повнота
Наявні обов’язкові сторінки, реквізити, підпис або КЕП.
Довідники
Контрагент, договір, центр витрат, номенклатура та податкові коди знайдені.
Дублі
Збіг перевірено за файлом і бізнес-ознаками: номером, датою, сумою та постачальником.
Математика
Підсумки рядків, ПДВ, знижки й загальна сума узгоджуються.
Відповідність
Документ звірено із замовленням, прийманням, договором або погодженим тарифом.
Період і статус
Дата відкрита для проведення, документ не анульований і готовий до обліку.
Людина не перевіряє все — лише винятки
Якісний інтерфейс перевірки не змушує бухгалтера заново читати весь документ. Він показує конкретне поле, координату на сторінці, знайдене значення, причину зупинки та доступні дії. Після виправлення дані повертаються в той самий процес, а не передаються вручну далі.
Висока впевненість, усі правила пройдено, довідники знайдено.
Нечітке поле, новий контрагент, розбіжність, дубль або відсутній зв’язаний об’єкт.
Відхилення від договору, перевищення допуску або потреба в погодженні.
Порогові значення не повинні бути однаковими для всіх полів. Помилка в коментарі й помилка в сумі або IBAN мають різний ризик.
Передача в ERP — це транзакція, а не «експорт файла»
Процес не завершився, поки цільова система не підтвердила створення документа. Інтеграційний рівень має перетворити дані у формат ERP, виконати запис, отримати відповідь, зберегти ідентифікатор і безпечно повторити операцію після технічної помилки без створення дубля.
- Мапінг полів і довідників має бути версіонованим.
- Технічна помилка відділяється від бізнес-помилки.
- Повторний запуск не створює другий обліковий документ.
- ERP ID і результат проведення повертаються у спільний реєстр.
- Документ можна знайти за номером, джерелом, статусом і причиною винятку.
«Фора»: від Вчасно через Document AI до SAP
Для рітейл-компанії «Фора» Іннора побудувала процес, у якому первинні документи надходять із сервісу Вчасно, обробляються RaccoonDoc і передаються в SAP. Цінність такого рішення — не в окремому OCR, а в контрольованому ланцюжку між джерелом і обліковою системою.
До інтеграції потрібно погодити типи документів, поля, статуси та правила винятків.
Команда має бачити причину зупинки й виправляти конкретну проблему, а не повторювати весь процес.
Успіх — це підтверджений запис у SAP, а не файл, який система спробувала відправити.
Що вимірювати після запуску
Одна точність розпізнавання не показує цінність процесу. CFO і Head of Accounting потрібні операційні метрики, які пояснюють швидкість, навантаження, якість та надійність.
| Метрика | Що показує | Як використовувати |
|---|---|---|
| Touchless rate | Частка документів без участі людини | Оцінювати реальне зменшення ручних операцій |
| Field accuracy | Якість критичних полів | Контролювати окремо суму, дату, номер, контрагента й IBAN |
| Exception rate | Частка та причини винятків | Усувати повторювані проблеми в даних і правилах |
| Cycle time | Час від отримання до ERP | Виявляти затримки в погодженні та інтеграції |
| ERP success rate | Частка підтверджених записів | Відділяти розпізнавання від фактичного завершення процесу |
| Cost per document | Повна вартість обробки | Порівнювати до/після й планувати масштабування |
Як почати без великого проєкту
Для пілота достатньо одного типу документа, одного каналу й одного сценарію передачі в ERP. Важливо взяти репрезентативну вибірку: різних постачальників, якісні й проблемні скани, багатосторінкові файли та реальні винятки.
Оберіть вузький потік
Наприклад, акти або видаткові накладні однієї юридичної особи.
Зафіксуйте baseline
Обсяг, час, помилки, черги, канали й вартість поточної обробки.
Опишіть правила
Обов’язкові поля, довідники, дублікати, допуски й маршрути погодження.
Запустіть shadow mode
Порівняйте результат системи з рішеннями команди без ризику для обліку.
Підключіть ERP
Передавайте лише підтверджені дані й контролюйте відповідь цільової системи.
Погодьте масштабування
Розширюйте типи документів після досягнення визначених метрик.
Мета — не «розпізнати документ», а завершити операцію
Ручна робота справді закінчується тоді, коли стандартний документ проходить процес без участі бухгалтера, виняток потрапляє до правильної людини з чіткою причиною, а ERP підтверджує створення коректного запису.
Саме така архітектура перетворює Document AI з демонстрації технології на керований бізнес-процес.
Часті питання
Чи можна повністю прибрати участь бухгалтера?
У стабільних типах документів більшість операцій можна виконувати без ручного введення. Але людина залишається власником правил і працює з винятками: низькою впевненістю розпізнавання, розбіжностями із замовленням, дублями, відсутніми довідниками або нетиповими документами.
З яких каналів можна забирати первинні документи?
З електронної пошти, Вчасно, M.E.Doc, EDIN, SFTP, SharePoint, Google Drive, файлових папок, вебформи або API. Важливо не саме джерело, а єдина реєстрація документа, статусу й історії обробки.
Що робити з документами поганої якості?
Система має визначати якість до вилучення даних. Нечитабельні сторінки, неправильну орієнтацію, відсутні сторінки чи слабку впевненість потрібно спрямовувати у контрольовану чергу винятків, а не передавати в ERP із неперевіреними значеннями.
Як запобігти повторному проведенню одного документа?
Перевірка дублів виконується до створення запису в ERP. Доцільно комбінувати технічний відбиток файла з бізнес-ознаками: номером, датою, сумою, постачальником і типом документа. Рішення системи та дія користувача мають залишатися в аудит-трейлі.
Чи потрібен окремий шаблон для кожного постачальника?
Не обов’язково. Сучасний Document AI може працювати з різними макетами одного типу документа. Окремі правила потрібні там, де відрізняється бізнес-логіка, набір обов’язкових полів або спосіб звірки, а не лише розташування реквізитів.
Скільки часу займає пілот?
Пілот для одного типу документа й одного сценарію передачі в облікову систему зазвичай планують на 6–10 тижнів. Точний строк залежить від якості вибірки, доступності інтеграцій, кількості бізнес-перевірок і готовності довідників.
Як зрозуміти, що процес готовий до промислової експлуатації?
Потрібно погодити пороги якості, частку автоматичного проходження, максимальний час обробки, правила повторного запуску, моніторинг інтеграцій та відповідальних за винятки. Однієї високої точності розпізнавання недостатньо.
Ігор Світельський
CEO, ІННОРА. Допомагає компаніям автоматизувати керовані бізнес-процеси за допомогою RPA, Document AI та AI-агентів.
