Проверка раздельного учёта редко ограничивается одной формой или одним регистром. Контролёры сопоставляют контракт, учётную политику, первичные документы, платежи, затраты, РКМ и фактический результат исполнения.
Главная задача подготовки — заранее найти разрывы в доказательной цепочке. Компания должна уметь быстро восстановить путь операции от договора и первичного документа до платежа, учёта, РКМ и фактического результата.
1Договоры и режим сопровождения
Первый блок проверки — правовое основание и маршрут расчётов.
- основной контракт и дополнительные соглашения;
- ИГК;
- условия казначейского или банковского сопровождения;
- договоры с соисполнителями;
- подтверждение открытия лицевых счетов или аналитических разделов;
- сведения о расчётных маршрутах;
- реестр кооперации, если он применим;
- переписка с заказчиком, ТОФК или уполномоченным банком.
Если расчёты идут по разным маршрутам — через лицевой счёт, банковский счёт и собственные средства — основание каждого маршрута должно быть документировано.
2Методология раздельного учёта
- действующая учётная политика;
- приказ о ведении раздельного учёта;
- перечень прямых затрат;
- состав ОПР и АУР;
- базы распределения накладных расходов;
- рабочий план счетов;
- формы регистров;
- порядок учёта собственных, заёмных и целевых средств;
- правила закрытия периода и исправления ошибок.
Проверьте 1С. Текст учётной политики и фактические настройки системы должны совпадать. Разная база распределения в документе и программе выглядит как системное расхождение, а не как техническая мелочь.
3РКМ и плановые расчёты
- плановый и фактический РКМ;
- расчёты отклонений и пояснения;
- кассовый план;
- график исполнения;
- документы по изменению цены, объёма или сроков;
- согласования с заказчиком.
Если структура статей в РКМ и 1С различается, заранее подготовьте таблицу соответствия.
4Первичные документы и склад
По существенным операциям должна восстанавливаться полная документальная цепочка.
- договор и счёт;
- УПД, накладная или акт;
- документы о поступлении и перемещении;
- складские документы;
- передача или списание в производство;
- документы о выпуске продукции или завершении этапа;
- привязка к контракту, изделию или работе.
Полезно заранее выбрать несколько материалов и пройти их путь целиком: от договора с поставщиком до списания в производство и отражения в РКМ.
5Не смешивайте разные учётные категории
6Персонал и оплата труда
- штатное расписание;
- трудовые договоры;
- должностные инструкции;
- табели;
- наряды и сменные задания;
- расчёты зарплаты и премий;
- договоры ГПХ и подтверждение результата;
- приказы о закреплении сотрудников за проектами;
- расчёт распределения зарплаты между контрактами.
Проверяющему важно видеть функцию сотрудника: кто создаёт результат, кто обеспечивает производство, а кто управляет организацией.
7Платежи, Сведения и электронный архив
- выписки и платёжные распоряжения;
- решения ТОФК или банка;
- Сведения по форме 0501213;
- архив XML-файлов и протоколов отправки;
- электронные подписи;
- подтверждение полномочий подписантов;
- переписка по отказам, корректировкам и повторным направлениям.
По спорному платежу сохраняйте всю историю версий, а не только успешно проведённый итоговый комплект.
8Соисполнители
- договор с соисполнителем и ИГК;
- подтверждение применимого режима сопровождения;
- счёт или раздел, если требуется;
- техническое задание;
- акты и документы фактического результата;
- счета и платёжные документы;
- переписка по спорным вопросам;
- связь результата с основным контрактом.
Отдельно проверьте случаи, когда работы уже выполнены, но нужный счёт не открыт, либо платеж прошёл не по тому маршруту. Такие ситуации лучше разобрать до проверки и оформить служебную позицию.
9Накладные расходы и базы распределения
- перечень ОПР и АУР;
- базы распределения;
- расчёты коэффициентов;
- расшифровка крупных накладных расходов;
- документы по аренде, коммунальным услугам, ИТ, связи, командировкам и консультациям;
- обоснование распределения между контрактами.
Проверьте, нет ли в прямой базе расходов, которые по экономическому смыслу являются накладными. Такая ошибка может изменить коэффициент распределения сразу по нескольким контрактам.
10Статья «прочие затраты»
Регулярные и существенные расходы не должны накапливаться в одной общей статье без аналитики. Для проверки нужна расшифровка до договора, документа и экономического основания.
11Внутренняя репетиция проверки
Перед внешним запросом выберите контрольную выборку:
- пять крупных расходов;
- пять нестандартных расходов;
- несколько платежей по счёту 71;
- один договор с соисполнителем;
- один материал от закупки до списания;
- один расчёт распределения накладных расходов.
Попросите сотрудника, который не участвовал в первоначальном учёте, восстановить путь каждой операции.
12Что должен восстановить независимый сотрудник
13Полный чек-лист перед проверкой
14Чем поможет ВСЕОГК
ВСЕОГК помогает провести внутреннюю диагностику до проверки и собрать связное досье по контракту.
Спорные операции безопаснее разобрать заранее, чем восстанавливать доказательную цепочку уже после запроса контролёров.
15Редакционная оговорка
Материал носит информационный характер. Для конкретного договора или операции необходимо проверить применимую редакцию нормативных актов, условия контракта, учётную политику организации и требования ТОФК либо уполномоченного банка.
16Нормативные и методические ориентиры
- приказ Минфина России от 10.12.2021 № 210н в редакции с изменениями, внесёнными приказом Минфина России от 27.06.2025 № 83н;
- постановление Правительства РФ от 19.01.1998 № 47 — в применимых случаях для государственного заказа и ГОЗ; изменения 2026 года вступают в силу с 01.01.2027;
- Федеральный закон от 29.12.2012 № 275-ФЗ — для государственного оборонного заказа;
- учётная политика организации и внутренние регистры раздельного учёта;
- условия конкретного контракта и требования применимого режима сопровождения.
Заключение
Подготовка к проверке — это не механический сбор папок. Договор, методика, первичный документ, платёж, учёт, РКМ и фактический результат должны складываться в одну воспроизводимую цепочку.
Чек-лист нужен для того, чтобы найти разрывы раньше контролёра и устранить их до появления дополнительных запросов и спорных выводов.