How to read XML from KSeF

XML from KSeF is a data file, not a document meant to be read like an ordinary PDF. You can open it in a text editor, but without knowing the FA(3) structure it is easy to confuse the invoice number, KSeF number, party data or technical metadata.

The safest order is: confirm where the file came from, check the FA(3) version, read the seller and buyer data, compare line items and amounts, and then run validation. Only after that does a readable PDF visualization help review the invoice with human eyes.

Converting XML to PDF does not replace validation and does not prove that the invoice was accepted by KSeF. The PDF is a preview. The official meaning sits in the FA(3) XML, system status, KSeF number and UPO.

The table below shows what is worth establishing before you treat a KSeF XML file as ready for accounting or onward processing.

A KSeF XML file contains a structured invoice: a document saved according to a defined data schema. In practice, the seller name, tax ID, invoice number, date, line items, VAT rates and amounts are stored in specific elements that accounting software can read.

Such a file does not have to look friendly to a human. You will see tags, angle brackets and technical field names, but for KSeF this structure is the point. The system evaluates data stored in FA(3) XML, not the visual layout of an invoice.

If you want to understand the foundations of the format, start with XML and the FA(3) format in KSeF. This article focuses on practically reading a file you already have on disk or received from accounting software.

First establish where the XML came from. A file downloaded directly from KSeF, an export from accounting software and an email attachment should not be treated in the same way. If you do not know the source, do not run macros, scripts or converters installed from random websites.

A normal text editor is enough for the first look. Do not edit the file if it may be evidence, part of an accounting process or material for diagnosing an error. Save the original unchanged and work on a copy.

If the file will be used for accounting or explaining a discrepancy, also save the context: who provided it, when it was downloaded, whether it has a KSeF number, whether you have UPO and which system produced the export.

Opening the file does not mean the invoice has been checked. In practice, you need to separate four activities: reading the text, visualizing the invoice, validating it and confirming it in KSeF.

This distinction prevents a common mistake: someone sees a readable PDF or a correctly opened `.xml` file and assumes the document is automatically correct. Each level answers a different question.

If the document is going into accounting, do not stop at the first level. Open XML shows data, but only validation combined with the KSeF number, metadata and UPO gives a sensible view of the invoice status.

You do not need to know the whole XSD schema to perform the first check. It is enough to know which areas correspond to the most important parts of the invoice. Node names may look technical, but their meaning is accounting-related.

Naglowek describes the document type, structure version and system data. Podmiot1 is the seller, and Podmiot2 is the buyer. Fa contains invoice header data, including number, dates, currency and document type. FaWiersz describes invoice lines. VAT summaries show values by rate.

Practical example: when looking for the seller tax ID, start in Podmiot1. When looking for the seller's own invoice number, go to Fa. When checking amounts and rates, compare FaWiersz with VAT summaries instead of reading the entire document from the top.

Do not treat this map as a complete list of mandatory fields. Requirements depend on invoice type and detailed FA(3) rules. The map helps orientation; it does not replace validation.

The first check is not about reading the whole file from top to bottom. Start with fields that usually decide document identification and further accounting work.

Compare the invoice number with the source document or accounting system. Then check the seller tax ID, buyer tax ID, issue date, sale date, currency, line items, VAT rates and totals. If the invoice has a KSeF number, save it together with the acceptance date and status.

If you see a difference between the XML and the expected document, do not manually edit the final file without understanding the cause. Most often, the source data should be corrected in the originating system and a new XML generated.

One of the most common sources of confusion is mixing up the invoice number with the KSeF number. The invoice number is assigned by the seller in their system. The KSeF number is assigned by the central system after the document is accepted and has its own technical structure.

The KSeF number consists of a part identifying the seller tax ID, the acceptance date and a technical part with a checksum. It is not a replacement for the seller invoice number and should not be invented or corrected manually.

When receiving invoices through KSeF, you may encounter both invoice XML and metadata. Metadata helps search for documents, check identifiers and statuses, but it is not the same as the full invoice content. For audit work, keep the set together: XML, metadata, KSeF number and UPO in KSeF, if available.

A readable PDF helps you quickly see what is on the invoice, but first it is worth knowing whether the XML is technically sound. A validator detects issues that the human eye will not see in a preview, such as an invalid date format, a missing required element or schema mismatch.

Technical validation does not guarantee tax correctness. It helps detect structural issues and some inconsistencies, but it does not decide whether the transaction is taxed correctly, whether the VAT rate is substantively appropriate or whether the invoice matches the contract.

If you want to check the file before further work, use the KSeF XML validator. It is a public tool with a daily limit, so check the current terms directly on the tool page.

XML is a format for systems, while PDF is a convenient view for people. Conversion to PDF makes sense when you want to quickly compare data with an order, show the invoice to a non-technical person, pass the document for approval or check lines without scrolling through raw XML.

Do not treat the PDF as a new version of the invoice. If the PDF was generated from XML, it is only a visualization of the data. If the source data contains an error, the PDF will show the same error in a nicer form.

KSeFGPT provides a KSeF XML-to-PDF converter. It is a public tool with a daily limit, so check current terms directly on the converter page.

The signals below do not always mean invoice rejection, but they should stop the process and trigger a source-data check. Be especially careful with files that will go into accounting or support a dispute with a counterparty.

If something looks suspicious, do not limit yourself to the PDF visualization. Keep the original XML, run validation, check metadata and compare the document with data in the system that generated it.

Do not upload sensitive XML to random converters found in search results. An invoice may contain counterparty data, addresses, bank account numbers, amounts and commercial information, so use tools whose privacy policy and processing scope you understand.

A practical process should have three layers. First, keep the original XML and download metadata. Then check the file technically. Finally, create a readable PDF preview or pass data to the accounting system.

This way you do not lose the source evidence. If an error appears along the way, you can return to the original, check KSeF status, compare the invoice number with the KSeF number and reconstruct who worked on the file and when.

With larger document volumes, opening XML manually becomes risky quickly. Then it is worth relying on a tool that combines import, validation, preview, counterparty search and result archiving.

If you want to understand the document structure, start with XML and the FA(3) format in KSeF. If you work with an invoice received as PDF and need XML first, read Free PDF to XML KSeF converter.

For technical file checks, see XML validation and processing in KSeF. If the XML was rejected by the system, read Invoice rejected by KSeF.

Do not start by copying data from XML into a spreadsheet. First keep the original, confirm the source, check the KSeF number or document status and run validation. Only then create a PDF, pass data to accounting or explain differences with the counterparty.

For single files, a validator and XML-to-PDF converter are enough. For larger volumes, you need a process that tracks the file source, version, validation result and document archive.

Recommended articles: XML and FA(3) in KSeF, XML validation and processing in KSeF, Receiving invoices through KSeF and UPO in KSeF.