Введение

KSeF (Krajowy System e-Faktur) — это не просто «новый формат электронных счетов». С 2026 года это обязательный контур работы с фактурами в Польше, который меняет процессы, роли и требования к данным.

Большинство проблем появляются не в момент старта, а через несколько месяцев — когда выясняется, что данные неполные, процессы разрознены, а ручные исключения перестают работать.

В этой статье — практическое объяснение, что именно меняется в 2026 году, кто и когда обязан подключиться к KSeF, как работает исключение 10 000 zł и что реально нужно подготовить — без маркетинга и общих слов.

В этой статье

Когда KSeF становится обязательным: ключевые даты

Обязательное использование KSeF вводится поэтапно:

  • с 1 февраля 2026 года — компании, у которых оборот в 2024 году превысил 200 млн zł (с НДС)
  • с 1 апреля 2026 года — все остальные налогоплательщики VAT

На практике это означает: даже если вы «попадаете на апрель», готовиться нужно заранее — потому что вам всё равно придётся принимать и обрабатывать фактуры от контрагентов, которые начнут работать через KSeF раньше.

Исключение 10 000 zł до конца 2026 года — как оно работает на самом деле

До 31 декабря 2026 года допускается выставление счетов вне KSeF (бумажных или обычных электронных), если сумма таких счетов в конкретном месяце не превышает 10 000 zł с НДС.

Важно понимать:

  • лимит считается помесячно, а не за год;
  • как только лимит в месяце превышен — дальнейшее выставление вне KSeF становится проблемой (нужно переключаться на KSeF);
  • исключение касается выставления, но не отменяет необходимость понимать процесс приёма документов.

Практический вывод: даже небольшим компаниям полезно заранее определить доступы, роли и сценарии обработки — иначе послабление превращается в «ручные костыли», которые не масштабируются.

KSeF 2.0: что обычно упускают при планировании

1) Это не только API и интеграция

Вместе с KSeF появляются регламенты: доступы и полномочия, ответственность за ошибки, обработка отказов, корректировки, контроль данных и связка с отчётностью (например, JPK). Часто делают «техническую отправку», но не закрывают вопрос: кто владелец процесса end-to-end.

2) Счета с приложениями — отдельный процесс

Если у вас есть приложения к счетам (спецификации, расчёты, технические файлы), это нужно планировать как отдельный сценарий: сроки, правила, хранение и операционная обработка. Иначе «мелочь» начинает ломать сроки выставления и внутренние SLA.

Практический чек-лист подготовки к KSeF

Процессы и ответственность (финансы / бухгалтерия)

  • Какие типы счетов вы используете на практике (B2B, B2C, корректировки, авансы)?
  • В какой момент счёт считается выставленным юридически?
  • Кто отвечает за доступы, роли, подписи/отправку, обработку отклонённых счетов?
  • Сколько исключений и нестандартных сценариев реально существует (а не «по регламенту»)?

Данные и системы (ERP / IT / интеграции)

  • Насколько полны и согласованы данные: NIP, адреса, условия оплаты, ставки НДС?
  • Из скольких систем фактически формируются счета?
  • Есть ли очередь отправки, повторы, логирование, мониторинг статусов?
  • Как вы будете работать с приложениями (если они есть)?

Типовые ошибки, которые проявляются после запуска

  • «У нас всё в ERP» — но часть счетов оказывается ручной.
  • Нет владельца процесса end-to-end (в итоге ошибки «между отделами»).
  • Корректировки и исключения не протестированы.
  • Фокус только на отправке, а приём и обработка входящих документов оставлены «на потом».

План внедрения 30 / 60 / 90 дней

0–30 дней — увидеть реальную картину

  • Полный список источников счетов
  • Аудит данных и справочников
  • Назначение владельца процесса

31–60 дней — собрать рабочий скелет

  • Базовая интеграция с KSeF
  • Настройка ролей и доступов
  • Тестирование нестандартных сценариев

61–90 дней — стабилизация

  • Процедуры на случай ошибок и отклонений
  • Метрики отказов и задержек
  • Готовность к приложениям и пиковым нагрузкам

Автоматизация вокруг KSeF: бесплатные / open-source варианты

KSeF закрывает юридический контур e-фактур, но не решает операционные задачи: валидацию данных, очереди отправки, retry-логику, мониторинг, интерфейсы для ручной проверки, маршрутизацию по ролям, контроль исключений.

Для этого часто используют low-code / internal tools платформы — чтобы быстро собрать «операционный слой» вокруг KSeF без дорогой кастомной разработки.

Open-source / бесплатные варианты, которые подходят для “операционного слоя”

  • Appsmith (open-source) — внутренние панели, ручная обработка ошибок, контроль статусов.
    Site · GitHub
  • ToolJet (open-source) — быстрые внутренние интерфейсы поверх API/БД, удобно для мониторинга и операций.
    Site · GitHub
  • MyCompany (lsFusion) (open-source) — platform-first подход: бизнес-логика описывается декларативно, удобно, когда процессы меняются и важна управляемость изменений.
    Site · GitHub
  • Budibase (community/open-source) — админ-интерфейсы, внутренние приложения, простые workflow.
    Site · GitHub
  • NocoBase (open-source) — расширяемая low-code платформа с плагинами, CRUD-приложения + процессы.
    Site · GitHub

Эти инструменты не «заменяют KSeF», но помогают сделать процесс устойчивым: меньше ручных исключений, больше прозрачности, быстрее реакции на ошибки и изменения в требованиях.

Вывод

KSeF — это операционный проект, а не «формат XML». Лучше всего проходят переход те, кто заранее: наводит порядок в данных, фиксирует ответственность и строит управляемый процесс обработки фактур end-to-end.

Почему автоматизация реально нужна (даже если у вас “небольшой объём”)

  • Чтобы не утонуть в исключениях. Первые недели обычно проходят спокойно, а затем начинают всплывать «нестандартные» кейсы: корректировки, авансы, разные источники данных, счета с приложениями, ручные счета, возвраты, расхождения по ставкам НДС. Без операционного слоя это быстро превращается в чат + Excel + “позвони бухгалтеру”.
  • Чтобы видеть статусы, а не гадать. Нужно понимать, что отправлено, что принято, что отклонено, где зависло, кто должен реагировать, и сколько времени это занимает. Мониторинг + очередь + алерты обычно дают больше пользы, чем “ещё одна интеграция”.
  • Чтобы снизить риск просрочек и штрафных последствий. Ошибки чаще возникают не из-за API, а из-за данных и процесса: неправильный контрагент, неполный адрес, неконсистентные справочники, дубль документа. Автопроверки до отправки и предсказуемый разбор ошибок сильно уменьшают операционный риск.
  • Чтобы масштабироваться без найма “ещё двух людей на ручной контроль”. Как только появится рост, новый филиал, новый ERP-модуль или новый тип документов — ручная схема ломается первой. Автоматизация — это про устойчивость и управляемость изменений.

Официальные источники

Читайте дальше:

Больше практических заметок о KSeF и операционной автоматизации.