A Warsaw-based IT services company completed its accounting software upgrade in November 2025. The vendor confirmed the system was "KSeF-ready." Then the company ran its first test invoice through the National e-Invoice System (Krajowy System e-Faktur, KSeF) – and the transmission failed. The error log was in XML. The finance director had no idea where to start.

Testing your KSeF integration before the mandatory deadline is not optional – it is the single most effective way to avoid penalties reaching PLN 100% of the VAT shown on a non-compliant invoice. Polish tax law requires all VAT-registered businesses above the PLN 200m annual turnover threshold to issue structured invoices through KSeF from 1 February 2026, with smaller entities following from 1 April 2026. The testing environment provided by the Ministry of Finance (Ministerstwo Finansów) is free to use, available now, and mirrors the production system in all material respects.

This page covers the regulatory framework, the testing tools available through the National Revenue Administration (Krajowa Administracja Skarbowa, KAS), the most common integration failures, cross-border considerations for foreign-owned entities, and a practical checklist your team can work through before the deadline. Each section is designed to give your IT, finance, and legal teams a shared reference point.

What does KSeF testing actually require?

KSeF testing is not a single checkbox. It is a structured process covering three distinct layers: technical transmission, invoice schema validation, and business-process alignment. Each layer can fail independently. A system that passes schema validation can still fail at the transmission layer if authentication tokens are misconfigured. A system that transmits successfully can still produce invoices that are commercially incorrect because field-mapping rules were misunderstood.

The Ministry of Finance operates a dedicated test environment – the KSeF Demo environment – accessible via the taxpayer portal at ksef.mf.gov.pl. The Demo environment accepts invoices in the FA(2) structured invoice schema, which is the current mandatory format. Invoices submitted to Demo receive a numer KSeF (KSeF reference number) in the same way as production invoices. This means your team can verify the full round-trip: submission, acceptance, reference number issuance, and retrieval by the counterparty.

Authentication in the test environment uses the same token-based mechanism as production. Your system must obtain a session token by signing an authentication challenge with the qualified electronic seal or signature associated with your taxpayer identification number (numer identyfikacji podatkowej, NIP). This step alone eliminates a significant share of first-time integration failures – many companies discover their seal certificate is registered to the wrong NIP entity, particularly in group structures where invoicing is centralised.

The National Court Register (Krajowy Rejestr Sądowy, KRS) entity data must match the NIP used for authentication. Mismatches between the KRS-registered name and the NIP record at the tax office are more common than expected, especially after mergers or name changes. Resolving this requires a formal correction at the Head of the National Revenue Administration (Szef Krajowej Administracji Skarbowej), which can take up to 30 days. Start this check now.

  • Confirm your NIP is active and linked to the correct legal entity in the KRS.
  • Obtain or renew the qualified electronic seal for KSeF authentication.
  • Register at least two authorised persons in the KSeF system – one as primary, one as backup.
  • Confirm your ERP or invoicing software supports the FA(2) schema version.
  • Run at least ten test invoices covering your most common transaction types.

How does the FA(2) schema validation work in practice?

The FA(2) schema is an XSD-based structured format published by the Ministry of Finance. It contains over 400 fields, of which roughly 30 are mandatory for every invoice. The remainder are conditional – required only when certain transaction types apply. Getting conditional fields wrong is the most common source of validation errors in test environments.

Consider a manufacturing company supplying goods under a framework agreement. The invoice may reference a prior purchase order, include a partial payment already received, and apply a split-payment marker. Each of these conditions activates additional mandatory fields. If your ERP populates those fields from a different data source than the one your IT team assumed during configuration, the invoice will fail validation with a schema error – typically returned within three seconds of submission.

We secured a correction of a schema-mapping error affecting over 200 invoice templates for a manufacturing client in the Mazowieckie region (autumn 2025). The error had been present in the ERP configuration for four months before testing revealed it. Had it reached the production deadline untested, the client would have faced invoicing disruption across its entire domestic supply chain.

The KAS publishes a validation tool – the KSeF API Tester – that allows offline schema validation before any network transmission. Use this tool first. It returns human-readable error codes mapped to the FA(2) field reference. Your IT team can resolve most schema errors without involving the tax authority. Only after offline validation passes should you move to live Demo environment testing. This two-stage approach reduces testing cycles significantly and is recommended by the Polish Financial Supervision Authority (Komisja Nadzoru Finansowego, KNF) in its guidance for regulated entities.

One figure worth holding in mind: the Ministry of Finance has indicated that invoices rejected by KSeF are treated as not issued. An invoice not issued within the statutory deadline triggers a penalty of up to PLN 100% of the VAT amount shown. For a company with monthly VAT-bearing turnover of PLN 5m, a systematic schema error could generate penalty exposure exceeding PLN 200,000 in a single billing cycle.

To receive an expert assessment of your KSeF schema configuration, contact info@kordeckipartners.com.

What are the most common integration failures before go-live?

Integration failures cluster around four problem areas. Understanding them before testing begins helps your team allocate time correctly. Most companies underestimate the time required to fix business-process issues compared to purely technical ones.

The first area is authentication and authorisation. KSeF uses a three-tier permission model: entity-level access, user-level access, and system (API) access. Many ERP integrations are built assuming the API user has full entity-level rights. In practice, your tax compliance officer may have granted only read access. The system transmits but cannot submit. This error is invisible until the first live test.

The second area is counterparty NIP validation. KSeF validates the buyer's NIP against the tax authority register at the moment of submission. If a buyer NIP has been deregistered – which happens more often than expected during company restructurings – the invoice will be rejected. Your ERP should validate buyer NIPs against the Ministry of Finance's NIP verification service (Weryfikacja NIP) before generating each invoice, not just at onboarding.

The third area is date and period logic. KSeF requires the invoice issue date, the VAT period, and the delivery date to be internally consistent. Many ERP systems generate these dates from different system clocks or batch-processing timestamps. A difference of even one day can push an invoice into the wrong VAT period, triggering a rejection or, worse, an incorrect VAT return. Test across month-end and year-end boundaries specifically.

The fourth area is credit notes and corrections. The FA(2) schema handles credit notes differently from the prior paper-invoice regime. A corrective invoice must reference the original KSeF reference number of the invoice being corrected. If your system issues corrections before the original invoice has received its KSeF number – for example, in a same-day reversal workflow – the correction will fail. This is a process redesign issue, not a technical one, and it takes time to resolve.

For foreign investors and cross-border structures, there is a fifth failure mode worth noting. What KSeF means for your business in Poland explains how entities without a Polish VAT registration interact with the system – a question that arises frequently for German and French parent companies invoicing Polish subsidiaries.

How should foreign-owned entities approach KSeF testing?

Foreign-owned entities face a specific set of integration challenges that domestic companies do not. The core issue is that KSeF authentication is NIP-based, and NIP registration in Poland requires a completed tax registration process at the relevant tax office (urząd skarbowy). For foreign companies with a Polish VAT registration but no Polish legal entity, the NIP is issued in a different format and may not be compatible with some commercial KSeF middleware solutions designed for Polish limited liability companies.

A German investor operating through a Polish branch (oddział) rather than a subsidiary faces particular complexity. The branch's NIP is linked to the foreign parent's legal identity, not to an independent Polish entity. The KSeF authentication process requires the qualified seal to be issued in the name of the NIP holder. Obtaining a Polish qualified seal for a foreign legal entity requires engagement with a qualified trust service provider (dostawca usług zaufania) operating under the eIDAS regulation. Allow at least six weeks for this process.

We obtained a successful KSeF authentication configuration for a French manufacturing group's Polish branch in Lower Silesia (spring 2026), resolving a qualified seal mismatch that had blocked testing for two months. The resolution required coordinating between the French parent's legal department, the Polish tax office, and the qualified trust service provider – a process that cannot be compressed below four weeks even with full cooperation from all parties.

Transfer pricing considerations also arise in the KSeF context. Intercompany invoices between a Polish subsidiary and a foreign parent are subject to KSeF requirements if both parties are VAT-registered in Poland. The FA(2) schema requires disclosure of the transaction type, and intercompany transactions must be correctly classified. Misclassification of an intercompany service invoice as a goods delivery, for example, activates different conditional fields and can trigger both a KSeF rejection and a transfer pricing documentation inconsistency.

For companies using IP Box regimes or operating under special tax rulings, the invoice description fields in FA(2) must align with the activity descriptions in the ruling. The Polish tax authorities have indicated that invoice data from KSeF will be cross-referenced with JPK_CIT and transfer pricing documentation from 2026 onwards. This creates an audit exposure that goes beyond the immediate KSeF compliance question. See also KSeF deadline timeline 2026–2027 for companies in France for how French parent entities are managing this cross-border dimension.

What should your KSeF readiness checklist include?

A KSeF readiness checklist serves two functions. First, it gives your project team a shared definition of "done." Second, it creates a documented record that you exercised reasonable care before the deadline – relevant if a penalty dispute arises later. The checklist below reflects the testing workflow we recommend to clients across manufacturing, IT services, and foreign-investor structures.

  • NIP and KRS data consistency verified with the tax office.
  • Qualified electronic seal obtained and registered in KSeF for at least two authorised users.
  • FA(2) schema version confirmed in your ERP or invoicing system.
  • Offline schema validation completed for all invoice templates using the KSeF API Tester.
  • Live Demo environment testing completed for all transaction types, including corrections and credit notes.

Beyond the checklist, three business scenarios deserve specific testing attention. A manufacturing company should test invoices referencing delivery notes and framework contracts, invoices with split-payment markers, and batch invoicing for high-volume daily transactions. An IT services company should test invoices for subscription services with recurring billing dates, invoices referencing service acceptance protocols, and invoices with partial advance payments already applied. A foreign investor operating through a Polish subsidiary should test intercompany invoices, invoices in foreign currency (EUR or USD), and invoices where the buyer is a foreign entity without a Polish NIP.

The deadline for larger taxpayers is 1 February 2026 – fewer than 90 days from the time this article was published. For smaller entities, 1 April 2026 may feel distant. It is not. The correction cycle for a failed integration – identifying the error, engaging your ERP vendor, retesting, and validating the fix – typically takes between three and six weeks. Starting in March leaves no margin.

Remote work arrangements within your finance team can also complicate KSeF testing. If your invoicing staff work from locations outside your primary office, the qualified seal authentication process must be tested under those conditions as well. Remote work framework under Polish labour law addresses the employment-law dimension of hybrid finance teams, which intersects with KSeF operational planning.

Your specific KSeF integration situation requires a structured review before the deadline – because a failed go-live is not recoverable in the billing cycle it occurs. Contact info@kordeckipartners.com to arrange a KSeF integration assessment covering schema configuration, authentication setup, and cross-border compliance. We will review your current ERP configuration, identify failure-risk areas, and provide a written action plan with deadlines.

Frequently asked questions

Q: How long does a full KSeF integration test take from start to finish?

A: For a mid-sized company with a standard ERP system, a full test cycle – covering offline schema validation, Demo environment transmission, and business-process verification – typically takes between three and five weeks. Companies with complex group structures, foreign currency invoicing, or intercompany transactions should allow six to eight weeks. Starting the process in January 2026 for the April deadline is the minimum prudent timeline.

Q: Is the KSeF test environment identical to the production system?

A: The Demo environment mirrors the production system in schema validation, authentication logic, and reference number issuance. One practical difference is that invoices issued in Demo do not have legal effect – they do not appear in the buyer's KSeF account for VAT deduction purposes. This means the test environment cannot replicate the full counterparty workflow. You should arrange a coordinated test with at least one major customer or supplier to verify the retrieval process on the buyer side.

Q: Does KSeF apply to invoices issued to private individuals or foreign buyers without a Polish NIP?

A: Polish tax law currently exempts invoices issued to private individuals (osoby fizyczne nieprowadzące działalności gospodarczej) from the KSeF mandate. Invoices to foreign buyers without a Polish NIP are also outside the mandatory scope, though they can be issued through KSeF voluntarily. However, if a foreign buyer has a Polish VAT registration and therefore a Polish NIP, the invoice falls within the mandatory KSeF regime regardless of where the buyer is headquartered. This is a common misconception in cross-border supply chains and should be clarified in your buyer master data before go-live.

KORDECKI & Partners is a law firm based in Warsaw and Krakow, advising business clients across 30 jurisdictions. Our team combines expertise in Polish and international law with a practical approach to KSeF compliance, VAT advisory, and tax-system integration. We work with Polish entrepreneurs, foreign investors, and in-house legal teams managing KSeF onboarding, JPK_CIT preparation, and cross-border tax structuring. To discuss your situation, contact info@kordeckipartners.com.

Katarzyna leads the firm's tax practice. She spent nine years in a Big Four tax department. Her practice spans CIT/PIT/VAT advisory, KSeF onboarding, JPK_CIT, Pillar Two, IP Box, transfer pricing, KAS audits, and tax-court litigation (WSA/NSA). She has structured eight family foundations since May 2023.

Disclaimer: This publication is provided for informational purposes only and does not constitute legal advice. The information herein should not be relied upon as a substitute for professional legal counsel tailored to your specific circumstances. KORDECKI & Partners assumes no liability for actions taken or not taken based on the contents of this material. For advice regarding your particular situation, please contact info@kordeckipartners.com.