Рахунки з фото в BAS: AI-розпізнавання без зайвих витрат

До мене звернувся клієнт-бухгалтер із типовим запитом: "Хочу, щоб я кидав фото рахунку, а в BAS з’являвся готовий документ". Перша ж оцінка рішення його злякала: занадто дорого. Це розбір того, де закладаються зайві гроші, які помилки я бачив у типових підходах (включно з AI-порадами, які легко скопіювати без перевірки) і як зробити те саме дешевше, без хайпу.

Що саме можна автоматизувати в рахунках і накладних?

Ланцюжок простий на словах:

Фото або PDF рахунку/накладної.
AI читає документ: ЄДРПОУ, номер, дата, позиції, кількість, ціни, ПДВ.
За ЄДРПОУ шукаємо контрагента в BAS. Якщо його немає, сервіс типу Пактум підтягує реквізити з відкритих державних реєстрів.
Кожну позицію зіставляємо з довідником «Номенклатура»: є схожа, беремо її; немає, створюємо нову.
У BAS створюється документ у статусі «Не проведено». Бухгалтер перевіряє і проводить.

Складність не в розпізнаванні тексту. Сучасні мультимодальні моделі читають навіть зім’яті фото. Складність у пункті 4 і в тому, скільки довіри ми віддаємо автоматиці.

Що означає "як у Монобанку" для рахунків?

Monobank не питає вас про кожну транзакцію. Якщо впевненість висока, категорія ставиться сама. Якщо сумнів, є запитання. Для номенклатури це три зони:

Score зіставлення	Дія
понад 90%	автоматична прив’язка до існуючого товару, без питань
60–90%	питання бухгалтеру: "Схоже на X, прив’язати?"
менше 60%	новий елемент у тимчасовій папці "Нові з AI"

Цифри порогів не істина, їх треба підбирати на реальних документах клієнта. Але сама схема з трьох зон і є тим, що робить систему придатною для роботи. Якщо питати про кожну позицію, бот буде дратувати. Якщо не питати ніколи, довідник за місяць заросте дублями.

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

Score зіставлення не обов’язково є текстовою схожістю. Назви "Папір А4 80 г/500 л" і "Бумага офисная А4 80 гм/м2, 500 листов" майже не схожі за символами, але це той самий товар. Тому score краще рахувати гібридно: точний артикул дає автоматичне зіставлення, а середню зону перевіряють ембединги й LLM.

Які помилки найчастіше роблять при автоматизації рахунків?

1. Брати кількість і ціну з довідника

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

2. Не з’ясувати, який документ насправді створюється

"Рахунок" і "накладна" це різні документи з різною логікою. Рахунок на оплату від постачальника ще не є надходженням товару. Якщо клієнт оплачує за рахунками з банкінгу, то створювати "Надходження товарів" з них передчасно. Спершу питаємо: який саме документ у BAS має з’явитися на виході.

3. Автоматично створювати товари без порогів

Автосворення нових позицій на кожну відмінність у назві дає дублі. "Папір А4 80г" і "Папір офісний A-One" стануть двома товарами. Лікується таблицею відповідностей "назва постачальника → наш товар" і трьома порогами зі схеми вище.

4. Вірити готовим текстам про безпеку

Клієнти-бухгалтери питають про безпеку першими, і це правильно. У згенерованих відповідях часто трапляються два перебільшення:

"API не зберігає дані". Насправді за замовчуванням провайдери можуть тимчасово зберігати запити для контролю зловживань, строки залежать від поточних умов. Повна відсутність зберігання (Zero Data Retention) це окрема угода.
"Azure дає повністю ізольований контейнер, до якого ніхто не має доступу". Це все ще хмара провайдера з власними правилами. Варіант може бути правильним, але обіцяти "стовідсоткову безпеку" не можна.

Перед кожною відповіддю клієнту перевіряйте актуальні умови провайдера. Якщо це підривне для довіри, краще написати "перевірю й підтверджу", ніж помилитися.

5. Обіцяти швидкість і "лише натиснути Провести"

Фрази на кшталт "за 5–10 секунд бухгалтеру залишиться тільки провести" гарно звучать у переписці, але ламаються на першому ж розмитому фото. Чесна обіцянка така: система готує чернетку, людина перевіряє. Перевірка і є частиною процесу, а не його збоєм.

6. Починати з найдорожчого

Головна причина, чому рішення лякає ціною. Типовий план: власний HTTP-сервіс у BAS, зовнішній оркестратор, повна інтеграція з Пактум, АРМ для перевірки. Це тижні роботи BAS-програміста ще до того, як ми побачили хоч один розпізнаний документ. Нижче показано, як цього уникнути.

7. Не рахувати час людини, яка перевіряє

Економія рахується не "скільки коштує розпізнавання", а "скільки хвилин на документ було й скільки стало". Якщо клієнт обробляє 10–100 документів на день, а перевірка займає менше хвилини, економія реальна. Якщо документів п’ять на день, окупність довга. Це питання треба поставити до початку розробки.

8. ПДВ як дрібниця

Ціна "з ПДВ" і "без ПДВ" у документах може відрізнятись від рядка до рядка. Модель має явно повертати два поля: ціна і ознака "ціна з ПДВ / без". Інакше сума документа в BAS може не збігтися, і виявиться це вже при проведенні.

Як зробити дешевше: три етапи замість одного великого проєкту?

Етап 1. Розпізнавання і перевірка без жодної розробки в BAS

Папка на диску. AI читає тільки її. Пошту й месенджери не чіпаємо, і багато бухгалтерів у цьому тверді.
Оркестратор (n8n на невеликому VPS або подібне) забирає нові файли.
Vision-модель повертає суворий JSON.
Результат кладемо в таблицю, яку бухгалтер бачить і виправляє.
Далі документ вводиться в BAS типовими засобами імпорту (наприклад, завантаження з Excel). Доступність залежить від конфігурації, це перевіряється на старті.

Клієнт уже на цьому етапі бачить реальну точність на своїх документах і не платить за BAS-розробку наосліп.

Етап 2. Автоматичне створення чернетки через стандартний API

Коли точність підтверджена, перевіряємо, чи база опублікована на веб-сервері, чи відкритий стандартний OData-інтерфейс і які саме документи та довідники в ньому доступні. Для документів із нетривіальною логікою заповнення OData може бути недостатнім: він записує дані, але не повторює автозаповнення, яке робить форма документа. Тоді потрібен HTTP-сервіс або зовнішня обробка в BAS. Створюємо документ у статусі "Не проведено".

Етап 3. Власний HTTP-сервіс у BAS і розширена логіка

Тільки якщо на етапі 2 упираємося в обмеження: складна логіка зіставлення номенклатури всередині BAS, окремий інтерфейс "фото ліворуч, документ праворуч", підсвітка сумнівних позицій. Це найдорожча частина, тому її роблять останньою і лише за потреби.

Що має повертати модель

Мінімальний JSON, який варто вимагати від моделі. Обов’язкове поле confidence по кожному ключовому реквізиту:

{
  "document_type": "invoice",
  "supplier": {
    "edrpou": {"value": "38294029", "confidence": 0.97},
    "name": {"value": "ТОВ Приклад", "confidence": 0.95}
  },
  "doc_number": {"value": "124", "confidence": 0.95},
  "doc_date": {"value": "2026-09-24", "confidence": 0.93},
  "currency": "UAH",
  "prices_include_vat": true,
  "vat_rate": 0.20,
  "items": [
    {
      "raw_name": "Папір А4 80г",
      "unit": "пач",
      "qty": 10,
      "price": 180.00,
      "price_without_vat": 150.00,
      "vat_amount": 300.00,
      "sum": 1800.00,
      "line_confidence": 0.92
    }
  ],
  "document_total": 1800.00
}

Промпт має вимагати відповідь тільки у форматі JSON, дату у форматі YYYY-MM-DD і явно заборонити вигадувати поля, яких на документі немає. Краще порожнє значення, ніж правдоподібна вигадка. Поле `document_type` не дає сплутати рахунок, акт і накладну, `raw_name` зберігає назву так, як вона на документі (для таблиці відповідностей і аудиту), а ПДВ по рядку не доводиться реконструювати. Суми рахує валідатор на сервері, а не модель: модель повертає qty, price і sum, а система перевіряє qty × price з допустимим округленням.

Які перевірки потрібні до створення документа?

Усе це дешево і ловить більшість помилок розпізнавання:

Арифметика. qty × price = sum по кожному рядку, а сума рядків збігається з підсумком документа.
Дублі. Комбінація ЄДРПОУ + номер + дата вже є в BAS? Тоді не створюємо, а попереджаємо.
ЄДРПОУ. 8 цифр для юридичної особи, 10 цифр (РНОКПП) для ФОП, плюс контрольне число. Помилка в одній цифрі може дати картку іншого контрагента.
Дата. Не з майбутнього і не на рік у минулому без причини.
Низький confidence. Документ іде у чергу ручної перевірки, а не в автоматику.

Контрагент і Пактум

Порядок простий: спершу шукаємо в BAS за ЄДРПОУ. Якщо знайшли, беремо наявну картку. Якщо ні, питаємо Пактум і створюємо контрагента з офіційними реквізитами. Відповіді сервісу варто кешувати, щоб не платити двічі за одного й того ж постачальника, але з терміном дії кешу: реквізити, керівник і статус платника ПДВ змінюються, тож ключові поля оновлюємо періодично або за запитом бухгалтера. Пактум заповнює реквізити, але не вирішує дублі в довіднику: перед створенням нового контрагента все одно шукаємо за ЄДРПОУ/ІПН, назвою та нормалізованими реквізитами. Якщо у клієнта Пактум уже підключений, це економить частину бюджету, тому питайте про це на початку.

Чи безпечно передавати рахунки в AI? Що сказати клієнту чесно

Коротка чесна схема розмови:

Веб-чат для людей і API для розробників працюють за різними правилами.
Для API провайдери заявляють, що дані клієнтів не використовуються для навчання моделей. Це перевіряється за актуальними умовами.
У деяких провайдерів і endpoint-ів передбачене тимчасове зберігання запитів для моніторингу зловживань. Наприклад, в OpenAI API для частини endpoint-ів це може бути до 30 днів. Zero Data Retention це окрема угода або налаштування, а не стандартна властивість будь-якого API.
Якщо вимоги ще суворіші, розглядається хмарний інстанс під окремого клієнта або обмеження переліку документів, які взагалі йдуть у модель.
NDA з клієнтом підписується, але не замінює технічного захисту.

Не обіцяйте абсолютної безпеки. Обіцяйте прозору схему: що, куди і на якій підставі передається.

Перед пілотом фіксуємо: провайдера, конкретну модель, endpoint, регіон обробки, чи увімкнено ZDR, чи передаються персональні дані та фінансові реквізити, і хто має доступ до логів оркестратора.

Скільки це може коштувати?

Нижче мої орієнтовні оцінки, не прайс. Реальні цифри залежать від конфігурації BAS, якості документів і ваших ставок. Ціни API змінюються, перевіряйте перед комерційною пропозицією.

Етап	Орієнтовна праця	Що отримує клієнт	Ризик / коли не потрібно
1. Розпізнавання, перевірки, таблиця	20–35 год	Реальна точність на власних документах	Фото низької якості дають багато ручних виправлень
2. Створення чернеток у BAS через API	15–30 год	Документ з’являється в BAS сам	OData не повторює логіку форми, для складних документів може не вистачити
3. Власний сервіс у BAS і інтерфейс перевірки	30–60 год	Повний сценарій з порогами і прив’язкою	Не потрібен, якщо етап 2 покриває потреби і обсяг невеликий

Щомісячні витрати на інфраструктуру при 10–100 документах на день (оцінка): API приблизно $5–60 залежно від моделі та обсягу, невеликий VPS або хмарний оркестратор $5–25. Разом зазвичай до кількох десятків доларів на місяць. Окремо йде ваш сервіс: моніторинг, донастроювання промпту й порогів, розбір помилок. Його варто закладати у фіксованій сумі, а витрати на API виписувати окремим рядком.

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

Що не варто автоматизувати на старті?

Автоматичне проведення документів.
Автоматичне створення нової номенклатури без підтвердження.
Документи з кількома валютами, взаємозаліками, авансами чи особливими умовами оплати.
Складні скановані документи без перевірки людиною.
Гарантію 100% точності.

Чекліст перед стартом

Який документ має з’явитися в BAS: рахунок, надходження чи інше?
Скільки документів на день і які це файли: чисті PDF чи фото з телефона?
Чи є документи в системах електронного обігу (тоді розпізнавання фото може не знадобитися, достатньо інтеграції)?
Яка конфігурація й версія BAS, чи доступні OData або HTTP-сервіси, де розміщена база: локально чи в хмарі?
Стан довідника "Номенклатура": дублі, артикули постачальників.
Чи є послуги в документах, які мають іти не в товарні позиції?
Чи підключений Пактум?
Що зі безпекою: чи є обмеження на передачу документів зовнішнім сервісам?
Скільки часу займає ручне введення одного документа зараз і хто перевірятиме результат?

Мій підсумок

Автоматизація "фото в BAS" цілком реальна і працює. Дорогою її роблять не моделі, а амбіція зробити все й одразу: кастомний сервіс у BAS ще до перевірки точності, автосворення товарів без порогів, обіцянки безпеки без підстав. Правильний порядок інший: спершу точність на реальних документах, потім чернетки, а власна розробка в BAS лише там, де без неї справді не обійтися. Бухгалтер при цьому лишається фінальним валідатором, і це не недолік системи, а її запобіжник.

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

Сайт: kotovich.uk.

Більше матеріалів і обговорень - в Telegram.

FAQ

Чи може AI створювати документи в BAS з фото рахунку?

Так. Модель читає фото, а система перевіряє контрагента й номенклатуру та створює чернетку «Не проведено». Бухгалтер перевіряє й проводить.

Звідки брати ціну й кількість: з довідника чи з документа?

Тільки з документа. Довідник дає лише прив’язку товару, а ціна постачальника може змінитись від поставки до поставки.

Чи безпечно передавати документи в AI API?

Дані API зазвичай не йдуть на навчання моделей, але можуть тимчасово зберігатися. Повна відсутність зберігання (Zero Data Retention) потребує окремої угоди.

Скільки це коштує?

Пілот без розробки в BAS починається з 20–35 годин праці. Щомісячні витрати на API та сервер зазвичай складають кілька десятків доларів.

Рахунки з фото в BAS "як в Монобанку": помилки, нюанси і дешевше рішення