Проанализируем ситуацию, которая выглядит «магически»: по счету 60 в целом все красиво, сальдо нулевое, акты сверки подтверждают, что никто никому не должен, но стоит провалиться в 60.01 — оплат как будто не было, а по 60.02 (или в развернутом сальдо) появляются «висящие» суммы. Разберем по шагам, почему так происходит именно в 1С:Бухгалтерия 8.3, как найти причину и как корректно закрыть взаиморасчеты без опасных ручных проводок.
Прежде чем «лечить», зафиксируем логику учета. В типовой схеме:
Поскольку счет 60 активно-пассивный, в отчетах мы можем видеть дебет и кредит, а в 1С это часто усиливается настройками «развернутого сальдо». Поэтому первая «ловушка» такая: по счету 60 в целом итог может быть ноль (дебет компенсирует кредит), но в разрезе субсчетов 60.01 и 60.02 суммы будут «разъехавшимися», и это уже повод разобраться, где разорвалась связка «оплата → поставка → зачет аванса/погашение задолженности».
Начнем с самого практичного: не будем гадать, а посмотрим факты в отчетах.
Сформируем Оборотно-сальдовую ведомость по счету 60 с максимально детальной аналитикой: контрагент → договор → документы расчетов (если используются).
Включим (если доступно в отчете) развернутое сальдо и сравним: по счету 60 итог 0, но по 60.01 есть кредит и одновременно по 60.02 есть дебет — классический признак «не произошло зачета аванса» или «оплата привязалась не туда».
Провалимся в расшифровку по проблемному контрагенту и увидим, по каким документам/договорам висит остаток: часто выясняется, что оплата «сидит» на одном договоре, а поступление/акт — на другом, или документы расчетов разные.
Ключевая мысль: если в 60.01 «оплат не видно», это почти всегда означает, что оплата отражена как аванс (60.02) или привязана к другой аналитике (другой договор/другой документ расчетов/другая организация/валюта).
Разберем по шагам, что проверить в документе оплаты (обычно это «Списание с расчетного счета», «Платежное поручение исходящее», либо документ создается из банковской выписки).
Проверим вид операции в документе оплаты. Для поставщиков это, как правило, «Оплата поставщику». Если вид операции неверный, программа может вести себя непредсказуемо в части взаиморасчетов.
Проверим реквизит «Погашение задолженности». В зависимости от конфигурации/версии он может быть «Автоматически», «По документу», «Не погашать» (формулировки могут отличаться).
Посмотрим на типовые сценарии:
Если задолженность уже есть (мы получили товары/услуги и должны поставщику), то для корректного попадания оплаты в 60.01 удобнее выбрать «По документу» и указать конкретный документ поступления/акт, либо оставить «Автоматически», но убедиться, что программа действительно видит долг.
Если задолженности нет (платим заранее), программа закономерно отнесет сумму на 60.02 как аванс. Тогда ждать, что оплата появится в 60.01, не нужно: она появится там только после зачета аванса при поступлении.
Проверим договор. Очень частая причина — платеж ушел по договору «Основной», а поступление оформлено по договору «Поставки 2025», или наоборот. При этом по счету 60 общий итог может быть нулевой, но по субсчетам и по договорам будет «перекос».
Если у нас включены расчеты по документам, проверим заполнение «Документа расчетов» (или аналогичного реквизита). Ошибка здесь приводит к тому, что оплата «лежит» на закрытом/старом документе расчетов и не зачитывается.
После исправлений действуем дисциплинированно: перепроведем платеж, затем перепроведем поступление/акт, затем заново сформируем ОСВ. Если цепочка документов длинная, перепроведение делаем в хронологическом порядке — это принципиально для взаиморасчетов.
Если оплата действительно была авансом (и ушла на 60.02), то закрытие происходит не «само по себе», а в момент, когда мы отражаем поступление товаров/услуг. Тогда 1С должна сформировать зачет: Дт 60.01 Кт 60.02 (или эквивалентные движения по взаиморасчетам).
Разберем по шагам, что проверить в документе поступления:
Откроем документ поступления (акт/накладная) и проверим настройку зачета аванса. В некоторых случаях там есть выбор «Автоматически», «По документу», «Не зачитывать».
Важно: если стоит «Не зачитывать», аванс останется на 60.02, а на 60.01 появится задолженность по поставке, и в итоге мы получим тот самый перекос «дебет 60.02 + кредит 60.01».
Если выбрали «По документу», то укажем конкретную оплату (платежный документ), которую нужно зачесть. Это особенно полезно, когда оплат несколько или когда автоматический выбор ошибается.
Проверим, что контрагент и договор в оплате и поступлении совпадают.
Перепроведем поступление и снова сформируем ОСВ по 60.01 и 60.02.
Если после корректного зачета у нас все равно остаются хвосты, переходим к более «сильным» инструментам — но по-прежнему типовыми методами.
Бывает так: документы оформлены, но сальдо по 60.01/60.02 не закрывается из-за ошибок выбора документов расчетов, смены договора «задним числом», ручных корректировок или исторических «наследий». Тогда применим документ «Корректировка долга» — это официальный типовой способ привести расчеты в порядок.
Разберем, какие варианты чаще всего помогают именно для 60.01/60.02:
«Зачет авансов» — применяем, когда у одного и того же контрагента и договора висит аванс на 60.02 и задолженность на 60.01, а автоматический зачет по документам не случился.
Действуем так: создаем документ, выбираем вид операции «Зачет авансов», заполняем остатками по взаиморасчетам, проверяем, что к зачету попали нужные суммы и нужные документы/договор, проводим и перепроверяем ОСВ.
«Перенос задолженности» — используем, когда проблема в аналитике: оплата висит на одном договоре/документе расчетов, а поступление — на другом. Здесь наша цель — перенести остаток так, чтобы оплата и поставка встретились в одном разрезе аналитики.
«Зачет задолженности» — применяем для взаимозачетов (когда поставщик одновременно нам должен, или есть встречные обязательства), но в контексте 60.01/60.02 чаще полезны первые два пункта.
Акцентируем: корректировку долга используем осознанно. Сначала выясняем причину перекоса, а затем фиксируем правильный результат документом, а не «красивой ручной проводкой».
Одна из самых частых причин «по 60 все хорошо, а по 60.01 оплаты не видно» — это когда цепочка документов распалась по аналитике. Разберем типовые варианты.
Два договора с одинаковым названием (или почти одинаковым). Тогда платеж мог попасть на договор-дубль, а поступление — на «правильный» договор. В результате в целом по контрагенту может быть ноль, но по договору — перекос.
Что делаем: открываем документы оплаты и поступления, сравниваем договоры, выбираем один «эталонный» договор и приводим документы к нему. Затем перепроводим документы по порядку и контролируем результат ОСВ.
В одном договоре включены расчеты «по документам», а в другом нет. При смешивании таких договоров у одного контрагента 1С будет по-разному формировать аналитику и выбирать документы расчетов.
Что делаем: унифицируем подход. Если расчеты должны быть по документам — включаем этот режим последовательно и следим, чтобы во всех документах был корректный «документ расчетов». Если расчеты по документам не нужны — не смешиваем режимы в рамках одного и того же реального договора/цепочки операций.
Оплата «привязалась» к старому закрытому документу расчетов. Это отдельный болезненный случай: в проводках платежа программа может подставлять «старые документы расчетов, которые давно закрыты», и в итоге зачет с текущей поставкой не происходит.
Что делаем: выясняем, к какому документу расчетов привязана оплата, и переносим остаток на актуальный документ (через «Перенос задолженности» или через корректную перепривязку в документах с перепроведением цепочки).
Проверочный принцип: для корректного закрытия 60.01/60.02 у нас должны совпасть как минимум контрагент и договор, а при учете «по документам» — еще и документ расчетов. Если совпадения нет, закрытия по субсчетам можно не дождаться.
Иногда причина не в том, что данные введены «не так», а в том, что последовательность проведения нарушена: документы вводили задним числом, меняли даты, переносили базы, обновляли, делали ручные операции, а взаиморасчеты остались «в неправильном порядке».
Тогда действуем системно:
Сначала восстановим последовательность расчетов (если в нашей конфигурации доступна сервисная обработка наподобие «Восстановление состояния расчетов» или «Восстановление последовательностей по расчетам»). В некоторых конфигурациях эта обработка показывает «границу» по расчетам (по приобретению/по реализации) — это важно, чтобы случайно не «залезть» слишком далеко в закрытые периоды.
Затем перепроведем документы хронологически: сначала оплаты (если они были раньше), затем поступления/акты, затем корректировки (если есть).
После перепроведения снова сформируем ОСВ по 60.01 и 60.02 в разрезе контрагента/договора/документа расчетов и убедимся, что перекос ушел.
Важно: «групповое перепроведение» само по себе не всегда лечит ситуацию, если у документов неправильно заполнена аналитика. Поэтому перед массовыми действиями мы обязательно делаем локальную диагностику по проблемному контрагенту.
Если мы видим, что оплата или остатки «залипли» на закрытых документах расчетов, а стандартными перепроведениями и корректировкой долга проблема не уходит, подключим диагностику на уровне данных учета.
В обсуждениях по подобным ошибкам часто предлагают проверить остатки по регистру бухгалтерии и посмотреть, нет ли «пересорта» (остатков там, где их быть не должно). Для этого используем запрос к РегистрБухгалтерии.Хозрасчетный.Остатки.
Посмотрим на минимальный диагностический запрос (идея — получить остатки по счету и контрагентам и увидеть «лишние» документы расчетов):
ВЫБРАТЬ *
ИЗ
РегистрБухгалтерии.Хозрасчетный.Остатки(,
Счет = &Счет
И Субконто1 В (&Контрагенты)
)
Дальше действуем логично:
Находим строки, где остатки висят на «не тех» документах расчетов (например, на давно закрытых или на неожиданных основаниях).
Делаем вывод: зачет не случается не потому, что «не работает 1С», а потому что оплата/поставка оказались в разных «корзинах» аналитики.
Исправляем: либо перепривязываем документы (если конфигурация позволяет корректно сменить документ расчетов), либо переносим остатки типовым документом «Корректировка долга» (обычно «Перенос задолженности»), чтобы остаток оказался на актуальных документах.
Иногда в обсуждениях встречается более «тяжелый» запрос, который агрегирует остатки по счетам расчетов/контрагентам/договорам/документам расчетов/валюте/подразделению. Приведем характерный фрагмент, чтобы понимать, какие поля участвуют в проблеме:
ВЫБРАТЬ
Остатки.Счет КАК СчетРасчетов,
Остатки.Субконто1 КАК Контрагент,
Остатки.Субконто2 КАК ДоговорКонтрагента,
Остатки.Субконто3 КАК ДокументРасчетов,
ЕСТЬNULL(Остатки.Валюта, ЗНАЧЕНИЕ(Справочник.Валюты.ПустаяСсылка)) КАК Валюта,
ЕСТЬNULL(Остатки.Подразделение, &ПустоеПодразделение) КАК Подразделение
ИЗ
РегистрБухгалтерии.Хозрасчетный.Остатки(
&МоментВремениОстатков,
Счет В (&СчетаКонтрагентыДоговоры),
&ВидыСубконтоКонтрагентыДоговоры,
Организация = &Организация
И Субконто1 В (&Контрагенты)
И Субконто2 В (&Договоры)
) КАК Остатки
Если такая диагностика показывает, что остатки «размазаны» по закрытым документам расчетов, делаем правильный вывод: пересчет итогов сам по себе не исправит логику учета. Нам нужно именно перераспределить остатки в корректную аналитику (типовым документом или обработкой, если у нас много строк и типовыми средствами это делать слишком долго).
Теперь соберем причины в понятный список и привяжем к действиям.
Оплата ушла на 60.02 как аванс. Тогда в 60.01 ее и не должно быть до момента зачета.
Что делаем: проверяем настройку зачета аванса в поступлении, проводим поступление с зачетом, либо делаем «Корректировку долга» видом «Зачет авансов».
Оплата и поступление на разных договорах.
Что делаем: унифицируем договор в документах, перепроводим по порядку.
Расчеты по документам включены, но документ расчетов заполнен по-разному (или оплата привязана к старому документу).
Что делаем: приводим документ расчетов к одному основанию (перепривязка/перенос задолженности), затем перепроведение цепочки.
Есть дубли договоров или контрагентов, которые внешне выглядят одинаково.
Что делаем: проверяем справочники, устраняем дубль организационно (выбираем один объект и используем его в документах), переносим остатки при необходимости.
Нарушена последовательность проведения (ввод задним числом, перенос данных, обновления, ручные операции).
Что делаем: восстанавливаем последовательность расчетов (если доступно), перепроводим документы в хронологии.
Рассмотрим подробнее «жесткий» сценарий, который часто встречается на практике: документы перепроводили, а оплаты в 60.01 так и нет, и перекос по 60.01/60.02 не исчезает.
Не делаем ручные проводки ради «красивой ОСВ». Ручная проводка Дт 60.01 Кт 60.02 может на время спрятать симптом, но оставит проблему в аналитике, и позже она всплывет в другом месте (сверки, НДС, взаиморасчеты, закрытие периода).
Ищем первичный документ, где началось расхождение. Для этого используем карточку счета 60.01/60.02 в разрезе аналитики и смотрим самый ранний документ, где остаток «встал не туда».
Проверяем, не использовались ли ручные операции по счету 60. Если да — оцениваем, не нарушили ли они регистры/аналитику расчетов.
Применяем «Корректировку долга» (зачет/перенос) как типовой способ исправления следствия, но параллельно устраняем причину: неверный договор, неверный документ расчетов, неверный выбор «погашения задолженности».
Чтобы подобные истории не повторялись, зафиксируем практические правила, которые реально экономят время:
Ведем единую «цепочку» документов: оплата → поступление/акт → зачет аванса (если оплата до поступления) → доплата (если частично).
Не смешиваем режимы учета (по документам/не по документам) в рамках одного реального договора. Если решили вести по документам — ведем последовательно.
Следим за договором в каждом документе. Если у контрагента несколько договоров, договариваемся внутри компании о правилах: один основной договор для типовых оплат/поставок, отдельные договоры — только для исключений.
После загрузки банковских выписок проверяем заполнение ключевых реквизитов: контрагент, договор, назначение, «погашение задолженности».
Если видим перекос в ОСВ — разбираемся сразу, пока документов мало. Чем дольше откладываем, тем больше «пересорт» по документам расчетов и тем сложнее автоматом закрыть хвосты.
Закрепим алгоритм, который можно повторять каждый раз.
Сформируем ОСВ по 60 с детализацией до договора и документа расчетов.
Выясним: оплата сидит на 60.02 (аванс) или на 60.01 (погашение долга).
Проверим совпадение контрагента и договора во всей цепочке документов.
Если учет по документам — проверим «документ расчетов» в оплате и поступлении.
Перепроведем документы строго по хронологии (оплата/поступление/зачет).
Если перекос остался — оформим «Корректировку долга» (зачет авансов или перенос задолженности) и снова проверим ОСВ.
Если остатки «залипли» на закрытых документах — диагностируем через РегистрБухгалтерии.Хозрасчетный.Остатки и перераспределим остатки в корректную аналитику.
Итог: счета 60.01 и 60.02 «не закрываются» не потому, что в 1С «пропали оплаты», а потому что оплата оказалась в другой логике учета (аванс/долг) или в другой аналитике (договор/документ расчетов). Если действовать по шагам — сначала диагностика по аналитике, затем исправление реквизитов документов, затем корректировка долга при необходимости — взаиморасчеты приводятся в порядок без рискованных ручных проводок и без сюрпризов в отчетности.