KSEF-007:KSeF date format invalid — wrong date or timestamp serialisation
Fix: Normalise every calendar-date field (P_1, P_6, P_6A, due dates) to YYYY-MM-DD and serialise DataWytworzeniaFa as a full timestamp with an explicit UTC designator, e.g. 2026-06-16T09:30:00Z or 2026-06-16T11:30:00+02:00. Do the formatting at serialisation time with an invariant/ISO formatter rather than the system locale. Keep the calendar value (P_1) independent of the timestamp's time zone — P_1 is evaluated by KSeF in Europe/Warsaw, so derive it from the Warsaw-local date. Invoice Navigator normalises these deterministically, which is why the fix confidence is high. Upload your invoice to fix this automatically.
KSEF-007 is raised when a date or timestamp in an FA(2)/FA(3) e-invoice does not match the format the KSeF (Krajowy System e-Faktur) XSD requires. The Polish schema uses two different date types: plain calendar dates such as P_1 (data wystawienia / issue date), P_6 (sale date) and the due date must be xs:date in YYYY-MM-DD form, while DataWytworzeniaFa (the technical document creation timestamp in the header) must be a full xs:dateTime with a UTC time-zone designator. Any other shape — a localised 15.04.2026, a slash date, a two-digit year, a date-only value placed in DataWytworzeniaFa, or a timestamp missing its Z / +02:00 offset — is rejected before the business checks even run.
Engine Classification
Structural normalization · No financial impact · Safe deterministic remediation
Confidence: 90% · Applied automatically in pipeline
What is KSEF-007?
KSEF-007 is a fatal validation rule defined in the KSeF specification (POL national rules). It validates the 2026 — written straight into a P_xx field that expects 2026-04-15. (2) DataWytworzeniaFa serialised as a date only (2026-04-15) when the element is xs:dateTime and needs a time component. (3) DataWytworzeniaFa serialised as a naive local timestamp (2026-04-15T09:30:00) with no time-zone designator — KSeF requires either Z (UTC) or an explicit offset such as +02:00. (4) Two-digit years or zero-padded-but-reordered components produced by a locale-aware date formatter. Because P_1 is xs:date and DataWytworzeniaFa is xs:dateTime, putting one in the other's element is a frequent, easy-to-miss mistake. element under 15 in the UBL invoice XML.
When this rule fires, the invoice is rejected by Peppol access points and never reaches the buyer.
Target path: The schema is strict about ISO 8601 and most failures come from the ERP serialising dates the way a Polish or German locale displays them. The four recurring shapes are: (1) localised display formats — 15.04.2026, 15-04-2026 or 04/15/2026 — written straight into a P_xx field that expects 2026-04-15. (2) DataWytworzeniaFa serialised as a date only (2026-04-15) when the element is xs:dateTime and needs a time component. (3) DataWytworzeniaFa serialised as a naive local timestamp (2026-04-15T09:30:00) with no time-zone designator — KSeF requires either Z (UTC) or an explicit offset such as +02:00. (4) Two-digit years or zero-padded-but-reordered components produced by a locale-aware date formatter. Because P_1 is xs:date and DataWytworzeniaFa is xs:dateTime, putting one in the other's element is a frequent, easy-to-miss mistake.
Why This Error Matters
Polish B2B e-invoicing runs through KSeF under the national mandate. A document KSeF will not accept is not legally issued for VAT — a schema-level date error blocks the invoice at the gateway.
KSEF-007 is a hard failure — the invoice must be corrected and re-sent before it can reach the recipient.
Invoice Navigator can automatically correct this error in your pipeline. The fix is applied with full audit evidence, so your compliance trail remains intact.
Validator Behavior
- ·Causes invoice rejection
- ·Error returned: KSEF-007
- ·Specification: KSeF
How to Fix It
Before / After
<P_1>15.04.2026</P_1> <DataWytworzeniaFa>2026-04-15</DataWytworzeniaFa>
<P_1>2026-04-15</P_1> <DataWytworzeniaFa>2026-04-15T09:30:00Z</DataWytworzeniaFa>
Technical Reference
The schema is strict about ISO 8601 and most failures come from the ERP serialising dates the way a Polish or German locale displays them. The four recurring shapes are: (1) localised display formats — 15.04.2026, 15-04-2026 or 04/15/2026 — written straight into a P_xx field that expects 2026-04-15. (2) DataWytworzeniaFa serialised as a date only (2026-04-15) when the element is xs:dateTime and needs a time component. (3) DataWytworzeniaFa serialised as a naive local timestamp (2026-04-15T09:30:00) with no time-zone designator — KSeF requires either Z (UTC) or an explicit offset such as +02:00. (4) Two-digit years or zero-padded-but-reordered components produced by a locale-aware date formatter. Because P_1 is xs:date and DataWytworzeniaFa is xs:dateTime, putting one in the other's element is a frequent, easy-to-miss mistake.Code Example
P_1 is xs:date and must be a plain ISO calendar date (YYYY-MM-DD). DataWytworzeniaFa is xs:dateTime and must carry a time plus a UTC designator (Z) or explicit offset. Both errors are deterministic to reformat.Common Causes
- ·The schema is strict about ISO 8601 and most failures come from the ERP serialising dates the way a Polish or German locale displays them.
Seeing this in production? The API handles KSEF-007 automatically. See the fix response →
Frequently Asked Questions
ISO 8601. Calendar-date fields like P_1 and P_6 must be YYYY-MM-DD (xs:date). The header field DataWytworzeniaFa is xs:dateTime and must include a time and a UTC designator, e.g. 2026-06-16T09:30:00Z.
They are different XSD types. P_1 is a date; DataWytworzeniaFa is a dateTime. A bare date is valid for one but not the other, which needs a time component and a time-zone offset or Z.
No. DataWytworzeniaFa is xs:dateTime, so 2026-04-15 fails. Use a full timestamp with Z or an offset, such as 2026-04-15T09:30:00Z.
Yes, in the common cases. A date in any recognisable locale is reformatted to the correct ISO type for the target element, and a missing time-zone designator on DataWytworzeniaFa is added. Confidence is 0.9.
From Warsaw-local time. KSeF evaluates the issue date in Europe/Warsaw, so deriving P_1 from a UTC instant can shift it by a day around midnight.
Related Errors
Related Content
Last updated: 16 June 2026
Validate your invoice
Drop your XML here to check for KSEF-007
Auto-fix KSEF-007 in seconds
Upload your invoice and we fix this error automatically. Financial fields are never touched.