What to check before sending JPK_V7 this month
Before you click send, verify completeness, correctness, and consistency. Confirm all sales and purchase invoices are captured for the month, dates align with your accounting policy, VAT numbers are valid, and invoice types are marked correctly (e.g., regular, advance, correction). Recalculate VAT and net totals, confirm tax procedure markers, and check whether split payment (MPP) and related-party (TP) flags apply.
Reconcile VAT records to the general ledger and bank statements. Ensure cash register summaries (if any) are posted, import and intra‑EU transactions are classified, and KSeF identifiers are stored for e‑invoices where applicable. Finally, run a schema validation on the JPK_V7 file and generate a management sign‑off log of who checked what and when.
Know your JPK_V7 file: parts, markers and timing
JPK_V7 combines VAT ledgers with a declaration section. Businesses reporting monthly use JPK_V7M; quarterly reporters typically submit records monthly with a quarterly declaration (JPK_V7K), subject to current rules. The file contains sales (Sprzedaz) and purchases (Zakup) records plus declaration data. Your accounting system should map each transaction to the required structure automatically.
Certain markers may be required depending on the schema version and the nature of transactions, such as GTU codes for specific goods/services, TP for related‑party operations, MPP for split payment applicability, FP for receipts turned into invoices, RO for cash register summaries, or WEW for internal documents. Because tag sets evolve, always confirm the current schema with your software vendor and official guidance.
A step-by-step monthly workflow that works
Step 1: freeze the period in your ERP. Step 2: pull a preliminary JPK_V7 and exception reports. Step 3: match sales to contracts, delivery notes, and KSeF entries where used. Step 4: validate counterparty VAT numbers and bank accounts on the finance ministry’s white list when relevant. Step 5: check tax markers (GTU/TP/MPP) and invoice types.
Step 6: reconcile VAT control accounts, input VAT by supplier, and output VAT by rate. Step 7: tie VAT to bank statements, including split payment transfers. Step 8: rerun JPK_V7 from clean data, validate against the latest XSD, and archive the validation log. Step 9: obtain internal approvals (finance lead, director) and submit through your approved channel, storing the official UPO acknowledgement.
Data quality controls and reconciliations you should not skip
Perform a three-way match on sales: source document, ledger entry, and JPK_V7 extract. Differences usually arise from posting dates, partial deliveries, or missing corrections. For purchases, verify invoice sequence, supplier identity, VAT deduction eligibility, currency translation, and that import entries are supported by customs documents. Flag duplicate invoice numbers and unusually high VAT amounts for secondary review.
Reconcile output VAT per rate (e.g., standard, reduced, exempt) to the general ledger and management reports. For input VAT, separate deductible, non-deductible, and postponed import VAT. Cross-check split payment operations against bank MPP statements. If using KSeF, reconcile internal invoice numbers with KSeF identifiers and ensure any rejected e‑invoices were corrected and excluded from the period. Retain evidence for every adjustment.
Edge cases: realistic examples to pressure-test your file
Example 1: you issued an advance invoice on 28th and a final invoice on 5th next month. Ensure the advance appears in this month’s sales with the correct tax base and that the final invoice nets the advance. Example 2: a supplier sent a corrective invoice (in minus). Verify the sign, reference to the original, and the period of recognition per your policy and current guidance.
Example 3: intra‑Community acquisition of goods (WNT) in EUR—record both input and output VAT where applicable, using the correct exchange rate and recognition date. Example 4: retail sales via fiscal cash register—post the daily/monthly “RO” summary, not each receipt. Example 5: transaction with a related entity—apply the TP marker if required and keep documentation supporting arm’s‑length terms.
Common mistakes and how to avoid them
Frequent errors include wrong dates (issue vs. delivery vs. receipt), missing or outdated tax markers, incorrect signs on credit notes, and failing to flag split payment applicability. Duplicates creep in when importing bank or KSeF data twice. Another trap is misclassifying exempt vs. zero‑rated sales, which distorts both the ledger and the declaration section.
System issues also cause trouble: stale mapping tables after a schema update, rounding differences on multi‑currency invoices, and broken links between KSeF IDs and ERP documents. Prevent them by locking master data changes post‑close, running a nightly schema check, documenting mapping rules, and maintaining a short “known issues” register your team revisits before every submission. When rules change, update both process and training.
A concise pre-submission checklist you can adopt today
Checklist: period frozen; all invoices posted; KSeF IDs matched; VAT numbers validated; white‑list checks done for critical suppliers; markers (GTU/TP/MPP/FP/RO/WEW as applicable) reviewed; imports/IC transactions reconciled; split payment matched to bank; VAT per rate ties to GL; schema validated; UPO archiving ready; approvals signed.
Keep supporting files with clear names: reconciliation workbooks, exception logs, marker justifications, and bank extracts. Store them alongside the JPK_V7 XML, schema version used, and validation reports. If you operate quarterly, note how your monthly records feed the quarterly declaration. Because KSeF timelines and JPK schema rules evolve, verify current requirements on official portals before each close.
What to do next and where to get help
Set a monthly calendar: day 1–3 data capture, day 4–6 reconciliation, day 7 validation and approvals, submission on the agreed date, and post‑mortem the next day. Assign named owners for sales, purchases, bank, and schema validation. For small teams, consider lightweight automation (bank feeds, VIES checks, white‑list API) to reduce manual risk and speed reviews.
When in doubt about treatment (e.g., special procedures, cross‑border, or KSeF edge cases), seek professional advice. Our 1 Point Business Service Package (Auranik /poland/consulting/business-services) helps founders and finance teams set up pragmatic VAT close routines and documentation. Always verify current rules and schemas via the Polish Tax Portal, the Ministry of Finance, and KSeF; for broader compliance calendars, also track ZUS communications.
Community content reflects individual experiences and should not be treated as legal, immigration, financial or government advice.
Know someone who may find this guide useful?