Can you send a PDF invoice to KSeF? A step-by-step explanation

Short answer: can you send a PDF to KSeF?

No. KSeF does not accept a PDF invoice as a valid invoice in the standard system workflow. For a document to be successfully received by Poland's National e-Invoicing System, it must be a structured invoice in XML format conforming to the FA(3) schema.

This distinction matters because many companies use the term 'e-invoice' loosely to refer to an ordinary PDF sent by email. A PDF is convenient for a human reader, but KSeF operates on data stored in a logical structure — not on how the document looks.

If you only have a PDF, you need one more step: extracting the data, mapping it to FA(3), and only then submitting the XML to KSeF. That is why the question 'can I send a PDF to KSeF?' should really be: 'how do I convert a PDF to XML and submit a valid invoice to the system?'.

How does KSeF work in practice?

KSeF is not an inbox for attachments. It is a government system for issuing, transmitting, receiving, and storing structured invoices. In practice this means a simple but strict process: you create a document, generate XML, send it to KSeF, the system checks the file against the required schema, and only then assigns a KSeF number.

The official Ministry of Finance FAQ describes a structured invoice as a schema-compliant XML file submitted to the system and assigned a unique number. That KSeF number is what confirms the document was successfully accepted. A PDF alone produces no such confirmation.

To better understand what the system checks before accepting a document, see also the article on XML validation and processing in KSeF.

Why is a PDF rejected by KSeF?

The reason is straightforward: a PDF is primarily a visual representation. It displays the invoice layout, logo, tables, and data in a human-readable form, but it does not carry information in the way an automatic document-validation system requires.

FA(3) XML works the opposite way. It is not designed to look good — it is designed to describe precisely the seller's data, the buyer's data, line items, VAT rates, deadlines, and the relationships between fields. This allows KSeF to check the document's structure, technical consistency, and business rules before assigning a KSeF number.

In practice this means one thing: a PDF can be a supplement to the process, but it is not the file a business submits to KSeF as the actual invoice.

PDF vs FA(3) XML — how do they differ in daily work?

A PDF is for humans. It is easy to read, print, email, or attach to an internal workflow. FA(3) XML is for systems. It lets KSeF and integrated applications understand the data without manual re-entry.

A PDF shows what the invoice looks like; XML carries the data in a form suitable for validation, automation, and integration. That is why a PDF cannot easily be checked against a schema automatically, while an XML file can be analysed before submission.

The shortest summary: PDF is for reading, XML is for system processing. That is why KSeF works with FA(3) and not with PDF files — even if from a user's perspective a PDF looks like a finished invoice.

Where does PDF still have a role?

The fact that PDF is not the correct invoice format for KSeF does not mean it becomes useless. In many companies it still plays an important operational and communication role.

First, a PDF is a convenient visual representation of a structured invoice. Second, it may be the document sent to a counterparty outside the KSeF workflow itself, if that format is practically needed. Third, it is often the starting material for conversion — when a company begins with a document received by email or scanned from a paper workflow.

This is most visible with cost documents. A company receives a PDF from a counterparty, then reads the data, converts it to XML, validates it, and only then processes it in KSeF or its own system. This scenario is covered in more detail in the article on the PDF to KSeF XML converter.

What to do if you only have a PDF?

If your starting point is only a PDF file, you do not try to 'upload it to KSeF'. You first treat it as a data source. The key information must be extracted from the document, mapped to the FA(3) schema, mandatory fields verified for correctness, and only then can the document be submitted to the system.

The most sensible process looks like this: identify the document type, map data to the schema, validate the XML, submit the invoice via an application or API, receive the KSeF number and UPO, and finally generate a PDF as a preview or document for further communication. This is the exact opposite of manually uploading a PDF to the system.

If you have a large volume of such documents, manual re-entry quickly stops making sense. You then need a converter or integration that handles at least part of the technical work.

Common mistakes companies make when starting with KSeF

The most common mistake is assuming that because an invoice exists as a PDF, it is already ready to submit. The second problem is confusing an ordinary electronic invoice with a structured invoice. The third is the lack of integration and attempts to work around the process manually — copying data between email, Excel, and the KSeF portal.

A further misconception is that once a counterparty has received a PDF, the document cycle is closed. In reality, what determines successful acceptance in KSeF is not the email sent or the nice visual — it is the correct XML that passed through the system and received a KSeF number.

If a company wants to avoid these mistakes, it should establish a single coherent process as soon as possible: where does the data come from, who validates the document, how is the XML submitted to KSeF, and when is a PDF generated as an auxiliary layer. Without that, even simple invoices start generating operational chaos.

Do you need to send a PDF to the client?

Not always. In a standard B2B workflow, a PDF is not required for the invoice to exist in the system. If both parties operate within KSeF, the system workflow itself is more important than an additional visual in an email.

In practice, however, PDF remains convenient. Purchasing departments, sales teams, and clients often prefer a quick preview of the document over working with raw XML. That is why many companies still generate a PDF alongside the XML — but as a convenient communication layer, not a substitute for the actual invoice.

Official Ministry of Finance materials also indicate that when a document is delivered outside KSeF — for example to a consumer or a foreign recipient — the practical form of delivery may include a PDF. This does not change the fundamental principle, however: a PDF does not replace a structured invoice within the system itself.

What about attaching a PDF as an attachment?

This is a separate question, but the answer still leads to the same conclusion. The official MF FAQ clarifies that only structured XML files can be submitted in KSeF. This means a PDF is neither the correct invoice format for the system nor a plain attachment that can freely be added to a document in the KSeF workflow.

If you need to pass a PDF, Word file, JPG, or other auxiliary material to a counterparty, you do so outside the system. Within KSeF itself, you keep to the XML logic and KSeF number as the basis of the workflow. This way you do not mix the system layer with the communication layer.

This distinction is especially important where companies try to recreate the old model of 'invoice plus email attachments' inside KSeF. The system was not designed as a repository for arbitrary files — it was designed to work with structured data.

What does a sensible company process look like?

The most practical model is straightforward: a system or tool generates FA(3) XML, validates it before submission, sends it to KSeF, receives the KSeF number and UPO, and only then makes a human-readable PDF available. In this setup, PDF is not a problem — it simply stops performing a function it was never meant for.

If your company mainly works with documents received as PDFs, a good step is to combine PDF-to-XML conversion, validation, and KSeF submission into a single process. This reduces errors, shortens processing time, and eliminates manual data re-entry.

If you want to move from the model of 'I have a PDF and don't know what to do next' to 'I have a valid XML and a ready KSeF workflow', also check the KSeFGPT application for import, export, and AI analytics.

Frequently asked questions

Can you send a PDF instead of XML to KSeF? - No. KSeF receives a structured invoice in XML format, not a PDF.

Is a PDF required in the KSeF workflow? - No. The correct FA(3) XML is what matters for KSeF. A PDF may be a supplementary element, but it is not a mandatory system format.

How do you convert a PDF to XML for KSeF? - You need to extract the data from the document, map it to the FA(3) schema, verify the mandatory fields for correctness, and only then generate the XML ready for submission.

Can I issue an invoice only as a PDF? - For the KSeF workflow, a PDF alone is not sufficient. A valid invoice in the system must exist as XML and be submitted to KSeF.

What confirms that KSeF accepted an invoice — a PDF or the KSeF number/UPO? - Confirmation is the KSeF number assigned by the system, and operationally also the UPO. A PDF alone does not confirm that a document was accepted by KSeF.