Розпізнавання рахунків і накладних за допомогою ШІ: як перевіряти результат

Менеджер відкриває PDF-рахунок від постачальника і передруковує в CRM номер, дату, реквізити та двадцять рядків позицій. Завтра прийде ще десяток таких файлів, фото накладної та прайс в Excel. Розпізнавання рахунків і накладних за допомогою ШІ знімає більшу частину цієї роботи за однієї умови: результат моделі перевіряють до запису у вашу систему. Нижче — що модель читає впевнено, де помиляється, як побудований процес із перевірками та що провайдери роблять із даними, надісланими через API (програмний інтерфейс: ваша система звертається до моделі напряму, без вікна чату).

Які рахунки та накладні ШІ читає впевнено

Розпізнавання документів за допомогою ШІ працює на моделях, які розуміють зображення (мультимодальних). Вони читають ті самі файли, що надходять протягом звичайного робочого дня:

• PDF із текстовим шаром. Рахунки на оплату з облікових програм та інтернет-банків. Текст уже є, витягування даних із PDF зводиться до пошуку потрібних полів.
• Скани та PDF без текстового шару. Сторінку модель читає як картинку, тому якість скану вирішує майже все. (Claude, наприклад, кожну сторінку будь-якого PDF перетворює на зображення і, якщо текст у файлі є, передає його поруч.)
• Фото з телефона. Накладна на капоті машини, акт із печаткою. Читаються гірше: тінь, нахил і відблиски псують результат сильніше, ніж здається людині.
• Excel і CSV різної структури. В одного постачальника прайс починається з шапки на п’ять рядків, у другого артикул захований у назві товару, у третього на кожному аркуші своя категорія.
• Листи з вкладеннями, де частина реквізитів у тексті листа, частина у файлі.

Якщо контрагенти надсилають документи через сервіс електронного документообігу, спочатку з’ясуйте, чи віддає сервіс дані в структурованому вигляді (через API або вивантаження). Якщо віддає, розпізнавати такі документи не потрібно, модель залишається для решти: PDF із пошти, сканів, фото та прайсів.

Класичний OCR за шаблонами (програма, яка перетворює картинку на текст за заздалегідь розміченими полями) вимагає розмітки під кожного постачальника: він бачить «15.10.2026» і без правила не знає, дата це рахунку чи термін оплати. Модель зазвичай розуміє різницю за змістом і сусідніми підписами, тому новий постачальник із незвичним макетом не потребує окремого налаштування. Його перші документи все ж варто перевірити вручну.

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

Слабкі місця відомі. Найгірше модель читає довгі таблиці позицій на кілька сторінок, рукописні позначки, зім’яті та вицвілі копії. Окрема проблема — зшиті файли: якщо в одному PDF лежать договір, рахунок і акт, модель може взяти суму із сусіднього документа. Такі файли спочатку ділять на частини і лише потім витягують дані.

Чому результат потрібно перевіряти

Модель помиляється інакше, ніж людина. Втомлений працівник пропускає рядок, і пропуск видно. Модель заповнює всі поля акуратно й одноманітно, включно з тими, де помилилася: порожню комірку таблиці може заповнити правдоподібним значенням із сусіднього рядка, артикул зі схожими цифрами «виправити» на той, що траплявся частіше. Таку відповідь називають галюцинацією: впевнену за формою і хибну за суттю.

Простий розрахунок. Модель правильно витягує 97% полів, у рахунку 15 полів. Імовірність, що всі 15 правильні, — 0,97 у п’ятнадцятому степені, близько 63%. Приблизно кожен третій документ містить щонайменше одну помилку.

Провайдери дають режим структурованої відповіді: модель повертає дані чітко за заданою схемою (номер, дата, код ЄДРПОУ постачальника, список позицій), і ваш код не ламається на несподіваному форматі. Схема гарантує лише форму. Документація Google до Gemini API каже прямо: відповідь буде синтаксично правильним JSON (стандартний формат даних для обміну між програмами), а значення потрібно перевіряти в застосунку. OpenAI та Anthropic обіцяють те саме: відповідність схемі, обов’язкові поля та типи даних. Про правильність самих значень у документації всіх трьох провайдерів нічого не сказано.

Процес розпізнавання з перевірками

Модель читає документ, код перевіряє і рахує, людина підтверджує спірне. За кроками:

1. Приймання. Документи надходять на виділену поштову скриньку, через форму в особистому кабінеті або в Telegram-бот, куди працівник надсилає фото накладної зі складу.
2. Підготовка. Код ділить зшиті PDF на окремі документи. Модель визначає тип кожного (рахунок, накладна, акт, договір), під тип обирається схема полів. Із файлів із текстовим шаром код бере готовий текст, сторінки без тексту (скани, фото) надсилає моделі як зображення.
3. Витягування. Модель повертає поля за схемою: реквізити сторін, номер і дату, позиції з кількістю, ціною та сумою, підсумки.
4. Перевірка кодом за правилами з наступного розділу.
5. Підтвердження. Документи без зауважень ідуть далі автоматично (коли ви до цього готові), документи із зауваженнями — працівнику на екран звірки.
6. Запис. Дані йдуть у CRM, інтернет-магазин, Google-таблицю, облікову систему або вашу власну базу. Оригінальний файл, витягнуті значення та правки працівника зберігаються в журналі: за ним видно, де модель помиляється найчастіше.

Що перевіряє код

Більшість помилок моделі ловлять ті самі перевірки, які досвідчений бухгалтер або комірник робить подумки. Набір залежить від ваших документів, базовий список майже завжди один:

• Арифметика. Кількість × ціна = сума рядка. Сума рядків = підсумок. Підсумок без ПДВ + ПДВ = підсумок із ПДВ. Якщо хоча б одна рівність не сходиться з точністю до копійки, документ іде на перевірку: неправильно прочитана цифра майже завжди ламає одну з рівностей. Суми рахує код, модель лише читає цифри.
• Реквізити. У коду ЄДРПОУ є контрольний розряд, тому більшість одруків видно простим розрахунком, без звернення до реєстру. Український IBAN складається з 29 символів і містить дві контрольні цифри, тож більшість одруків у номері рахунку теж видно розрахунком. У податкових номерів інших країн правила свої, їх додають під ваших контрагентів.
• Довідники. Контрагент із таким кодом є в базі? Артикул є в каталозі? Одиниця вимірювання збігається з карткою товару? Невідомий постачальник або товар — привід показати документ людині.
• Звірка із замовленням. Позиції та ціни в рахунку мають збігатися із замовленням постачальнику, кількість у накладній — з прийнятим на склад. Розбіжність зупиняє оплату або оприбуткування до рішення працівника.
• Дублі. Документ із тим самим номером, датою та контрагентом уже завантажували: постачальник переслав рахунок повторно або двоє працівників завантажили один файл. Без цієї перевірки оплата або оприбуткування проходять двічі.
• Правдоподібність. Дата документа не в майбутньому і не дворічної давнини. Ціна відрізняється від минулої закупівлі не більше ніж на заданий вами відсоток. Кількість не на порядок більша за звичайну.

Що залишається людині

Екран звірки влаштований просто: ліворуч документ, праворуч витягнуті поля, спірні підсвічені з поясненням («сума рядків не збігається з підсумком на 120,00»). Працівник виправляє одне поле і підтверджує документ, а не передруковує його повністю.

Ми радимо починати з ручного підтвердження кожного документа. За кілька тижнів журнал покаже, які поля модель читає без помилок, а які працівник постійно виправляє. Тоді автоматичне приймання вмикають за типами документів і полів: наприклад, рахунки постійних постачальників у PDF із текстовим шаром проходять самі, фото накладних, як і раніше, дивиться людина. Частину автоматично прийнятих документів і після цього перевіряють вибірково — лише так видно реальну точність. «Упевненість», про яку повідомляє сама модель, для цього не підходить.

Прайси постачальників: ціни та залишки в магазині

Частий окремий випадок — оновлення цін із прайса постачальника. Магазин працює з десятком постачальників, і кожен надсилає файл по-своєму: в одного залишки числом, у другого «є / немає / під замовлення», у третього «>10». Один пише артикул виробника, другий — свій внутрішній код, третій лише назву на кшталт «Змішувач д/кухні хром Ф40 гусак».

Модель закриває два завдання, які раніше вимагали ручного налаштування під кожен файл:

• знаходить, у якій колонці артикул, ціна, валюта та залишок, навіть якщо постачальник змінив шаблон;
• зіставляє «брудні» назви та чужі артикули з картками вашого каталогу і пропонує відповідність із поясненням, чому обрано саме цей товар.

Далі працює код: застосовує вашу націнку за категоріями та правила округлення, перераховує валюту за вашим курсом, перевіряє мінімальну маржу. Зміна ціни понад заданий поріг, новий товар без картки в каталозі або сумнівне зіставлення потрапляють у чергу на підтвердження. Підтверджене зіставлення зберігається, і наступного разу той самий артикул прив’язується без моделі та без запитань.

В інтернет-магазині на WooCommerce або іншій платформі ціни та залишки оновлюються за розкладом. Контент-менеджер розбирає лише винятки.

Готовий сервіс чи розробка

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

Розробка виправдана в чотирьох ситуаціях:

• Свої документи. Специфікації до замовлень, акти замірів, заявки дилерів, сертифікати, прайси — усе, для чого в готового сервісу немає схеми полів.
• Свої правила. Мінімальна маржа, ліміти за контрагентами, звірка із замовленням у вашій CRM, особливі одиниці вимірювання.
• Дані йдуть не в бухгалтерію, а в CRM, інтернет-магазин, складську таблицю, корпоративний портал або самописну систему без готового конектора.
• Дані не можна випускати назовні: договори, персональні дані, комерційні умови. Тоді потрібен контроль над маршрутом кожного файлу, аж до моделі на своєму сервері.

Якщо документів десяток на тиждень і вони однотипні, автоматизація не окупиться. Проєкт окупається там, де ручне введення забирає помітну частину чийогось робочого дня або де помилки введення вже коштували грошей. До витрат, крім розробки, входять оплата API за кожну сторінку (або сервер для своєї моделі) та підтримка правил перевірки після запуску. Економія є лише тоді, коли зекономлений час працівників коштує більше за ці витрати.

Куди йдуть дані: API чи свій сервер

Чи використовує провайдер ваші рахунки для навчання, залежить від способу підключення. Нижче — що написано в офіційних політиках трьох провайдерів (перевірено 21.10.2026; умови змінюються, перед запуском перечитайте їх).

• OpenAI API. Дані, надіслані через API, з 1 березня 2023 року не використовуються для навчання моделей, якщо ви самі не дали згоду. Журнали для контролю зловживань зберігаються до 30 днів. Режим без зберігання даних (Zero Data Retention) та обробка в європейському регіоні доступні після схвалення OpenAI. Джерело — сторінка Your data у документації OpenAI.
• Anthropic API. Вхідні та вихідні дані комерційних продуктів, до яких належить API, за замовчуванням не використовуються для навчання; виняток — коли ви самі надіслали відгук або дали згоду. На серверах дані видаляються протягом 30 днів, якщо не укладено іншої угоди (наприклад, про нульове зберігання). Запити, які автоматична система позначила як такі, що порушують правила використання, зберігаються до 2 років. Джерела — статті Privacy Center про терміни зберігання та про навчання моделей.
• Google Gemini API. Умови залежать від рівня: безкоштовного чи платного. На безкоштовному Google використовує запити та відповіді для покращення своїх продуктів, їх можуть переглядати живі рецензенти, і умови прямо просять не надсилати конфіденційні та персональні дані. На платному запити для навчання не використовуються і зберігаються обмежений час лише для виявлення порушень. Для Європейської економічної зони (країни ЄС плюс Ісландія, Ліхтенштейн і Норвегія), Швейцарії та Великої Британії умови платного рівня поширюються і на безкоштовну квоту. України, Казахстану та інших країн СНД у цьому списку немає: їхня безкоштовна квота працює на умовах безкоштовного рівня. Джерело — Gemini API Additional Terms of Service.

Для більшості рахунків і накладних платного API з такими умовами достатньо. Окремий ризик — працівник, який вставляє договір в особистий безкоштовний чат-бот, бо так швидше. Робочий інструмент зменшує спокусу, але заборона і пояснення все одно потрібні.

Якщо документи надходять через Telegram, враховуйте будову месенджера. Листування з ботом — звичайний хмарний чат: шифрування працює між клієнтом і сервером, наскрізного шифрування немає. Для договорів і сканів паспортів надійніша форма завантаження на вашому сервері (її можна відкрити всередині Telegram як мінізастосунок). Ще одне обмеження: через стандартний Bot API бот може отримати файл розміром до 20 МБ. Багатосторінкові скани бувають більшими, і тоді потрібен власний сервер Bot API, де такого ліміту немає.

Нейромережа на своєму сервері

Нейромережа на своєму сервері — це відкрита модель, розгорнута на власному або орендованому сервері з відеокартою (GPU). Варіант для випадків, коли документи зовсім не мають залишати вашу інфраструктуру: файли обробляються всередині, зовнішній провайдер їх не бачить.

Головний плюс — повний контроль над даними. Другий — економія, але лише за великого потоку: ви платите за сервер, а не за кожну сторінку, і за малого обсягу сервер обходиться дорожче за API. Мінусів більше. Потрібен сервер із GPU і людина, яка його адмініструє та оновлює. Відкриті моделі, які можна розгорнути на такому сервері, зазвичай поступаються великим хмарним на складних документах: довгих таблицях, поганих фото, змішаних мовах. Перевірки кодом та екран звірки потрібні так само: локальна модель помиляється не рідше за хмарну.

Є проміжний варіант: документи без чутливих даних (прайси, рахунки постійних постачальників) ідуть через платний API, а договори та все з персональними даними обробляє модель на вашому сервері. Маршрут задає правило за типом документа та контрагентом.

З чого почати пілот

1. Виберіть один потік документів, де ручне введення забирає найбільше часу: вхідні рахунки, накладні складу або прайси.
2. Зберіть реальні документи за кілька місяців, включно з поганими сканами, фото та найнезручнішими макетами. П’ять «красивих» PDF нічого не скажуть про роботу на звичайному потоці.
3. Підготуйте еталон: правильні значення полів, внесені людиною. На цій вибірці модель не налаштовують, на ній лише перевіряють.
4. Рахуйте точність за цілими документами: документ правильний, лише якщо правильні всі його поля. Окремо дивіться критичні поля — суми, реквізити, кількість.
5. Запишіть правила перевірки, які працівники зараз тримають у голові. Вони стануть основою коду.
6. Вирішіть, куди і в якому вигляді потрапляють дані: чернеткою на підтвердження чи одразу робочим записом.

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

Як із цим допомагає RIVERIT

Пропонуємо розробку ШІ-автоматизації бізнесу під ваші документи: витягування даних із рахунків, накладних, прайсів та інших файлів із перевірками за вашими правилами. Підключаємо моделі OpenAI, Anthropic і Google через API або розгортаємо відкриту модель на вашому сервері, якщо дані не мають виходити назовні. Рішення пишемо кодом та інтегруємо з CRM, інтернет-магазином, таблицями або власною базою. Приймання документів можна організувати через Telegram-бот із панеллю керування. Докладніше — на сторінці ШІ-автоматизації бізнесу.