KSeF in 2026/2027: How to Open and Read an FA(3) Invoice XML — No Software, Nothing Uploaded

In Poland, an invoice is no longer a document you send — it’s a record the state’s system accepts. Since 1 April 2026 every VAT-registered business issues invoices through KSeF as FA(3) XML, the XML is the legally binding invoice, and from 1 January 2027 issuing outside the system carries penalties of up to 100% of the invoice’s VAT. Reading one of these files, though, requires no software at all: the KSeF viewer parses FA(3)/FA(2) XML into a normal, readable invoice — entirely in your browser.

The model: clearance, not correspondence

Most countries’ e-invoicing mandates (Germany’s, France’s) are about format — you must exchange structured files. Poland went further: KSeF is a clearance system. The invoice is submitted to the government platform as XML, validated against the FA(3) schema and business rules, and — only if accepted — assigned a KSeF number, at which moment it legally exists. A rejected submission isn’t a late invoice; it’s no invoice, per the European Commission’s country profile.

The timeline — and why 2027 matters more than 2026

Date	Obligation
1 Feb 2026	Large taxpayers (> PLN 200M turnover) must issue via KSeF; everyone must be able to receive
1 Apr 2026	All VAT-registered businesses must issue via KSeF
1 Jan 2027	Micro-entrepreneurs (small invoice volumes) join; penalty grace period ends

The detail that changes behaviour: 2026 is deliberately penalty-free while the country adapts, per the implementation guides. From January 2027, sanctions become enforceable — up to 100% of the VAT amount for invoices issued outside the system. So KSeF competence isn’t a passed deadline; it’s a rising-stakes requirement.

Inside an FA(3) file

FA(3) is the third revision of Poland’s struktura logiczna — the XML schema every KSeF invoice follows, mandatory since February 2026 (per the Ministry of Finance’s KSeF documentation). The shape is stable and readable once decoded:

Element	What it holds
<Naglowek>	Schema variant (FA(3)), creation timestamp, issuing system
<Podmiot1>	The seller — name, address, NIP
<Podmiot2>	The buyer — same structure
<Fa>	The invoice: P_1 issue date, P_2 number, KodWaluty currency, P_15 total due, P_13_*/P_14_* net/VAT per rate group
<FaWiersz> (repeated)	Line items: P_7 name, P_8B quantity, P_9A unit price, P_11 net value, P_12 VAT rate

The cryptic P_n names come from the VAT regulation’s field numbering — one reason raw FA(3) XML is unreadable to humans and why a viewer that maps them back to “issue date, line items, total due” is the practical bridge. The viewer auto-detects FA(3) vs the older FA(2) and flags the difference.

The NIP check digit — arithmetic before bureaucracy

Every Polish NIP’s tenth digit is a checksum: multiply the first nine digits by the weights 6, 5, 7, 2, 3, 4, 5, 6, 7, sum, take modulo 11 — the result must equal the last digit. A mistyped NIP therefore fails arithmetic before it fails validation, which is exactly the kind of error worth catching on your own machine rather than as a KSeF rejection. The pre-checker runs that checksum on both parties, plus the structural checks (required elements, date and currency formats, line items, totals consistency) — clearly labelled as an unofficial early warning, because only KSeF’s own acceptance has legal effect.

Privacy: why local parsing is the whole point

An FA(3) file names your counterparties, itemizes what you sold them, and often carries a bank account number. Pre-submission invoices are unfiled tax data. Both are precisely what should not be pasted into a random “free online XML viewer” that processes uploads server-side. The LazyTools viewer and pre-checker parse everything with the browser’s own XML engine — they work offline, and nothing you load leaves your device.

Elsewhere in Europe, same story

Poland is the sharpest deadline, not an outlier. Belgium has required structured B2B invoices over the Peppol network since 1 January 2026 (penalties since April) — the Peppol BIS viewer reads those UBL files. Germany (XRechnung, ZUGFeRD) and France (Factur-X, mandate from September 2026) are covered by the e-invoice viewer and Factur-X viewer. One pattern across all of them: the XML is the invoice, and being able to read it locally is the minimum literacy the mandates quietly assume.

Quick summary

KSeF turned Polish invoicing into a clearance process: FA(3) XML in, validation, KSeF number out — and only then does the invoice exist. All VAT-registered businesses have issued this way since April 2026; micro-firms join by January 2027, when penalties (up to 100% of the invoice’s VAT) begin to bite. The XML structure is decodable — parties with checksummed NIPs, P_n fields, FaWiersz lines — and both reading and pre-checking an FA(3) file are browser-local jobs: the KSeF viewer renders it as a normal invoice, and the pre-checker catches the cheap mistakes before the system rejects them, with your data never leaving your machine.

Sources: Ministry of Finance — KSeF FA(3) documentation · European Commission — eInvoicing in Poland · VATupdate — KSeF 2026 deadlines guide · EY — Belgium’s mandatory e-invoicing from 1 January 2026