Как проверить 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 для Польши. Названия польских регистров сверяйте с документами, а не с привычными терминами другой страны.

Как принять решение после пяти тестов?

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

Для дальнейшего сравнения выбирайте программу, в которой понимаете результат и можете исправить неверное предложение. Перед переходом согласуйте с текущим бухгалтером дату границы учёта, состав переносимых данных и проверку первого периода. Если невозможно восстановить источник суммы или найти нерешённое исключение, сначала разберитесь с этим ограничением. Скорость демонстрации имеет смысл оценивать после того, как понятны результат, контроль и исправление ошибок.