Інтернет-магазин отримав звіт: витрати різко зросли, частина надходжень зникла, а кілька платежів схожі на дублікати. ШІ називає це аномаліями. Проте за тривожним формулюванням можуть стояти звичайне повернення покупцеві, комісія платіжного сервісу або повторно завантажена виписка. Якщо одразу «виправити» такі записи, можна створити помилку там, де її не було.
Для власника невеликого онлайн-бізнесу корисніше сприймати ШІ як помічника для первинного відбору операцій. Він формує список запитань, але відповіді потрібно шукати в документах. Нижче — порядок перевірки, який допоможе відрізнити незвичну подію від технічної помилки та реальної нестачі коштів.
Що означає сигнал про аномалію — і чому це ще не доказ помилки
Аномалія — це відхилення від певного очікування: звичної суми, частоти платежів, категорії або співвідношення доходів і витрат. Але саме очікування може бути невдалим. Якщо порівняти тиждень розпродажу зі звичайним тижнем, зростання витрат на рекламу виглядатиме підозрілим, хоча бізнес свідомо збільшив бюджет.
Приклад позиціювання фінансового ШІ — NUMEVIA: на https://www.numevia.io/ сервіс заявляє аналіз транзакцій, витрат і доходів, прогнозування та підготовку звітів. Такі можливості доречні для попереднього перегляду незвичних операцій, але опис на сайті не доводить точності їх виявлення. Важливе й обмеження: умови сервісу називають поточну версію демонстрацією інтерфейсу, а результати — не фінансовою порадою. Це не огляд протестованого детектора аномалій.
Розділяйте три речі: що постачальник обіцяє, що інструмент фактично показує і що підтверджують ваші документи. Переконливе пояснення в чаті ще не означає правильного розрахунку. Навіть точне виявлення незвичної суми не встановлює її причину: великий платіж може бути і помилкою, і запланованою річною оплатою.
Чотири причини хибної тривоги: повернення, дублікати, затримки виплат і сезонність
Повернення покупцеві. Продаж відбувся наприкінці місяця, а гроші повернули вже наступного. Якщо аналізувати лише банківські надходження за другий місяць, повернення може виглядати як незрозуміла витрата. Потрібно знайти первинне замовлення, документ про повернення та перевірити, як платіжний провайдер відобразив комісію. Не варто автоматично переносити платіж до іншої категорії лише через мінус перед сумою.
Подвійний імпорт. Один файл містить операції за весь місяць, інший — за останній тиждень того самого місяця. Після об’єднання частина рядків повторюється. ШІ може правильно помітити дублікати у файлі, але помилково пояснити їх подвійним списанням із рахунку. Однакова дата та сума не є достатньою підставою видаляти рядок: у магазині можуть бути кілька справжніх замовлень на однакову суму. Звіряйте ідентифікатор транзакції та джерело запису.
Затримка виплати. Оплачене замовлення, кошти на балансі платіжного сервісу та зарахування на банківський рахунок — різні події. Виплата може об’єднувати багато продажів, містити утримання комісій або перейти на наступний період. Перш ніж називати різницю втратою, перевірте статус виплати, часовий пояс звіту й умови розрахунків конкретного провайдера.
Навчальний приклад: за звітом платіжного сервісу магазин отримав оплат на 60 000 грн. Із них повернуто 4 000 грн, утримано 1 200 грн комісій, а 8 000 грн ще очікують виплати. Тоді очікуване зарахування становить 60 000 − 4 000 − 1 200 − 8 000 = 46 800 грн. Якщо банк показує саме цю суму, різниця з продажами пояснена. Це звіряння руху коштів, а не розрахунок прибутку чи податкового доходу.
Сезонність і разові витрати. Перед святами бізнес закуповує пакування, а цифровий сервіс раз на рік оплачує програмне забезпечення. Порівняння лише із середнім значенням попередніх тижнів створить хибну тривогу. Додайте до аналізу календар акцій, договори та графік регулярних оплат. Незвичність може потребувати пояснення, але не обов’язково виправлення.
Як перевірити підозрілу операцію: від виписки до повторного розрахунку
Почніть не з повторного запиту до ШІ, а зі збереження початкових даних. Залиште оригінальні експорти без змін, а очищення й перерахунки робіть у копії. Зафіксуйте, який файл аналізували, за який період і що саме система назвала підозрілим. Інакше після кількох виправлень буде складно зрозуміти, звідки виникла розбіжність.
- Сформулюйте твердження для перевірки. Не «є проблема з доходом», а «за 12 число у файлі двічі враховано платіж із таким ідентифікатором».
- Знайдіть першоджерело. Для руху грошей це може бути банківська виписка або звіт платіжного сервісу; для змісту операції — замовлення, рахунок, акт чи документ про повернення.
- Узгодьте межі порівняння. Перевірте валюту, часовий пояс, дату операції та дату зарахування, статус платежу, включення комісій і повернень.
- Відтворіть розрахунок незалежно. Порахуйте суму в таблиці або обліковій системі за явними умовами відбору. Повторна відповідь того самого чату не є незалежною перевіркою.
- Запишіть висновок і дію. Наприклад: «дубль лише в аналітичному файлі; прибрати повторний рядок у копії; первинні документи не змінювати».
Такий підхід узгоджується з принципами NIST AI Risk Management Framework — AI RMF Core: надійність ШІ потрібно оцінювати, межі застосування — документувати, а ролі людського нагляду — визначати. Для малого бізнесу практичний висновок простий: має бути зрозуміло, хто перевіряє сигнал і хто дозволяє зміну даних. Це не спеціальна бухгалтерська інструкція, а рамка управління ризиком.
Корисний запит до інструмента: «Назви рядки, на яких ґрунтується висновок, покажи формулу та переліч відсутні дані. Не припускай причину без підтвердження». Якщо сервіс не може вказати джерело числа, позначте пояснення як неперевірене. Для важливого рішення краще залишити питання відкритим, ніж підмінити відсутній документ правдоподібною версією.
Що з’ясувати про пояснення ШІ та захист даних до завантаження документів
Прозорість постачальника й перевірюваність конкретного результату — не те саме. На сторінці https://www.numevia.io/about NUMEVIA заявляє доступ користувачів до інформації про використання ШІ, споживання ресурсів і результати аналізу. Це приклад того, як компанія описує прозорість, але не підтвердження наявності детального журналу розрахунків чи незалежного аудиту. Так само заяви про шифрування та захищену інфраструктуру самі по собі не відповідають на всі питання щодо обробки документів.
Перед роботою з будь-яким сервісом з’ясуйте: чи можна зіставити висновок із рядками джерела, отримати використану формулу та зберегти результат разом із версією файлу. Окремо запитайте, де зберігаються документи, хто має до них доступ, чи використовуються вони для навчання моделей, які строки зберігання та як працює видалення. Якщо відповідей немає, не вважайте їх автоматично сприятливими.
Ризик розкриття фінансових даних і конфіденційної бізнес-інформації розглянуто в розділі LLM02:2025 Sensitive Information Disclosure документа OWASP Top 10 for Large Language Model Applications — 2025. Серед доречних заходів — маскування чутливих полів, мінімально необхідні права доступу та обмеження джерел даних. Самого прохання в промпті «не розголошувати інформацію» недостатньо.
Для первинного тесту підготуйте синтетичний набір або дозволену до використання знеособлену копію: замініть імена, приберіть контакти, реквізити й зайві примітки. Залиште лише поля, потрібні для перевірки. Врахуйте, що поєднання точної суми, дати та опису іноді теж дозволяє впізнати клієнта. Паролі, ключі API та секрети доступу не повинні потрапляти у файл узагалі.
Коли виправляти облік, коли звертатися до бухгалтера, а коли залишити все без змін
Дія залежить від того, де саме підтвердилася помилка. Якщо двічі імпортовано виписку, виправляйте аналітичну копію та правила завантаження. Якщо виплата ще перебуває в обробці й це підтверджує провайдер, призначте дату повторної звірки. Не потрібно змінювати правильний запис лише для того, щоб він перестав відрізнятися від очікування моделі.
Бухгалтера варто залучити, коли питання стосується визнання доходу, податків, валютних різниць, закритого звітного періоду або коригування первинних документів. За непоясненого списання зв’яжіться з банком чи платіжним провайдером через офіційний канал. Підозра на несанкціонований платіж потребує оперативної перевірки, а не очікування нового ШІ-звіту.
Перед завершенням перевірки пройдіть короткий список:
- Є документ або запис у першоджерелі, що підтверджує висновок.
- Період, валюта, статуси та комісії враховані однаково.
- Розрахунок можна повторити без пояснення ШІ.
- Визначено, що саме змінюється і хто це погоджує.
- Якщо дані правильні, причина незвичної операції зафіксована.
Зберігайте також підтверджені хибні сигнали: вони допоможуть уточнити категорії, періоди порівняння та правила імпорту. Корисний результат ШІ — не кількість тривог, а список перевірених винятків із зрозумілим рішенням. Іноді найкраще рішення після перевірки — нічого не змінювати.
