Ко всем статьям
XBRL-отчетность в России выходит на новый этап: от машиночитаемых агрегированных отчетов к детальным данным в формате XBRL-CSV. Что это значит для участников рынка, какие риски возникают и почему контроль должен быть непрерывным – в нашем разборе.
Что такое XBRL-отчетность
В конце 90-х, Чарльз Хоффман и AICPA (American Institute of Certified Public Accountants – Американский институт дипломированных бухгалтеров) инициировали разработку нового стандарта сбора отчетности. Изначально он назывался XFRML (eXtensible Financial Reporting Markup Language), но всего через год его переименовали в XBRL (eXtensible Business Reporting Language). И не зря – ведь довольно рано стало понятно, формат может быть использован во многих сферах. В разных странах его применяют для раскрытия финансовой информации, банковского и страхового надзора, налоговой отчетности и работы корпоративных реестров. По данным XBRL International, стандарт используется более чем 10 млн компаний в 60 странах и более чем 100 регуляторами.
XBRL – формат обмена бизнес-отчетностью, изначально основанный на расширяемом языке разметки XML. Его первостепенная ценность – возможность предоставлять отчетность в унифицированном и прозрачном виде. Вместе с данными передается их формализованная семантика: что означает показатель, к какому периоду он относится, в каких единицах измеряется, с какими другими показателями связан и какие правила должны выполняться. Использование XBRL автоматизирует процессы передачи и предварительной проверки данных.
Но нужно понимать, сейчас сделать документ машиночитаемым уже недостаточно. Регуляторы все чаще работают непосредственно с большими массивами структурированных данных.
Международная практика использования XBRL
Стандарт XBRL за рубежом используется не только центральными банками.
В США XBRL применяется SEC (U.S. Securities and Exchange Commission – Комиссия по ценным бумагам и биржам) для раскрытия информации публичными компаниями и инвестиционными фондами.
В Японии XBRL используется при подаче финансовой информации в EDINET. Компании подают финансовую информацию в электронном виде, структурированные данные становятся доступными регулятору и другим пользователям рынка. Руководит процессом FSA (Financial Services Agency – Агентство по финансовым услугам).
В Великобритании XBRL используется в налоговом администрировании: большинство компаний подают определенную бухгалтерскую отчетность и налоговые расчеты с использованием Inline XBRL. Inline XBRL – технический стандарт документации, дающий возможность сдавать отчетность одновременно в машиночитаемом и человекочитаемом виде.
Особенность XBRL-отчетности в Банке России
В российской практике таксономия Банка России фактически объединяет требования к бухгалтерской, надзорной и статистической отчетности соответствующих участников рынка.
Подготовка к обновлению стандарта началась еще в 2016 году. С 2018 года XBRL стал обязательным для ряда категорий некредитных финансовых организаций. Область применения стандарта последовательно расширялась.
В настоящее время в перечень участников входят страховщики, НПФ, профессиональные участники рынка ценных бумаг, управляющие компании и инвестиционные фонды, бюро кредитных историй, операторы различных финансовых платформ и другие организации.
Главная особенность российской модели – характер собираемой информации. ЦБ РФ движется от получения относительно агрегированных показателей к сбору детальных, гранулярных и учетно-операционных данных. К примеру, популярный за рубежом формат Inline XBRL, в котором упор идет на удобство читаемости для человека, не оптимизирован для задач по работе с гранулярными данными. Необходимость собирать большие массивы данных принципиально меняет технологическую задачу.
Если отчет содержит несколько тысяч или десятков тысяч показателей, традиционная модель формирования XBRL-файла еще может оставаться относительно управляемой. Но когда регулятор начинает получать данные на уровне отдельных операций, клиентов, сделок или элементов реестров, количество записей может возрастать на порядки.
Таким образом, задача постепенно превращается в задачу массового формирования, проверки, хранения и передачи больших массивов структурированных данных.
Именно здесь проявляются ограничения традиционной архитектуры.
Регламент предоставления отчетности
Существует как минимум две периодичности сдачи отчетности: регулярная и нерегулярная.
Регулярная отчетность формируется в установленные сроки – ежемесячно, ежеквартально или ежегодно. При сдаче известны состав показателей, сроки и правила представления.
Нерегулярная отчетность предоставляется по запросу регулятора.
В российской практике существуют отдельные механизмы и точки входа в таксономии. Например, Банк России прямо выделяет нерегулярную отчетность профессиональных участников рынка ценных бумаг, предоставляемую по запросу.
Именно второй сценарий особенно важен с точки зрения операционного риска: организация не всегда может заранее знать, когда именно и какой набор данных потребуется сформировать.
XBRL на стороне участников рынка
Период сдачи отчетности – практически всегда стресс для организации, вне зависимости от формата. Это кросс-функциональное взаимодействие между несколькими подразделениями: бухгалтерией, финансовым блоком, риск-менеджментом, IT, подразделениями внутреннего контроля и специализированными внешними подрядчиками. Процессы организации и автоматизации сдачи регулярной отчетности отладить легче. Известны сроки, таксономия и правила контроля. Но даже в этом случае, сдача сразу нескольких форм отчетности одновременно увеличивает нагрузку на отделы и риск ошибки.
ЦБ РФ использует механизм точек входа для синхронизации разных видов отчетности. Для некоторых категорий организаций в один XBRL-пакет объединяется несколько видов отчетности с одинаковым сроком представления.
Организация процесса по сдаче нерегулярной отчетности – задача в разы сложнее. При получении запроса требуется то же самое кросс-функциональное взаимодействие и многоступенчатый процесс формирования итогового документа. Компания должна найти необходимые данные, доказать их корректность, сформировать требуемую структуру, пройти контрольные соотношения и уложиться в установленный срок.
В результате на рынке сформировался отдельный класс решений и поставщиков, специализирующихся на автоматизации подготовки и сдачи отчетности. Однако наличие специализированного ПО само по себе не устраняет главный риск: ошибка может быть обнаружена слишком поздно.
Что меняется в подходе сбора отчетности
Следующий этап развития XBRL связан с изменением способов его технологического применения. Одним из ключевых направлений становится XBRL-CSV.
По данным Банка России, новая спецификация предназначена для оптимизации сбора и обработки гранулированных данных. Введение нового стандарта, XBRL-CSV, позволяет уменьшить размер передаваемых файлов.
Модель данных и таксономия XBRL сохраняются. Меняется способ физического представления больших массивов данных.
В классическом XBRL-XML значительная часть структуры и контекстов представлена в XML-документе. Для больших повторяющихся наборов данных это приводит к существенному увеличению объема.
В XBRL-CSV данные размещаются в CSV-файлах, а метаданные JSON описывают их структуру и связь с моделью XBRL.
Банк России проводил первые пилоты нового стандарта в 2018-2019 годах. По результатам экспериментов физический объем реестровых данных удалось сократить более чем в 15 раз. Кроме того, была подтверждена возможность работы большими массивами детальных данных.
В 2025 началась подготовка к переходу. Банк России публикует правила, примеры пакетов и схемы проверки XBRL-CSV, а представление отдельных видов отчетности в этом формате уже предусмотрено на практике.
Одновременно развивается еще более широкий сценарий – сбор учетно-операционных данных. В октябре 2025 года Банк России приступил к пилотированию сбора таких данных у профессиональных участников рынка ценных бумаг в формате XBRL-CSV.
Для этого разработана многомерная модель, позволяющая собирать общий массив данных и отдельные наборы информации по операциям, клиентам и периодам. При этом встроенные правила контроля качества сохраняются.
То есть направление изменений можно описать следующим образом:
от отчетности -> к данным
от агрегатов -> к детализации
от периодической загрузки -> к постоянному сбору и контролю
от XML -> к более эффективным способам представления больших массивов XBRL-данных
Есть информация, Банк России уже сейчас имеет техническую возможность обрабатывать пакеты отчетности в формате XBRL-CSV, содержащие до 500 миллиардов точек данных в одном пакете отчетности. Это позволит запрашивать срезы транзакционных данных поднадзорных организаций и проводить анализ этих данных.
Ввод нового стандарта может значительно увеличить риски несоблюдения требований (compliance risk) поднадзорными организациями. Огромные срезы данных должны быть предоставлены в сжатые сроки и не иметь ошибок и противоречий.
Новые вызовы у участников рынка
Изменение подхода создает новую технологическую проблему уже на стороне отчитывающейся организации.
Исторически многие системы подготовки XBRL строились вокруг модели:
данные -> формирование XML -> валидация -> отправка
Но при увеличении объема и детализации данных этого становится недостаточно.
-
Первый вызов – объем
Если количество отчетов и детализация данных увеличиваются, растут требования к системам хранения, обработки и передачи данных. Старые решения, рассчитанные на относительно небольшие XBRL-файлы, могут стать узким местом.
-
Второй вызов – скорость
При сдаче регулярной отчетности срок известен заранее. Для сдачи отчетности по запросу времени может быть значительно меньше.
Если формирование отчета занимает часы или дни, организация постоянно находится в режиме ожидания следующего запроса.
-
Третий вызов – контроль качества
Увеличение объема данных увеличивает количество потенциальных ошибок. При этом проблема может находиться не в самом XBRL-файле. Отчет может технически соответствовать формату и пройти синтаксическую проверку, но содержать неверное значение, неполное множество данных или несогласованность с другими источниками. Это значит, технически валидный XBRL-файл не обязательно означает корректную отчетность.
-
Четвертый вызов – изменение привычной архитектуры
То, что хорошо работало для XML, не обязательно будет одинаково эффективно работать с большими CSV-наборами.
При переходе к детальным данным к работе с готовой отчетностью присоединяется работа с исходными наборами данных, историей их изменений, версиями таксономий и правилами расчета.
В результате нужно постоянно поддерживать данные в состоянии готовности к формированию отчетности, а не просто сформировать и проверить готовый отчет.
Что можно улучшить
Переход к новой модели не обязательно означает необходимость полностью перестраивать существующую систему сдачи отчетности. Достаточно добавить второй уровень контроля.
Первый существующий уровень:
учетные системы -> система подготовки отчетности -> XBRL -> валидация -> отправка
Второй уровень – постоянная сверка данных. Он может работать постоянно, независимо от конкретного цикла сдачи:
операционные данные -> непрерывная сверка -> выявление отклонений -> оценка риска формирования отчета
Такой подход, предиктивный контроль вместо реактивного, позволяет перейти от контроля факта ошибки к контролю риска возникновения ошибки. Если система обнаруживает отклонение заранее, у организации есть время разобраться в его причине.
Это принципиально отличается от сценария, когда проблема обнаруживается в последний день перед отправкой.
Сегодня контроль часто выглядит так:
- Сформировали отчет -> проверили -> нашли ошибку -> исправили -> сформировали заново
Более зрелая модель:
- Постоянно контролируем данные -> обнаруживаем отклонение -> оцениваем вероятность ошибки -> исправляем до начала формирования отчета
В этом случае инструмент является вторым фактором контроля качества и готовности. Это особенно важно при нерегулярных запросах. Организации не нужно начинать собирать данные в момент поступления запроса. У сотрудников уже есть понимание: какие данные доступны, насколько они полны, согласованы ли они между системами и насколько быстро из них можно сформировать требуемую отчетность.
Главное преимущество такого решения – возможность сохранить существующую инфраструктуру.
Можно сохранить:
- существующие учетные системы;
- существующего подрядчика по регуляторной отчетности;
- существующие процессы формирования XBRL;
- используемые средства валидации;
- существующую архитектуру взаимодействия с Банком России.
И добавить поверх них независимый контур постоянного контроля.
В результате появляется дополнительный уровень защиты от наиболее дорогого сценария –обнаружения проблемы сразу перед сдачей.
Итог
Развитие XBRL в России сейчас на новом этапе, связанном с переходом от машиночитаемой агрегированной отчетности к приему и обработке детальных данных.
Именно поэтому Банк России развивает XBRL-CSV и экспериментирует со сбором учетно-операционных данных. Для участников рынка это означает изменение требований к формату файлов и архитектуре подготовки данных.
Чем больше объем, чем выше детализация и чем чаще появляются запросы регулятора, тем менее эффективной становится модель, в которой качество отчетности проверяется только непосредственно перед ее отправкой. Поэтому следующим шагом становится непрерывный контроль готовности данных к сдаче отчетности.
Такой подход позволяет превратить период сдачи отчетности из авральной процедуры в постоянно контролируемый процесс, где ошибки выявляются заранее.