«Лимит регистрации» НН, или Арифметика — ваша мать, любите арифметику — вашу мать!

Как это часто бывает, соответствующие нормы НКУ прописаны безобразно и явно недостаточно. Потому нам оставалось додумывать их самостоятельно. Но внезапно на сайте ГФСУ был выложен проект постановления КМУ*** (далее — Проект), который, возможно, и будет изменен, но по крайней мере помогает понять «ход мысли» законодателя…☹

Хотя нам и жалко места, но без полного цитирования п. 200¹.3 НКУ тут, понятно, не обойтись…

Но прежде все же уточним, что «лимитом регистрации» мы называем здесь «сумму налога, на которую плательщики имеют право выдать налоговые накладные» (абзац пятый п. 200¹.1 НКУ). Эта сумма в формуле из п. 200¹.3 НКУ обозначена как ∑_Накл.

Что думал законодатель? И чем…

Опять же, прежде чем погрязнуть в многочленах с целью понять-таки, как открывается этот ларчик, надо взглянуть, как он закрывался…

К сожалению, в пояснительной записке к базовому законопроекту, на основании которого и был принят Закон № 1621, сказано мало. Мол, изменения направлены на предотвращение мошенничества с так называемым схемным кредитом через так называемые налоговые ямы. Механизм «предотвращения» описан в упомянутом законопроекте буквально одним предложением: условием для регистрации НН в ЕРНН сделать наличие достаточной суммы НДС по полученным НН, а при недостаточности — путем пополнения спецсчета в системе электронного администрирования НДС.

Да уж, не густо…

Понятно в общем, что в законопроекте речь идет о «мошеннической» ситуации, когда покупатель ставит на возмещение сумму НДС по «левой» НН, полученной от «фирмы-однодневки»… И вот, в отличие от давно провалившейся попытки вывести вообще все суммы НДС плательщиков на спецсчета (что грозило серьезным отвлечением их оборотных средств), на этот раз законодатель выбрал более «технологичный» и менее жесткий вариант. Очевидно, что идея теперь такова: 　

искоренить саму возможность существования «левых» НН — причем не на том этапе, когда они уже «спрятаны» в разделе налогового кредита сравнительно честных налоговых деклараций добросовестных плательщиков НДС, а уже на этапе выдачи, а точнее — регистрации НН

Ведь для того и внедряется со следующего года повсеместная обязательная регистрация НН в ЕРНН, чтобы каждый «схемщик» знал: выдать НН без регистрации — все равно что выбросить. (Внимание! Выданная, но не зарегистрированная НН тоже увеличивает налоговое обязательство (НО) поставщика в его декларации — см. п. 1 разд. ІІІ Проекта, и кстати — забегая вперед — выданный и не зарегистрированный поставщиком «увеличивающий» расчет корректировки — РК также)… Что касается полученных НН, то тут все однозначно: если они не зарегистрированы в ЕРНН, то толку в них нет никакого (в смысле права покупателя на увеличение налогового кредита — НК). Поэтому дальше будем называть соответствующие НН просто «выданными» и «полученными» плательщиком НН, подразумевая, что все они зарегистрированы в ЕРНН.

Формула лимита

А теперь давайте присмотримся к злосчастной формуле из п. 200¹.3 НКУ:

∑_Накл = ∑_{НаклОтр} + ∑_Митн + ∑_ПопРах - - ∑_{НаклВид} - ∑_{Відшкод} - ∑_{Перевищ},
где:
∑_{НаклОтр} — общая сумма налога по полученным плательщиком налоговым накладным, зарегистрированным в Едином реестре налоговых накладных;
∑_Митн — общая сумма налога, уплаченного плательщиком при ввозе товаров на таможенную территорию Украины;
∑_ПопРах — общая сумма пополнения счета в системе электронного администрирования налога на добавленную стоимость с собственного текущего счета плательщика;
∑_{НаклВид} — общая сумма налога по выданным плательщиком налоговым накладным, зарегистрированным в Едином реестре налоговых накладных;
∑_{Відшкод} — общая сумма налога, заявленная плательщиком к бюджетному возмещению;
∑_{Перевищ} — общая сумма превышения налоговых обязательств, указанных плательщиком в поданных налоговых декларациях, над суммой налога, содержащейся в составленных таким плательщиком налоговых накладных, зарегистрированных в Едином реестре налоговых накладных

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

Чтобы докопаться до сути механизма реализации вышеупомянутой идеи, давайте немного «демонтируем» эту пугающую формулу. Смотрите: в правой части равенства есть три суммы, которые увеличивают лимит регистрации (∑_{НаклОтр}, ∑_Митн, ∑_ПопРах) и три другие суммы, которые его уменьшают (∑_{НаклВид}, ∑_{Відшкод}, ∑_{Перевищ}). И хотя эти переменные и расшифрованы под формулой, посмотрим на них не как математики, а как бухгалтеры.

Для наглядности давайте прежде всего сосредоточимся на двух переменных из перечисленных: одной — из троицы увеличивающих — ∑_{НаклОтр} и другой — из троицы уменьшающих — ∑_{НаклВид}. Тем более, откровенно говоря, для большинства плательщиков эти две суммы и будут прежде всего определять результат. Присмотревшись к ним, мы поймем, что:

∑_{НаклВид} — это по сути в основном («в основном» — потому что не считая «самовыписанных» НН) сумма полученного/надлежащего к получению НДС от покупателей или сумма НО плательщика;

∑_{НаклОтр}  — это по сути сумма НДС, уплаченного/надлежащего к уплате НДСным продавцам данного плательщика. Обратите внимание: в отличие от предыдущей переменной, эта сумма не является эквивалентом налогового кредита плательщика (потому что его НК не увеличивают полученные НН на «необъектные» и «необлагаемые» покупки — и это, видимо, можно рассматривать как некое «послабление» от законодателя, поскольку и суммы «неналоговокредитных» НН тоже увеличивают лимит регистрации). Опять же в основном — это сумма НК плательщика.

Тогда идея самой формулы становится ясной как день:

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

Задача понятна — заставить плательщика НДС создавать такой «резерв», чтобы на каждый текущий момент времени он мог уплатить (или с его спец­счета могли списать), так сказать, текущую сумму его налогового обязательства по НДС перед бюджетом! ☹

Как это работает? Давайте для наглядности рассмотрим ситуацию для плательщика НДС без «необъектных» и «необлагаемых» операций (для простоты допустим, что все НН зарегистрированы).

Смотрите: например, на некий момент времени ваш НК = 100 грн. (∑_{НаклОтр} = 100 грн.), и при этом вы хотите выдать покупателю НН, сумма НДС в которой составляет 250 грн. (НО = 250 грн). Нет! — говорят вам налоговики, — нельзя, потому что ваш лимит регистрации (∑_Накл) равен 100 грн. (∑_{НаклОтр} = 100 грн.) и поэтому допускает выдачу (регистрацию) новой НН только на эти же 100 (грн.)! А вдруг вы на этом просто остановите работу и у вас потом нечем будет заплатить НДС в бюджет в сумме 250 - 100 = 150 (грн.)? Сначала положите на свой спецсчет «денежное обеспечение» (∑_ПопРах) на эти самые «недостающие» 150 грн., а потом уже выдавайте вашу НН (читай: увеличивайте переменную ∑_{НаклВид} на соответствующие 250 грн.)… ☹ Потому что благодаря пополнению спецсчета ваш лимит регистрации ∑_Накл вырос до 100 + 150 = 250 (грн.). Красиво? Да уж, «красиво». Но больно…

Расчленение формулы

Понятно, что авторам формулы пришлось подумать, как сделать ее жизненной…

Разберемся, для чего же нужны остальные переменные.

∑_ПопРах  — это, как уже понятно, инструмент плательщика для управления величиной своего лимита регистрации (∑_Накл). А точнее — только для увеличения этого лимита. Понятно, что переменная ∑_ПопРах в принципе не может принимать отрицательное значение: деньги можно перечислять только «туда» (т. е. с текущего счета на спецсчет). При этом очень беспокоит, насколько плательщик оперативно: 1) будет узнавать свой лимит регистрации ∑_Накл (надеемся, что в режиме он-лайн) и 2) сможет управлять этой переменной, т. е. насколько быстро будет реагировать вся «цепочка» на платеж с текущего счета (все зависит от «периодичности» обмена информацией между банком и ГФСУ — см. п. 6 разд. ІІІ Проекта).

∑_{Відшкод} — с этой переменной тоже все ясно: эта дебиторка бюджета перед вами совершенно очевидным образом опускает ваш лимит регистрации только «вниз». Это — страховка фискалов от того, что вы не только не заплатите в бюджет, но при этом еще и получите из него возмещение…

∑_Митн  — это по сути ваш «импортный» НДС, который тоже увеличивает НК и одновременно увеличивает (через формулу) лимит регистрации. В «Налоги и бухгалтерский учет», 2014, № 83, с. 21 вы могли прочитать о возможных будущих вариантах подтверждения «импортного» НДС в системе электронного администрирования НДС. Как только станет ясно, какой именно вариант будет воплощен в реальности, прояснится и конкретный механизм учета системой влияния обсуждаемой переменной на ваш лимит регистрации.

∑_{Перевищ}  — а вот эта переменная, наверное, самая каверзная (видимо, потому и расшифровка ей дана самая невнятная ☹). Оно-то понятно, что авторам формулы надо было как-то «приплести» декларацию по НДС… Но как? Подробнее — см. ниже.

Смотрите: если пока оставить в стороне ваши вынужденные пополнения спецсчета и заявки на возмещение НДС, тогда формула будет «реагировать» только на текущие регистрации в ЕРНН зарегистрированных вашими поставщиками и выданных вам НН и зарегистрированных вами и выданных вашим покупателям НН… Стоп! — скажете вы, — но в ЕРНН должны обязательно регистрироваться и РК тоже?! Почему же про них не упомянули в формуле из п. 200¹.3 НКУ? Анализ п. 2 разд. ІІІ Проекта подтвердил, что законодатели этот момент просто прохлопали. ☹ Зато авторы Проекта ловко «подправили» расшифровку переменных ∑_{НаклВид} и ∑_{НаклОтр}, добавив туда упоминание о РК, но не только это…

Патологии формулы

Помните «фишку» налоговиков, мол, уменьшать свой НО на основании «уменьшающего» РК поставщик не вправе, пока соответствующий НК по ней не уменьшил покупатель? Так вот, авторы Проекта (см. п. 8 разд. ІІІ) об этой идее не забыли и теперь придумали бредовый механизм, согласно которому «увеличивающий» РК регистрировать в ЕРНН обязан поставщик, а «уменьшающий» РК — покупатель (!!!). О-ля-ля! Но выписывает и тот, и другой РК поставщик? — спросите вы… Да, но согласно Проекту поставщик пересылает такой «уменьшающий» РК покупателю, а тот уже, в свою очередь, регистрирует его в ЕРНН. Кстати, внимание! — если покупатель не зарегистрировал «уменьшающий» РК, соответственно уменьшить свой НК по декларации (п. 9 разд. ІІІ Проекта) он все равно обязан! ☹ И еще один важный момент прямо прописан в Проекте. На переменную ∑_{НаклВид} влияют не только «обычные» НН, но и любые другие — итоговые, сводные и «самовыписанные» (и в том числе  получателями услуг от нерезидента — см. п. 1 разд. ІІІ Проекта), а также составленные при бартерных сделках. Иначе логика формулы нарушается. Да, здесь же, конечно, и РК к «самовыписанным» НН (такие РК регистрирует, понятно, сам плательщик).

С прискорбием отмечаем, что мимо одного нюанса таки прошли как законодатели, так и авторы Проекта. Напоминаем и тем, и другим о существовании так называемых «заменителей» НН, которые позволяют увеличивать НК без получения НН (пп. «а» и «б» п.п. 201.11 НКУ). По логике, эти суммы тоже должны увеличивать переменную ∑_{НаклОтр}, а с ней — и величину лимита регистрации! Не хочется думать, что этим фактом и объясняется «забывчивость» наших пифагоров…☹

Но вернемся к переменной ∑_{Перевищ}. Если вы согласны со всем вышесказанным, то резонен вопрос: а откуда собственно может взяться упомянутое в характеристике этой переменной «превышение налоговых обязательств» (а мы бы сказали шире — показателей) вашей налоговой декларации по НДС над показателями, содержащимися в ваших (полученных и выданных) НН? Кстати, авторы Проекта в эту проблему сильно не вникали… L Нам же ответ очевиден. Если понимать «превышение» в широком смысле — как отклонение, то оно возможно, во-первых, за счет самоисправлений, которые на величину вашего НДС в декларации повлияли, а в ваши же зарегистрированные НН не попали, а во-вторых — не забывайте о незарегистрированных поставщиком НН и незарегистрированных поставщиком и покупателем соответственно РК! — в декларацию их суммы войдут, а на величины переменных ∑_{НаклВид} и ∑_{НаклОтр} не повлияют! Надеемся, что законодатель это и имел в виду, но не смог написать… ☺ Кстати, получается, что переменная ∑_{Перевищ} может принимать как положительное, так и отрицательное значение!..

«Резать к чертовой матери!..»

В завершение коснемся п. 200¹.4 НКУ, тесно взаимосвязанного с обсуждаемым п. 200¹.3 НКУ и касающегося источников пополнения спецсчета (переменная ∑_ПопРах). При этом обойдемся без цитат… Дело тут вот в чем. Нормы подпунктов «а» и «б» этого пункта описывают вполне очевидные (в следующем году) ситуации, когда суммы на спецсчете не достаточно для регистрации НН в ЕРНН (п.п. «а») или для уплаты НДС в бюджет (п.п. «б»), и никаких эмоций не вызывают. Напротив, формулировки подпунктов «в» и «г» этого же пункта, где говорится о пополнении спецсчета «в сумме налога, полученного от покупателей при проведении операций по продаже товаров/услуг за наличные средства или при проведении бартерных (товарообменных) операций» (п.п. «в») и «… начисленного плательщиком по результатам проведения операций, предусмотренных п. 198.5* Кодекса» (п.п. «г»), вызывают некие опасения. ☹ Ведь это можно было бы понять и так, что такие суммы НДС надо перекидывать на спецсчет обязательно!

По нашему мнению, подобная трактовка абсурд­на. Да, при бартере (сопровождаемом выпиской НН) и «самоначислении» (с «самовыпиской» НН) денег, конечно же, на счет плательщика не поступает, но НН-то при этом составляются и регистрируются в ЕРНН! И на соответствующие переменные зло­счастной формулы влияют! Причем поступление/непоступление на счет денег не имеет ровно никакого отношения к деньгам на спецсчете! А насчет подобного гипотетического ущемления розницы скажем прямо: перечисление всей наличной выручки на спецсчет — это явный бред! Там и итоговая НН регистрируется в ЕРНН, да и деньги не по карманам рассовываются… Мы считаем, что в п. 200¹.4 НКУ нет императивности!

Но если все так, как мы утверждаем, то сам п. 200¹.4 НКУ — превращается в какой-то «пункт Очевидность»! ☺

А вот по поводу других наших претензий хочется сказать: «тщательнЕЕ надо!»…

Чтобы не заканчивать на минорной ноте, заметим, что Проект содержит еще две тонкости, непостижимые для законодателей-теоретиков: 1) уплату штрафов, «самопогашения» недоплат и «самоштрафов» при уточнениях плательщик НДС будет осуществлять прямо с текущего счета (п. 6 разд. IV Проекта); 2) переплаты будут поступать тоже прямо на текущий счет (п. 7 разд. IV Проекта) — таким образом, эти суммы не повлияют на величину лимита регистрации НН.

А самый главный плюс, «дописанный» в Проекте (см. абз. четвертый п. 8 разд. IV) по отношению к нормам НКУ, — это надежда, что сумма со спецсчета аннулированного плательщика будет перечисляться в бюджет не «с концами», а с возможностью возврата превышения этой суммы над его «итоговым» согласованным налоговым обязательством по НДС (в статусе излишне уплаченных сумм аналогично порядку, установленному в ст. 43 НКУ).

Спокойствие, бухгалтеры! Пока они осваивают азы арифметики, мы с вами давно прошли мнимые единицы! ☺

выводы

• Задача нового порядка повальной регистрации и установления лимита регистрации НН — исключить возможность существования «фиктивных» НН, т. е. это борьба с мошенническим возмещением НДС из бюджета.

• В новом механизме администрирования будут участвовать все НН (в том числе и «самовыписанные»), датированные начиная с 01.01.2015 г., а также РК, выписанные к таким НН, и декларации начиная с отчета за январь или І квартал 2015 года, а кроме того — платежи «импортного» НДС и пополнения спецсчета с этой же даты.

• Абсолютно все НН и «увеличивающие» РК обязан регистрировать в ЕРНН поставщик и только «уменьшающие» РК — покупатель.