Як перевірити AI-бухгалтерію в Польщі: пʼять тестів для JDG

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

Нижче наведено сценарій самостійної перевірки програми для бізнесу в Польщі. Це не рейтинг сервісів і не результати вимірювання точності Norman. Суми у прикладі вигадані й потрібні лише для перевірки звʼязку між фактурою та платежами. Польські поняття й документи зберігають своє значення незалежно від мови інтерфейсу.

Що саме перевіряти в AI-бухгалтерії?

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

У цій статті AI-first описує порядок роботи, коли ви починаєте із запитання або документа, а система готує наступні кроки. Сама назва не підтверджує правильність обліку. Набагато корисніше перевірити, чи можна перейти від відповіді до першоджерела, побачити відсутні відомості та змінити пропозицію.

Переконайтеся, що обрано сценарій саме вашого бізнесу. JDG і sp. z o.o. не повинні отримувати однакові бухгалтерські вказівки лише тому, що завантажили ту саму фактуру. Для JDG уточніть форму оподаткування, статус VAT і відповідний реєстр. Якщо ще обираєте форму бізнесу, почніть із порівняння JDG та sp. z o.o..

Як підготувати документи й очікувані результати?

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

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

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

Тест 1: чи збігаються поля з оригіналом фактури?

Почніть із добре читабельної фактури у злотих за типову покупку вашого бізнесу. Порівняйте постачальника, NIP, номер, дати, валюту й суми netto, VAT і brutto. Якщо документ містить кілька ставок VAT, перевірте кожну позицію окремо. Правильний загальний підсумок не виключає помилки в окремих рядках.

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

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

Тест 2: що відбувається з дублікатом із KSeF та PDF?

Попросіть показати ситуацію, коли одна фактура надходить через KSeF і повторно у PDF від постачальника. Використайте саме один документ, а не дві схожі фактури з однаковою сумою. Очікуваний результат: одна господарська операція зі зрозумілими джерелами.

За описом Міністерства фінансів Польщі, структурована фактура має формат XML. Її дані не потрібно зчитувати з фотографії. Проте варто перевірити, як програма обробляє додатковий файл, показує звʼязок і запобігає повторному запису в обліку.

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

Тест 3: чи залишається часткова оплата частковою?

Контрольний приклад: фактура становить 1 230 zł, а повʼязаний платіж становить 600 zł. Якщо інших платежів, взаємозаліків і коригувань немає, залишається 630 zł. Ви повинні мати змогу повторити цей розрахунок і відкрити конкретну банківську операцію.

Перевірте, чи не стала фактура повністю оплаченою лише через збіг контрагента та частини призначення переказу. Потім покажіть другий платіж на 630 zł. Після правильного зіставлення непогашений залишок має становити нуль. Перегляньте не лише статус документа, а й перелік повʼязаних платежів.

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

Тест 4: чи видно відсутній контекст?

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

Запитайте: «На чому ґрунтується ця категорія та яких відомостей бракує?». Корисна відповідь вказує на документ і конкретні прогалини. Упевненого тону без джерела недостатньо. Якщо система наводить норму права, відкрийте офіційне джерело й перевірте, чи застосовна вона до вашої ситуації.

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

Тест 5: чи зберігається звʼязок коригування з оригіналом?

Використайте готову пару документів: фактуру та faktura korygująca. Перевірте, що обидві доступні, звʼязок між ними зрозумілий, а зміну вартості можна перевірити. Якщо система не визначила звʼязок, має бути можливість зʼясувати його без втрати історії. Попросіть показати початкову й змінену суми поруч.

Міністерство фінансів пояснює, що виставлену в KSeF фактуру не можна редагувати чи видаляти. Помилку виправляють коригувальною фактурою. Зміна локальної бухгалтерської категорії стосується іншої дії та не змінює вже виставленого документа.

Не припускайте, що кожне коригування належить до періоду початкової фактури. Тут перевіряється прозорість звʼязків; правильний період обліку потрібно підтвердити з огляду на причину коригування. Результат має бути доступний для перегляду до закриття звітного періоду, щоб помилка не виявилася лише в готовій звітності.

Із чого почати перевірку в Norman?

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

Не сприймайте позначку про завершення операції як гарантію відсутності попередніх записів у реєстрах. Інструкція Norman пояснює: операція може потрапити до KPiR та JPK_V7 до цієї позначки, яка слугує вашій перевірці. Тому переглядайте сам реєстр разом зі статусом завдання.

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

Як ухвалити рішення після пʼяти тестів?

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

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