ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

Poland — KSeF and the FA(2) invoice

Poland has chosen a full clearance model: every B2B invoice flows through the Krajowy System e-Faktur (KSeF), operated by the Ministry of Finance, which assigns a KSeF number (UPO) acting as legal timestamp.

Regulatory timeline

  • Law of 9 November 2018. Introduces in the VAT law the notion of faktura ustrukturyzowana (structured invoice) and kicks off the work on KSeF.
  • 18 April 2019. Go-live of the PEF platform for B2G under EU Directive 2014/55.
  • 1 January 2022. KSeF launches in voluntary B2B mode. Initial FA(1) schema.
  • Law of 16 June 2023 (Dz.U. 2023 poz. 1598). Establishes the B2B obligation, with go-live initially scheduled for 1 July 2024.
  • Ministry of Finance announcement of 19 January 2024. Deferral to 2025 then 2026 following a technical audit (the KSeF stress test incident at the end of 2023).
  • Law of 9 May 2024. Sets the final timeline: 1 February 2026 for large taxpayers, 1 April 2026 for the rest.
  • Regulation of 29 June 2023. Publication of the FA(2) schema — variant 2 of the FA form, structured for KSeF.

Deep dives — 10 dedicated pages

Ten dedicated pages drill into every dimension of the Polish KSeF mandate — the 2026 clearance reform, technical specs (API, FA(2), UUID, e-Doręczenia), and real-world B2B usage that pre-dates and survives the reform.

2026 reform

  • Mandatory KSeF 2026 · Krajowy System e-Faktur, pure clearance, mandatory 1 Feb 2026 (large taxpayers > 200M PLN), 1 Apr 2026 universal. Legal basis art. 106nf-106nm.
  • FA(2) — e-faktura ustrukturyzowana · Official Polish XML schema, UN/CEFACT CII + EN 16931, sectoral extensions (mediation, transport, energy), schemas on biznes.gov.pl.
  • JPK_FA and JPK_VAT — Polish SAF-T · Polish SAF-T standard since 2018, JPK_V7M monthly mandatory, JPK_FA migrating to KSeF. 7 active structures (FA, VAT, KR, MAG, WB, EWP, PKPiR).
  • KSeF calendar 2022-2027 · 1 Jan 2022 voluntary, 1 Feb 2026 large taxpayers, 1 Apr 2026 universal, 1 Jul 2026 cash registers, 2027 parliamentary review.

Technical specs

  • KSeF API specifications · REST on ksef.mf.gov.pl, OAuth 2.0 hierarchy AuthorizationToken / SessionToken / AccessToken, batch limits 50 inv/packet, 21xxx error codes.
  • Numer KSeF — legal UUID · 36-character identifier assigned after clearance, legally replaces issuer sequence. Format NIP-DATE-UUID-CHK. Accounting propagation.
  • e-Doręczenia — registered delivery · Mc Cyfryzacji / Poczta Polska platform, e-IDAS QERDS, mandatory for businesses 1 Jan 2025, ADE bound to NIP, KSeF notification integration.

Real-world B2B usage

  • Polish retail EDIFACT · Biedronka, Lidl, Kaufland, Auchan, Carrefour, Żabka, Dino — EANCOM 2002 S4/S5 subsets, GS1 Polska, ~1.2 billion messages/year.
  • Polish automotive EDIFACT · Volkswagen Poznań, Stellantis Tychy + Gliwice, FCA Bielsko-Biała, MAN Niepołomice, Toyota Wałbrzych — VDA + Galia + Odette standards, OFTP2 over ENX.
  • Polish VAT regimes · Rates 23/8/5/0/zw/np, ryczałt, zwolnienie podmiotowe (< 200K PLN), reverse charge art. 17, split payment appendix 15.

Technical schema

The format is FA(2), a Polish proprietary XML published by the Ministry of Finance on the crd.gov.pl portal. It differs structurally from PEPPOL BIS and FatturaPA — no EN 16931 alignment. The root is tns:Faktura in the http://crd.gov.pl/wzor/2023/06/29/12648/ namespace. Main sections: Naglowek (header), Podmiot1 (seller), Podmiot2 (buyer), Podmiot3 (optional third party), and Fa (invoice body, dates, lines). Minimal FA(2) example:

xmlksef-fa2.xml
<?xml version="1.0" encoding="UTF-8"?>
<tns:Faktura xmlns:tns="http://crd.gov.pl/wzor/2023/06/29/12648/"
             xmlns:etd="http://crd.gov.pl/xml/schematy/dziedzinowe/mf/2022/01/05/eD/DefinicjeTypy/">
  <tns:Naglowek>
    <tns:KodFormularza kodSystemowy="FA (2)" wersjaSchemy="1-0E">FA</tns:KodFormularza>
    <tns:WariantFormularza>2</tns:WariantFormularza>
    <tns:DataWytworzeniaFa>2026-04-01T10:15:00</tns:DataWytworzeniaFa>
    <tns:SystemInfo>ediverse-demo</tns:SystemInfo>
  </tns:Naglowek>
  <tns:Podmiot1>
    <tns:DaneIdentyfikacyjne>
      <etd:NIP>5260250995</etd:NIP>
      <tns:Nazwa>Warsztat Warszawa Sp. z o.o.</tns:Nazwa>
    </tns:DaneIdentyfikacyjne>
    <tns:Adres>
      <etd:KodKraju>PL</etd:KodKraju>
      <etd:AdresL1>ul. Marszalkowska 102</etd:AdresL1>
      <etd:AdresL2>00-026 Warszawa</etd:AdresL2>
    </tns:Adres>
  </tns:Podmiot1>
  <tns:Podmiot2>
    <tns:DaneIdentyfikacyjne>
      <etd:NIP>7011089487</etd:NIP>
      <tns:Nazwa>Spoldzielnia Krakowska</tns:Nazwa>
    </tns:DaneIdentyfikacyjne>
  </tns:Podmiot2>
  <tns:Fa>
    <tns:KodWaluty>PLN</tns:KodWaluty>
    <tns:P_1>2026-04-01</tns:P_1>
    <tns:P_2>FA/04/2026/00187</tns:P_2>
    <tns:RodzajFaktury>VAT</tns:RodzajFaktury>
  </tns:Fa>
</tns:Faktura>

KSeF requires strong authentication: Polish qualified electronic signature (kwalifikowany podpis elektroniczny), advanced ZUS signature, ePUAP, or an authorisation token issued by KSeF. The legal timestamp is the numer KSeF returned upon submission — that is what the tax authority recognises, not the issue date carried by the seller.

Submission flow

The model is pure clearance: the seller publishes the invoice on KSeF (interactive REST API or batch), KSeF validates structure and rules, assigns a numer KSeF with UPO (Urzędowe Poświadczenie Odbioru), and the invoice becomes accessible to the buyer in its KSeF workspace.

textksef-flow.txt
┌────────────┐    ┌──────────────┐    ┌────────────┐
│ PL Seller  │───>│    KSeF      │───>│ PL Buyer   │
│ (ERP)      │    │ (Ministry of │    │ (ERP)      │
└────────────┘    │  Finance)    │    └────────────┘
                  └──────┬───────┘
                         │
                         ▼
                ┌─────────────────┐
                │ KSeF number      │  ← assigned within
                │ (UPO)            │     24h, timestamped
                └─────────────────┘

The buyer is not actively notified: they pull from their KSeF workspace. For cross-border flows, KSeF does not apply: operations with foreign partners follow traditional invoicing (structured or not, EN 16931 via PEPPOL for the EU).

Validation

  • KSeF Demo environment: ksef-demo.mf.gov.pl — Ministry of Finance sandbox to test the API and signing.
  • KSeF documentation: podatki.gov.pl/ksef — official reference for FA(2) schemas, business rules and error codes.
  • FA(2) XSD downloadable from crd.gov.pl/wzor/2023/06/29/12648/.
  • PEPPOL validator: /en/tools/peppol-validator/ — for outbound cross-border flows running in parallel.

Common pitfalls

  1. 24-hour push for the KSeF number. UPO assignment can take up to 24 hours when the system is backed up. Any architecture that assumes a synchronous return within seconds is at risk of triggering double submissions. The official SDK recommends async polling with backoff.
  2. Strict multi-factor authentication. The KSeF token is tied to a ZUS certificate, an ePUAP, or a qualified certificate: rotating the certificate without reissuing the token breaks the entire chain. Plan an automated renewal process.
  3. No native PEPPOL interoperability. KSeF neither issues nor accepts PEPPOL UBL invoices. For inbound or outbound cross-border traffic, you must run a second channel in parallel (PEPPOL or bilateral EDI). Private gateways that claim interop are dual-entry converters under the hood.
  4. Issue date vs KSeF assignment date. The seller can populate an issue date (P_1) earlier than the KSeF submission date, but only the UPO date is enforceable for tax purposes. This decoupling surprises teams used to a single ERP timestamp.
  5. Passive buyer notification. KSeF does not push invoices to the buyer: the buyer must poll their KSeF workspace. Architectures that don't industrialise the buyer-side collection accrue accounting delays.