SAF-T UA без паники: как выглядит электронный аудит глазами бухгалтера

Что является действующим состоянием на 11 сентября 2026 года

От учетной базы до проверок ГНС

Структура файла языком бухгалтера

Как «читаются» отдельные участки учета

Контрольный список качества аналитики

Учебный пример: ищем расхождение между обороткой и SAF-T

Типичные ошибки подготовки

Как организовать готовность без аврального проекта

Главный вывод

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

Главная сложность не в самом XML. Она в качестве учетной аналитики: одинаково ли идентифицирован контрагент в разных подсистемах, имеет ли каждая проводка источник, согласуются ли складские движения с количеством и суммой, не потерялась ли первоначальная стоимость основного средства при миграции. Поэтому подготовка к SAF-T начинается не с кнопки «Выгрузить», а со сверки того, что уже есть в BAS, ERP, складской системе и вспомогательных регистрах.

Что является действующим состоянием на 11 сентября 2026 года

Электронный аудит уже перешел из презентаций в практику. В официальном сообщении ГНС о применении SAF-T UA указано, что за первый квартал практического использования служба получила 14 файлов от плательщиков непосредственно по запросам во время документальных проверок. Данные обрабатываются системой е-аудита, которая автоматически ищет расхождения, несоответствия и потенциальные нарушения.

В то же время важно не переносить требования к крупным плательщикам на весь бизнес. Согласно действующему порядку обязанность предоставить SAF-T UA касается крупного налогоплательщика, включенного в соответствующий Реестр, когда файл запрошен во время документальной проверки — плановой или внеплановой, выездной или невыездной. Срок, который приводит ГНС, — не позднее двух рабочих дней, следующих за днем получения запроса; начало и конец периода определяются самим запросом.

SAF-T UA не является налоговой декларацией и не подается ежемесячно или ежеквартально по календарю отчетности. Это электронные документы и информация, связанные с предметом проверки. ГНС называет 2024 год первым календарным годом, за который может запрашиваться такой файл, и подтверждает, что обновленная структура SAF-T UA версии 2.0 опубликована 6 ноября 2024 года. На официальном ресурсе доступны XSD-схема, техническое описание, приложение, описание изменений и примеры валидных и ошибочных файлов.

Еще одна полезная граница между фактом и старыми прогнозами: законопроект № 6255 о внедрении электронных проверок был отозван 17 июля 2025 года. Следовательно, таблицы будущих этапов, которые когда-то строились на его тексте, нельзя подавать как действующий календарь распространения SAF-T UA. Отдельного штрафа исключительно под названием «за SAF-T» Кодекс не устанавливает; ГНС связывает ответственность с общими правилами непредоставления или неполного предоставления информации по запросу. Денежный размер в такой ситуации зависит от минимальной зарплаты на 1 января соответствующего налогового года, поэтому его следует проверять именно для периода и оснований конкретного запроса.

От учетной базы до проверок ГНС

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

В этой схеме XSD-валидация отвечает только на вопрос, правильно ли построен файл технически: допустимы ли элемент, тип данных, формат даты, количество знаков, обязательность поля. Она не доказывает, что сумма верна. XML может быть безупречно валидным и одновременно содержать пропущенный документ, дублированную проводку или контрагента с неправильным кодом.

Структура файла языком бухгалтера

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

1. Заголовок: кто, за какой период и из какой системы

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

2. Справочники: единый язык для всех операций

В справочном слое собраны сущности, на которые ссылаются проводки и документы. Его следует представлять как контролируемый экспорт карточек из базы:

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

Ключевое требование здесь — постоянство идентификаторов. Если один и тот же поставщик в закупках имеет код «P-154», а в проводке — старый код «000154», автоматическая проверка увидит две разные сущности или «сиротскую» ссылку. Для человека названия могут выглядеть одинаково; машина сверяет ключи.

3. Главная книга: не просто оборотка, а каждая строка проводки

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

Здесь особенно заметны ручные операции. Если бухгалтер ввел проводку без документа, комментария или необходимого субконто, во внутренней оборотке сумма сойдется. Однако во время е-аудита будет сложнее объяснить экономический смысл и подтвердить связь с первичным документом.

4. Первичные документы: откуда возникла проводка

Этот слой детализирует хозяйственные события: документы продажи и приобретения, платежи, движения товаров и операции с активами. В нем важны дата, номер, контрагент, позиции, количество, цена, база налогообложения, налог, итог и статус. В хорошей модели можно пройти цепочку в двух направлениях: от документа к его проводкам и от проводки обратно к документу.

Для бухгалтера это привычное требование прослеживаемости, только проверяет его уже не человек, который открывает карточку документа, а алгоритм. Он быстро находит ситуации, когда накладная есть, а проводки нет; проводка есть, а документ не идентифицирован; в документе один контрагент, а в аналитике счета — другой.

Как «читаются» отдельные участки учета

Контрагенты

Проверка смотрит не только на название. Важны код, налоговый идентификатор, роль покупателя или поставщика, адресные данные и использование одного ключа в документах и проводках. Дубликаты вроде «ООО Альфа» и «Альфа, ООО» — не косметическая проблема, если по ним рассеяны обороты и налоговые суммы.

Запасы

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

Основные средства

Для каждого объекта важно проследить первоначальное признание, изменения стоимости, амортизацию, перемещения и выбытие. Типичная проблема миграции — в главной книге остатки перенесены, а карточки объектов не содержат полной истории. В результате синтетические счета сходятся, но сумма первоначальной стоимости или износа по перечню активов отличается.

Налоги

Налоговая сумма должна иметь понятный источник: операцию, базу, код налога, примененную ставку и правила округления. Не следует «улучшать» исторические документы во время экспорта, пересчитывая их по текущим ставкам. SAF-T должен воспроизводить данные исходной системы за соответствующий период, а отклонения — документироваться и объясняться.

Контрольный список качества аналитики

Перед тестовой выгрузкой полезно фиксировать не только отметки «выполнено», но и доказательство: название отчета, параметры отбора, дату запуска, количество строк, контрольную сумму и ответственного. Минимальный список выглядит так:

• период, организация и валюта в заголовке соответствуют запросу;
• каждый счет из проводок существует в выгруженном плане счетов;
• начальное сальдо плюс дебетовый оборот минус кредитовый оборот равно конечному сальдо для активного представления; для пассивных и активно-пассивных счетов проверено корректное развернутое представление;
• сумма всех дебетовых оборотов равна сумме всех кредитовых оборотов в пределах одного набора записей;
• коды покупателей, поставщиков, номенклатуры, складов и основных средств уникальны и не изменяются между блоками;
• нет ссылок на отсутствующий справочный элемент;
• дубликаты контрагентов выявлены по налоговому идентификатору, а не только по названию;
• у проводок есть дата, номер, источник и необходимые аналитические измерения;
• удаленные, сторнированные и непроведенные документы попадают в набор данных по однозначному, согласованному правилу;
• количественные остатки запасов согласуются со складскими регистрами, а стоимостные — со счетами учета;
• первоначальная стоимость, накопленная амортизация и балансовая стоимость основных средств сверены с главной книгой;
• налоговые базы, суммы, коды и ставки связаны с документами; правила округления воспроизводят исходную систему;
• повторная выгрузка с теми же параметрами дает те же количества строк и контрольные суммы;
• файл проходит XSD-валидацию, а все предупреждения разобраны, а не просто скрыты;
• для больших объемов проверено формирование, передача и открытие полного файла, а не только тестового фрагмента.

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

Учебный пример: ищем расхождение между обороткой и SAF-T

Предположим, по счету 281 «Товары на складе» оборотно-сальдовая ведомость за апрель показывает:

• начальное сальдо — 1 250 000 грн;
• дебетовый оборот — 780 000 грн;
• кредитовый оборот — 690 000 грн;
• конечное сальдо — 1 340 000 грн.

Формула сходится: 1 250 000 + 780 000 − 690 000 = 1 340 000 грн. Но после агрегации строк главной книги из тестового SAF-T конечный остаток составляет 1 310 000 грн. Расхождение — 30 000 грн. Паниковать и сразу исправлять проводки не следует: сначала нужно доказать, в каком слое появилась разница.

Шаг 1. Сделать сопоставимые наборы

Проверяем, что в оборотке и в выгрузке одинаковы организация, счет, период, валюта и признак проведения. Отдельно убеждаемся, что оборотка не сформирована по подразделению или складу, тогда как SAF-T содержит все подразделения. После этого сохраняем контрольные итоги обоих наборов.

Шаг 2. Определить сторону расхождения

Начальное сальдо и дебет в двух наборах одинаковы. Кредит в SAF-T равен 720 000 грн, то есть превышает оборотку именно на 30 000 грн. Следовательно, искать следует не «где-то в товарах», а среди кредитовых строк счета 281.

Шаг 3. Сгруппировать до уровня документа

Строки группируем по дате, номеру документа, сумме и идентификатору операции. Почти все документы дают одинаковые итоги. Только перемещение запасов № СК-000184 на 30 000 грн в XML присутствует дважды, а в оборотке — один раз.

Шаг 4. Найти техническую причину

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

Шаг 5. Исправить и доказать результат

Разработчик изменяет правило соединения, чтобы каждая строка проводки имела уникальный ключ. Новый файл проходит три проверки: кредитовый оборот счета 281 равен 690 000 грн, конечное сальдо — 1 340 000 грн, документ № СК-000184 представлен один раз. Дополнительно стоит проверить другие счета с той же налоговой аналитикой: локальное исправление могло повлиять на весь экспорт.

Этот алгоритм работает и для пропуска. Если SAF-T имеет меньший оборот, сравниваем итоги по дате, далее — по виду документа, номеру и строке. Движение от общего к конкретному быстрее и надежнее, чем просмотр XML глазами от первой строки до последней.

Типичные ошибки подготовки

• Проверять только валидность XML. Валидный формат не гарантирует полноты и правильности сумм.
• Строить файл без участия бухгалтера. Разработчик видит поля и типы, но не всегда знает, почему конкретное сторно, ручная проводка или закрытие месяца имеют именно такую экономическую логику.
• Сверять только баланс. Одинаковое конечное сальдо может скрывать взаимно компенсированные пропуски в дебете и кредите.
• Очищать справочники накануне проверки. Массовое объединение дублей без карты соответствия может разорвать исторические ссылки.
• Пересчитывать историю по новым правилам. Экспорт должен воспроизводить учетные данные периода, а не создавать их новую версию.
• Не сохранять протокол формирования. Без параметров, версии обработки, времени, количества строк и контрольных сумм трудно воспроизвести результат.
• Полагаться на одного человека. Бухгалтер, специалист по учетной системе и ответственный за передачу должны знать свои действия и резервный порядок.

Как организовать готовность без аврального проекта

Первый тест стоит делать не за весь доступный архив, а за один закрытый месяц с разными типами операций. Для него формируется матрица сверок: счет — оборотка — SAF-T; контрагент — карточка — документы — проводки; номенклатура — складское движение — счет; основное средство — карточка — амортизация — главная книга. Когда правила отлажены на компактном периоде, их запускают на квартале и году.

Второй шаг — распределить ответственность. Бухгалтер определяет экономическую правильность и контрольные отчеты; специалист BAS или ERP отвечает за отбор, маппинг и повторяемость; ИТ-специалист — за ресурсы, защищенное хранение и передачу; руководитель утверждает сроки и порядок реагирования. Результатом должен быть не один «успешный файл», а воспроизводимый процесс.

Третий шаг — провести репетицию запроса. Команда получает условный период, запускает выгрузку, фиксирует время, выполняет контрольный список и готовит объяснения к известным особенностям. Такая репетиция быстро показывает, реально ли уложиться в два рабочих дня, где не хватает доступов и какие сверки до сих пор зависят от ручной памяти конкретного работника.

Главный вывод

SAF-T UA не изменяет двойную запись, не отменяет первичные документы и не создает отдельную бухгалтерскую реальность. Он делает существующую реальность машиночитаемой. Если справочники имеют постоянные коды, проводки прослеживаются до документов, запасы и основные средства сверяются с главной книгой, а налоговая аналитика не отрывается от операций, электронный аудит перестает быть «черным ящиком».

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