Реестр госконтрактов прозрачный с 2026 года: учёт в 1С

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

что меняется в реестре госконтрактов с 1 июля 2026 года

С 1 июля 2026 года заказчик, конкурент и контролирующий орган видят по контракту больше данных: суммы, сроки этапов, историю изменений, статус исполнения. Раньше часть этих сведений закрывали от посторонних глаз, теперь закрытых полей меньше. В карточке контракта появляются даты каждого этапа, форма расчётов и статус оплаты — то, что раньше можно было увидеть только по официальному запросу. Для добросовестного поставщика это скорее плюс: чистая история контрактов работает как рекомендация при участии в новых закупках, и по 44-ФЗ, и по 223-ФЗ — правила раскрытия касаются обеих схем закупок.

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

Заодно снимается ещё один вопрос, который периодически возникает у закупщиков: 1С входит в реестр российского программного обеспечения, а значит соответствует требованию использовать отечественные решения при работе по государственным контрактам.

почему в 1С расходятся суммы по контракту и реестр закупок

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

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

Но для заказчика и для реестра закупок разницы нет: забытый черновик и реальный срыв поставки выглядят одинаково — контракт исполнен с опозданием.

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

Поэтому прежде чем разбираться со штрафом, стоит понять, откуда берётся расхождение. На практике причины почти всегда одни и те же: номер контракта в 1С вводят вручную, и один менеджер пишет его с пробелами, другой без — система не видит, что это один и тот же контракт; накладные, акты и платежи проводят разные сотрудники в разное время, и промежуточный статус контракта в базе не совпадает с тем, что видит заказчик; отчёт для сверки собирают вручную в Excel, а не выгружают из 1С — при повторном сборе легко упустить один документ; ответственного за реестр контрактов формально нет, и каждый считает, что сверку делает кто-то другой.

как исправить расхождения между 1С и реестром контракта

Разовая сверка снимает симптом, но не причину. Рабочее решение — завести в 1С отдельный справочник «Государственные контракты» с полями номер, заказчик, срок, сумма, статус, и привязать к каждой записи все первичные документы: накладные, акты, счета, платежи. Тогда отчёт по конкретному контракту собирается за один клик, а не пересчитывается вручную перед каждой сверкой.

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

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

ручной учёт против 1С: во сколько обходится ошибка поставщику

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

Настройку такого учёта обычно оформляют как доработку существующей базы, а дальнейшую поддержку — как обычные часы сопровождения 1С и работы сисадмина, от 3800 руб/час: специалист раз в месяц сверяет контракты, обновляет отчёт и поправляет то, что успело разойтись за прошедший период. Для той же типографии из примера выше это выглядит так: справочник настроен один раз, отчёт сверки собирается автоматически, и акт для заказчика не приходится пересобирать вручную к каждому дедлайну.

что делать, если ошибка в отчётности по контракту повторяется

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

Но это уже не ошибка ввода, а вопрос производительности базы, и лечится он не доработкой справочника, а проверкой инфраструктуры.

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

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

как предотвратить срыв срока исполнения госконтракта из-за учётных ошибок

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

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

Для поставщика с одним-двумя контрактами в квартал хватает справочника в существующей базе. Для тех, кто ведёт контракты по нескольким юрлицам или подразделениям, логичнее сразу закладывать этот учёт в общую систему — при внедрении 1С:Управление торговлей задача решается на уровне архитектуры, а не отдельной надстройкой сверху. Если система для учёта контрактов ещё не разворачивалась, начать стоит с базового внедрения 1С — дальше в неё добавляют нужные доработки по мере роста числа контрактов. Для компании, которая работает и по 44-ФЗ, и по 223-ФЗ одновременно, справочник контрактов удобно делать общим для обеих схем, а разницу в правилах закрывать отдельным полем «вид закупки» — так отчёт сверки остаётся один, а не превращается в две параллельные таблицы, которые снова придётся сводить вручную.

❓ Частые вопросы

Как понять, что учёт госконтрактов в 1С пора настраивать отдельно, а не вести в Excel?

Если сверка с заказчиком перед актом занимает больше часа, а номера контрактов в базе введены в разных форматах — это уже сигнал. После 1 июля 2026 года расхождения видны в открытом реестре, поэтому разумнее перевести учёт в 1С заранее, а не после первого штрафа за просрочку.

Нужна ли для этого отдельная конфигурация 1С или хватит доработки текущей?

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

Что грозит поставщику, если он не успеет привести учёт в порядок до 1 июля 2026 года?

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

Сколько стоит настроить в 1С учёт и сверку по госконтрактам?

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

База с контрактами тормозит при закрытии месяца — это точно проблема в настройках учёта?

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