Розрахунок коригування ПДВ: три сценарії від причини до перевірки в BAS

Сім контрольних питань до будь-якого РК

Матриця рішень: три причини — три різні маршрути

Сценарна карта 1. Повернення товару або авансу

Сценарна карта 2. Зміна ціни, кількості або номенклатури

Сценарна карта 3. Помилка в раніше складеній ПН

Строки і квитанції: що перевірити на дату подання

Відображення РК у BAS і M.E.Doc як контрольний ланцюг

«Контрольна сума» від первинки до декларації

Карта ескалації для неоднозначного випадку

Чекліст доказів перед закриттям періоду

Питання для обов’язкового профільного ПДВ-рев’ю

Пряма відповідь: розрахунок коригування починається не з умовного коду і не з кнопки в обліковій програмі. Спочатку бухгалтер встановлює, що саме сталося у господарській операції, яким первинним документом це підтверджено та на яку дату виникла підстава для перерахунку. Лише потім визначають зв’язок із зареєстрованою податковою накладною, спосіб заповнення РК, відповідальну за реєстрацію сторону та період відображення у звітності. Саме так варто будувати розрахунок коригування ПДВ: навчання має давати логіку вибору, а не один шаблон на всі випадки.

Актуальність норм: 26 вересня 2026 року. На цю дату чинна форма РК є додатком 2 до податкової накладної за Порядком № 1307 з урахуванням змін, а форми декларації та додатків застосовуються за Порядком № 21. Тимчасові строки реєстрації ПН/РК у період дії воєнного стану та шести місяців після місяця його припинення або скасування визначає пункт 89 підрозділу 2 розділу XX ПКУ. Перед кожним реальним поданням треба повторно перевірити чинність форми, XML-версію, строк, статус платників і спеціальні правила саме для своєї операції. Цей алгоритм є навчальним і не замінює індивідуальної податкової консультації.

Сім контрольних питань до будь-якого РК

Найнадійніший спосіб не переплутати сценарії — заповнити короткий паспорт коригування до створення електронного документа:

1. Який факт змінився? Товар повернули, аванс віддали, сторони переглянули ціну, змінилася кількість чи лише виявлено помилку в уже складеній ПН?
2. Коли це сталося? Потрібна дата реальної події, а не зручна дата закриття місяця.
3. Яка первинка це доводить? Додаткова угода сама по собі не завжди підтверджує рух товару або коштів; потрібен документ, що відповідає суті операції.
4. До якої ПН належить зміна? Перевіряють дату, номер, покупця, договір, номенклатуру, ставку ПДВ і попередні РК.
5. Який фінансовий результат? Загальна компенсація збільшується, зменшується чи не змінюється?
6. Хто реєструє? Це залежить від знака коригування, статусу отримувача та виду ПН, а не від того, хто технічно створив файл.
7. Чим закінчується контроль? Не кнопкою «Надіслати», а зареєстрованим статусом, квитанцією, правильним обліком у двох сторін і узгодженою декларацією.

Поки хоча б на одне питання немає документованої відповіді, код причини обирати рано. Наприклад, код 103 має назву, пов’язану з поверненням, але в окремих процедурах виправлення помилкової ПН його застосовують для обнулення. Назва коду не замінює аналізу господарської події та чинного порядку.

Матриця рішень: три причини — три різні маршрути

Сценарна карта 1. Повернення товару або авансу

Факт і дата-подія

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

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

Первинка і зв’язок із ПН

До робочого пакета варто покласти договір, документ постачання або передоплати, накладну чи акт повернення, платіжний документ, банківську виписку та акт звірки взаєморозрахунків. Далі знаходять саме ту зареєстровану ПН, яка відображала першу подію. Звіряють покупця, номенклатуру, одиницю виміру, ставку, номер рядка та історію попередніх РК. РК не повинен створювати нову операцію — він коригує показники конкретної ПН.

Хто реєструє і що перевіряє

Якщо РК до ПН, складеної на покупця — платника ПДВ, зменшує загальну суму компенсації постачальнику, його реєструє покупець після отримання від постачальника. Якщо ПН не видавалася отримувачу, у загальному випадку РК реєструє постачальник. Перед переданням файла постачальник контролює знак, залишок рядків, ІПН і відповідність первинці; покупець — факт повернення, право підпису, цілісність документа та строк від дати отримання.

Реєстраційний статус, облік і фінальний контроль

Для зменшувального РК постачальник отримує право зменшити податкові зобов’язання після реєстрації в ЄРПН. Якщо покупець уже відобразив податковий кредит, він зменшує його у періоді, коли виникла підстава для коригування, незалежно від того, чи встиг отримати або зареєструвати РК. Тому «чекаємо квитанцію і нічого не робимо» — небезпечна позиція для покупця. У BAS контролюють сторнування або зміну взаєморозрахунків, ПДВ-регістри та відсутність дублювання; у M.E.Doc чи іншому сервісі — доставку, підписи, квитанцію і фактичний статус ЄРПН.

Timeline навчального кейсу

1. 3 вересня: постачальник відвантажив товар, склав ПН за першою подією та пов’язав її з документом реалізації.
2. 15 вересня: сторони погодили повернення частини партії; домовленість пояснює причину, але ще не доводить рух товару.
3. 18 вересня: товар фактично повернено за накладною. На цю подію формують РК із перевіркою залишку за рядками.
4. 19 вересня: постачальник передав РК покупцю. Дата документованого отримання запускає контроль спеціального строку для зменшувального РК.
5. Після реєстрації: обидві сторони зберігають квитанцію, звіряють ПДВ-регістри та окремо визначають період відображення у декларації.

Цей timeline показує послідовність доказів, а не універсальні дати для будь-якого повернення. У реальній операції можуть відрізнятися момент переходу права власності, статус покупця, вид ПН і попередні коригування.

Сценарна карта 2. Зміна ціни, кількості або номенклатури

Факт, первинка і правильна класифікація

Зміна ціни після постачання виникає, коли сторони переглянули вартість одиниці: надали післяпродажну знижку, погодили доплату або остаточно визначили ціну за умовами договору. Зміна кількості — це інша математика: частину товару повернули, обсяг послуг уточнили або фактична кількість відрізняється від попередньо оформленої. Заміна одного товару іншим уже може бути зміною номенклатури. Однаковий підсумок у гривнях не робить ці випадки тотожними.

Первинка має показати не лише нову суму, а й причину та момент її виникнення: додаткова угода, акт виконаних робіт, акт перерахунку, накладна на часткове повернення, специфікація. Бухгалтер порівнює первинку з початковою ПН і всіма зареєстрованими РК, а потім обчислює контрольний залишок у розрізі кожного рядка та ставки ПДВ.

Код причини — наслідок, а не початок

Чинний довідник містить, зокрема, коди 101 для зміни ціни, 102 для зміни кількості, 103 для повернення товару або авансових платежів і 104 для зміни номенклатури. Але механічно підставляти код за одним словом у договорі не можна. Спочатку визначають, який показник початкового рядка змінюється, чи треба замінити рядок, як працюють групи коригування та яким буде загальний знак РК.

Реєстрація, облік і фінальний контроль

Якщо загальна компенсація збільшується або підсумково не змінюється, РК до ПН, виданої покупцю-платнику, у загальному випадку реєструє постачальник; при загальному зменшенні — покупець. Постачальник збільшує податкові зобов’язання у періоді перерахунку, а покупець отримує право збільшити податковий кредит після реєстрації РК. Для зменшення діє асиметрія, описана в першій карті: право постачальника на зменшення пов’язане з реєстрацією, а покупець не повинен завищувати кредит через її відсутність.

У BAS перевіряють договірну суму, взаєморозрахунки, партії та ПДВ-регістри; у сервісі обміну — підписанта, маршрут документа, квитанцію та статус ЄРПН. Назви команд і розташування полів залежать від конфігурації BAS, релізу й налаштувань M.E.Doc, тому контроль будують за результатом, а не за «універсальним» скриншотом.

Щоб не лише прочитати правило, а відпрацювати операції з ПН і РК у BAS, корисно брати один кейс і проводити його від первинного документа до регістрів та звітності. Саме на такій наскрізній перевірці видно, де програма повторює помилкове рішення користувача.

Сценарна карта 3. Помилка в раніше складеній ПН

Спершу відокремити помилку від нової події

Ключове питання звучить так: «Чи змінилися договір, товар, кількість, ціна або розрахунки після складання ПН?» Якщо так — це, ймовірно, коригування господарської події. Якщо ні, але ПН не відповідає первинним документам, маємо сценарій виправлення помилки. Підміняти друге першим небезпечно: можна створити неправдивий рух товару, неправильну дату або подвійний податковий результат.

Помилки треба класифікувати: реквізит заголовної частини, ІПН отримувача, ознака у верхній лівій частині, дата або порядковий номер, номенклатура чи числовий показник. Для кожної групи чинний Порядок № 1307 передбачає різний маршрут. Наприклад, окремі помилки заголовної частини, які не заважають ідентифікувати операцію, виправляють РК на дату виявлення без заповнення розділів А і Б. Натомість дата складання ПН та її порядковий номер таким способом не виправляються.

Чому код 103 може з’явитися без повернення

Окремий показовий випадок — неправильна ознака у полях верхньої лівої частини ПН. Актуальне роз’яснення ДПС щодо виправлення помилки у верхній лівій частині ПН описує обнулення показників помилкової ПН із кодом 103 та складання нової ПН із правильними реквізитами. Це підтверджує лише конкретну процедуру; переносити її на будь-яку реквізитну або сумову помилку не можна. Для помилкового ІПН, зайвої ПН, помилки в табличній частині чи спеціальної ПН слід окремо звірити чинний порядок і консультацію для відповідної ситуації.

Первинка, реєстрація й облікове відображення

Первинна господарська операція в цьому сценарії не переписується. До пакета додають документи, за якими ПН мала бути складена правильно, копію зареєстрованої ПН, службову довідку з описом помилки, перевірену процедуру виправлення та, за потреби, нову ПН. Сторона реєстрації залежить не від слова «помилка», а від виду ПН, знака і спеціальної норми: в одному випадку реєструє постачальник, в іншому — покупець із помилковим або фактичним статусом.

У BAS неправильний податковий документ не слід «лікувати» зміною первинки, яка була правильною. Спочатку зберігають зв’язок із реальною операцією, потім відображають коригувальний комплект і перевіряють, чи не виникли другі податкові зобов’язання або другий кредит. У M.E.Doc контролюють не лише відправлення, а кожен зареєстрований документ у ланцюгу: помилкову ПН, РК та нову ПН, якщо вона потрібна.

Строки і квитанції: що перевірити на дату подання

Станом на 26 вересня 2026 року тимчасові граничні строки за пунктом 89 підрозділу 2 розділу XX ПКУ такі:

• для ПН/РК, складених з 1 по 15 число місяця включно, — до 5 числа включно наступного місяця;
• для ПН/РК, складених з 16 числа по останній календарний день місяця включно, — до 18 числа включно наступного місяця;
• для РК на зменшення компенсації до ПН, складеної на отримувача — платника ПДВ, — протягом 18 календарних днів із дня отримання такого РК покупцем.

Ці строки мають тимчасову сферу дії, тому їх не варто вшивати у внутрішню інструкцію без дати актуальності. Для зменшувального РК важливо мати доказ дати отримання покупцем: без нього складно захистити розрахунок граничного строку. Перед відправленням також перевіряють операційний день, можливі зупинення реєстрації, чинні обмеження за давністю базової ПН, статус платників і наявність реєстраційного ліміту. Квитанція про прийняття файла сервісом не завжди дорівнює факту реєстрації в ЄРПН — контроль завершується відповідним реєстраційним статусом.

Відображення РК у BAS і M.E.Doc як контрольний ланцюг

Конфігурації BAS і версії сервісів електронного документообігу відрізняються, тому безпечний алгоритм не прив’язується до вигаданого однакового інтерфейсу. Він прив’язується до даних:

1. Первинка: дата, контрагент, договір, номенклатура, кількість, ціна, ставка й сума ПДВ.
2. Обліковий документ: правильно проведений рух товару, коштів і взаєморозрахунків.
3. ПН/РК: посилання на базову ПН, актуальні рядки, знак, причина та відповідальна сторона.
4. Обмін: підпис, доставка адресату, квитанції та остаточний статус ЄРПН.
5. Регістри ПДВ: коректний період, відсутність дубля, правильний податковий кредит або зобов’язання.
6. Декларація: сума потрапила до актуальної форми звітності та, коли це вимагається, деталізована у чинному додатку Д1.

Якщо один із рівнів не збігається, не потрібно одразу перепроводити весь період. Спершу визначають перший вузол, де з’явилася різниця: первинка, документ BAS, сам РК, обмін чи звітність. Це скорочує пошук і не руйнує правильні дані нижче за ланцюгом.

«Контрольна сума» від первинки до декларації

Для РК корисно рахувати не одну технічну суму, а чотири узгоджені підсумки:

Практична формула звірки проста: первинний факт = економічний результат комплекту ПН/РК = дані облікових регістрів = показник декларації. Різниця в будь-якій частині означає, що reconcile не завершено. Після такої наскрізної звірки доречно використати практичну програму навчання з ПДВ, щоб закріпити контроль документів, регістрів і звітності на реальних конфігураціях BAS.

Карта ескалації для неоднозначного випадку

1. Рівень 1 — бухгалтер операції. Збирає первинку, відтворює хронологію, визначає базову ПН, знак і очікуваний економічний результат. Нічого не «виправляє» заднім числом без доказу.
2. Рівень 2 — головний бухгалтер або методолог BAS. Перевіряє статуси платників, попередні РК, алгоритм у конкретній конфігурації, ПДВ-регістри, період декларації та комплект квитанцій.
3. Рівень 3 — профільний ПДВ-експерт. Потрібен, якщо є помилка в ІПН чи даті, спеціальна/зведена ПН, неплатник ПДВ, кілька ставок, експортний режим, старий документ, заблокована реєстрація або суперечність між первинкою і даними ЄРПН.
4. Рівень 4 — офіційне роз’яснення. Якщо наслідки істотні, а чинні норми не дають однозначної відповіді, формулюють фактичні обставини та розглядають отримання індивідуальної податкової консультації. До відповіді зберігають повний журнал рішень і не маскують невизначеність технічною операцією.

Чекліст доказів перед закриттям періоду

• причина РК сформульована одним реченням через реальний факт, а не через код;
• дата-подія підтверджена первинним документом і рухом товару, послуг або коштів;
• базова ПН зареєстрована, правильно ідентифікована, усі попередні РК враховані;
• статус покупця та вид ПН перевірені на релевантні дати;
• код причини, групи й рядки відповідають чинному Порядку № 1307 та конкретному сценарію;
• визначено сторону реєстрації і задокументовано дату отримання зменшувального РК;
• є квитанція та підтверджений статус ЄРПН, а не лише статус відправлення;
• податкові наслідки постачальника і покупця віднесені до належних періодів;
• ПН/РК, BAS-регістри, M.E.Doc і декларація дають однаковий економічний результат;
• використано актуальні на дату подання форму РК, форму декларації та додатки.

Питання для обов’язкового профільного ПДВ-рев’ю

Tax/payroll review: Так. Перед практичним застосуванням кейс має пройти профільне ПДВ-рев’ю. Рев’юеру слід передати не лише готовий РК, а повний комплект доказів і поставити конкретні питання:

• чи правильно визначено господарську подію та дату складання РК;
• чи відповідає вид первинки суті повернення, перерахунку або помилки;
• чи коректні сторона і чинний строк реєстрації саме для цієї ПН;
• чи допускає Порядок № 1307 обраний спосіб виправлення реквізиту;
• чи не потрібна нова ПН, уточнюючий розрахунок або окрема дія через несвоєчасну реєстрацію;
• у якому періоді кожна сторона відображає ПЗ або ПК і який додаток чинної декларації заповнює;
• чи немає спеціальних правил через статус неплатника, зведену ПН, експорт, давність документа або блокування.

Головна ознака якісного РК — не відсутність попереджень у програмі. Це відтворюваний ланцюг доказів: причина, дата, первинка, базова ПН, правильна сторона реєстрації, квитанція, облік і декларація. Якщо цей ланцюг не складається, документ ще не готовий до подання, навіть коли електронна форма технічно заповнена.