Нужно ли вручную размечать поступления на расчетный счет при АУСН, и как правильно проверить и исправить разметку в 1С

← На главную

Проанализируем ситуацию, с которой сталкиваются почти все пользователи АУСН: деньги приходят на расчетный счет, банк и/или 1С где-то “размечают” эти движения, а мы не понимаем — обязательно ли вручную проставлять признаки доходов/не доходов, и что будет, если ничего не трогать.

Разберем по шагам, как устроена разметка при АУСН, кто за нее отвечает, что именно нужно делать руками, а что делать не нужно. Далее посмотрим, как организовать контроль в 1С через документы и отчеты, и как действовать при ошибках разметки, эквайринге, комиссиях, возвратах, собственных переводах и прочих “неочевидных” поступлениях.

Разметка при АУСН: кто “размечает” и зачем это вообще нужно

Для начала выясним причину путаницы. При АУСН налоговая база формируется не так, как при классической УСН с КУДиР. Здесь основная логика такая:

Банк (уполномоченный участник АУСН) классифицирует движения по расчетному счету: что относится к налоговой базе, а что нет.
ФНС получает сведения от банка (и от ККТ по кассовым операциям), рассчитывает налог и формирует уведомления.
Налогоплательщик обязан контролировать корректность разметки и при необходимости исправлять ее в установленные сроки.

То есть ключевая мысль: разметка — это не “внутренняя хотелка 1С”, а механизм формирования налоговой базы по АУСН. Поэтому нам важно не просто “завести документы в учете”, а обеспечить, чтобы в итоге банк/ФНС получили правильную классификацию операций.

При этом 1С встраивается в эту схему как инструмент учета и контроля: в документах банка появляются признаки АУСН, формируются специальные регистры, а мы можем быстро увидеть, что попало в базу и почему.

Обязательно ли вручную размечать все поступления на расчетный счет

Теперь ответим на главный вопрос “по-человечески”. Вручную размечать каждое поступление “с нуля” обычно не требуется, потому что:

Банк по АУСН выполняет автоматическую разметку движений по счету.
1С при загрузке/вводе банковских документов тоже часто проставляет признак автоматически по виду операции.

Но есть важное “НО”: контроль и исправление — обязательны. Мы не “создаем разметку вручную каждый раз”, но мы обязаны:

ежемесячно проверить, как банк разметил операции;
исправить ошибки, если банк отнес поступление не туда;
успеть сделать корректировки вовремя (обычно — до определенной даты в следующем месяце, чтобы банк передал корректные сведения в ФНС).

Давайте рассмотрим подробнее, в каких случаях можно спокойно опираться на автоматическую разметку, а в каких — почти наверняка придется вмешиваться.

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

Посмотрим на типовые ситуации, где автоматическая разметка чаще всего корректна:

Оплата от покупателя по договору поставки/услуг, когда назначение платежа однозначно и соответствует выручке.
Поступления по платежным картам (эквайринг) в простом варианте, если банк/агрегатор передает данные без “смешивания” комиссий и удержаний, и сумма зачисления соответствует логике учета.
Возврат от поставщика (если он корректно идентифицируется как возврат именно наших ранее перечисленных средств, и банк умеет распознать это как неформирующее доход).

В этих случаях наша задача — не “размечать руками”, а проверить, что все распознано правильно, и не тратить время на лишние правки.

Когда разметку придется проверить особенно внимательно: операции, которые банк часто классифицирует неверно

Теперь разберем по шагам “опасные зоны”, где ошибка разметки — обычное дело. Здесь мы действуем так: сначала выявляем тип операции, затем проверяем признак налоговой базы, затем корректируем (если нужно).

Собственные переводы (внесение собственных средств, перевод между своими счетами, пополнение счета учредителем без признака выручки). Банк может ошибочно принять такие поступления за доход, если назначение платежа неочевидное.
Займы и возвраты займов. Если нам поступили заемные средства или возврат ранее выданного займа, это не выручка, но банк может классифицировать как доход при “кривом” назначении платежа.
Возвраты покупателям / возвраты от покупателей. Поступление возврата может быть не доходом (например, возврат ранее перечисленного аванса в некоторых сценариях), но автоматическая логика не всегда угадывает контекст.
Эквайринг/маркетплейсы/агенты: удержания комиссий, штрафов, логистики, взаимозачеты. Тут частая проблема: на расчетный счет приходит сумма “за минусом”, а налоговая база должна считаться по другой логике (например, по полной сумме выручки). В таких кейсах почти всегда требуется сверка и иногда ручная корректировка.
Зачеты, взаимозачеты, бартер. Такие операции не всегда проходят через расчетный счет “правильно” для автоматизации, и часть данных придется отражать вручную в соответствующих источниках (в зависимости от того, как именно формируется база и откуда ФНС берет сведения).

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

Как 1С помогает контролировать разметку: какие документы и регистры участвуют

Перейдем к практике в 1С. Термин “разметка” в 1С обычно привязан именно к банковским документам. Поэтому в типовой логике участвуют:

Документ ПоступлениеНаРасчетныйСчет
Документ СписаниеСРасчетногоСчета
Регистр накопления БанковскиеОперацииАУСН (сюда пишутся показатели по доходам/расходам с признаком включения/невключения)
Отчет БанковскиеОперацииАУСН (в интерфейсе обычно доступен из раздела налогов/отчетов по АУСН)
Для “доходы минус расходы” дополнительно важны механизмы учета расходов (например, регистры и документы, которые формируют данные в логике АУСН, включая РасходыАУСН)

Логика работы такая: мы отражаем банковскую выписку (загрузкой или ручным вводом), проводим документы, и 1С формирует движения по БанковскиеОперацииАУСН. Далее мы строим отчет и видим, какие суммы 1С считает “в базе”, а какие — “вне базы”. Это и есть удобная площадка для проверки и выявления расхождений.

Решение 1: Ничего “вручную не размечать”, но поставить ежемесячный контроль разметки по отчету

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

Разберем по шагам:

Загружаем банковскую выписку в 1С стандартными средствами (обычно через обработку загрузки выписки или интеграцию банка).
Формируем документы ПоступлениеНаРасчетныйСчет и СписаниеСРасчетногоСчета и проводим их.
Открываем отчет БанковскиеОперацииАУСН и группируем данные так, чтобы были видны признаки включения в налоговую базу.
Сверяем по каждому “подозрительному” платежу: относится ли он к доходам/расходам АУСН, или должен быть исключен.
Фиксируем список ошибок: какие операции нужно переклассифицировать.

Обратите внимание: этот подход хорош тем, что мы не вмешиваемся без необходимости. Мы сначала находим именно ошибки, и только затем исправляем их точечно.

Решение 2: Исправляем классификацию поступлений в 1С через корректный вид операции и признак АУСН

Теперь разберем ситуацию, когда в 1С операция распозналась неверно. Здесь мы действуем аккуратно: не “ломаем учет”, а приводим в порядок первичную классификацию документа.

Посмотрим на пример логики:

Если платеж — выручка, но документ создан “не тем видом операции”, 1С могла поставить неправильный признак. Значит, меняем вид операции документа на корректный (например, “Оплата от покупателя”, если это действительно оплата).
Если вид операции корректный, но признак включения в АУСН проставлен неверно, тогда меняем признак включения (в тех конфигурациях/релизах, где это предусмотрено) и перепроводим документ.
После перепроведения перестраиваем отчет БанковскиеОперацииАУСН и проверяем, что сумма попала в нужную категорию.

Важно: мы всегда перепроверяем результат именно по регистру/отчету АУСН, а не “на глаз” по документу. Потому что цель — корректные движения в БанковскиеОперацииАУСН.

Решение 3: Исправляем разметку там, где она юридически важна — в личном кабинете банка (и соблюдаем сроки)

Теперь самое важное: даже если в 1С мы “подкрутили” признак, для АУСН критична разметка, которую банк передает в ФНС. Поэтому в большинстве рабочих схем корректировки делаются именно в банковском интерфейсе АУСН.

Разберем по шагам правильный порядок действий:

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

Таким образом, “ручная разметка” в реальной жизни чаще означает не ручное проставление в каждом документе 1С, а ручную корректировку ошибочных классификаций в кабинете банка + контроль в 1С.

Отдельный разбор: эквайринг, комиссии агента и поступления “за минусом”

Проанализируем ситуацию, которая вызывает максимум вопросов: деньги от эквайринга/маркетплейса приходят на расчетный счет не в полной сумме, потому что комиссия удержана автоматически.

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

Разберем по шагам, как действовать безопасно:

Определяем “правильную базу”: что является доходом для АУСН в вашем кейсе — сумма продаж целиком или сумма фактического зачисления.
Проверяем, как банк размечает поступление: включил ли он в доход только зачисление или учитывает “грязную” выручку.
Если банк учитывает только зачисление, а по смыслу нужна полная выручка, тогда рассматриваем корректировку данных в источнике (чаще всего — через кабинет АУСН и/или вручную через предусмотренные механизмы передачи сведений, если банк не умеет учитывать комиссию корректно).
В 1С приводим учет к согласованному итогу: чтобы аналитика по доходам и сверка по АУСН не “рассыпалась”.

В подобных кейсах почти всегда есть нюанс: часть данных может требовать внесения вручную, потому что не все удержания и расчеты автоматически попадают в правильном виде в контур АУСН. Поэтому наша стратегия простая: сначала добиваемся правильного итога в контуре банка/ФНС, затем синхронизируем 1С.

Как настроить работу в 1С, чтобы “разметка” не превращалась в ручной ад

Посмотрим на практическую организацию процесса. Наша цель — чтобы ежемесячная проверка занимала считанные минуты.

Рекомендуем выстроить процесс так:

Ведите банк в 1С регулярно, без накопления за несколько месяцев. Так ошибки видно сразу.
Используйте единый подход к назначению платежей (шаблоны, договоры, контрагенты), чтобы автоматическая классификация работала стабильнее.
Каждый месяц делайте контрольный отчет БанковскиеОперацииАУСН и анализируйте нестандартные операции отдельным списком.
Фиксируйте правила: какие типы поступлений вы считаете доходом, а какие — нет, чтобы одинаковые платежи не разметались по-разному.

Если у вас несколько источников поступлений (эквайринг, маркетплейсы, возвраты, займы), особенно важно описать “карту правил” и проверять по ней, а не по памяти.

Практика диагностики: как быстро найти ошибки разметки в 1С

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

Сгруппируем отчет БанковскиеОперацииАУСН по признаку налоговой базы (включается/не включается).
Отдельно просмотрим “не включается”: не попали ли туда реальные оплаты от покупателей.
Отдельно просмотрим “включается”: нет ли там собственных переводов, займов, возвратов, пополнений, ошибочно признанных доходом.
Проверим периоды: иногда платеж относится к другому периоду из-за даты зачисления/исполнения, и это влияет на месячную базу.

Этот алгоритм мы применяем каждый месяц. Он дает именно то, что нужно для АУСН: быстро выявляет “аномалии” и сводит ручные действия к минимуму.

Пример кода 1С: как программно проверить, что попало в регистр Банковские операции АУСН за месяц

Иногда нам нужно не просто “посмотреть отчет”, а быстро выгрузить список операций в обработку, сравнить с внутренними правилами, найти подозрительные строки. Тогда помогает чтение регистра БанковскиеОперацииАУСН через запрос.

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


Процедура ПроверитьРазметкуАУСН(ДатаНач, ДатаКон) Экспорт

	Запрос = Новый Запрос;
	Запрос.Текст =
	"ВЫБРАТЬ
	|	Операции.Период КАК Период,
	|	Операции.Организация КАК Организация,
	|	Операции.РасчетныйСчет КАК РасчетныйСчет,
	|	Операции.ДокументОснование КАК ДокументОснование,
	|	Операции.ВидДвижения КАК ВидДвижения,
	|	Операции.Сумма КАК Сумма,
	|	Операции.ПризнакНалоговойБазы КАК ПризнакНалоговойБазы
	|ИЗ
	|	РегистрНакопления.БанковскиеОперацииАУСН КАК Операции
	|ГДЕ
	|	Операции.Период МЕЖДУ &ДатаНач И &ДатаКон
	|
	|УПОРЯДОЧИТЬ ПО
	|	Период";

	Запрос.УстановитьПараметр("ДатаНач", ДатаНач);
	Запрос.УстановитьПараметр("ДатаКон", ДатаКон);

	Результат = Запрос.Выполнить();
	Выборка = Результат.Выбрать();

	Пока Выборка.Следующий() Цикл
		// Здесь можно добавить правила проверки:
		// например, если ДокументОснование = ПоступлениеНаРасчетныйСчет и ПризнакНалоговойБазы = "НеВключать"
		// то вывести предупреждение.
	КонецЦикла;

КонецПроцедуры

Как использовать этот пример на практике:

Сначала запустим запрос и убедимся, что поля существуют в вашей базе (если поле ПризнакНалоговойБазы называется иначе — подставим фактическое имя).
Затем добавим правила контроля: например, “Оплата от покупателя” всегда должна включаться в базу, а “Перевод собственных средств” — нет.
Сформируем список исключений и уже по нему точечно исправим документы/разметку.

Такой подход особенно полезен, если операций много и ручной просмотр отчета занимает слишком долго.

Если разметка в 1С и в банке отличается: как действовать правильно

Иногда возникает типовая проблема: в 1С мы видим одну картину, а в банке (в АУСН-интерфейсе) — другую. Разберем по шагам, как не запутаться:

Определим “источник истины” для налога: для расчета налога по АУСН решающим является то, что банк передал в ФНС (и что ФНС приняла).
Исправим первопричину: если банк неверно классифицировал — исправляем в банке, а не пытаемся “перебить” 1С ради красоты отчета.
Синхронизируем учет: после исправления в банке приводим 1С к той же логике (документами, корректной аналитикой, настройками обмена), чтобы сверка не показывала постоянные расхождения.
Зафиксируем правило на будущее: меняем шаблоны назначения платежа, настройки обработки выписки, правила формирования документов, чтобы ошибка не повторялась.

Так мы получаем управляемый процесс: налог считается правильно, учет “не спорит” с банком, а разметка перестает быть источником стресса.

Частые ошибки и как их предотвратить

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

Смешанные назначения платежа (в одном назначении и возврат, и оплата, и что-то еще). Решение: разделяем платежи или делаем назначение максимально однозначным.
Неверный вид операции в документе банка. Решение: проверяем, что документ ПоступлениеНаРасчетныйСчет создан правильным видом операции, и только потом оцениваем признак АУСН.
Редкие нетиповые поступления (займы, пополнения, субсидии, компенсации). Решение: заводим “шпаргалку” по классификации и каждый такой платеж проверяем в первую очередь.
Опоздание с корректировками. Решение: ставим ежемесячный регламент — “проверка разметки и исправления” в первые дни следующего месяца, чтобы успевать до передачи данных в ФНС.

Если мы выстроим эти правила, то “ручная разметка” сведется к редким точечным исправлениям, а не к ежедневной рутине.

Итог: что именно делаем по факту каждый месяц

Соберем все в понятный чек-лист и закрепим результат.

Загружаем выписку и проводим ПоступлениеНаРасчетныйСчет / СписаниеСРасчетногоСчета.
Формируем отчет БанковскиеОперацииАУСН и группируем по признаку налоговой базы.
Проверяем “опасные” типы операций: собственные переводы, займы, возвраты, эквайринг/маркетплейсы, поступления “за минусом”.
Исправляем ошибки там, где это влияет на налог: обычно — в кабинете АУСН у банка, соблюдая сроки передачи сведений в ФНС.
Синхронизируем 1С (при необходимости) — чтобы учет и сверка совпадали с итогом у банка/ФНС.

Если действовать так, то ответ на исходный вопрос будет простым: вручную размечать каждое поступление не нужно, но обязательно нужно регулярно проверять разметку и корректировать ошибки, используя удобные инструменты 1С и интерфейс АУСН в банке.

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