Skip to content
All Articles

FA(2) to FA(3) Migration Guide

Poland's Ministry of Finance replaced the FA(2) e-invoice schema with FA(3) (version 13775). This guide covers what changed, what's new, what was removed, and common mistakes during migration. KSeF Guard validates against FA(3) exclusively.

FA(2) to FA(3) Migration Guide

What changed from FA(2) to FA(3)?

FA(3) is not a minor revision. It restructures several sections, adds new mandatory elements, removes deprecated fields, and tightens validation rules. If your invoicing system was built for FA(2), a direct XML mapping will likely produce invalid invoices.

Key Numbers

v13775

Schema version

47

New elements

12

Removed elements

23

Changed constraints

New mandatory elements in FA(3)

These elements did not exist in FA(2) and must be present in FA(3) invoices:

Element XPath Purpose
RodzajFakturyFaktura/Fa/RodzajFakturyInvoice type code: VAT, KOR, ZAL, ROZ, UPR, KOR_ZAL, KOR_ROZ
P_1Faktura/Fa/P_1Invoice issue date (was in header, now in Fa section)
P_6Faktura/Fa/P_6Date of supply / completion (mandatory for most invoice types)
KodWalutyFaktura/Fa/KodWalutyCurrency code (ISO 4217) — always required, even for PLN
P_13_11Faktura/Fa/P_13_11Margin-procedure summary total bucket (new in FA(3))

Removed elements (breaking changes)

These elements existed in FA(2) but are no longer valid in FA(3). If your XML generator still emits them, KSeF will reject the invoice with an XSD validation error.

  • × NrKSeF and NrKSeFN — replaced by system-assigned reference numbers
  • × ZalszczegolneProcedury — old special procedure section
  • × Podmiot3 — third-party entity (restructured)
  • × Several P_* fields with changed numbering — see XSD diff below

5 most common migration mistakes

1. Missing KodWaluty on PLN invoices

In FA(2), currency was optional for domestic PLN invoices. In FA(3), KodWaluty is always required. Set it to "PLN" for domestic invoices.

2. Wrong RodzajFaktury value

FA(3) requires an explicit invoice type code. Using an invalid or missing value causes immediate rejection. Common error: using "FV" instead of "VAT".

3. P_14_*W fields missing on foreign currency invoices

FA(3) enforces PLN tax equivalents for every VAT bracket when currency is not PLN. This is caught by KSeF Guard rule BUS-003. See rule details

4. Line item field numbering changed

FA(3) renumbered several FaWiersz (invoice line) fields. P_8B (quantity), P_9A (unit price), P_11 (net value) — verify your field mappings match the new schema.

5. Date format and placement changes

P_1 (issue date) and P_6 (supply date) moved within the XML structure. Date validation is stricter: BUS-030 flags issue dates beyond the 30-day future window. BUS-168 covers far-future and pre-issue date limits.

How KSeF Guard catches FA(3) issues

KSeF Guard validates against FA(3) v13775 exclusively. It runs two layers of checks:

XSD Schema Validation

Full libxml2 validation against the official FA(3) XSD schema. Catches structural errors, missing elements, wrong types, and deprecated FA(2) elements instantly.

128 Active Validation Rules

Substantive compliance checks that go beyond schema validation. Rules include source-backed evidence appropriate to each rule class. Browse all rules

Validate your FA(3) invoices before submission

Download KSeF Guard