How to test your KSeF integration before

A Warsaw-based software distributor scheduled its KSeF go-live for the first week of February 2026 – only to discover, three days before the mandatory date, that its ERP system was sending invoices with a mismatched VAT identification number. The National e-Invoicing System (Krajowy System e-Faktur, KSeF), administered by the National Revenue Administration (Krajowa Administracja Skarbowa, KAS), rejects structurally invalid invoices silently. No rejection notice reaches the buyer. The seller's obligation is simply left unfulfilled.

Testing your KSeF integration before the mandatory deadline requires a structured sequence: environment access, schema validation, end-to-end transmission tests, and error-log review. The Ministry of Finance operates a dedicated pre-production environment that mirrors the live KSeF system. Completing a full test cycle takes a minimum of four weeks for a mid-size business and longer for companies operating across multiple VAT registrations or ERP modules.

This guide covers the four-stage testing procedure, the timeline and costs you should plan for, common integration errors that appear only under load, and three business scenarios – manufacturing, IT services, and a foreign investor – that illustrate where the process diverges. A checklist and FAQ close the guide.

What does the KSeF testing environment actually offer?

The Ministry of Finance (Ministerstwo Finansów) maintains two distinct environments: the production system and a pre-production sandbox called the Test Environment (Środowisko Testowe). The sandbox accepts real FA(2) schema invoices but issues no fiscal numbers and triggers no VAT obligations. Access requires a qualified electronic signature or a trusted profile (Profil Zaufany) linked to the company's Tax Identification Number (NIP). Registration in the National Court Register (KRS) must be current before access is granted.

The sandbox replicates the production API in all material respects. It validates the logical structure of the FA(2) schema – 463 fields, of which roughly 80 are mandatory for a standard B2B invoice. It also enforces the business-rule layer: date sequencing, VAT rate consistency, and buyer-seller NIP pairing. What it does not replicate is load behaviour under simultaneous submissions. That gap matters for companies issuing more than 1,000 invoices per day.

Three features are especially useful during testing. First, the environment returns a detailed XML error log for every rejected document – far more granular than the production error message. Second, it supports batch submission of up to 100 invoices per API call, allowing stress testing. Third, it retains submitted documents for 14 days, enabling your IT team and tax advisor to review the same data set without re-uploading.

Qualified signature or Profil Zaufany linked to the company NIP
Current KRS registration (for legal entities)
FA(2) schema – latest version published by the Ministry of Finance
API token generated separately for the test environment
Separate token for each ERP module or integration layer

One practical point worth flagging: the test environment is periodically updated to reflect schema amendments. If your IT team downloaded the FA(2) XSD file more than 60 days ago, re-download it before beginning tests. Schema drift is the single most common cause of validation failures in the first testing cycle.

How should you structure the four-stage testing procedure?

A disciplined four-stage approach reduces rework and keeps the project on a predictable timeline. Stage one covers schema validation. Stage two covers single-invoice transmission. Stage three covers batch and edge-case testing. Stage four covers reconciliation and sign-off. Each stage has a defined output – a go/no-go gate – before the next begins. Skipping a gate to save time is the most expensive shortcut available.

Stage one – schema validation (days 1–5). Run every invoice template your business uses through a local XML validator against the current FA(2) XSD. Do not submit to the sandbox yet. Fix structural errors offline. A typical mid-size distributor has between 8 and 15 distinct invoice templates (standard, corrective, advance, intra-EU, export). Each must pass local validation before transmission. This stage costs nothing beyond internal IT time.

Stage two – single-invoice transmission (days 6–12). Submit one invoice of each template type to the sandbox. Retrieve the XML error log. Common failures at this stage: incorrect sequence of the seller's NIP and buyer's NIP in the header block, missing mandatory field P_6 (invoice issue date in ISO 8601 format), and VAT rate codes that do not match the approved KSeF dictionary. Each failure requires a schema fix and a re-submission. Allow two business days per template for this iteration.

Stage three – batch and edge-case testing (days 13–22). Submit batches of 50–100 invoices covering edge cases: zero-VAT transactions, split-payment invoices, invoices issued to foreign buyers without a Polish NIP, and corrective invoices referencing a KSeF number from stage two. This stage reveals integration logic errors that single-invoice tests miss. We secured a correction of a critical batch-submission error for a manufacturing client in the Mazowieckie region (autumn 2025) – the root cause was a hardcoded timestamp format that failed only when invoices crossed midnight.

Stage four – reconciliation and sign-off (days 23–28). Compare the sandbox submission log against your ERP's outgoing invoice register. Every invoice in the ERP must have a corresponding sandbox reference number. Gaps indicate invoices that were generated internally but never transmitted – a silent failure mode. Your tax advisor should review the reconciliation report before sign-off. Budget PLN 3,000–8,000 for external tax advisory time at this stage, depending on the complexity of your VAT structure.

What are the most common KSeF integration errors – and how do you fix them?

Integration errors fall into three categories: schema errors, authentication errors, and business-logic errors. Schema errors are the easiest to fix. Authentication errors are the most time-consuming. Business-logic errors are the most dangerous because they may not surface until the production system rejects a live invoice, leaving a buyer without a valid tax document for up to 30 days.

Schema errors typically involve field encoding. The FA(2) schema requires UTF-8 encoding throughout. ERP systems configured for Windows-1250 encoding – still common in legacy Polish accounting software – produce malformed XML that the KSeF API rejects at the gateway level. The fix is a one-line encoding declaration change, but identifying the source requires tracing the invoice through every transformation layer between the ERP and the API call.

Authentication errors arise when the API token is generated under the wrong NIP. A company with a tax group (Polish tax law permits VAT groups since 2023) must generate separate tokens for the group's representative NIP and for each member entity. Confusion between group and member credentials accounts for a disproportionate share of authentication failures in the first testing cycle.

Business-logic errors are subtler. Three appear repeatedly in practice:

Corrective invoices that reference a KSeF number from a prior fiscal year – KSeF treats these as orphaned documents
Advance invoices where the settlement invoice does not carry the advance KSeF reference number
Split-payment invoices where the gross amount and the MPP flag are inconsistent

Each of these errors will cause a production rejection. The buyer receives nothing. Under Polish tax law, an invoice that has not been assigned a KSeF number is not a valid VAT document. The seller cannot deduct input VAT and the buyer cannot claim a deduction either. Personal liability of the board member responsible for tax compliance may arise if the failure is systemic and prolonged – a consequence that forfeits the company's right to input VAT deductions retroactively.

For companies with transfer pricing obligations, the KSeF number will eventually need to be cross-referenced against intercompany invoices in the Local File. Begin mapping that linkage now, even though the transfer pricing deadline is separate. Similarly, businesses using the IP Box preferential rate should confirm that R&D invoices carry the correct PKWiU classification codes in the FA(2) schema – a mismatch will not prevent KSeF acceptance but will create a reconciliation problem at year-end.

How do the three main business scenarios differ in testing complexity?

Testing complexity scales with the number of ERP modules, VAT registrations, and invoice types in use. Three scenarios illustrate the divergence clearly: a domestic manufacturing company, an IT services provider, and a foreign investor operating through a Polish subsidiary.

Manufacturing scenario. A mid-size manufacturer in Silesia typically issues standard sales invoices, corrective invoices, advance invoices for custom orders, and intra-EU supply invoices. The testing challenge is the advance-settlement chain: each advance invoice must be linked to a settlement invoice, and the KSeF number of the advance invoice must appear in the settlement document. Manufacturers using SAP or Microsoft Dynamics should verify that the standard KSeF connector handles this chain correctly – several connector versions released before Q3 2025 did not. Allow six weeks for testing. Budget PLN 15,000–25,000 for external integration support.

IT services scenario. An IT services company typically issues subscription invoices on a monthly cycle – sometimes thousands in a single batch run. The testing priority is batch throughput and error handling. If the API returns a partial-failure response (some invoices accepted, some rejected), the ERP must correctly identify and re-queue only the rejected invoices. A naive retry of the entire batch creates duplicate submissions, which KSeF flags as errors. Our team resolved a duplicate-submission loop for an IT client in Małopolska (winter 2025) – the fix required a custom deduplication layer between the ERP and the KSeF API wrapper.

Foreign investor scenario. A German investor operating a Polish subsidiary faces an additional layer: the parent company's invoicing system may generate invoices in a format that the Polish ERP then converts to FA(2). Each conversion step is a potential error source. The subsidiary's NIP must appear correctly in every invoice header. If the parent issues invoices in its own name on behalf of the subsidiary (a common treasury arrangement), the self-billing rules under Polish tax law require explicit KSeF configuration. For a broader view of what KSeF means for businesses operating across borders, see our analysis of what KSeF means for your business in the United States. Allow eight weeks for testing in this scenario. Budget EUR 5,000–10,000 for combined IT and tax advisory support.

Companies facing financial pressure during the integration period – for example, where the IT investment strains working capital – may find it useful to consider restructuring options in parallel. Our guide on simplified arrangement proceedings as the fastest restructuring path explains the options available under Polish insolvency law. Separately, businesses with cross-border structures should review their treaty positions; our note on the double tax treaty between Poland and Poland: key provisions addresses common misunderstandings in intra-group arrangements.

What should your KSeF readiness checklist include?

A readiness checklist serves two purposes. It gives the project team a shared definition of "done." It also provides documentary evidence of due diligence – relevant if the Polish Financial Supervision Authority (KNF) or KAS ever reviews your compliance timeline. The checklist below covers the minimum items for a mid-size business. Larger organisations should expand each item into a sub-checklist.

FA(2) XSD downloaded from the Ministry of Finance portal within the last 30 days and version number recorded
All invoice templates validated locally against the current schema before any sandbox submission
Batch reconciliation report showing 100% match between ERP invoice register and sandbox reference numbers
API tokens generated and stored securely for both test and production environments, with separate tokens per NIP
Error-handling procedure documented: who receives rejection alerts, response time target (recommended: 4 hours), and escalation path

The checklist should be signed off by both the IT lead and the tax advisor. A signature from the board member with tax compliance responsibility is advisable – it establishes that the board exercised oversight, which is relevant to the personal liability question under Polish corporate legislation if a systemic failure later occurs.

Timing matters acutely. The mandatory KSeF date for large taxpayers is 1 February 2026. For remaining taxpayers, the date is 1 April 2026. A company that begins testing in January 2026 for an April deadline has approximately 12 weeks – enough time if the four-stage procedure is followed without interruption. A company that begins in March has four weeks. That is survivable for a simple invoice profile. It is not survivable for a manufacturing or foreign-investor scenario.

One final point on costs. The Ministry of Finance provides the test environment free of charge. External costs – ERP connector licences, integration consultants, and tax advisory review – typically range from PLN 10,000 to PLN 50,000 depending on complexity. That figure is small relative to the penalty exposure: KAS may impose a fine of up to PLN 100 per invoice for systematic non-compliance, and the loss of input VAT deductibility on rejected invoices can easily exceed PLN 1m for a mid-size business in a single quarter.

Frequently asked questions

Q: Can we use the KSeF test environment to train our accounts payable team, or is it for IT testing only?

A: The test environment is available for any internal purpose, including staff training. Accounts payable teams benefit from practicing the retrieval and download of incoming invoices through the KSeF interface, since the process differs from the email-based workflow most teams currently use. There is no restriction on the number of users or submissions in the test environment, though documents are retained for only 14 days.

Q: How long does it take to obtain a KSeF API token, and what does it cost?

A: Generating an API token for the test environment takes between one and three business days once the qualified signature or Profil Zaufany is correctly linked to the company NIP. There is no fee for the token itself. The main delay is usually internal: confirming which legal entity NIP should be used, and ensuring the person generating the token has the correct authorisation level registered with KAS. For companies with multiple NIP numbers, each NIP requires a separate token generation process.

Q: Is it a common misconception that passing the test environment automatically means the production system will accept all invoices?

A: Yes – and it is an expensive one. The test environment validates schema and business logic, but it does not replicate production load, network latency under peak submission windows, or the behaviour of the production system when it receives invoices with a NIP that KAS flags for enhanced monitoring. A full test-environment pass reduces risk substantially. It does not eliminate it. Post-go-live monitoring for the first 30 days of production operation is essential, with a dedicated person reviewing the KSeF dashboard each morning for rejection flags.

To receive an expert assessment of your KSeF integration readiness, contact info@kordeckipartners.com.

Your company's specific invoice structure and ERP configuration will determine where the critical failure points lie. Identifying those points after the mandatory deadline – rather than before – precludes correction without penalty exposure and may trigger personal liability for the board member responsible for tax compliance.

If your business issues more than 500 invoices per month, operates across multiple VAT registrations, or relies on a legacy ERP system, the four-week minimum testing window is not a guideline – it is a floor. To discuss a tailored KSeF testing strategy for your organisation, email info@kordeckipartners.com.

About KORDECKI & Partners

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