ШІ для бухгалтерії: рахунки, аномалії, обслуговування

Бухгалтерія обслуговує в середньому від кількох до кількох десятків клієнтів. Кожен з них щомісяця надсилає пачки рахунків, банківських виписок та кадрових документів. Бухгалтер витрачає від кількох до кільканадцяти годин на місяць на переписування чисел з документів до системи, пошук розбіжностей та відповіді на повторювані запитання: «Коли термін сплати ЗУС?», «Чи вже надіслали JPK?», «Скільки мені платити ПДФО?».

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

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

OCR у поєднанні з вилученням даних змінює цей процес: система зчитує рахунок (PDF, скан, фото з телефону), розпізнає поля (NIP, дата, сума нетто, ПДВ, номер рахунку) та повертає structured output, готовий до імпорту або перевірки.

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

• Валідація критичних полів: NIP перевіряється в реєстрі ПДВ, номер рахунку — у білому списку, перш ніж будь-який запис потрапить до системи. Помилка тут — це податковий ризик для клієнта.
• Поріг впевненості OCR: коли модель має низьку впевненість щодо зчитаного числа (наприклад, ручна корекція на рахунку), справа потрапляє до черги на ручну обробку замість автоматичного імпорту.
• Human-gate при імпорті: жоден запис до бухгалтерської системи не створюється автоматично без підтвердження бухгалтером. ШІ пропонує, людина затверджує.

Час обробки одного рахунку зазвичай скорочується з 2-4 хвилин вручну до 15-30 секунд перевірки. При 500 рахунках на місяць це кільканадцять годин роботи, повернутих без зміни архітектури ERP-системи.

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

Приклади застосування:

• Аномалії у витратах: сума в категорії «послуги сторонніх» зросла на 60% місяць до місяця без змін у замовленнях. Це може бути пропущений дублікат рахунку або реальна зміна, яку варто обговорити з клієнтом.
• Невідповідності ПДВ: ставка ПДВ не збігається з категорією товару згідно з базою PKWiU. Система позначає документ для перевірки перед поданням декларації.
• Прострочені платежі: система відстежує терміни погашення зобов'язань і генерує пріоритетний список для клієнта заздалегідь, замість інформування після терміну.
• Дублікати рахунків: той самий NIP постачальника, та сама сума, інші номери документів. Перед імпортом система запитує: «Це дублікат?»

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

Кожна бухгалтерія щомісяця відповідає на ті самі запитання. Терміни ЗУС, ПДФО, JPK, статуси розрахунків, запитання щодо конкретних рахунків. Асистент на базі RAG, підключений до даних клієнта, може відповідати на значну частину цих запитань без залучення бухгалтера.

Схема роботи:

1. Клієнт пише через форму, чат або електронну пошту: «Коли мені платити ЗУС цього місяця?»
2. Система класифікує намір: запитання про термін (→ RAG + календар), запитання про суму (→ RAG + останній розрахунок), запитання про статус документа (→ база документів клієнта), запитання, що потребує інтерпретації (→ ескалація до бухгалтера).
3. RAG шукає в індексі: документи клієнта, законодавчі терміни, листування. Відповідь формулюється з цитуванням джерела.
4. Якщо запитання виходить за межі системи або впевненість низька, асистент прямо каже: «Запитайте підтвердження у свого бухгалтера» та ескалує.

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

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

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

Бухгалтерія обробляє конфіденційні дані: номери NIP, доходи, зарплати, персональні дані працівників клієнтів. Професійна таємниця накладає тут додаткові зобов'язання понад стандартне RODO.

Чотири технічні вимоги, які мають бути виконані перед запуском будь-якої системи ШІ:

• PII masking локально: імена, номери PESEL, номери рахунків маскуються або токенізуються до того, як щось залишить інфраструктуру бухгалтерії. Хмарна модель бачить токени, а не персональні дані.
• Self-hosting для фінансових даних: повні фінансові документи та історія транзакцій не повинні потрапляти до зовнішніх API. Локальні моделі inference (Ollama або сервер on-premise) для рівня аналізу документів — стандарт для бухгалтерій з клієнтами з регульованих секторів.
• Окремі індекси на клієнта: кожен клієнт має власний ізольований індекс у векторній базі. Відсутність ізоляції — ризик витоку даних між клієнтами через cross-query.
• Лог кожної операції: що система зчитала, що запропонувала, хто затвердив. Аудит має бути можливим ретроспективно протягом мінімум 5 років згідно з вимогами бухгалтерського обліку.

Якщо клієнти бухгалтерії — це компанії з фінансового, медичного або державного секторів, слід провести DPIA перед впровадженням. Деталі вимог RODO та AI Act розглядає стаття AI Act і RODO 2026.

Ефективність системи ШІ залежить від якості інтеграції з ERP. У польських бухгалтеріях домінують кілька систем, кожна з різними можливостями експорту та API.

Найпоширеніші патерни інтеграції:

• Імпорт через файл: система ШІ генерує файл XML або CSV, готовий до імпорту в Optimу, Symfoniю або Wapro. Найпростіший спосіб, не потребує доступу до API, але імпорт завжди підтверджується бухгалтером вручну.
• API ERP: прямий запис після затвердження людиною. Швидший потік, потребує налаштування та end-to-end тестів на тестовому середовищі перед стартом.
• n8n як шар оркестрації: n8n з'єднує поштову скриньку (отримання рахунків), систему OCR, валідацію та імпорт до ERP в один потік з логуванням кожного кроку. Підходить особливо, коли бухгалтерія має гетерогенне середовище кількох різних систем у різних клієнтів.

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

Вартість пілоту залежить від обсягу та кількості документів. Для бухгалтерії з 400-800 рахунками на місяць і одним рівнем (OCR або асистент FAQ) пілот зазвичай триває кілька тижнів. Точні цифри залежать від технічного середовища та рівня інтеграції. Калькулятор ROI дозволяє ввести реальні години, ставку та обсяг і отримати термін окупності без «на око».

Три метрики, які показують, чи працює пілот:

• Час обробки документа: скільки хвилин від отримання рахунку до готової пропозиції в системі. Базовий показник, виміряний вручну до старту, є обов'язковим.
• Показник втручання: відсоток документів, де система помилково розпізнала критичне поле (сума, NIP, дата). Має знизитися нижче 2% протягом першого місяця на типових документах.
• Час відповіді асистента: медіана та p95 від запитання клієнта до відповіді асистента. Ціль — менше 5 секунд для запитань з індексу.

При обсязі понад 500 рахунків на місяць автоматизація OCR зазвичай окупається за 3-6 місяців. При меншому обсязі термін окупності довший, але часто впровадження все одно має сенс через зменшення помилок, а не лише економію часу.

Опишіть ваш поточний потік документів та найчастіші запитання клієнтів, а модель вкаже, які рівні ШІ мають найбільший потенціал у вашій бухгалтерії (playground: PII маскуються, нульова ретенція):

Не повинен без human-gate. ШІ може підготувати пропозицію імпорту з усіма заповненими полями, але затвердження кожної фінансової операції має належати бухгалтеру. Фінансові дані в ERP-системі є основою податкових розрахунків клієнта, тому помилка автоматичного імпорту може мати правові наслідки. Патерн такий: ШІ пропонує, людина перевіряє одним кліком затвердження або відхилення.

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

Так, сучасні системи OCR з шаром візуальної моделі справляються з цифровим PDF, сканом та фото з телефону. Якість залежить від роздільної здатності та читабельності документа. Ручні виправлення на друкованих примірниках знижують впевненість системи, тому патерн завжди однаковий: низька впевненість = черга на ручну обробку замість автоматичного імпорту. Перевірте оцінку готовності, щоб з'ясувати, чи відповідають ваші документи мінімальним вимогам.

Не справляється і не повинен намагатися. Асистент RAG відповідає на фактичні запитання (терміни, статуси, суми з документів) та ескалує запитання, що потребують інтерпретації, до бухгалтера. Обсяг чітко визначений через guardrails, а асистент прямо інформує клієнта, коли передає справу людині. Це не обмеження системи, а цілеспрямоване проектне рішення, що випливає з професійної відповідальності бухгалтерії.

З вимірювання, де витрачається найбільше часу. Якщо це рахунки — почніть з OCR з валідацією. Якщо це повторювані запитання клієнтів — почніть з асистента RAG на базі термінів та FAQ. Впроваджуйте один обсяг за раз, вимірюйте результати протягом 4-6 тижнів, потім вирішуйте про розширення. Повний посібник з чого почати впровадження ШІ розглядає методологію крок за кроком незалежно від галузі.