JPK_CIT 2026: the end of "the books are our business" — what changes and how to get ready

What actually changes

Until now, your accounting books were the company's private kitchen. The tax office saw the result: the CIT return, the declarations, a JPK file on request. Exactly how each operation was booked — which account, what description, on which source document — stayed inside the company until an audit came along and asked for an extract.

JPK_CIT flips that logic. Now the company itself, once a year, sends the authority the whole ledger in a machine-readable format — with accounts tagged against a standard, tax markers on every relevant line, identified counterparties, and a separate register of fixed assets. Not the result. Not a sample. The ledger.

What this means in practice for the accounting team:

• The chart of accounts must be mapped to the standard layout the structure expects — "for us that's account 731-2" no longer cuts it.
• Every entry with tax significance must carry the right tax marker (e.g. non-deductible cost, exempt revenue).
• Counterparties must be identified with verifiable data — a NIP in a single consistent format, not "Kowalski Trading Co."
• Fixed assets and intangibles go in a separate JPK_ST_KR structure — with dates, values, depreciation.
• The data must reconcile with what you already sent in JPK_VAT and what went through KSeF.

What JPK_CIT is: two structures, one obligation

"JPK_CIT" is the informal name for an obligation that in practice consists of two separate logical structures. Worth separating them right away, because confusing the two is the first source of chaos during rollout.

The obligation was introduced by an amendment to the Polish CIT Act — books are to be kept using software and submitted to the tax authorities in a structured form. "JPK_CIT" is convenient in conversation, but in technical documentation always work with the structure names: they define which fields, and in which format, your system must generate.

Timeline: who and from when

The obligation phases in depending on your tax year and which group of taxpayers you belong to. The key wording is "for a tax year starting after" a given date — don't confuse it with the calendar year of the submission.

In other words: if you're a large taxpayer or operate within a tax capital group, the obligation already applies to you for the year that started in 2025. Mid-sized companies filing JPK_VAT join a year later. Everyone else, a year after that. But note: preparation starts long before the first submission, because the books must be kept in the new structure from day one of the year in scope.

Deadline: when the first submission is due

Unlike JPK_VAT (monthly), JPK_CIT is submitted once a year — together with the annual CIT return. The deadline is the end of the third month after the tax year ends.

For a company whose tax year matches the calendar year, that usually means the end of March the following year. If your year is shifted (say, 1 July to 30 June), you count three months from your own closing date. The submission itself is a formality — the challenge is that the books, throughout the year, are kept in a way you can generate as JPK_KR_PD and JPK_ST_KR in a single move.

What the books must contain

This is the section that decides success. The structure requires data that many companies don't record in the required form today:

Accounts tagged against the standard

Your company chart of accounts must be mapped to the layout the structure expects. This doesn't mean abandoning your own numbering — but every account needs an assigned counterpart in the standard. The most common trap: "legacy" accounts, in use for years, that nobody can cleanly classify anymore.

Tax markers

Entries with tax significance must carry the right marker — e.g. a non-deductible cost, exempt revenue, temporary differences. It's information the accounting team already knows "in their head," but it has to reach the entry in a machine-readable way. Without it, JPK_KR_PD is incomplete.

Counterparty identification

The counterparty in an entry must be identified with verifiable data — above all a NIP in a consistent format. "Shop on the corner," "Advance — Kowalski," "Various" — such descriptions pass in internal bookkeeping, but in the structure they're a signal of trouble.

Fixed assets and intangibles (JPK_ST_KR)

A separate structure with data on the fixed-asset base: initial value, date put into use, depreciation method and rate, value adjustments, disposals. Many companies keep the fixed-asset register in a separate module or spreadsheet that isn't tied to the general ledger. That's the first candidate for a mismatch.

Ties to KSeF and JPK_VAT: consistency or an audit

JPK_CIT doesn't live in isolation. It's the third piece of the puzzle alongside JPK_VAT and KSeF — and the tax office receives all three and can cross-check them.

• Revenue in the books vs sales in JPK_VAT. If revenue reported in JPK_KR_PD doesn't match the sales reported in JPK_VAT (after adjusting for VAT/CIT differences), that's a ready-made reason for questions.
• A booked invoice vs its KSeF counterpart. Once a sales or purchase invoice passes through KSeF, it has an identifier. The entry in the books that relates to that invoice should be traceable back to it. A gap here is the cleanest possible audit signal.
• Corrections. A correction invoice changes the VAT, the CIT base, and the book entry. If you correct these three layers inconsistently or in different periods, the data drifts apart — and an audit spots the difference immediately.

7 places where it goes sideways

1. Account mapping done "just barely." The standard was assigned only to accounts active in the current year. Old accounts, technical accounts, accrual accounts — skipped. It surfaces on the first unusual operation.
2. No markers along the way. The accounting team knows the tax classification "from memory" but doesn't record it at booking time. At year-end you have to tag thousands of entries by hand — or guess.
3. Fixed-asset register outside the ledger. Fixed assets kept in a separate spreadsheet/module, never reconciled to the general ledger. JPK_ST_KR reveals a gap no one had seen before.
4. Counterparties with no NIP or with "NIPs in various formats." No separators in the ERP, dashes in the CRM, a PL prefix in the ledger of receivables. To an audit it looks like three different counterparties.
5. Drift from JPK_VAT. CIT revenue and VAT sales computed independently, with no reconciliation of the differences. Cross-checking the files exposes the gap.
6. Corrections in different periods. A VAT correction booked in a different month than the CIT correction. It may be formally correct — but it needs a clear trail explaining why.
7. No process owner. Accounting owns the entries, IT owns the submission, the tax advisor owns the markers. When the file doesn't reconcile, nobody knows whose problem it is.

6 of the 7 traps aren't technical. They're data and process. Generating the XML is easy. The hard part is making the data inside that XML consistent, complete, and aligned with the other reports.

Preparation checklist

Tools: off-the-shelf vs open-source

Most accounting systems on the Polish market are adding or announcing a JPK_CIT module. If you don't have a dev team, that's the simplest path. If you do, an open-source layer gives flexibility where the packaged modules go quiet: consistency checks, reconciliation across JPK_CIT / JPK_VAT / KSeF, exception handling. Check scope and maturity directly with vendors — JPK_CIT support is still maturing.

Conclusion: what to do now

JPK_CIT is a data project, not "a new file to send." Companies that treat it as a year-end formality will discover, in the first quarter, that the whole previous year has to be tidied up in the books, retroactively. Those who put the books in order in advance send JPK_KR_PD in a single move.

Three things worth doing this month:

1. Pin down your wave and start date. Check from which tax year you must keep the books in the structure — it's often earlier than you think, because it's the start of the year that counts, not the submission deadline.
2. Audit the source data. Account mapping, tax markers, counterparty NIP format, consistency between the fixed-asset register and the ledger. That's 80% of the work — and what decides whether the file reconciles.
3. Cross-check with JPK_VAT. Generate a working JPK_KR_PD and compare it with JPK_VAT for the same period. Every difference you find now is a difference the tax office won't.

FAQ

What is JPK_CIT?

It's the obligation to keep accounting books using software and submit them to the tax authorities in a structured format. It consists of two structures: JPK_KR_PD (books with tax data) and JPK_ST_KR (fixed assets and intangibles). The obligation was introduced by an amendment to the Polish CIT Act.

When does it start and who is affected first?

Phased. For a tax year starting after 31 Dec 2024 — the largest CIT payers (revenue >EUR 50M) and tax capital groups. For a year after 31 Dec 2025 — other CIT payers who file JPK_VAT. For a year after 31 Dec 2026 — the remaining CIT payers.

When is it submitted for the first time?

Once a year, together with the annual CIT return — by the end of the third month after the tax year ends. For a year matching the calendar year, that's usually the end of March. But the books must be kept in the structure throughout the year, not only assembled at submission time.

How does JPK_CIT connect to KSeF and JPK_VAT?

The book data must be consistent with JPK_VAT and with invoices from KSeF. A mismatch between revenue in the books and sales in JPK_VAT, or between a booked invoice and its KSeF counterpart, is the most common trigger for an audit. Cleaning up the source data before the first submission is essential.

Official sources

• JPK_CIT on podatki.gov.pl — official portal
• Polish Ministry of Finance — gov.pl
• Standard Audit File (JPK) — general information

Quick feedback

Related posts