KSeF and VAT Margin: How to Issue a Margin Invoice

A VAT margin invoice in KSeF is a structured FA(3) XML invoice, but it concerns a special method of taxation under Article 119 or Article 120 of the Polish VAT Act. KSeF does not create a new margin scheme and does not decide whether a transaction qualifies for it.

In FA(3), the margin-scheme annotations are central, including P_PMarzy and the appropriate detailed variant. The Ministry of Finance KSeF handbook also recommends P_13_11 for the total sales value under the margin scheme, but this field should not be described as a simple, unconditional requirement in every case without reviewing the specific structure.

The main operational risk is mixing four layers: the tax decision on eligibility for the margin scheme, the FA(3) XML invoice, a readable PDF visualization and JPK reporting codes such as MR_T and MR_UZ. These elements are connected, but they are not the same.

KSeFGPT can assist with imports, data checks, FA(3) XML, invoice searches and preparing information for accounting. It should not be treated as a tool that automatically qualifies a transaction for the VAT margin scheme.

This topic concerns businesses that issue invoices under special margin schemes: travel agencies, used-car dealers, second-hand shops, art dealers, galleries and businesses trading in collectors' items and antiques. In practice, the question is not only how to issue an invoice. It is also who confirmed eligibility and how that decision should be recorded correctly in FA(3).

This article reflects the position as of June 29, 2026. Its scope is deliberately narrow: it covers the invoice, FA(3) fields, the boundary with JPK reporting and the control process in a small business. It does not decide whether a specific item, vehicle or service qualifies for the margin scheme.

If you are still organizing the KSeF basics in your company, start with KSeF for small businesses. This article is the next step for businesses with a special invoice type that need to keep invoice data separate from the tax calculation.

1. How the margin scheme works under the Polish VAT Act

2. What a VAT margin invoice does not show the buyer

3. Map of a VAT margin invoice in FA(3)

4. Where the invoice ends and JPK reporting begins

5. Small-business process before submission to KSeF

6. Used-car dealer scenario

7. Common VAT margin errors

8. How KSeFGPT can help without making the tax decision

9. Expert perspective

10. Frequently asked questions

The table summarizes the main decisions and distinctions needed before issuing a VAT margin invoice through KSeF.

The Polish VAT Act contains two main margin-scheme areas relevant here. Article 119 covers travel services and provides that the taxable amount is the margin less the VAT due. Article 120 covers, among other items, supplies of second-hand goods, works of art, collectors' items and antiques.

For travel services, the margin is the difference between the amount payable by the customer and the actual cost of goods and services acquired from other taxable persons for the direct benefit of the traveler. For second-hand goods and related categories, Article 120 describes the margin as the difference between the selling price and purchase price, less the VAT amount.

Practical division: a travel agency checks Article 119, while a used-car dealer or second-hand shop checks Article 120. Technical condition: only after this decision can the FA(3) invoice be prepared correctly. Risk: the fact that an item is second-hand does not automatically make it eligible for the VAT margin scheme.

A business owner should separate the tax question from the technical question. The tax question is whether the transaction meets the conditions of the scheme. The technical question is how to record the invoice correctly in FA(3) after that decision.

Now that the boundary between Articles 119 and 120 is clear, consider what the buyer sees on the invoice itself.

A VAT margin invoice differs from an ordinary invoice because it does not show the buyer the standard breakdown of taxable amount and VAT used on a general invoice. The KSeF 2.0 handbook states that an invoice under the margin scheme does not include, among other details, the net unit price, net sales value, VAT rate, net sales totals by rate or VAT amounts on those totals.

This is logical because the margin is part of the seller's tax calculation. The buyer must receive an invoice with the correct margin-scheme wording, but should not receive a calculation that discloses the purchase price, margin and internal VAT on the margin.

Data visible to the buyer: invoice number, date, parties, description of the supply, total amount payable and the correct margin-scheme wording. Data controlled internally: purchase price, selling price, margin calculation and reporting treatment. KSeF technical data: the appropriate FA(3) fields and acceptance status.

This distinction can easily be lost when generating a PDF. A PDF may only be a visualization of the invoice, while the formal invoice in KSeF is the FA(3) XML. The broader distinction is explained in XML and the FA(3) format in KSeF.

With the invoice presentation clarified, move to the FA(3) fields that describe the margin scheme.

The KSeF 2.0 handbook confirms that FA(3) supports VAT margin invoices for travel services, supplies of second-hand goods, works of art, collectors' items and antiques. The central element is the PMarzy annotation, which declares whether the margin scheme applies.

In practice, this means P_PMarzy and one detailed variant: P_PMarzy_2 for travel agencies, P_PMarzy_3_1 for second-hand goods, P_PMarzy_3_2 for works of art or P_PMarzy_3_3 for collectors' items and antiques. The FA(3) XSD also defines P_PMarzyN when the scheme does not apply.

P_13_11 requires careful wording. The FA(3) XSD defines it as the total sales value under the margin schemes in Articles 119 and 120, and the Ministry's KSeF handbook recommends specifying it on a VAT margin invoice. This should not be reduced to a claim that software always knows by itself when and how to populate P_13_11 without a human decision.

Before submission: check the type of scheme, the required invoice wording, the P_PMarzy variant, the total amount payable in P_15 and any P_13_11 value against the generator, schema and accounting procedure. After submission: retain the KSeF number and UPO official acknowledgement.

With the invoice fields mapped, move to the JPK codes that operate in a different layer.

An invoice in KSeF and JPK_VAT are not the same file. FA(3) describes an individual invoice. JPK_VAT with the VAT return describes records and settlement for a reporting period. This distinction matters for the VAT margin scheme because the scheme annotation on an invoice is not the same as the MR_T or MR_UZ code in JPK.

The official JPK_VAT brochure applicable from February 1, 2026 states that MR_T covers travel services taxed under the margin scheme in accordance with Article 119, while MR_UZ covers supplies of second-hand goods, works of art, collectors' items and antiques taxed under Article 120.

The brochure also explains that procedure fields, including MR_T and MR_UZ, are completed for the entire document with the value 1 when the procedure applies and left empty when it does not. It defines SprzedazVAT_Marza as the gross sales value of supplies of goods and services taxed under the margin scheme.

Control sequence: first agree the scheme with accounting, then generate a correct FA(3), retain the KSeF status and only then ensure the proper JPK codes in the reporting process. Do not infer a GTU code merely from the phrase VAT margin without separately checking the goods or services.

Now that the invoice and JPK are separated, consider a process a small business can implement before submission.

The safest process begins before the invoice is issued. The person responsible for sales should know whether a transaction is intended for the margin scheme, but the owner should confirm the tax decision with an accountant or adviser. Only then should the FA(3) XML be prepared.

The process should separate roles. Sales provides the transaction data. Accounting confirms the Article 119 or Article 120 basis. Invoicing software generates FA(3). The sender checks the KSeF status, KSeF number and UPO. VAT records receive a separate JPK check.

Pre-submission checklist: eligibility confirmed, correct scheme selected, correct invoice wording applied, no standard VAT rate shown as on an ordinary invoice, P_PMarzy and the detailed variant checked, P_15 verified, P_13_11 reviewed against the handbook and generator, and JPK data prepared without confusing it with the FA(3) XML.

If a business issues invoices in volume, a separate exception review is more important than a single submit button. Margin-scheme invoices should be visible in filters, statuses and accounting exports so they are not lost among ordinary sales invoices.

With the roles separated, consider a specific used-car dealer example.

Assume a used-car dealer issues about 20 invoices per month. Some concern vehicles acquired under a model that accounting qualifies for the margin scheme, while others may require ordinary invoicing. The worst process would mark every vehicle as VAT margin solely because it is second-hand.

A safe process is more demanding but clear. Each vehicle needs an acquisition document, an accounting decision, the correct invoice type, the appropriate scheme wording, valid FA(3) XML, a KSeF number after acceptance and information for JPK reporting. New means of transport in a specified intra-Community supply scenario are additionally excluded from Article 120(1-20) by Article 120(21).

Data that software can help organize: customer, vehicle description, invoice number, amount payable, KSeF status, KSeF number, UPO and a filter for invoices marked as using the margin scheme. Data that software should not decide by itself: whether the previous supply meets Article 120 and whether the specific vehicle can be sold under the margin scheme.

The added value for the business is straightforward: software should not hide the scheme but provide a list of documents for review. Accounting should quickly see which invoices contain P_PMarzy, which require MR_UZ and which should not be grouped with ordinary sales.

The example highlights the main risks. Next, review the errors caused most often by mixing these layers.

The first error is over-automating the tax decision. Software can check the presence of fields, data consistency and document status, but should not decide by itself that a transaction meets Article 119 or Article 120.

The second error is trying to present a VAT margin invoice like an ordinary invoice with a VAT rate and VAT amount for the buyer. The KSeF 2.0 handbook states that a margin-scheme invoice does not include, among other details, the VAT rate or standard net totals by rate.

The third error is confusing FA(3) fields with JPK codes. P_PMarzy and the detailed variant are invoice elements. MR_T and MR_UZ are reporting codes. GTU must be analyzed separately according to the goods or services, not solely by the words VAT margin.

The fourth error is treating the PDF as the KSeF invoice. A PDF can be a readable view or a document for the counterparty, but KSeF formally works with FA(3) XML. If an invoice is rejected, follow Invoice rejected by KSeF.

With the error points identified, move to KSeFGPT's role in this process.

KSeFGPT should be presented in this process as a private application for working with KSeF invoices, not as a government service or tax adviser. Its appropriate role is to support data imports, FA(3) XML checks, invoice filtering, statuses, KSeF numbers, UPO acknowledgements and the preparation of information for accounting.

A business can use KSeFGPT to separate ordinary invoices from documents requiring special review. A margin invoice should be easy to find, check and pass to accounting together with confirmation that the tax decision was made outside the tool.

Example uses: importing a file or invoice data, viewing XML, organizing statuses, finding documents with a KSeF number, preparing an accounting export and reviewing an invoice list for operational omissions. These functions should not be described as an automatic decision on eligibility for the VAT margin scheme.

If a business works with several special invoice types, compare this process with an advance invoice in KSeF and self-billing in KSeF. In each case, the technical invoice structure and the business and tax decision must remain separate.

With the tool's role clear, move to the expert perspective on responsibility.

The VAT margin scheme is one of those areas where an error often begins before the XML is created. If a business has no documented decision explaining why a transaction falls under Article 119 or Article 120, a correctly formatted KSeF invoice does not solve the problem.

A sound process therefore begins with classifying the transaction, not selecting a field in a generator. Only after the tax decision should the business consider P_PMarzy, P_13_11, P_15, MR_T or MR_UZ. Reversing the order creates a risk that the user tries to fit the law to the form.

Second-hand vehicle sales require particular care. They are a common business example, but acquisition conditions, the status of the previous seller and statutory exclusions may all matter. The word second-hand alone is not sufficient for a safe classification.

Implementing KSeF should not remove human review from the margin-scheme process. It should make the decisions, XML fields, KSeF number, UPO and JPK codes visible, consistent and defensible in a later audit.

Continue with KSeF for small businesses to organize the basic KSeF process, roles and cooperation with accounting.

Advance invoices in KSeF explains how to separate the tax decision, document type and links between invoices.

Self-billing in KSeF covers the special roles and annotations involved when the buyer issues the invoice.

XML and the FA(3) format in KSeF explains why the formal KSeF invoice is structured XML rather than a PDF.