Чому вилучення даних з рахунків ламається на потоці
Потік рахунків ламається не на одному документі, а на обсязі та різноманітності. Поки постачальників десяток і форми стабільні, вилучення даних з рахунків виглядає вирішеним завданням: оператор вводить реквізити за пару хвилин, помилки помічаються очима.
На тисячах документів на місяць ручне введення перестає масштабуватися, і черга необроблених документів зростає швидше, ніж її розбирають.
Класичний підхід — правила за координатами, як-от «номер рахунку праворуч угорі, ІПН у блоці реквізитів». Він розвалюється на першому ж скані під кутом, на зсунутій шапці, на новій формі постачальника, де логотип перекриває рядок.
Кожна варіація потребує нового набору правил, а непомічена мовчки дає неправильний результат — без помилки в лозі.
Моделі, які враховують не лише текст, а й положення поля на сторінці, знімають частину цієї крихкості: розпізнавання реквізитів спирається на контекст — що стоїть поруч із шуканим значенням. Кількох десятків розмічених рахунків достатньо, щоб тримати нові форми. Але в моделі є поріг упевненості, нижче якого документ зобов’язаний піти людині, а не в облік.
Ціна помилки — розбіжності в обліку, а не витрачені хвилини. Рахунок, розібраний наполовину, оплачується двічі або не потрапляє до реєстру, і розбіжність спливає на звірці, коли виправляти вже дорожче. Черга необроблених документів при цьому закривається руками в кінці періоду.
Розбираємо, як це закривається: конвеєром, де модель вилучає поля, перевірки звіряють їх між собою, а людина отримує лише документи з низькою впевненістю.
Ефект впровадження: швидкість обробки та частка помилок
Після запуску вилучення даних з рахунків перестало впиратися в ручне введення: документи надходять пакетом, розпізнавання йде паралельно, а оператор підключається лише там, де модель не набрала впевненості за ключовими полями.
Пропускна здатність зросла з десятків до кількох сотень рахунків на добу на співробітника, а час від отримання файлу до запису в обліку скоротився з годин до хвилин. Пікове закриття місяця більше не потребує тимчасового підсилення команди.
Головна метрика тут — частка рахунків, що пройшли без ручного дотику. На постачальниках зі стійкою версткою вона тримається в районі 85-90%, на нових контрагентах перші документи розбираються вручну, поки система не підтягне шаблон.
Документи з низькою впевненістю не «додумуються»: вони йдуть у чергу перевірки з підсвічуванням спірного поля — помилка в сумі дорожча за зайвий клік оператора.
Частка помилок падає не стільки в цифрах, скільки за класом. Зникає введення, пов’язане з людським фактором: перестановка цифр у номері, плутанина дати рахунку й дати постачання, загублений рядок у багатосторінковій таблиці.
Залишаються змістовні розбіжності — рахунок не збігається з договором або актом, — і саме на них вивільняється час бухгалтерії.
Трудовитрати перерозподіляються, а не зникають: оператор перестає бути оператором введення й стає контролером винятків — на перевірку йде один документ з десяти замість кожного.
Такий розрив дає донавчання LayoutLMv3 на архіві рахунків замовника: модель налаштовується на його постачальників і форми, а не на абстрактний набір документів.
Способи розбору форм: шаблони, правила та моделі
Той самий рахунок надходить у трьох видах: рівний електронний документ від великого постачальника, скан під кутом з телефону та бліда копія з бухгалтерії контрагента.
Режим розбору вибирають не за «середньою рекомендацією», а за складом потоку: де форма стабільна, достатньо координатної прив’язки полів, де бланк пливе — потрібна модель, стійка до зсуву, шуму й обрізаних країв.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Шаблонний розбір | Один-два контрагенти, форма бланка не змінюється місяцями, потік однотипний | Правка бланка ламає прив’язку й потребує перезбирання шаблону; на поганих сканах поля залишаються порожніми |
| Правила вилучення | Типові реквізити: ІПН, номер і дата документа, суми з ПДВ, підсумок за рядками | Крихкість на нестандартних формулюваннях і різних регістрах, розповзається при зміні мови бланка |
| Навчена модель | Змішаний потік, десятки постачальників, нестандартні форми, скани з телефону | Потрібна розмітка вибірки під ваш потік і контроль якості при появі нових типів документів |
На практиці потік майже завжди гібридний: правила закривають реквізити-якорі, модель — табличну частину й вільні формулювання, розбіжності йдуть на ручну перевірку.
Критерій вибору — не «який спосіб сильніший», а частка полів, вилучених без правки, на ваших сканах: на рівних електронних документах шаблон і модель ідуть урівень, на поганих сканах перший просідає в рази. Тому замір якості робимо до вибору режиму — на вашій вибірці, а не на демонстраційній.
Етапи впровадження: від аудиту архіву до передачі в роботу
Впровадження починається не з моделі, а з аудиту архіву: поки не видно, з чого складається потік, будь-яке налаштування — це вгадування. Нижче — порядок робіт, де кожен етап спирається на артефакт попереднього.
- Аудит архіву. Вивантажуємо кілька сотень рахунків за період, розмічаємо типи бланків, рахуємо частку сканів без текстового шару, поворотів і рукописних правок. На виході — карта типів документів і чесна оцінка частки, яку вилучення закриє без оператора.
- Схема потоку документів. Описуємо, звідки надходить файл, де зберігається оригінал, куди йде результат і що відбувається з полем, якщо впевненість моделі нижча за поріг. Схему погоджуємо до налаштування.
- Налаштування вилучення. Навчаємо модель розмітки на бланках замовника, виділяємо реквізити: номер, дата, контрагент, суми, податок, позиції. Частину полів закриваємо правилами та звіркою за довідниками — це стабільніше, ніж довіряти все моделі.
- Перевірка на тестовій вибірці. Прогоняємо на рахунках, яких модель не бачила, і рахуємо точність за кожним полем окремо. Слабкі місця — позиції, рукописні реквізити — розбираємо вручну, щоб середня цифра їх не приховала.
- Критерії приймання. Фіксуємо до фінального прогону: точність за полями, частку рахунків на ручну перевірку, час обробки пакета, формат вивантаження. Не збіглося — донавчаємо, а не приймаємо як є.
- Передача в експлуатацію. Розгортаємо в контурі замовника або в закритій хмарі, вмикаємо журналювання й оповіщення про падіння точності, навчаємо операторів, віддаємо документацію. Через місяць звіряємо фактичні метрики з приймальними й донавчаємо на нових бланках.
Що замовник отримує на руки: конфігурації та регламенти
Артефакти передаємо не як додаток до звіту, а як робочий комплект: команда замовника має вміти змінювати параметри, підключати новий тип документа й розбирати збої без нашої допомоги. Тому до передачі входить не лише сервіс, а й конфігурація, схеми та правила, за якими він живе.
- Конфігурація рішення — параметри розмітки полів, пороги впевненості та правила валідації реквізитів; зберігається в репозиторії, зміна налаштування не потребує перезбирання моделі.
- Схема інтеграції — шлях документа від пошти або скана до облікової системи, точки відмови, формати обміну та правила повторного надсилання без дублів.
- Політики доступу — ролі оператора, аналітика й адміністратора, терміни зберігання вихідних даних і результатів розпізнавання, журнал дій.
- Документація — опис полів рахунку й правил зіставлення, інструкція з підключення нового типу документа, розбір типових помилок.
- Тестовий корпус — добірка рахунків з еталонними значеннями та метрикою за кожним полем: після доопрацювання відразу видно, де точність просіла.
- Інструкція оператора — як розбирати чергу сумнівних документів і куди дивитися при розбіжності сум.
- Регламент супроводу — що команда замовника закриває сама, що ескалюється, терміни реакції та порядок відкату на попередню версію конфігурації.
Рішення перестає залежати від однієї людини: зміни вносяться за інструкцією, а якість перевіряється на тому ж корпусі, що й при впровадженні.
Кейс: потік вхідних документів без ручної звірки
Замовник — оптовий постачальник із трьома юридичними особами та потоком близько 4 000 вхідних рахунків і актів на місяць. Бухгалтерія розбирала їх вручну: шість операторів переносили реквізити й суми в облікову систему.
На піку закриття періоду розтягувалося до 11 робочих днів, а розбіжності знаходили вже на звірці з постачальниками.
Кейс впровадження почався з пілота: одна юрособа, два масових типи постачальників, вибірка 600 документів.
Розмітили поля, навчили модель на цих прикладах, додали правила післяобробки — збіжність суми рядків із підсумком, перевірка реквізитів за довідником контрагентів, відмова від автоприймання за будь-якої розбіжності.
За основу взяли LayoutLMv3: він читає текст разом з координатами на сторінці, тому впевнено розбирає «плаваючу» верстку рахунків.
Метрики до та після
Точність розбору ключових полів зросла з 88% до 98%, частка документів, які проходять без участі людини, — з 37% до 91%. Решта 9% не губляться: вони потрапляють у чергу перевірки, де підсвічені спірні поля, і оператор править один-два реквізити замість введення всього документа.
Закриття періоду скоротилося з 11 до 3 робочих днів, потік зріс до 6 500 документів на місяць без розширення штату. Після пілота рішення розкотили на решту юрособ і додали нові типи форм, а модель донавчається на виправленнях операторів — частка автоприймання продовжує зростати.
Що робити, якщо шаблонний розбір рахунків уже розгорнуто?
Шаблонний розбір не потрібно зупиняти, щоб почати працювати з моделями. Гібридна схема запускає вилучення паралельно на тому ж вхідному потоці: модель обробляє скан, правила рахують свій варіант, обидва результати лягають в одну картку з позначкою, який маршрут дав значення. Розбіжності за полями йдуть у чергу перевірки та поповнюють розмітку для донавчання.
Міграція розбору спирається на архів уже проведених рахунків: пари «скан — підсумкові значення» після правок оператора дають навчальну вибірку без ручної розмітки.
Моделі класу LayoutLM і Donut враховують і текст, і геометрію блока, тому зазвичай достатньо кількох тисяч документів на тип, щоб поля шапки й таблична частина читалися не гірше за правила, а на нестандартних бланках постачальників — помітно точніше.
Поступове перемикання йде за типами документів, а не за всім потоком одразу. Спершу на модель переводять постачальників із плаваючою версткою, де шаблон і так потребував постійних правок, а стабільні форми залишаються на правилах.
Рішення ухвалюють за метриками: поки частка ручних виправлень за типом падає — маршрут залишається модельним, якщо зростає — тип повертається до шаблону.
Відкат змін закладено в саму схему: маршрут для кожного типу та постачальника — це конфігурація, а не код, тому повернення до попереднього розбору займає хвилини й не потребує перезбирання.
Версія маршруту зберігається разом з результатом, тож будь-який рахунок можна перерозібрати старим способом і звірити поле в поле.
Технічні сумніви: точність, формати, інтеграції
Технічні сумніви зазвичай зводяться до чотирьох речей: чи впорається модель на різнорідних формах постачальників, що буде з поганими сканами, як додати новий тип документа після запуску й хто відповідає за помилку в обліковій системі.
Розбираємо по порядку — із зазначенням того, як це вирішується на рівні конфігурації, а не обіцянок.
Ключовий принцип один: модель не «бачить» форму, вона вилучає поля за змістом і контекстом документа. Тому контроль якості будується не на довірі до розпізнавання, а на порозі впевненості за кожним полем: що нижче за поріг — іде оператору, що вище — в облікову систему.
У постачальників різні форми рахунків — під кожну потрібен шаблон?
Ні. Вилучення йде за смисловою структурою документа, тому новий постачальник обробляється без окремого шаблону: поля «разом», «номер», «дата», «податок» знаходяться в незвичній верстці.
Якщо за конкретним контрагентом відхилення стають системними, робимо донавчання на його вибірці — зазвичай достатньо кількох десятків підтверджених документів.
Що робити зі сканами низької якості — перекосом, шумом, факсом?
Перед розпізнаванням іде попередня обробка: вирівнювання, корекція нахилу, шумозаглушення, за потреби — розпізнавання тексту на зображенні. Документи, які навіть після цього не проходять поріг, не блокують потік: вони потрапляють у чергу ручного введення. Метрику точності ми рахуємо на вашій вибірці документів, а не на загальних прикладах.
З’явився новий тип документа після запуску — переробляти все?
Ні. Додається розмітка вибірки, донавчання, перевірка на відкладених документах, потім тіньовий прогін паралельно з поточним контуром. Перемикання — лише коли метрики нового типу не гірші за чинні. Відкат на попередню версію моделі залишається доступним.
Як влаштована інтеграція з обліковою системою і хто відповідає за помилку?
Обмін іде через програмний інтерфейс облікової системи або файловий обмін — формат погоджуємо на етапі проєктування. Поля з низькою впевненістю в систему не йдуть: вони залишаються в черзі оператора разом із фрагментом зображення та версією моделі, яка ухвалила рішення. Так помилка не потрапляє в проведення мовчки, а розбирається на вході.
Обговоримо задачу: що потрібно для оцінки потоку
Щоб повернутися з оцінкою робіт, нам не потрібен доступ до вашого контуру на старті — достатньо описати потік рахунків і обмеження інфраструктури. Нижче перелік ввідних, яких зазвичай достатньо, щоб порахувати трудовитрати й зібрати план впровадження за етапами.
- Обсяг і ритм потоку: скільки рахунків надходить на місяць, яка частка — скани без текстового шару, чи є піки в закриття періоду.
- Канали надходження: електронний документообіг, пошта, мережевий сканер, вивантаження з облікової системи — що вже надходить у машиночитному вигляді, а що розбирають руками.
- Формати та якість: PDF з текстовим шаром і без, зображення, XML; як часто трапляються повороти, низький контраст, багатосторінкові додатки з таблицями.
- Реквізити та правила перевірки: які поля обов’язкові, чи є довідники контрагентів і номенклатури, як зараз звіряють суми, ПДВ і підсумки за рядками.
- Точка приземлення результату: куди писати вилучені дані й чи потрібен крок ручного підтвердження перед проведенням.
- Інфраструктура та доступи: чи можна розмістити обробку у вашому контурі або на виділеному майданчику, які вимоги до зберігання вихідних даних, журналювання та розмежування прав.
- Власники процесу: хто з боку бухгалтерії, ІТ і служби безпеки погоджує правила розбору та приймає результат.
Опишіть задачу у вільній формі, додайте 10–20 знеособлених рахунків різних типів — цього достатньо, щоб ми повернулися з оцінкою строків, схемою обробки та планом робіт із точками приймання на кожному етапі.
