Финансовые отчёты с ИИ: проверка возвратом
Финансовые отчёты с ИИ должны допускать проверку расчёта. Пример Norman показывает, как возвраты, итоговые строки и формат CSV влияют на понимание суммы.
- Категория
- Общее
- Обновлено
- Автор
- Stan Kharlap
Вы спрашиваете ИИ-ассистента, сколько потратили на офисные принадлежности. Была покупка на 500 € и возврат на 200 €. В ответ приходит аккуратная таблица, короткое объяснение и число, выделенное жирным. Прежде чем читать объяснение, посмотрите на это число. Там 300 € или 700 €?
Финансовые отчёты с ИИ должны позволять воспроизвести расчёт. Уверенное объяснение не спасает сумму, в которой возврат прибавили к первоначальному расходу. Я хочу изменить один входной параметр, заранее назвать ожидаемый эффект и увидеть именно его в отчёте и выгруженном файле.
Этот тест полезен именно своей простотой. Для понимания правильного ответа не нужен сложный дашборд. При этом система должна сохранить несколько вещей, которые легко теряются в обычном списке сумм: сторону учёта, смысл возврата и связь между итогом и его составляющими. Если убрать эту информацию, числа останутся знакомыми, а вопрос, на который отвечает их сумма, изменится.
Что должен выдавать финансовый отчёт с ИИ?
22 сентября 2026 года Accrual представила Arc: результаты работы для проверки, включая книги Excel и отчёты для клиентов. Источник: Accrual. 15 сентября Workiva представила Agent Studio для создания ИИ-агентов с использованием знаний компании и контролируемых процессов. Источник: Workiva.
Я читаю эти анонсы так: полезный результат работы выходит за рамки сообщения в чате. Человеку предлагают проверить документ, который затем будет использоваться в другом процессе. Отсюда простой вопрос: что остаётся рядом с числом, когда самого разговора уже нет?
Как минимум мне нужны период, валюта, правила расчёта и возможность посмотреть, из чего сложился результат. Фраза о снижении расходов мало помогает, если в выгруженном файле невозможно понять, какие именно расходы имеются в виду. Хорошее объяснение должно выдерживать такую передачу между людьми и инструментами.
В статье об ИИ-агенте для бухгалтерии мы разбирали весь процесс. Здесь возьмём небольшой фрагмент: детерминированный расчёт под отчётом в бухгалтерском продукте с ИИ. Мы локально запустили расчётные функции Norman и форматирование CSV на вымышленных данных. Это не демонстрация того, как ИИ создаёт книгу Excel.
Как отчёт с ИИ должен учитывать возврат?
Начнём с одной категории расходов. Запишем туда покупку на 500 €, а затем возврат 200 € от этой покупки. Для примера НДС равен нулю, доля делового использования составляет 100 %. Эти условия позволяют проверить именно возврат и не смешивать несколько бухгалтерских вопросов в одном результате.
Локальный прогон использует неизменённые расчётные функции, извлечённые из кода отчётности Norman. Расчёт берёт величину суммы без знака, учитывает сторону учёта и меняет вклад на противоположный для возврата. Получается расход 300 €. Без возврата та же функция выдаёт 500 €, а при полном возврате 500 € результат становится нулевым.
| Вымышленный случай | Покупка | Возврат | Чистый расход | Сумма модулей |
|---|---|---|---|---|
| Без возврата | 500 € | 0 € | 500 € | 500 € |
| Частичный возврат | 500 € | 200 € | 300 € | 700 € |
| Полный возврат | 500 € | 500 € | 0 € | 1 000 € |
Последняя колонка намеренно показывает неправильный способ расчёта. Это не измеренный ответ модели и не заявление о старой ошибке Norman. Она объясняет, почему на первый взгляд разумное действие, убрать знаки и сложить числа, проваливает этот конкретный тест.
Категорию мы задали заранее. Поэтому эксперимент ничего не говорит о том, правильно ли модель классифицировала бы покупку. Такое разделение упрощает поиск проблемы: сначала определяем ожидаемый расчёт, затем отдельно проверяем, передаёт ли система правильные входные данные. Иначе неверную классификацию легко принять за ошибку арифметики или наоборот.
Почему одного знака суммы недостаточно?
Положительное число легко принять за доход, если представлять данные как простой список банковских движений. Но сохранённая сумма транзакции и её сторона учёта являются разными сведениями. Возврат поставщика в нашем примере относится к расходу. Если считать любой положительный знак выручкой, ответ будет уже на другой вопрос.
Для такого теста есть практическое основание. Агрегатная проверка активных записей транзакций в проде Norman обнаружила несколько сотен записей без отметки возврата, у которых знак сохранённой суммы отличался от стороны учёта. Проверка охватывала девяносто дней по дате валютирования до 28 сентября 2026 года. Мы получили только количества, без отдельных операций и их описаний.
Это наблюдение о представлении данных при хранении. Оно не означает такое же количество неправильных отчётов и не объясняет, почему записи имеют именно этот вид. Кроме того, проверенная совокупность отличается от более узкой выборки деловых операций, которую использует конкретный отчёт.
В локальном прогоне положительная сохранённая сумма 500 € со стороной учёта «расход» по-прежнему даёт расход 500 €. Именно это поведение мы можем показать. Агрегат из прода объясняет, зачем его проверять. Он не превращает вымышленный пример в измерение точности продукта на реальных счетах.
Можно ли посчитать итоговую строку дважды?
Теперь добавим в отчёт две составляющие операционных расходов: аренду 400 € и офисные расходы 300 € после возврата. Вместе получается 700 €. Если раскрыть подробности, на экране одновременно могут оказаться все три числа.
Сложите каждый видимый денежный показатель и получите 1 400 €. С самой операцией сложения всё нормально. Ошибка возникла раньше: итог и его составляющие приняли за независимые расходы. Человек может сделать это в электронной таблице, а агент при обратном превращении отображённого отчёта в данные.
В CSV Norman строки верхнего уровня имеют отметку ноль, а детализация операционных расходов имеет отметку один. Так экспорт сохраняет полезную связь между строками. Но отсюда не следует, что можно безопасно сложить вообще все строки нулевого уровня: полный отчёт содержит и расчётные промежуточные итоги, и результаты.
В нашем тесте правило уже и понятнее: составляющие операционных расходов дают родительскую сумму 700 €, а сама сумма учитывается один раз. Похожую разницу мы разбирали в статье об оценках сопоставления транзакций. Число полезно только тогда, когда понятно, что именно оно обозначает.
Должен ли CSV совпадать с экраном?
В изученном коде экран отчёта Norman, экспорт CSV и экспорт PDF используют общую функцию подготовки строк. Поэтому значения имеют общий источник, хотя оформление может отличаться. Это также позволяет в одном месте проверить связь между итогом 700 € и его составляющими.
Мы передали вымышленный отчёт настоящим функциям формирования CSV. Английский числовой формат записывает 700.00 и разделяет поля запятыми. Немецкий формат записывает 700,00, а поля разделяет точкой с запятой. Оба варианта представляют одну и ту же сумму.
Можно посмотреть CSV с английским числовым форматом и CSV с немецким форматом. В обоих файлах подписи учебного примера оставлены на английском. Это результаты локального прогона, а не выгрузка из клиентского аккаунта. Мы проверили значения ячеек и разделители, но не открытие в конкретном табличном редакторе.
Формат заслуживает отдельного теста, потому что файл тоже служит интерфейсом. После скачивания объясняющего чата рядом может уже не оказаться. Период, валюта и смысл строк должны пережить эту передачу. В статье о результатах инструментов ИИ-агента мы обсуждаем ту же проблему при обмене данными между инструментами.
Что проверить, прежде чем доверять отчёту?
Запишите ожидаемый ответ до того, как попросите систему его получить. Начните с трёх случаев возврата выше, затем добавьте итог с детализацией. Оставьте исходные записи неизменными и переключите формат экспорта. Сумма должна сохраниться, даже если её запись выглядит иначе.
Затем проверьте границы, которые оставляет открытыми этот небольшой эксперимент: выбор категории, отсутствующие суммы, фильтры дат, пересчёт валют и старые записи возвратов. Ноль, полученный из известных входных данных, отличается от ответа, при котором исходного значения не было. Интерфейс должен позволять увидеть эту разницу, а не заставлять угадывать смысл пустой ячейки.
Это рекомендации по оценке системы, а не утверждение, что мы проверили всё приложение. Прогон не вызывает модель, не запускает полный метод получения отчёта и не измеряет точность бухгалтерии. Его ценность в том, что показанную арифметику и ячейки файла можно проверить независимо.
Я бы начинал проверку финансового отчёта с ИИ именно здесь: одна покупка, один возврат, один итог. Проследите их до выгруженного файла. Если система не сохраняет их смысл на таком коротком пути, длинное объяснение не сделает результат убедительнее.
Частые вопросы
- Как проверить финансовый отчёт с ИИ?
- Начните с небольшого набора данных, результат для которого можете рассчитать самостоятельно. Зафиксируйте период, валюту и правила отбора. Проверьте покупку, частичный и полный возврат, затем итоговую строку с её составляющими. Сравните расчёт с ячейками экспортированного файла. Такая проверка оценивает конкретное поведение системы, а не точность всей бухгалтерии.
- Должен ли возврат уменьшать расходы в отчёте ИИ?
- В вымышленном примере из статьи покупка на 500 € и возврат от поставщика на 200 € дают чистый расход 300 €. Категория расхода задана заранее, НДС равен нулю, использование полностью деловое. Отчёт должен сохранять смысл возврата. Сам по себе положительный знак сохранённой суммы ещё не означает, что операция относится к выручке.
- Почему сумма в CSV отличается от финансового отчёта?
- Одна из возможных причин состоит в сложении итога и уже включённых в него подробных строк. Другая связана с неверным чтением десятичного разделителя или границ столбцов. Наш локальный пример проверяет итог расходов 700 € и составляющие 400 € и 300 € в двух форматах CSV. Импорт в конкретный табличный редактор этот тест не проверяет.
Norman берет операционную финансовую работу на себя
От invoicing до bookkeeping: Norman организует повторяющиеся финансовые процессы так, чтобы вы успевали к дедлайнам с меньшим объемом ручной работы.