Соответствует ли ИИ-бухгалтерия GoBD? Проверьте протокол

Если в 2027 году налоговый проверяющий откроет ваш протокол изменений и увидит, что категория расхода была задана в 03:14 в воскресенье, он не станет спрашивать, имел ли право это сделать ИИ. Он спросит, кто это сделал. И большинство бухгалтерских систем, включая нашу до недавнего времени, ответить не могут.

В этом и состоит вся проблема соответствия ИИ-бухгалтерии в Германии, и она значительно уже и решаемее, чем следует из дискуссии. GoBD не запрещают автоматические проводки. Никогда не запрещали. Требуется, чтобы каждая налогово значимая запись была прослеживаема до своего источника и неизменяема после факта. Модель, отнёсшая ваш чек за кофе на неверный счёт, это бухгалтерская ошибка. Модель, которая отнесла его и не оставила следа того, что вообще что-то решала, это проблема GoBD.

Соответствует ли ИИ-бухгалтерия GoBD?

Может соответствовать, и требования не изменились из-за появления ИИ. Соответствие GoBD опирается на те же принципы, что и всегда: прослеживаемость (Nachvollziehbarkeit), неизменяемость (Unveränderbarkeit), своевременность проводки, принцип первичного документа и письменное описание процесса (Verfahrensdokumentation). Ни одно из этих требований не интересуется тем, человек или модель предложили категорию. Все они интересуются тем, что решение и любое последующее его изменение зафиксированы и не могут быть тихо перезаписаны.

Практическая проверка любого ИИ-инструмента для бухгалтерии, таким образом, не в надписи «соответствует GoBD» на странице тарифов. Это три вопроса, которые можно задать протоколу изменений:

1. Появляется ли вообще строка в протоколе, когда автоматизация что-то проводит?
2. Обозначает ли эта строка автоматизацию как субъекта действия, отличимого от владельца аккаунта?
3. Можно ли после сдачи или экспорта периода что-то отредактировать напрямую вместо исправления обратной проводкой?

Мы построили механику GoBD для своей бухгалтерии, и когда я задал эти три вопроса нашим производственным данным, третий мы прошли, а первые два нет. К этому я вернусь.

Что на самом деле требует EU AI Act и что только что сдвинули

Если вы ждали, что AI Act скажет вам, что протоколировать, перестаньте ждать. В этом году произошло два события.

Во-первых, 7 мая 2026 года законодатели ЕС достигли предварительного политического согласия отложить обязанности для систем высокого риска в рамках Digital Omnibus. Обязанности, которые применялись бы с 2 августа 2026 года к автономным системам высокого риска по Приложению III, включая обязанность автоматического ведения записей в статье 12, теперь применяются с 2 декабря 2027 года. ИИ, встроенный в регулируемые продукты по Приложению I, сдвигается на 2 августа 2028 года.

Во-вторых, 2 августа 2026 года всё равно наступило, потому что обязанности по прозрачности из статьи 50 остались в исходном графике. Это обязанности по раскрытию: сообщать людям, что они взаимодействуют с системой ИИ, маркировать синтетический контент. Это не обязанности по протоколированию.

И третий момент обычно теряется. Бухгалтерия и налоговая категоризация не входят в Приложение III. Этот список охватывает биометрию, критическую инфраструктуру, образование, занятость, базовые услуги, правоохранительную деятельность, миграцию и правосудие. Оценка кредитоспособности там есть, а решение о том, является ли покупка ноутбука деловым расходом, нет. То есть для подавляющего большинства бухгалтерской автоматизации статья о протоколировании и так не срабатывала, а там, где сработала бы, она теперь отложена.

Моё мнение, и оно опровержимо: для немецкой бухгалтерии AI Act это отвлечение. Обязывающий свод правил это налоговое предписание 2019 года, переизданное с действием с 1 апреля 2024 года, которое применяется к любому предприятию независимо от категории риска, не имеет переходного периода и обеспечивается людьми, приезжающими в ваш офис.

Что требуют GoBD, а EU AI Act нет

Перечитайте строку про неизменяемость. Это единственное, чего не требует ни один свод правил об ИИ и что предполагает каждая немецкая налоговая проверка. Это же и самое сложное в реализации, потому что противоречит любому инстинкту продуктовой команды позволять пользователям исправлять свои данные.

Столбец, которого не было в нашем протоколе

Мы построили механику GoBD в апреле. Транзакция несёт поле is_locked, описанное в коде как «GoBD locked (immutable)», и record_hash, SHA-256 по двенадцати полям, определяющим проводку: сумма, дата операции, ставка и сумма НДС, направление платежа, категория, страна поставщика, reverse charge, тип операции, описание. Попытка снять верификацию с заблокированной транзакции вызывает ошибку с указанием сделать сторнирующую проводку. Есть модель AuditLog, в докстринге которой прямо говорится о GoBD-совместимом протоколе изменений и которая фиксирует создание, изменение, удаление, верификацию и экспорт с построчным сравнением старого и нового значения, а также пользователя и IP-адрес.

Затем я прогнал три вопроса по продакшену. Четыре месяца строк протокола, около двухсот тысяч.

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

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

Остальные решены памятью компании, детерминированным поиском по контрагентам, которых это предприятие исправляло минимум дважды, либо моделью. Оба варианта бухгалтерски оправданы. Ни один из них потом не отличим по самой записи.

Форма этого сбоя мне кажется поучительной. Протокол изменений добросовестно фиксирует, как человек исправляет машину, и ничего не говорит об исходном решении машины. Это ровно противоположно тому, что значит прослеживаемость.

Что мы сделали не так: верифицировано не значит неизменяемо

Разбор короткий и слегка неловкий.

Наша первая попытка неизменяемости блокировала транзакцию, когда пользователь её верифицировал. Звучало правильно: пользователь подтвердил проводку, значит запечатываем. Это было неверно сразу в двух направлениях. Верификация это рабочий шаг, который пользователи делают мимоходом и часто отменяют, поэтому блокировка при верификации ломала обычное редактирование. И она не соответствует ничему, что интересует GoBD, потому что юридически значим момент, когда цифры покидают вашу систему в отчёт или экспорт, а не момент, когда кто-то поставил галочку.

Поэтому более поздняя миграция разблокировала все верифицированные транзакции с примечанием, что is_locked следует ставить только явно, например после экспорта в DATEV. Диагноз верный. Только в нынешнем коде метод, который его ставит, никто не вызывает. У lock() есть читатели: команда проверки целостности, защитные проверки, отказывающие в удалении документа у заблокированной транзакции, но нет вызывающей стороны. Во всей производственной базе не заблокировано ни одной транзакции. Путь исправления только через сторно, то есть та часть, которая собственно реализует Unveränderbarkeit, не выполнялся ни разу.

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

Проблема субъекта имеет ту же форму. Протокол изменений, построенный вокруг запроса вошедшего в систему человека, имеет один столбец субъекта, потому что субъект всегда был одного рода. Решение не хитрое. Это второй столбец, заполняемый на каждом пути записи, отличающий владельца аккаунта от детерминированного правила и от модели, с указанием правила или модели. Именно это мы и добавляем, и я бы спросил любого поставщика, чей продукт делает проводки за вас, есть ли это в его протоколе.

Как оценивать соответствие GoBD в ИИ-инструменте для бухгалтерии

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

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

По самим обязанностям наше руководство по GoBD-совместимой бухгалтерии охватывает десять принципов, сроки хранения и доступ к данным Z1 до Z3. С технической стороны как мы отслеживаем прогоны агентов без хранения данных и как наша категоризация учится на исправлениях описывают два механизма, которые вообще делают вопрос о субъекте разрешимым.

Частые вопросы

Есть ли бухгалтерская программа, которой можно пользоваться без технических знаний и которая соответствует GoBD?

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

Какими критериями должна руководствоваться немецкая компания при оценке ИИ-налоговых технологий?

Четырьмя, в таком порядке. Может ли протокол изменений отнести проводку именно к автоматике, а не просто к вашему аккаунту? Какое событие запечатывает период от дальнейших правок и делаются ли исправления затем обратной проводкой? Идёт ли экспорт данных в формате, который проверяющий действительно прочитает при доступе Z1 до Z3? И даёт ли поставщик описание процесса, соответствующее фактической работе программы? Качество модели менее важно, потому что неверная категория исправляется дёшево, а непроверяемая книга нет.

Какая бухгалтерская программа лучше с точки зрения правовой определённости: GoBD, защита данных и обновления под новые законы?

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

Применяется ли EU AI Act к бухгалтерской автоматизации?

В основном не так, как ожидают. Бухгалтерии и налоговой категоризации нет в Приложении III, поэтому обязанности для высокого риска, включая протоколирование по статье 12, как правило не применяются, и они в любом случае отложены до 2 декабря 2027 года предварительным согласием по Digital Omnibus от 7 мая 2026 года. Обязанности по прозрачности из статьи 50 действуют с 2 августа 2026 года, но касаются раскрытия того, что система является ИИ, а не ведения бухгалтерских записей. Обязывающим ограничением остаются GoBD.

Может ли ИИ принимать решение о проводке или человек обязан его подтвердить?

GoBD не требуют человеческого подтверждения каждой проводки. Они требуют, чтобы проводка была прослеживаемой, основанной на документе, своевременной и неизменяемой после факта, и чтобы ваше описание процесса точно отражало, как делаются проводки. Если в вашей Verfahrensdokumentation указано, что автоматическая категоризация проводится без проверки, это может соответствовать требованиям при условии, что протокол изменений фиксирует решение, а путь исправления это обратная проводка. Не соответствует описание процесса, заявляющее человеческую проверку, которой нет.

Заключение

Интересный вопрос про ИИ в бухгалтерии никогда не состоял в том, разрешает ли его регулятор. Он в том, способна ли ваша система объяснить себя потом. GoBD потребовали этого в 2019 году, причём способом, который для машинных субъектов оказался ровно правильным: назвать источник, сохранить старое значение, никогда не перезаписывать молча. Мы нашли две дыры в своей реализации, задав три вопроса своим же данным, и обе оказались в скучном направлении, отсутствующий столбец и невызываемый метод, а не в модели. Именно там я ожидал бы найти дыры и у всех остальных.