Poland · KSeF FA(3): e-invoice formats and rules
Use this page to choose the Poland · KSeF FA(3) check, identify the fixed package and follow diagnostic examples before sending an invoice to its recipient.
Formats and syntax
The Ministry of Finance publishes FA(3) as the logical structure for Polish structured invoices, with the official pattern in repository entry 13775. It is a Polish XML format, distinct from UBL and CII. Moving UBL elements into a Faktura wrapper does not convert their meaning into FA(3). The official FA(3) documentation contains the field descriptions and example files needed to produce a document in the correct namespace and element order.
Rules XSDHub applies
The Polish engine pins FA(3) 1-0E from CRD 13775 and runs XSD 1.0 validation. This deliberately limited check detects structural constraints, permitted values and data types expressed in the schema. It does not calculate tax, verify arithmetic consistency, validate a taxpayer’s authority or reproduce the KSeF application’s acceptance rules. A successful schema result therefore only describes the selected XSD layer; there is no hidden full KSeF certification behind that result.
Who this affects
KAS describes the phased business obligation and the exceptions for smaller taxpayers in its implementation guidance. B2B means an invoice between businesses; issuing and receiving through KSeF also involves roles, permissions and the applicable exceptions. An authority buying from a supplier is a B2G context, but that label alone does not identify all requirements. Use the Ministry’s scope guidance for the actual transaction instead of assuming every Polish invoice follows one identical process.
Common errors to investigate
- FA(3) namespace — Use the namespace of the published FA(3) schema; an older FA(2) namespace selects a different document structure.
- Element order — Compare the sequence of children with the schema instead of adding an optional field at an arbitrary position.
- Invalid data type — Check the literal date or number representation before treating a type error as a tax calculation problem.
| Check | XSDHub coverage |
|---|---|
| XML structure and fixed rules | KSeF FA(3) 1-0E / CRD 13775; XSD 1.0 only |
| Certification and legal acceptance | Not provided |
| Government portal submission | Not provided |
| Peppol | Not supported yet |
Working with the result
Download or export the actual Faktura XML and keep the schema version in your reproduction notes. Resolve the first structural failure before reviewing later findings, since a misplaced parent can produce several child errors. After a passing XSD report, continue with your own business checks and the official KSeF exchange process. These diagnostic examples are selected to explain the checker’s limits, not to claim a measured frequency of Polish customer errors.