A chart of accounts, now with an external schema.
For most of its life the chart of accounts is an internal convenience. Someone designed it, it grew as the business did, and the only people who need to understand it work in finance. Poland has changed that for corporate income tax payers. Under the obligation known as JPK_CIT, a company keeps its accounting books electronically and files them to the tax authority as a structured data file after the year end. The largest companies filed their first books, the JPK_KR_PD structure, by 31 July 2026. The chart of accounts is no longer private. It is a reported object with a schema someone else defined.
That sounds heavy, and the useful surprise is how narrow the first year actually is. The regulation phases the new data in. For the first covered year it lets a first wave company leave out four of the five new data elements, so the only new content most of them had to add was an identifier, a marker, on each account in the chart of accounts, drawn from a dictionary the Ministry of Finance publishes. Companies reporting under International Financial Reporting Standards were allowed to leave out even that for the first year. So for year one, the whole of the new obligation for most first wave filers reduces to one question asked of every account: which marker does it carry.
Read that way, this is not a tax project. It is a master data project wearing a tax deadline. The account to marker mapping is a property of the chart of accounts, set once, owned by someone, and kept current as accounts are opened and closed. A company that builds it as master data files the structure as a query and barely notices the deadline. A company that rebuilds it inside a reporting tool every year pays for it every year and never quite trusts the result. The constructive point is that the master data version is both cheaper and better, and the work leaves behind a cleaner, better documented ledger that helps well beyond this one filing.
The rest of this piece lays out the timetable so you can place yourself on it, walks through exactly what the file asks for and why year one is so contained, and then gets concrete about the one artefact worth building: a governed account to marker mapping, with a fixed asset register complete enough to answer the second structure. None of it is exotic. It is ordinary master data discipline, applied to a place most teams never had to govern before.
Where you are on the timetable.
The obligation was created by the Act of 29 October 2021, which added article 9(1c) and 9(1e) to the CIT Act. From 1 January 2025 those provisions require accounting books to be kept using computer programs and sent to the tax office after the year end, in a form corresponding to the JPK logical structure, by the deadline for the annual CIT return. The detail of what to add was set by the Regulation of the Minister of Finance of 16 August 2024, published in the Journal of Laws as Dz. U. 2024 poz. 1314, which came into force on the same date. The obligation does not land on everyone at once. It arrives in three waves.
| Who is in the wave | From which tax year | What it means |
|---|---|---|
| Largest taxpayers | Tax years starting after 31 December 2024 | CIT payers whose prior year revenue exceeded EUR 50 million, and tax capital groups regardless of revenue. First JPK_KR_PD for a calendar 2025 year was due 31 July 2026 after the extension. |
| VAT monthly filers | Tax years starting after 31 December 2025 | The remaining CIT payers who are obliged to submit the monthly JPK_VAT return. These entities keep their books in the structure through 2026 and file for the first time in 2027. |
| Everyone else | Tax years starting after 31 December 2026 | All other CIT payers keeping accounting books, the largest population by count. They are scoping and mapping now for a first structured year that begins in 2027. |
The deadline itself has moved, which is worth knowing so you plan to the data rather than to the date. The original rule tied the JPK_KR_PD submission to the annual CIT return, at the end of the third month after the year end, which for a calendar 2025 year would have been 31 March 2026. A regulation in early 2026 extended it to the end of the seventh month after the year end, moving the first filing to 31 July 2026. Treat the seventh month as a buffer, not the plan. If the master data is ready by the ordinary return date, a shorter window in a future year is a non event.
One more piece of sequencing matters. The second structure, JPK_ST_KR for fixed assets, was deferred by a year for the first wave by a regulation of 13 December 2024, so it begins one year behind the books. That gap is a gift: it lets a first wave company get the account mapping right in year one and turn to the fixed asset register data in year two, rather than standing both up at once.
What the file actually asks for.
The regulation lists five additional data elements the books have to carry. Reading them in order shows where the work sits, and reading the first year phasing next to them shows why the account markers are the place to start. Four of these five were switched off for the first covered year for first wave filers, which is the on ramp the timetable builds in.
| The data element | Where it sits | What it means for the data |
|---|---|---|
| Counterparty tax identifier | Paragraph 2(1) | The tax identification number of the taxpayer counterparty, where one has been assigned, recorded against the individual events booked. A field the ledger often holds on the master record but not on the transaction line. |
| KSeF invoice number | Paragraph 2(2) | The number identifying an invoice in the National e-Invoice System, where assigned by the date the books are filed, for invoices the taxpayer issued that are accounting evidence. It links the ledger entry to the cleared e-invoice. |
| Account markers | Paragraph 2(3) | An identifier for each ledger account, shown according to the Ministry dictionary of account identification markers. Annex 7 holds the dictionary for entities that are not banks, insurers, investment funds, brokerages, credit unions or public benefit organisations. This is the master data task. |
| Fixed asset events | Paragraph 2(4) | Data confirming the acquisition, creation or removal of a fixed asset or intangible from the register: the document number and type it was taken into use under, the relevant dates, the entity inventory number, and the KSeF number of any disposal invoice. This feeds the separate JPK_ST_KR structure. |
| Book to tax differences | Paragraph 2(5) | The difference between the accounting result and the CIT tax base, split into eight named categories of exempt, non taxable and non deductible amounts and timing differences. The permanent tax character of an account is where this meets the markers above. |
The line that changes how you read the rest is the phasing. Paragraph 5 of the regulation lets the books for a tax year that starts after 31 December 2024 and before 1 January 2026 omit the counterparty identifier, the KSeF number, the fixed asset data and the book to tax differences, which leaves only the account markers. For a company that reports under IFRS, even the markers could be left out for that first year. So the standard, in its first year, deliberately narrows to one thing for most filers. That is not an accident of drafting. It is the regulator handing you a year to get the chart of accounts mapped before the fuller data arrives.
The account markers, read as master data.
The marker requirement is simple to state and easy to underrate. Every account in the chart of accounts has to be shown with an identifier from a dictionary the Ministry publishes. There is a dictionary for banks, one for insurers, one for public benefit organisations, one for investment funds, one for brokerage houses, one for cooperative savings and credit unions, and one for everyone else in Annex 7. For an ordinary company, Annex 7 is the schema its chart of accounts now has to speak.
The regulation is specific about how the marker is chosen, and the specificity is what makes this master data rather than guesswork. Paragraph 2(3) says the markers are assigned on the basis of the classification criteria already used to record events in the books, criteria that come from accounting law. In other words, you do not invent the mapping alongside the ledger. You derive it from how the ledger already classifies things. That is the difference between a map you can defend to an auditor and a set of choices held in one person memory that nobody can reproduce next year.
Once you see it as a mapping derived from the ledger and attached to the account master, the whole shape of the solution follows. The marker becomes an attribute of the account definition, so every posting inherits it and the file assembles itself. A new account cannot go live without one. The map is owned, versioned, and re-checked when the dictionary changes. And completeness stops being a hope and becomes a single query: any account with activity and no marker. Here is that mapping expressed as data, so the shape is concrete.
An account to marker mapping, expressed as governed data
# Chart of accounts to JPK_KR_PD marker mapping
# One governed table, owned and versioned. Codes are placeholders for shape, not the official values.
account_marker_map:
dictionary: "MF account identification markers, Annex 7, other entities"
legal_basis: "Dz. U. 2024 poz. 1314, paragraph 2(3)"
owner: "coa.steward@entity"
version: 2026.1
effective_from: 2025-01-01
rule: >
A marker is assigned from the accounting classification already
used to record the event, per paragraph 2(3). The map is derived
from how the books work, not invented alongside them.
accounts:
- gl_account: "401-01"
name: "Raw materials consumed"
accounting_class: "operating cost by nature"
marker: "COST_DEDUCTIBLE" # placeholder family
tax_character: "deductible"
status: confirmed
last_reviewed: 2026-02-14
- gl_account: "409-11"
name: "Representation expense"
accounting_class: "operating cost by nature"
marker: "COST_NON_DEDUCTIBLE_PERM" # permanent difference, paragraph 2(5)
tax_character: "never deductible"
status: confirmed
- gl_account: "760-03"
name: "Grant recognised in income"
accounting_class: "other operating income"
marker: "INCOME_EXEMPT"
tax_character: "exempt"
status: confirmed
unmapped:
- gl_account: "245-90"
name: "Suspense, to be cleared"
marker: null
status: blocked # no clean file until this is resolved
change_control:
new_account_requires: "marker assigned and reviewed before first posting"
dictionary_update: "re-map on any Ministry revision, keep prior versions"The two blocks at the end are the ones that keep it honest. The unmapped list is the control: while it holds any account with activity, the file is not ready, and you know exactly what to fix. The change control block is what stops the map drifting away from the ledger, by making a marker a required field the moment an account is opened and forcing a re-map when the Ministry revises the dictionary. Neither is elaborate. Together they are the difference between master data that stays true and a spreadsheet that slowly stops describing reality.
An implementation checklist.
- 1.Name an owner for the chart of accounts as master data. The account to marker mapping is not a year end task that a tax team improvises. It is a standing attribute of every account, so it needs a steward who signs off new accounts and reviews the map when the dictionary changes. Put the name on the record, not on a person who happens to be free in July.
- 2.Build the mapping table once and derive it from how the books already work. The rule says the marker follows the accounting classification used to record the event. Start from your existing account structure and the way postings are classified, map each account to the dictionary entry that matches, and store the basis for the choice. A mapping derived from the ledger is defensible; one invented beside it drifts.
- 3.Drive the marker from a master record, not a manual tag at close. If the marker lives on the account definition, every posting inherits it and the file assembles itself. If it is applied by hand each period, two periods will disagree and the reconciliation becomes the job. Master data set once beats a monthly tagging exercise every time.
- 4.Treat the fixed asset register as the source for JPK_ST_KR, and check it is complete at the item level. The structure asks for the document and date an asset was taken into use, the entity inventory number, and the events that remove it. Assets entered before 1 January 2025 are grandfathered except for disposals, but everything after needs those fields present per asset. A register that is complete in total but thin per item cannot answer it.
- 5.Use the first year phasing as room to build, not room to wait. In the first covered year the rules let a first wave filer leave out four of the five data elements, so the only new content is the account markers, and IFRS preparers were given a further reprieve on even those. That is a deliberate on ramp. Spend it standing up the mapping and the ownership, so the year the other elements switch on is a data year, not a scramble.
- 6.Keep the book to tax difference categories connected to the markers. The eight categories in paragraph 2(5) describe the permanent and timing character of amounts, and the account markers already carry much of that character. Design the two together so the permanent non deductible account and its difference category tell one consistent story rather than two that have to be reconciled.
- 7.Version the mapping and the dictionary it points at. The Ministry can revise the dictionary, and your chart of accounts changes as the business does. Hold the map under change control, keep prior versions, and record which version produced which filing, so a question about a past file has an answer that does not depend on memory.
- 8.Prove the file is complete before it is due, with an unmapped account report. The single most useful control is a query that lists any account with a posting and no marker. If that list is empty, the master data is complete. If it is not, you know exactly what to fix, weeks before the deadline rather than the night before it.
Failure modes, framed so you can avoid them.
- Treating the marker as a tax export step instead of master data. If the account to marker mapping is rebuilt inside a reporting tool each filing season, it is expensive, inconsistent, and invisible to the people who add new accounts. The mapping belongs on the account master, where it is set once and inherited by every posting, and where a new account cannot go live without it.
- Mapping by memory rather than from the accounting classification. The rule ties the marker to the classification already used to record events. A team that assigns markers from intuition, account by account, will not be able to defend the map or reproduce it. Derive it from the ledger structure and store the reasoning, so the same inputs always give the same map.
- Leaving the fixed asset register complete only in total. The JPK_ST_KR structure is per asset. It asks for the document an asset was taken into use under, the dates, and the inventory number. A register that reconciles in aggregate but is missing those fields on individual items looks fine until the structure is generated and half the assets have blanks.
- Reading the first year relief as permission to defer the whole thing. The phasing removes four data elements in year one, not the obligation. Companies that hear relief and stop will find the account markers still due, and will meet the other four elements with no groundwork the year they switch on. The relief is time to build, and it is easy to waste.
- Letting the chart of accounts and the mapping drift apart. New accounts get opened, old ones fall out of use, and if the map is a static spreadsheet it slowly stops describing the ledger. Without change control at the point an account is created, the file quietly develops gaps that only surface at generation time.
- Keeping two stories for tax character. The account markers and the book to tax difference categories both encode whether an amount is deductible, exempt or a timing item. If they are designed separately they will disagree, and the disagreement becomes a reconciliation nobody owns. Designed together, they are one description of the same fact.
- Assuming the deadline that applied this year is the permanent one. The end of the seventh month after the year end came from an extension, and the timetable has moved more than once. Build to the data being ready by the ordinary return date, so a shorter window in a later year is not a crisis, and treat any extra months as a buffer rather than the plan.
- Waiting for the last wave because it is furthest away. The largest population files first for tax years starting after 31 December 2026, which feels distant, but the mapping and the register cleanup take longer than a filing. The entities with the most accounts and the least central master data are exactly the ones that benefit from starting while there is time.
What this asks of the data model.
- The unit of the mapping is the account, and the marker is an attribute of the account master. The whole design rests on the marker being a property of the account definition, inherited by every posting, rather than a label applied to a transaction after the fact. That is what makes the file a query and not a project.
- The marker is derived, and the derivation is data too. Paragraph 2(3) ties the marker to the accounting classification used to record events. Storing the classification and the resulting marker together, with the basis for the map, turns the mapping into something reproducible and auditable rather than a set of choices held in one person head.
- The chart of accounts needs change control at the point of creation. A new account without a marker is a future gap in the file. The cheapest place to close it is the workflow that opens the account, where the marker is a required field before the first posting rather than a cleanup task later.
- The fixed asset register carries per item evidence, not just balances. JPK_ST_KR asks for the document and date an asset was put into use, the inventory number, and the events that remove it. The register has to hold those at the level of the individual asset, which many registers built for depreciation totals do not.
- The book to tax difference categories share character with the markers. The eight categories describe permanent and timing differences. Modelling them next to the account markers, so the permanent non deductible account and its difference category are one definition, avoids maintaining two overlapping descriptions of the same tax character.
- Counterparty identifiers and KSeF numbers live at the event, not only the master. Two of the five elements attach to individual booked events. If the ledger keeps the counterparty tax number only on the vendor or customer master, the structure needs it stamped onto the entry, which is a small change to how postings carry reference data.
- The map is versioned, and each filing records the version it used. The dictionary can change and the chart of accounts evolves. A file generated last year should be explainable by the map that was in force then, which means keeping prior versions and recording which one produced which submission.
- Completeness is a testable property, not a hope. Because the marker is master data, completeness is a single query: any account with activity and no marker. That query is the control that tells you the master data is ready, and it can run continuously rather than once at the deadline.
The audit evidence to keep.
- The account to marker mapping in force for the period, showing each account, its assigned marker, the accounting classification it was derived from, and the person who confirmed it.
- The version history of the mapping and of the Ministry dictionary it references, with the version that produced each filed structure recorded against that filing.
- The unmapped account report as at generation, ideally empty, evidencing that every account with activity in the period carried a marker before the file was produced.
- The change control record for new accounts opened in the period, showing that a marker was assigned and reviewed before the account was posted to.
- The fixed asset register extract behind JPK_ST_KR, with the put into use document and date, the inventory number, and any removal events, at the level of the individual asset.
- The reconciliation between the account markers and the eight book to tax difference categories, showing that the permanent and timing character is described consistently in both.
- The event level evidence for the counterparty tax identifier and the KSeF invoice number, showing how each was carried onto the booked entry rather than held only on a master record.
- The submission log for JPK_KR_PD and JPK_ST_KR, with the filing dates against the applicable deadline for the wave and year, so timeliness is demonstrable.
Questions worth asking in your own review.
- Is the account marker an attribute of our chart of accounts master, or something a reporting tool would apply at filing time?
- Could we produce, today, a report of every account with activity and no assigned marker for the period?
- When someone opens a new general ledger account, is a marker a required field before the first posting, or a later cleanup?
- Does our fixed asset register hold the put into use document, the inventory number and the removal events at the level of each asset, not just in total?
- Are our account markers and our book to tax difference categories one connected model, or two overlapping descriptions of the same tax character?
- Do our booked entries carry the counterparty tax identifier and, where relevant, the KSeF invoice number, or do those live only on the master records?
- Who owns the account to marker mapping, and is that ownership named, or does it fall to whoever is free at the deadline?
- If the Ministry revised the dictionary, could we re-map, keep the prior version, and still explain a file we submitted last year?
What this adds up to.
Poland has made the chart of accounts a thing you file, and in doing so it has quietly made the case for governing it. The obligation is real and the deadlines are moving through the waves, but the response that works is not a tax scramble. It is the same master data discipline you would want anyway: one owned mapping from your accounts to a defined dictionary, derived from how the books already classify events, kept current as the ledger changes, and provable complete with a single query.
The timetable even hands you the room to do it properly. The first year narrows to the account markers for most filers, the fixed asset structure comes a year later, and the deadline sits seven months out. That is enough time to build the mapping once, name its owner, wire the marker into the workflow that opens accounts, and get the fixed asset register complete at the item level before its structure switches on. Do that and each filing is a report, not a rebuild.
If there is one place to start, run the unmapped account query against your own ledger and see what comes back. If it is short, you are closer than you think. If it is long, that list is your project, and it is a good one to take on now, because the payoff arrives twice: a clean structured file when it is due, and a chart of accounts that finally has an owner, a schema and a documented reason for every line.
Sources.
- Rozporzadzenie Ministra Finansow z dnia 16 sierpnia 2024 r. w sprawie dodatkowych danych, o ktore nalezy uzupelnic prowadzone ksiegi rachunkowe podlegajace przekazaniu na podstawie ustawy o podatku dochodowym od osob prawnych (Dz. U. 2024 poz. 1314). The primary regulation, downloaded as a PDF and read directly rather than through a summariser. Source for the legal basis in art. 9 ust. 5 pkt 1 of the CIT Act, the five additional data elements in paragraph 2, the dictionary of account identification markers with the dictionary for other entities in Annex 7, the fixed asset and intangible register fields, the first year phasing in paragraph 5, and the entry into force on 1 January 2025
- Ustawa z dnia 29 pazdziernika 2021 r. o zmianie ustawy o podatku dochodowym od osob fizycznych, ustawy o podatku dochodowym od osob prawnych oraz niektorych innych ustaw (Dz. U. 2021 poz. 2105). The amending act that added art. 9 ust. 1c and 1e to the CIT Act, requiring accounting books to be kept with computer programs and submitted after the tax year end in a form corresponding to the JPK logical structure
- Ministerstwo Finansow and Krajowa Administracja Skarbowa, JPK_PD information pages on podatki.gov.pl. The tax administration guidance on who is covered, the JPK_KR_PD and JPK_ST_KR logical structures, and the account marker mechanism
- PwC, Poland Corporate Tax administration summary, 2026. A near primary practitioner reference used to confirm the three implementation waves and their effective tax years, the original submission deadline aligned to the CIT return, and the deferral of the JPK_ST_KR fixed asset structure
- Accace, JPK CIT in Poland: obligations, deadlines and how to prepare. A practitioner guide used to cross check the JPK_KR_PD data content, including the counterparty tax identification number, the KSeF invoice number, the account markers, the fixed asset data and the accounting to tax result differences
- ALTO, JPK_CIT in 2026: deadlines, JPK_KR_PD structure and new obligations. A practitioner guide used to confirm the extension of the submission deadline to the end of the seventh month after the year end for the first wave, the one year deferral of JPK_ST_KR by the regulation of 13 December 2024, and the further reprieve for IFRS preparers on the account markers
- ISAP, Rozporzadzenie Ministra Finansow z dnia 16 sierpnia 2024 r. document record (Dz. U. 2024 poz. 1314). The official legislative register entry for the regulation and its seven annex dictionaries of account identification markers
The five data elements, the dictionary of account markers with the dictionary for other entities in Annex 7, the rule that a marker follows the accounting classification used to record events, the fixed asset register fields, the grandfathering of assets entered before 1 January 2025, and the first year phasing that leaves only the markers were all read directly from the primary regulation, the Rozporzadzenie of 16 August 2024, Dz. U. 2024 poz. 1314, downloaded as a PDF and read rather than summarised. The three waves, the original and extended submission deadlines, the one year deferral of JPK_ST_KR, and the further reprieve for IFRS preparers were confirmed against the PwC, Accace and ALTO practitioner guides and the Ministry of Finance JPK_PD pages, and no fact here rests on a single secondary source alone. No embedded posts from X appear in this article, because no public post on the JPK_CIT rollout could be verified as current, relevant and authentic at the time of writing, and an unverified embed is worse than none. Nothing here is accounting, legal or tax advice for a specific company. The treatment of any particular entity depends on its facts, its reporting framework and the regulations as applied by the Polish tax authority, and the timetable and deadlines have already changed more than once.