Податкова накладна: навчальний цикл від підстави до контролю

Навчальний кейс: одна операція без прихованих припущень

Карта шести контрольних воріт

Ворота 1–2: від господарської підстави до дати ПН

Ворота 3–4: реквізити, подання і доказ реєстрації

Ворота 5–6: BAS, офіційні дані та контроль декларації

Три помилки, які проходять крізь форму непомітно

Картка самоперевірки: 10 пунктів перед закриттям періоду

Мінітест: чи працює маршрут без підказок

Маршрут наступної практики

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

Актуальність: 26 вересня 2026 року. На цю дату перевірено норми розділу V Податкового кодексу України, чинну форму податкової накладної, Порядок її заповнення № 1307, правила роботи ЄРПН і актуальні роз’яснення ДПС. Реєстраційні строки та тимчасові особливості треба повторно перевіряти саме на дату конкретної операції. Перед випуском матеріал має пройти обов’язкове профільне tax/payroll review. Стаття є навчальним маршрутом, а не індивідуальною податковою консультацією.

Навчальний кейс: одна операція без прихованих припущень

Розглянемо лише одну наперед визначену послідовність. ТОВ «Оріон», платник ПДВ, продає ТОВ «Вектор», яке також є платником ПДВ, партію офісних крісел. Операція здійснюється на митній території України, оподатковується за основною ставкою 20% і не має пільг чи спеціального режиму. Договірна вартість партії — 60 000 грн, у тому числі ПДВ 10 000 грн.

1. 4 вересня 2026 року сторони уклали договір і погодили специфікацію.
2. 7 вересня покупець перерахував 100% передоплати; банк зарахував кошти на рахунок продавця цього самого дня.
3. 12 вересня продавець відвантажив усю партію та оформив видаткову накладну.
4. Повернення коштів, зміни ціни, кількості чи номенклатури не було.

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

Які дані не можна домислювати

Навіть у навчальному прикладі треба відділити відомі факти від реквізитів, що підлягають перевірці. До складання документа бухгалтер збирає:

• договір, специфікацію і погоджені умови оплати та постачання;
• банківський документ і фактичну дату зарахування коштів продавцю;
• видаткову накладну та фактичну дату відвантаження;
• чинний ПДВ-статус обох сторін на дату операції;
• найменування сторін та їхні податкові номери з перевіреного джерела;
• номенклатуру, одиниці виміру, кількість, ціну, ставку і суми за первинними документами;
• код товару згідно з УКТ ЗЕД, визначений за належними даними про товар, а не за схожою позицією в старому документі;
• чинну форму ПН і правила її заповнення на дату складання;
• актуальний граничний строк реєстрації з урахуванням режимних та перехідних норм;
• конфігурацію, реліз і налаштування BAS, у якій відображають операцію.

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

Карта шести контрольних воріт

«Ворота якості» — це момент, після якого операцію не передають далі, доки не зібрано доказ проходження. Така логіка не дає помилці тихо перейти з договору до ПН, а потім — до декларації.

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

Ворота 1–2: від господарської підстави до дати ПН

Ворота 1. Спочатку доведіть зміст операції

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

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

Ворота 2. Визначте першу подію, а не зручну дату

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

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

Ворота 3–4: реквізити, подання і доказ реєстрації

Ворота 3. Звірте зміст до підписання

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

Контрольна сума проста: база 50 000 грн, ПДВ 10 000 грн, загальна сума 60 000 грн. Але арифметична рівність не виправляє помилкового покупця, коду чи дати. Доказ проходження — контрольна копія вхідних даних, де видно джерело кожного критичного реквізиту. Конкретні назви команд, вкладок чи полів не наводимо: вони залежать від продукту, релізу та налаштувань, а імітація універсального інтерфейсу створює хибну впевненість.

Ворота 4. Відокремте відправлення від реєстрації

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

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

Ворота 5–6: BAS, офіційні дані та контроль декларації

Ворота 5. Відобразіть операцію один раз і в правильному періоді

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

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

Ворота 6. Зіставте облік із ЄРПН перед декларацією

Внутрішній статус у програмі не замінює офіційного результату обробки. ПКУ визначає, що підтвердженням прийняття ПН/РК до ЄРПН є електронна квитанція, а покупець має право звіряти отримані дані з Реєстром; це правило можна перевірити в актуальному розділі V Податкового кодексу на сайті ДПС. Тому контрольний пакет містить квитанцію або офіційні дані Реєстру, а не тільки позначку локальної програми.

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

Три помилки, які проходять крізь форму непомітно

1. Невірна підстава

ПН може виглядати акуратно, але бути складеною за неправильним договором, на непідтверджену суму або за датою рахунка. Лікується це не повторною перевіркою форми, а поверненням до воріт 1: встановити зв’язок платежу з договором, предметом та сторонами. У нашому кейсі доказом є зарахування саме 60 000 грн за погоджену партію, а не сам факт існування рахунка.

2. Дубль або пропуск

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

3. Розрив між реєстрацією й обліком

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

Картка самоперевірки: 10 пунктів перед закриттям періоду

1. Чи підтверджені сторони, предмет і сума договором та специфікацією?
2. Чи встановлено фактичну послідовність оплати й постачання?
3. Чи підтверджена дата першої події банківським або первинним документом?
4. Чи використано чинну форму та Порядок заповнення на дату складання?
5. Чи має кожен критичний реквізит перевірене джерело, а арифметика сходиться?
6. Чи визначено актуальний строк реєстрації саме для цієї дати та виду документа?
7. Чи збережено квитанцію, дату/час подання і фактичний статус у ЄРПН?
8. Чи відображено ПДВ у BAS один раз, у належному періоді та в перевіреному релізі?
9. Чи зіставлено реквізити, базу і ПДВ між первинними документами, BAS та ЄРПН?
10. Чи пояснена кожна розбіжність до перенесення показників у декларацію?

Мінітест: чи працює маршрут без підказок

1. Яка подія визначає дату ПН у кейсі? Зарахування 100% передоплати 7 вересня, бо воно сталося раніше за відвантаження.
2. На яку суму складається ПН? На 60 000 грн, у тому числі ПДВ 10 000 грн, оскільки передоплата покриває всю партію.
3. Чи потрібна друга ПН 12 вересня? Ні: відвантаження не створює повторного зобов’язання щодо вже охопленої суми.
4. Чи потрібен РК? Ні: у заданих фактах немає зміни компенсації, повернення або зміни погоджених показників.
5. Що доводить проходження реєстраційних воріт? Не саме відправлення, а збережена квитанція та перевірений офіційний статус.
6. Що завершує цикл? Звірка первинних документів, ЄРПН, обліку BAS і показників декларації з документованим результатом.

Маршрут наступної практики

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

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