How to link advance and final invoices in KSeF correctly?

Linking advance and final invoices under the KSeF FA(3) schema requires precise field mapping. The settlement invoice ROZ must carry the full order values in its lines, while field P_15 holds only the remaining balance. You must link the documents using the mandatory KSeF identifier of the advance invoice.

8 min read 23 views
How to link advance and final invoices in KSeF correctly?

An advance invoice calculates VAT backwards

An advance invoice (faktura zaliczkowa) documents a gross amount received, not a net sale. The tax is derived using the formula in Article 106f(1)(3) of the VAT Act, the "in the hundred" method:

KP = (ZB × SP) / (100 + SP)

KP - tax amount
ZB - payment received (gross)
SP - tax rate

A PLN 10,000 prepayment at 23% yields PLN 1,869.92 in tax and a PLN 8,130.08 taxable base. That reverses the usual direction, where you start from net and add VAT. The tax point arises when the money arrives, not when the document is issued.

The advance invoice is due no later than the 15th day of the month following receipt of the payment (Article 106i(2)) and no earlier than 60 days before receipt (Article 106i(7)(2)).

Beyond the amounts, the advance invoice must carry the order or contract details: the name of the goods or service, quantity, net value, rates, tax amounts, and the total order value including tax. In FA(3) this is the Zamowienie element, with the WartoscZamowienia field and ZamowienieWiersz rows. The field-by-field description is in the Polish Ministry of Finance guide to the FA(3) structure.

Splitting the prepayment across VAT rates is where cents come from

The trouble starts when an order mixes rates. The prepayment is a single amount, but VAT has to be reported per rate. Standard practice is to allocate it in proportion to the gross structure of the order.

Take an order covering a service of PLN 20,000 net at 23% and goods of PLN 10,000 net at 8%. That is PLN 30,000 net, PLN 5,400 VAT, PLN 35,400 gross. The customer pays PLN 10,000 up front.

Rate Gross share Prepayment gross VAT in the hundred Prepayment net 23% 24,600 / 35,400 6,949.15 1,299.43 5,649.72 8% 10,800 / 35,400 3,050.85 225.99 2,824.86 Total 10,000.00 1,525.42 8,474.58

The last row absorbs the rounding remainder, so the shares add up to exactly PLN 10,000.00. It is the same rule we apply in the Biurko codebase whenever an amount is split across multiple rows.

The final invoice: what you show and what you subtract

Article 106f(3) is explicit. The sum of the values of the goods or services is reduced by the value of the part-payments received, and the tax amount is reduced by the sum of the tax shown on the advance invoices. The operative word is "reduced". Not "recalculated".

Continuing the example:

Rate Order net Advance net Net on final invoice Order VAT Advance VAT VAT on final invoice 23% 20,000.00 5,649.72 14,350.28 4,600.00 1,299.43 3,300.57 8% 10,000.00 2,824.86 7,175.14 800.00 225.99 574.01 Total 30,000.00 8,474.58 21,525.42 5,400.00 1,525.42 3,874.58

Here is the trap. Apply 23% to PLN 14,350.28 and you get PLN 3,300.56. Subtracting as the statute requires gives PLN 3,300.57. The gap is one cent, but it is the cent that puts your sales register and your JPK_V7 filing out of step with the advance invoice. Subtraction is the correct method.

In FA(3) the settlement invoice carries RodzajFaktury = ROZ and is filled in like this:

  • FaWiersz holds the full order or contract values, meaning PLN 20,000 and PLN 10,000 net,

  • P_13_1 with P_14_1 and P_13_2 with P_14_2 hold the totals after the advance has been deducted,

  • P_15 holds the amount left to pay, PLN 25,400.00 in our example.

This is the only document type where the sum of the line items deliberately differs from the net totals in the header section. The Ministry guide states this directly in the description of P_15 and in the notes on the FaWiersz element. If your software enforces equality between the two, it will produce a document that looks fine as a PDF and is substantively wrong.

In FA(3) the link lives in the FakturaZaliczkowa element, which can repeat up to 100 times on a single settlement invoice. The rule is simple and easy to get backwards:

  • advance issued through KSeF: fill NrKSeFFaZaliczkowej and omit both NrKSeFZN and NrFaZaliczkowej,

  • advance issued outside KSeF: set NrKSeFZN to 1 and put your own invoice number in NrFaZaliczkowej.

The KSeF identifier and the invoice number are two separate numbering spaces. Putting your own number in the KSeF field will not fail XSD validation, but it breaks the link on the buyer's side.

There is a separate case for prepayments predating mandatory KSeF. Settlement invoices are issued under FA(3) even when the advance invoice was created before 1 February 2026 under FA(2) or FA(1). In that case you will normally use the NrKSeFZN and NrFaZaliczkowej pair.

Three cases where the final invoice looks different

The advance covered 100% of the order. No final invoice is issued. If there were several advances that jointly cover the whole payment, the last one must list the numbers of the earlier ones, per Article 106f(4). In FA(3) that last document is still flagged ZAL.

Prepayment and delivery in the same month. Since 1 September 2023, Article 106b(1a) removes the obligation to issue a separate advance invoice when the payment was received in the same month the transaction was performed. You then issue a single document, extended with the data listed in Article 106e(1a), flagged in FA(3) as ROZ. The dates and amounts of the individual payments go into the ZaliczkaCzesciowa element, fields P_6Z and P_15Z.

Several advances under one settlement invoice. Repeat the FakturaZaliczkowa element for each one. The settled amounts must not exceed the order value, and each advance can be settled only once. Biurko enforces this with a validation rule that sums the amounts already settled by sibling settlement invoices and compares them against the advance value after any correction.

Corrections: KOR_ZAL and KOR_ROZ

A correction to an advance invoice carries its own flag, KOR_ZAL; a correction to a settlement invoice carries KOR_ROZ. In both, field P_15ZK holds the pre-correction amount: the payment amount for an advance, the outstanding balance for a settlement.

Two things are worth remembering. First, a correction to a settlement invoice has to restate the same advance links as the original, or the FakturaZaliczkowa element disappears from the XML and the correction loses a legally required reference. Second, the corrective note (nota korygująca) was abolished on 1 February 2026, so a wrong buyer tax ID (NIP) on an advance invoice calls for a correction to zero and a fresh document, not an annotation.

Checklist before you submit to KSeF

  1. Confirm the advance invoice carries the order details together with the gross value of the whole order.

  2. Split the prepayment across VAT rates in proportion to the gross structure of the order, assigning the rounding remainder to the last row.

  3. Calculate VAT with the in-the-hundred formula from Article 106f(1)(3), separately for each rate.

  4. On the final invoice, subtract the advance net and VAT from the order values instead of recalculating tax on the remaining balance.

  5. Make sure the settlement invoice line items show full order values and that P_15 shows only the outstanding amount.

  6. Put the advance's KSeF identifier in NrKSeFFaZaliczkowej, and your own number only if the advance was issued outside KSeF.

  7. Verify that the settled advances do not exceed the order value and that both documents use the same currency.

Summary

Settling a prepayment involves three independent layers: the reverse VAT arithmetic, the split across rates, and the document link inside the FA(3) structure. Each can break on its own, and the error usually surfaces only when KSeF rejects the file or when the VAT return fails to reconcile.

In Biurko a settlement invoice cannot be created without pointing to at least one issued advance invoice, and the system checks the settlement cap, the currency, and the buyer identity for you. The KSeF number is filled in automatically when the advance went through the system. Create a free account at biurko.io and try it against a real order of yours.

FAQ

Do I always have to issue a final invoice after a prepayment?

No. If one or several advance invoices covered the entire payment for the order, no settlement invoice is required. The obligation only arises when an amount remains to be settled after delivery or completion of the service.

What is the KSeF code for a final invoice?

In FA(3) the settlement invoice carries the value ROZ in the RodzajFaktury field. This applies to invoices issued under Article 106f(3) of the VAT Act and to invoices where no separate advance document was issued because payment and delivery fell in the same month.

What goes into field P_15 on a settlement invoice?

The amount still due after the advances have been taken into account, not the value of the whole order. The line items show the full order values, while P_15 holds only the outstanding balance.

Does the final invoice have to quote the KSeF number of the advance?

Yes, if the advance invoice was issued through KSeF. In that case you fill the NrKSeFFaZaliczkowej field. If the advance was issued outside the system, set NrKSeFZN to 1 and give your own invoice number in NrFaZaliczkowej.

How is VAT on a prepayment calculated?

Using the in-the-hundred method, KP = ZB × SP / (100 + SP), where ZB is the gross amount received and SP is the tax rate. For a PLN 10,000 prepayment at 23%, the tax is PLN 1,869.92 and the taxable base PLN 8,130.08.


Tags

#KSeF
Share

Previous article

How to issue a collective correcting invoice in KSeF?

Stay in the Loop

Get notified when we publish new articles — no newsletter, unsubscribe anytime.

We respect your privacy. Unsubscribe at any time.

Cookies

Essential ones keep the service running. The rest only with your consent. Cookie Policy