* Закон України «Про внесення змін до Податкового кодексу України та деяких інших законодавчих актів України» від 31.07.2014 р. № 1621-VII. Аналітичний матеріал про такі новації читайте в «Податки та бухгалтерський облік», 2014, № 64, с. 9.
** Податковий кодекс України від 02.12.2010 р. № 2755-VI.
Як це часто буває, відповідні норми ПКУ прописані жахливо і явно недостатньо. Тому нам довелося додумувати їх самостійно. Аж раптом на сайті ДФСУ було викладено проект постанови КМУ*** (далі — Проект), який, можливо, і буде змінено, але принаймні він допомагає зрозуміти «хід думки» законодавця… ☹
*** Див. за посиланням: http://sfs.gov.ua/diyalnist-/regulyatorna-politika-/regulyatorna-politika/2014-rik/63322.html.
Хоча нам і шкода місця, але без повного цитування п. 2001.3 ПКУ тут, зрозуміло, не обійтися…
Але до цього все ж уточнимо, що «лімітом реєстрації» ми називаємо тут «суму податку, на яку платники мають право видати податкові накладні» (абзац п’ятий п. 2001.1 ПКУ). Ця сума у формулі з п. 2001.3 ПКУ позначена як ∑Накл.
Що думав законодавець? І чим…
Знову ж таки, перш ніж загрузнути у многочленах з метою зрозуміти-таки, як відкривається цей «ларчик», треба поглянути, як він закривався…
На жаль, у пояснювальній записці до базового законопроекту, на підставі якого і було прийнято Закон № 1621, зазначено мало. Мовляв, зміни спрямовані на запобігання шахрайствам з так званим схемним кредитом через так звані податкові ями. Механізм «запобігання» описано в зазначеному законопроекті буквально одним реченням: умовою для реєстрації ПН в ЄРПН зробити наявність достатньої суми ПДВ за отриманими ПН, а в разі недостатності — шляхом поповнення спецрахунку в системі електронного адміністрування ПДВ.
Якось не густо…
Зрозуміло загалом, що у законопроекті йдеться про «шахрайську» ситуацію, коли покупець ставить до відшкодування суму ПДВ за «лівою» ПН, отриманою від «фірми-одноденки»… І ось, на відміну від давно проваленої спроби вивести взагалі всі суми ПДВ платників на спецрахунки (що загрожувало серйозним відволіканням їх оборотних коштів), цього разу законодавець обрав більш «технологічний» і менш жорсткий варіант. Очевидно, що ідея тепер така:
викоренити саму можливість існування «лівих» ПН — причому, не на тому етапі, коли вони вже «заховані» у розділі податкового кредиту порівняно чесних податкових декларацій добросовісних платників ПДВ, а вже на етапі видачі, а точніше — реєстрації ПН
Адже для того й запроваджується з наступного року повсюдна обов’язкова реєстрація ПН в ЄРПН, щоб кожен «схемник» знав: видати ПН без реєстрації — усе одно що викинути. (Увага! Видана, але не зареєстрована ПН теж збільшує податкове зобов’язання (ПЗ) постачальника в його декларації — див. п. 1 розд. ІІІ Проекту, і до речі — забігаючи наперед — виданий і не зареєстрований постачальником «збільшуючий» розрахунок коригування — РК також...) Що стосується отриманих ПН, то тут усе однозначно: якщо вони не зареєстровані в ЄРПН, то сенсу в них немає жодного (у розумінні права покупця на збільшення податкового кредиту — ПК). Тому далі називатимемо відповідні ПН просто «виданими» та «отриманими» платником ПН, маючи на увазі, що всі вони зареєстровані в ЄРПН.
Формула ліміту
А тепер давайте придивимося до злощасної формули з п. 2001.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 ви могли прочитати про можливі майбутні варіанти підтвердження «імпортного» ПДВ у системі електронного адміністрування ПДВ. Тільки-но стане зрозуміло, який саме варіант буде втілено в реальності, проясниться і конкретний механізм обліку системою впливу обговорюваної змінної на ваш ліміт реєстрації.
∑Перевищ — а ось ця змінна напевно найкаверзніша (мабуть тому й розшифровка їй дана найменш виразна ☹ ). Воно ж бо зрозуміло, що авторам формули треба було якось «приплести» декларацію з ПДВ… Але як? Детальніше — див. нижче.
Дивіться: якщо поки що залишити збоку ваші вимушені поповнення спецрахунку і заявки на відшкодування ПДВ, тоді формула «реагуватиме» тільки на поточні реєстрації в ЄРПН зареєстрованих вашими постачальниками та виданих вам ПН і зареєстрованих вами та виданих вашим покупцям ПН… «Стоп! — скажете ви. — Але в ЄРПН повинні обов’язково реєструватися і РК теж?! Чому ж про них не згадали у формулі з п. 2001.3 ПКУ?» Аналіз п. 2 розд. ІІІ Проекту підтвердив, що законодавці цей момент просто проґавили. ☹ Зате автори Проекту вправно «підмалювали» розшифровку змінних ∑НаклВид і ∑НаклОтр, додавши туди згадку про РК, але не тільки це…
Патології формули
Пам’ятаєте «фішку» податківців, мовляв, зменшувати своє ПЗ на підставі «зменшуючого» РК постачальник не має права, доки відповідний ПК за нею не зменшив покупець? Так-от, автори Проекту (див. п. 8 розд. ІІІ) про цю ідею не забули і тепер вигадали безглуздий механізм, згідно з яким «збільшуючий» РК реєструвати в ЄРПН зобов’язаний постачальник, а «зменшуючий» РК — покупець (!!!).« О-ля-ля! Але виписує і той, й інший РК постачальник?» — запитаєте ви… Так, але згідно з Проектом постачальник пересилає такий «зменшуючий» РК покупцю, а той уже у свою чергу реєструє його в ЄРПН. До речі, увага! — якщо покупець не зареєстрував «зменшуючий» РК, відповідно зменшити свій ПК за декларацією (п. 9 розд. ІІІ Проекту) він усе одно зобов’язаний! ☹
І ще один важливий момент прямо прописано у Проекті. На змінну ∑НаклВид впливають не тільки «звичайні» ПН, а й будь-які інші — підсумкові, зведені та «самовиписані» (і в тому числі — отримувачами послуг від нерезидента — див. п. 1 розд. ІІІ Проекту), а також складені при бартерних угодах. Інакше логіка формули порушується. Так, тут, звичайно, і РК до «самовиписаних» ПН (такі РК реєструє, зрозуміло, сам платник).
Із сумом зазначаємо, що повз одного нюансу таки пройшли як законодавці, так і автори Проекту. Нагадуємо і тим, й іншим про існування так званих «замінників» ПН, що дозволяють збільшувати ПК без отримання ПН (пп. «а» і «б» п.п. 201.11 ПКУ). За логікою, ці суми теж повинні збільшувати змінну ∑НаклОтр, а з нею — і величину ліміту реєстрації! Не хочеться думати, що цим фактом і пояснюється «забудькуватість» наших піфагорів…☹
Але повернемося до змінної ∑Перевищ. Якщо ви погоджуєтеся з усім вищезазначеним, то резонне запитання: а звідки, власне, може взятися зазначене в характеристиці цієї змінної «перевищення податкових зобов’язань» (а ми б сказали ширше — показників) вашої податкової декларації з ПДВ над показниками, що містяться у ваших (отриманих та виданих) ПН? До речі, автори Проекту в цю проблему сильно не заглиблювалися… L Нам же відповідь очевидна. Якщо розуміти «перевищення» в широкому сенсі — як відхилення, то воно можливе, по-перше, за рахунок самовиправлень, які на величину вашого ПДВ у декларації вплинули, а до ваших же зареєстрованих ПН не потрапили, а по-друге — не забувайте про незареєстровані постачальником ПН і незареєстровані постачальником і покупцем відповідно РК! — до декларації їх суми увійдуть, а на величини змінних ∑НаклВид і ∑НаклОтр не вплинуть! Сподіваємося, що законодавець це й мав на увазі, але не зміг написати… ☺ До речі, виходить, що змінна ∑Перевищ може набувати як додатного, так і від’ємного значення!..
«Резать к чертовой матери!..»
На завершення торкнемося п. 2001.4 ПКУ, що тісно взаємопов’язаний з обговорюваним п. 2001.3 ПКУ і стосується джерел поповнення спецрахунку (змінна ∑ПопРах). При цьому обійдемося без цитат… Справа тут ось у чому. Норми підпунктів «а» і «б» цього пункту описують цілком очевидні (наступного року) ситуації, коли суми на спецрахунку не достатньо для реєстрації ПН в ЄРПН (п.п. «а») або для сплати ПДВ до бюджету (п.п. «б») і жодних емоцій не викликають. Навпаки, формулювання підпунктів «в» і «г» цього ж пункту, де йдеться про поповнення спецрахунку «у сумі податку, отриманого від покупців при проведенні операцій з продажу товарів/послуг за готівкові кошти або при проведенні бартерних (товарообмінних) операцій» (п.п. «в») і «… нарахованого платником за результатами проведення операцій, передбачених п. 198.5* Кодексу» (п.п. «г»), викликають деякі побоювання. ☹ Адже це можна було б зрозуміти і так, що такі суми ПДВ треба перекидати на спецрахунок обов’язково!
* Нагадаємо, що там ідеться про «самонарахування» ПДВ, зокрема, при невиробничому використанні тощо.
На нашу думку, подібне трактування абсурдне. Так, при бартері (що супроводжується випискою ПН) і «самонарахуванні» (із «самовипискою» ПН) гроші, звичайно ж, на рахунок платника не надходять, але ПН при цьому все ж складаються і реєструються в ЄРПН! І на відповідні змінні злощасної формули впливають! Причому, надходження/ненадходження на рахунок грошей не має жодного стосунку до грошей на спецрахунку! А щодо подібного гіпотетичного утиску роздрібу скажемо прямо: перерахування усієї готівкової виручки на спецрахунок — це явна маячня! Там і підсумкова ПН реєструється в ЄРПН, та й гроші не по кишенях розсуваються… Ми вважаємо, що в п. 2001.4 ПКУ немає імперативності!
Але якщо все так, як ми стверджуємо, то сам п. 2001.4 ПКУ — перетворюється на якийсь «пункт Очевидність»! ☺
А ось з приводу інших наших претензій хочеться сказати: «ретельніше треба!»…
Щоб не закінчувати на мінорній ноті, зауважимо, що Проект містить ще два нюанси, незбагненні для законодавців-теоретиків: 1) сплату штрафів, «самопогашення» недоплат і «самоштрафів» при уточненнях платник ПДВ здійснюватиме прямо з поточного рахунка (п. 6 розд. IV Проекту); 2) переплати надходитимуть теж прямо на поточний рахунок (п. 7 розд. IV Проекту) — таким чином, ці суми не вплинуть на величину ліміту реєстрації ПН.
А найголовніший плюс, «дописаний» у Проекті (див. абз. четвертий п. 8 розд. IV) у порівнянні з нормами ПКУ, — це надія, що сума із спецрахунку платника, що анульований, перераховуватиметься до бюджету не «з кінцями», а з можливістю повернення перевищення цієї суми над його «підсумковим» погодженим податковим зобов’язанням з ПДВ (у статусі надмірно сплачених сум аналогічно порядку, установленому у ст. 43 ПКУ).
Спокійно, бухгалтери! Поки вони освоюють ази арифметики, ми з вами давно пройшли уявні одиниці! ☺
висновки
-
Завдання нового порядку поголовної реєстрації та встановлення ліміту реєстрації ПН — унеможливити існування «фіктивних» ПН, тобто це боротьба з шахрайським відшкодуванням ПДВ з бюджету.
-
У новому механізмі адміністрування братимуть участь усі ПН (у тому числі і «самовиписані»), датовані починаючи з 01.01.2015 р., а також РК, виписані до таких ПН, і декларації починаючи зі звіту за січень або I квартал 2015 року, а крім того — платежі «імпортного» ПДВ і поповнення спецрахунку з цієї самої дати.
-
Абсолютно всі ПН і «збільшуючі» РК зобов’язаний реєструвати в ЄРПН постачальник і тільки «зменшуючі» РК — покупець.
