Отключить рекламу

Підпишіться!


Бухгалтер 911, жовтень, 2017/№41
Друкувати

Загадковий override, або Хто вкрав ліміт реєстрації в СЕА ПДВ?

Казанова Марина, податковий експерт, m.kazanova@buhgalter911.com
Багато платників, отримавши в останніх числах вересня Витяг із СЕА (J/F 1401206), не повірили своїм очам. Значення за ряд. 2 Витягу (сума, на яку можна зареєструвати податкові накладні) або істотно зменшилося, або взагалі пішло в мінус. Зате в гр. 6 з’явився незрозумілий показник оverride із зазначенням періоду його виникнення. Сьогодні розберемося, звідки він узявся і що з ним тепер робити.
регліміт, електронний ПДВ-рахунок

Відразу зазначимо, якщо раніше, скажімо, на 20.09.2017 р. у вас не було у Витягу із СЕА (J/F 1401206) значення за гр. 6, а зараз воно з’явилося і не пов’язано із серпневою декларацією (тобто там стоїть період не 08.2017), то ваш ліміт списали незаконно. І податківці зобов’язані вам його повернути. Але про все по порядку.

Що означає показник оverride?

Враховуючи, що показник оverride значиться в гр. 6 Витягу із СЕА (J/F 1401206), то це є не що інше, як показник ∑Перевищ з формули ліміту реєстрації. А цей показник може виникнути, якщо податкові зобов’язання за поданою ПДВ-декларацією (вказані в розділі I) перевищують суму ПДВ за даними зареєстрованих платником податкових накладних.

Така ситуація може виникнути, зокрема, якщо в декларації ви податкові зобов’язання показали, а відповідну(-ні) податкову накладну / збільшуючі розрахунки коригування на момент подання декларації ще не зареєстрували у Єдиному реєстрі.

Наприклад, податкову накладну із сумою ПДВ 2000 грн., складену 10 серпня, платник зареєстрував тільки 28 вересня. При цьому, як того вимагають п. 187.1 ПКУ і п. 201.1 ПКУ, він показав зобов’язання в декларації за серпень у періоді їх виникнення.

У цьому випадку податкових зобов’язань за декларацією буде на 2000 більше, ніж зобов’язань за даними зареєстрованих податкових накладних. Тому на дату подання серпневої декларації відразу «вилізе» показник ∑Перевищ.

Інакше кажучи, показник ∑Перевищ виникає, коли є незбіг періодів реєстрації податкової накладної / розрахунку коригування і відображення їх у декларації.

Щоправда, 28 вересня (на дату реєстрації податкової накладної, показаної раніше в декларації) цей показник повинен зникнути. Оскільки п. 9 Постанови № 569* установлює, що для визначення показника ∑Перевищ порівнюються (з першого віднімається друге):

* Порядок електронного адміністрування податку на додану вартість, затверджений постановою КМУ від 16.10.2014 р. № 569.

1) сума задекларованих податкових зобов’язань (приймаються в розрахунок наростаючим підсумком дані ряд. 9 декларацій за липень / 3 квартал 2015 року і закінчуються останньою декларацією, поданою на момент перерахунку) і

2) сума ПДВ за виданими і зареєстрованими податковими накладними і розрахунками коригування. У їх розрахунок приймаються наростаючим підсумком податкові накладні, складені з 01.07.2015 р., і розрахунки коригування до них (+/-), закінчуючи останнім календарним днем звітного періоду, за який подана декларація з ПДВ.

Самі податківці визнали, що показник ∑Перевищ повинен перераховуватися кожного разу при: (1) наданні декларації з ПДВ або уточнюючих розрахунків за вказані періоди; (2) запізнілій реєстрації у Єдиному реєстрі податкових накладних і розрахунків коригування.

Див. у тому числі лист ДФСУ від 10.07.2015 р. № 1402/99-99-19-03-01-18.

Чому він з’явився зараз?

Імовірно, податківці взялися за реалізацію норми п. 2001.9 ПКУ, що набула чинності ще з 01.01.2017 р., яка дозволяє реєструвати податкові накладні за рахунок показника ∑Перевищ. Пам’ятайте, там є така умова, що за рахунок ∑Перевищ можуть реєструватися тільки податкові накладні за той період, у якому виник цей показник? Інакше кажучи, податківцям потрібно було налаштувати період виникнення ∑Перевищ. Але щось, мабуть, у програмі пішло не так. Розрахунок цього показника став здійснюватися абсолютно некоректно. Формула перестала враховувати, що показник ∑Перевищ повинен (1) розраховуватися наростаючим підсумком і (2) автоматично перераховуватися (зменшуватися) при реєстрації запізнілої податкової накладної. Інакше кажучи, у податківців стався збій у програмі!

Показник ∑Перевищ може значитися тільки в тому випадку, якщо податкові накладні, які відображені в декларації, так і не були зареєстровані (проте в цьому випадку показник ∑Перевищ повинен був фігурувати у вас і раніше, якщо йдеться не про свіжий серпневий ∑Перевищ).

Приклад 1. Платник подав 18.08.2017 р. декларацію за липень.

ПЗ за декларацією за липень (розділ 1)

ПЗ за даними зареєстрованих ПН за липень

20000

18000 (не зареєстрована податкова накладна на суму 2000)

Припустимо, податкова накладна, зобов’язання за якою були відображені в декларації за липень, зареєстрована 08.09.2017 р.

Дата події

Подія

НаклВид

Перевищ

Накл

(регліміт)

17.08.2017 р.

5000

18.08.2017 р.

Подано декларацію за липень

2000

3000

08.09.2017 р.

Як повинен надалі перераховуватися показникПеревищ

Зареєстровано відображену в декларації податкову накладну (2000)

2000

0

3000

Як фактично помилково перерахували його податківці

Зареєстровано відображену в декларації податкову накладн (2000)

2000

2000

1000

Приклад 2. 12 травня 2017 року платник виписав і своєчасно зареєстрував податкову накладну із сумою ПДВ 2000 грн. Проте виявилось, що вона виписана на неправильну дату. 15 травня платник зареєстрував нову податкову накладну (у декларацію за травень включив зобов’язання тільки за правильною податковою накладною). Цією ж датою склав зменшуючий розрахунок коригування до помилкової податкової накладної. Проте покупець зареєстрував його із запізненням — 19 червня 2017 року.

Період

ПЗ за декларацією (розділ 1)

ПЗ за даними зареєстрованих ПН

Травень

100000

102000 (включаючи 2000 за помилковою податковою накладною)

Червень

90000

88000 (включаючи розрахунок коригування на «-2000» до помилкової податкової накладної)

Зараз програма вважає, що в покупця є ∑Перевищ за червень у сумі 2000 (оскільки зобов’язання за декларацією за червень перевищують зобов’язання за червень за даними Єдиного реєстру).

Проте, виходячи з вимог п. 9 Постанови № 569, ∑Перевищ бути не повинно. Загальна сума зобов’язання за деклараціями наростаючим підсумком складає 190000 (100000 + 90000). Зобов’язання за даними зареєстрованих податкових накладних / розрахунків коригування на дату подання червневої декларації також складають 190000 (102000 + 88000).

Що робити?

Сподіваємося, що податківці оперативно виправлять свою помилку. Якщо ж ні, і ви бачите, що розрахунок показника ∑Перевищ здійснений некоректно, подавайте скаргу з вимогою відновити ліміт.

Як підтвердження незаконного списання ліміту згодяться:

1) витяги з СЕА (J/F 1401206) на різні дати: до появи override і після його появи;

2) витяги із СЕА в розрізі операцій (J/F1401902). Цей витяг дозволяє отримати показники СЕА в розрізі на певну дату;

Причому ось що важливе — у ньому розкривається перелік усіх сум і документів (з реквізитами), що вплинули на формулу за цей день.

3) декларації з ПДВ за той період, у якому за даними витягу виник override (період виникнення вказаний у Витягу із СЕА (J/F 1401206);

4) квитанції, що підтверджують факт реєстрації податкових накладних, через які згідно з даними Витягу із СЕА виник override.

Крім того, якщо незаконне списання ліміту призвело до того, що ви не змогли вчасно зареєструвати податкові накладні — вимагайте звільнення від штрафів за ст. 1201 ПКУ. Адже, по суті, списавши незаконно ліміт, податківці позбавили вас права і можливості виконати обов’язок зі своєчасної реєстрації податкових накладних. Стаття 109 ПКУ встановлює, що податковим правопорушенням вважається протиправне діяння (бездіяльність) платника. Особа вважається невинною, якщо доведе, що нею були вжиті всі заходи для належного виконання зобов’язання.

Для того, чтоб распечатать текст необходимо авторизоваться или зарегистрироваться