KSeF Frequently Asked Questions

The National e-Invoice System (KSeF, Krajowy System e-Faktur) is Poland’s central platform for issuing, receiving, and storing structured electronic invoices (in practice XML under the Ministry of Finance schema, currently in the FA(3) line). After acceptance, the system assigns a unique identifier, which matters for proving issuance and receipt.

The reform stems from VAT Act amendments and EU VAT modernisation (e.g. “VAT in the Digital Age”). Technical and organisational rules are published by the Ministry of Finance and the National Tax Administration (KAS).

Mandatory use is phased (large taxpayers, other businesses, micro-enterprises). Always confirm the legal situation and MF/KAS communications on the date relevant to your case.

The schedule is staged under the Act (e.g. revenue thresholds). In practice: the first stage covers the largest taxpayers, then most other businesses, with a later date for micro-businesses. Always verify thresholds and dates in the current Act and on MF/KAS pages.

Before the obligation applies to a given group, legacy invoicing may still run in parallel until the legal cut-off for that group — relevant for IT rollout and training.

A grace period without penalties for incorrect use in 2026 was signalled in legislative materials — still confirm in current law and official notices.

In B2B, a sales VAT invoice is sent to KSeF first; the buyer retrieves it from the system instead of relying only on e-mail PDFs. You need receipt processes (portal, API, or middleware) and user permissions.

Invoices processed through KSeF receive an identifier and acceptance metadata, affecting evidence of date and content.

For accounting, structured data grows in importance: ERP import, NIP consistency checks, XML validation, and linkage to JPK_V7 reporting — a separate compliance area.

Once mandatory for a given scope of B2B transactions, the structured e-invoice in KSeF becomes the primary document. Paper or PDF may serve as a human-readable copy but do not replace registration where the obligation applies.

Exceptions (cross-border, B2C, receipts, etc.) need case-by-case review of current law.

Key acts include VAT Act amendments (Journal of Laws 2023 and 2024) and the Council implementing decision authorising Poland’s special e-invoicing arrangements.

Links below point to official sources — always use the consolidated text and MF guidance.

The system acts as a registry; statutory retention (often discussed around a 10-year horizon for central storage) reduces duplicate archiving for taxpayers for invoices covered by KSeF — exact scope follows detailed rules.

Regardless of KSeF, maintain your own backup and audit policy for accounting systems.

Options include the free taxpayer app from the Ministry of Finance (with strong authentication, e.g. ePUAP depending on service design) and commercial or ERP software integrated with the KSeF API.

Data must be submitted as XML matching the current schema. Validate counterparty NIPs and required fields before sending — errors result in rejection.

A proforma is not a VAT invoice under the VAT Act, so it is not registered in KSeF. After the deal, issue the VAT invoice in KSeF; you may reference the proforma number in additional fields.

Common cases include VAT invoices, corrective invoices linked to KSeF documents, and many domestic B2B scenarios. Excluded or special regimes (some B2C, specific procedures) require tax analysis.

KSeF uses structured XML that the system validates and stores. PDF is usually a visualisation; it does not replace KSeF registration where mandatory.

Corrections run through corrective invoices in KSeF, linked to the original KSeF number. Legacy “correcting notes” are not the target integration pattern.

You need an active account / permissions. Use the taxpayer application (manual review and file export) or automate via API-enabled software.

The system is not designed to e-mail you every new invoice — plan polling or integration.

Yes, if the KSeF administrator grants appropriate authorisations to the accounting office. Scope (issue, receive, admin) follows MF procedures.

The model focuses on structured data. Binary attachments like typical e-mail enclosures are not standard; extra information may go in descriptive fields or parallel processes per MF rules and the XML specification.

There is no buyer-side rejection that cancels a supplier document. Errors are resolved with the issuer via a corrective invoice in KSeF. For legal doubt, consult a tax advisor.

Besides statutory fields (parties, dates, lines, VAT rates, payment), you get the KSeF identifier and acceptance metadata — useful for cross-checks with JPK.

KSeF covers invoice flow; JPK_V7 is monthly VAT declaration and records reporting. They are separate processes, though structured invoice data can feed JPK preparation.

Registering invoices in KSeF is intended to reduce certain on-demand FA file obligations — final scope follows current law.

KSeF is not for bulk import of legacy invoices issued outside the system. Keep historical archives under general document retention rules.

Use the official KSeF portal, authenticate (e.g. trusted profile, qualified signature — per current MF instructions), then configure the entity and user permissions.

The MF-side technical administrator assigns roles electronically where the law and MF instructions allow, often without a paper power of attorney for each employee.

Entities registered for VAT in Poland and issuing certain domestic invoices are generally subject to the same direction as residents — access rules are set by the MF.

Legislation links payments to the KSeF invoice identifier (including a long reference in transfer messages) to aid automatic matching. Effective dates per taxpayer group must be checked in the current Act.

Split payment and KSeF are related compliance areas; payment description may depend on KSeF registration and transaction type. Confirm with MF guidance and your bank.