1 лютого 2026 року польська Національна система електронних фактур (KSeF) перестала бути темою галузевих конференцій і стала щоденною рутиною бухгалтерій. За графіком Міністерства фінансів Польщі обовʼязок спершу охопив найбільших платників податку, а з 1 квітня 2026 року — усі інші компанії, що виставляють рахунки в B2B. Для ринку ІТ це означало жорсткий дедлайн: перебудувати те, як тисячі компаній виставляють документи, і встигнути до дати.
Більшість вендорів поставилася до задачі як до латки — дописала модуль до наявного продукту й закрила питання. Ми пішли іншим шляхом. Ми побудували Biurko.io: самостійну платформу для електронного фактурування, спроєктовану з першого рядка коду під реалії API KSeF 2.0.
Ця стаття — повна дуга проєкту: ринковий контекст, рішення «купити чи будувати», обсяг, архітектура і продакшен-реліз. Ми пишемо її не для того, щоб похвалитися стеком. Рішення, які ми ухвалювали дорогою, — це рівно ті самі рішення, перед якими стоїть будь-яка компанія, що планує власну бізнес-систему.
Ринковий контекст: чому KSeF виявився операційною, а не податковою проблемою
Коли Міністерство фінансів публікувало чергові версії графіка, у більшості компаній тема потрапляла на стіл головного бухгалтера. Це була помилка категорії. KSeF — не зміна в розрахунках, а зміна в русі документів, тобто в процесі, який одночасно зачіпає продажі, логістику, стягнення заборгованості та клієнтський сервіс.
Графік, який не залишив запасу
Запуск розбили на етапи: великі субʼєкти з лютого 2026 року, мікро-, малий і середній бізнес — з квітня 2026 року, а компанії з обмеженим доступом до цифрових інструментів — із січня 2027 року. На папері це виглядало як комфортний розподіл у часі. На практиці двомісячний розрив між першою та другою хвилею означав, що постачальники ПЗ мали мати готовий і протестований продукт уже в січні — одразу для всієї клієнтської бази.
Є ще одна стратегічно важлива деталь: 2026 рік лишається перехідним періодом, у якому штрафи за помилки та невідповідність систем призупинено, а обовʼязок вказувати номер KSeF у платіжних дорученнях перенесено на 2027 рік. Бізнес отримав час на доопрацювання процесів — але не дозвіл відкладати саму інтеграцію.
Що обовʼязок означає на практиці
Структурована фактура — це не PDF під іншою назвою. Це XML-документ за схемою FA(3), надісланий до централізованої системи, яка присвоює йому номер і повертає офіційне підтвердження отримання. Наслідки цілком практичні:
Немає варіанту «надішлю на пошту» — документ існує лише тоді, коли його прийняла державна система.
Немає правок на льоту — коригування є окремим документом, повʼязаним із первинним номером KSeF.
Інтеграція стає єдиною точкою відмови — якщо вона впала, продажі стоять.
Немає толерантності до неповних даних контрагента — схема валідує структуру безжально.
Саме останній пункт виявився найдорожчим. Компанії роками тримали в базах неповні картки контрагентів, бо фактура в PDF «якось виходила». Централізований валідатор таких компромісів не приймає.
Рішення: купити готове, адаптувати чи будувати своє
Будь-який проєкт такого масштабу починається з одного питання. У випадку KSeF відповідь не була очевидною, бо ринок вендорів заповнився дуже швидко.
Чому готових рішень виявилося недостатньо
Ми оцінили доступні варіанти під потреби наших клієнтів — переважно середнього бізнесу, бухгалтерських бюро та груп компаній із кількома юридичними особами. Три речі відсіяли більшість інструментів на ринку.
Робота з кількома субʼєктами. Значна частина рішень будувалася за моделлю «одна ліцензія = одна компанія». Для бухгалтерського бюро, яке веде сорок клієнтів, або для групи з шести компаній це неприйнятно — і річ не в ціні, а в тому, що бухгалтерка перемикатиме акаунти сорок разів на день.
Закрита інтеграція. Модулі KSeF, вбудовані у великі ERP-системи, працювали коректно, але лише всередині цих систем. Клієнт із власною CRM або інтернет-магазином мусив будувати міст між двома світами й підтримувати його самотужки.
Відсутність передбачуваності при змінах. Схема та API з боку Міністерства еволюціонували протягом усього 2025 року. Компанії, залежні від зовнішнього постачальника, стояли в черзі на оновлення без жодного впливу на пріоритети.
Критерії, які вирішили справу
Рішення «build vs buy» ми ухвалювали за чотирма критеріями — і радимо їх кожному клієнту, який стоїть перед схожим вибором.
Чи є цей процес для нас диференціювальним? Саме по собі фактурування — ні. Але ведення десятків субʼєктів з однієї панелі, трьома мовами, з повним контролем над чергою відправлень — так.
Скільки система житиме? KSeF — безстроковий обовʼязок. Інвестиція розкладається на десятиліття, а не на фінансовий рік.
Скільки коштує залежність? Коли йдеться про критичний процес продажів, привʼязка до чужої дорожньої карти — це реальний операційний ризик.
Чи маємо компетенцію це підтримувати? На це питання більшість компаній відповідає надто оптимістично. Ми відповіли ствердно, бо інтеграції із зовнішніми системами — наша щоденна робота.
Варто сказати прямо: для багатьох компаній правильною відповіддю є купівля готового інструмента. Власний продукт має сенс тоді, коли процес нетиповий, масштаб виправдовує витрати, а команда здатна його супроводжувати. У нашому випадку виконувалися всі три умови.
Обсяг продукту: що обовʼязково мало бути в продакшен-версії
Обсяг ми визначали у зворотному порядку до звичної практики — не зі списку побажань, а зі списку того, без чого продукт був би непридатним у перший же день.
Мультикомпанійна панель як фундамент, а не додаток
Це було перше архітектурне рішення й найважче для подальшої зміни. Мультитенантність, дописана до готової системи, завжди виглядає як протез: окремі логіни, дублювання даних, відсутність спільної звітності. Ми спроєктували Biurko.io так, що контекст компанії є шаром, який проходить крізь увесь застосунок. Права доступу, нумерація, налаштування KSeF і дані контрагентів ізольовані на рівні субʼєкта, але користувач перемикається між ними одним кліком.
Інтеграція з API Міністерства фінансів
Це серце проєкту й водночас його найбільший ризик. Інтеграція охоплює повний життєвий цикл документа: автентифікацію в контексті конкретного податкового номера, надсилання фактури за схемою FA(3), відстеження статусу обробки, отримання номера KSeF та офіційного підтвердження, а також імпорт вхідних документів.
Рівень автентифікації спирається на сертифікати KSeF, які платники отримують через модуль сертифікатів і повноважень, наданий Міністерством. У технічному вимірі це означало побудувати безпечне зберігання та ротацію облікових даних окремо для кожного субʼєкта, який обслуговує платформа.
Три мови інтерфейсу
Польська бухгалтерія дедалі частіше обслуговує компанії з іноземним капіталом, а фінансові команди в центрах спільних послуг рідко є одномовними. Інтерфейс Biurko.io працює трьома мовами від самого продакшен-релізу — не як переклад, доданий постфактум, а як проєктне припущення, що вплинуло на структуру контенту, формати дат і найменування полів.
Стек і архітектурні рішення мовою бізнесу
Технології ми описуємо через призму того, яку бізнес-проблему вони вирішують. Це та оптика, яку варто застосовувати в будь-якій розмові про систему: назва фреймворку нікого не цікавить, доки незрозуміло, що з неї випливає.
Laravel та Inertia: одне середовище замість двох команд
Класична архітектура з окремим бекендом і окремим фронтендом означає два репозиторії, два набори компетенцій і постійну роботу над підтримкою API-контракту між ними. У продукті, який будується під жорсткий регуляторний дедлайн, це витрати, яких ми не хотіли нести.
Laravel з Inertia дає застосунок, у якому бізнес-логіка живе в одному місці, а інтерфейсний шар лишається сучасним і реактивним без побудови окремого API для власного вжитку. Бізнес-ефект: коротший шлях від продуктового рішення до робочої функції та менша команда для супроводу.
Черги: асинхронність як вимога, а не оптимізація
Це рішення найчастіше пропускають команди, які будують першу інтеграцію з державною системою. Надсилання фактури до KSeF не є миттєвою операцією — документ потрапляє в обробку, а відповідь надходить із затримкою. Якщо користувач чекає на це, дивлячись на спінер, продуктом неможливо користуватися.
У Biurko.io кожна операція із зовнішньою системою проходить через чергу. Це дає три конкретні переваги:
Стійкість до недоступності API — якщо система на іншому боці не відповідає, задача чекає та повторює спробу замість того, щоб віддавати помилку користувачеві.
Передбачувана продуктивність при масових відправленнях — бюро, яке надсилає пʼятсот фактур першого числа місяця, не кладе застосунок.
Повний контроль над повторами — а у фіскальній інтеграції це різниця між документом, надісланим один раз, і надісланим двічі.
WebSockets і Reverb: статус у реальному часі
Оскільки операції асинхронні, користувачеві потрібно бачити, що відбувається, без перезавантаження сторінки. Reverb — WebSocket-сервер в екосистемі Laravel — дозволяє надсилати в браузер інформацію про зміну статусу тієї миті, коли ця зміна справді відбувається.
Звучить як деталь UX. Насправді це функція, яка будує довіру до системи. Бухгалтерка, яка бачить наживо, що документ пройшов валідацію й отримав номер, перестає перевіряти його вручну на державному порталі. Це реально зекономлений час, помножений на кожен документ.
Три середовища згідно з адресацією Міністерства
Міністерство фінансів підтримує три повністю відокремлені середовища — тестове, демонстраційне та продакшен. Кожне має власні адреси, власні дані й власне призначення, а фактура, надіслана в одне з них, не видима в інших. Тестові середовища призначені виключно для перевірки інтеграції, і надсилати туди реальні дані субʼєктів заборонено.
Ми побудували відповідну структуру на своєму боці: окремі test, demo і production, кожне налаштоване під правильну адресацію. Це дозволяє тестувати зміни на синтетичних даних, перевіряти сценарії в передпродакшен-середовищі з реальними правами, і лише потім викочувати код у продакшен. В інтеграції з податковими наслідками місця для скорочень немає.
Чого нас навчила робота з державним API
Кілька спостережень, які переносяться на будь-який інтеграційний проєкт із державним сектором.
Документація — рухома ціль. Специфікація API змінювалася під час робіт. Архітектура, що ізолює комунікаційний шар від бізнес-логіки, перестає бути академічним побажанням і стає умовою дотримання дедлайну.
Тестове середовище — не продакшен. Поведінка, зафіксована в тестах, не завжди переноситься один в один. Етап на demo, з реальними правами й без юридичних наслідків, врятував нас від кількох сюрпризів.
Обробка помилок — половина проєкту. Сценарій «усе пройшло добре» зайняв частку часу. Решта — аварійні гілки: відхилення документа, таймаут, завершення сесії, недоступність системи. У фіскальних інтеграціях саме вони визначають якість продукту.
Регуляторний дедлайн не обговорюється. Це змінює підхід до управління обсягом. Пріоритет — перелік функцій, без яких продукт не може стартувати; усе інше є кандидатом на наступну ітерацію.
Результат
Проєкт завершився робочим продакшен-релізом Biurko.io — платформою, яка покриває повний шлях документа від виставлення до архіву, не виходячи за межі одного інтерфейсу.
З боку користувача
Людина, відповідальна за фактурування, працює в одній панелі незалежно від кількості субʼєктів. Перемикання контексту компанії не вимагає повторного входу. Статуси відправлень оновлюються наживо, а документи, відхилені централізованою системою, потрапляють у чітко виділену чергу з описом причини — замість зникати в логах.
З боку організації
Платформа покриває сценарії, які у звичайній програмі для фактурування залишилися б ручною роботою: масове надсилання, повтор невдалих спроб, коригування, повʼязані з первинним номером KSeF, та імпорт вхідних фактур. Кожен із цих пунктів — години, повернені в масштабі місяця. А оскільки обовʼязок стосується кожної окремої B2B-транзакції, економія масштабується з кількістю документів, а не з кількістю користувачів.
З боку супроводу
Розділення середовищ і асинхронна архітектура означають, що оновлення, спричинені змінами на боці Міністерства, викочуються передбачувано: спершу test, потім demo, потім production. Звучить буденно, але для системи з податковими наслідками це єдина прийнятна модель роботи — і водночас та, від якої найчастіше відмовляються команди, що будують першу інтеграцію.
Висновки для компаній, які планують власну систему
Biurko.io — наш продукт, але патерни, що стоять за ним, універсальні й однаково працюють у проєктах CRM, ERP та автоматизації процесів.
Починайте з того, що не зміниться. Тут константою був законодавчий обовʼязок і його графік. У вашій системі такою константою буде ключовий бізнес-процес. Навколо нього й будуйте архітектуру — решта є конфігурацією.
Вважайте асинхронність проєктним припущенням. Будь-яка система, що спілкується із зовнішнім світом — банком, курʼєрською службою, маркетплейсом, державним API, — має виходити з того, що інший бік буде повільним або недоступним. Дописати це пізніше означає перебудову.
Мультикомпанійність і багатомовність вирішуйте на старті. Це дві речі, які практично неможливо додати дешево постфактум.
Інвестуйте в середовища. Окремі test, demo і production — витрата, яка окупається на першому ж уникненому інциденті з реальними даними клієнта.
Підсумок
KSeF змусив польський ринок зробити те, до чого багато компаній не були готові: перейти від документів, які «якось циркулюють», до процесу, що має бути герметичним, відтворюваним і стійким до збоїв. Biurko.io постав як відповідь на цей виклик — від першого аналізу до продакшен-версії, узгодженої з адресацією середовищ Міністерства фінансів.
Найважливіший висновок із проєкту, однак, не технічний. Він звучить так: система, яка обслуговує критичний процес у вашій компанії, має бути спроєктована під цей процес, а не навпаки. Підлаштування організації під обмеження готового інструмента — це витрата, якої не видно в прайсі ліцензій. Вона стає видимою в кількості годин, які команда витрачає на обхід системи.
Якщо ви хочете створити систему, узгоджену з процесами вашої компанії, — звʼяжіться з нами. Наша команда допоможе перекласти бізнес-цілі мовою конкретних ІТ-рішень: від аналізу та вибору між готовим продуктом і власним до впровадження й подальшого супроводу. Перша консультація безкоштовна.
