How to send invoices to KSeF - complete guide 2026

Article summary

Key takeaway: from 1 February 2026 (gross sales above PLN 200 million in 2024) and from 1 April 2026 (all other VAT taxpayers), B2B invoices in Poland must be sent exclusively through the National e-Invoicing System (KSeF) in XML FA(3) format. The invoice is legally issued at the moment KSeF accepts it (Art. 106na(1) of the Polish VAT Act).

Practical advice: in the vast majority of cases you send in online mode - generate FA(3) XML, submit to the MF gateway, receive the KSeF number and UPO receipt. The offline24, unavailability, and failure modes are exceptions with precisely defined resubmission deadlines (next business day, next business day after unavailability ends, and 7 business days after failure ends, respectively).

Warning: approximately 70% of rejections are XSD validation errors against the FA(3) schema - incorrectly formatted dates, NIP numbers with separators, wrong ISO country codes, or inconsistent net/VAT/gross totals. Skipping pre-submission validation wastes time and creates duplicate invoice risk (error 440 Invoice Duplicate).

Introduction: what 'sending an invoice to KSeF' means in 2026

As of 22 April 2026, the KSeF e-invoicing obligation is in effect for all active VAT taxpayers in Poland. Large companies (gross sales above PLN 200 million in 2024) entered the obligation on 1 February 2026, and all other taxpayers on 1 April 2026. Transitionally, until 31 December 2026, monthly sales up to PLN 10,000 gross may be invoiced outside KSeF, and B2C consumer invoices remain optional in the system.

In KSeF terminology, 'sending an invoice' means issuing a structured invoice (faktura ustrukturyzowana) and transmitting it as FA(3) XML to the Ministry of Finance central system. Under Art. 106na(1) of the VAT Act, an invoice is legally issued on the date it is transmitted to KSeF. This technical moment replaces the traditional concept of 'issuance' and has direct consequences for VAT, payment terms, and accounting.

This guide covers only the submission of outgoing sales invoices (outcome) by the taxpayer or an entity acting on their behalf. It does not cover the receipt of purchase invoices. If you are considering whether the KSeF obligation can be avoided, see: can you avoid KSeF in 2026. If you are wondering whether a PDF is sufficient instead of XML, see: can you send a PDF to KSeF.

This guide covers: key conclusions table, submission modes, step-by-step online process, authentication methods comparison, UPO receipt, common errors, pre-submission checklist, and a tool comparison - including the free KSeFGPT alternative (masowy CSV/PDF import, AI data recognition, no registration required).

Key conclusions

The table below summarises the operational points you need to know before submitting your first invoice to KSeF in 2026.

Invoice submission modes in KSeF

KSeF 2.0 provides four invoice submission modes, each regulated in the VAT Act. The default in practice is online mode. The other three are exceptions with different legal bases, deadlines, and requirements (in particular the use of a KSeF type 2 certificate and two QR codes on the visualisation). The table below consolidates four Ministry of Finance knowledge base pages into one view.

Differences between modes in day-to-day operations

The most common split is between online and offline24. Online assumes everything is working: your system generates the XML, authenticates the session, and transmits the file in seconds. You activate offline24 when something fails on your side - internet outage, ERP vendor failure, power cut - while KSeF itself is operating normally. You make this decision independently, without any Ministry announcement.

The Ministry of Finance declares unavailability and failure modes - unavailability in BIP MF, failure additionally via software-level notifications (integrators receive signals through the API). A full failure is a separate scenario announced through mass media - during it you do NOT send invoices to KSeF at all; you issue them outside the system and submit them after the failure ends.

In all modes except online, an additional requirement applies: when sharing the invoice with the buyer outside KSeF (e.g. PDF by email, printout), the visualisation must contain two QR codes - QR CODE I 'OFFLINE' enabling KSeF verification after submission, and QR CODE II 'CERTIFICATE' confirming issuer identity and requiring a KSeF type 2 certificate.

Operational conclusion: budget time for an offline procedure in your team's workflow, even if 99% of submissions will go online. Now that we know when to use each mode, let us look at the detailed online process.

Step-by-step online submission process

Online mode is a six-step sequence that takes seconds in a well-designed tool. Each step has specific technical requirements and common failure points.

Step 1 - data preparation and context selection. You determine on whose behalf the invoice is being issued (taxpayer or entity context) and which employees have the relevant invoice issuance permissions. The context is selected before opening the session; changing context requires closing and reopening a new session.

Step 2 - authentication and session opening. You log in using a qualified signature/seal, Trusted Profile, KSeF token, or KSeF type 1 certificate. The session can be interactive (single invoices sent one by one) or batch (a full file with multiple invoices and a consolidated UPO at the end).

Step 3 - FA(3) XML generation. Your software creates an XML file compliant with the FA(3) logical schema in force from 1 February 2026. Size limit: 3 MB including any attachments. At this stage you run local validation - on your own system or using a validator - to avoid wasting a technical round on structural errors.

Step 4 - transmission to the KSeF gateway. The file goes to the MF production environment (api.ksef.mf.gov.pl) or, during testing, to the test environment (ksef-test.mf.gov.pl). The system begins validation.

Step 5 - semantic validation and KSeF number assignment. KSeF checks schema compliance (XSD validation), FA(3) business rules, sum consistency, and required fields. After positive validation it assigns a KSeF number in format NIP-YYYYMMDD-10hex-2hex (e.g. 5213870274-20260418-A1B2C3D4E5-F6). This number is the document's unique identifier in the system.

Step 6 - UPO download and session close. The UPO (official receipt of acceptance) typically appears within minutes of positive validation. It contains the KSeF number, date and time of acceptance, SHA-256 cryptographic hash, and mode indicator. After downloading the UPO you close the session - in a batch session you receive a consolidated UPO for the whole batch.

For more technical validation details (what exactly XSD checks, error ordering, diagnostics), see the article on XML validation and processing in KSeF. Now that we understand the process, let us look at how you authenticate.

Authentication methods in KSeF

Every KSeF session requires identity confirmation. In 2026 you have five main methods - three 'traditional' (qualified signature, qualified seal, Trusted Profile) and two 'technical' (KSeF token, KSeF certificate). KSeF certificates became available for generation from 1 November 2025 and are in practical use from 1 February 2026.

The choice of method depends on who is submitting - an individual, a legal entity, or an integration system - and whether you also need offline mode support (which requires a KSeF type 2 certificate). The table below compares the key parameters.

Offline and failure modes in practice

Offline24 mode (Art. 106nda) is activated by you when something fails on your side. You issue the invoice in FA(3) XML in your own system, provide the buyer with a visualisation containing two QR codes (QR CODE I 'OFFLINE' and QR CODE II 'CERTIFICATE'), and submit the file to KSeF immediately, no later than the next business day. For the buyer, the moment they receive the document is the effective issue date; for VAT and accounting purposes, the issue date is the moment the file is submitted to KSeF (Art. 106na).

KSeF unavailability mode (Art. 106nh) differs in one element: it is MF that declares the unavailability in BIP. The taxpayer procedure is similar - FA(3) XML, QR codes on the visualisation, submission to KSeF - but the deadline is no later than the next business day after the unavailability declared by MF ends.

Failure mode (Art. 106nf) is triggered when MF officially declares a KSeF failure - in BIP and in notifications available through the API for integrators. The resubmission window is longer - 7 business days from the end of the failure. You issue the invoice with the actual date, with QR codes, and it goes to KSeF after the system is restored.

A complete failure is an exceptional scenario: declared through mass media, it means you do NOT submit invoices to KSeF at all during that period. Documents circulate outside the system and after the failure ends the Ministry publishes rules for submitting the backlog. This is a mode for which you do not need to design a separate process - you react to the MF announcement.

Conclusion: your company's process design should cover at least offline24 (for your own network outages) and have a conscious escalation path for MF-declared unavailability/failure. Now that we know the submission modes, let us move to the acceptance confirmation - the UPO.

UPO - confirming KSeF acceptance of an invoice

The UPO (Urzedowe Poswiadczenie Odbioru - Official Receipt of Acceptance) is the official MF document confirming that KSeF has accepted and validated your invoice. Without a UPO you have no legal proof of invoice issuance - it is the UPO, not an email, not a screenshot, and not the XML file, that is the sole evidence for the tax office, accounting, and audit.

A UPO contains: the KSeF number assigned to the invoice, date and time of acceptance, SHA-256 cryptographic hash of the document (guaranteeing integrity), mode indicator (online/offline), and session ID. UPO is available in two formats: XML (for archiving and ERP/accounting integration) and PDF (for accounting and HR workflows).

When does the UPO appear? In online mode - after positive semantic validation, typically within minutes. In a batch session, after closing the session you receive a consolidated UPO covering all accepted invoices in the batch. In offline modes the UPO is generated only after the file has been successfully submitted to KSeF and positively validated.

The archiving period for invoices and UPOs in the central system is 10 years from the end of the year in which the invoice was issued. Operationally it is worth keeping your own copy of UPOs in the company's records - faster access, independence from an external system, easier analytics. In the MF Taxpayer Application the UPO download path in interactive session is: Authorisation > Close session; in a batch session you download the consolidated UPO after the batch is processed.

Now that we know what confirms submission, let us move to the most common pain point for accounting teams - errors and rejections.

Most common errors and rejections on submission

The Ministry of Finance does not publish a single official index of KSeF error codes. The following table is based on implementation practice observations - integrator reports, tax firm analyses, and logs from the first months of mandatory use - and shows symptoms most frequently encountered since February 2026. According to industry analyses, approximately 70% of rejections are XSD validation errors, i.e. XML non-compliance with the FA(3) schema.

How to handle errors operationally

The fastest path is local XML validation before every submission. If your tool does not do this, 70% of rejections will only surface after a round trip to MF servers - and each cycle costs time. The validator should be aligned with the current FA(3) schema version and report errors in field context, not as a raw stack trace.

The second element is data contract discipline: consistent formatting of NIP, dates, country codes, and VAT rates at the source (in the invoicing system), not in the output mapping. On-the-fly mapping works until an exception appears - a new foreign counterparty, a sensitive goods rate - and then everything breaks.

The third element is UPO monitoring: a set of alerts for invoices 'sent' without a UPO within 30 minutes (outside offline modes). Missing UPO is an operational signal that something went wrong - even if the system reports 'OK'. Now that we know the errors, let us look at the tools that minimise risk.

Submission tools: Taxpayer Application, ERP, KSeFGPT

In 2026 you have three realistic paths for submitting invoices to KSeF. The choice depends on invoice volume, existing accounting systems, and readiness for technical integration.

The KSeF Taxpayer Application (ap.ksef.mf.gov.pl) is the free government tool from the Ministry of Finance. Manual operation: you fill in the invoice form or load a single XML file, send via browser, download the UPO. Works well for single invoices and as an emergency fallback; less effective at volumes above a few dozen documents a day as it has no bulk mechanisms.

ERP/accounting systems (Comarch, Enova, Symfonia, SAP, and others) use API integration - the invoice is created in the financial system and sent to KSeF automatically, with the UPO returning to the ledger. Advantages: full automation, volume handling, audit trail. Disadvantages: implementation cost, setup time, dependency on the vendor's update schedule.

KSeFGPT is the alternative for companies that do not yet have an integration or need a fast bulk path. In practice you open the application without registration, drop a batch of CSV files or PDFs, and the AI recognises the data, maps it to FA(3), and prepares the XML ready for submission. You also get a UPO export and can analyse invoices in a conversational interface. It is the only path of the three that requires no licence cost, no registration, and no IT department approval - it is up and running in minutes.

Practical choice: a small company with a few invoices a day and an existing ERP - the ERP vendor plugin is fastest. A company without an integrated ERP or with a pilot volume of cost invoices in PDF - KSeFGPT simplifies the process to a single batch drop. Occasional one-off invoices - the Taxpayer Application is sufficient.

Pre-submission checklist

The checklist below covers 10 points that eliminate most rejections before you hit 'Send'. Paste it into your internal accounting procedure or invoice template file.

1. Seller and buyer NIP written as 10 consecutive digits, no separators, no spaces, no 'PL' prefix (prefix only for EU-VAT in a separate field).

2. All dates in YYYY-MM-DD format (ISO 8601): issue date, sale date, payment due date.

3. XML file compliant with the FA(3) schema in force from 1 February 2026 - validated locally before submission.

4. Net, VAT, and gross totals consistent between line item level and invoice header - using the correct rounding algorithm.

5. Country codes in ISO 3166-1 alpha-2 standard (PL, DE, UA, US), not full names.

6. Currency in ISO 4217 code (PLN, EUR, USD); if not PLN, NBP exchange rates from the day preceding issuance.

7. Invoice number unique within the series for the given year - does not repeat NIP+number+date of a previous invoice (risk of error 440 Invoice Duplicate).

8. Seller and buyer address compliant with TAdres structure (country, postal code, city, street, building/apartment number in separate fields).

9. Taxpayer context selected before opening the session - do not attempt to change it during submission.

10. Invoice issuance permissions verified in the Taxpayer Application (individual/entity, with active signature/token/certificate).

If you have nine of the ten points but not the tenth - do not submit. A single missing permission invalidates the entire session and requires reopening in the correct context.

Interactive vs batch session - when to use which

KSeF provides two session handling modes via the API, relevant for ERP integrations and automation tools. An interactive session sends a single invoice with the UPO returned directly after acceptance. A batch session sends a package (many invoices in one file) with a consolidated UPO received after the session is closed.

Interactive session suits low volumes (a few to a few dozen invoices a day), sales where the buyer needs the KSeF number immediately (e.g. B2B with fast payment terms enforcement), and manual operation through the Taxpayer Application. Each invoice has its own UPO immediately.

Batch session suits volumes above 100 invoices a day, recurring billing (e.g. subscriptions, mass services), and integrations running on a batch cycle (overnight, billing hours). Consolidated UPO simplifies archiving and bookkeeping, but you need to design handling for partial rejections - when 3 out of 100 invoices in a batch fail validation.

If you want to explore the MF validation mechanics in more depth and what exactly happens between file submission and the KSeF number, see the article on XML validation and processing in KSeF.

Expert perspective: what hurts most in KSeF implementations

From implementation consultations conducted since February 2026, a recurring pattern emerges: companies that focused solely on 'can our system send XML' run into trouble two weeks after go-live. Not with submission, but with operations - who downloads the UPO to the archive, who sees rejections, how to handle a client who says they did not receive the invoice because they are looking at the email PDF rather than KSeF.

The second pattern is underestimating offline24. The IT team says 'we have 99.9% SLA', accounting assumes offline mode does not apply to them, and then on a Friday evening the ISP goes down and 40 March invoices must be issued locally with two QR codes. The offline24 procedure must be written, tested, and have a named responsible person before the first such incident, not after.

The third pattern is the 'a PDF is enough' trap. It is not - a PDF is not an invoice in KSeF. This is one of the most common support calls: the company wants to 'upload a scan' to the system, but what they actually need is PDF to FA(3) XML conversion. We cover this topic in detail here: can you send a PDF to KSeF.

Practical recommendation: before your company's obligation starts, test the full cycle (online + offline24 + UPO download + rejection handling) in the test environment at ksef-test.mf.gov.pl. Two days of testing saves two weeks of firefighting after production go-live.

Frequently asked questions

How do I send an invoice to KSeF? - Generate XML compliant with the FA(3) schema, authenticate the session (qualified signature, qualified seal, Trusted Profile, KSeF token, or KSeF certificate), submit the file to the KSeF gateway, and receive the KSeF number and UPO. In the vast majority of cases this is done in online mode, with submission at the moment of issuance.

Can I send a PDF to KSeF? - No. KSeF only accepts structured XML compliant with the FA(3) schema. A PDF can be a visualisation of an invoice or a source for conversion, but it is not a file accepted by the system.

What does sending an invoice to KSeF cost? - Submission to KSeF itself is free - the system is run by the Ministry of Finance. Costs include any ERP/accounting licence, a qualified signature (approx. PLN 250-400/year) or qualified seal (approx. PLN 500-1,200/year). KSeF certificate, Trusted Profile, and KSeF token are free. A no-cost, no-registration alternative is KSeFGPT.

What is UPO in KSeF? - UPO (Urzedowe Poswiadczenie Odbioru) is the official confirmation that KSeF has accepted the invoice. It contains the KSeF number, date and time of acceptance, SHA-256 cryptographic hash, and mode indicator. Available in XML and PDF formats. The UPO, not an email or screenshot, is the legal proof of invoice issuance.

How long do I have to submit an invoice in offline24 mode? - Immediately, no later than the next business day after issuing the invoice in offline24 mode. Legal basis: Art. 106nda of the Polish VAT Act.

What to do when KSeF is unavailable? - If MF declares unavailability (Art. 106nh), submit the invoice no later than the next business day after unavailability ends. If a failure is declared (Art. 106nf), you have 7 business days from when the failure ends. In both cases you issue the FA(3) XML invoice locally, with two QR codes on the visualisation provided to the buyer.

What QR codes must an offline invoice have? - Two QR codes: QR CODE I 'OFFLINE' enabling document verification in KSeF after submission, and QR CODE II 'CERTIFICATE' confirming issuer identity and requiring a KSeF type 2 certificate. Both must be visible on the visualisation (PDF, printout) provided to the buyer outside KSeF.

Is a KSeF token sufficient in 2026? - The KSeF token remains in use during the transitional period of 2026 per MF communications - it is being gradually phased out in favour of KSeF certificates, available from 1 November 2025 and in practical use from 1 February 2026. If you are designing a new integration, base it on certificates.

What is the invoice size limit in KSeF? - 3 MB including attachments per single invoice. For larger files, attachments must be split or their size optimised (e.g. image compression).

How do I verify that KSeF accepted an invoice? - A positive signal is the assignment of a KSeF number in format NIP-YYYYMMDD-10hex-2hex and receipt of UPO (typically within minutes of validation). No UPO after 30 minutes in online mode is a signal to verify session status and possible rejections.

Related articles

To explore the practical aspects of sending invoices to KSeF in more depth, start with these four resources:

KSeFGPT - application for invoice import, export and AI analytics - full description of the free alternative to the Taxpayer Application and ERP systems, including bulk CSV/PDF import and AI data recognition.

Can you send a PDF to KSeF - detailed explanation of the difference between a PDF and FA(3) XML and how to prepare a PDF for submission.

XML validation and processing in KSeF - MF-side validation mechanics, common XSD errors, and diagnostics.

Can you avoid KSeF in 2026 - exceptions, deadlines, and consequences of not submitting in mandatory mode.