A Warsaw-based technology company receives a notice from the National Revenue Administration (Krajowa Administracja Skarbowa, KAS) requesting its first JPK_CIT file. The finance director opens the accounting system and discovers that three years of transaction data are stored across four separate ledgers – none of them formatted to the statutory schema. Submission is due in 30 days.

JPK_CIT is Poland's structured audit file for corporate income tax, requiring companies to transmit their full accounting books in a machine-readable XML format defined by the Ministry of Finance. The obligation applies in phases: large taxpayers were first in scope, with mid-size and smaller entities following on a rolling timetable. Failure to submit a compliant file on time exposes the company to fiscal penal code sanctions and triggers an elevated audit risk that is difficult to reverse once flagged.

This service page walks your finance team through the full preparation cycle. We cover the regulatory framework, the data and system requirements, the most common errors that generate KAS queries, and the specific considerations that matter for foreign-owned subsidiaries and transfer-pricing groups. A self-assessment checklist closes the guide so your team can benchmark readiness before the deadline arrives.

What is JPK_CIT and who must file?

JPK_CIT – formally the Jednolity Plik Kontrolny dla podatku dochodowego od osób prawnych (Uniform Control File for Corporate Income Tax) – is an XML-based data transmission that replaces the traditional paper or PDF tax book. It requires companies to export their entire general ledger, subledger entries, and supporting transaction data in a schema prescribed by the Minister of Finance. The file is submitted electronically to the National Court Register's tax portal and cross-referenced automatically against the company's CIT return. Think of it as JPK_VAT's more demanding sibling: the volume of data is larger and the audit algorithms run deeper.

The rollout follows a three-wave schedule. Large taxpayers – those whose revenue exceeded EUR 50m in the prior fiscal year – entered scope first, for financial years beginning on or after 1 January 2025. The second wave covers all CIT taxpayers belonging to a tax capital group (podatkowa grupa kapitałowa, PGK), regardless of size. The third wave, bringing in remaining CIT payers, follows for fiscal years beginning on or after 1 January 2026. If your company's fiscal year does not align with the calendar year, the entry date shifts accordingly – a detail that mid-size subsidiaries of foreign groups frequently miss.

Three categories of entity are currently exempt: entities subject only to lump-sum corporate income tax, non-profit organisations whose income is entirely exempt, and entities whose net revenue in the prior year fell below a threshold set by regulation. Before relying on an exemption, verify the revenue figure against the statutory definition – gross revenue including VAT-exempt turnover can push an apparently small entity above the threshold. The Polish Financial Supervision Authority (Komisja Nadzoru Finansowego, KNF) supervised entities in the financial sector face additional data-quality expectations layered on top of the base JPK_CIT schema.

One practical point worth flagging early: the JPK_CIT file is not simply an export button. It is a structured representation of the accounting records as they exist on the filing date. If the records contain coding errors, missing cost-centre tags, or misclassified intercompany charges, those errors appear verbatim in the file – and KAS algorithms will flag them within days of submission.

What data does the file require, and how should your system be configured?

The JPK_CIT schema has two main components. The first, ZAL_1, covers the chart of accounts and the full general ledger – every debit and credit entry for the fiscal year, tagged with account codes, dates, document references, and counterparty identifiers. The second, ZAL_2, covers additional analytical data: fixed-asset registers, depreciation schedules, intercompany receivables and payables, and selected subledger details. Together they can run to several hundred thousand rows for a mid-size manufacturing operation. Preparing both components simultaneously, rather than sequentially, saves weeks of rework.

System configuration is the single biggest preparation task. Most ERP platforms – SAP, Microsoft Dynamics, Comarch ERP XL, and their equivalents – require a dedicated JPK_CIT export module or a custom XSLT transformation layer. The Ministry of Finance publishes the official XSD schema on its e-deklaracje portal; your IT team must validate every export against that schema before submission. A mismatch in a single field type – for example, a date formatted as DD/MM/YYYY instead of YYYY-MM-DD – will cause the entire file to be rejected at the gateway. Rejection is not a neutral event: the KAS timestamp records the failed attempt, and a late-filed corrected file still attracts scrutiny.

We secured a successful first-time JPK_CIT submission for a manufacturing client in the Mazowieckie region (spring 2025), after identifying that their legacy Comarch system was exporting account codes without the mandatory leading zeros. The fix took four days once diagnosed; without it, the submission would have failed validation entirely.

Four data-quality issues appear most frequently during our pre-submission reviews:

  • Missing NIP (tax identification number) for domestic counterparties on invoices above PLN 15,000
  • Intercompany transactions coded to generic trade-payable accounts rather than dedicated related-party accounts
  • Fixed-asset disposals recorded in the asset register but not mirrored in the general ledger
  • Foreign-currency transactions restated at the wrong exchange rate reference (NBP mid-rate vs. bank rate)

Each of these generates an automatic KAS query. Queries are not penalties – but they trigger a 14-day response window, and an unsatisfactory response escalates the matter to a formal audit proceeding. Cleaning the data before submission is always cheaper than explaining it afterwards.

For a tailored assessment of your system's JPK_CIT readiness, reach out to info@kordeckipartners.com.

Your finance team's preparation work also intersects with broader Polish tax law obligations. Transfer pricing documentation, for instance, must be consistent with the intercompany figures reported in ZAL_2. If the two sets of records diverge – even because of a legitimate year-end adjustment – KAS will ask why. We discuss that intersection in more detail in the section on cross-border considerations below.

What are the most common pitfalls that trigger KAS queries?

KAS uses automated matching algorithms that compare the JPK_CIT file against three external data sources: the company's own CIT return, the JPK_VAT files of the company's counterparties, and the National Court Register (Krajowy Rejestr Sądowy, KRS) for ownership and related-party data. Any inconsistency across these three sources flags the file for human review. The review team then has 90 days to issue a formal query or open a proceeding. Understanding the matching logic helps your team anticipate which entries will draw attention.

The most damaging pitfall is the intercompany mismatch. If your Polish subsidiary records a management fee payable to a German parent at EUR 500,000 but the parent's JPK equivalent (or its CbCR filing accessible to KAS via the OECD exchange framework) shows EUR 480,000, the discrepancy triggers a transfer-pricing query. The 30-day response window is tight for a cross-border matter. Aligning intercompany figures before year-end – not after the file is filed – is the only reliable mitigation.

A second common pitfall involves IP Box (ulga IP Box) claims. Companies claiming the 5% preferential CIT rate on qualifying intellectual property income must segregate that income in their accounting records throughout the year. If the JPK_CIT file shows a single blended revenue account with no IP-income subledger, the preferential rate claim in the CIT return will be questioned immediately. The IP Box rules under Polish tax law require contemporaneous record-keeping – not a year-end reconstruction.

A third pitfall affects entities that established a family foundation (fundacja rodzinna) during the year. Transfers from a CIT-paying operating company to the foundation must be coded correctly in the general ledger; incorrect coding can make a tax-exempt transfer appear as a taxable dividend. Since the family foundation regime entered force in May 2023, we have seen several cases where the accounting treatment was correct commercially but coded in a way that created a false positive in the JPK_CIT matching algorithm.

Our team obtained a withdrawal of a KAS audit notice for a logistics client in Lower Silesia (autumn 2025) by demonstrating that the apparent intercompany mismatch arose from a legitimate functional-currency restatement, fully documented in the transfer pricing master file. The matter was resolved within the 30-day response window, avoiding formal proceedings.

How should foreign-owned subsidiaries approach JPK_CIT?

Foreign-owned subsidiaries face a layer of complexity that purely domestic companies do not. The parent group's consolidation timeline, its intercompany pricing policies, and its chart-of-accounts structure are often designed for IFRS reporting – not for the granular Polish CIT account-coding requirements. Bridging that gap is the core preparation challenge for the finance teams of foreign-owned entities.

The first issue is the chart of accounts. Polish accounting law (the Accounting Act, ustawa o rachunkowości) requires companies to maintain books in Polish zloty and to use a chart of accounts that maps to Polish CIT categories. Many foreign subsidiaries run a parallel IFRS ledger for group reporting and a statutory Polish ledger for local purposes. The JPK_CIT file must reflect the statutory ledger – not the IFRS ledger. If the two ledgers have diverged over the year (for example, because of different lease-accounting treatments under IFRS 16 versus Polish GAAP), the divergence must be reconciled and documented before submission.

The double-tax treaty dimension adds another layer. A German parent receiving interest or royalties from its Polish subsidiary will rely on the double-tax treaty between Poland and Germany to apply a reduced withholding tax rate. The JPK_CIT file will show the gross payment and the tax withheld. If the withholding tax rate applied in the books differs from the rate shown in the WHT remittance certificate, KAS will query the discrepancy. Aligning the accounting entry, the WHT certificate, and the treaty claim is a three-document exercise that many subsidiaries leave until the last week before filing.

Warehouse and logistics operations present a specific variant of this problem. A foreign group running a Polish distribution hub will have significant intercompany flows – inbound stock purchases, outbound fulfilment fees, and shared-service recharges. Each of these must be coded in a way that is consistent with both the transfer pricing policy and the JPK_CIT schema. The treatment of warehouse and logistics contracts under Polish law affects how these flows are classified in the statutory ledger, and therefore how they appear in the JPK_CIT file.

For groups within scope of Pillar Two, the interaction between the global minimum tax top-up calculation and the JPK_CIT data is an emerging area. The effective tax rate computation required under Pillar Two draws on the same underlying accounting data that feeds the JPK_CIT file. Inconsistencies between the two sets of data – filed with different authorities on different timelines – are increasingly visible to tax administrations. Our Pillar Two guide for Polish subsidiaries covers the interaction in detail.

To receive an expert assessment of your subsidiary's JPK_CIT exposure, contact info@kordeckipartners.com.

What should your finance team do in the 90 days before the filing deadline?

Ninety days is a workable preparation window – if used systematically. The most common mistake is treating JPK_CIT preparation as an IT project rather than a finance and tax project. The system configuration matters, but the underlying data quality determines whether the file passes scrutiny. IT can build the export; only the finance team can fix the books.

A practical 90-day timeline breaks into three phases. In the first 30 days, conduct a full chart-of-accounts review. Map every account code to the JPK_CIT schema fields. Identify accounts that aggregate transactions which the schema requires to be reported separately – particularly related-party accounts, fixed-asset accounts, and IP-income accounts. This mapping exercise typically takes a senior accountant two to three weeks and is the foundation for everything that follows.

In the middle 30 days, run a test export against the official XSD schema. Validate the output using the Ministry of Finance's published validation tool. Fix structural errors first – date formats, field lengths, mandatory-field gaps. Then run a data-quality pass: check for missing NIP numbers, unmatched intercompany balances, and depreciation schedule discrepancies. Budget at least five business days for the data-quality pass in a company with more than 500 monthly transactions.

In the final 30 days, reconcile the test file against the draft CIT return. Every material figure in the CIT return – revenue, deductible costs, depreciation, intercompany charges – must trace to a corresponding set of entries in the JPK_CIT file. Gaps in that traceability are what KAS algorithms are designed to find. Complete the reconciliation in writing: a documented reconciliation memo is your first line of defence if a KAS query arrives after submission.

What to prepare – a self-assessment checklist:

  • Chart-of-accounts mapping to JPK_CIT schema fields completed and signed off by the tax advisor
  • ERP export module configured and tested against the official XSD schema
  • Related-party transactions identified, coded to dedicated accounts, and consistent with transfer pricing documentation
  • IP Box subledger maintained contemporaneously (if the preferential rate is claimed)
  • Draft CIT return reconciled line-by-line to the test JPK_CIT file before submission

Frequently asked questions

Q: Can a company submit a corrected JPK_CIT file after the original deadline without penalty?

A: Polish tax procedure allows voluntary correction of a submitted JPK_CIT file, and a correction submitted before KAS opens a formal proceeding generally eliminates the fiscal-penal-code exposure for the original error. However, the correction must be accompanied by a written explanation of the reason for the change. Corrections submitted after a KAS query has been issued are still possible but carry a higher risk of escalation, because the authority has already flagged the discrepancy. Filing a correct original is always preferable to relying on the correction mechanism.

Q: How does JPK_CIT interact with transfer pricing documentation deadlines?

A: The local transfer pricing file (dokumentacja lokalna) must be prepared by the end of the ninth month after the fiscal year-end – the same general window in which the JPK_CIT file is due. Both documents draw on the same underlying transaction data. Preparing them in parallel, rather than sequentially, reduces the risk of inconsistency between the intercompany figures reported in the JPK_CIT file and those described in the transfer pricing documentation. A mismatch between the two is one of the most reliable triggers for a KAS transfer pricing audit. Polish tax law requires that the local file be ready for submission within 14 days of a KAS request.

Q: Does a company using a tax advisor in Warsaw need to do anything differently for JPK_CIT compared to managing the process in-house?

A: Working with a tax advisor Warsaw does not change the company's formal obligations – the company remains the responsible taxpayer and the file is submitted under the management board's electronic signature. What changes is the allocation of preparation tasks. A well-structured engagement divides responsibility clearly: the finance team owns data quality and system configuration; the advisor owns schema compliance, reconciliation review, and KAS query response. Companies that blur this division – expecting the advisor to fix the data as well as review it – typically miss deadlines or submit files with unresolved errors. Clarify the division of responsibility in writing before the preparation cycle begins.

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 JPK_CIT compliance, KSeF Poland onboarding, and broader corporate tax advisory. We work with Polish entrepreneurs, foreign investors, and in-house legal teams navigating Polish tax law obligations. 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.