Інтеграція ERP-системи з KSeF крок за кроком

KSeF (Krajowy System e-Faktur) є польською Національною системою електронних рахунків-фактур. Інтеграція ERP з KSeF має пов’язувати документ в ERP з результатом його обробки, номером KSeF та офіційним підтвердженням отримання, тобто UPO (Urzędowe Poświadczenie Odbioru). Окремий процес має завантажувати рахунки-фактури за закупівлями та передавати їх на погодження або для відображення в бухгалтерському обліку.

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

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

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

1. Обсяг інтеграції та відповідальність

2. Конектор, проміжне ПЗ чи власна інтеграція з API

3. Доступ і середовища

4. Зіставлення даних

5. Продажі, статуси та UPO

6. Отримання рахунків за закупівлями

7. Помилки та повторні спроби

8. Офлайн-режими й аварії

9. 12 приймальних тестів

10. Запуск у робочому середовищі та супровід

11. Вартість і запит комерційної пропозиції

12. Можливості KSeFGPT

13. Поширені запитання

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

Обов’язковість використання KSeF залежить від платника податків і документа. Звільнення від VAT (польського податку на додану вартість) не означає автоматичного звільнення від KSeF, а рахунки-фактури для споживачів можна виставляти в KSeF добровільно. Узгодьте правила з бухгалтерією; сам по собі польський NIP (податковий ідентифікаційний номер) або валюта рахунку не визначають, чи підпадає документ під цей обов’язок.

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

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

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

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

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

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

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

Міністерство фінансів Польщі (MF) повідомляє про безстрокове збереження підтримки токенів KSeF. Обираючи спосіб доступу, перевірте чинні підзаконні акти та документацію API. Для обраного способу призначте відповідального за поновлення, анулювання та безпечне зберігання облікових даних для автентифікації. Секрети й повні дані рахунків-фактур не мають потрапляти до звичайних діагностичних журналів.

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

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

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

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

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

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

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

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

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

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

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

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

Інкрементальне завантаження потребує надійної межі повноти даних. Документація MF описує дату постійного збереження, PermanentStorage, та маркер HWM, який визначає діапазон доступних документів. Не замінюйте його часом із локального годинника або датою виставлення рахунку-фактури.

Обробляйте всі сторінки, частини експорту й усічені діапазони. Документи на межі діапазону можуть з’являтися повторно, тому усувайте дублікати за номером KSeF у межах відповідного середовища й контексту. Зсувайте точку синхронізації лише після надійного збереження всього обробленого діапазону.

Результатом має бути звірений набір рахунків за закупівлями, який залишається повним після затримки збереження, повторного завантаження та збою імпорту. Один рахунок-фактура, видимий у кількох ролях, не повинен створювати кілька зобов’язань до оплати.

Приклад: ERP запустила надсилання, KSeF почала обробку, але з’єднання обірвалося до отримання відповіді. Зафіксуйте невідомий результат. Якщо маєте референс рахунку-фактури, прочитайте його статус; якщо лише референс сесії, звірте її документи. Не створюйте змінений XML лише для того, щоб повторити передавання.

Виконуйте повторні спроби на основі надійно збереженого реєстру, з одним активним виконавцем для документа. Статус дубліката з кодом 440 є статусом обробки рахунку-фактури, а не кодом HTTP. Використовуйте повернутий зв’язок із первинним документом. Локальний контроль усе одно потрібен: той самий за змістом рахунок може мати різні технічні дані.

У разі HTTP 429 дотримуйтеся часу очікування, зазначеного в Retry-After, та обмежте інтенсивність відповідної групи запитів. Помилка XML потребує виправлення даних. Відсутність прав потребує втручання адміністратора. Тимчасові помилки читання можна обробляти повторними спробами зі збільшенням інтервалу; кожна спроба має зберігати референси й досягнутий прогрес.

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

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

Наведені нижче строки відповідають інформації MF, перевіреній 15 жовтня 2026 року. Offline24 не означає 24 астрономічні години. Черга має враховувати робочі дні, відстежувати повідомлення та попереджати до закінчення строку. Якщо тим часом оголошено ще одну аварію, застосуйте відповідні правила переходу між режимами.

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

У разі передавання документа до його надсилання в KSeF отримувачам, зазначеним у ст. 106gb ч. 4 польського закону про VAT, потрібні відповідні позначення OFFLINE і CERTYFIKAT із сертифікатом типу 2. Для польського покупця з NIP MF описує підтвердження операції, яке не є рахунком-фактурою. Після прийняття візуалізація, яку передають поза KSeF, має QR-код із номером KSeF. Повна аварія не потребує QR-коду KSeF або подальшого надсилання рахунку.

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

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

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

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

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

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

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

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

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

KSeFGPT пропонує готове підключення до Fakturownia.pl: налаштування за допомогою субдомену й токена API, попередній перегляд, надсилання окремих документів або пакетів і перевірку результату. Вибрані рахунки-фактури з KSeF можна також експортувати до Fakturownia. Можливості описано в модулі «Інтеграції».

Імпорт файлів є окремим способом роботи, відмінним від прямого підключення до ERP. PDF потребує розпізнавання за допомогою OCR і перевірки даних, а CSV, XLS або XLSX потребують розбору та зіставлення стовпців. До KSeF надходить підготовлений XML FA(3). Доступність експорту даних із конкретної ERP потрібно підтвердити в її конфігурації.

Наразі KSeFGPT не має прямої інтеграції із SAP. Автоматичне читання із SAP та збереження номера KSeF у SAP залишаються запланованими функціями без оголошеної дати запуску. Не поширюйте можливості готового підключення до Fakturownia на будь-яку ERP. Інструменти виставлення рахунків і обміну даними не замінюють повноцінної бухгалтерської системи або податкової оцінки.

Відповіді на запитання про можливості інтеграції, підтвердження та приймання впровадженого рішення.