Сповіщення про нові рахунки-фактури в KSeF

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

Такий додатковий рівень може забезпечити KSeFGPT: він періодично перевіряє метадані рахунків-фактур у KSeF, розпізнає новий документ і запускає автоматизацію. Стандартний сценарій надсилає окремий або зведений електронний лист, а власна дія сповіщення може використовувати електронну пошту, Slack, Telegram або webhook.

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

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

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

1. Чи надсилає KSeF сповіщення про нові рахунки-фактури?

2. Як програма виявляє новий рахунок-фактуру в KSeF?

3. Три події, які не слід плутати

4. Що має містити корисне сповіщення?

5. Як спрямовувати сповіщення відповідним людям?

6. Сповіщення не означає погодження чи обліку

7. Як KSeFGPT перетворює новий рахунок-фактуру на дію?

8. Найчастіші запитання

Добре спроєктоване сповіщення пов’язує подію в KSeF із конкретною відповідальністю в компанії, але не замінює перевірки документа.

Ні. У Посібнику KSeF 2.0, частина II, розділ 6.4, сторінка 98, прямо зазначено: «KSeF не надсилає автоматично системних сповіщень про отримання нового рахунка-фактури в системі». Матеріал Міністерства фінансів Польщі також пояснює, що програмне забезпечення платника податків має надсилати запити до KSeF, а функцію сповіщення можна запровадити у фінансово-бухгалтерській програмі, якою він користується. Стан матеріалів перевірено 23 липня 2026 року.

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

Доступність у KSeF: документ уже може бути доступний покупцеві.

Сповіщення: додаткову інформацію може надіслати програма, яка використовує дані KSeF.

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

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

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

Джерело даних: KSeF надає інформацію про рахунки-фактури через API.

Синхронізація: застосунок отримує дані, доступні відповідному суб’єкту, і розпізнає нові документи.

Дія: програма запускає вибраний канал комунікації або подальший процес.

У продукційному KSeF API 2.0, за станом, перевіреним 23 липня 2026 року, є операція отримання метаданих рахунків-фактур за фільтрами. Документація інкрементального отримання також визначає необхідне повноваження і спосіб упорядкування результатів. Ця інформація описує технічний механізм KSeF, а не гарантований час надходження сповіщення в зовнішньому застосунку.

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

Вислів сповіщення про рахунок-фактуру може описувати три різні ситуації. Їх розмежування допомагає уникнути помилкового припущення, що повідомлення для контрагента, внутрішнє сповіщення про покупку та UPO є взаємозамінними.

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

Вихідний рахунок-фактура: окреме повідомлення може поінформувати контрагента або команду, що надсилання до KSeF завершилося успішно.

Системні підтвердження: статус, номер KSeF і UPO документують окремі елементи процесу, але не доводять, що покупець прочитав рахунок-фактуру.

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

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

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

Одержувач: особа або група, відповідальна за цей вид рахунка-фактури.

Очікувана дія: чітка інформація про те, чи потрібно документ перевірити, погодити, з’ясувати або передати далі.

Безпечний доступ: посилання на відповідний екран замість автоматичного розсилання повного XML або надмірного обсягу даних.

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

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

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

Сума: власна умова може порівнювати суму брутто з внутрішнім порогом компанії. Такий поріг є організаційним правилом, а не законодавчим обмеженням.

Продавець: власна умова може розпізнати доступні в метаданих дані постачальника і запустити сповіщення у вибраному каналі.

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

Відповідальність: спільний канал Slack або Telegram може надати сповіщення команді також тоді, коли одна людина недоступна.

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

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

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

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

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

KSeFGPT не очікує push-сповіщення від KSeF, адже KSeF такого повідомлення не надсилає. Механізм продукту періодично отримує метадані рахунків-фактур, запам’ятовує вже розпізнані номери KSeF і запускає сценарій автоматизації лише для нових документів.

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

Виявлення: KSeFGPT перевіряє метадані, доступні в KSeF, і порівнює їх зі збереженим станом.

Умова: стандартне правило розрізняє один і кілька рахунків-фактур, а власні умови можуть використовувати поля даних тригера.

Одержувач: інформація надходить на налаштовану адресу електронної пошти, у канал Slack, чат або канал Telegram чи до під’єднаної системи через webhook.

Дія: команда переходить до перевірки, погодження, з’ясування або іншої дії, передбаченої в компанії.

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

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

Чи KSeF сам надсилає електронний лист, SMS або push-сповіщення про новий рахунок-фактуру? - Ні. Відповідно до Посібника KSeF 2.0 Міністерства фінансів Польщі, KSeF не надсилає автоматичного системного сповіщення про отримання нового рахунка-фактури. Таку функцію може забезпечити програмне забезпечення, яке перевіряє KSeF і запускає сповіщення після виявлення документа.

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

Чи може сповіщення надійти кільком особам? - Так, якщо сповіщення надходить у спільний канал команди, наприклад у Slack або Telegram. Стандартна автоматизація KSeFGPT надсилає повідомлення на налаштовану адресу електронної пошти, а власна дія сповіщення може використовувати електронну пошту, Slack, Telegram або webhook. Перевірена реалізація вказує адресу чи інтеграцію, а не організаційну групу KSeFGPT як окремий тип одержувача автоматизації.

Чи підтверджує UPO, що покупець прочитав рахунок-фактуру? - Ні. UPO стосується результату опрацювання документа в KSeF. Його не слід вважати підтвердженням того, що покупець прочитав рахунок-фактуру, погодив витрату або розпочав опрацювання документа.

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

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

Що робити, якщо в KSeF з’явився рахунок за не наші покупки? - перевірте, чому новий документ потребує змістовної перевірки.

Як перевірити статус рахунка-фактури в KSeF після надсилання? - подивіться, як читати результат процесу для вихідного рахунка-фактури.

UPO в KSeF - дізнайтеся, що підтверджує UPO і чим воно відрізняється від операційного сповіщення.