Автоматизація роботи з документами: ШІ для накладних

Автоматизація роботи з документами в невеликій компанії майже завжди починається з одного болю. Бухгалтер або менеджер щодня вручну переносить дані з PDF-накладних, рахунків і актів в облікову програму. Постачальників десятки, і в кожного свій бланк. Кожен документ треба відкрити, знайти контрагента, внести позиції, звірити суму. Одна хибна цифра — і рахунок не сходиться при звірці, оплата затримується, а постачальник телефонує з претензією.

Стаття для власників і операційних директорів компаній на 5–100 людей: виробництво під замовлення, будівництво й монтаж, оптова торгівля, сервіс. Розберемо, як штучний інтелект читає первинні документи і чим це відрізняється від звичайного сканування. Покажемо, як порахувати, скільки коштує ручне введення саме у вас. Порівняємо три підходи до автоматизації документообігу і дамо покроковий план запуску.

Окремо — про те, де ШІ помиляється і які перевірки потрібні, щоб помилка не дійшла до обліку. Без обіцянок «повної автоматизації за добу»: лише те, що можна перевірити на власних документах.

Коротко

Скан у PDF — це ще не автоматизація. Цінність дає витяг полів (постачальник, позиції, суми) і запис в облікову програму без ручного введення.
Не розпізнавайте те, що вже електронне. Податкові накладні з ЄРПН і документи із сервісів ЕДО вже є даними. ШІ потрібен для PDF, сканів і фото.
ШІ читає, формули перевіряють, людина підтверджує. Без автоматичних перевірок помилка розпізнавання тихо потрапить в облік.
Рахуйте до старту. Документи × хвилини на документ × вартість години — і окремо помилки, подвійні оплати й затримки.
Починайте з одного потоку. Наприклад, вхідні рахунки й накладні постачальників. Решту додавайте, коли перший потік працює без сюрпризів.

Що таке автоматизація роботи з документами і чим вона відрізняється від «скану в PDF»

Коли власник чує «ШІ для документів», то зазвичай уявляє так: надіслав PDF — програма сама все прочитала. Насправді між «прочитати» і «корисно обробити» є кілька рівнів. Від того, який рівень вам потрібен, залежать вибір інструмента і обсяг робіт.

Три рівні: OCR, витяг полів і розуміння змісту

OCR (оптичне розпізнавання символів) перетворює картинку на текст. Він є в Adobe Acrobat, Google Drive, ABBYY FineReader. Результат — суцільний текст без структури. Назва постачальника, номер, позиції й суми йдуть підряд, і людина сама шукає, де що.

Витяг полів (в англомовних джерелах — IDP, Intelligent Document Processing) додає до OCR розуміння структури. Система визначає тип документа і повертає окремі поля: постачальник, код ЄДРПОУ, номер, дата, таблиця позицій, сума без ПДВ, ПДВ, сума до оплати. Такі дані вже можна записати в облікову програму.

Розуміння змісту — те, що додали сучасні мовні моделі. Вони не лише знаходять поле «сума», а й розуміють контекст. «К-ть» і «кільк.» — одне й те саме. Рядок «доставка» — це послуга, а не товар. Примітка «ціна дійсна до кінця місяця» — важлива умова. Саме цей рівень дає змогу працювати з документами від десятків постачальників без окремого шаблону під кожного.

Для бізнесу різниця проста. OCR економить частину набору тексту. Витяг полів прибирає ручне введення. Розуміння змісту прибирає ручне налаштування під кожен новий бланк.

Які документи автоматизувати першими

Документ	Звідки зазвичай приходить	Що витягувати	Складність для ШІ
Рахунок на оплату	PDF на пошту, месенджер	постачальник, ЄДРПОУ, IBAN, позиції, суми, ПДВ	низька
Видаткова накладна	PDF або папір разом із товаром	позиції, кількість, ціни, номер, дата, підписи	середня: печатки поверх тексту, папір
Акт виконаних робіт	PDF, сервіс ЕДО	сторони, перелік робіт, період, суми	низька або середня
Товарно-транспортна накладна	папір, електронна ТТН	відправник, одержувач, перелік вантажу	середня
Договір	Word, PDF	сторони, предмет, суми, строки, умови оплати	висока: довгий текст, правки
Чеки для авансових звітів	фото з телефона	продавець, дата, сума	середня: якість фото

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

Не розпізнавайте те, що вже є в електронному вигляді

Типова помилка — пропускати через розпізнавання документи, які вже існують як дані. В Україні таких документів багато:

Податкові накладні. Продавець зобов’язаний зареєструвати податкову накладну в Єдиному реєстрі податкових накладних і надати покупцю (пункт 201.10 Податкового кодексу). Покупець отримує її в електронному вигляді через програму звітності. Розпізнавати друковану копію немає сенсу.
Документи із сервісів ЕДО. Те, що прийшло через «Вчасно», M.E.Doc чи інший сервіс, можна вивантажити у структурованому форматі або забрати через інтеграцію, якщо сервіс її підтримує.
Банківські виписки. Клієнт-банк віддає їх у форматах для імпорту в облікову програму.

Правило: спершу перелічіть канали, якими документи приходять, і позначте, де дані вже структуровані. ШІ-розпізнавання потрібне лише для решти — PDF на пошту, сканів, фото з телефона, документів у месенджерах. Після такого розбору «ручних» документів часто лишається менше, ніж здавалося.

Як іде один документ: від пошти до облікової програми

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

Без автоматизації

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

Найдорожчі тут не кроки 3–4, а кроки 2, 5 і 6. Документ губиться між людьми, звірку пропускають, погодження тягнеться днями.

З ШІ-обробкою

Документ потрапляє в одну точку входу: окрему поштову скриньку, Telegram-бот, папку сканера.
ШІ визначає тип документа і витягує поля.
Система перевіряє: контрагент є в базі, суми сходяться, такого номера від цього постачальника ще не було, документ відповідає замовленню.
Якщо все гаразд — створює документ в обліковій програмі і прикріплює до нього файл.
Якщо є розбіжність — ставить документ у чергу на перевірку з поясненням: «сума позицій не дорівнює підсумку», «контрагента немає в базі».
Відповідальна людина підтверджує або виправляє. Рахунок іде на погодження оплати.
Файл зберігається поруч із записом. Його можна знайти за контрагентом, замовленням чи сумою.

Участь бухгалтера зводиться до перевірки винятків і підтвердження. Скільки часу це займає на один документ, міряйте на своїх даних у пілоті. Час залежить від якості документів і кількості позицій, і чужі цифри тут мало що скажуть.

Обов’язкові реквізити — готовий чекліст для перевірки

Закон «Про бухгалтерський облік та фінансову звітність в Україні» дозволяє складати первинні документи в паперовій або електронній формі. Він же перелічує їхні обов’язкові реквізити (стаття 9). Цей перелік зручно взяти за основу автоматичної перевірки. Система позначає документ, де чогось бракує:

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

При монотонному введенні людина легко пропускає відсутній підпис чи посаду. Система перевіряє кожен документ однаково. Для актів є нюанс. Якщо в документі вказано період послуг, а письмовий договір передбачає такий порядок, відсутність підпису замовника не є порушенням (та сама стаття 9 закону). Таке правило теж можна закласти в перевірку, а не тримати в голові.

Скільки коштує ручна робота з документами: як порахувати

Ручне введення первинки рідко хтось рахує, бо «так було завжди». Порахувати можна за пів години. Методика нижче не потребує жодних зовнішніх даних — лише ваші.

Формула прямих витрат

Прямі витрати на місяць = кількість документів × середній час на документ (хв) ÷ 60 × повна вартість години працівника.

Повна вартість години — це зарплата плюс ЄСВ, поділені на фактичні робочі години за місяць. Не беріть «чисту» зарплату: так ви занизите результат.

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

Розібраний приклад

Це приклад для розрахунку, а не статистика. Торговельна компанія на 50 людей отримує 300 вхідних документів на місяць. Тижневий замір показав у середньому 8 хвилин на документ разом із пошуком контрагента і звіркою.

300 × 8 = 2 400 хвилин, тобто 40 годин на місяць. Це повний робочий тиждень одного працівника щомісяця — лише на перенесення цифр із PDF в облікову програму. Помножте 40 на повну вартість години вашого бухгалтера, і отримаєте прямі витрати.

Детальніше про те, як рахувати втрати часу і окупність, — у статті про розрахунок окупності на документах.

Приховані витрати: що додати до розрахунку

Прямі витрати — лише частина картини. Додайте до них:

Виправлення помилок. Скільки годин на місяць іде на пошук і виправлення хибних записів? Запитайте бухгалтера — він знає.
Подвійні оплати. Чи бувало, що один рахунок оплатили двічі, бо він прийшов і поштою, і в месенджер? Сума такої помилки — пряма втрата до повернення коштів.
Втрачені знижки за ранню оплату. Якщо постачальник дає знижку за оплату в короткий строк, а рахунок кілька днів чекає на введення, знижку ви втрачаєте. Перегляньте договори й оплати за минулий квартал.
Штрафи й пеня. Подивіться в договорах, яка відповідальність за прострочення оплати, і скільки разів вона наставала.
Час керівника. Пошук «де той акт», з’ясування, хто погодив оплату, ручні звірки перед перевіркою.

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

Коли автоматизація окупиться, а коли ні

Автоматизація роботи з документами має сенс, якщо виконуються хоча б дві умови з чотирьох:

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

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

Автоматизація документообігу: три підходи і як обрати

Під назвою «автоматизація документообігу» ринок пропонує три різні речі. Вони вирішують різні задачі, і плутанина між ними — часта причина розчарування.

Сервіси ЕДО: обмін підписаними документами

«Вчасно», M.E.Doc та інші сервіси ЕДО вирішують юридичну частину. Документ підписується кваліфікованим електронним підписом (КЕП) і передається контрагенту без паперу. Закон прямо каже: юридична сила електронного документа не може бути заперечена виключно через те, що він має електронну форму (стаття 8 Закону «Про електронні документи та електронний документообіг»).

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

Обмеження: – розпізнавання паперових і PDF-документів та запис в облік — не основна задача таких сервісів; – контрагент має працювати в тому самому або сумісному сервісі; – документи від тих, хто надсилає PDF поштою чи привозить папір, лишаються ручними.

ЕДО — правильний крок для обміну. Але він не прибирає ручне введення того, що приходить поза ним.

Сервіси розпізнавання для BAS і 1С

Окрема ніша — сервіси, які розпізнають первинку і передають її в облікову програму. Приклад — український сервіс JDOC. За його описом, він працює з рахунками, актами, видатковими й прибутковими накладними, банківськими виписками й чеками, а підключається обробкою до конфігурації 1С/BAS (анонс на «Дебет-Кредит», позначений як реклама). Подібні модулі пропонують і партнери BAS.

Для кого: бухгалтерія, яка живе в BAS, а головний біль — набір первинки.

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

Обмеження: – документ потрапляє в облік, але не пов’язується з погодженням оплати, відвантаженням і замовленням поза бухгалтерією; – документи з месенджерів і від менеджерів хтось усе одно має передати; – правила перевірки — ті, які закладено в сервіс, а не ваші.

Власна система під процес компанії

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

Для кого: компанії, де документи — частина продажу, постачання чи виробництва. Де втрати не в наборі тексту, а в розривах між людьми і відділами.

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

Порівняння підходів

Критерій	Сервіс ЕДО	Розпізнавання для BAS/1С	Система під процес
Головна задача	Обмін підписаними документами	Введення первинки в облік	Документи всередині замовлень, постачання й оплат
Документи на папері й PDF поштою	Не закриває	Закриває	Закриває
Зв’язок із замовленням і оплатою	Немає	Обмежений	Є
Хто налаштовує	Бухгалтер сам	Бухгалтер або партнер BAS	Підрядник разом із вами
Залежність від постачальника	Висока	Середня	Код і дані ваші
Коли обирати	Контрагенти готові до ЕДО	Біль — набір у BAS	Документи губляться між відділами

Підходи не виключають один одного. Типова зв’язка: ЕДО для обміну з великими контрагентами, розпізнавання — для решти, а система управління пов’язує документ із замовленням і оплатою. Чи вистачить вам готового рішення, допоможе визначити тест «Готова CRM чи своя система».

Як ШІ розпізнає рахунки й накладні: покрокова логіка

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

Крок 1. Прийом документа

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

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

Крок 2. Визначення типу документа

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

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

Крок 3. Витяг полів

Для рахунку чи накладної типовий набір полів:

постачальник: назва, код ЄДРПОУ, IBAN;
покупець: назва, код ЄДРПОУ;
номер і дата документа;
підстава: номер договору або замовлення;
позиції: найменування, одиниця виміру, кількість, ціна, сума;
сума без ПДВ, ПДВ, сума до оплати;
строк оплати, якщо вказаний.

Результат повертається у структурованому вигляді. Його одразу можна перевіряти правилами і записувати.

Важливий принцип: ШІ лише читає. Перераховує суми і порівнює їх формула, а не модель. Так ми робимо в наших системах: ціни й суми рахують формули, а ШІ відповідає за розбір тексту.

Крок 4. Автоматичні перевірки

Тут вирішується, чи можна довіряти системі.

Арифметика. Кількість × ціна = сума рядка. Сума рядків = підсумок. ПДВ = база × ставка. Основна ставка ПДВ — 20 відсотків, є також ставки 7 і 0 відсотків (пункт 193.1 Податкового кодексу). Система має знати, яка ставка очікується для цього постачальника і товару.
Контрагент. ЄДРПОУ є в довіднику, IBAN збігається з тим, що вже був у цього постачальника. Зміна реквізитів — завжди на ручну перевірку. Підміна рахунку з чужим IBAN — класичний сценарій шахрайства.
Дублікати. Поєднання номера, дати й постачальника ще не траплялося.
Звірка із замовленням. Позиції, кількість і ціни відповідають замовленню постачальнику. Накладна відповідає тому, що реально прийняли на склад. Це так звана тристороння звірка: замовлення, накладна, рахунок.
Ліміти. Сума вища за поріг — обов’язкове погодження людиною.
Реквізити. Обов’язкові реквізити зі статті 9 закону про бухоблік на місці.

Крок 5. Запис і маршрут

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

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

Точність: де ШІ помиляється і як це обійти

Чесна відповідь: ШІ помиляється. Питання не в тому, чи будуть помилки. Питання в тому, чи помітить їх система до запису в облік.

Що показують незалежні тести

Відкритих досліджень саме на українських накладних ми не знайшли. Найближче — незалежний тест розпізнавання тексту AIMultiple на 300 документах. На друкованому тексті найкращі інструменти показали 95–96%: Azure Document Intelligence — 96%, GPT-5, Gemini 2.5 Pro, Google Vision і Amazon Textract — по 95%. На рукописному тексті розкид — від 46% до 95% залежно від інструмента (AIMultiple, OCR accuracy benchmark).

Цей тест вимірює, наскільки точно прочитано текст, а не те, чи правильно знайдено поле «сума до оплати». Висновок для бізнесу: друкований документ сучасні моделі читають добре, рукописні вставки — лотерея, а кожне поле треба перевіряти правилами. Реальну точність на ваших документах покаже лише пілот на вашому архіві.

Де виникають помилки і що з цим робити

Проблема	Чому виникає	Як закрити
Розмитий скан, фото під кутом	символи нечитабельні	інструкція для фото, автоматичне повернення неякісного знімка з проханням перезняти
Рукописні правки поверх друку	хтось виправив кількість ручкою	будь-яка розбіжність із замовленням — на ручну перевірку
Печатка поверх суми	частина цифр закрита	арифметична перевірка ловить невідповідність
Складні таблиці з об’єднаними клітинками	рядки зсуваються	такі документи — у тестовий набір, перевірка суми кожного рядка
Різне написання контрагента	«ТОВ Альфа-Трейд» і «Альфа Трейд ТОВ»	пошук за кодом ЄДРПОУ, а не за назвою
Документи іноземною мовою	інші формати дат і чисел	окремі правила для імпортних постачальників
Кілька документів в одному файлі	рахунок і накладна разом	розділення на документи перед розбором

Принцип, який рятує від дорогих помилок

Найнебезпечніша помилка — не та, яку система не прочитала. Найнебезпечніша — та, яку вона прочитала впевнено і неправильно. Наприклад, загубила кому, і рахунок на 9 250 гривень записався як 925 000.

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

Інтеграція з українськими програмами: BAS, M.E.Doc, «Вчасно», Telegram

Найкраще розпізнавання нічого не дає, якщо дані не потрапляють туди, де з ними працюють.

BAS і 1С

Є три способи передачі даних:

Через HTTP-сервіс. Зовнішня система передає розпізнані поля, BAS створює документ. Найгнучкіший варіант, але потрібен фахівець BAS для налаштування.
Через файловий обмін. Система формує файл у форматі, який BAS завантажує стандартним механізмом обміну. Підходить, якщо обмін між програмами вже налагоджено.
Через зовнішню обробку. Готові модулі від партнерів чи сервісів розпізнавання. Найпростіше в запуску, найменше гнучкості.

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

Номенклатура — найтонше місце. Постачальник пише «Профіль 40х20х2 ст.», а у вашому довіднику «Труба профільна 40×20×2». Потрібна таблиця відповідностей, яку система поповнює після кожного підтвердження людиною. Через місяць-два більшість позицій зіставляється сама, а людина бачить лише нові.

M.E.Doc, «Вчасно» та інші сервіси ЕДО

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

Telegram і пошта як точка входу

Для невеликої компанії найзручніша точка входу — Telegram-бот. Менеджер, комірник чи водій фотографує накладну або пересилає PDF у бот. Бот відповідає, що документ прийнято, а після розбору — що розпізнано або чого бракує. Пошта — для постачальників: окрема скринька для рахунків, яку система читає сама.

Якщо у вас уже є CRM

Замінювати її не обов’язково. Ми доробляємо готові CRM клієнтів: не міняємо систему, а додаємо те, чого бракує. Наприклад, розбір вхідних документів і прив’язку їх до угоди чи замовлення.

Як ШІ-система управління бізнесом закриває роботу з документами

Directoria робить ШІ-систему управління бізнесом під процеси компанії. Документи в ній — не окремий модуль, а частина замовлення: від заявки до оплати. Код таких систем пише штучний інтелект під контролем архітектора, тому перша робоча версія виходить за кілька днів.

Вихідні документи формуються із замовлення

Рахунок, видаткова накладна, акт, комерційна пропозиція, сума прописом, PDF — це готова основа наших систем. Менеджер не набирає реквізити клієнта і позиції вдруге. Вони беруться з картки замовлення і клієнта. Ціну рахують формули компанії, а не ШІ. Про вихідні рахунки і контроль оплат докладніше — у статті про автоматизацію виставлення рахунків і звірки оплат.

Вхідні документи читає ШІ, підтверджує людина

ШІ в системі читає документи й прайси, розбирає повідомлення у вільній формі, готує чернетки відповідей для менеджера. Розпізнаний рахунок прив’язується до замовлення постачальнику, проходить перевірки і чекає на підтвердження відповідальної людини. Клієнту чи постачальнику нічого не надсилається без людини, якщо інше не погоджено.

Як це працює в закупівлях — від заявки виробництва до оплати постачальнику — показано в статті про автоматизацію відділу постачання.

Наш приклад: документи, які формуються самі

У калькуляторі для виробника металоконструкцій система для кожної заявки сама формує комерційну пропозицію у фірмовому PDF і розрахунок в Excel із живими формулами. Перед запуском розрахунок звірили з Excel-книгою інженера на контрольних прикладах — збіглося до копійки.

Під час звірки в самій книзі знайшли помилки. Для кроку ферм 4,25 м таблиця видавала #Н/Д, а в кількох місцях рахувала неточно. Ми не виправляли мовчки, а передали інженеру. Урок для автоматизації документів той самий: перенесення в систему виявляє помилки старого способу, а рішення щодо них ухвалює людина.

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

Типові помилки під час впровадження і як їх уникнути

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

Автоматизують хаос

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

Немає перевірок — дані йдуть в облік як є

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

Налаштовують на «ідеальних» документах

Демо на трьох чистих PDF нічого не доводить. Зберіть реальний набір: 10–20 документів кожного типу від різних постачальників, разом із найгіршими сканами й фото. На ньому і міряйте точність.

Ніхто не відповідає за чергу винятків

Документи «на перевірку» накопичуються, якщо за ними не закріплена людина. Призначте відповідального і строк реакції. Налаштуйте сповіщення в Telegram, якщо черга росте.

Забувають про зміну бланків у постачальників

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

Немає резервних копій і контролю версій

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

План запуску: з чого почати автоматизацію роботи з документами

Нижче — послідовність, яка працює для компанії без власного IT-відділу.

Крок 1. Інвентаризація потоків

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

Крок 2. Вибір першого потоку

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

Крок 3. Опис правил і полів

Список полів, правила перевірки, ліміти, хто погоджує, що робити з винятками. Це робочий документ для підрядника. У нас опис процесу триває тиждень.

Крок 4. Перша версія на реальних документах

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

Крок 5. Паралельна робота

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

Крок 6. Перехід і розширення

Коли розбіжностей майже немає, переходите на новий спосіб. Далі додаєте наступні типи документів по одному. Уся система під процес — 2–4 тижні після опису.

Чекліст: що підготувати до старту

приклади документів кожного типу, включно з поганими сканами і фото;
довідник контрагентів і номенклатури, почищений від дублів;
правила погодження оплат і ліміти сум;
доступи: пошта, облікова програма, сервіс ЕДО;
відповідальний за чергу винятків і строк реакції;
результати заміру часу на документ — щоб через місяць було з чим порівняти.

Що ще автоматизувати після документів, підкажуть приклади автоматизації бізнесу і перелік бізнес-процесів для автоматизації.

Коли автоматизувати документи не варто

Чесно про випадки, коли гроші краще витратити на інше:

Документів мало, бланки стабільні. Кілька десятків документів на місяць від постійних постачальників простіше вносити вручну або через шаблони облікової програми.
Довідники в безладі. Контрагенти задвоєні, номенклатура без правил. Система зіставлятиме документи з неправильними записами. Спершу почистіть довідники.
Проблема не у введенні, а в підписах. Якщо документи не повертаються підписаними, допоможе ЕДО, а не розпізнавання.
Ви чекаєте повної автоматизації без людини. Для фінансових документів людина в контурі лишається. Інакше перша впевнена помилка ШІ обійдеться дорожче, ніж уся економія.
Основний потік — рукописні документи. Незалежні тести показують великий розкид у розпізнаванні рукопису. Тут краще спершу перевести постачальників на друковані чи електронні документи.

Часті питання

Автоматизація роботи з документами і автоматизація документообігу — це одне й те саме?

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

Чи потрібен IT-фахівець у штаті?

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

Що буде, якщо постачальник змінить бланк рахунку?

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

Скільки часу займає впровадження?

Сервіс ЕДО підключається за кілька днів. У нас опис процесу займає тиждень, перша робоча версія — кілька днів, уся система — 2–4 тижні після опису. Ще два тижні система працює паралельно зі старим способом, щоб звірити результат.

Яка точність розпізнавання порівняно з людиною?

На друкованих документах сучасні інструменти читають текст дуже точно, на рукописних — з великим розкидом (дані тесту AIMultiple вище). Людина при монотонному введенні втомлюється і пропускає дрібниці. ШІ не втомлюється, але може впевнено помилитися. Найкращий результат дає зв’язка: ШІ обробляє стандартні документи, правила ловлять невідповідності, людина розбирає винятки.

Як захищені дані документів?

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

Якщо ваша бухгалтерія і менеджери щодня переносять дані з накладних, рахунків і актів вручну, опишіть, як у вас зараз іде один документ — від пошти постачальника до оплати. Покажемо систему на демо за 30 хвилин і чесно скажемо, що вам вигідніше: сервіс розпізнавання, ЕДО чи система під ваш процес. Детальніше — ШІ-система управління бізнесом.