The data contract

Exactly what we need in order to build the file

This is the whole specification, with no form in front of it. An IT manager or the person who files these can judge in fifteen minutes whether the system your Polish entity runs can produce it — and do that without speaking to us.

One rule matters more than the rest of this page: we need the data the system already holds. We do not ask anyone to change how they post, to restructure a chart of accounts, or to move a period close. Where something is not in the data, that is information about scope, not a request to repost anything.

On the quoted statements. Every statutory date, threshold and schema version below is quoted in Polish, as published by the source, with a link to that source and the date a person last opened it. Translating a statute quote would make it a paraphrase, which is the thing this ledger exists to prevent.JPK is the Polish statutory reporting file;UPO is the official confirmation that a filing was accepted.

How you can hand it over

Whoever holds the data picks the form, not us. Each option below is an equally good start; they differ only in how much work is left on your IT team's side at the next period.

Files: CSV, XLS, XLSX

The usual starting point and entirely sufficient for a first round. One file per dataset, headers in the first row, column names of your choosing.

XML

If your system already produces something — a partial structure, or an export on its own schema — we take what exists and map the remainder.

A database view

The calmest arrangement in the long run: one read-only view, prepared once. The next period then depends on nobody's memory and nobody's click.

The transport channel is a separate decision: SQL, an API, storage, an SFTP directory, or an agent running inside your network. It depends on what your IT function is willing to open and it does not change the scope of data on this page.

Character encoding, separators, date formats, decimal marks, how the debit and credit side are expressed, the sign convention on reversals — that is the translator's job. It is precisely the work we do not want to push onto an accounting team, which is why it is not in the requirements.

Read access is all that is needed. SimplyTax writes nothing back into your system.

How the extraction itself works, step by step →

JPK_KR_PD — books and tax reconciliation

Five datasets. The first four come out of the finance system and are available immediately in most implementations. The fifth almost never is, and it is the one that decides how long preparation takes.

The current value of the wersjaSchemy attribute for the JPK_KR_PD(1) structure is 1-1 (changed from 1-0).

It is the value of the wersjaSchemy attribute that changed; the edition of the structure itself is unchanged.

Verified 6 August 2026 · Ministerstwo Finansów, Aktualizacja broszury informacyjnej JPK_KR_PD(1) – aktualna od 01.07.2026 r., sekcja B
The Polish text of the linked source is authoritative.

Datasets required to build a JPK_KR_PD file: what each one is, which fields matter, and why it is usually incomplete.
Dataset	What it is	Fields that matter	Why it is usually incomplete
Trial balance	The account list with opening balances, movements for the period and closing balances — the same report you print at year end.	account number and name parent account · analytical level account type (balance sheet / P&L) opening balance, debit and credit period movements, debit and credit closing balance, debit and credit tag assigned to the account	The export is usually flat, with no link between an analytical account and its synthetic parent — recoverable from the account number or a lookup table. The harder and more common gap is the mapping of accounts to the tags the structure requires: no accounting system holds it, because it is a reporting concept rather than a bookkeeping one. It is done once, against the chart of accounts.
Journal	The chronological record of the period, numbered so that an entry can be tied back to its source document.	sequence number document number and type transaction date document date posting date description amount	The three dates are frequently one field in the system — normally the posting date, copied into the other two. After a migration from a previous system the journal numbering often restarts mid-year, so the sequence has to be rebuilt from the documents.
Postings	The debit and credit side of every entry, attached to an account in the trial balance and to a line in the journal.	entry identifier debit account · credit account amount in PLN currency and foreign-currency amount counterparty identifier link to the journal line	For foreign-currency transactions the system often hands over the converted amount only. The original-currency amount then sits in the receivables module and has to be pulled separately, by entry identifier — assuming that identifier is shared between the two modules.
Counterparties	The parties appearing in the entries, on both the purchase and the sales side.	name NIP (Polish tax identification number) country code address identifier used in the entries	The NIP lives in the master data, and the entry points at that master record through an identifier that, years later, is sometimes empty or resolves to a record merged with another. One-off counterparties get posted with no master record at all, described in free text — those entries cannot be matched automatically, and it shows on the first extract.
Permanent and temporary differences	The tagging of amounts that create a difference between the statutory result and the taxable result — the input for the tax-reconciliation part of the file.	difference attached to an account or to an entry amount of the difference category: permanent / temporary	The most frequently missing dataset in this table. In many companies the differences are computed once a year in a spreadsheet outside the system, so they are not in the books at all and there is nothing to export. Which item is a permanent difference and which is temporary is decided by your tax adviser — we do not determine it and do not suggest it; we carry over the tagging you give us.

The field names in the table are descriptive; they are not schema element names. The binding scope of the structure is set by the Ministry of Finance's schema and its accompanying brochure, which every fact on this page links to.

JPK_ST_KR — the fixed asset register

In manufacturing this structure, not the ledger, is the bottleneck. The books can be extracted in a week because they are complete by definition; a fixed asset register is complete only after somebody has walked it line by line. What is not in it cannot be reconstructed from memory after the fact.

The first year for which first-wave CIT taxpayers actually submit JPK_ST_KR is the tax year beginning on 1 January 2026 or later — for a calendar year, that is 2026.

Verified 6 August 2026 · Ministerstwo Finansów, Aktualizacja broszury informacyjnej JPK_ST_KR(1) – aktualna od 01.07.2026 r.
The Polish text of the linked source is authoritative.

The JPK_ST_KR(1) structure has the value 1-0 in the wersjaSchemy attribute.

The versions of the two structures differ: JPK_KR_PD was raised to 1-1, JPK_ST_KR stayed at 1-0. This asymmetry is misleading and easy to get wrong.

Verified 6 August 2026 · Ministerstwo Finansów, Broszura informacyjna dotycząca struktury JPK_ST_KR(1)
The Polish text of the linked source is authoritative.

Fixed asset register data required to build a JPK_ST_KR file: what each dataset is, which fields matter, and why it is usually incomplete.
Dataset	What it is	Fields that matter	Why it is usually incomplete
Asset identification	One row per fixed asset or intangible asset in the register.	inventory number name and description type: tangible / intangible KŚT symbol (Polish classification of fixed assets) acquisition date date brought into use	Acquisition date and date brought into use are one field copied into two places in many systems. For assets that were built or assembled they differ by months, and so does the point at which depreciation starts. The inventory number is sometimes assigned during a physical count and no longer matches the number in the accounting register.
Acquisition document	The document on which the asset entered the register.	acquisition document number document type document date supplier: name and NIP	The single most common gap in the whole register. For assets carried over from a previous system the acquisition document number usually did not survive the migration — it is in a binder, not in the database. Reconstructing it for several hundred items is manual work, which is worth knowing about a year ahead rather than in July.
Value and its changes	The initial value and every event that changed it during the period.	initial value increases, with date and reason decreases, with date and reason value at the end of the period date and basis of disposal or write-off	Improvements get posted to an account but are not always added to the register as a dated event. The value in the ledger and the value in the register then diverge by an amount that cannot be attributed to a specific asset — which is the first thing a reconciliation surfaces.
Depreciation	Depreciation data, separately for statutory and tax purposes where the two differ.	method and rate depreciation start date charge for the period accumulated depreciation net book value at period end flag for charges not deductible for tax	Tax depreciation is often maintained in a spreadsheet beside the system. The database then holds the statutory view only, and the second one has to be built from scratch and reconciled — not an evening of work.
Link to the ledger	The accounts and entries through which the asset and its charges pass in the books.	fixed asset account accumulated depreciation account depreciation expense account entry identifier	The register and the ledger are frequently reconciled in aggregate, one figure per month. The per-asset link simply does not exist and has to be built once, on the account mapping — after which it runs without the accounting team.

AZ-KRH and PZ-KRH — balances with non-residents

This is not a JPK file and it does not go to the Ministry of Finance. Two quarterly forms report assets and liabilities arising from trade with non-residents, and the recipient is the National Bank of Poland. The obligation covers only some entities and it is conditional — the statement below says plainly who it applies to.

The obligation on forms AZ-KRH and PZ-KRH is conditional: it applies to residents that, at year-end or at the end of the given quarter, have NOT reached the general reporting thresholds and at the same time have exceeded 3 million zł of assets or liabilities connected with foreign trade.

This is a replacing obligation, not an additional one: it arises precisely because the general threshold was not reached. An entity above the general threshold files its returns on the general forms.

Verified 6 August 2026 · Obwieszczenie MF z 31.10.2024 (Dz.U. 2024 poz. 1746), § 8 pkt 1 i 2
The Polish text of the linked source is authoritative.

Residents that have not reached the general reporting thresholds but hold assets or liabilities connected with foreign trade whose total amount at year-end exceeds 3 million zł submit quarterly returns to the NBP on forms AZ-KRH and PZ-KRH within 26 days after the end of the quarter.

The 20-day deadline, which can be encountered in other sources, applies to monthly returns of entities above 300 million zł and has no application here.

Verified 6 August 2026 · Obwieszczenie Ministra Finansów z 31.10.2024 – tekst jednolity rozporządzenia Ministra Rozwoju i Finansów z 9.08.2017 (Dz.U. 2024 poz. 1746), § 8
The Polish text of the linked source is authoritative.

We do not submit these

We generate the NBP returns, but a person uploads them to the reporting portal — the person holding the certificate. There is no equivalent of the UPO here, so the evidence chain we close for JPK filings does not close here, and we are not going to pretend otherwise. What remains on our side is the generated file, its contents and the moment it was produced.

Returns are submitted to the NBP through an electronic service made available on the reporting portal, and the user is authenticated with a certificate the NBP issues free of charge.

The regulation provides non-bank entities with neither an API nor any equivalent of the UPO.

Verified 6 August 2026 · Obwieszczenie MF z 31.10.2024 (Dz.U. 2024 poz. 1746), § 13
The Polish text of the linked source is authoritative.

The scope of the form itself is set by the regulation the statements above link to. What follows is what we need out of your system in order to complete it.

Data required to build the AZ-KRH and PZ-KRH returns: what each dataset is, which fields matter, and why it is usually incomplete.
Dataset	What it is	Fields that matter	Why it is usually incomplete
Open balances with non-residents	Unsettled receivables and payables towards foreign entities at the end of the quarter.	counterparty and country code of its seat currency amount in currency and in PLN date incurred due date nature: trade / other	The country is taken from the counterparty address, and that address is often a branch, an office or an agent rather than the registered seat. The position lands under the wrong country and nobody notices, because the total still agrees.
Split by country and currency	Open positions aggregated by counterparty country and settlement currency.	country code currency code total open receivables total open payables	The system knows the counterparty but does not always flag it as resident or non-resident. The tax number alone does not settle it: a foreign entity may hold a Polish registration, and a Polish company may be posted under a VAT number from another country.
Prepayments and advances	Payments made before delivery on either side — the positions most easily left out of cross-border balances.	amount and currency counterparty and country direction: paid / received account the position sits on	Advances sit on accounts that look like ordinary domestic settlements in the chart of accounts. Without an account mapping they drop out of the report entirely.

What is usually missing

We put this on the page instead of discovering it in week three. The fields below come back empty or inconsistent in a first extract more often than any others, whatever system produced it. Naming them now saves a week later.

The NIP on the entry, not only in master data

The entry carries an identifier; the master record may have been merged or emptied. We need both to attach a counterparty to a transaction.

Acquisition document numbers for older assets

A migration carries values across, rarely documents. This is the longest single line item in every implementation plan.

Date brought into use

Separate from the acquisition date. Where the system has one field, it has to be recovered from the commissioning document for assets that were built.

The original-currency amount

Once converted to PLN, the currency disappears from the entry. Both the JPK files and the NBP returns need the original and the converted figure.

Permanent and temporary difference tags

Computed once a year in a spreadsheet outside the system. For them to come out of the books, somebody has to put them into the books first.

Resident / non-resident flag

Master data holds an address, not a status. Without that field the NBP return has to be assembled by hand even though the data is in the system.

None of these gaps rules out an implementation. Each of them costs somebody's time on your side, and that time has to be planned in months rather than in the week before the deadline.

What we do not ask for

A change to how you post

The chart of accounts, the accounting policy and the period close stay as they are. If the structure needs something the data does not carry, we map it on our side or say plainly that it cannot be derived from what exists.

Write access

Everything on this page is read-only. Not one record goes back into the finance system, so the rollout does not require approval to modify a production environment.

The whole database

We take the scope described above, not the production schema in full. If the simplest route is a view covering exactly these fields, a view is enough.

When you can stop reading here

If your system generates JPK_KR_PD itself, the file validates, and there is one Polish entity — you need neither a translator nor us. That is a job for your system's vendor and the Ministry's free filing client. We are not going to pretend otherwise.

This specification starts being worth something when the data has to be assembled from more than one source, when there is more than one entity, or when nobody can get anything out of the system beyond a printout.

Test it against your own extract

The fastest test of this specification is one file out of your system for a closed period. We compare it against the tables above and tell you what is missing — named fields, not a general impression. Thirty minutes with the person who files these, and no presentation.

Who processes this data

Controller: SimplyMobilePlus Sp. z o.o., ul. Prezydenta Gabriela Narutowicza 40/1, 90-135 Łódź. Data enquiries: sales@simplymobileplus.com.
Purpose: To answer your enquiry and, if it goes that way, prepare a quotation.
Legal basis: GDPR art. 6(1)(b) — steps prior to entering a contract — and art. 6(1)(f), our legitimate interest in commercial correspondence. We do not ask for marketing consent, because answering an enquiry does not need it.
Retention: Up to 24 months from the last contact; if a contract follows, for the period required by accounting law and limitation periods.
Recipients: Our mail and hosting providers, acting on our instructions. We do not sell this data and do not transfer it outside the European Economic Area.
Your rights: Access, rectification, erasure, restriction, portability, and objection to processing based on legitimate interest. You may also complain to the President of the Polish Personal Data Protection Office.
Is it required: No. Providing data is voluntary, but without an email address we have no way to reply.

Tell us which system the data comes out of →