KSeF error 440: three fields identify a duplicate

Error 440, “Duplikat faktury” (“Duplicate invoice”), concerns an XML file submitted to KSeF. It is not an instruction for sharing a lost PDF again.

Compare three fields

The Ministry of Finance handbook identifies exactly three values:

• The seller’s NIP — the NIP field in Podmiot1/DaneIdentyfikacyjne.
• The taxpayer’s own invoice number — the P_2 field.
• The invoice kind — the RodzajFaktury field.

When all three values are identical to those of an invoice already in KSeF, the submitted XML is rejected with error 440, “Duplikat faktury”. This is not a test of general similarity in content.

The taxpayer’s own number is not the KSeF identifier

P_2 is the invoice number assigned by the taxpayer, not the identifier assigned by the system. The KSeF identifier identifies the invoice in the system, is generated automatically and is returned in the official receipt confirmation (UPO).

The handbook describes a ten-year lookback for checking uniqueness. This describes the KSeF mechanism, not guidance on tax settlements.

Check earlier acceptance

The following checklist is optional organizational guidance, not a legal obligation:

1. Compare the rejected XML with the earlier invoice that may have the same set of values.
2. Compare the seller’s NIP in Podmiot1/DaneIdentyfikacyjne, P_2 and RodzajFaktury separately.
3. Check the earlier submission result and any available UPO and KSeF identifier. Do not treat the taxpayer’s own invoice number alone as confirmation of acceptance.
4. Keep the comparison results together with the rejection message to help investigate discrepancies.

Do not change the number, seller identity or invoice kind merely to bypass duplicate protection.

FAQ

Is one matching field enough?

The described rejection condition requires identical values in all three listed fields compared with an invoice already in KSeF.

Is P_2 the KSeF identifier?

No. It is the invoice number assigned by the taxpayer. The system assigns the KSeF identifier.

Does re-sharing a lost PDF cause error 440?

The description of error 440 concerns rejection of XML submitted to the system. Distinguish this from a request to share the PDF of an existing invoice again; the description of the mechanism does not establish rules for sharing that copy.

Does rejection of one XML file as a duplicate mean the entire ZIP batch is rejected?

No. Batch submission is not an all-or-nothing process: each XML file is processed independently, and errors affect individual files, not the entire ZIP batch. The remaining valid XML files receive KSeF identifiers after verification. Information about why individual documents were rejected is obtained by querying the rejected XML documents in that session. The list of erroneous XML files is returned after all submitted documents have been checked. See the Ministry of Finance’s KSeF 2.0 handbook, part II, section 3.3.2.

Source

Ministry of Finance: KSeF 2.0 handbook, part II, sections 3.4 and 4.1, pages 69–70.

Next step

Before another submission, consider organizing the comparison results for the three fields and the earlier acceptance. The aim is to understand the message, not to bypass the safeguard.