Почему при УСН в 1С:Бухгалтерии оплата от покупателя не попадает в графу 5 КУДиР?

Бухгалтер 1С v8.3 (Управляемые формы) 1C:Бухгалтерия Налоговый учет Сфера услуг, туризм и социальный сектор
← На главную

При ведении налогового учета по УСН («Доходы» или «Доходы минус расходы») в программе 1С:Бухгалтерия 8.3 пользователи нередко сталкиваются с ситуацией: поступает безналичная оплата от контрагента, документ закрывает существующий долг по отгрузке, но сумма оплаты упорно не отражается в графе 5 («В т.ч. доходы, учитываемые при исчислении налоговой базы») Книги учета доходов и расходов. При этом, если сумму платежа увеличить сверх суммы задолженности, появившийся аванс (переплата) сразу же попадает в графу 5 КУДиР. Разберем по шагам механизм возникновения этой ошибки, выясним причину такого поведения системы и рассмотрим способы исправления учета.

Механизм распределения доходов в подсистеме УСН

Чтобы понять логику программы, проанализируем, как 1С определяет налогооблагаемый доход при проведении банковской выписки:

  1. Поступление аванса (проводка Дт 51 Кт 62.02): программа автоматически расценивает авансовый платеж как доход текущего периода по основной системе налогообложения организации (УСН) и сразу включает всю сумму предоплаты в графу 5 КУДиР.
  2. Погашение дебиторской задолженности (проводка Дт 51 Кт 62.01): программа не может признать доход вслепую только по факту прихода денег. Она обращается к первичному документу закрываемой отгрузки (документу Реализация (акт, накладная)), чтобы определить, к какой именно деятельности относилась эта реализация.
  3. Особый порядок налогообложения: если отгрузка по учетным регистрам была отнесена к деятельности с особым порядком (например, патент или ЕНВД), то поступление денежных средств в счет ее оплаты не признается доходом УСН. Поэтому сумма погашения задолженности отсекается из графы 5 КУДиР, а любая переплата (аванс сверх долга) отправляется в доходы УСН.

Основная причина: коллизия в системе налогообложения номенклатуры

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

Разберем, как устранить эту ошибку:

  1. Перейдем в раздел Справочники и откроем справочник Номенклатура.
  2. Найдем ту услугу или товар, по которому происходила отгрузка.
  3. Откроем историю реквизита Система налогообложения (или перейдем по соответствующей ссылке в карточке номенклатуры).
  4. Проверим список записей на наличие дубликатов с некорректной датой вступления в силу. Если обнаружена лишняя запись, удалим ее либо скорректируем дату начала действия.
  5. После ис source-настроек обязательно выполним последовательное перепроведение цепочки документов: сначала документ реализации, затем документ оплаты (Поступление на расчетный счет).

Другие распространенные причины неверного отражения дохода

Если в истории номенклатуры все заполнено корректно, проанализируем альтернативные места настроек, из-за которых программа может исключать сумму из графы 5:

  1. Неверный счет учета доходов в реализации (90.01.1 против 90.01.2): выручка от реализации по УСН должна списываться на счет 90.01.1 («Выручка по деятельности с основной системой налогообложения»). Если в проводках документа стоит субсчет 90.01.2 («Выручка по отдельным видам деятельности с особым порядком налогообложения»), программа зафиксирует, что долг покупателя не относится к УСН. Проверим регистр сведений Счета учета номенклатуры: для услуги или группы услуг не должно быть задано жесткое правило со счетом 90.01.2.
  2. Настройки номенклатурной группы: откроем карточку номенклатурной группы, указанной в строке реализации, и убедимся, что для нее не включен признак учета по патенту или иному специальному налоговому режиму.
  3. Режим погашения задолженности в банковской выписке: в документе Поступление на расчетный счет обратим внимание на реквизит Погашение задолженности. Если установлен переключатель По документу, а выбранный документ уже погашен или относится к другому договору/периоду, алгоритм зачета долга отработает с ошибкой. Рекомендуется использовать режим Автоматически.
  4. Вид договора контрагента: проверим договор с покупателем. Вид договора должен быть строго С покупателем. При выборе вида С комиссионером (агентом) расчеты подчиняются другой логике, и прямая выписка не регистрирует доход в КУДиР до ввода отчета комиссионера.
  5. Ручные корректировки движений: проверим, не включен ли в документах отгрузки или оплаты флажок Ручная корректировка (разрешает редактирование движений документа). При включенной ручной корректировке программа перестает автоматически обновлять движения по служебным регистрам УСН, в частности по регистру накопления Книга учета доходов и расходов (раздел I).

Диагностика с помощью встроенных отчетов 1С

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

  1. Анализ состояния налогового учета по УСН: перейдем в раздел Отчеты — УСН — Анализ состояния налогового учета по УСН. Раскроем блок «Поступления от покупателей» и расшифруем суммы. Отчет наглядно выделит, какие суммы программа распределила в облагаемые доходы, а какие квалифицировала как необлагаемые или относящиеся к спецрежимам.
  2. Экспресс-проверка ведения учета: запустим обработку в разделе Отчеты. В блоке «Ведение книги учета доходов и расходов» программа автоматически сопоставит данные бухгалтерских счетов расчетов с фактическими записями КУДиР и покажет предупреждения о расхождениях.
  3. Универсальный отчет: сформируем отчет по регистру накопления Книга учета доходов и расходов (раздел I) с группировкой по регистратору и документу возникновения дохода, чтобы увидеть, какую именно цепочку расчетов подтягивает алгоритм проведения.

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

← На главную