Бесплатная консультация юриста

+7 (800) 302-87-29

Реклама jurik.ru

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

XML‑формат (основной стандарт)

XML‑сообщения используются в большинстве сервисов ФНС: отправка деклараций, получение уведомлений, обмен данными по контрольно‑кассовой технике (ККТ) и др.

Кодировка – UTF‑8 без BOM.
Корневой элемент – зависит от типа сообщения (например, <Declaration> для декларации, <Response> для ответа).
Обязательные атрибуты – версия схемы (version), идентификатор сообщения (MessageID), timestamp (SentAt).
Схема валидации – XSD‑файлы, опубликованные на официальном портале ФНС.

Пример фрагмента XML‑сообщения (декларация по НДС):

JSON‑формат (альтернативный для веб‑сервисов)

В некоторых API ФНС (например, сервисы проверки контрагентов, получение справок) используется JSON. Это упрощает интеграцию с современными веб‑ и мобильными приложениями.

Кодировка – UTF‑8.
Обязательные поля – version, messageId, sentAt (ISO‑8601).
Структура данных – вложенные объекты и массивы, соответствующие XSD‑схемам, но представленные в виде JSON.

Пример JSON‑сообщения (запрос на получение статуса декларации):

{

  «version»: «1.0»,
  «messageId»: «20260910-002»,
  «sentAt»: «2026-09-10T11:13:12Z»,
  «requestType»: «declarationStatus»,
  «taxpayer»: {
    «inn»: «###»,
    «kpp»: «###»
  },
  «declarationId»: «DECL-2026-09-00123»
}

Текстовый формат (EDI‑like) для устаревших систем

Некоторые крупные налогоплательщики всё ещё используют позиционные файлы fixed‑width или delimited (CSV, TSV). Такие форматы регламентируются отдельными приказами ФНС и применяются mainly для массовой передачи реестров (например, списки налогоплательщиков, выписки из ЕГРЮЛ).

Разделитель – табуляция ( ) или запятая (,).
Кодировка – Windows‑1251 или UTF‑8 (указывается в заголовке файла).
Строка заголовка – содержит имена полей согласно справочнику ФНС.
Контрольная сумма – иногда добавляется в последней строке файла для проверки целостности.

Пример CSV‑строки (реестр налогоплательщиков):

ИНН,КПП,Наименование,Адрес,Статус
###,###,ООО «Пример»,г. Москва, ул. ###, д. 10,Активный

Особенности формирования и отправки сообщений

Подписание – все сообщения, передаваемые в ФНС, должны быть подписаны квалифицированной электронной подписью (КЭП) налогоплательщика или его представителя. Подпись помещается в отдельный блок <Signature> (XML) или в поле signature (JSON).
Шифрование – при передаче через открытые каналы (интернет) используется TLS 1.2/1.3. В некоторых сервисах предусмотрено дополнительное шифрование содержимого сообщения алгоритмом ГОСТ Р 34.12‑2015 (Кузнечик) или AES‑256.
Контроль дублирования – поле MessageID должно быть уникальным в пределах одного налогоплательщика за сутки. При получении дубликата ФНС возвращает код ошибки DUPLICATE_MESSAGE.
Ответы и уведомления – после обработки сообщения ФНС возвращает ответный документ того же формата, содержащий поля status (например, ACCEPTED, REJECTED), errorCode (при наличии) и description.

Где найти актуальные схемы и рекомендации

Все официальные XSD‑схемы, примеры сообщений и инструкции по заполнению доступны на портале nalog.ru в разделе «Электронные сервисы → Форматы обмена». Рекомендуется периодически проверять наличие обновлений, так как ФНС может вносить изменения в структуру сообщений (например, добавление новых реквизитов для НДС‑платёжного агента).

Понимание форматов сообщений – ключевой элемент успешного электронного взаимодействия с налоговыми органами. Выбор формата зависит от типа сервиса, используемого программного обеспечения и требований к уровню автоматизации. XML остаётся основным стандартом благодаря строгой валидации и широкой поддержке в корпоративных системах. JSON удобен для веб‑ и мобильных приложений, а текстовые форматы сохраняются в niche‑сценариях массовой выгрузки данных. Соблюдение правил подписания, шифрования и уникальности идентификаторов гарантирует своевременную доставку и корректную обработку сообщений ФНС.