ШІ для контролінгу та фінансів: OCR, аналіз витрат і закриття місяця 2026

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

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

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

Чисті друковані рахунки, прямо з ERP-системи постачальника: точність екстракції критичних полів (номер рахунку, ІПН, сума без ПДВ, сума ПДВ, дата, термін оплати) зазвичай становить 97–99 відсотків при використанні сучасних візуальних моделей. Рахунки, відскановані з матричних принтерів, фото з телефону, документи після кількох копій на ксероксі: точність падає до діапазону 85–95 відсотків, а при найгірших сканах може бути нижчою.

Це не архітектурний недолік, це фізика документів. Правильна відповідь на це обмеження — не твердження, що «ШІ впорається», а проектування ручної черги: документи з впевненістю екстракції нижче порогу (наприклад, нижче 0,92 за ключове поле) потрапляють до контролера, перш ніж потраплять до будь-якого реєстру.

Екстракція даних з рахунків — це завдання, в якому structured output (модель, що повертає JSON з полями та рівнем впевненості за кожне поле) є стандартом, а не опцією. Валідація схеми (ІПН — 10 цифр, сума — невід’ємна, дата у форматі ISO) відбувається перед записом до бази. Невідповідності надходять до черги, а не тихо пропускаються далі.

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

ШІ класифікатор навчається на історії затверджень: пара (контрагент, опис позиції рахунку) до (витратний рахунок) — це тренувальний сигнал. Після 3–6 місяців історії модель правильно класифікує 75–90 відсотків рахунків від відомих контрагентів при стабільному плані рахунків. Нові контрагенти, нестандартні описи та зміни плану рахунків знижують впевненість і потрапляють на ручний перегляд.

Ключовий момент: модель не проводить самостійно. Пропонує рахунок з рівнем впевненості та коротким обґрунтуванням (наприклад, «попередні 14 рахунків від цього постачальника потрапили на рахунок 4010-03, канцтовари»). Контролер затверджує одним кліком або коригує. Коригування повертається як тренувальний сигнал.

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

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

Аналіз відхилень за допомогою ШІ працює у двох режимах:

Статистичний режим. Модель time-series (наприклад, Prophet або проста лінійна модель на сезонних патернах) порівнює витрати в поточному місяці з очікуваним значенням на основі історії та бюджету. Відхилення вище встановленого порогу (наприклад, понад 8 відсотків і понад 5 000 грн одночасно) автоматично фіксуються з приміткою: рахунок, сума відхилення, напрямок (перевищення/економія) та порівняння рік до року.

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

Хибні спрацьовування (false positives) мають свою ціну: контролер перевіряє флаг і нічого не знаходить. За нашими спостереженнями, при добре відкаліброваному порозі вдається утримувати рівень хибних спрацьовувань нижче 15 відсотків усіх флагів. Занадто чутливий поріг призводить до втоми від сповіщень, через яку реальні відхилення ігноруються. Калібрування порогу — це постійне завдання, а не разова дія.

Стаття ШІ для виявлення шахрайства розглядає архітектуру виявлення фінансових аномалій ширше, в контексті транзакцій і платежів.

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

ШІ може скоротити цей час на 50–70 відсотків, згенерувавши чернетку на основі даних. Чернетка — це не готовий звіт. Це перша версія структури з даними, вставленими у відповідні місця:

• Розділ доходів: фактичні vs план, відхилення у відсотках, топ-3 категорії продуктів з найбільшим впливом.
• Розділ витрат: відхилення вище порогу, виявлені причини (гіпотези з контекстного аналізу), категорії без пояснень.
• Розділ cash flow: порівняння з попереднім місяцем, ключові позиції.
• Прогноз: екстраполяція на основі поточного виконання та графіка.

Контролер читає чернетку, перевіряє кожне число (узгодження з обліком є обов’язковим перед відправкою), коригує наратив і додає контекстну інформацію, якої немає у моделі: дані про новий контракт, зміну ціни сировини, разову подію.

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

Фінансові дані рідко бувають анонімними. Рахунки містять ІПН (який може ідентифікувати фізичну особу-підприємця), ім’я та прізвище власника компанії, адресу. Звіти про витрати на працівника — це персональні дані в розумінні RODO. Розрахункові відомості в пайплайнах ШІ — особливо чутлива область.

Три принципи, які діють при будь-якому впровадженні ШІ в контролінгу:

По-перше: персональні дані маскуються перед передачею до зовнішньої моделі. ІПН фізичної особи, ім’я та прізвище в рахунку, дані з розрахункової відомості токенізуються на рівні інжекції. Модель бачить ідентифікатор, а не дані. Детокенізація відбувається на стороні застосунку.

По-друге: системи ШІ, що класифікують витрати за працівником або генерують рейтинги ефективності підрозділів, можуть кваліфікуватися як системи високого ризику згідно з Додатком III AI Act. Така система потребує оцінки DPIA та формального нагляду людини за кожним рішенням, що впливає на особу.

По-третє: self-hosting моделі є стандартом для даних, що підпадають під фінансову таємницю, NDA або зобов’язання конфіденційності за договорами. Немає винятку «довіреного хмарного постачальника», який звільнив би від обов’язку оцінки ризику.

Стаття ШІ для аналізу документів детально розглядає патерн маскування PII та ізоляції індексів за проектом.

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

Human-oversight при затвердженні для звітності — це не надмірна обережність. Це вимога аудиту. Аудитор запитує, хто затвердив число. «Затвердила модель» — це відповідь, яка не відповідає жодному стандарту внутрішнього контролю.

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

Стаття ШІ для аналізу даних і BI описує архітектуру шару NL2SQL та семантичного, який добре доповнює контролінговий пайплайн з боку ad hoc аналізу. Цілісний підхід до впровадження разом з кошторисом описує стаття як виміряти ROI від ШІ, а управління вхідними даними для системи розглядає governance даних для ШІ.

Для чистих друкованих рахунків (цифровий PDF або якісний лазерний друк) сучасні візуальні моделі досягають 97–99 відсотків точності за критичними полями: ІПН, сума, дата, номер рахунку. Для сканів низької якості, старих матричних принтерів або фото з телефону точність падає до діапазону 85–95 відсотків, а при вкрай поганих документах — нижче. Правильною відповіддю на цю варіативність є черга ручної перевірки для документів з впевненістю нижче встановленого порогу, а не твердження, що OCR завжди працює добре.

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

Ціна одного хибного спрацьовування — це час контролера на перевірку флагу, зазвичай 10–30 хвилин. При 20 флагах на місяць і рівні хибних спрацьовувань 30 відсотків — це 6 непотрібних перевірок, тобто від години до трьох втраченого часу. Занадто чутливий поріг нівелює вигоду від автоматизації. Калібрування порогу на історичних даних за кілька місяців зазвичай дозволяє знизити рівень хибних спрацьовувань до менш ніж 15 відсотків, що робить систему реально корисною.

Це залежить від характеру даних та угод. Неперсональні, агреговані дані без комерційної таємниці: при відповідній угоді доручення (ст. 28 RODO) та оцінці ризику можна використовувати зовнішні API. Дані, що містять інформацію під фінансовою таємницею, NDA або персональні дані працівників і контрагентів: стандарт — це self-hosting моделі або принаймні маскування PII перед відправкою до зовнішнього API з документацією правової основи обробки. Немає єдиної відповіді для всіх компаній, проте є обов’язок провести цю оцінку перед запуском.

Пілот, що охоплює екстракцію рахунків від однієї категорії постачальників та автоматичну пропозицію класифікації витрат: 4–8 тижнів за умови доступу до 3–6 місяців історії затверджень як тренувальних даних. Повний обсяг з аналізом відхилень, чернеткою коментаря та інтеграцією з ERP: 3–5 місяців, залежно від стану даних та кількості інтегрованих систем. Переважна більшість часу в такому проекті — це робота з даними та визначення бізнес-правил, а не налаштування моделі.