Кредит-нота і авансовий рахунок як е-рахунок

Коротко

• Кредит-нота має тип 381 (CreditNote), дебет-нота 383 (Invoice). Обидві посилаються на первісний рахунок у полі BT-25.
• Коригувальний рахунок з кодом 384 для Словаччини лише готується. До того часу ФА рекомендує кредит-ноту і новий рахунок.
• Авансовий (проформа) рахунок як вимога про оплату через Peppol не надсилається. Податковий документ до отриманого платежу так, за ФА з кодом 388.
• Оподаткований аванс у кінцевому рахунку вираховується від’ємним рядком, неоподаткований через PrepaidAmount.
• Графік платежів за оренду або лізинг з 2027 року рахунок за кожен період не замінить.

Кредит-нота: тип 381 і посилання на первісний рахунок

Найчастіший і найпростіший порядок коригування в мережі Peppol, за Фінансовою адміністрацією (далі ФА), це кредит-нота до первісного рахунку (Credit Note), а потім новий, правильний рахунок. У полі BT-25 (InvoiceDocumentReference) мусить бути однозначне посилання на первісний рахунок (FAQ ФА, частина I, питання 50). Кредит-нота у Peppol BIS Billing 3.0 є окремим типом документа 381, і для неї діють ті самі правила мапування, що й для рахунку 380 (FAQ ФА, частина II, питання 17).

Закон про ПДВ вважає електронним рахунком також документ, який змінює первісний електронний рахунок і окремо та однозначно його стосується; він мусить містити порядковий номер первісного рахунку і дані, які змінюються (§ 85o абз. 5). Кредит-нота у Peppol, однак, є повним документом. Пояснювальна записка до урядового законопроєкту (друк 1454), станом на 30. 9. 2026 у першому читанні, зазначає, що норма EN 16931 не дозволяє обмежити зміст коригувального рахунку лише даними, які змінюються, і тому проєкт регулює повідомлення даних з коригувальних рахунків. Проєкт поки що не є чинним законом.

Готову кредит-ноту знайдете у зразку 08: кореневий елемент CreditNote з кодом 381, номер і дата первісного рахунку в cac:BillingReference (BT-25, BT-26) і додатні суми.

Дебет-нота: тип 383

Дебет-ноту, яка збільшує базу оподаткування, можете у Peppol BIS Billing 3.0 скласти з кодом 383 (Debit note) з кодового списку UNCL1001. Зв’язок з первісним рахунком зазначите так само через BT-25 (FAQ ФА, частина II, питання 39). Подивіться зразок 09: кореневий елемент Invoice з кодом 383 і посиланням у cac:BillingReference, в іншому як звичайний рахунок, включно зі строком оплати.

Коригувальний рахунок з кодом 384: поки що ні

ФА наразі рекомендує вирішувати коригування комбінацією кредит-нота і новий рахунок. Разом з OpenPeppol вона готує запровадження коду 384 (коригувальний рахунок), подібно як у Німеччині. Задум полягає в тому, щоб використовувати його у випадках без впливу на ПДВ або ціну, тоді як при впливі на ПДВ або ціну залишиться кредит-нота і новий рахунок. Включення коду 384, за ФА, реальне в межах випуску Peppol BIS Billing 3.0 восени 2026 року (FAQ ФА, частина II, питання 30). Як альтернативу ФА наводить також коригувальний рахунок з усіма обов’язковими реквізитами і посиланням у BT-25 (FAQ ФА, частина I, питання 50).

Один коригувальний рахунок до кількох рахунків

Якщо обставина, вирішальна для коригування бази оподаткування, настала на останній день розрахункового періоду, можете скласти один коригувальний рахунок до кількох повторюваних постачань. Поле BT-25 можна повторювати, тож кожен номер первісного рахунку зазначите в окремому записі, а не розділені знаком в одному полі. Зазначити потрібно всі коригувані рахунки. Період, якого стосується коригування, не є обов’язковим реквізитом; дату складання первісного рахунку зазначити можете, але не мусите (FAQ ФА, частина II, питання 49).

Авансовий рахунок проти податкового документа до отриманого платежу

Тут найбільша різниця між двома документами, які на практиці називають «авансовим рахунком» (FAQ ФА, частина I, питання 34):

• Проформа-рахунок або вимога про оплату не має реквізитів рахунку згідно із законом про ПДВ, і його складанням не виникає податкове зобов’язання. Він не є рахунком у розумінні закону про ПДВ і через систему е-рахунків не надсилається.
• Рахунок до отриманого платежу виникає, коли ви отримаєте платіж перед постачанням товару або послуги (§ 72 абз. 1). Він має характер податкового документа, підлягає режиму електронного рахунку і надсилається через службу доставки.

З 1. 1. 2027 вітчизняний платник мусить скласти електронний рахунок на платіж, який отримає перед постачанням товару або послуги в країні від вітчизняної оподатковуваної особи або вітчизняної неоподатковуваної юридичної особи (FAQ ФА, частина I, питання 38; § 85o абз. 2). Строк становить 15 днів від дня отримання платежу (§ 85o абз. 6 літ. b), як його наводить і ФА (FAQ ФА, частина I, питання 74). Закон регулює його для електронного рахунку окремо: згідно з § 85o абз. 1 § 71 до 76 застосовуються лише тоді, коли абзаци 2 до 8 і 15 не встановлюють інакше. На можливість скласти рахунок до кінця місяця отримання платежу згідно з § 73 абз. 1 літ. b) при е-рахунку тому не покладайтеся.

На тип документа ФА відповідає прямо: для податкового документа до отриманого платежу використовується код 388 (Tax invoice) з кодового списку UNCL1001 (FAQ ФА, частина II, питання 22). Структуру такого документа (один рядок зі ставкою, PrepaidAmount у розмірі всієї суми і PayableAmount 0) показує зразок 12, який використовує саме код 388.

Вирахування авансу в кінцевому рахунку

ФА розрізняє, чи ви виставили до авансу податковий документ (FAQ ФА, частина II, питання 38):

• Оподаткований аванс (ви виставили рахунок до отриманого платежу): вирахування зазначається не в AllowanceCharge, а як від’ємний рядок у cac:InvoiceLine з кількістю -1. Рядок містить базу оподаткування і ПДВ зі ставкою з первісного податкового документа, тож зменшує рекапітуляцію ПДВ. Зв’язок з податковим документом зазначите через BillingReference / InvoiceDocumentReference (BT-25).
• Неоподаткований аванс (податковий документ не виник): не йдеться про коригування бази оподаткування чи ПДВ. Суму зазначите як PrepaidAmount (BT-113), яка лише зменшить суму до оплати. Від’ємний рядок з ПДВ тут не використовується.

Те, що вже сплачені аванси стандартно зазначаються у PrepaidAmount, ФА підтверджує і при розрахункових рахунках (FAQ ФА, частина II, питання 26). Обидві ситуації на одному документі показує зразок 10: від’ємний рядок з кількістю -1 для оподаткованого авансу, зв’язок з податковим документом через BillingReference (BT-25) і неоподаткований аванс у PrepaidAmount.

Оренда, лізинг і графік платежів

Якщо платник з 1. 1. 2027 зобов’язаний скласти електронний рахунок, він уже не може як зведений рахунок згідно з § 75 абз. 2 використати угоду про платежі орендної плати (графік платежів). Електронний рахунок він складе за кожну повторно надану послугу оренди (FAQ ФА, частина I, питання 33 і 51). Це стосується і лізингових платежів, якщо лізинг є наданням послуги. Зведений електронний рахунок можна скласти лише за постачання протягом щонайбільше одного календарного місяця, протягом п’ятнадцяти днів від його кінця (§ 85o абз. 7; FAQ ФА, частина II, питання 41).

Електронний рахунок не потрібно складати, якщо постачання звільнене від податку згідно з § 28 до 43 і 47, тобто наприклад при оренді нерухомості, звільненій згідно з § 38 абз. 3 (FAQ ФА, частина I, питання 51).

Коригування рахунків 2026 року

На документ, який у період з 1. 1. 2027 до 30. 6. 2030 змінює рахунок за постачання, здійснене до 31. 12. 2026, згідно з § 85o абз. 23 поширюються ті самі умови, що й на первісний рахунок. Якщо первісний рахунок був електронним і надісланим службою доставки вже у 2026 році, коригування мусить відповідати тим самим умовам і також іти службою доставки.

Урядовий законопроєкт (друк 1454), станом на 30. 9. 2026 у першому читанні, пропонує це правило (після перенумерації як § 85o абз. 22) пом’якшити: ті самі умови, що й при первісному рахунку, «можуть» застосовуватися. Згідно з пояснювальною запискою постачальник до паперового рахунку 2026 року міг би вибрати паперове або електронне коригування, а до електронного рахунку, який не йшов службою доставки, міг би надіслати коригування також службою доставки. Проєкт поки що не є чинним законом. Інші обов’язкові дані документа підсумовує стаття реквізити е-рахунку, технічні рамки стаття Peppol BIS Billing 3.0.

Часті запитання