Ваш інструмент ШІ для бухгалтерії щойно обробив 200 рахунків-фактур, поки ви пили каву. Швидкий, невтомний, упевнений — і, можливо, помилковий щодо сорока з них. Опитування від вересня 2026 року показало, що 62% фахівців із фінансових послуг кажуть, що помилка, згенерована ШІ, уже дійшла до клієнта, тоді як 93% аудиторських функцій тепер використовують ШІ, але 60% не мають формальної стратегії для нього. Розрив між цими двома цифрами — це те місце, де живуть викривлені звіти, провалені аудити та незручні розмови з клієнтами.
Незручна правда: постачальники озвучують показники точності, виміряні на чистих, спеціально підібраних документах, а ваша вхідна скринька повна чого завгодно, тільки не цього. Зім’яті чеки, багатосторінкові рахунки-фактури з позиціями у трьох валютах, кредит-ноти, які виглядають як рахунки, постачальники, які змінюють макет щокварталу — ось це справжній тестовий набір. Якщо ви використовуєте ШІ деінде у своєму бухгалтерському процесі, вам потрібен власний бенчмарк: повторюваний спосіб виміряти, що модель робить правильно, що неправильно і чи покращується вона, чи тихо деградує. Цей посібник покаже, як його створити.
Чому «виглядає правильно» — це не вимірювання
Великі мовні моделі не помиляються так, як люди. Втомлений бухгалтер переставляє дві цифри, і помилка виглядає як помилка. LLM галюцинує правдоподібну суму рахунку з повною впевненістю, гарно форматує її і рухається далі. Як сказала одна команда, яка роками тестувала моделі на вилученні документів: модель усе одно дає впевнену відповідь — без обґрунтувань, без суджень, просто читає число, і навіть найкращі моделі не можуть зробити це з точністю 100%.
Цей режим збою має реальні наслідки. Аудитори тепер явно перевіряють робочі документи, згенеровані ШІ, і фірми, які покладаються на результати ШІ без підтвердження, тестування та документування висновків, мають очікувати виявлення суттєвого недоліку у своєму фінансовому контролі. Галюциновані числа у фінансовій звітності рідко виглядають очевидно неправильно — вигадана сума позиції все одно сходиться в електронній таблиці, яку також згенерувала модель. Єдиний захист — це вимірювання: знання фактичного рівня помилок вашого інструмента на ваших документах, із постійним моніторингом.
Є також хороші новини, які варто виміряти. У прямих порівняльних тестах проти людей-ревізорів рахунків LLM досягали точності до 92% у рішеннях про затвердження рахунків, перевершуючи межу 72%, встановлену досвідченими юристами, — при цьому працюючи на порядки швидше та дешевше. ШІ справді може перевершувати людей на чітко визначених завданнях вилучення даних. Сенс бенчмаркінгу не в тому, щоб довести, що ШІ поганий; це з’ясувати, де саме ваш ШІ хороший, щоб автоматизувати частини, які він виконує ідеально, і контролювати частини, де він помиляється.
Три завдання, які варто бенчмаркувати
Бухгалтерський ШІ робить багато речей, але три завдання несуть більшу частину ризику та обсягів. Бенчмаркуйте кожне окремо, бо модель, яка досягає успіху в одному, може провалитися в іншому.
1. Вилучення даних із рахунків-фактур
Витягування структурованих полів — назва постачальника, номер рахунку, дати, позиції, проміжні підсумки, податок, загальна сума, валюта — із PDF і сканованих зображень. Це завдання з найбільшим обсягом і найчастіше бенчмаркується: публічні тестові набори, як-от DocILE, оцінюють моделі за 55 полями рахунків, і навіть моделі переднього краю помиляються приблизно в 26% полів. Особливу увагу зверніть на позиції, суми з податком проти без податку та багатовалютні рахунки, де помилки зосереджені.
2. Класифікація витрат
Віднесення кожної транзакції до правильного рахунку або категорії — обіди проти розваг, матеріали проти обладнання, платежі підрядникам проти зарплати. Це завдання судження, замасковане під завдання маркування: «правильна» відповідь залежить від вашого плану рахунків і ваших податкових позицій, тому точність тут завжди вимірюється проти ваших правил, а не універсального ключа. Відстежуйте точність і повноту за категоріями, бо модель із 98% загальної точності все одно може неправильно класифікувати кожну підписку на програмне забезпечення.
3. Введення фінансових даних і проведення проводок
Перетворення первинних документів на фактичні бухгалтерські проводки — правильні рахунки, правильний напрямок дебет/кредит, правильні суми, правильні періоди. Це завдання, де малі помилки накопичуються: неправильно класифікована витрата — це одна неправильна клітинка, але неправильно проведена проводка потрапляє в оборотно-сальдову відомість, фінансову звітність і податкову декларацію. Бенчмаркуйте це наскрізно, від документа до проведеної проводки, а не лише поле за полем.
Спочатку створіть набір із перевіреними даними
Бенчмарк настільки чесний, наскільки чесний його ключ відповідей. Перш ніж тестувати будь-яку модель, зберіть від 50 до 100 реальних документів зі свого процесу та розмітьте їх вручну — уважно, бо кожна помилка маркування пізніше стане хибною невдачею.
Прагніть до реалістичного поєднання, а не чистого. Хороший еталонний набір — це приблизно дві третини звичайних документів і одна третина проблемних: низькоякісні скани з телефону, рукописні нотатки на чеках, багатосторінкові рахунки, виписки з десятками позицій, кредит-мемо, іншомовні рахунки та документи від ваших найнеохайніших постачальників. Одна опублікована оцінка агента для рахунків використовувала саме такий розподіл — 35 чистих і 15 проблемних рахунків — і саме на проблемному наборі проявилися всі цікаві невдачі.
Розмічайте на рівні полів, а не просто «правильно чи неправильно за документом». Для кожного рахунку записуйте постачальника, номер рахунку, дату виставлення, дату оплати, кожну позицію з кількістю та ціною за одиницю, проміжний підсумок, суму податку та загальну суму. Для витрат записуйте правильний рахунок згідно з вашим поточним планом рахунків. Зберігайте мітки у простій електронній таблиці або JSON-файлі, контрольованому версіями разом із вашими книгами, щоб ви могли повторно запускати той самий тест проти кожної нової моделі чи зміни запиту. Цей версіонований ключ відповідей — це довговічний актив; моделі приходять і йдуть.
Опіртеся спокусі дозволити ШІ розмічати власний тестовий набір. Розмітка за допомогою моделі — це нормально для першого чернетки, але кожна мітка має бути перевірена людиною, яка звіряє її з першоджерелом. Ключ відповідей, який модель написала собі сама, — це дзеркало, а не вимірювання.
Метрики, які справді мають значення
Інформаційні панелі постачальників люблять єдині заголовні числа. Для бухгалтерської роботи вам потрібна невелика родина метрик, бо різні помилки коштують по-різному.
Точність на рівні полів — це ваша заголовна метрика: яка частка всіх запитаних полів у всіх тестових документах точно збіглася з ключем відповідей? Будьте суворими — «приблизно» не рахується в бухгалтерії. Сума $12,540 — це не $12,450, а модель, яка округлює, змінює формат або «допоміжно» виправляє дати, — це модель, яка редагує ваші книги без дозволу.
Показник точного збігу — це суворіший брат: яка частка документів повернулася з кожним полем правильним? Це число передбачає ваше робоче навантаження на перевірку. Різниця між 82% і 94% точності полів здається помірною, поки не переведете її в практичну площину: при 82% приблизно кожен п’ятий рахунок потребує людини; при 94% — кожен сімнадцятий.
Точність і повнота за полями показують, де живуть помилки. Точність запитує: коли модель заповнила це поле, як часто воно було правильним? Повнота запитує: коли поле існувало в документі, як часто модель його знаходила? Низька точність на сумах рахунків означає вигадані числа — це небезпечно. Низька повнота на позиціях означає пропущені рядки — теж небезпечно, але принаймні видимо. Розбийте ці показники за полями, бо «точність 95%» може приховувати модель, яка ніколи не пропускає дату, але регулярно вигадує суми податків.
Показник наскрізної обробки — це бізнес-метрика: яка частка документів пройшла шлях від вхідної скриньки до проведеної проводки без жодного втручання людини? Добре побудовані виробничі конвеєри, що поєднують OCR із вилученням за допомогою LLM і детермінованою валідацією, повідомляють приблизно про 77% наскрізної обробки з точністю полів 99% — і, що не менш важливо, вони знають, які 23% направити людині. Бенчмарк, який не вимірює рішення про маршрутизацію, вимірює лише половину системи.
Вартість і затримка за документ завершують картину. Модель переднього краю, яка набирає на два бали більше, але коштує в двадцять разів дорожче за рахунок, може бути виправдана для складних документів і невиправдана для простих — але лише ваш бенчмарк може сказати, де проходить ця межа. Відстежуйте долари за документ і секунди за документ разом із точністю, інакше ви оптимізуватимете оцінку, поки рахунок за обробку рахунків потроїться.
Як проводити тест
Маючи ключ відповідей і метрики, процедура проста:
- Заморозьте тестовий набір. Заблокуйте свої 50–100 документів і міток до будь-якого тестування. Ніколи не додавайте документ до тестового набору після того, як побачили, що модель на ньому помиляється — це перетворює вимірювання на навчання.
- Проводьте тест наосліп. Подайте моделі лише сирі документи з тим самим запитом і налаштуваннями, що й у виробництві. Жодних підказок, повторних спроб, вибіркового відбору.
- Оцінюйте автоматично. Порівнюйте результати з мітками поле за полем за допомогою скрипта, а не на око. Автоматизоване оцінювання робить повторні запуски дешевими, а повторні запуски — це весь сенс.
- Класифікуйте кожну помилку. Побудуйте таксономію помилок, аналізуючи невдачі: галюциновані поля (вигадані значення), переставлені позиції, неправильний постачальник у багатопостачальних виписках, плутанина сум із податком і без, валютні помилки, переосмислення формату дат, пропущені сторінки. Шаблони в таксономії стають вашим списком виправлень — кращі запити, кроки попередньої обробки чи правила валідації.
- Додайте шар валідації та повторіть тест. Найкращі конфігурації поєднують LLM із детермінованими перевірками: чи сходяться позиції до проміжного підсумку? Чи дорівнює проміжний підсумок плюс податок загальній сумі? Чи є постачальник у затвердженому списку? Чи дата в межах відкритого періоду? Вимірюйте точність із цими запобіжниками та без них, щоб побачити, що дає кожен шар.
- Перезапускайте за графіком. Моделі змінюються без вашого відома — постачальники оновлюють ваги, припиняють підтримку версій і непомітно змінюють поведінку. Перезапускайте бенчмарк щомісяця та щоразу, коли змінюєте моделі, запити чи попередню обробку. Бенчмарк, запущений один раз, — це сувенір; бенчмарк, який перезапускають, — це контроль.
Помилки, які змушують бенчмарки брехати
Більшість саморобних оцінок провалюються передбачуваними способами. Уникайте цих п’яти:
Тестування на п’яти чистих рахунках. Крихітний, охайний тестовий набір доводить, що модель вміє читати охайні документи — те, що ви вже знали. Якщо у вашому тестовому наборі немає сканів, рукописного тексту та крайніх випадків, ваш результат 100% вимірює ваш тестовий набір, а не вашу модель.
Дозвіл моделі оцінювати себе. Оцінювання LLM-як-суддя — це зручно і систематично поблажливо, особливо щодо власних результатів моделі. Якщо ви використовуєте автоматизоване суддівство, щоразу вручну перевіряйте вибірку, і використовуйте іншу модель як суддю, ніж та, що тестується.
Оцінювання заголовка й ігнорування позицій. Поля заголовка (постачальник, дата, сума) — це легка частина. Гроші ховаються в позиціях — неправильні кількості, пропущені рядки, неправильно прочитані ціни за одиницю. Бенчмарк, який пропускає позиції, — це аудит конверта, який ігнорує лист.
Плутанина точності OCR із точністю вилучення. Правильно прочитати кожне слово і поставити правильне число в правильне поле — це різні навички. Традиційний OCR може ідеально транскрибувати сторінку, нічого не розуміючи; LLM може розуміти макет, але неправильно читати змазану цифру. Оцінюйте структурований результат, а не транскрипт.
Відсутність порогу впевненості. Не кожен документ заслуговує автоматизації. Професійна модель — це селективне прогнозування: система автоматично проводить високовпевнені вилучення, а низьковпевнені спрямовує людині. Ваш бенчмарк має знайти поріг — рівень впевненості, нижче якого перевірка людиною виявляє більше помилок, ніж коштує. Пропуск цього кроку означає вибір між перевіркою всього (немає економії) і довірою до всього (клуб 62%).
Як виглядає «достатньо добре»
Бенчмарки допомагають лише тоді, коли ви знаєте, що робити з результатом. Думайте категоріями:
- Нижче 85% точності полів: лише режим помічника. Модель створює чернетку, людина перевіряє кожне поле. Це все ще швидше, ніж ручне введення, але не довіряйте нічому.
- 85–95%: автоматизація під наглядом. Автоматично проводьте звичайні документи від відомих постачальників, а все інше — нових постачальників, великі суми, низьковпевнені вилучення — направляйте на перевірку. Це зона, де має працювати більшість малих підприємств.
- Вище 95% із захисними валідаційними механізмами: наскрізна обробка стандартних документів із вибірковими аудитами (перевірка випадкових 5–10% щомісяця) для виявлення дрейфу. Навіть тут дотримуйтеся жорстких правил: жодного автоматичного проведення вище грошового порогу, жодного автоматичного проведення в закриті періоди, жодних нових постачальників без затвердження.
Контекст має величезне значення. Рішення про затвердження рахунків із точністю ШІ 92% можуть перевершувати людей-ревізорів із 72% — але затвердження — це судження з людським резервом, тоді як проведення неправильної суми у ваш реєстр — це тихе пошкодження. Пристосовуйте автономію до оборотності: чим важче скасувати помилку, тим вища планка.
Охайні книги роблять вимірювання можливим
Ось частина, яку постачальники пропускають: ви не можете бенчмаркувати класифікацію витрат без послідовного плану рахунків, і ви не можете оцінювати точність введення даних без звірених книг для порівняння. Еталонний набір, якого потребує ваш бенчмарк, — це, по суті, фрагмент добре ведених книг — послідовно категоризованих, повністю звірених, контрольованих версіями. Підприємства з дисциплінованим веденням книг можуть створити бенчмарк за один вечір; підприємства з трьома місяцями некатегоризованих транзакцій в електронній таблиці не можуть створити його взагалі, бо немає ключа відповідей.
Це працює в обидва боки. Той самий книг у відкритому текстовому форматі, який робить ваші фінанси придатними для аудиту, робить ваш ШІ вимірюваним: кожен рахунок визначено текстом, кожну проводку можна перевірити через diff, кожне виправлення простежуване. Коли модель пропонує класифікацію, ви можете точно побачити, яке правило вона виконала або порушила. А інструменти візуалізації, які перетворюють ваш реєстр на діаграми, роблять помилки моделі — і ваші власні — видимими з першого погляду; дашборд Fava, який постачається з Beancount, перетворює бухгалтерські проводки на подання балансу та витрат, які ви можете переглядати щомісяця. Якщо ви збираєтеся дозволити ШІ торкатися ваших книг, тримайте ці книги у форматі, який ви справді можете інспектувати.
Вимірюйте, перш ніж довіряти
Впровадження ШІ в бухгалтерії — це вже не питання — оскільки майже дев’ять із десяти бухгалтерських фахівців використовують його для роботи з клієнтами, а використання подвоюється щороку в податкових дослідженнях, питання полягає в тому, чи вимірюєте ви те, що він робить для вас. Вихідні, витрачені на створення бенчмарку з 50 документів, купують вам те, що не може жодна демонстрація постачальника: знання реального рівня помилок вашого інструмента, на ваших документах, з вашими правилами — плюс повторюваний контроль, який вловлює дрейф, перш ніж він дійде до ваших клієнтів або вашої податкової декларації.
Почніть з малого: витягніть п’ятдесят рахунків, розмітьте їх вручну, оцініть свій поточний інструмент і класифікуйте, що він робить неправильно. Яким би не було число, його знання ставить вас попереду 60% аудиторських функцій, які запускають ШІ без жодної стратегії. Фірми, які процвітатимуть із бухгалтерським ШІ, будуть не тими, хто довіряв йому найбільше, — а тими, хто виміряв його першими.
Тримайте свої книги з AI-перевіркою у відкритому текстовому форматі
Поки ви бенчмаркуєте та впроваджуєте інструменти ШІ для рахунків-фактур і відстеження витрат, підтримання чітких фінансових записів, які ви можете інспектувати, залишається важливим — ключ відповідей, який ви не можете прочитати, — це взагалі не ключ відповідей. Beancount.io надає бухгалтерію у відкритому текстовому форматі, що дає вам повну прозорість і контроль над вашими фінансовими даними — жодних чорних скриньок, жодної прив’язки до постачальника. Почніть безкоштовно і подивіться, чому розробники та фінансові фахівці переходять на бухгалтерію у відкритому текстовому форматі.
