XML and the FA(3) schema in KSeF - a guide for businesses

Summary

XML is a structured data format, not an image or a PDF. KSeF requires it because machines can read and validate it automatically.

FA(2) was the previous version of the invoice schema. From 2026, FA(3) is mandatory. If your system still uses FA(2), invoices will be rejected.

An invalid XML file means a rejected invoice - and a rejected invoice does not legally exist. Validation before submission is a necessity, not an option.

Table of Contents

1. What is XML - and why KSeF requires it

2. The FA(2) schema - what the name means and where it comes from

3. Invoice structure in FA(2) - key XML elements

4. FA(2) vs FA(3) - what changed and what is now required

5. Why XML and the FA schema matter for KSeF integration

Key Findings

The table below summarises the most important conclusions from this article - one sentence per section.

What is XML - and why KSeF requires it

XML (eXtensible Markup Language) is a text-based format for storing data in a way that is readable by both humans and machines. It is not a programming language or software - it is a method of organising information using tags. Each piece of data is described by an opening and closing tag pair; a counterparty name, an invoice amount or a NIP tax number are all stored in clearly labelled fields.

The best analogy is an official form. A free-form letter may contain the same information as a completed form, but a clerk may struggle to extract the answer to a specific question. A form - with dedicated fields - gives the answer immediately. XML works in exactly the same way: instead of free text you have precisely labelled fields that a system can read automatically.

PDF works completely differently. A PDF file is essentially a visual description of a document - it tells the printer and screen where to draw text, how many pixels it should be and how it should look. A person sees an invoice. A system sees an image. There is no data that a computer can process without additional text recognition (OCR). That is precisely why KSeF does not accept PDFs as valid invoices.

The Ministry of Finance chose XML for several reasons. First, XML is machine-readable: the system can verify whether a NIP has 10 digits, whether amounts balance and whether all required fields are completed - without human involvement. Second, XML is validatable: a document can be checked against a template (an XSD schema) before submission. Third, XML is interoperable: every ERP system, application and server can read it in the same way, regardless of the software vendor.

To summarise the distinction every business owner should remember: PDF is for eyes, XML is for systems. KSeF is a system, not a person - hence the XML requirement.

The FA(2) schema - what the name means and where it comes from

An XSD schema is a template describing what a valid XML document should look like. Think of it as a recipe: the recipe specifies which ingredients to use, in what order and in what proportions. An XSD schema tells an XML document which elements must be present, which data types are permitted (for example, a date must follow the YYYY-MM-DD format) and which relationships must hold between fields. An XML invoice that does not conform to the schema is like a dish prepared without following the recipe - the result may be inedible.

The abbreviation FA comes from the Polish word for invoice. FA(1), FA(2) and FA(3) are successive versions of the XSD schema for structured invoices in KSeF, published by the Ministry of Finance. FA(1) was used during the system's pilot phase. FA(2) applied during the voluntary KSeF period - companies could, but were not required to, issue invoices through the system. FA(3) is the mandatory schema, introduced with the phased rollout of compulsory KSeF.

Why is it worth knowing what FA(2) is if it is no longer in force? Documentation for ERP systems, trade articles, guides and internal procedures of many companies were created on the basis of FA(2). If you encounter examples of fields, descriptions of XML nodes or system configuration instructions that reference FA(2), you need to know you are dealing with an outdated version. The consequences can be serious: an invoice submitted in FA(2) format to KSeF in 2026 will be rejected.

Key date: from 1 February 2026, the only schema accepted by KSeF is FA(3). This applies to large companies (gross sales above PLN 200 million in 2024). From 1 April 2026, the obligation extends to all other VAT taxpayers. FA(2) is no longer accepted by the system - and every invoice submitted in that format will be automatically rejected, without exception.

Invoice structure in FA(2) - key XML elements

To understand FA(3) and potential migration issues from FA(2), it is worth familiarising yourself with the basic structure of an XML invoice in KSeF. The document is divided into several main nodes, each responsible for a specific part of the invoice data. Nodes are simply sections of the document - like chapters in a contract.

Podmiot1 is the section describing the seller - the invoice issuer. It contains company identification data: NIP, name and address. This field is mandatory and must exactly match the data registered in tax records. Podmiot2 is the corresponding section for the buyer. It also contains NIP, name and address. For transactions with a private individual not running a business, the field is optional or completed in a specific way.

The Fa node is the invoice header - its metadata. Here you will find: invoice number (P_2), issue date (P_1), sale date (P_6), document type (P_15), currency (KodWaluty), payment terms (TerminPlatnosci) and other key attributes. FaWiersz is a line item - one row corresponds to one product or service. It contains a description of the goods or service, quantity, unit of measure, net unit price, VAT rate and values. An invoice may have multiple such rows. Podsumowanie is the node that aggregates VAT totals by rate - total net amount, VAT and gross amount.

Which fields most commonly cause validation errors? Implementation experience shows that problems concentrate in several areas. NIP must have exactly 10 digits and pass a check-digit verification - the PL prefix and spaces are not permitted in a field intended exclusively for digits. Dates must be in ISO 8601 format (YYYY-MM-DD) - the notation 15.04.2026 will be rejected. VAT rate codes must conform to the Ministry of Finance dictionary, not arbitrary descriptions. Amounts must be rounded according to the KSeF algorithm - even a one-penny discrepancy causes rejection.

FA(2) vs FA(3) - what changed and what is now required

The transition from FA(2) to FA(3) is not merely a version number update - it is a change in requirements that directly affects how an ERP system or invoicing application must construct an XML document. If your software provider has not updated the integration to FA(3), invoices will be rejected by KSeF without any warning that would be meaningful to the end user.

What does FA(3) introduce? Most significantly, the possibilities for describing payment terms have been expanded - FA(3) allows multiple payment deadlines to be specified precisely for a single invoice, which is important for instalment invoices. It is now possible to attach attachments directly to the XML invoice - this was not possible previously. The bank account number field has been extended to support the IBAN standard. New special procedure codes have been added, including for transactions between related parties (TP), the split payment mechanism (MPP) and sales through digital platforms (IED). GTU codes - identifiers for types of goods and services relevant to JPK reporting and VAT returns - have been expanded.

How do you check whether your system is operating on FA(3)? Below is a list of questions to ask your ERP or accounting software provider:

When did you last update the KSeF module in your system? Does the update include the FA(3) schema published by the Ministry of Finance? Does the system test invoices against the KSeF demo environment before submission? Which XSD schema version does your XML export generate? Does the system support the new FA(3) fields: multiple payment terms, IBAN, TP and MPP codes? What happens when an invoice is rejected by KSeF?

Why XML and the FA schema matter for KSeF integration

In the KSeF system, an invoice either passes validation and is accepted, or it is rejected. There is no intermediate state. A rejected invoice does not legally exist under tax law - it is not considered issued, cannot serve as the basis for a buyer's VAT deduction and is not stored in the Ministry of Finance system. It must be corrected and resubmitted.

The validation process in KSeF operates on three levels. The first is XSD structure validation: the system checks whether the XML is structurally correct - whether elements are in the right order, whether data types match and whether required fields are present. If the file fails this stage, it does not proceed to further checks. The second is business validation: the system checks logical rules - whether the sale date is not later than the issue date, whether the VAT total is mathematically correct and whether tax identifiers have the correct format. The third is duplicate checking: KSeF verifies whether an invoice with the same number, seller NIP and document type has already been registered in the system (the check covers 10 years back).

How do you avoid invoice rejection? The most effective method is local validation - checking the XML before submitting to KSeF, using tools available outside the production system. This way, errors are detected at the document preparation stage, not only after a submission attempt.

KSeFGPT enables import and verification of XML invoices directly from KSeF. The platform allows you to check document structure, identify errors and manage invoices without manually working with the Ministry of Finance API. It is a practical tool both for businesses issuing large volumes of invoices and for accounting firms serving multiple clients.

Perspective: why understanding XML matters even without technical knowledge

A business owner does not need to write XML code or memorise the XSD schema specification. But it is worth understanding what XML is and why it exists - if only because that knowledge protects against blind trust in software. If you know that a structured invoice is a data file, not a visual document, you also know that simply generating a PDF in your accounting software is not equivalent to issuing an invoice in KSeF. This distinction costs real money and time if discovered too late.

The most common organisational mistake encountered by companies implementing KSeF is a split in responsibility: the IT department handles technical integration while accounting is responsible for the substantive accuracy of invoices - and these two worlds do not communicate during the configuration phase. The predictable result is an XML file that is technically valid against the XSD schema but contains incorrect VAT rates, wrong GTU codes or missing procedure markings. Such invoices pass structural validation but cause problems in tax accounting.

Tools are increasingly effective at abstracting XML away from the end user. A good invoicing programme or integrated ERP system allows you to issue a correct KSeF invoice without manually handling the XML file. But this convenience has a cost: if the system generates incorrect data and the user does not understand how the document is structured, the error may go unnoticed for a long time. A basic understanding of XML structure gives you the ability to ask your software provider the right questions: are you generating FA(3) or FA(2)? Where are GTU codes stored in the XML? Is validation triggered before or after submission?

A practical recommendation: before launching production invoice submission through KSeF, test the full cycle on the Ministry of Finance demo environment. Issuing an invoice, checking the validation status, receiving the KSeF number and UPO, and then verifying that the data in the system matches what you expected to send - this is the absolute minimum before going live. The test environment is available free of charge and has no impact on actual tax returns. Every hour spent on testing is an hour less spent fighting fires in production.

Verify your XML invoices before submitting to KSeF

KSeFGPT is a KSeF invoice management platform that enables import, verification and processing of XML documents directly from the Ministry of Finance system. Whether you are a business issuing several dozen invoices per month or an accounting firm serving hundreds of clients, the platform reduces manual API work and minimises rejections.

Frequently asked questions

Is FA(2) still accepted by KSeF? - No. From 1 February 2026 (large companies) and from 1 April 2026 (all other VAT taxpayers), the only accepted schema for structured invoices is FA(3). An invoice submitted in FA(2) format will be automatically rejected by the KSeF system without receiving a KSeF number.

How do I check whether my XML file conforms to FA(3)? - The most effective method is local validation against the XSD schema published by the Ministry of Finance. You can use an XSD validator available online or in XML editing tools. The Ministry of Finance also provides a KSeF test environment (ksef-test.mf.gov.pl) where you can submit a test document and verify whether it passes validation without affecting actual tax returns.

How does a KSeF XML file differ from a standard XML file? - Every KSeF XML file must conform to the specific XSD schema published by the Ministry of Finance - currently FA(3). It is not sufficient for the file to be technically valid XML. It must contain exactly the nodes, in exactly the order and with exactly the data types defined in the FA(3) schema. In addition, the file must satisfy KSeF business rules - for example, VAT totals must be mathematically consistent with the line items.

What does invoice rejection by KSeF mean - do I need to reissue it? - Yes. A rejected invoice is not registered in the KSeF system, which means that under tax law it has not been issued. You must correct the XML file (removing the error indicated by the system) and then resubmit the invoice. The invoice number remains the same - you are not creating a new document, but correcting and resubmitting the same one. The exception is if the same invoice number has already been successfully registered - in that case KSeF will reject the document as a duplicate.

Recommended articles

Read also: XML validation and processing in KSeF - how the KSeF system verifies a document before assigning a KSeF number. PDF to KSeF XML converter - how to convert a PDF invoice into a valid FA(3) file ready for submission. Most common challenges when implementing KSeF - errors, edge cases and contingency procedures not described in any legislation. Can a PDF be sent to KSeF? - a short and direct answer to one of the most frequently asked questions about KSeF.