Why Validate Before You Send to KSeF
KSeF rejects structurally invalid invoices and selected substantive violations. Finding out after submission costs time, disrupts VAT reporting, and exposes your data to third-party cloud services. Here is what pre-validation actually prevents.
What happens when KSeF rejects your invoice
When you submit an invoice to KSeF and it fails validation, the system returns an error response with a rejection code. The invoice does not enter the National e-Invoice System. You must fix the XML, correct the business logic violation, and resubmit.
This matters because a rejection means no KSeF number is assigned. You must correct the XML and resubmit. The KSeF receipt date of the corrected invoice may differ from your intended issue date. This can shift your VAT reporting period, affect cash flow timelines, and create discrepancies between your accounting system and the KSeF record.
For batch submissions, a single invalid invoice can block the entire batch, delaying all invoices in the set. In production environments processing hundreds of invoices daily, this creates a cascade of downstream problems: delayed delivery confirmations, mismatched settlement dates, and manual intervention to identify which invoice caused the failure.
Batch validation catches this before the batch reaches KSeF — especially useful for accounting offices handling many clients.
128 active validation rules
KSeF Guard checks 128 active validation rules. These are not generic XML checks — they are substantive compliance rules derived from specific legal sources, with source-backed evidence appropriate to each rule class:
- Art. 106e of the VAT Act (ustawa o podatku od towarów i usług) -- mandatory invoice elements, correction requirements, and special invoice types (margin, self-billing, advance payments)
- Ministry of Finance regulations -- detailed formatting rules, NIP validation, currency constraints, and rounding requirements
- Official FA(3) information brochure -- the Ministry's own guidance on how to populate each field, including edge cases for VAT exemptions, reverse charge, and split payment annotations
- XSD schema constraints -- structural rules enforced by the FA(3) schema definition (CRWDE 13775)
Each rule is classified into one of six categories: GOV_MANDATED (derived from legislation), BEST_PRACTICE (recommended by official guidance), HEURISTIC (catches likely errors based on patterns), SECURITY (detects suspicious data patterns), BATCH_CHECK (cross-invoice consistency), and INFERRED (logically derived). You can explore all rules in the Rule Explorer.
XSD structural validation runs first
Before any business rules execute, KSeF Guard validates your XML against the official FA(3) schema (CRWDE 13775) using libxml2, the same XML library used by most enterprise systems and many government infrastructure components.
XSD validation catches structural problems that would cause immediate rejection:
- Missing required elements (e.g., no
P_1invoice date, noNIPin seller data) - Wrong element ordering -- FA(3) requires elements in a specific sequence
- Invalid data types (text where a decimal is expected, dates in wrong format)
- Namespace mismatches and encoding issues (the schema requires UTF-8)
Only after the XML passes XSD validation does KSeF Guard proceed to evaluate the 128 active validation rules. This two-phase approach means you get structural errors immediately rather than wading through business rule results on a malformed document.
Your invoices never leave your machine
Cloud-based KSeF validators require uploading your invoice XML to third-party servers. That XML contains sensitive business data: NIP numbers (tax identification), client names and addresses, transaction amounts, bank account numbers, and the full structure of your commercial relationships.
KSeF Guard runs entirely on your local machine. The validation engine, the XSD schema, the business rules, and the legal reference library are all embedded in the binary. No network connection is required for validation. Validation runs offline. License activation, payments, and automatic updates may connect.
This is not just a privacy preference -- it is a GDPR compliance consideration. Under Articles 5 and 25 of the GDPR (data minimisation and data protection by design), processing personal data locally when remote processing is unnecessary supports data minimisation and privacy-by-design. Invoice data may contain personal data (NIP numbers, names, financial details) as defined under GDPR. Uploading it to external servers creates data controller obligations, requires a legal basis for processing, and introduces breach notification risk that is significantly reduced when validation stays local.
Every rule traces to a documented source
KSeF Guard rules include source-backed evidence appropriate to each rule class. GOV_MANDATED rules carry verbatim quotes from the VAT Act, Ministry regulations, or FA(3) brochure in Polish as published by the relevant authority. BEST_PRACTICE and HEURISTIC rules reference the official FA(3) guidance or describe the detection logic. Not every rule has a legal citation — but every rule traces to a documented source.
Every source quote is accompanied by a SHA-256 hash for provenance verification. This means you can independently verify that the legal text backing a rule has not been altered. The hash is computed from the original Polish text and stored alongside the rule for independent provenance verification.
Why does this matter in practice? When your validation report flags a rule violation, you can trace it to the exact legal provision. This is valuable for:
- Tax audits -- demonstrate that your pre-submission validation was based on current law, not arbitrary rules
- Compliance documentation -- provide auditors with the legal basis for each check in your validation pipeline
- Dispute resolution -- when a rule fires unexpectedly, read the underlying legal text to understand whether the rule applies to your specific invoice type
You can explore every rule, its classification, legal source, and hash in the Rule Explorer.
Proven by conformance testing against KSeF
We submitted 256 test invoices to the official KSeF test environment
(api-test.ksef.mf.gov.pl)
and compared KSeF's verdicts with ours. The results: 0 false negatives in conformance v9 (we catch
everything KSeF catches) and 107 additional rules that KSeF does not enforce —
55 legal requirements and 52 best-practice and security checks.
This proves that KSeF is primarily an XSD schema validator — it does not check VAT arithmetic, cross-field dependencies, or most business logic rules from the VAT Act. Pre-validation with KSeF Guard catches these 107 additional issues before they become audit liabilities.
Read the full analysis: Why KSeF Guard Catches More Than KSeF.
Catch rejections before they happen. KSeF Guard validates locally, instantly, with full legal traceability.
Download KSeF Guard