Счёт 53 и выписка по цифровому рублю в 1С:ERP, КА и УТ: как это устроено на практике

Практический разбор по описаниям обновлений «1С:Комплексная автоматизация» и «1С:ERP Управление предприятием» версии 2.6.1.64 и «1С:Управление торговлей» версии 11.6.1.64 на 1С:ИТС. Материал не является банковской, бухгалтерской или юридической консультацией: состав функциональности и названия реквизитов уточняйте по описанию вашего релиза на releases.1c.ru, а порядок работы с платформой цифрового рубля — у своего банка. Приведённые ниже правила подбора бюджетных реквизитов — это алгоритм программы, а не норма законодательства.

Короткий вывод

Поддержка цифрового рубля в линейке ERP, КА и УТ устроена асимметрично, и это главное, что нужно понять до настройки. В 1С можно принять историю операций, но нельзя отправить платёж.

Учётная часть выглядит так. В 1С:ERP и 1С:Комплексной автоматизации появился предопределённый счёт 53 «Счет цифрового рубля», встроенный в документы, справочники, отчёты и бухгалтерскую отчётность. В 1С:Управлении торговлей блока про план счетов нет — там речь идёт о загрузке выписки, и приписывать УТ счёт 53 не нужно.

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

Дальше — подробно, по шагам и с ограничениями, о которые проще споткнуться, чем догадаться.

Что меняется в учёте

Появление предопределённого счёта — это не косметика. Счёт 53 «Счет цифрового рубля» приезжает с обновлением уже в плане счетов, а не заводится пользователем. Практическая разница существенная: не нужно договариваться внутри компании о названии и коде, не нужно вручную привязывать его к документам и отчётам, и, что важнее всего, бухгалтерская отчётность учитывает счёт 53 штатно.

Счёт интегрирован в типовую обвязку: он используется в документах движения денежных средств, в справочниках банковских счетов и в отчётности по денежным средствам. То есть остатки по цифровому рублю не живут отдельной жизнью «на 76-м, потому что больше некуда».

Для УТ модель другая. Там нет плана счетов в бухгалтерском смысле, и в описании обновления соответствующего блока нет. Если в вашей схеме торговая база обменивается с бухгалтерской, вопрос «на каком счёте в итоге окажутся эти суммы» решается на принимающей стороне. Проектировать обмен под счёт 53 внутри УТ — ошибка на старте.

Второе изменение касается формы документов. В документах списания и поступления безналичных денежных средств поле «Номер по банку» переименовано в «Идентификатор», а его длина увеличена до 36 символов. Причина понятная: идентификаторы операций на платформе цифрового рубля длиннее привычных банковских номеров. Если у вас есть доработки, печатные формы или выгрузки, завязанные на это поле, их нужно проверить — переименование и рост длины ломают жёсткие шаблоны.

Как завести счёт цифрового рубля

Здесь два разных правила для двух сторон сделки, и путать их не стоит.

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

В ERP и КА при создании карточки счёта цифрового рубля счёт учёта 53 подставляется автоматически. То есть выбирать его руками в реквизитах учёта не придётся — достаточно указать, что это счёт цифрового рубля.

Счёт контрагента создаётся автоматически при загрузке выписки — но только если включена настройка «Создавать контрагентов автоматически». Она живёт в рабочем месте загрузки выписки (раздел «Загрузка выписки / зачисления на лицевые счета», подраздел «Настройки»). Если галка выключена, новые счета цифрового рубля контрагентов сами не появятся, и загрузка будет останавливаться на неопознанных реквизитах.

Отсюда практический вывод для настройки: решение про автосоздание принимается один раз и влияет на всю загрузку выписки, а не только на цифровой рубль. Включать её «ради одного сценария» стоит осознанно — в базах с грязной НСИ автосоздание контрагентов умеет быстро наплодить дублей.

Ещё одна мелочь, которая экономит время: в поле «Счёт отправитель» программа подбирает единственный доступный счёт цифрового рубля. Пока счёт у организации один — а на старте он обычно один, — заполнение происходит само.

Как загрузить выписку

Файлы выписки по цифровому рублю приходят в формате обмена ЦБ РФ. Это отдельный формат, и в интерфейсе это отражено сознательно скупо: в карточке счёта поле «Формат обмена» не отображается, а настройки прямого обмена скрыты. Варианта выбора у пользователя нет, поэтому нет и лишних полей.

В рабочем месте загрузки для файла XML используется команда «Настройка обмена». Это точка, куда стоит зайти один раз при настройке и больше не возвращаться.

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

Какие документы создаются автоматически

При загрузке выписки программа умеет распознавать и создавать документы по ограниченному перечню сценариев:

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

Всё остальное программа помечает как «операция не поддерживается». Это не ошибка и не сбой загрузки — это честное сообщение о том, что автоматического сценария для такой строки нет и разбирать её будет человек.

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

Незаполненные реквизиты: где это нормально

Несколько послаблений в контроле заполнения, о которых полезно знать заранее, чтобы не искать «почему пусто».

Счёт получателя необязателен для операции с видом «Прочий расход», если указан счёт цифрового рубля. Пустое поле здесь — штатное поведение.

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

Подбор бюджетных реквизитов

Это самая интересная и самая деликатная часть механизма, потому что здесь программа принимает решение за пользователя.

Причина, по которой подбор вообще понадобился: в соответствии с приказом Минфина России от 16.05.2025 № 58н поля 101–109 через платформу цифрового рубля не передаются. То есть в файле выписки бюджетных реквизитов нет, а в учётном документе они нужны. Программа пытается восстановить их сама.

Подбор работает по ключевым словам в назначении платежа, и правила такие:

• если в назначении встречаются слова про взносы, травматизм или СФР, подставляется КБК, начинающийся с 7971021200006…;
• для таможенного платежа — при сочетании «авансовые платежи» и «ФТС» — подставляются КБК 15301061301010000510 и ОКТМО 45328000;
• для единого налогового платежа — КБК 18201061201010000510 и ОКТМО 0.

Всё остальное подбирается по истории операций либо заполняется вручную.

Два вывода отсюда, и оба практические.

Первый: это алгоритм программы, а не норма законодательства. Правильность КБК в конкретном платеже остаётся зоной ответственности бухгалтера. Механизм экономит время на типовых операциях, но не заменяет проверку.

Второй, более жёсткий: если подбор не удался, документ не проводится. Это не «проведётся с пустым полем, разберёмся потом» — строка просто не пройдёт. Поэтому назначение платежа, которое вы формулируете в личном кабинете банка, напрямую влияет на то, сколько ручной работы будет в учёте. Формулировка «оплата по счёту» вместо внятного назначения обойдётся в ручное заполнение реквизитов на приёмной стороне.

Что не выгрузится из 1С

Раздел, который лучше прочитать до того, как обещать бухгалтерии «платим из 1С».

Выгрузка платёжных поручений на платформу цифрового рубля не поддерживается — ни через формат 1CClientBankExchange, ни через ДиректБанк. Формат обмена находится в стадии разработки.

Соответственно:

• счёт цифрового рубля и операции по нему исключены из выгрузки;
• при выгрузке по обычному расчётному счёту исключаются документы, в которых одна из сторон — счёт цифрового рубля;
• платёжное поручение и платёжное требование с участием цифрового рубля оформляются в личном кабинете банка, а не в 1С.

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

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

Ограничения, о которых стоит знать заранее

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

• Исходящих платежей из 1С нет. Контур односторонний — только приём истории.
• Обычная банковская выписка операции цифрового рубля не содержит. Нужен отдельный механизм получения файла от банка.
• Формат обмена — ЦБ РФ, выбора нет, поле формата скрыто.
• Набор автоматически создаваемых документов ограничен перечнем сценариев; остальное — «операция не поддерживается».
• Без успешного подбора бюджетных реквизитов документ не проводится.
• Счёт 53 существует в ERP и КА; в УТ этого блока нет.
• Счёт организации заводится вручную; автоматика касается только счетов контрагентов и только при включённой настройке.

Типичные ошибки

Ждать операции в обычной выписке. Самая частая. Бухгалтер загружает привычный файл из клиент-банка, не видит цифрового рубля и делает вывод, что «1С не поддерживает». Поддерживает — но по другому файлу.

Планировать исходящие платежи из учётной системы. Регламент, написанный по аналогии с расчётным счётом, придётся переписывать после первой же попытки.

Заводить счёт 53 вручную в УТ. Попытка «унифицировать» линейку приводит к тому, что в торговой базе появляется самодельный объект, который потом мешает обмену.

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

Писать в банке нечитаемые назначения платежа. Подбор бюджетных реквизитов работает по ключевым словам. Плохое назначение — ручная работа в учёте и непроведённые документы.

Не проверить доработки по полю «Номер по банку». Переименование в «Идентификатор» и длина 36 символов ломают жёстко заданные печатные формы и внешние обработки.

Считать подбор КБК гарантией правильности. Это алгоритм, а не проверка законности платежа.

Чек-лист перед запуском

1. Обновите базу до релиза, в котором функциональность присутствует, и сверьте состав по описанию версии на releases.1c.ru.
2. Уточните у банка, как именно вы получаете файл выписки по счёту цифрового рубля и в каком виде.
3. Заведите счёт цифрового рубля организации вручную. В ERP и КА проверьте, что подставился счёт 53.
4. Проверьте в рабочем месте загрузки настройку обмена для файла XML.
5. Осознанно решите вопрос с настройкой «Создавать контрагентов автоматически» и оцените её влияние на всю загрузку выписки.
6. Прогоните тестовую загрузку на копии базы — с реальным файлом, а не с выдуманным.
7. Посмотрите, какие строки получили статус «операция не поддерживается», и оцените объём ручного разбора.
8. Проверьте подбор бюджетных реквизитов на своих типовых платежах: взносы, ЕНП, таможня.
9. Согласуйте с теми, кто оформляет операции в личном кабинете банка, формат назначения платежа.
10. Проверьте доработки и печатные формы, завязанные на поле «Номер по банку».
11. Опишите регламент: кто оформляет операцию в банке, кто получает файл, кто загружает, кто разбирает неподдерживаемые строки.
12. Отдельно зафиксируйте в регламенте, что исходящие платежи из 1С не выгружаются, — до того, как кто-то попробует.

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

Источники

• Новое в версии 2.6.1.64 «1С:ERP Управление предприятием» — its.1c.ru
• Новое в версии 2.6.1.64 «Комплексная автоматизация» — its.1c.ru
• Новое в версии 11.6.1.64 «Управление торговлей» — its.1c.ru
• Описания релизов и полные описания версий — releases.1c.ru

Контакты: it-digit.ru/about/contacts · +7 (495) 646-01-17 · sales@it-digit.ru