KSeF E-Invoice Format & Mandatory Data

• Header (Nagłówek): Contains metadata about the invoice as a document – notably the date and time the XML file was generated, the schema version in use, and (optionally) an identifier of the software that created it. The header also includes the formal invoice issue date (field P_1) and the invoice sequence number assigned by the issuer (field P_2). (These are described more below.) [ksef.podatki.gov.pl]
• Seller (Podmiot1) and Buyer (Podmiot2): These sections contain the identification details for the seller (the taxpayer issuing the invoice) and the purchaser. Each includes the party’s tax ID, name, and address in a structured form. For most businesses, the tax ID is the NIP (Polish VAT number), but the schema also has fields for an EU VAT number and other national IDs to accommodate foreign entities. We’ll dive into these fields shortly. [ksef.podatki.gov.pl] [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
• Invoice Content (Fa): This is the core section that breaks down the transaction. It contains the list of invoice line items (each in a sub-element called FaWiersz), where each line has details like description, quantity, unit price, and VAT rate. It also contains the invoice-level summaries of the sale, such as the total net amount and total tax for each VAT rate (fields P_13_x and P_14_x). Additionally, the Fa section encompasses related information like payment terms, delivery or transaction conditions, references to orders or contracts, and any required notes or annotations mandated by law. [ksef.podatki.gov.pl], [ksef.podatki.gov.pl] [ksef.podatki.gov.pl]
• Footer (Stopka): An optional section for any remaining invoice information not covered above. In practice, this might include the seller’s registry numbers (like KRS or REGON in Poland) or a general comments field if needed. It’s not heavily used for standard compliance data, since most required notes (e.g., “Reverse charge”) have dedicated fields in the Adnotacje (annotations) segment of Fa. [ksef.podatki.gov.pl]
• Attachment (Załącznik): Another optional section that can hold structured attachments to the invoice. The FA(3) schema (effective 2026) newly allows adding data blocks or tables here. This is meant for complex data sets that would clutter the main invoice – for example, an energy invoice’s detailed consumption breakdown can be put in an attachment block. Attachments in this context are not external files like PDFs, but rather embedded XML data blocks formatted as tables or text. (The new schema does support embedding PDF/image files in a limited way, but primarily for specific use cases; generally, everything is meant to be captured as data.) [ksef.podatki.gov.pl]

• Third-Party Entity (Podmiot3): This section is used if there is another party related to the invoice besides the main seller and buyer. For instance, if an invoice involves multiple buyers (split payment between two companies), one of them will be Buyer (Podmiot2) and the other can be listed as an “Additional purchaser” in Podmiot3 with a role code. Podmiot3 can repeat up to 100 times to list many parties if needed, each with a role (such as “recipient of goods”, “third party billing agent”, etc.). Typically, Podmiot3 isn’t used in simple one-seller/one-buyer scenarios. [ksef.podatki.gov.pl] [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
• Authorized Issuer (PodmiotUpoważniony): A conditional section for when the invoice is issued by someone on behalf of the taxpayer. This could be a fiscal representative, an attorney, or a bailiff (for enforced sales) acting as the invoicing entity under Polish law. PodmiotUpoważniony includes that entity’s identifying details and their role code (e.g., “tax representative”). It’s only used if applicable – for example, in self-billing cases one might think the buyer is an “issuer”, but KSeF handles self-billing differently (as explained later, via a flag rather than treating the buyer as PodmiotUpoważniony). [ksef.podatki.gov.pl] [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]

Seller & Buyer Identification (Podmiot1 & Podmiot2)

• Seller (Podmiot1): This section carries the seller’s official details. The Tax Identification Number (NIP) of the seller is the critical field here. It must be provided exactly, as it is used by KSeF to verify the issuing taxpayer’s authorization – if the seller’s NIP is missing or wrong, the invoice cannot be issued in KSeF. Alongside the NIP, the seller’s name or company name is included (Nazwa) and the address is broken into structured subfields (country code, street, city, postal code, etc.). The address fields are usually filled according to the seller’s registered business address. Optionally, other seller identifiers can be provided: for example, if the seller is part of a VAT Group, there may be a group identifier, or a GLN (Global Location Number) can be given if used in trade – but these are not common requirements for domestic invoices. [ksef.podatki.gov.pl] [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
• Buyer (Podmiot2): Similarly, this section contains the purchaser’s information. For B2B transactions within Poland, the buyer’s NIP should be captured here if the buyer is a Polish taxpayer. (Notably, the KSeF system uses the buyer’s NIP to make the invoice available to that buyer’s account. If a Polish business customer’s NIP isn’t entered in the NIP field, they won’t see the invoice in KSeF – hence the schema note that the buyer’s Polish NIP must go in the NIP field, not just as an EU VAT or other ID.) The buyer section also has fields for an EU VAT number: these consist of a country prefix (KodUE) and the number (NrVatUE) for cases where the buyer is an EU business with a VAT ID in their own country. If the buyer doesn’t have a VAT number (e.g., a private individual or a small entity not registered for VAT), the schema provides an “No ID” flag (BrakID) which can be set to “1” to indicate a buyer without tax ID. In such cases, you would still provide the buyer’s name and address, but leave tax ID fields empty and mark BrakID=1. [ksef.podatki.gov.pl]
  The buyer’s name and address are included here just like for the seller, under analogous fields. If the buyer is foreign and uses some other tax number (for instance, a US company with an EIN, or any foreign taxpayer ID), the schema has a generic field NrID for “other ID” plus a country code (KodKraju) to specify the country of that ID. This flexibility allows non-Polish, non-EU customers to be identified in a structured way. [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
• Additional Buyer Details: In some cases, invoices might list multiple buyers or a buyer and an “ordered by” party separately. If the invoice lists more than one purchaser (for example, two companies splitting the cost), one is entered in Podmiot2 and the others can be in Podmiot3 with the role code “4” (meaning additional purchaser). There’s also a provision for an internal Purchaser ID (IDNabywcy) to link buyer data on a corrective invoice if the buyer’s details changed between the original and correction, but for a normal invoice this isn’t used. Generally, for each entity, you can also include contact info like an email or phone number in a DaneKontaktowe sub-element if needed (this is more relevant for Podmiot3 or PodmiotUpowazniony; for Podmiot1/2, contact fields may not be present or are rarely used since not legally required on invoices). [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]

Invoice Header Details (Nagłówek): Number, Dates, and Metadata

• Invoice Issue Date (P_1): This is the official date of issuance of the invoice, equivalent to the date that would appear on a paper invoice. In KSeF, there is an important nuance: if an invoice is transmitted online to KSeF immediately, P_1 will match the KSeF submission date. If the invoice is issued in an offline mode (e.g., during a KSeF downtime or using the 24h grace period) and sent to KSeF later, the law still considers the date in P_1 as the issue date. The system will accept that as long as it’s within allowed time frames. For practical purposes, P_1 is the date that will be used for VAT settlement deadlines, etc., so it’s critical that it is correct. The format is YYYY-MM-DD (e.g., 2026-02-01). [ksef.podatki.gov.pl] [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
• Invoice Number (P_2): This is the invoice’s sequential number or identifier assigned by the issuer within their invoicing sequence or series. It corresponds to the combination of numbers/letters that a company uses to uniquely identify the invoice (e.g., “2023/INV/0001”). The schema doesn’t split prefix and number; the entire string goes in P_2. A note in the schema explicitly clarifies that this is not the KSeF ID. The KSeF platform will assign its own long identification code to the invoice upon acceptance, but that KSeF code is separate and not to be confused with the invoice’s internal number. Essentially, P_2 is what you’d see on the invoice as “Invoice No. ____”. It remains a required field because Polish VAT law requires invoices to have an sequential number. [ksef.podatki.gov.pl]
• Place of Issue (P_1M): An optional field to specify the place where the invoice was issued. Traditionally, Polish invoices often include a place name (city) next to the date. In KSeF, you can include that in P_1M if desired, but it’s not mandatory to fill it. If used, it’s just a text field for the city or location. [ksef.podatki.gov.pl]
• Invoice Creation Timestamp (DataWytworzeniaFa): Separately from P_1, the schema records the date and time the XML file was generated in the system. This is in YYYY-MM-DDTHH:MM:SSZ format (UTC time). This timestamp (sometimes called the “creation date”) might differ from the issue date P_1. For example, you could generate the e-invoice file on Jan 5 but set P_1 as Jan 2 if you are back-dating within the allowed period. KSeF uses DataWytworzeniaFa for internal tracking and to enforce that offline invoices are uploaded within 24 hours if issue date and upload date diverge. Generally, this field is more of a technical metadata – it doesn’t appear on the printed invoice, but it’s recorded in the XML. [ksef.podatki.gov.pl] [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
• Schema Code and Version (KodFormularza, WariantFormularza): These fields identify which invoice schema is being used. For example, KodFormularza will be “FA” with an attribute like kodSystemowy=”FA(3)” and WariantFormularza might be “3” for version 3 of the schema. This is automatically handled by software; it ensures the tax authorities know how to interpret the file. [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
• System Information (SystemInfo): An optional field where the name of the software or system that generated the invoice can be provided. For instance, it might say “Comarch ERP v.X” or “SAP KSeF Module”. It’s not mandatory and is just for the taxpayer’s/reference use. [ksef.podatki.gov.pl]

Invoice Line Items: Description, Quantity, Price, Tax (Fa/FaWiersz)

• Line Number (NrWierszaFa): A sequential line number on the invoice. This is simply “1” for the first item, “2” for the second, and so on. It helps if you need to reference a specific line (for example, if providing additional info or correcting a particular line later). The numbering resets for each invoice. [ksef.podatki.gov.pl]
• Product/Service Name (P_7): The description of the item being invoiced. This field holds the name or description exactly as you’d want it to appear on an invoice (e.g., “Consulting services – January 2026” or “Steel bolts M8 (50mm)”). It can be up to 512 characters, and you can include necessary specifics here. Essentially, P_7 fulfills the requirement to specify what was supplied. [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
• Unit of Measure (P_8A) and Quantity (P_8B): P_8A is the unit of measure code (for example, “pcs” for pieces, “kg” for kilograms, “hour” for hours). You can use abbreviations or full names; the schema doesn’t strictly define the allowed values for unit, but commonly accepted units or their abbreviations are used. P_8B is the quantity of that unit delivered – it’s a numeric field that can have up to 3 decimal places by default, and more if needed for certain units. For example, P_8A = “m³” (cubic meters) and P_8B = 81 as in one schema example for water delivery. If the item is an intangible service sold as a lump sum, one might put “pcs” = 1 or a similar convention. [ksef.podatki.gov.pl]
• Unit Price Net (P_9A): This field is the net unit price of the item, i.e., price per unit excluding VAT. For instance, if one piece is priced at 100 PLN net, P_9A = 100. It can support up to 8 decimal places for precision if needed (for very small unit prices). If the line has a discount or rebate, the unit price would typically be the price after discount per unit. [ksef.podatki.gov.pl] [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
• Line Discount (P_10): If there’s any discount or rebate applied to the line (either as a value or percentage), it can be represented in P_10. This is optional; many invoices don’t explicitly list a discount field per line unless there’s a specific rebate. The schema allows you to express a discount as a negative amount or as a rate. For example, a 5% discount on the line could be shown by calculating the reduced unit price and possibly noting the discount elsewhere. P_10 is there to explicitly state a discount amount if needed (e.g., “-50” if 50 PLN off). [ksef.podatki.gov.pl]
• Net Amount (P_11) for the line: This is the total net value for that line (quantity × unit price, minus any discount). Some invoice schemas expect the sender to calculate and include the line net amount. It appears that KSeF’s FA(3) might derive it, but likely there is a field for it or it’s implicitly P_9A * P_8B minus P_10. In earlier versions, P_11 was the net amount. Regardless, KSeF will compute and cross-check the math. For clarity, one can assume the line’s net amount is indeed captured (either directly or by calculation of provided fields).
• VAT Rate (P_12) and Tax Category: The VAT rate applied to this line is indicated in P_12. If it’s standard rated, P_12 might be “23” (meaning 23% VAT). If reduced, “8” or “5” etc. For a 0% rate or an exemption, P_12 and possibly related fields in the Adnotacje section are used. Specifically, if an item is VAT-exempt, one wouldn’t put “0” here (zero-rate is different from exempt). Instead, P_12 might be left blank and an exemption note provided. However, the schema likely has codes for various cases: it references fields like P_13_6_x in the summary to categorize 0% ICS, 0% export, etc.. On the line item, if the item is subject to VAT, P_12 holds the percent. If it’s exempt or outside scope, there is a flag in Adnotacje/Zwolnienie to cover that (and possibly a field P_11A at line-level to mark no VAT charged on that line). The documentation indicates P_11A as a conditional field at line, likely meaning “VAT not charged under Art. …” for certain cases. [ksef.podatki.gov.pl] [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
• VAT Amount for the line: While not always printed on paper invoices, the schema can include the VAT amount per line (especially since rounding line by line vs overall can differ). P_11 might be used for that in older schema, but in FA(3) it might be structured differently. We do see that for summary, the tax is captured per rate in P_14_x, so per line VAT might actually be omitted to reduce redundancy, given the system can sum. But it’s possible that for each line, an internal field calculates VAT which sums up to P_14 totals. Whether explicitly present or not, the system will ensure that the sum of line net * rate = total VAT.
• Additional line details (optional): The schema allows extra descriptive fields per line if needed. For example, PKWiU or CN codes (Polish Goods Classification or Combined Nomenclature codes) can be provided for each item (there are fields for those, optional). If the item is a margin scheme or a second-hand good, a procedure code can be set at line level. In fact, GTU codes (Group of Goods/Services codes) that are used in JPK VAT reporting can be specified per line in the structured invoice as well. This isn’t mandatory for the invoice to be valid, but including them might help with the SAF-T (JPK) alignment. Additionally, if the delivery dates differ per line, P_6A at the line level can specify the performance/delivery date for that specific item. For instance, one line of services delivered on March 1 and another delivered on March 5 can each carry their own P_6A date. [ksef.podatki.gov.pl] [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]

VAT Breakdown and Totals (Podsumowanie Rozliczenia)

• Net amounts by VAT rate (P_13_x): There are separate fields for the total net sales value at each tax rate or category. For example:
  • P_13_1 – Net amount at the basic VAT rate (currently 23% in Poland). [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
  • P_13_2 – Net amount at the first reduced rate (8%). [ksef.podatki.gov.pl]
  • P_13_3 – Net amount at the second reduced rate (5%). [ksef.podatki.gov.pl]
  • P_13_4 – Net amount at the “third rate” (this was historically the 0% for taxis or some special flat rate, not commonly used). [ksef.podatki.gov.pl]
  • P_13_5 – Net amount under the special procedure of Chapter 6a Section XII of the Act (this corresponds to OSS – One Stop Shop – or other special VAT regimes like distance sales). [ksef.podatki.gov.pl]
  • P_13_6_x – Net amount at 0% rates, divided further:
    • P_13_6_1 for 0% domestic (e.g. certain internally zero-rated supplies under art 83(1)), [ksef.podatki.gov.pl]
    • P_13_6_2 specifically for 0% intra-Community supply of goods, [ksef.podatki.gov.pl]
    • P_13_6_3 for 0% export of goods. [ksef.podatki.gov.pl]
  • P_13_7 – Net amount of exempt sales (VAT zwolnione). [ksef.podatki.gov.pl]
  These fields appear as needed. If an invoice has only 23% items, you’ll fill P_13_1 with the sum of those net values and maybe none of the others. If it also had an 8% item, you’d fill P_13_2, etc. If a field is not applicable (zero), it might be omitted or set to 0 – the schema likely allows omission for clarity.
• VAT amounts by rate (P_14_x): Corresponding to each net category above, there are fields for the VAT amount:
  • P_14_1 – VAT amount on the P_13_1 net (23% category). [ksef.podatki.gov.pl]
  • P_14_2 – VAT on P_13_2 (8% net). [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
  • P_14_3 – VAT on P_13_3 (5% net). [ksef.podatki.gov.pl]
  • P_14_4 – VAT on P_13_4 (taxi lump sum or special rate). [ksef.podatki.gov.pl]
  • P_14_5 – VAT on P_13_5 (special OSS regime, if applicable). [ksef.podatki.gov.pl]
  • P_14_6_x – possibly for 0% categories (though 0% of course yields 0 VAT; instead of a VAT amount, 0% categories require legal basis notes rather than a number).
  • Actually, in the schema excerpt, it shows P_13_6 and P_13_7 for net 0% and exempt, but no P_14_6 since no VAT is due. Instead, the presence of P_13_6 or P_13_7 indicates those categories of sales, and the VAT amount fields for them are not applicable. (You wouldn’t have a “VAT amount” for exempt or 0% beyond 0).
  There are also fields P_14_1W, P_14_2W, etc. which come into play if the invoice currency is foreign. For instance, if you issued an invoice in EUR, Polish law requires you to report VAT also in PLN for official records. The fields P_14_1W would contain the VAT amount for 23% converted to PLN, while P_14_1 is the amount in the invoice’s currency. These “W” fields are filled when currency conversion is needed (they stand for “wartość” in PLN). The schema indicated up to P_14_3W similarly. [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
• Total Gross Amount: Interestingly, the schema doesn’t explicitly list a “P_15” for total gross in the excerpts we saw, but one exists implicitly by summing up all net + VAT. In older schema (FA(1) or FA(2)), P_15 was the “łączna kwota należności” (total amount due). It’s likely in FA(3) the total amount due is still present, perhaps encoded as part of the payment block or deduced. Many invoice software simply calculates Gross = Σ(net) + Σ(VAT). We should assume the total gross is either to be provided or is trivially calculated by KSeF. In any case, one must ensure the numbers add up: Σ P_13_i + Σ P_14_i = total gross.
• Handling of Corrections in Summary: If this is a corrective invoice (RodzajFaktury = KOR), the P_13/P_14 fields represent the adjustments rather than new totals. For example, on a credit note that gives a 100 PLN net refund of a 23% item, P_13_1 might be -100.00 and P_14_1 -23.00 (and gross effectively -123.00). The schema explicitly states for corrective invoices these fields hold “the amount of the difference”. For regular invoices, they hold the positive totals. [ksef.podatki.gov.pl], [ksef.podatki.gov.pl] [ksef.podatki.gov.pl]

• P_13_1 = 1000.00 (net at 23%),
• P_14_1 = 230.00 (VAT 23% on that net),
• P_13_2 = 500.00 (net at 8%),
• P_14_2 = 40.00 (VAT 8% on that net),
• Total gross = 1770.00 (which is 1000+500+230+40).

Payment Terms and Bank Information (Płatność)

• Payment Due Date (Termin Płatności): This appears as a sub-element where you can specify the due date for payment. There’s a field for the actual date (Termin) and also a structured way to describe the terms. For instance, you might either enter a concrete date (e.g., 2026-03-31) or use the description fields (TerminOpis) which allow a phrase like “14 days from invoice date”. The example in the schema shows TerminOpis broken into components: quantity = 14, unit = “days”, initial event = “from issue of the invoice”. This means you could either say “Payment due: 2026-04-14” or put terms as “14 days from issue”. Either way, it’s optional; if no credit is given (cash sale), you might omit this. [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
• Payment Method (Forma Płatności): A coded field indicating how the payment is or will be made. The schema defines codes 1 through 7: [ksef.podatki.gov.pl]
  • 1 = cash,
  • 2 = card,
  • 3 = voucher,
  • 4 = cheque,
  • 5 = credit (probably meaning on account/transfer after credit period),
  • 6 = bank transfer,
  • 7 = mobile payment. These cover common methods. If the method doesn’t fit these (e.g., barter or some unusual form), there is a flag PłatnośćInna that you set to “1” and then you can provide a custom description in Opis Płatności (for example, “compensation by offset of mutual liabilities”). Typically, most B2B invoices will use “6” for bank transfer. [ksef.podatki.gov.pl]
• Bank Account (Rachunek Bankowy): If payment is by transfer, you usually include your bank account number. The schema provides a RachunekBankowy element where you can specify:
  • NrRachunku (Account Number) – the IBAN or bank account number for payment,
  • NazwaBanku (Bank Name) – optional, could specify the bank’s name,
  • Opis Rachunku – a description if needed (like “Main account” or currency, etc.). You can repeat this element if multiple accounts are provided (up to 100 occurrences, though normally one is enough). There’s also RachunekBankowyFaktora if a factoring arrangement is in place – i.e., payment goes to a factor’s account. That would be used if the receivable was sold to a factoring company and they are collecting payment. [ksef.podatki.gov.pl]
• Payment Status Flags:
  • Zaplacono (Paid) flag – if the invoice amount has already been paid (typically relevant for an advance invoice or cash-on-delivery scenario). If you set Zaplacono = “1”, you should also provide DataZapłaty (Date of Payment) to indicate when the payment was made. For example, on an advance invoice, you might say it was paid on such date. [ksef.podatki.gov.pl] [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
  • Partial Payment Indicator (ZnacznikZapłatyCzęściowej): This flag can indicate if an invoice has been partially paid before issuance. It has values “1” for partially paid (still not fully paid) and “2” for fully paid in multiple partial payments. This is a nuance that allows the issuer to convey, for instance, “I have received some pre-payment”. It’s not commonly used unless tracking complex payment schedules within the invoice. [ksef.podatki.gov.pl]
• Partial Payment Details (ZapłataCzęściowa): If partial payments were received, you can list each one here (dates and amounts) up to 100 entries. Each entry includes KwotaZapłatyCzęściowej (amount paid) and DataZapłatyCzęściowej (date of that payment) and the method (you can specify method for each partial payment too). For example, if the customer paid two installments before invoicing, you’d list those two payments. [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
• Skonto (Discount) Terms: If you offer an early payment discount (skonto), there is an element to specify the conditions and amount of discount for early payment. This could outline “2% discount if paid within 7 days” or similar. It’s optional and only used if such terms exist on the invoice. [ksef.podatki.gov.pl]
• Payment Link and Identifier: The FA(3) schema introduced fields for a payment link (LinkDoPłatności) and an IPKSeF (KSeF payment identifier). These are meant to integrate with online payment systems. For instance, a seller could include a URL that the buyer can click to pay the invoice online, and an identifier that ties that payment to this invoice in the payment provider’s system. The example given is a link containing a unique 13-character code (IPKSeF) which encodes the payment request. While not mandatory, this is a modern feature to facilitate quick payments (imagine scanning the invoice and clicking “Pay now”). [ksef.podatki.gov.pl], [ksef.podatki.gov.pl] [ksef.podatki.gov.pl]

• TerminPlatnosci: Termin = (invoice date + 14 days) or TerminOpis (14 days from issue),
• FormaPlatnosci = 6 (bank transfer),
• RachunekBankowy: NrRB = that account number, maybe Bank name,
• Zaplacono = 2 (default meaning NOT paid by issuance – since “1” means paid; actually if not paid, you just leave it empty or as “2” meaning false),
• ZnacznikZaplatyCzesciowej = (not needed unless partial prepayments happened).

Additional Notes, References, and Attachments

• Order/Contract Reference (Zamówienie): Within the Fa section, there is a Zamówienie element where you can indicate an order or contract related to the invoice. This might include an order number and date, for instance. It wasn’t explicitly covered in our excerpts, but typically such fields exist so that buyers can match the invoice to their purchase order. If your invoice is based on PO #12345, you’d put that number and possibly date in this element. [ksef.podatki.gov.pl]
• Annotations (Adnotacje): This is a crucial section for any special tax notes or required statements. We touched on this with P_17, P_18, etc. The Adnotacje element can include:
  • Invoice Type (RodzajFaktury): As mentioned, KSeF explicitly classifies the invoice type: “VAT” for a standard sale invoice, “KOR” for a correction, “ZAL” for an advance payment invoice, “ROZ” for a final invoice that combines prior advances (in specified cases), “UPR” for a simplified invoice (per Art. 106e.5(3)), etc.. This field is important because it tells the system which extra fields to expect (e.g., an advance invoice might need P_6 (delivery date) to be filled with the date payment was received, a corrective needs original invoice refs, etc.) – and also ensures compliance (for example, marking “ROZ” when required). [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
  • Mandatory Invoice Notes: Polish law requires certain phrases in specific scenarios (these used to be written on invoices). Adnotacje covers them as boolean flags:
    • P_16 – “metoda kasowa” (cash accounting scheme). If the seller is under the cash accounting regime (VAT is due upon payment, not delivery), their invoices must be marked “metoda kasowa”. In KSeF, you put P_16 = 1 for yes, otherwise 2. [ksef.podatki.gov.pl]
    • P_17 – “samofakturowanie” (self-billing note). 1 means this is self-billed by the buyer. [ksef.podatki.gov.pl]
    • P_18 – “odwrotne obciążenie” (reverse charge note). 1 means the invoice should carry the note “reverse charge” (this applies to certain domestic reverse-charge cases that existed pre-2020, and intra-EU services where the customer is liable, etc.). [ksef.podatki.gov.pl]
    • P_18A – “mechanizm podzielonej płatności” (split payment mechanism). 1 means the invoice has to include the phrase “mechanizm podzielonej płatności” (mandatory for transactions over 15k PLN involving certain goods from Annex 15). [ksef.podatki.gov.pl]
  • Exemption Reason (Zwolnienie): If any items are VAT-exempt, the Zwolnienie sub-element is used to state whether the invoice contains exempt sales and to provide the legal basis. It includes:
    • P_19 – a flag if any exempt supplies under Art. 43(1) or Art. 113 (small taxpayer exemption) are present, [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
    • P_19A or others might specify which law exemption (e.g., “Art. 43(1)(XYZ)”).
    • Essentially, you fill in the exact legal clause or a code for it. For example, if exempt under Art. 43(1)(2) (financial services), you indicate that.
  • New Means of Transport (NoweŚrodkiTransportu): For intra-Community supply of new means of transport (like new cars, boats, planes sold across borders), EU law requires specific details on the invoice. The schema has fields for things like the vehicle’s production year, first use date, mileage, engine capacity, etc., under this element. These are filled only if applicable (e.g. selling a new car to another EU country). [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
  • Margin Scheme (Procedura Marży / PMarży): If the sale is under a margin scheme (e.g. second-hand goods, travel services), the invoice must be noted accordingly. The structured invoice has a P_Marży element for margin schemes, where it flags which margin scheme applies (tourism, second-hand goods, etc.) and ensures the phrase “procedura marży – …” is recorded. [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
• Footer (Stopka): In the Stopka element, one might include the seller’s registration numbers like:
  • REGON (National Business Registry number) or KRS (Court Register number) if relevant. These aren’t mandatory on invoices by law, but some companies include them. The schema likely has fields for those in Stopka. [ksef.podatki.gov.pl]
  • Any free-form additional info: Possibly a field for a general note or footer text if needed. However, since Adnotacje covers most regulated notes, the need for random comments is minimized.
• Attachments (Załącznik): The Załącznik element can hold an embedded data block. For example, an invoice for utilities might need to show a table of readings. The schema allows a data block with a header (ZNagłówek), some metadata, and a table of rows. This is quite advanced usage – essentially you can embed a mini spreadsheet in the XML. This isn’t commonly used for standard invoices, but it’s provided for industries that require it. Attachments could also theoretically be used to include a long list of item serial numbers or detailed specs without cluttering the main bill. Note that attachments are part of the structured data (not separate files like a PDF of terms and conditions – you’d instead incorporate that text as a data block). [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]

• If the invoice is self-billed: P_17=1 (and you have an agreement on file off-system).
• If the invoice has an entry subject to reverse charge (less common now domestically; for EU it’s usually the whole invoice would be without Polish VAT instead).
• If split payment is mandatory: P_18A=1 (the system ensures this note is present when needed by checking the goods codes, perhaps).
• If exempt: fill Zwolnienie with the legal basis.
• If margin scheme: tick that in PMarży.

Corrective Invoices and Credit Notes in KSeF

• Original Invoice Reference (DaneFaKorygowanej): This is a group of fields where you provide information about the invoice being corrected. It includes: [ksef.podatki.gov.pl]
  • NrFaKorygowanej (Corrected Invoice Number): The number of the original invoice that is being corrected. This should exactly match the invoice number as it was on the original. KSeF requires this regardless of whether the original was in KSeF or not. [ksef.podatki.gov.pl]
  • DataWystawieniaFaKorygowanej: The issue date of that original invoice. [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
  • KSeF Reference of Original: If the original invoice was issued through KSeF, you must indicate that and provide its KSeF ID.
    • There’s a flag NrKSeF set to “1” if the original was in KSeF, and then NrKSeFFaKorygowanej is used to input the actual KSeF identification number of the original invoice. [ksef.podatki.gov.pl] [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
    • Conversely, if the original was outside KSeF (e.g., a 2024 invoice before you joined KSeF, or issued when KSeF was down), you set NrKSeFN = 1 (non-KSeF original). In that case, you only fill the original number and date, and you do not provide any KSeF ID for it. [ksef.podatki.gov.pl]
  • These references ensure a clear link; the tax authorities can trace back the original record if needed. In KSeF, if the original had an ID, the correction references it, effectively linking the documents in the system.
• Original Seller/Buyer Details (Podmiot1K, Podmiot2K): If the correction is being made because something was wrong with the seller or buyer details on the original, those original details are captured here. [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
  • Podmiot1K would contain the seller info as it was on the original invoice. For example, maybe the seller’s address changed and the original had old address; Podmiot1K records what was originally stated so the correction can say “we correct the address to …”. If the correction isn’t about seller info, Podmiot1K isn’t used. [ksef.podatki.gov.pl]
  • Podmiot2K likewise holds the buyer’s info from the original invoice if you are correcting, say, a misspelled name or a wrong address for the buyer. It also has a field IDNabywcy to link if the buyer changed (e.g., buyer’s name changed due to company transformation). If buyer info wasn’t wrong, you don’t include Podmiot2K. [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
  • In most corrections (like correcting amounts), you won’t need Podmiot1K/2K — they’re only for correcting identification data. Including them is conditional on the nature of the correction.
• Reason for Correction (PrzyczynaKorekty): While Polish law (as of 2021) no longer mandates stating the reason for correction on the invoice (it says it “may include” the reason), the schema provides the PrzyczynaKorekty field to add a reason text if you want. It’s optional in KSeF (and optional by law indeed) and can be up to 256 characters. Typically you might fill it with something like “Zniżka posprzedażna 10%” (post-sale 10% discount) or “Zwrot towaru – 1 szt.” (return of goods – 1 piece) if you choose to inform the customer of the reason on the document. [ksef.podatki.gov.pl]
• Adjusted Values in Lines and Summary: In a corrective invoice, the line item section (FaWiersz) and summary (P_13/P_14) are used to reflect changes:
  • The correction can be shown either as difference values or by restating the corrected line fully (old vs new). The schema supports both methods. The more common approach (difference method) is: you include only those items that changed, with the amounts representing the increase or decrease. [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
  For example, if the original invoice had 5 items and you give a discount affecting item 3, the corrective invoice might include one line: “Item 3 – discount” with a negative net amount. Or if an entire item is returned, you list that item with negative quantity or amount.
  The summary P_13_x and P_14_x then will typically contain the net and VAT differences. So if gross was reduced by 123 PLN (100 net, 23 VAT), P_13_1 = -100, P_14_1 = -23. [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
  The schema explicitly mentions that for corrective invoices, these fields hold “the amount of the difference referred to in Article 106j sec. 2 item 5 of the Act” (that item of the law is exactly about the difference in tax). [ksef.podatki.gov.pl]
  If using the “before and after” method (less common), you’d populate a “StanPrzed” (state before) and “StanPo” (state after) perhaps in the attachment or lines, but this is usually only if multiple values change and you want clarity. The difference method is succinct and encouraged.
• Invoice Type for specific correction cases: Note there are special types like KOR_ZAL and KOR_ROZ in RodzajFaktury. [ksef.podatki.gov.pl]
  • KOR_ZAL is used when correcting an advance payment invoice.
  • KOR_ROZ for correcting a “ROZ” type final invoice. In general, though, “KOR” covers standard invoice corrections; these subtypes just provide extra clarity for advances.

• A credit note = a corrective invoice reducing the amount. It will have negative adjustments (or positive adjustments in favor of the buyer, meaning a refund or reduction).
• A debit note (increasing amount) also is a corrective invoice, but with positive adjustments (the buyer owes more).

Self-Billing and Third-Party Issuance (Roles in Invoicing)

• Roles remain the same: Even if the buyer issues the invoice, in the KSeF invoice Podmiot1 is still the seller (supplier) and Podmiot2 is the buyer. You do not swap them. The buyer, acting as issuer, will likely need to be authorized in KSeF to issue on the seller’s behalf (that’s handled via granting permissions to the buyer’s entity under PodmiotUpoważniony mechanism outside of the invoice content). But on the invoice itself, you wouldn’t list the buyer as Podmiot1. [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]
• Self-billing Indicator (P_17): To indicate that this invoice was issued by the buyer (self-billing), the P_17 field in Adnotacje is set to “1”. This essentially replaces the need to write “Self-billing” on the invoice. If P_17 = 1, the schema knows and the recipient knows that although the supplier is listed as seller, the physical issuance was by the purchaser. If P_17 = 2 (the default), it means it’s a normal invoice issued by the seller. [ksef.podatki.gov.pl], [ksef.podatki.gov.pl] [ksef.podatki.gov.pl]
• Approval outside KSeF: The schema note reminds that the procedure for the seller to approve these self-billed invoices is outside of KSeF’s scope. In practice, that means the buyer might send a copy for approval or there’s an agreement that all self-billed invoices are considered accepted unless rejected within X days. KSeF doesn’t manage that process; it just marks the invoice accordingly. [ksef.podatki.gov.pl]

• Tax Representative: In case of a foreign entity, a tax rep may issue invoices.
• Court Bailiff or Enforcement Authority: For enforced auctions/sales (Article 106c/d of the VAT Act), the bailiff issuing the invoice on behalf of the debtor (seller) must put their details.
• Other Authorized Party: A company might outsource invoicing to an accounting firm.

• **“UPR” invoice (RodzajFaktury = UPR)】: This is a simplified invoice (for sales <= 450 PLN or certain receipts) which has limited buyer info. In KSeF, if you mark UPR, likely Podmiot2 might be minimal (maybe just name, no NIP). It’s a niche case for B2C mostly.
• “ROZ” invoice (RodzajFaktury = ROZ): This is when no advance invoice was issued for a prepayment in the same month, so the final invoice carries a note that it includes an advance (this is per Art. 106f.3). The schema indicates to mark such invoices as ROZ. Essentially a ROZ invoice is a regular invoice that serves also as a settlement of an advance that wasn’t separately invoiced. [ksef.podatki.gov.pl], [ksef.podatki.gov.pl]

• Seller and buyer are correctly identified (with NIP or other IDs as needed).
• The invoice number is unique in your series and the dates are correct.
• Each line item has a clear name, quantity, unit, net price, and the correct VAT rate code.
• The summary matches the lines and includes each VAT rate used.
• Any required legal notes are set via the P_16/P_17/P_18 flags or exemption reason fields.
• If it’s a correction, the original invoice info is referenced.
• If it’s being self-billed or issued by an agent, the appropriate flags/sections are used.
• Payment info is included if relevant (to get you paid on time!).