Як надіслати багато рахунків до KSeF з Excel?

Рахунки не надсилаються до KSeF як Excel-файли. Однак таблиця XLSX, XLS або CSV може бути практичним джерелом даних, з якого такий інструмент, як KSeFGPT, створює рахунки відповідно до структури FA(3), перевіряє їх і дозволяє надіслати до KSeF лише коректні документи.

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

KSeFGPT підтримує масовий імпорт даних із файлів XLSX, XLS і CSV. Після імпорту користувач перевіряє зіставлення колонок, переглядає чернетки рахунків, виправляє помилкові рядки і надсилає лише готові документи. Це безпечніше, ніж вручну переписувати багато рахунків у форму.

Так, але з важливим уточненням: KSeF не приймає Excel-файл як рахунок. KSeF працює зі структурованими рахунками, тобто з даними, що відповідають логічній структурі FA(3). Excel є робочим форматом, який перед відправленням потрібно перетворити на коректні дані рахунка.

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

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

Це розрізнення важливе також для відповідальності платника. Якщо в таблиці є неправильний NIP, хибна дата або сума, яку Excel трактує як текст, проблема не зникає після імпорту. Її потрібно виявити перед відправленням, бажано у звіті перевірки.

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

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

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

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

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

Дати записуйте у форматі РРРР-ММ-ДД, наприклад 2026-05-20. NIP зберігайте як текст із 10 цифрами, без пробілів, дефісів і префікса PL. Суми тримайте як числа з двома десятковими знаками. Валюту записуйте трилітерним кодом, наприклад PLN або EUR.

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

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

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

1. Виберіть компанію, для якої надсилаєте рахунки. Дані продавця, права доступу і подальші статуси мають бути пов'язані з правильним суб'єктом.

2. Завантажте файл XLSX, XLS або CSV з даними рахунків. Якщо файл походить з Excel, перед імпортом перевірте формати дат, NIP і сум.

3. Перевірте виявлені колонки. Зрозумілі назви пришвидшують роботу: `buyer_nip` легко пов'язати з NIP покупця, `issue_date` - з датою виставлення, а `gross_amount` - із брутто-сумою.

4. Перевірте зіставлення колонок із полями рахунка. Для нетипових назв колонок не варто припускати, що все розпізнано ідеально. Особливо перевірте NIP, дати, валюту, ставки ПДВ і суми.

5. Перегляньте чернетки рахунків. На цьому етапі нічого ще не надсилається до KSeF. Ви перевіряєте, скільки документів система розпізнала, які коректні, які мають прогалини і які варто пропустити.

6. Запустіть перевірку і надішліть лише вибрані коректні рахунки. Після відправлення відстежуйте статуси, номер KSeF і UPO для документів, прийнятих системою.

Цей етап є найважливішим операційно. Масове відправлення не полягає в тому, щоб надіслати все якнайшвидше. Йдеться про виявлення проблем у великій таблиці до контакту з KSeF: відсутній NIP, неправильна дата, неузгоджені суми або порожні позиції.

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

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

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

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

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

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

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

XML FA(3) - це формат, якого вимагає KSeF. Він містить дані рахунка в логічній структурі, а не у вигляді таблиці чи візуального документа. Тому імпорт з Excel має завершитися створенням коректних даних рахунка і їх відправленням через інструмент, інтегрований з KSeF.

PDF - це ще інше: візуалізація, скан або документ, отриманий від контрагента. Якщо хочете впорядкувати різницю між PDF і XML, прочитайте Чи можна надіслати PDF до KSeF. Технічні основи структури описані у статті XML і формат FA(3) у KSeF.

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

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

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

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

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

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

Якщо тема відправлення рахунків з Excel стосується вашої команди, варто впорядкувати також ширший процес KSeF:

Масове відправлення рахунків до KSeF - ширший посібник про роботу з пакетами рахунків, перевіркою і статусами.

Відправлення рахунків до KSeF - базовий посібник про відправлення, UPO, автентифікацію і етапи процесу.

XML і формат FA(3) у KSeF - технічні основи структури, до якої зрештою мають потрапити дані з Excel.

KSeFGPT - застосунок для імпорту, експорту та AI-аналітики рахунків - як KSeFGPT допомагає з рахунками, імпортом і аналізом даних.