Poland JPK SAF-T Reporting: Complete Guide to GTU Codes

GTU codes (Grupy Towarowo-Usługowe) are 13 mandatory classification codes within Poland's JPK_V7 SAF-T reporting system. Applied exclusively to sales records within the JPK_V7 return, these codes categorize transactions involving sensitive goods and services, from GTU_01 for alcohol through GTU_13 for transport services. Each code must be assigned based on what the invoice line items actually describe, and the Polish tax authority imposes penalties of PLN 500 for every incorrect entry. The codes themselves never appear on the invoices. They exist only in the filed return, which means someone on your team has to read each line item description, determine whether it falls under one or more of the 13 categories, and tag it accordingly.

Poland's JPK (Jednolity Plik Kontrolny, meaning "Uniform Control File") is the country's implementation of the OECD Standard Audit File for Tax (SAF-T), and it is arguably the most advanced SAF-T deployment in Europe. Poland was the first EU member state to replace its traditional summary VAT return entirely with mandatory transaction-level data submission. Rather than filing a condensed summary and keeping detailed records on standby for audits, every VAT-registered business in Poland now transmits granular, line-level transaction data directly to the Polish Ministry of Finance on a regular schedule.

Since October 2020, this submission takes the form of the combined JPK_V7 return, which serves a dual purpose: it is both the VAT return and the VAT transaction register filed as a single XML structure. Businesses that file monthly submit JPK_V7M. Those eligible for quarterly VAT settlement submit JPK_V7K, though even quarterly filers must transmit the transaction register portion (the "ewidencja" part containing individual invoice records and GTU classifications) every month. There is no escaping the monthly data obligation regardless of your settlement period.

The results of this system have been measurable. According to an analysis of the EU VAT Gap Report by A&O Shearman, Poland's VAT gap decreased by 7.8 percentage points between 2020 and 2021, with tools such as the Standard Audit File for Tax and the mandatory split payment mechanism contributing to a major decrease in the domestic VAT gap. For the Polish Ministry of Finance, transaction-level reporting has proven its worth as an enforcement tool. For finance teams on the compliance side of that equation, the Jednolity Plik Kontrolny requirements demand a level of data granularity that many organizations were not built to produce.

This is where Poland JPK reporting becomes a practical challenge rather than just a regulatory checkbox. GTU classification requires analyzing the description of every line item on every sales invoice to determine which, if any, of the 13 codes apply. A single invoice selling both electronic equipment (GTU_06) and fuel (GTU_02) needs both codes flagged on that record. The descriptions that drive these decisions are only as reliable as the data captured from the original invoices. When line item descriptions are accurately extracted and categorized, applying the correct GTU codes is straightforward. When those descriptions are manually keyed, abbreviated, or poorly captured from scanned documents, errors cascade through the entire filing. Poland SAF-T requirements, in other words, turn invoice data quality into a direct compliance risk. Every misread product description or truncated service line is a potential PLN 500 penalty waiting in the next tax authority review.

---

JPK File Types and Filing Deadlines

Poland's SAF-T framework encompasses several distinct file types, each covering a different slice of a company's financial data. Some are filed on a fixed schedule. Others sit dormant until the tax authority comes knocking.

Mandatory Monthly Filing: JPK_V7M and JPK_V7K

The cornerstone of Poland's JPK system is JPK_V7, which merged the old VAT-7 return and the VAT transaction register into a single unified file. Since October 2020, there is no separate VAT return — JPK_V7 is the return.

Two variants exist based on your filing frequency:

• JPK_V7M — For taxpayers filing VAT monthly. Both the declaration (return) and the transaction register are submitted together each month, due by the 25th of the following month.
• JPK_V7K — For taxpayers eligible for quarterly VAT filing. The transaction register portion (ewidencja) is still submitted monthly by the 25th, but the declaration portion is filed only once per quarter. This catches some first-time filers off guard: quarterly status does not mean quarterly data submission.

The transaction register within JPK_V7 is where GTU codes, procedural flags, and detailed line-item classifications live. This is the file that demands the most attention to invoice data quality.

On-Demand JPK Files

Beyond the monthly obligation, Poland requires taxpayers to produce additional JPK files within 3 days of a tax authority request during audits, inspections, or tax proceedings:

File Type	Content	When Required
JPK_FA	Detailed sales invoice data (line items, dates, amounts, VAT rates)	On demand during audit
JPK_KR	General ledger and accounting books	On demand (transitioning to mandatory via JPK_CIT)
JPK_WB	Bank account statements	On demand during audit
JPK_MAG	Warehouse and inventory records	On demand during audit
JPK_FA_RR	Invoices from flat-rate (ryczałt) farmers	On demand during audit

That 3-day turnaround for on-demand files is tight. Organizations that lack structured, export-ready financial data often scramble when the request arrives — which is precisely why maintaining clean, classified invoice records matters well before any audit begins.

Filing Requirements Across All JPK Types

Every JPK submission, whether mandatory or on demand, must meet the same technical requirements:

• XML format conforming to the Ministry of Finance schema for that file type
• Qualified electronic signature (or trusted profile authorization) applied to the file
• Electronic submission to the tax authority — paper is not accepted
• 5-year retention minimum, archived in the format originally submitted

How Poland's Approach Differs

Poland's decision to combine the VAT return and transaction register into a single JPK_V7 file is unusual among European SAF-T implementations. Most countries keep these as separate obligations — you file your VAT return through one channel and submit SAF-T transaction data through another. Portugal's SAF-T reporting framework, for example, maintains this separation between the periodic VAT return and the SAF-T data export. Romania's D406 regime adds another variation, with separate General, Assets, and Inventory SAF-T submissions that follow different trigger points, as explained in this Romania SAF-T D406 deadlines guide. Lithuania adds another invoice-register model with monthly i.SAF reporting deadlines and nil-filing decisions, which likewise depends on keeping sales and purchase data structured before submission. Poland's unified approach simplifies the number of submissions but raises the stakes for each one: a classification error in your transaction register is simultaneously an error in your VAT return.

All 13 GTU Codes for Goods and Services Classification

Poland's GTU classification system assigns one of thirteen codes to specific categories of goods and services that the Ministry of Finance considers sensitive to VAT fraud. Every sales transaction involving items in these categories must carry the corresponding GTU code in the JPK_V7 file.

Three rules govern how GTU codes work in practice:

GTU codes apply to sales records only. They are never assigned to purchase records in the JPK_V7 file. Purchases use a separate set of procedural flags (covered in a later section).

GTU codes do not appear on the invoice itself. There is no legal requirement to print or display GTU codes on the physical or PDF invoice document. The codes exist exclusively within the JPK_V7 data file submitted to the tax authority. Some businesses choose to note GTU codes on internal invoice copies for convenience, but this is optional.

Multiple GTU codes can apply to a single invoice. If an invoice covers goods or services falling into more than one GTU category, all applicable codes must be flagged on that invoice's sales record in the JPK_V7 file.

If none of the 13 categories apply, no GTU code is assigned. The GTU field in the JPK_V7 record is simply left empty. Not every invoice requires a GTU code — only those involving goods or services covered by the categories below.

The complete list of Poland GTU codes is as follows:

Code	Category	What It Covers
GTU_01	Alcoholic beverages	Supply of alcoholic drinks subject to excise duty, including beer, wine, spirits, and ethyl alcohol
GTU_02	Fuels	Motor fuels, aviation fuels, diesel oil, liquefied petroleum gas (LPG), and other fuel products listed in Article 103(5aa) of the VAT Act
GTU_03	Heating and lubricating oils	Heating oil not covered under GTU_02, lubricating oils, and other oils classified under specific CN codes
GTU_04	Tobacco and nicotine products	Cigarettes, cigars, pipe tobacco, dried tobacco, e-cigarette liquids, and novel tobacco products
GTU_05	Waste and secondary raw materials	Scrap metal, waste glass, waste paper, waste rubber, waste plastic, and other recyclable materials
GTU_06	Electronic devices	Integrated circuits, processors, central processing units, solid-state drives (SSDs), computers, hard drives, smartphones, tablets, digital cameras, and video cameras
GTU_07	Vehicles and parts	Passenger cars, trucks, buses, tractors, motorcycles, vehicle chassis, bodies, trailers, and vehicle parts
GTU_08	Precious and base metals	Gold, silver, platinum, steel products, non-ferrous metals, jewelry, and articles made from precious metals
GTU_09	Pharmaceuticals and medical devices	Medicines, pharmaceutical products, and medical devices as defined by the Pharmaceutical Law and medical device regulations
GTU_10	Real estate	Buildings, structures, building plots, developed and undeveloped land, and perpetual usufruct rights to land
GTU_11	Emission allowances	Greenhouse gas emission permits and allowances under the EU Emissions Trading System
GTU_12	Intangible services	Consulting, advisory, legal, accounting, bookkeeping, tax advisory, IT development, IT consulting, management, advertising, marketing, market research, and head office services
GTU_13	Transport and storage	Freight transport services, passenger transport, warehousing, storage, courier services, and postal services

GTU_12 Deserves Special Attention

Among all thirteen codes, GTU_12 stands out for its breadth. It covers a wide range of professional and intangible services that many businesses do not initially associate with VAT-sensitive categories. A law firm invoicing for contract review, an accounting practice billing for monthly bookkeeping, a software consultancy charging for system implementation, a marketing agency billing for a campaign — all of these require GTU_12 classification in the seller's JPK_V7 filing.

The practical scope of GTU_12 includes:

• Legal services — advisory, representation, contract drafting
• Accounting and bookkeeping — financial statement preparation, ledger maintenance
• Tax advisory — tax planning, compliance consulting
• IT services — software development, systems consulting, IT project management
• Management consulting — strategy, operational advisory, organizational consulting
• Advertising and marketing — campaign management, media buying, brand consulting
• Market research — surveys, competitive analysis, consumer studies
• Head office services — centralized management functions billed between group entities

Any business that sells professional services in Poland should treat GTU_12 as a default consideration for every outgoing invoice. Missing this classification is one of the most common GTU errors, particularly for foreign companies whose Polish operations are service-oriented rather than goods-based.

Mapping Invoice Line Items to GTU Codes

GTU codes do not appear on invoices. This is the central challenge of GTU classification in Poland's JPK_V7 system: the person filing the return must read each invoice's line item descriptions and determine which of the 13 GTU categories apply to the transaction. The invoice seller has no obligation to mark GTU codes on the document itself. The entire classification burden falls on the taxpayer preparing the JPK_V7 file.

This makes GTU assignment fundamentally an invoice data interpretation problem. The accuracy of your classification depends entirely on how clearly you can read and categorize what was actually sold or delivered. When invoice descriptions are vague, abbreviated, or inconsistent across suppliers, the risk of misclassification rises sharply.

Straightforward Mappings

Many invoice line items map cleanly to a single GTU code when the description is specific enough:

Invoice Line Item Description	GTU Code	Reasoning
Diesel delivery, 5000L, site depot	GTU_02	Fuel delivery — goods covered under fuel and lubricant categories
Scrap metal collection, 2.4 tonnes	GTU_05	Waste and scrap metals fall squarely under GTU_05
Laptop computers x25 (HP ProBook 450)	GTU_06	Electronic devices including computers and laptops
Medical supplies, surgical masks, examination gloves	GTU_09	Medicines and medical devices per Annex 15 of the VAT Act
IT consulting services, Q1 2026	GTU_12	Intangible services — consulting falls under the GTU_12 umbrella
Legal advisory, contract review	GTU_12	Legal services are explicitly covered by GTU_12
Freight transport Warsaw to Gdańsk	GTU_13	Transport services are classified under GTU_13

In each of these cases, the description contains enough detail to identify the goods or services and match them to a specific code. The classifier does not need to guess.

Ambiguous Cases That Require Judgment

Real-world invoices are rarely this clean. Consider an invoice line reading "office supplies including printer cartridges and computer peripherals." The printer cartridges alone would not trigger any GTU code. But "computer peripherals" is vague — if the peripherals include items like external drives, monitors, or other electronic devices listed in Annex 15 of the VAT Act, the transaction may require GTU_06. Without knowing exactly which peripherals were purchased, the classifier cannot make a confident determination. They need to go back to the supplier or examine supporting documentation.

Professional services bundling creates similar problems. An invoice described as "consulting and logistics management, project Alpha" could involve both advisory services (GTU_12) and transport coordination (GTU_13). If the invoice does not break these into separate line items with distinct amounts, the filer must apply both codes to the transaction. A single invoice can carry multiple GTU markers — the codes are not mutually exclusive.

Mixed-goods invoices compound the difficulty further. A wholesale supplier invoice listing dozens of product lines may span several GTU categories in a single document. Each line item must be evaluated independently. Missing one category means an incorrect JPK_V7 declaration for that period.

The Scale Problem

Manual GTU classification is manageable when a business processes a handful of invoices per month. It becomes a serious accuracy risk at scale. A mid-sized company with Polish VAT obligations might process several hundred purchase and sales invoices monthly, each containing multiple line items that need to be evaluated against all 13 GTU code categories.

The error pattern is predictable: an accountant working through a batch of invoices misreads an abbreviated description, overlooks a line item that triggers a secondary GTU code, or applies inconsistent classification logic across similar transactions from different suppliers. These are not knowledge failures — the accountant understands the GTU framework. They are data quality failures that stem from the gap between unstructured invoice text and the structured codes required by JPK_V7.

A concrete example: an invoice originally reading "Samsung Galaxy S24 Ultra smartphones x10" is manually entered into the accounting system as "Samsung x10." The abbreviated description no longer clearly identifies the items as electronic devices, and GTU_06 is not applied. Ten invoices with the same shortcut, repeated over three months, produces 30 unclassified entries — each carrying a potential PLN 500 penalty.

Consistent classification accuracy depends on how clearly invoice data is captured and categorized before the GTU assignment step begins. When line item descriptions are accurately extracted from source documents — with product names, quantities, and service types preserved in full — the accountant has reliable raw material to work with. When those descriptions are truncated during manual entry, transliterated poorly from foreign-language invoices, or compressed into summary lines, the classification task becomes guesswork.

This is where automated invoice data extraction for tax compliance changes the workflow. Rather than manually keying invoice data and then separately classifying each entry, extraction tools can capture line item descriptions at their original level of detail and categorize them into groups that map to GTU code categories — fuel and lubricants, electronics, consulting services, transport services, and so on. The categorization happens during extraction, not as a separate downstream step. The accountant still makes the final GTU determination, but they are working from structured, consistently categorized data rather than raw invoice text. The classification step shifts from interpretation to verification.

---

Procedural Flags in JPK_V7 Reporting

GTU codes classify what was sold. Procedural flags classify how the transaction was conducted. Together, they form the two classification layers that every JPK_V7 record must carry, and confusing them or omitting either layer is one of the fastest paths to a correction request from the tax office.

The distinction matters for a practical reason: GTU codes apply exclusively to sales records. Procedural flags apply to both sales and purchase records in JPK_V7. This asymmetry catches many filers off guard, particularly those managing purchase-side reporting who assume that because GTU codes do not apply to their records, no classification is required. Procedural flags close that gap.

TP: Related Party Transactions

The TP flag marks transactions between related entities as defined under Polish tax law. When the buyer and seller share ownership ties, management overlap, or family connections that meet the statutory thresholds, every invoice between them must carry the TP designation in JPK_V7. The flag exists to support transfer pricing oversight. Omitting it does not change the tax calculation, but it does signal to authorities that the filer may not be tracking related-party dealings with appropriate diligence.

For groups with multiple Polish entities or foreign parents transacting with Polish subsidiaries, TP flagging requires a current and accurate map of entity relationships. Changes in ownership structure mid-year can shift which transactions need the flag.

MPP: Split Payment Mechanism

The MPP flag indicates that an invoice falls under Poland's mandatory split payment mechanism for invoices. Mandatory split payment applies when three conditions are met simultaneously: the transaction value exceeds PLN 15,000 gross, the seller is a VAT-registered entity, and the goods or services appear on Annex 15 to the Polish VAT Act. Annex 15 covers categories including steel products, electronics, fuel, construction services, and vehicle parts.

When mandatory split payment applies, the invoice itself must carry the annotation "mechanizm podzielonej płatności," and the corresponding JPK_V7 record must include the MPP flag. Voluntary use of split payment on invoices below the threshold or outside Annex 15 categories does not trigger the MPP flag requirement.

EE: Cross-Border B2C E-Commerce

The EE flag identifies cross-border business-to-consumer e-commerce transactions reported under the EU One Stop Shop (OSS) scheme. Companies selling goods or digital services to consumers in other EU member states and using the OSS registration to handle VAT in those countries must flag the relevant records with EE. This flag appears primarily in the records of e-commerce sellers and SaaS companies with EU consumer revenue.

MR_T and MR_UZ: Margin Scheme Transactions

Two flags cover transactions taxed under margin schemes rather than standard VAT rules:

• MR_T applies to tourism services taxed under the special margin scheme for travel agents, where VAT is calculated on the margin between the purchase cost and the sale price rather than on the full invoice amount.
• MR_UZ applies to second-hand goods, works of art, collector's items, and antiques sold under the margin scheme.

Both flags are relevant primarily to specialized industries, but they must not be overlooked by general-practice accountants handling clients in travel or resale sectors.

TT_WNT and TT_D: Triangular Transactions

These flags mark the two sides of an intra-Community triangular transaction, the three-party cross-border arrangement where goods move directly from the first seller to the final buyer while the intermediary handles the invoicing chain:

• TT_WNT flags the intra-Community acquisition side of the triangular transaction.
• TT_D flags the domestic supply leg of the triangular transaction.

Triangular transaction flags require careful attention to the commercial flow of goods versus the invoicing chain. Mislabeling which leg is which, or failing to flag either side, creates inconsistencies that surface during automated cross-checks between EU member states' VAT reporting systems.

Practical Implications

Because procedural flags span both the sales and purchase sections of JPK_V7, the data requirements reach further into the organization than GTU codes alone. Purchase-side flags like TP and MPP require the accounts payable team to capture and verify transaction attributes that go beyond the standard invoice fields. A supplier invoice for PLN 20,000 worth of steel products needs the MPP flag on the purchase record even though GTU codes are irrelevant on the purchase side. Related-party purchases need the TP flag regardless of the transaction amount.

This dual-sided requirement means that any system feeding data into JPK_V7 preparation must capture procedural flag attributes at the point of invoice entry, not as a retrospective exercise during filing. Retrofitting flags onto thousands of purchase records at month-end is the kind of manual classification burden that leads to omissions and corrections.

---

JPK_CIT and KSeF: Poland's Evolving SAF-T Framework

Poland's SAF-T obligations no longer stop at VAT. Two parallel developments are expanding the framework: JPK_CIT extends structured electronic reporting to corporate income tax, while a new JPK_V7 version integrates directly with the national e-invoicing platform. Together, they create an interconnected reporting ecosystem where invoice data captured at the source feeds into every downstream tax filing.

JPK_CIT: Corporate Tax Joins the SAF-T Framework

JPK_CIT introduces structured, machine-readable reporting for corporate income tax (CIT), applying the same logic that JPK_V7 brought to VAT. Rather than submitting traditional CIT returns with supporting documentation on request, taxpayers must now transmit standardized data files that give the tax authority direct visibility into accounting records and their tax treatment.

The rollout follows a phased schedule based on company size:

• January 2025 (already in effect): CIT taxpayers with revenue exceeding EUR 50 million, plus tax capital groups (podatkowe grupy kapitałowe).
• January 2026 (now in effect): All CIT taxpayers who are already required to submit JPK_V7.
• January 2027 (upcoming): All remaining CIT taxpayers.

JPK_CIT consists of two distinct file structures. JPK_KR_PD covers accounting books with corporate tax adjustments, mapping general ledger entries to their CIT treatment and flagging where accounting and tax values diverge. JPK_KR_ST is the fixed assets register, capturing acquisition costs, depreciation methods, and tax-versus-accounting depreciation differences for each asset.

Starting from 2026, JPK_CIT files must also include KSeF invoice numbers for each transaction, contractor identification numbers (NIP), and explicit breakdowns of accounting-to-tax differences. This requirement means that the e-invoicing data flowing through KSeF becomes a mandatory reference point within corporate tax reporting, not just VAT compliance.

JPK_V7 Version 3 and KSeF Integration

On the VAT side, Poland is rolling out JPK_V7(3), a new version of the reporting structure designed to align with the Krajowy System e-Faktur (KSeF), Poland's national e-invoicing platform. Where earlier JPK_V7 versions treated invoice data as self-reported by the taxpayer, version 3 ties each entry to a verifiable e-invoice record in the government system.

The core change: every invoice entry in JPK_V7(3) must include the KSeF identification number, the unique reference assigned to each e-invoice when it passes through the national platform. This creates a direct link between the VAT return data and the structured invoice stored in KSeF, giving the tax authority the ability to cross-reference both datasets automatically.

Three exception codes handle entries that legitimately lack a KSeF number:

Code	Meaning	Use Case
OFF	Invoice issued in offline mode	System outage or connectivity failure during KSeF submission
BFK	Transaction not subject to KSeF obligation	Transactions exempt from the e-invoicing mandate
DI	Invoice predates the KSeF mandate	Historical invoices issued before KSeF became mandatory

The practical consequence of this integration is significant. The tax authority no longer needs to request invoices during an audit; it already holds the structured e-invoice data in KSeF and can validate it against JPK_V7 entries programmatically. Discrepancies between what a company reports in its VAT filing and what KSeF records show for the same transaction will surface immediately.

An Interconnected Reporting Ecosystem

These developments mean Poland's SAF-T framework is converging into a single, cross-validated network. Invoice data flows from KSeF into JPK_V7 for VAT reporting. The same invoice references feed into JPK_CIT for corporate tax purposes. The tax authority can trace a single transaction across all three channels: the original e-invoice in KSeF, its VAT treatment in JPK_V7, and its CIT treatment in JPK_KR_PD.

Each European country is charting its own course with SAF-T adoption. While Poland is building tight integration between e-invoicing and tax reporting, Norway's SAF-T implementation for accounting records focuses on standardizing general ledger data for audit purposes. Poland's approach is distinct in how aggressively it connects invoice-level data across multiple tax domains.

For finance teams and advisors working with Polish entities, the implication is straightforward: accuracy at the point of invoice data capture now cascades through every downstream compliance obligation. A GTU code error in the source invoice affects JPK_V7 reporting. A missing KSeF reference number creates mismatches in both VAT and CIT filings. The margin for correcting data quality problems downstream is shrinking as these systems become more tightly coupled.

---

Penalties for JPK Filing Errors

Poland's penalty framework for JPK non-compliance operates on a per-error basis, making the financial consequences directly proportional to the number of incorrect entries in a filing. Understanding this structure is essential for anyone responsible for JPK_V7 submissions.

Per-Error Penalties

The Polish tax authority imposes a penalty of PLN 500 for each individual error identified in a JPK_V7 file. This is not a flat fine per filing — each incorrect entry is penalized separately. A single monthly JPK_V7M submission containing 40 invoices with incorrect GTU classifications can therefore generate PLN 20,000 in penalties from one filing alone. Systematic errors compound rapidly: if the same classification mistake repeats across several months of filings before detection, the cumulative exposure grows accordingly.

Criminal Fiscal Liability

When deliberate misreporting results in a tax liability reduction exceeding PLN 10,000, the matter moves beyond administrative penalties into criminal fiscal code territory. Under the Kodeks karny skarbowy (Criminal Fiscal Code), intentional filing of false information that reduces VAT obligations can result in criminal charges, fines calculated as multiples of the minimum daily wage, and in severe cases, imprisonment. This threshold elevates serious JPK filing errors from a cost-of-doing-business concern to a legal risk that affects individuals personally, not just the reporting entity.

Late and Missing Filings

Failure to submit JPK_V7 by the required deadline — the 25th of the following month for JPK_V7M filers — carries a penalty of PLN 2,800 per occurrence. This deadline is strict and applies regardless of whether the taxpayer intends to file a nil return. Poland's digital tax reporting infrastructure expects timely electronic submission, and the penalty applies equally to late filings and complete non-filings.

Voluntary Correction Procedure

Taxpayers who discover errors in previously submitted JPK_V7 filings can submit a corrective filing (korekta JPK_V7) through the same electronic channel used for the original submission. The corrective filing replaces the data for that period entirely. Filing a voluntary correction before the tax authority initiates an audit or formal proceedings generally allows the taxpayer to avoid the PLN 500 per-error penalties. Even when the tax authority identifies errors first and notifies the taxpayer, there is typically a 14-day window to submit a correction before per-error penalties are imposed. However, once the tax office has commenced formal verification proceedings or an audit, the window for penalty-free correction closes. This creates a strong incentive for regular internal review of filed JPK data.

Archival Requirements

All JPK files and their supporting documentation must be retained for a minimum of five years from the end of the tax year to which they relate. The records must remain accessible in their original XML format. This means that invoice source data, GTU classification decisions, and the filed JPK_V7 XML files all need to be preserved in a retrievable state for potential future audit.

Why GTU Accuracy Carries Outsized Financial Risk

The PLN 500 per-error penalty structure means that GTU classification errors are individually priced. Unlike a single flat penalty for a flawed filing, this model turns every misclassified invoice line into its own liability event. A business that consistently fails to apply GTU_12 to intangible service invoices across a quarter of filings — 150 invoices affected — faces potential penalties of PLN 75,000 from a single recurring error. Combined with the voluntary correction mechanism, this penalty structure creates a clear incentive: proactive data quality at the point of invoice processing and regular self-review of filed JPK data are the most cost-effective ways to manage JPK SAF-T compliance risk.