Як ми навчили агента читати PDF-рахунки краще бухгалтера

Фінансовий відділ отримував 40–60 PDF-рахунків на день. Від різних постачальників. У різних форматах. Деякі — скановані, деякі — цифрові, деякі — таблиці в PDF без жодної структури.

Бухгалтер відкривав кожен вручну, переносив дані в 1С, звіряв з договором. В середньому — 8 хвилин на документ. За тиждень це 40 робочих годин тільки на введення. Помилки: 3–4 на тиждень, кожна обходилась від 2 годин на розбір і виправлення.

Нам поставили задачу: автоматизувати. Звучить просто. На практиці — ні.

Де ми помилилися спочатку

Перший підхід — взяти готову OCR-бібліотеку і натренувати на прикладах документів клієнта. Проблема з'ясувалась через тиждень: OCR добре читає текст, але не розуміє контекст. "42 000" у документі може бути сумою, номером артикула, датою або просто кодом. Без розуміння структури документа — це просто символи.

Ми перебудували підхід. Замість "читати текст" агент спочатку класифікує тип документа: рахунок-фактура, акт виконаних робіт, видаткова накладна, митна декларація. Кожен тип має свою схему полів і логіку перевірки. Тільки після класифікації агент знає де шукати суму, де ЄДРПОУ, де дату.

Це подвоїло точність одразу — без зміни базової моделі.

Три проблеми, що з'явилися після

Проблема 1: Сканований PDF від ксерокса 2008 року. Частина постачальників досі надсилає фото паперових рахунків. Якість — від прийнятної до "чи це взагалі текст". Ми не намагалися підвищити якість обробки нижче певного порогу. Замість цього ввели метрику впевненості: якщо агент не впевнений у значенні поля — він не заповнює його і відправляє документ на ручну перевірку з поясненням що саме він не зміг прочитати.

Проблема 2: Один постачальник міняє формат щоквартально. Раз на три місяці постачальник оновлював шаблон. Перша версія агента падала — нове розміщення полів, нові підписи колонок. Ми перейшли від жорстких правил ("сума в рядку 7 колонка 3") до семантичного пошуку: агент шукає "де тут написано загальна сума до сплати" — і знаходить незалежно від розміщення.

Проблема 3: 1С версії 8.2 у клієнта. Сучасний REST API Anthropic добре спілкується з 1С 8.3. З 8.2 — потрібен COM-інтерфейс і значно менша гнучкість. Ми витратили тиждень на налаштування прошарку між агентом і застарілою версією. Тепер це стандартна частина нашого чеклісту: першим питанням на аудиті — яка версія 1С і чи є REST API.

Як виглядає система зараз

Документ надходить через email або Google Drive. Агент класифікує, витягує поля, перевіряє ЄДРПОУ через відкритий реєстр і порівнює суму з відповідним замовленням у 1С. Якщо все збігається — вносить і позначає як верифіковано. Якщо є розбіжність — відправляє фінансовому директору з конкретним поясненням: "сума рахунку ₴84,200, в замовленні ₴82,000, різниця ₴2,200 — перевірте умови договору".

91% документів проходять без участі людини. Решта 9% — ті де або впевненість нижче порогу, або є розбіжності. Бухгалтер витрачає 40 хвилин на місяць замість 40 годин.

За 6 місяців роботи агент виявив помилки постачальників на ₴180,000. Деякі — навмисні завищення, деякі — технічні збої в їхніх системах. Бухгалтер цього не бачив — просто через обсяг.

Що ми б зробили інакше

Не починали б зі "стандартного OCR". Почали б відразу з класифікатора типів документів і семантичного пошуку полів. Це заощадило б нам тиждень переробки.

І запитали б про версію 1С на першій зустрічі, а не на третій.

Якщо у вас схожа задача — обробка документів, рахунків, актів або митних декларацій — залиште заявку на аудит. Покажемо де агент дасть результат у вашому конкретному стеку, і де ручна перевірка залишиться потрібною.