Розпізнавання рахунків та інвойсів із ШІ: як контролювати помилки в цифрах

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

Головна умова проста. ШІ відповідає за читання документа, а рішення «прийняти чи зупинити» ухвалюють правила, які ви можете перевірити. Після цієї статті ви зможете визначити, які перевірки потрібні саме вашому потоку рахунків, де встановити поріг автоматичної обробки і як порахувати, скільки коштуватиме ручна перевірка винятків. Ми не обіцяємо нульової помилки розпізнавання. Ми пояснюємо, як не пропустити помилку далі в облік.

Чому помилка в цифрах небезпечніша за друкарську помилку

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

Ось типові випадки, що трапляються в нестандартних сканах:

• Зсув десяткового розділювача. «1 440,00» перетворюється на «144000» або «14400», бо модель сприйняла кому як роздільник тисяч чи загубила її на нечіткому скані.
• Втрачений знак. Рахунок-коригування з від’ємною сумою стає звичайним рахунком до сплати.
• Неправильна валюта. Символ валюти стоїть у шапці, а в рядках його немає. Модель підставляє валюту за замовчуванням.
• Сплутані поля. «Сума без податку» записується в поле «До сплати», або попередній борг додається до поточної суми.
• Банківські реквізити. Одна змінена цифра в IBAN не впливає на арифметику, але гроші підуть не туди.
• Переплутані дати. «03.04» може означати 3 квітня або 4 березня залежно від формату країни постачальника. Від дати залежать строк оплати, звітний період і пошук дублів, тому помилка тут тягне за собою інші.
• Ціна за одиницю замість суми рядка. У таблицях без чітких меж колонок модель іноді бере сусіднє число. Підсумок рядка тоді виглядає правдоподібно, але не збігається з добутком кількості на ціну.

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

Витягування й нормалізація: зберігайте вихідний фрагмент поруч зі значенням

Перший крок процесу: модель або спеціалізований сервіс розпізнавання витягує поля. Готові моделі для рахунків уже вміють знаходити типові реквізити. Наприклад, готова модель обробки рахунків у Microsoft AI Builder може витягувати номер рахунку, дату, постачальника, суму без податку, суму податку, загальну суму, суму до сплати, платіжні реквізити на кшталт IBAN і рядки товарів із кількістю та ціною за одиницю. Для цих полів модель також повертає показник впевненості (confidence).

Друга дія часто випадає з уваги: нормалізація. Розпізнаний рядок «1 440,00 грн» треба перетворити на число 1440.00 і валюту UAH. Саме тут народжується багато помилок, тому радимо зберігати три речі одночасно:

1. Вихідний фрагмент, як його прочитано з документа: «1 440,00 грн».
2. Нормалізоване значення: 1440.00, UAH.
3. Посилання на місце в документі: сторінка, область, рядок таблиці.

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

Окремо про структурований вивід. Якщо ви використовуєте мовну модель і просите її повернути JSON за схемою, Structured Outputs гарантує відповідність схемі лише для успішної завершеної відповіді, яка не є відмовою чи обірваною через ліміт токенів: усі обов’язкові ключі будуть на місці, типи збігатимуться. Але це не гарантує, що в полі total стоїть правильна сума. Відмови й обірвані відповіді потрібно окремо обробляти кодом. Правильний JSON означає лише правильну форму, а не правильний зміст.

Арифметичні перевірки: рахунок сам себе перевіряє

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

Базовий набір перевірок:

• Рядок: кількість × ціна за одиницю = сума рядка.
• Проміжний підсумок: сума всіх рядків = сума без податку.
• Знижки: проміжний підсумок мінус знижка = база оподаткування, якщо знижка застосовується до податку.
• Податок: база × ставка = сума податку, з урахуванням правил округлення.
• Разом: база + податок = загальна сума.
• До сплати: загальна сума ± попередній баланс або аванс = сума до сплати, якщо ці поля є в документі.

Округлення заслуговує окремої уваги. Податок може округлятися в кожному рядку або один раз для всього документа. Різниця між двома способами іноді становить кілька копійок. Тому перевірка має допускати визначену вами похибку, наприклад до 0,01 на рядок або до кількох копійок на документ, але не більше. Правило допуску записуйте явно й узгоджуйте з бухгалтерією, а не вигадуйте в коді «на око».

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

Навчальний приклад: число правильного формату, яке не проходить перевірку

Умовний рахунок, вигаданий для пояснення, не взятий з реального проєкту:

Значення 14400 має коректний числовий формат, і структурована відповідь моделі з ним цілком валідна. Проте арифметика документа його спростовує: 1200 + 240 дорівнює 1440. Документ іде в чергу винятків із позначкою «розбіжність загальної суми», а бухгалтер бачить вихідний фрагмент «1 440,00 грн» і нормалізоване 14400.

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

Жодна з цих перевірок не підтверджує платіжні реквізити. Якщо в рахунку змінився IBAN, арифметика залишиться бездоганною. Реквізити перевіряються окремо, про це нижче.

Довідники й дублі: що ви вже знаєте про постачальника

Арифметика ловить внутрішні суперечності документа. Довідники ловлять суперечності між документом і вашими даними.

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

Платіжні реквізити. Порівняйте розпізнаний IBAN з тим, що збережено в картці постачальника. Будь-яка зміна реквізитів має йти на окреме підтвердження, бажано через канал, не пов’язаний із самим рахунком: дзвінок контактній особі з довідника, а не за номером із листа. Це правило захищає не лише від помилки розпізнавання, а й від шахрайських листів з «оновленими реквізитами».

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

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

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

Черга винятків: куди потрапляє все сумнівне

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

• впевненість розпізнавання критичного поля нижча за ваш поріг;
• не проходить будь-яка арифметична перевірка;
• постачальника не знайдено в довіднику;
• реквізити відрізняються від збережених;
• знайдено можливий дубль;
• модель відмовилася відповідати або відповідь неповна.

Про поріг впевненості варто сказати точніше. У Document Intelligence поле confidence є оцінкою ймовірності від 0 до 1: значення 0,95 означає, що прогноз, імовірно, правильний приблизно 19 разів із 20. Для сценаріїв, де точність критична, впевненість можна використовувати як критерій: прийняти результат автоматично чи позначити для перевірки людиною. Впевненість розпізнавання тексту і впевненість витягування пари «ключ–значення» є різними величинами, тому перевіряти варто обидві.

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

Як вибрати поріг? Емпірично. Візьміть вибірку документів, де правильні значення відомі. Подивіться, скільки помилок модель робить при різних рівнях впевненості. Поріг, за якого частка помилок, що проходять далі, стає прийнятною для вашого бізнесу, і є робочим. Для критичних полів, як-от сума до сплати чи IBAN, він буде вищим, ніж для адреси доставки.

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

Оцінка якості: три різні метрики замість однієї «точності»

Найчастіша помилка при запуску: говорити про «точність 98%» без уточнення, що саме вимірюється. Насправді вам потрібні щонайменше три окремі показники.

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

Точність документа. Яка частка документів має правильними всі критичні поля одночасно. Якщо в документі десять критичних полів і кожне розпізнається правильно в 98% випадків, документ повністю правильний помітно рідше. Якщо помилки в полях незалежні, ймовірність отримати всі десять правильними дорівнює 0,98 у десятому степені, тобто приблизно 0,82. Це умовний розрахунок для ілюстрації: на практиці помилки часто пов’язані між собою, бо поганий скан псує кілька полів одночасно. Тому точність документа майже завжди нижча за точність полів.

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

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

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

Що зробити на своєму процесі

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

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