Коригування до нуля в KSeF і ризик спору з податковою щодо VAT

Рахунок, прийнятий KSeF, тобто Krajowy System e-Faktur, польською національною системою електронних рахунків, не можна виправити через редагування, анулювання або видалення. Якщо документ отримав номер KSeF, помилку виправляють коригувальним рахунком, який створює наступний слід у системі.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Коли коригування до нуля в KSeF є обгрунтованим? Коригування до нуля є обгрунтованим передусім тоді, коли потрібно обнулити весь господарський ефект документа, наприклад при повному поверненні, анульованій операції, помилковому рахунку або рахунку, виставленому на неправильний суб'єкт.

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

Чи коригування до нуля потребує підтвердження отримання покупцем? У випадку структурованого коригувального рахунку до нуля, виставленого в KSeF, наприклад при повному поверненні товару, MF вказує, що продавець не мусить мати підтвердження отримання покупцем, бо покупець отримує коригування в KSeF.

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

Чи відхилений XML у KSeF потрібно коригувати? Ні. Якщо KSeF відхилив XML, рахунок не був ефективно виставлений у системі і не має номера KSeF. Потрібно виправити файл або дані та надіслати рахунок повторно як первинний документ.

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

Для ризику на стороні покупця корисним буде текст Що робити, якщо в KSeF з'явився рахунок за не наші покупки?.

Якщо коригування впливають на облік, перевірте також KSeF і JPK.

Після кожного відправлення коригування контролюйте підтвердження. Дивіться UPO в KSeF.