KSeF integration: how to connect your system to Poland's e-invoicing hub
Integrating with KSeF means authentication, sessions, sending FA_VAT and retrieving the UPO. Here's the shape of a KSeF integration and the decisions to make before you build.
KSeF integration: how to connect your system to Poland's e-invoicing hub
Connecting your invoicing to KSeF is an API integration with a specific shape: authenticate, open a session, submit FA_VAT invoices, and collect the confirmation. Here's what an integration involves and the choices to get right first.
Environments
KSeF exposes separate environments — a test and a demo environment that behave like production without legal effect, and production. Build and validate against test/demo before touching production. Never trial with real invoices.
Authentication
You authenticate as the taxpayer (or their authorised software) using one of:
- a qualified electronic signature or qualified seal,
- a trusted profile (Profil Zaufany), or
- an authorisation token generated inside KSeF for automated/software access.
For system-to-system automation, the token flow is the usual choice. Manage permissions carefully — who/what may issue invoices on the company's behalf.
Sessions: interactive vs batch
KSeF works in sessions:
- Interactive — open a session, send invoices one by one, receive each
result, then close.
- Batch — package many invoices and submit them together (useful for volume).
Your integration picks the mode based on how you invoice.
The core loop
□ Authenticate → obtain a session token
□ Build a valid FA_VAT XML invoice
□ Submit it in the session
□ Receive the KSeF number (invoice is now "issued")
□ Collect the UPO (proof of receipt)
□ Store the KSeF number + UPO against your invoice record
□ Handle errors/rejections and retry safely (idempotency)
What to store on your side
- The KSeF number and UPO for every issued invoice.
- The exact FA_VAT submitted (for audit).
- Status transitions and any rejection reasons.
Decisions before you build
- Direct vs provider. Integrate against the KSeF API yourself, or go through
a provider/software that already speaks KSeF. Direct gives control; a provider gives speed and maintenance cover as the schema evolves (FA(2) → FA(3)).
- Signature/token strategy — how software authenticates without a human each
time.
- Retry + idempotency — never double-issue on a network hiccup.
- Schema versioning — KSeF evolves; plan for format updates.
Don't forget the EU side
KSeF is domestic. If you also invoice across the EU, you still need Peppol/EN 16931 for cross-border — a separate channel with its own format. Many Polish exporters run both.
Where Eurobillr fits
Eurobillr integrates with Recommand for EU e-invoicing over Peppol (Belgium, France's accredited-platform flow, and more) — the same "authenticate, build a valid structured document, send, confirm" pattern KSeF uses, applied to the cross-border side. KSeF is Poland's national hub; for domestic Polish issuance you'll connect to KSeF directly or via a KSeF provider. If you need both, we're happy to hear where the gaps are.
Next: KSeF API · how to issue a KSeF invoice.