Як виставити рахунок-фактуру VAT у KSeF крок за кроком

Звичайний рахунок продажу в KSeF є структурованим XML FA(3). У полі `RodzajFaktury` він повинен мати значення `VAT`, бо офіційна схема FA(3) описує цей код як базовий рахунок.

Правильне виставлення не зводиться до вибору одного коду. Потрібно підготувати дані продавця і покупця, номер рахунку, дати, позиції, ставки VAT, суми, оплату, а потім перевірити XML перед надсиланням.

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

1. Коли ви виставляєте VAT-рахунок у KSeF

2. Чи це точно звичайний VAT-рахунок

3. Які дані підготувати перед виставленням рахунку

4. Крок 1: виберіть компанію і повноваження

5. Крок 2: встановіть RodzajFaktury VAT

6. Крок 3: заповніть дані сторін

7. Крок 4: додайте позиції, ставки і суми

8. Крок 5: згенеруйте XML FA(3)

9. Крок 6: перевірте рахунок перед надсиланням

10. Крок 7: надішліть рахунок і отримайте підтвердження

У цьому посібнику йдеться про звичайний рахунок продажу, тобто базовий рахунок у структурі FA(3). Це типовий документ для продажу товару або послуги, коли ви не документуєте аванс, не розраховуєте попередній аванс і не виправляєте рахунок, уже прийнятий KSeF.

Найважливіше розрізнення практичне: рахунок може містити VAT, але не завжди повинен мати в XML код `VAT`. Авансовий рахунок, кінцевий рахунок після авансу або корекція можуть містити VAT, але в FA(3) працюють в окремих процесах.

Якщо ви не впевнені, почніть з карти типів рахунків у KSeF. Ця стаття припускає, що після такого рішення ви виставляєте саме звичайний рахунок продажу.

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

Наведена нижче таблиця є практичним робочим списком, а не дослівною цитатою зі ст. 106e закону про VAT. Для нетипових транзакцій, авансових рахунків, валют, спеціальних процедур або міжнародного продажу підтвердьте вимоги з бухгалтерією.

Для типового рахунку продажу найважливіше, щоб бізнес-дані можна було однозначно записати у FA(3): хто продає, хто купує, чого стосується продаж, за яку суму, з якою ставкою VAT і коли документ має бути виставлений.

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

Цей крок особливо важливий у бухгалтерському бюро, групі компаній або фірмі, де одна людина обслуговує кілька суб'єктів. Технічно правильний XML не вирішить проблему, якщо рахунок створено з неправильного акаунта платника.

Якщо ви тільки налаштовуєте доступ, поверніться до посібника як згенерувати сертифікат KSeF. Ця стаття зосереджується на самому виставленні рахунку після підготовки доступу.

Для звичайного рахунку продажу у FA(3) ключовим є поле `RodzajFaktury`. В офіційній схемі значення `VAT` означає базовий рахунок. Це не маркетинговий опис і не етикетка з PDF, а код у XML.

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

Добра практика: показуйте тип рахунку в перегляді документа або звіті валідації. Людина, яка виставляє документ, повинна бачити, чи надсилає `VAT`, `KOR`, `ZAL`, `ROZ`, `UPR`, `KOR_ZAL` або `KOR_ROZ`, перш ніж документ потрапить до KSeF.

У звичайному VAT-рахунку почніть з продавця і покупця. Для польської B2B-транзакції найважливіші NIP, повна назва і адреса. Для іноземного контрагента додаються ідентифікатори і країна, а іноді також текст рахунку іншою мовою для одержувача.

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

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

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

Для звичайного VAT-рахунку найчастіші контрольні поля - нетто-суми за ставками, суми податку і загальна сума до сплати. У FA(3) вони є впорядкованими даними, а не таблицею з PDF.

Якщо хочете зрозуміти технічні поля XML, перейдіть до посібника XML і формат FA(3) KSeF. Тут важливіший процес: дані позицій мають узгоджуватися з математикою рахунку і бухгалтерським рішенням.

Рахунок можна підготувати в Aplikacja Podatnika, бухгалтерській системі, ERP або інструменті, який генерує XML FA(3). Незалежно від інструмента результат має бути сумісним зі структурою, яку вимагає KSeF.

Публічний генератор рахунків XML KSeF у KSeFGPT допомагає підготувати звичайний VAT-рахунок як XML. Для використання потрібно вказати email і працювати в межах денного ліміту. Це корисно для простих випадків і тестування даних, але не замінює повний процес надсилання до KSeF.

Не трактуйте завантажений PDF або перегляд як рахунок, прийнятий KSeF. PDF є читабельною візуалізацією для людини. Структурованим рахунком є XML, а ефективність виставлення в KSeF підтверджують лише статус, номер KSeF і UPO.

Валідація перед надсиланням повинна мати два рівні. Перший технічний: чи XML сумісний з FA(3), чи має потрібні поля і чи підтримується тип рахунку. Другий бухгалтерський: чи дані, суми і тип документа відповідають реальному продажу.

Мінімальна перевірка перед надсиланням: `RodzajFaktury = VAT`, правильний NIP продавця, NIP або правильний ідентифікатор покупця і країна, якщо застосовується, правильний номер рахунку, дати, позиції, ставки VAT, суми, валюта і оплата. Якщо щось не збігається, виправте XML перед надсиланням, замість того щоб розраховувати на корекцію після факту.

Для швидкої перевірки файлу можна використати валідатор XML KSeF. Для використання публічного валідатора потрібно вказати email і діє денний ліміт. Валідатор не ухвалює податкового рішення за компанію, але допомагає знайти структурні помилки і очевидні неузгодженості перед подальшим процесом.

Після підготовки і перевірки XML настає етап надсилання. В онлайн-режимі структурований рахунок вважається виставленим у день передання його до KSeF, а отриманим через KSeF у день присвоєння номера, який ідентифікує цей рахунок у системі.

Для процесу компанії найважливіші три дані: статус надсилання, номер KSeF і UPO. Номер рахунку з власної серії, зазвичай поле `P_2`, не є номером KSeF. Це два різні ідентифікатори, і обидва варто зберігати.

Детальний процес сесії, надсилання і отримання підтверджень описує посібник надсилання рахунків до KSeF. Ця стаття зупиняється на мінімумі, потрібному для звичайного VAT-рахунку.

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

Усередині компанії варто розділити три стани: проект рахунку, XML готовий до надсилання і рахунок, прийнятий KSeF. Найбільше помилок з'являється тоді, коли команда трактує згенерований файл або PDF-перегляд як документ, уже ефективно прийнятий.

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

Перша помилка - використання типу `VAT` для документа, який має бути корекцією, авансом або розрахунком авансу. Самою технічною валідацією це не виправити, бо частина рішення випливає з бізнесового і податкового процесу.

Друга помилка - неузгоджена математика: позиції виглядають правильно, але нетто-суми, VAT і брутто не збігаються після знижки або округлення. Третя помилка - дані контрагента, скопійовані зі старого запису без перевірки актуального NIP і назви.

Четверта помилка - повторне виставлення документа поза правильним процесом після відхилення або відсутності UPO. Якщо KSeF відхилив рахунок, почніть з діагностики у статті рахунок відхилено KSeF.

KSeFGPT допомагає на двох рівнях. Публічні інструменти дозволяють підготувати XML звичайного VAT-рахунку і перевірити файл валідатором. Для їх використання потрібно вказати email і працювати в межах денного ліміту. Це добрий етап для простих рахунків, тестів даних і вивчення структури FA(3).

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

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

Використовуйте цей список як коротку процедуру для звичайного VAT-рахунку. Якщо будь-який пункт викликає сумнів, зупиніть надсилання і виправте дані перед переданням документа до KSeF.

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

Спочатку прочитайте типи рахунків у KSeF, якщо не впевнені, чи `VAT` є правильним типом. Потім перейдіть до надсилання рахунків до KSeF, якщо хочете зрозуміти сесію, статуси і підтвердження.

Якщо проблема технічна, поверніться до XML і формату FA(3) KSeF. Якщо документ не пройшов через KSeF, почніть з посібника рахунок відхилено KSeF.

Чи VAT-рахунок у KSeF завжди має RodzajFaktury VAT? Ні. У FA(3) код VAT означає базовий рахунок, тобто звичайний рахунок продажу. Корекція, аванс, розрахунковий рахунок після авансу або спрощений рахунок мають окремі типи документів.

Чи можна надіслати PDF рахунку VAT до KSeF? Не як структурований рахунок. KSeF працює з XML-файлом, сумісним зі структурою FA(3). PDF може бути візуалізацією або джерелом даних для підготовки документа, але формально до KSeF потрапляє XML.

Чи можна виправити звичайний VAT-рахунок після надсилання? Рахунок, прийнятий KSeF, не виправляють редагуванням старого XML або повторним надсиланням того самого документа. Якщо документ потребує зміни, потрібно визначити правильний тип корекції, найчастіше KOR для звичайного рахунку продажу.

Чи безкоштовний генератор KSeFGPT надсилає рахунок до KSeF? Ні. Публічний генератор допомагає підготувати XML звичайного VAT-рахунку, а валідатор допомагає перевірити файл. Для використання публічних інструментів потрібно вказати email і діє денний ліміт. Надсилання до KSeF потребує інструмента, який обслуговує автентифікацію, сесію і статус прийняття.

Як зрозуміти, що VAT-рахунок прийнято KSeF? Найважливіші елементи - статус прийняття, номер KSeF і UPO. Саме генерування XML або завантаження PDF ще не означає, що рахунок виставлено і прийнято в KSeF.

Що робити, якщо VAT-рахунок відхилено? Спочатку перевірте повідомлення валідації, дані сторін, дати, суми і тип документа. Якщо KSeF відхилив документ, виправте дані і надішліть правильний XML, замість того щоб вважати рахунок уже ефективно виставленим.