EZD з підтримкою KSeF — це ще не обіг фактур

Цей допис — для секретарів і скарбників, які чують від постачальника «наша EZD підтримує KSeF» і замислюються, чи закриває це тему обігу фактур.

Що насправді робить інтеграція EZD з KSeF

З 1 лютого 2026 р. установи отримують структуровані фактури через Національну систему е-фактур Польщі (KSeF). Частина систем класу EZD, зокрема EZD RP, уміє отримувати таку фактуру й показувати її як вхідну кореспонденцію. Це реальна перевага: фактура не губиться в поштовій скриньці, має номер KSeF і дату надходження, її видно в системі. Проте зазвичай вона не потрапляє одразу до справи. Спочатку її бачить канцелярія, яка передає її до профільного підрозділу, і лише цей підрозділ долучає фактуру до справи. А чи канцелярія одразу знає, до якого структурного підрозділу таку фактуру скерувати? Варто також пам'ятати, що метадані фактури описують саму фактуру: позиції, суми нетто і брутто, ставки ПДВ. Вони не завжди збігаються з тим, що міститься у формі реєстрації вхідної кореспонденції, обсяг метаданих якої визначає канцелярська інструкція.

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

Шлях фактури від надходження до оплати

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

1. Надходження. Фактура надходить через KSeF, але не лише. До кінця 2026 р. частина менших постачальників ще може виставляти фактури поза KSeF, а закордонні постачальники виставлятимуть їх поза системою й надалі. Фактури й надалі надходять електронною поштою та на папері, а паперові потрібно сканувати і розпізнавати (OCR), щоб дані не доводилося переписувати вручну. У KSeF, як правило, немає місця для вкладень (структура FA(3) передбачає лише обмежене вкладення у вигляді даних, і його застосування потрібно зареєструвати), тому постачальник часто надсилає ту саму фактуру додатково електронною поштою разом із супровідними документами: актом приймання, переліком робіт чи специфікацією. Трапляється й так, що він надсилає роздруківку або PDF фактури, яка вже є в KSeF, без жодних вкладень. У разі збою KSeF або в офлайн-режимі фактура з QR-кодом потрапляє до установи раніше, ніж до системи. Тож установа має знати, що вже отримала цю фактуру, щоб не опрацьовувати її двічі. Крім того, фактура — не єдиний видатковий документ. Страхові поліси, рахунки до цивільно-правових договорів, нотатки (ноти), платежі та рішення щодо заборгованостей проходять подібний шлях: опис, погодження, класифікація, облік, оплата. Усі видаткові документи, незалежно від каналу надходження й типу, мають потрапляти до єдиного обігу. Інакше установа матиме окремий шлях для фактур із KSeF і другий, паперовий, для всього іншого.
2. Прив'язка до договору або замовлення. Фактура стосується конкретного договору, доручення чи замовлення. Іноді достатньо зіставити її з договором. Іноді — із замовленням, яке не має окремого договору. А буває й так, що в межах рамкового договору подається кілька послідовних замовлень, і фактура стосується одного з них, тож її потрібно прив'язати до замовлення, а через нього — до договору. Правильна прив'язка одразу вказує профільний підрозділ, суму до розрахунку й те, скільки залишилося із замовлення та договору. Без реєстру договорів і обліку замовлень комусь доводиться шукати це вручну.
3. Опис і погодження. Підрозділ, який робив замовлення, підтверджує, що послугу виконано або товар доставлено відповідно до договору чи замовлення. Часто цим усе не закінчується. Якщо закупівлю фінансовано з кількох бюджетів, за які відповідають різні підрозділи, кожен із них має погодити ту частину фактури, яка навантажує його бюджет. Якщо видаток має інформаційно-технологічний характер, інструкція обігу зазвичай вимагає ще й погодження відділу інформаційних технологій, навіть якщо профільним є інший відділ. Подібно буває з інвестиційними видатками, проєктами ЄС чи публічними закупівлями. Отже, одна фактура може потребувати трьох-чотирьох погоджень, а зібрати їх усі, особливо на папері, часто є найбільш виснажливою частиною обігу: фактура чекає на столі людини у відпустці, повертається через відсутній підпис, і ніхто не знає, у кого вона наразі перебуває.
4. Джерело фінансування та бюджетна класифікація. Потрібно вказати розділ, підрозділ і параграф бюджетної класифікації, завдання з фінансового плану, а іноді — проєкт і джерело співфінансування. Хтось перевіряє, чи передбачено на це кошти в плані.
5. Контроль, резолюція та затвердження до виплати. Бухгалтерія перевіряє фактуру за формальними і розрахунковими критеріями, а головний бухгалтер (у JST — скарбник) підтверджує попередній контроль. Документ кваліфікується для відображення в обліку. Після контролю скарбника інструкція обігу часто вимагає ще затвердження членом виконавчого органу, який здійснює нагляд за профільним підрозділом (у гміні — війтом, бургомістром або заступником), а за його відсутності — іншим членом виконавчого органу. Це ще одна людина, ще один підпис і ще одне місце, де фактура може чекати, якщо обіг не знає, хто кого заміщує.
6. Внесення до фінансово-бухгалтерської системи. Погоджена фактура має потрапити до бухгалтерії. Це найважливіша точка стику систем: якщо тут немає з'єднання, дані фактури, яка надійшла як структурований файл, хтось переписує з роздруківки.
7. Оплата. Платіж — це окремий процес, пов'язаний із фактурою, але не її частина. Зазвичай його обслуговує фінансово-бухгалтерська система: в один пакет переказів потрапляють платежі з кількох фактур, із контролем термінів і, якщо потрібно, поділеного платежу. Обіг фактури має лише надати бухгалтерії повний комплект даних, а потім знати, що фактуру оплачено.
8. Архівування. Фактура з описом, погодженнями та підтвердженням оплати має залишитися в одному місці, готова до перевірки.

KSeF з EZD обслуговують перший крок і частину восьмого. Решта шести відбувається осторонь.

Приклад процесу на одній схемі

Нижче той самий шлях у нотації BPMN — стандартному записі процесів. Кожна доріжка — це одна роль в установі. Чорні стрілки показують, хто за ким працює, а пунктирні лінії — обмін даними із системами, які стоять поряд з обігом: KSeF, картотекою контрагентів, реєстром договорів і замовлень та фінансово-бухгалтерською системою. Завдання з піктограмою зубчастого колеса може виконати система без участі людини. Рухомий маркер показує шлях однієї фактури: від KSeF через послідовні погодження до внесення в бухгалтерію, а менші маркери — це дані, якими обмінюються із системами по дорозі. Це приклад, а не шаблон: у кожній установі доріжки, погодження й з'єднання будуть трохи іншими.

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

Скількох систем торкається одна фактура

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

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

Де насправді витрачається час

Змістове погодження чи контроль скарбника — це рішення, і вони мають залишатися за людьми. Час витрачається деінде, на допоміжних діях:

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

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

Як розумно підійти до обігу фактур

Порядок має значення. Спочатку процес, потім інструмент.

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

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

Визначити, де відбувається погодження. Це не обов'язково має бути EZD. Погодження можуть відбуватися в системі класу EZD, в окремому інструменті для обігу (workflow) або в модулі фінансово-бухгалтерської системи. Важливо, щоб вони відбувалися в одному місці, з повним слідом, і щоб результат рухався далі без переписування. Добре налаштований обіг сам визначає шлях погодження на основі бюджетів, з яких фінансується видаток, та його виду, запускає погодження паралельно там, де черговість не має значення, і має заміщення на час відпустки. Різницю між системою для процесів і бухгалтерською системою я описую в дописі про BPM і галузеві системи.

З'єднати обіг із фінансово-бухгалтерською системою. Це найважливіша інтеграція: дані погодженої фактури — з описом, класифікацією та погодженнями — мають потрапляти до бухгалтерії як готовий документ, а не роздруківка. Це можна зробити трьома способами. Найкращий — програмний інтерфейс (API), наданий постачальником системи. Другий — прямий запис до бази даних бухгалтерської системи, що потребує згоди та участі постачальника, бо помилку в такому записі потім важко виявити. Третій, коли система не має інтерфейсу, — робот (RPA): проста програма, яка від імені користувача вносить фактуру через екран, так само як це зробила б людина. Робот буває швидким і дешевим на старті, але крихким, бо зміна вигляду екрана після оновлення може його зупинити. Варто розглядати його як міст на час, поки постачальник не надасть інтерфейс. Платежі та пакети переказів можуть залишатися там, де вони є сьогодні, — у фінансово-бухгалтерській системі.

Узгодити картотеку контрагентів. Фактура в бухгалтерії має потрапити до правильного контрагента, тож обіг і фінансово-бухгалтерська система мають говорити про одні й ті самі суб'єкти. У системі класу EZD контрагентів зазвичай набагато більше: там є мешканці, заявники та установи, які пишуть до органу влади, але ніколи не виставлять йому фактуру. У фінансово-бухгалтерській системі є лише суб'єкти, з якими установа має розрахунки. Тому з самого початку потрібні чіткі правила життєвого циклу даних контрагента в системах установи: хто і коли створює контрагента та в якій системі, хто і коли оновлює його дані, а також як зміна в одній системі має переноситися до решти. До цього додається спосіб розпізнавання того самого постачальника, наприклад за податковим ідентифікатором (NIP), щоб новий постачальник із фактури потрапляв до бухгалтерії без повторного ручного створення.

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

Оновити інструкцію обігу. Електронне погодження, не передбачене інструкцією, зазвичай закінчується тим, що фактуру все одно друкують «для порядку». Змінюючи процеси та інструкцію, варто спочатку уявити собі ідеальний стан: такий спосіб роботи людей, за якого ніхто вже не виконує зайвих допоміжних дій. І лише під нього підлаштовують положення інструкції, а не навпаки.

Джерела

• Міністерство фінансів Польщі: обсяг обов'язкового KSeF
• Закон від 29 вересня 1994 р. про бухгалтерський облік, ISAP (ст. 21, 22)
• Закон від 27 серпня 2009 р. про публічні фінанси, уніфікований текст Канцелярії Сейму (ст. 54)
• Календар обов'язків Krogis: KSeF, e-Doręczenia, EZD

Правовий стан станом на 30 жовтня 2026 р.