A mid-sized Polish manufacturing company, operating three production facilities across Mazowieckie and Silesia, had been preparing for the mandatory Krajowy System e-Faktur (National e-Invoice System, KSeF) rollout for months. Their ERP vendor had delivered the integration module on schedule. The finance director assumed the hard work was done. Then, six weeks before the go-live date, the first test batch produced 340 rejected invoices – none of which triggered any alert in the internal system.

Testing a KSeF integration before the mandatory deadline requires structured validation across three layers: technical connectivity with the Ministry of Finance API, logical correctness of invoice data, and process readiness within the finance team. Polish tax law requires that e-invoices issued through KSeF carry a unique KSeF number assigned by the system within a defined acceptance window. Errors detected after go-live can result in invoices being treated as not issued, triggering VAT and penalty exposure. A structured pre-deadline testing programme, run in the KSeF test environment, eliminates the most common failure points before they cause real harm.

This case study follows that manufacturer through a four-week remediation and testing programme coordinated by our Warsaw tax practice. The lessons apply to any Polish taxpayer – manufacturing, IT, or foreign-owned subsidiary – facing the same deadline pressure. We address the background, the testing strategy we designed, the process steps, and the transferable lessons for your own integration.

What was the background, and why did the initial integration fail?

The company issued around 1,200 invoices per month across domestic and cross-border transactions. Its ERP system had been configured to generate XML files in the FA(2) schema required by the National Court Register (KRS)-linked taxpayer identifiers and the Ministry of Finance API. The Polish Financial Supervision Authority (KNF) reporting obligations added a parallel data stream that the IT team had inadvertently merged with the invoice output. A third complexity: the company's IP Box arrangement required separate cost allocation fields that the standard ERP template did not accommodate.

The root cause was straightforward. The ERP vendor had tested connectivity – confirming that the system could send files to the KSeF test environment and receive a response. They had not tested data quality. Of the 340 rejected invoices, 180 failed on incorrect buyer NIP (tax identification number) format, 95 failed on missing mandatory fields in the FA(2) schema, and 65 failed because the invoice date field used a format the API rejected. None of these errors were visible in the ERP's own validation layer.

We were engaged four weeks before the client's internal go-live date – itself set two weeks before the statutory deadline. That left 28 days to diagnose, remediate, and re-test. Our team from the Warsaw tax practice, working alongside the client's CFO and IT lead, structured the programme into three sequential phases.

How did we design the testing strategy?

The testing strategy addressed three distinct failure modes: structural errors in the XML schema, semantic errors in invoice data, and process gaps in the finance team's handling of rejection notifications. Each failure mode required a different remediation path. Structural errors needed developer time. Semantic errors needed a data-cleansing exercise on the customer master file. Process gaps needed a written escalation protocol that the finance team could follow without legal or IT involvement.

In the first week, we conducted a full audit of the client's customer master file – 640 active counterparties. We cross-referenced each NIP against the Ministry of Finance's taxpayer verification API (the "White List"). Eighteen counterparties had outdated NIP entries. Four were foreign entities whose Polish branches had been assigned new identifiers after restructuring. Correcting these before testing eliminated the single largest rejection category. For context on how similar issues arise in cross-border KSeF scenarios, see our analysis of the KSeF deadline timeline for companies in Slovakia.

In week two, we ran 500 test invoices through the KSeF test environment in five batches of 100. We deliberately included edge cases: credit notes, corrective invoices, advance invoices, and invoices with split payment markers. The rejection rate fell from 28% in the first batch to under 3% by the fifth. The remaining rejections all traced to the IP Box cost-allocation fields – a schema customisation that required a formal interpretation request to the tax authority, which we filed on the client's behalf.

  • Week 1: customer master file audit and NIP verification against the White List
  • Week 2: five test batches of 100 invoices, covering all invoice types
  • Week 3: remediation of schema customisation for IP Box fields; staff training on rejection alerts
  • Week 4: parallel running – live invoices issued both through the legacy system and KSeF simultaneously

We also reviewed the client's transfer pricing documentation to confirm that intercompany invoice fields would not conflict with KSeF mandatory data requirements. For a broader view of safe harbour rules that affect intercompany pricing disclosures, our guide on transfer pricing safe harbours under Polish law sets out the applicable thresholds.

What did the process reveal, and what were the outcomes?

The parallel-running week was the most instructive phase. Three invoices issued through the legacy system were not replicated in KSeF within the required window. Two were caused by a network timeout that the IT team had not anticipated. One was caused by a finance team member manually overriding the ERP workflow – a process gap that no amount of technical testing would have caught. The escalation protocol we had drafted in week three was invoked for the first time during parallel running, and it worked. The missing invoices were reissued within 24 hours, within the correction window permitted by Polish VAT law.

The finance director later noted that the parallel-running phase alone justified the entire engagement. The company entered mandatory KSeF operation with a documented testing history, a working escalation protocol, and zero outstanding rejection issues. That documentation also proved valuable three months later, when a KAS (National Revenue Administration) audit queried two invoices from the first week of mandatory operation. The testing records allowed the company to demonstrate due diligence, and the audit was closed without a surcharge.

What are the transferable lessons for your KSeF testing programme?

The single most important lesson is that connectivity testing and data-quality testing are not the same exercise. An ERP system can connect to the KSeF API and receive a "received" response while still generating invoices that will be rejected at the validation stage. Many companies – particularly those that delegated integration entirely to their ERP vendor – conflate the two. The distinction matters because rejected invoices are not treated as issued under Polish tax law. That triggers a cascade: the buyer cannot deduct input VAT, and the seller faces a late-issuance penalty of up to PLN 500 per invoice.

The second lesson concerns process, not technology. The KSeF system assigns a unique number to each accepted invoice within a defined window (currently up to 24 hours in the test environment, shorter in production). If your finance team does not have a protocol for monitoring acceptance confirmations and escalating rejections, a technical integration – however well-built – will fail in operation. We recommend a written escalation protocol as a mandatory deliverable of any KSeF implementation project, not an optional add-on.

The third lesson is specific to companies with complex invoice types: test every type, not just the standard sales invoice. Credit notes, corrective invoices, advance invoices, and invoices with mandatory split payment markers each have distinct schema requirements. A rejection rate of zero on standard invoices tells you nothing about your exposure on the edge cases that, in practice, generate the most disputes. For companies operating under DORA compliance obligations with digital operational resilience requirements, the parallel discipline of system-level testing is addressed in our briefing on DORA compliance: who must comply and by when.

A second result worth noting: our team obtained a formal tax ruling protecting a Silesian distribution company's KSeF correction procedure, covering a transaction value exceeding PLN 1.2m (spring 2026). The ruling confirmed that the company's corrective invoice workflow met the statutory requirements without triggering a penalty notice.

What to prepare before your KSeF testing programme:

  • Full customer master file with NIP numbers verified against the White List
  • Inventory of all invoice types issued (standard, corrective, advance, split payment)
  • Written escalation protocol for rejection notifications
  • Confirmation from ERP vendor of FA(2) schema version and update schedule
  • Legal review of any non-standard invoice fields (IP Box, transfer pricing, family foundation structures)

The statutory deadline is fixed. The KSeF test environment is available now, at no cost, through the Ministry of Finance portal. There is no technical reason to delay testing. The only reason companies delay is that they underestimate the gap between connectivity and compliance – precisely the gap this case study is designed to close.

Your company's specific situation may differ from the manufacturer described here. The consequences of a failed go-live – invoices not treated as issued, VAT deduction denied to buyers, penalty exposure per rejected document – are not reversible after the deadline passes.

If your company is approaching the KSeF mandatory deadline and has not yet completed structured data-quality testing across all invoice types, contact our Warsaw tax practice to discuss a tailored testing programme: info@kordeckipartners.com.

Frequently asked questions

Q: How long does a proper KSeF integration test take?

A: A structured testing programme covering data-quality audit, multi-batch test submissions, and parallel running typically requires three to four weeks. Companies that attempt to compress this into one week routinely miss the semantic error categories – incorrect NIP formats, missing mandatory fields – that cause the highest rejection volumes. Budget at least 20 business days before your go-live date.

Q: Is it a common misconception that ERP vendor testing is sufficient?

A: Yes. ERP vendors typically test connectivity and schema compliance. They do not audit your customer master file, verify NIP numbers against the White List, or test edge-case invoice types such as corrective invoices and advance invoices. Those gaps are the company's responsibility. A Polish tax advisor Warsaw-based or otherwise should review the data layer independently of the vendor's technical sign-off.

Q: What happens if an invoice is rejected by KSeF after the mandatory deadline?

A: Under Polish tax law, a rejected invoice is not treated as issued. The seller's VAT liability still arises on the transaction date, but the invoice number required for the buyer's input VAT deduction does not exist. The seller must reissue the invoice, which may be treated as a late issuance. Penalties apply per document. In high-volume scenarios, the cumulative exposure can reach significant amounts within a single reporting period – making pre-deadline testing the most cost-effective risk management available.

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 tax compliance, KSeF integration, and VAT advisory. We work with Polish entrepreneurs, foreign investors, and in-house legal teams. To discuss your situation, contact info@kordeckipartners.com.

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.