← На главную

Рассмотрим распространенную ситуацию при ведении налогового учета по УСН в конфигурации 1С:ERP Управление предприятием 2.5. Допустим, мы перечисляем аванс поставщику (например, сервису покупки билетов Smartway), загружаем электронный билет в систему, а затем сотрудник отчитывается по командировке через документ АвансовыйОтчет. Однако при формировании Книги учета доходов и расходов (КУДиР) выясняется, что суммы по одним авансовым отчетам корректно попадают в расходы, а по другим — нет, хотя документы визуально заполнены абсолютно одинаково. Разберем по шагам, почему так происходит и как добиться корректного признания расходов.

Причина 1: Входящее сальдо по счету 71 (взаиморасчеты с подотчетником)

Первое, на что мы обратим внимание при анализе проблемных авансовых отчетов конкретных сотрудников — это состояние взаиморасчетов по счету 71. Проанализируем входящее сальдо по подотчетному лицу на момент проведения документа.

Если для сотрудника числится дебетовое сальдо в недостаточном объеме или висит кредитовое сальдо (организация должна сотруднику), система при проведении авансового отчета считает, что сотрудник расходует свои личные средства, а не ранее выданный аванс от фирмы. Поскольку деньги компании не были потрачены (или их не хватило на покрытие билета), система не видит факта оплаты расхода со стороны организации. Следовательно, запись в КУДиР сформирована не будет до момента окончательного погашения задолженности перед сотрудником.

Причина 2: Незачтенные авансы агрегатору билетов

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

Если зачета безналичных денежных средств не произошло, программа классифицирует данный электронный билет как неоплаченный поставщику, из-за чего расходы в КУДиР не будут признаны.

Причина 3: Нарушение хронологии ввода документов

Проанализируем последовательность оформления операций. В 1С:ERP партионный учет и регистры накопления для УСН крайне чувствительны к хронологии. Расход признается по последнему из необходимых событий (оплата поставщику или принятие услуги/материалов).

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

Причина 4: Настройки статей расходов и «зависшие» статусы

Посмотрим на внутренние настройки и состояние регистров. Проблема может крыться в следующем:

1. Разные настройки в статьях расходов. Даже если строки в документах выглядят одинаково, внутри выбранной статьи расходов может быть снят флаг принятия затрат к налоговому учету по УСН.
2. Ошибки в регистрах. В регистре накопления РасходыПриУСН статусы могут зависнуть в состоянии «Не оплачено» или «Не списано». Часто это происходит из-за ручного перепроведения документов задним числом без последующего восстановления последовательности расчетов.
3. Ошибки закрытия месяца. В ERP 2.5 записи в КУДиР окончательно формируются регламентными операциями. Если процедура «Закрытие месяца» завершилась с ошибками, часть расходов останется нераспределенной.

Алгоритм решения проблемы

Теперь рассмотрим, как практически решить эту задачу и вернуть потерянные расходы в КУДиР. Выполним следующие действия:

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

Важное ограничение: любые ручные корректировки проводок (бухгалтерского учета) в первичных документах гарантированно сломают попадание сумм в КУДиР. Система опирается исключительно на данные регистров накопления, поэтому использовать ручные операции не рекомендуется.

Альтернативный вариант: отказ от вкладки билетов в авансовом отчете

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

Поскольку агрегаторы билетов по итогам месяца предоставляют закрывающие документы (УПД или акты выполненных работ) на все билеты и сервисные сборы, мы можем отражать эти билеты напрямую. Оформим их обычным документом ПриобретениеУслугИПрочихАктивов и отнесем сразу на затраты нужного подразделения.

При такой схеме авансовый отчет будет использоваться сотрудником исключительно для отчета по суточным и своим личным тратам. Расходы на билеты при этом попадут в КУДиР по классической, прозрачной цепочке «Оплата поставщику —> Поступление услуг», которая работает в ERP значительно стабильнее и не зависит от сальдо по счету 71.