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

 

Готовность к SAF-T UA как часть учетной дисциплины

Что не стоит делать перед проверкой

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

Подготовка базы 1С или BAS

Почему выгрузка дает ошибки

Как электронный аудит проверяет данные

Какие данные попадают в файл

Что такое SAF-T UA на практике

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

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

Что такое SAF-T UA на практике

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

Главная идея формата проста: данные разных учетных систем приводятся к общей модели. У предприятия может быть собственный рабочий план счетов, свои коды операций, номенклатуры и подразделений, но в выгрузке они должны быть однозначно описаны и связаны между собой. Для бухгалтера это означает, что подготовка SAF-T UA начинается не с кнопки «Выгрузить», а с проверки логики учета.

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

Какие данные попадают в файл

Структуру SAF-T UA удобно рассматривать как связанный набор нескольких блоков. Конкретный состав обязательных и необязательных элементов определяется актуальной версией технического описания и XSD, но смысл основных разделов остается понятным для бухгалтера.

Заголовок и сведения о предприятии

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

Справочники и начальные данные

Справочники создают основу для всех последующих ссылок. В них могут входить:

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

Смысл справочников не в том, чтобы механически выгрузить все когда-либо созданные карточки. Важно представить объекты, которые относятся к проверяемому набору данных, и сохранить однозначные идентификаторы. Если одна карточка контрагента в разных документах превращается в несколько несвязанных кодов, автоматическая сверка даст разрывы.

Главная книга и журнал бухгалтерских записей

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

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

Первичные документы и движение активов

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

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

Налоговые показатели и разницы

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

Как электронный аудит проверяет данные

Проверка не сводится к одному признаку «файл открылся». Полезно разделять как минимум два уровня контроля.

Технический контроль

Сначала проверяется соответствие XML актуальной XSD-схеме. На этом уровне выявляются:

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

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

Логический и арифметический контроль

Далее данные можно сопоставлять между разделами. Типовые контрольные соотношения выглядят так:

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

Автоматический контроль хорошо находит массовые закономерности. Например, он может выделить операции без контрагента на счетах расчетов, отрицательные количества при обычном приходе, одинаковые номера документов, нетипичную корреспонденцию или разрыв между закупкой и движением запасов. Поэтому единичная «техническая» привычка в 1С или BAS может превратиться в сотни однотипных замечаний.

Почему выгрузка дает ошибки

Чаще всего причина находится не в самом XML, а в исходной базе или в правилах преобразования данных.

1. Дубли справочников. Один поставщик заведен несколько раз, причем в одной карточке есть налоговый номер, а в другой - договор и обороты. Выгрузка не может надежно собрать единую историю.
2. Пустая аналитика. На счете расчетов отсутствует контрагент или договор, на счете запасов - номенклатура либо склад, на счете основных средств - объект учета.
3. Неустойчивые коды. При каждой выгрузке объект получает новый идентификатор или разные системы используют несовместимые ключи. В результате ссылки между разделами разрываются.
4. Ручные неподтвержденные проводки. Запись меняет обороты, но не связана с документом, бухгалтерской справкой или понятным основанием.
5. Расхождение регистров. Главная книга, складской учет, налоговые регистры и первичные документы закрыты на разные даты либо были изменены после формирования отчетности.
6. Неверное сопоставление. Собственный счет, вид операции, налоговый код, группа актива или единица измерения не связаны с допустимым значением формата.
7. Ошибки знака и округления. Суммы выгружены с противоположным знаком, количество и стоимость округляются по разным правилам, а итог документа отличается от суммы строк.
8. Неподходящая версия схемы. Модуль обмена формирует старый набор элементов, тогда как проверка выполняется по актуальной XSD.
9. Проблемы периода. В файл попадают документы за пределами запроса, начальные остатки рассчитаны на другую дату или данные нескольких лет ошибочно объединены в один файл.
10. Технический объем. Выгрузка не завершается из-за нехватки памяти, нестабильной обработки больших таблиц или неверного разбиения архивов. Это нужно обнаруживать на испытании, а не в первый день после запроса.

Подготовка базы 1С или BAS

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

1. Зафиксировать периметр

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

2. Составить таблицу соответствий

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

3. Нормализовать справочники

Дубли не следует удалять механически. Сначала находят документы и движения по каждой карточке, выбирают основной объект, переносят ссылки контролируемым способом и сохраняют историю изменений. После объединения повторно проверяют обороты и взаиморасчеты.

4. Закрыть пробелы в аналитике

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

5. Разобрать ручные операции

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

6. Сверить контрольные итоги

До формирования XML следует согласовать оборотно-сальдовую ведомость, Главную книгу, регистры по НДС и налогу на прибыль, взаиморасчеты, складские остатки, ведомость амортизации и финансовую отчетность. Контроль выполняют на начало периода, по месяцам и на конец периода. Так легче найти момент возникновения расхождения.

7. Выполнить пробную выгрузку

Пробу проводят на копии базы или в выделенном контуре, используя тот же период и объем, которые могут быть запрошены при проверке. Файл проверяют актуальной XSD, затем разбирают логические ошибки и сопоставляют контрольные суммы с учетной системой. Важно измерить время формирования, размер файла и потребление ресурсов. Результат «не успели за ночь» при сроке в два рабочих дня - полноценный риск, даже если алгоритм формально правильный.

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

Перед тем как считать базу подготовленной, полезно пройти короткий чек-лист:

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

Что не стоит делать перед проверкой

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

Не менее рискованно исправлять только XML вручную. Если выгрузку приходится «подкрашивать» после формирования, исходная система и файл начинают рассказывать разные истории. Допустимы документированные правила преобразования, но они должны быть воспроизводимыми и проверяемыми.

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

Готовность к SAF-T UA как часть учетной дисциплины

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

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