FA(3) field reference

P_1 in FA(3): invoice issue date

How to fill P_1 (data wystawienia) in a KSeF FA(3) invoice: date format, timezone rules, common mistakes and a valid XML example.

Updated

Overview

P_1 is the invoice issue date ("data wystawienia" in Polish). It is a required field inside the Fa section of the FA(3) XML and records the calendar date on which the invoice is issued. The value must be a valid ISO 8601 date in the form YYYY-MM-DD — for example, 2026-10-12 for 12 October 2026.

What P_1 is (and is not)

P_1 is not the same as DataWytworzeniaFa. DataWytworzeniaFa lives in the Naglowek (header) and records the exact moment the XML document was generated, typically an ISO 8601 timestamp such as 2026-10-12T07:23:07Z. P_1, in contrast, is the business date of the invoice. The two usually fall on the same day, but they describe different things, and mixing them up is a common integration bug.

Three practical rules. First, send P_1 as a date, never as a timestamp. Second, use the date the invoice becomes effective for the buyer; for a software subscription that is usually the start of the billing period. Third, keep P_1 stable together with P_2 (the invoice number) so invoices sort and archive consistently.

Timezone and year-end edge cases

There is no timezone in P_1, and that is deliberate. You send only the date, so you never need to convert between UTC and local time for this field. The one place where timezones still matter is DataWytworzeniaFa, which is a timestamp; P_1 stays a plain date. At year-end, watch the boundary carefully: an invoice generated on 31 December and issued on 2 January must carry the 2 January date in P_1, not the generation date. Getting this right keeps your numbering and VAT periods aligned with the calendar the tax office expects.

Where P_1 appears downstream

P_1 appears in three places after the invoice is accepted. The KSeF verification QR code renders it as DD-MM-YYYY, the official register indexes the invoice by the seller NIP together with P_1 and P_2, and the Notaly PDF prints it in the invoice header. Because the date is used for identification and not only for display, a stable and correct P_1 matters even after the invoice leaves your system.

Common mistakes

  • Sending a timestamp instead of a date.
  • Using the localised Polish format (12.10.2026) instead of ISO 8601.
  • Copying DataWytworzeniaFa into P_1 without converting it to a date.
  • Leaving P_1 empty because the invoice "will be dated later".

All four cause a validation error. The Notaly API validates this field on the way in, so a bad value is caught early and does not consume one of your three free sandbox invoices.

A complete, valid FA(3) example appears below. Change the seller and buyer to your own test data and submit it to the KSeF TEST environment through the Notaly API.

<Faktura xmlns="http://crd.gov.pl/wzor/2025/06/25/13775/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Naglowek>
    <KodFormularza kodSystemowy="FA (3)" wersjaSchemy="1-0E">FA</KodFormularza>
    <WariantFormularza>3</WariantFormularza>
    <DataWytworzeniaFa>2026-10-12T07:23:07Z</DataWytworzeniaFa>
    <SystemInfo>einvoice-api</SystemInfo>
  </Naglowek>
  <Podmiot1>
    <DaneIdentyfikacyjne><NIP>2745013933</NIP><Nazwa>Example Sp. z o.o. (FICTIONAL)</Nazwa></DaneIdentyfikacyjne>
    <Adres><KodKraju>PL</KodKraju><AdresL1>ul. Testowa 1, 00-001 Warszawa</AdresL1></Adres>
  </Podmiot1>
  <Podmiot2>
    <DaneIdentyfikacyjne><NIP>1234563218</NIP><Nazwa>Test Customer S.A. (FICTIONAL)</Nazwa></DaneIdentyfikacyjne>
    <Adres><KodKraju>PL</KodKraju><AdresL1>ul. Probna 2, 30-001 Kraków</AdresL1></Adres>
    <JST>2</JST>
    <GV>2</GV>
  </Podmiot2>
  <Fa>
    <KodWaluty>PLN</KodWaluty>
    <P_1>2026-10-12</P_1>
    <P_2>FV/2026/10/001</P_2>
    <P_13_1>1000.00</P_13_1><P_14_1>230.00</P_14_1>
    <P_13_2>301.00</P_13_2><P_14_2>24.08</P_14_2>
    <P_15>1555.08</P_15>
    <Adnotacje>
      <P_16>2</P_16><P_17>2</P_17><P_18>2</P_18><P_18A>2</P_18A>
      <Zwolnienie><P_19N>1</P_19N></Zwolnienie>
      <NoweSrodkiTransportu><P_22N>1</P_22N></NoweSrodkiTransportu>
      <P_23>2</P_23>
      <PMarzy><P_PMarzyN>1</P_PMarzyN></PMarzy>
    </Adnotacje>
    <RodzajFaktury>VAT</RodzajFaktury>
    <FaWiersz>
      <NrWierszaFa>1</NrWierszaFa>
      <P_7>SaaS subscription - October</P_7>
      <P_8A>pcs.</P_8A>
      <P_8B>1</P_8B>
      <P_9A>1000.00</P_9A>
      <P_11>1000.00</P_11>
      <P_12>23</P_12>
    </FaWiersz>
    <FaWiersz>
      <NrWierszaFa>2</NrWierszaFa>
      <P_7>Support</P_7>
      <P_8A>hrs.</P_8A>
      <P_8B>2</P_8B>
      <P_9A>150.50</P_9A>
      <P_11>301.00</P_11>
      <P_12>8</P_12>
    </FaWiersz>
  </Fa>
</Faktura>

Sources

Source: crd.gov.pl

Frequently asked questions

Is P_1 mandatory in every FA(3) invoice?

Yes. P_1 is a required field inside the Fa section of every FA(3) invoice sent to KSeF.

What date format does P_1 use?

ISO 8601: YYYY-MM-DD, for example 2026-10-12 for 12 October 2026.

Does P_1 include a time or timezone?

No. P_1 is a plain calendar date. Timestamps appear only in DataWytworzeniaFa in the header.

Issue your first KSeF test invoice today

Create a sandbox account: API key in seconds, 3 free test invoices on KSeF TEST, no credit card.