Разберем ситуацию, когда в программе «1С:Бухгалтерия предприятия 3.0» платеж поставщику вместо полного отражения по дебету счета 60.02 частично попадает на счет 60.01, а в оборотно-сальдовой ведомости появляется красная сумма с минусом. На первый взгляд может показаться, что программа формирует неправильную проводку. Однако чаще всего причина заключается не в настройках самого платежа, а в нарушенной последовательности документов, неверно определенном зачете задолженности или ошибке в аналитике взаиморасчетов.
Рассмотрим подробнее, как программа определяет счет учета оплаты, почему сумма может разделяться на две части, как найти документ-источник ошибки и какими способами восстановить корректный учет расчетов с поставщиком.
Для начала зафиксируем назначение субсчетов, чтобы правильно оценить результат проведения документов. Счет 60.01 используется для учета расчетов с поставщиками и подрядчиками по уже полученным товарам, работам, услугам, основным средствам, материалам и другим поступлениям. Обычно кредитовое сальдо по счету 60.01 означает задолженность организации перед поставщиком.
Счет 60.02 предназначен для учета авансов, выданных поставщикам. Дебетовое сальдо по этому счету означает, что организация перечислила деньги поставщику раньше, чем получила товары, работы или услуги. Иными словами, это дебиторская задолженность поставщика перед организацией.
Когда организация перечисляет деньги поставщику, программа должна определить экономический смысл платежа. Если перед поставщиком уже есть задолженность по ранее отраженному поступлению, платеж является оплатой долга и должен попасть на счет 60.01. Если задолженности нет, перечисленные деньги считаются авансом и должны быть отражены по счету 60.02.
Рассмотрим стандартную ситуацию. Организация получила товар на сумму 120 000 рублей. Документ Поступление (акт, накладная, УПД) сформировал задолженность перед поставщиком. После проведения поступления возникает проводка по кредиту счета 60.01. Затем организация оплачивает поставщику эти 120 000 рублей. В этом случае документ Списание с расчетного счета должен сформировать проводку по дебету счета 60.01 и кредиту счета 51.
Если же организация сначала перечисляет поставщику 120 000 рублей, а поступление товаров будет отражено позднее, документ Списание с расчетного счета должен сформировать проводку по дебету счета 60.02 и кредиту счета 51. После отражения поступления программа зачтет аванс проводкой по дебету счета 60.01 и кредиту счета 60.02.
Таким образом, сама проводка между счетами 60.01 и 60.02 не является ошибкой. Это нормальный механизм зачета аванса при поступлении товаров, работ или услуг. Ошибка возникает тогда, когда программа закрывает несуществующую задолженность, повторно использует один аванс или распределяет платеж не по тем документам расчетов.
Разделение одной оплаты между счетами 60.01 и 60.02 может быть полностью корректным. Рассмотрим пример. На дату оплаты у организации есть задолженность перед поставщиком в размере 70 000 рублей. Организация перечисляет поставщику 100 000 рублей. Программа при автоматическом погашении задолженности сначала закроет долг на сумму 70 000 рублей через счет 60.01, а оставшиеся 30 000 рублей учтет как аванс по счету 60.02.
В такой ситуации разделение платежа является логичным. Программа не может всю сумму признать авансом, если часть суммы предназначена для оплаты уже отраженной задолженности. При включенном варианте Погашение задолженности со значением «Автоматически» программа сначала анализирует состояние расчетов по выбранному поставщику и договору, а затем распределяет платеж между задолженностью и авансом.
Проблемой является ситуация, когда фактической задолженности на дату платежа нет, но программа все равно часть суммы относит на 60.01. В таком случае нужно выяснить, какую задолженность программа пытается погасить. Как правило, она находится в более раннем периоде и связана с нарушенной последовательностью проведения документов, неверной аналитикой или ошибочно проведенной корректировкой долга.
Не будем ориентироваться только на итоговую сумму по счету 60. Общий остаток по контрагенту может выглядеть правильным, но внутри аналитики могут одновременно присутствовать дебетовое сальдо по 60.02 и кредитовое сальдо по 60.01. В результате в общем итоге они частично сворачиваются, однако бухгалтерская отчетность, анализ взаиморасчетов и сверка с поставщиком могут быть искажены.
Красная сумма с минусом в оборотно-сальдовой ведомости или карточке счета обычно означает отрицательное значение по выбранной стороне учета. Для счета 60.01 такая ситуация часто говорит о том, что программа отразила оплату как погашение задолженности, которой фактически не должно было быть на эту дату.
Например, программа могла провести оплату поставщику по дебету 60.01, хотя поступление товаров было отражено позже, отменено, перепроведено иной датой или зачтено другим платежом. В результате по документу расчетов появляется отрицательный остаток. В отчетах он может отображаться красным цветом.
Важно не пытаться устранить красное сальдо только изменением счета в одном текущем банковском документе. Если причина находится в старом периоде, изменение последней оплаты обычно лишь перемещает проблему. После следующего поступления или следующего платежа ошибка снова проявится, потому что программа продолжит использовать неверную цепочку расчетов.
В рассматриваемой ситуации ключевой вывод заключается в том, что обычного перепроведения отдельных документов может быть недостаточно. Необходимо восстановить последовательность расчетов начиная с периода, в котором впервые появилось неправильное сальдо. По данным разбора исходной ситуации, проверку следует начинать со второго квартала 2023 года.
Многие пользователи снимают документы с проведения, затем проводят их заново в визуальном порядке по датам. Иногда это помогает, но при сложной цепочке взаиморасчетов такой способ не гарантирует восстановления корректной последовательности. В базе могут быть документы, которые не попали в ручную выборку, документы с одинаковой датой, операции прошлого периода, документы корректировки долга, документы с иной аналитикой или загруженные банковские выписки.
Кроме того, программа учитывает не только дату документа, но и последовательность формирования расчетов. Если документ поступления был введен позднее банковской выписки, затем был перепроведен задним числом или изменен после закрытия месяца, последовательность взаиморасчетов могла нарушиться. Внешне документы могут стоять в правильной календарной очередности, но расчетная последовательность внутри информационной базы уже будет неактуальной.
Рассмотрим пример. Оплата поставщику отражена 10 апреля как аванс. Позднее бухгалтер вводит поступление от 5 апреля. После проведения поступления программа видит, что к моменту оплаты уже существовала задолженность, и может переклассифицировать оплату с 60.02 на 60.01. Если затем документы перепроводятся не от самой ранней даты проблемы, взаиморасчеты могут остаться сформированными некорректно.
Еще одна распространенная ситуация возникает, когда один и тот же платеж используется для зачета нескольких поступлений. Например, платеж на 50 000 рублей был зачтен документом поступления на 30 000 рублей, а затем другой документ поступления также использовал этот же платеж для зачета аванса. В результате на счетах 60.01 и 60.02 появляются отрицательные остатки, хотя общий оборот по контрагенту может выглядеть приемлемо.
Поэтому не будем начинать исправление с последнего банковского документа. Сначала найдем момент, в котором впервые возникла красная сумма или развернутое сальдо. Именно эта дата определит, с какого периода необходимо восстановить последовательность проведения.
Первый этап — сформируем отчетность с максимальной детализацией. Нам потребуется не только общая оборотно-сальдовая ведомость по счету 60, но и детализация по субсчетам, контрагенту, договору и документам расчетов с контрагентами.
Отчеты и сформируем отчет Оборотно-сальдовая ведомость по счету.60.Рассмотрим подробнее, почему важна именно аналитика по документам расчетов. Счет 60 ведется не только в разрезе контрагента. Для правильного автоматического зачета программа должна понимать, по какому договору и какому документу возник долг или аванс. Если у одного поставщика несколько поступлений и несколько платежей, общий остаток по договору не всегда показывает, какой именно документ был закрыт программой.
После формирования оборотно-сальдовой ведомости откроем отчет Карточка счета отдельно для счетов 60.01 и 60.02. Установим отбор по тому же контрагенту и договору. Затем найдем первую операцию, после которой возникло отрицательное сальдо.
Не будем ограничиваться последним месяцем. Если в карточке счета видно, что красная сумма впервые появилась, например, в июне 2023 года, именно июнь 2023 года нужно считать стартовой точкой анализа. Любые документы, проведенные после этой даты, могут быть следствием первоначальной ошибки.
Затем откроем документ, который сформировал проблемную проводку. Для платежей это обычно документ Списание с расчетного счета. Для возникновения задолженности — документ Поступление (акт, накладная, УПД). Для ручной корректировки — документ Корректировка долга или Операция, введенная вручную.
В каждом документе проверим проводки через команду ДтКт. Нам нужно установить не только счет учета, но и аналитику проводки: контрагента, договор и документ расчетов. Часто причина находится именно в том, что счет выглядит правильным, но документ расчетов выбран неверно или заполнен не полностью.
Основной документ, который отражает оплату поставщику, — Списание с расчетного счета с видом операции «Оплата поставщику». Откроем проблемный платеж и последовательно проверим его реквизиты.
Договоры, который указан в поступлениях.60.01.60.02.Наиболее важный реквизит в этой ситуации — Погашение задолженности. В документе оплаты поставщику обычно используются три варианта: «Автоматически», «По документу» и «Не погашать». Каждый вариант влияет на распределение платежа между счетами 60.01 и 60.02.
При варианте «Автоматически» программа анализирует расчеты с поставщиком в разрезе выбранного договора. Если долг есть, программа сначала направляет платеж на его погашение через счет 60.01. Если долг отсутствует, программа отражает платеж как аванс по счету 60.02. Если долг меньше платежа, сумма будет разделена между двумя счетами.
При варианте «По документу» программа направляет оплату на конкретный документ расчетов. Этот вариант следует использовать, когда необходимо погасить определенное поступление, конкретный счет, отдельный заказ, отдельный этап работ или определенный акт. Такой способ позволяет избежать автоматического распределения платежа по другим документам договора.
При варианте «Не погашать» программа не закрывает текущую задолженность по договору и относит перечисленную сумму на счет, указанный в поле Счет авансов. То есть при счете авансов 60.02 вся сумма оплаты будет отражена как аванс.
Однако не будем использовать значение «Не погашать» только для того, чтобы скрыть красное сальдо. Этот вариант применим, когда по экономическому смыслу платеж действительно должен быть признан авансом и не должен закрывать существующую задолженность. Если организация фактически оплачивает старый долг, искусственное отнесение платежа на 60.02 приведет к развернутому сальдо и усложнит последующий зачет.
Наличие одного договора с поставщиком не означает, что программа всегда сможет правильно распределить авансы. При автоматическом зачете программа видит все поступления и все авансы внутри договора. Если поставщик работает по множеству счетов, заказов, актов, этапов или поставок, программа может зачесть аванс по хронологии, а не так, как стороны договорились между собой.
Например, организация перечислила аванс под будущую поставку по счету № 25. Одновременно по тому же договору остается неоплаченный акт по счету № 14. Если в платежном документе оставить вариант «Автоматически», программа может сначала погасить долг по старому акту, а остаток признать авансом. С точки зрения алгоритма учета это корректно, но с точки зрения фактического назначения платежа может быть неверно.
В такой ситуации рассмотрим два способа организации учета. Первый способ — использовать в платежном документе вариант «По документу» и выбрать конкретное поступление, которое необходимо оплатить. Второй способ — вести расчеты по отдельным договорам, заказам или счетам, если это соответствует договорной модели организации и требуется для регулярной сверки с поставщиком.
Не будем создавать отдельные договоры без необходимости. Если поставщик один, договор долгосрочный и расчетов много, большое количество договоров может усложнить работу. Но если организация должна отслеживать авансы по отдельным счетам или поставкам, дополнительная аналитика в виде отдельных договоров или документов расчетов помогает исключить автоматическое смешение платежей.
При работе с отдельными счетами можно использовать понятное правило: один договор в программе соответствует одному значимому направлению взаиморасчетов. Например, отдельный договор можно вести для отдельного проекта, заказа, договора поставки, крупного этапа работ или отдельного счета, который должен быть закрыт конкретным авансом.
Следующий этап — проанализируем документы Поступление (акт, накладная, УПД). Именно при проведении поступления программа обычно выполняет зачет ранее выданного аванса проводкой между счетами 60.01 и 60.02.
Откроем документы поступления, которые относятся к периоду появления проблемы. В каждом документе проверим контрагента, договор, дату, сумму, счета расчетов и способ зачета аванса. Особое внимание уделим поступлениям, которые были введены задним числом или перепроводились после отражения оплаты.
В документе поступления программа обычно предлагает варианты зачета авансов: «Автоматически», «По документу» и «Не зачитывать». При варианте «Автоматически» программа самостоятельно подбирает авансы по договору. При варианте «По документу» можно указать конкретные платежные документы и сумму зачета. При варианте «Не зачитывать» программа не будет автоматически закрывать аванс при проведении поступления.
Если в организации необходимо, чтобы конкретный аванс закрывал конкретную поставку, рассмотрим вариант «По документу». В этом случае в поступлении следует выбрать платежный документ, который должен быть зачтен. При необходимости можно скорректировать сумму зачета вручную, если аванс используется частично.
Рассмотрим пример. Организация перечислила поставщику 150 000 рублей авансом. Затем получила товары на 100 000 рублей и позднее услуги на 50 000 рублей. Если все документы оформлены по одному договору и везде установлен автоматический зачет, программа может закрыть аванс корректно. Но если нужно, чтобы первые 100 000 рублей относились к товарам, а оставшиеся 50 000 рублей — к услугам, точнее использовать зачет по документу.
Не будем смешивать настройки платежа и настройки поступления. Значение «Не погашать» в банковском документе определяет, будет ли платеж закрывать текущую задолженность. Значение «Не зачитывать» в документе поступления определяет, будет ли поступление автоматически закрывать ранее отраженный аванс. Это разные механизмы, и изменение только одного из них не всегда дает ожидаемый результат.
Если в программе используется один договор, но проблема возникает только с одним поставщиком, обязательно проверим аналитику. Очень часто причина скрывается не в счетах учета, а в том, что в разных документах выбран разный элемент справочника, хотя названия выглядят одинаково.
Сначала проверим справочник Контрагенты. В нем могут существовать дубли поставщика: один контрагент создан по полному названию, другой — по сокращенному, третий — после загрузки из банка или обмена с другой программой. Если оплата проведена по одному элементу справочника, а поступление отражено по другому, программа не сможет корректно связать расчеты.
Затем проверим договоры контрагента. В карточке поставщика могут быть несколько договоров с одинаковыми или похожими названиями. Например, один договор может быть создан вручную, другой — автоматически при загрузке платежа, третий — после переноса данных. Визуально они могут выглядеть одинаково, но для учета это разные аналитические объекты.
Отдельно проверим заполнение субконто Документы расчетов с контрагентами. Если часть документов проведена без выбора документа расчетов, а другая часть содержит конкретный документ, возможны несоответствия в детализации. В отчетах такие случаи часто проявляются пустыми строками, незаполненной аналитикой или остатками, которые невозможно сопоставить с конкретным платежом либо поступлением.
Не будем считать пустую аналитику незначительной технической особенностью. Если в отчетах по счету 60 встречаются строки без договора или без документа расчетов, это признак того, что автоматический зачет может работать непредсказуемо. Такие записи нужно анализировать отдельно и связывать с исходными документами.
Если период, в котором возникла ошибка, еще открыт для корректировки, основным способом исправления является восстановление последовательности проведения документов. Начинать нужно не с текущего платежа, а с самой ранней даты, когда в карточке счета появилось неверное сальдо.
В рассматриваемом случае следует проверить документы начиная со второго квартала 2023 года. Это не означает, что каждый документ этого периода обязательно содержит ошибку. Однако именно с этой даты нужно восстановить корректную последовательность, чтобы программа заново рассчитала взаиморасчеты по поставщику.
Перед началом исправления обязательно создадим резервную копию информационной базы. Перепроведение документов может изменить бухгалтерские проводки, налоговый учет, зачет авансов, курсовые разницы, учет НДС и результаты закрытия месяца. Резервная копия позволит сравнить результат и при необходимости вернуться к исходному состоянию. При обслуживании нескольких баз процедуру перед проведением технических работ можно вынести в автоматическое архивирование и обслуживание баз 1С.
60.01 или 60.02.Операции и перейдем в обработку Закрытие месяца.Перепроведение документов.60.01 и 60.02 с максимальной аналитикой.Рассмотрим подробнее, почему рекомендуется использовать именно обработку закрытия месяца. Этот механизм перепроводит документы с учетом последовательности и пересчитывает зависимые операции. Ручное перепроведение нескольких документов в журнале может не затронуть документы, которые влияют на расчеты косвенно, а также не обновить последствия закрытия месяца.
Не будем выполнять перепроведение только за последний месяц, если первая ошибка обнаружена в более раннем периоде. Например, если отрицательное сальдо появилось в июне 2023 года, а сейчас перепроводятся документы только за май 2026 года, программа не сможет исправить первоначальное распределение расчетов.
После перепроведения обязательно проверим не только общий остаток по счету 60, но и остатки в разрезе документов. Правильным результатом будет отсутствие необъяснимого красного сальдо, отсутствие одновременного аванса и задолженности по одному и тому же документу расчетов, а также соответствие данных внутреннему акту сверки с поставщиком.
Если ошибка возникла в закрытом периоде, который нельзя перепроводить из-за уже сданной отчетности, установленной даты запрета редактирования или организационной политики, рассмотрим исправление текущим периодом. В такой ситуации не следует перепроводить старые документы без предварительной оценки влияния на бухгалтерскую и налоговую отчетность.
Для устранения развернутого сальдо между счетами 60.01 и 60.02 можно использовать документ Корректировка долга. Этот документ применяется, когда нужно зачесть аванс и задолженность, перенести остатки между документами расчетов или оформить взаимозачет в рамках одного поставщика.
Если необходимо зачесть аванс поставщику в счет задолженности перед этим же поставщиком, рассмотрим операцию «Зачет авансов». В документе укажем поставщика, организацию и договор. Затем подберем документы, по которым числится дебиторская задолженность в виде аванса, и документы, по которым числится кредиторская задолженность.
После заполнения документа проверим, чтобы сумма аванса и сумма задолженности, участвующие в зачете, совпадали. Если суммы не равны, не будем проводить документ автоматически. Сначала определим, какая часть аванса действительно должна быть зачтена, а какая должна остаться на счете 60.02.
В ряде случаев может использоваться вариант «Прочие корректировки». Такой вариант удобен, когда необходимо вручную выбрать конкретные документы расчетов, исключить лишние строки из автоматического заполнения или устранить последствия старой ошибки, которая затрагивает несколько документов.
При использовании «Прочих корректировок» не будем механически заполнять все найденные остатки. Необходимо убедиться, что в документ попали только те строки, которые действительно должны быть взаимозачтены. Если программа подобрала задолженность по другому договору, другой поставке или документу, который должен остаться открытым, такую строку следует удалить из корректировки.
Корректировку долга рекомендуется проводить датой, которая не нарушит порядок учета и не попадет в закрытый период. Обычно выбирают последний день открытого месяца или квартала. При этом не следует устанавливать документ последней секундой дня, поскольку это может осложнить последующее упорядочивание документов и анализ последовательности расчетов.
При корректном зачете выданного аванса в счет задолженности перед поставщиком программа должна сформировать проводку по дебету счета 60.01 и кредиту счета 60.02. Экономический смысл такой проводки заключается в следующем: задолженность перед поставщиком уменьшается, а ранее отраженный аванс перестает числиться отдельным дебиторским требованием.
Например, на счете 60.01 числится кредиторская задолженность перед поставщиком в размере 80 000 рублей. Одновременно на счете 60.02 числится аванс этому же поставщику в размере 80 000 рублей. Если эти суммы относятся к одному договору и должны быть зачтены, корректировка долга должна убрать оба остатка.
После проведения корректировки не будем сразу считать задачу решенной. Обязательно откроем проводки документа через ДтКт, проверим контрагента, договор и документ расчетов. Затем сформируем карточки счетов 60.01 и 60.02 на дату после проведения корректировки.
Если корректировка убрала общий остаток, но в разрезе документов остались красные суммы, значит проблема устранена не полностью. В таком случае нужно вернуться к аналитике документов расчетов и проверить, какие именно строки были зачтены.
Документ Операция, введенная вручную следует использовать только как исключительный способ исправления, когда стандартный документ Корректировка долга не позволяет корректно подобрать аналитику или когда требуется исправить последствия старой технической операции.
При ручной операции особенно важно заполнить все субконто по счетам расчетов. Недостаточно указать только счета 60.01 и 60.02. Необходимо заполнить контрагента, договор и соответствующий документ расчетов с контрагентом. Если аналитика будет заполнена неполностью, общий остаток может исчезнуть, но проблема останется на уровне документов расчетов.
Не будем использовать ручную операцию только ради того, чтобы «схлопнуть» остатки в оборотно-сальдовой ведомости. Такой подход может скрыть ошибку, но не восстановит корректную цепочку взаиморасчетов. Ручную операцию допустимо применять только после анализа первичных документов и понимания того, какую именно ошибку она исправляет.
После ручной операции обязательно сформируем отчет по счету 60 с группировкой по документам расчетов. Если после проводки появились строки без документа расчетов, незаполненные договоры или новые красные остатки, операцию необходимо проверить и исправить.
Отдельно проанализируем документы Корректировка долга, Операция, введенная вручную, документы возврата, корректировки поступления и документы переноса задолженности. Именно такие операции часто создают ситуацию, когда общая сумма по поставщику правильная, а распределение между 60.01 и 60.02 нарушено.
Например, бухгалтер мог вручную перенести сумму с одного субсчета на другой, не указав документ расчетов. В тот момент отчет мог выглядеть приемлемо. Позднее программа при автоматическом зачете авансов не смогла определить, к какому платежу относится остаток, и начала распределять последующие оплаты между задолженностью и авансами неверно.
Другой типовой случай — корректировка долга была проведена по контрагенту, но по другому договору. В общем анализе по поставщику сумма может свернуться, однако в разрезе договоров останутся одновременно долг и аванс. При следующем платеже программа будет анализировать только договор, указанный в банковском документе, и может отнести часть суммы на 60.01.
Поэтому при поиске причины обязательно просмотрим все корректировки долга по проблемному поставщику начиная с периода появления ошибки. Проверим дату, договор, состав подобранных документов, счета учета и аналитику проводок.
Если банковские выписки загружаются автоматически, не будем считать, что все поля всегда определяются безошибочно. При загрузке программа может подставить договор по умолчанию, создать новый договор, выбрать не того контрагента или перенести настройки из предыдущего платежа.
После загрузки выписки следует проверить документы Списание с расчетного счета, особенно если платеж связан с новым договором, новым счетом поставщика, частичной оплатой, авансом под будущую поставку или оплатой нескольких документов одной суммой.
Если учет ведется с обменом между несколькими конфигурациями, например между бухгалтерской программой и учетной системой управления торговлей, производством или услугами, необходимо проверить, не были ли документы изменены после обмена. Внешняя система может передать документ с другой аналитикой, иной датой или иной настройкой зачета, чем в бухгалтерской базе.
Не будем исправлять последствия обмена только в бухгалтерской базе, если исходная ошибка повторяется при каждой синхронизации. В таком случае необходимо определить источник некорректного реквизита и исправить правило обмена, настройку выгрузки или первичный документ в системе-источнике.
Ситуация, когда после проведения акта или поступления суммы временно «схлопываются», а после следующей оплаты снова появляется красное сальдо, является характерным признаком нарушенной аналитики или последовательности взаиморасчетов.
Когда проводится акт, программа пытается зачесть существующий аванс. Она формирует проводку между 60.01 и 60.02, поэтому общий остаток может стать нулевым. Однако если исходный платеж был связан не с тем документом, договором или задолженностью, автоматический зачет просто временно компенсирует ошибку.
После нового платежа программа снова анализирует остатки по договору. Если в системе продолжает числиться искусственная задолженность по 60.01, часть оплаты будет направлена на ее погашение. Остаток платежа программа отнесет на 60.02. В результате сумма снова разделится, а красное сальдо появится повторно.
Поэтому не будем воспринимать временное закрытие сумм после акта как подтверждение правильности учета. Проверим состояние расчетов непосредственно перед новым платежом. Если до оплаты на счете 60.01 уже есть необоснованный остаток, нужно устранить его первопричину.
Оборотно-сальдовая ведомость по счету по счету 60.60.01 и 60.02.ДтКт.Предположим, что на 15 июля у организации нет задолженности перед поставщиком. В этот день организация перечисляет 200 000 рублей в качестве предоплаты. В документе Списание с расчетного счета указан поставщик, корректный договор, счет расчетов 60.01, счет авансов 60.02, а способ погашения задолженности установлен «Автоматически».
Поскольку задолженность отсутствует, программа должна отразить всю сумму как аванс. В проводках будет дебет счета 60.02 и кредит счета 51 на 200 000 рублей. На счете 60.01 движения по этому платежу не должно быть.
20 июля организация получает товар на сумму 150 000 рублей. Документ поступления отражает стоимость товара и формирует кредиторскую задолженность по счету 60.01. Затем программа засчитывает часть ранее выданного аванса: дебет 60.01, кредит 60.02 на 150 000 рублей.
После проведения поступления на счете 60.02 остается дебетовое сальдо 50 000 рублей. Это нормальный остаток аванса. На счете 60.01 задолженность отсутствует, поскольку стоимость полученного товара полностью закрыта авансом.
Предположим, что на 15 июля перед поставщиком есть задолженность 90 000 рублей по ранее полученному товару. Организация перечисляет поставщику 140 000 рублей. В документе оплаты установлен вариант «Автоматически».
Программа должна сначала закрыть задолженность 90 000 рублей через дебет счета 60.01. Оставшиеся 50 000 рублей должны быть учтены как аванс по дебету счета 60.02. Такое разделение платежа является корректным и не требует исправления.
Если же организация намеренно перечисляет все 140 000 рублей как аванс под будущую поставку, несмотря на существующую старую задолженность, в банковском документе необходимо использовать вариант «Не погашать». Но применять этот вариант следует только тогда, когда такое распределение соответствует фактическому назначению платежа и согласовано с поставщиком.
После перепроведения документов или проведения корректировки долга не будем ограничиваться проверкой одной строки в оборотно-сальдовой ведомости. Убедимся, что расчеты корректны на всех уровнях аналитики.
60 с детализацией до документов расчетов.60.01.60.02.Анализ субконто по контрагенту и договору.Корректным считается состояние, при котором дебетовое сальдо по 60.02 действительно соответствует неотработанному авансу, а кредитовое сальдо по 60.01 соответствует реальной неоплаченной задолженности перед поставщиком. Красные остатки, отрицательные суммы по документам расчетов и пустая аналитика требуют дополнительной проверки.
Некорректное распределение авансов может повлиять не только на оборотно-сальдовую ведомость, но и на учет НДС. Если поставщик выставляет счет-фактуру на аванс, организация может отражать НДС по выданному авансу на счете 76.ВА. При зачете аванса в счет поступления программа должна корректно восстановить ранее принятый к вычету НДС.
Если аванс ошибочно числится на счете 60.02 после фактического зачета или, наоборот, оплата ошибочно попала на счет 60.01, могут возникнуть расхождения между взаиморасчетами, счетами-фактурами на аванс и данными книги покупок.
Поэтому после исправления расчетов с поставщиком дополнительно проверим, есть ли по проблемным платежам зарегистрированные документы Счет-фактура полученный на аванс, отражены ли вычеты НДС и корректно ли выполнено восстановление НДС при поступлении товаров, работ или услуг.
Не будем исправлять проводки по счету 76.ВА отдельно до восстановления расчетов на счетах 60.01 и 60.02. Сначала нужно привести в порядок первичную цепочку оплаты, аванса и поступления. После этого можно оценить необходимость исправления НДС.
В большинстве случаев причина неверного распределения оплаты заключается в логике документов, последовательности проведения или аналитике. Не следует начинать исправление с технического тестирования базы, поскольку процедура тестирования не заменяет анализ хозяйственных операций.
Техническую проверку информационной базы имеет смысл рассматривать только после того, как мы проверили документы, аналитику, последовательность проведения и корректировки долга, но получили необъяснимые результаты. Перед любыми техническими процедурами обязательно создадим резервную копию базы.
Процедура Тестирование и исправление выполняется пользователем с административными правами в режиме конфигуратора. Использовать ее следует осторожно и только при наличии резервной копии, поскольку техническое исправление не должно подменять бухгалтерское исправление документов.
Если после восстановления последовательности и проверки аналитики проблема сохраняется, целесообразно передать специалисту карточки счетов 60.01 и 60.02, ОСВ по счету 60 с детализацией, проводки проблемных документов, сведения о корректировках долга и данные о наличии обменов с другими программами.
В рассматриваемой ситуации счета расчетов и авансов в банковской выписке указаны правильно: 60.01 и 60.02. Само наличие этих счетов не гарантирует правильного распределения платежа. Программа использует их в зависимости от наличия задолженности и настроек погашения задолженности.
Если часть оплаты необоснованно попадает на 60.01, сначала найдем задолженность, которую программа пытается погасить. Для этого сформируем карточку счета и ОСВ с детализацией до документов расчетов. В данном случае анализ необходимо начинать со второго квартала 2023 года, поскольку именно с этого периода нужно восстановить последовательность документов.
Если период открыт, исправим первичные документы и выполним перепроведение через механизм закрытия месяца. Если период закрыт, не будем перепроводить старые документы без оценки последствий. Вместо этого проанализируем остатки и оформим корректировку долга с точным подбором аванса и задолженности.
Не будем устранять проблему только изменением последнего платежа или ручной проводкой без аналитики. Правильное решение состоит в восстановлении цепочки взаиморасчетов: платеж — аванс — поступление — зачет аванса — корректировка при необходимости. После этого новые оплаты поставщику будут автоматически распределяться корректно между счетами 60.01 и 60.02.
Информация носит справочный характер