JPK control totals: sales, purchases and FA invoices
Trace V7 control sums, FP exclusions, K_360 and separate FA invoice/line totals with a fictional local example.
Find the control block before editing a row
JPK-TOTAL identifies a difference between a declared control value and the recognized fields that contribute to it. The fictional V7M(3) error contains a sales row with K_20 of 23.00 and PodatekNalezny of 24.00. The independent check points to SprzedazCtrl/PodatekNalezny. Repairing that demo means making the control value reflect the row; it does not demonstrate that the underlying sale received the correct tax treatment.
Work backwards from the failed layer in a real export. A count failure uses JPK-COUNT and concerns records rather than amounts. An XML syntax failure means arithmetic has not run. A schema compilation failure leaves the XSD layer unexecuted, while a compiled schema that rejects the document produces an actual XSD failure. Those outcomes require different fixes and should remain distinct in client batch reports.
Sales tax uses a versioned formula
For the supported V7 packages, the sales-control calculation adds K_16, K_18, K_20, K_24, K_26, K_28, K_30, K_32, K_33 and K_34. It subtracts K_35 and K_36. Version (3) additionally subtracts K_360. Rows marked FP are excluded from that amount calculation, while they remain rows for the declared sales-row count.
This distinction catches a common exporter mistake: summing every visible tax number without respecting the document marker. Another mismatch can appear when a version (2) exporter is partially updated for version (3) and the control calculation overlooks the new subtraction. Signed values are retained, so negative correction amounts are not automatically rejected. The checks use exact fixed-point arithmetic and avoid putting accounting values into diagnostic text or analytics.
Purchases and invoices have different controls
PodatekNaliczony is reconciled with K_41, K_43, K_44, K_45, K_46 and K_47 from purchase rows. The purchase count compares LiczbaWierszyZakupow with the number of ZakupWiersz records. Sales and purchase sections cannot share one generic counter: each control block describes its own records and fields. When rows are present but their control block is absent, the independent result requires correction even without an XSD package.
JPK_FA(4) uses a separate invoice-data model. WartoscFaktur sums P_15 from Faktura records, and WartoscWierszyFaktur sums P_11 from FakturaWiersz records. P_2B links a line back to P_2A in the invoice records. A missing reference is reported separately from a mismatched amount, so a batch reviewer can distinguish an extraction problem from a control-sum problem.
Treat net/VAT comparisons as review prompts
A simple net base multiplied by a current VAT rate is useful for finding suspicious arithmetic. It cannot establish the legally applicable rate. Historical rates, advances, mixed treatments, corrections, discounts and foreign-currency tax conversions can require more context. The lite validator therefore labels those comparisons as plausibility warnings and limits ordinary FA gross arithmetic to the stated PLN/VAT context.
Do not replace all declared values merely to remove a warning. Confirm the source entries, the selected reporting period and the reason for any special treatment. After regenerating the export, compare each file's JSON or CSV result by index, package version and scope. The final technical and filing process still belongs to the official MF/KAS workflow; a local result cannot prove successful submission or UPO.
Before and after
Before: independent rule fails
<K_20>23.00</K_20>
<PodatekNalezny>24.00</PodatekNalezny>After: this field passes
<K_20>23.00</K_20>
<PodatekNalezny>23.00</PodatekNalezny>Fictional failing XML · Passing rule-only demo · Expected codes and locations
Primary sources and exact scope
MF / KAS JPK structures identifies current and historical V7 packages and the separate FA(4) structure. The official V7M(3) XSD and official FA(4) XSD define the factual fields used by the independent explanation. Sources rechecked 6 November 2026. No protected explanatory text or official rule pack is copied here.
The schema, independent business, plausibility and unchecked fiscal / submission layers remain separate. This page describes supported technical checks for Polish administrations; it does not create a JPK obligation in another country.
Recheck the corrected export
Poland JPK validator · Walidator JPK Polska · Related JPK repair guide