MPP on KSeF invoices after an individual interpretation

In KSeF invoices, you need to distinguish the statutory note mechanism podzielonej platnosci from the buyer's simple decision to pay voluntarily with split payment. These two situations may sound similar in a conversation with a counterparty, but they do not necessarily mean the same thing in FA(3) XML.

The P_18A field in FA(3) is not a general note about a preferred payment method. The schema links it with mandatory MPP conditions: invoice value above PLN 15,000 or the equivalent in foreign currency, and a supply of goods or services listed in Annex 15 to the Polish VAT Act.

Individual interpretation 0112-KDIL1-3.4012.185.2026.1.KM should be read carefully. An individual interpretation concerns the applicant and the described facts, not every taxpayer issuing invoices in KSeF.

The practical scenario is simple. A seller issues an invoice in KSeF, the transaction does not appear to fall under mandatory split payment, but the buyer says: I will pay by split payment anyway. The question then appears: should the issuer mark the invoice as MPP in XML?

In the old flow, it was easy to add a note on a PDF or copy a setting from invoicing software. In KSeF, that decision enters the data structure. That is why you need to know whether the marking follows from the law and the FA(3) schema, or only from operational information about how the buyer intends to pay.

Questions before the decision: does the invoice exceed the PLN 15,000 threshold, does it cover goods or services from Annex 15, are both parties acting as taxpayers in a B2B scenario, and is the buyer talking about their payment method or a statutory obligation? Since this is the problem, let us move to the article map.

1. Short answer for the invoice issuer

2. What P_18A means in FA(3)

3. When the split payment mechanism is mandatory

4. Voluntary split payment and the invoice note

5. What interpretation 0112-KDIL1-3.4012.185.2026.1.KM decides

6. Decision table for the issuer before submission

7. How KSeFGPT can help without replacing an adviser

8. Frequently asked questions

The table below collects the most important decisions to make before marking Mechanizm Podzielonej Platnosci on a KSeF invoice.

If the invoice meets the mandatory MPP conditions, the split payment mechanism marking should be reflected on the invoice and in field P_18A. The decision should follow from the transaction, not from an invoice template or habits from previous software.

If the buyer wants to pay voluntarily by split payment, but the transaction does not meet statutory conditions, do not automatically assume that the invoice must contain the Mechanizm Podzielonej Platnosci marking. This nuance became the axis of the interpretation and the later MF comment.

Short decision checklist: check total amount due, currency and possible conversion, Annex 15 items, buyer status, contractual arrangements and whether the invoice wording describes an obligation or only the expected payment method. Since we know the short answer, let us move to the FA(3) field itself.

The official FA(3) schema describes P_18A through transaction conditions: total amount due exceeds PLN 15,000 or the equivalent of that amount in foreign currency, and the invoice documents a supply of goods or services from Annex 15 to the Polish VAT Act. In that situation, value 1 means application of the split payment mechanism, while otherwise value 2 is provided.

This is not a field for describing any buyer payment decision. If the buyer chooses split payment out of their own caution, the issuer should still ask whether the statutory conditions are met. The buyer's chosen transfer technique is not always the same thing as a mandatory invoice note.

Good practice: decide on P_18A before generating XML, not after validation. A validator may help detect a structural issue, but it does not replace accounting classification of goods from Annex 15. Since we know what the field is, we need to return to the mandatory MPP conditions.

As of July 9, 2026, the starting point is the same as in the FA(3) schema: the invoice must exceed the PLN 15,000 threshold or its equivalent and cover goods or services from Annex 15 to the Polish VAT Act. Only when these conditions occur together does a practical need to mark MPP on the invoice arise.

A high amount alone is not enough. An item from the catalogue alone is also not enough if the invoice value does not exceed the threshold. It is also not enough that the buyer prefers to pay by split payment transfer message. In the invoicing process, it is worth separating three questions: what is the amount due, what is being sold and what is the status of the parties.

Checklist: gross invoice amount, currency, Annex 15 items, taxpayer status, possible collective payments, contract documentation and the reason for the P_18A setting. Since the conditions are clear, we can move to the hardest case, voluntary split payment.

Voluntary split payment is a payment decision made by the buyer. The mechanism podzielonej platnosci note on the invoice is information from the issuer about the statutory regime of a given transaction. In practice, both topics meet on the same invoice, but they must not be merged into one automatic rule.

The MF information is important precisely because it refers to voluntary MPP in the KSeF era and interpretation 0112-KDIL1-3.4012.185.2026.1.KM. This comment should be read together with the full interpretation record ID 692287, not as a shortcut allowing every company to mark every invoice according to its own preference.

The practical rule is cautious: if the buyer wants to pay voluntarily by split payment, note that operationally in settlements, but set P_18A only after checking statutory conditions and sources. Since we have separated voluntary payment from the note, we need to organize the interpretation itself.

The individual interpretation concerns a specific question about marking invoices in KSeF in the context of the split payment mechanism and voluntary split payment on the buyer side. It does not automatically decide every case in which a counterparty wants to pay by split payment transfer message.

The applicant wanted to determine whether such a practice could be acceptable when issuing invoices. For assessing your own situation, the full wording of the interpretation is key: the facts or future event, the question, the taxpayer's position, the authority's assessment and the reasoning. Only these elements show how far conclusions from the interpretation can be transferred to similar transactions.

The boundary is the most important point. An individual interpretation is not a universal invoicing rulebook for KSeF. It usually protects the applicant who described a specific set of facts or future event. For other companies it may be a useful signal, but it does not replace analysis of their own transaction. Since we know the boundaries of the interpretation, let us move to the practical decision table.

The greatest practical value is not memorizing the interpretation number, but organizing the decision before sending XML. The table below helps separate cases where MPP is a statutory layer from cases where the buyer merely chooses split payment as the payment method.

Do not treat this table as tax advice for every industry. It is a map for a conversation with accounting: it helps quickly show what is missing for a decision and where error risk appears. Since we have the map, it is worth naming the typical mistakes as well.

The first mistake is marking MPP just in case. In KSeF, data is structural, so this is not an innocent margin note. If the marking does not follow from the transaction, it may create unnecessary questions for the buyer and accounting.

The second mistake is looking only at the amount. The PLN 15,000 threshold matters, but without checking Annex 15 it is not enough for the decision. The third mistake is transferring settings from paper invoices or PDFs without checking again whether old mapping rules are compliant with FA(3).

Mistakes to discuss in the company: automatic note for every counterparty, no Annex 15 verification, ignoring currency, treating the buyer's request as the issuer's obligation, and no accounting note for a borderline decision. Since we know what to avoid, we can design a safer tool process.

The biggest risk with MPP in KSeF is not the act of clicking a field in a form. The risk arises earlier, when a company does not know whether the marking follows from regulations, the counterparty's expectation or a setting inherited from old software.

For implementation, it is worth separating responsibilities. The person issuing the invoice should have a simple procedure and see warnings for amount and item type. Accounting should confirm borderline cases. The system should record the decision in invoice data, but it should not pretend to be a tax adviser.

Individual interpretations are helpful because they show how the authority thinks. They should not replace the company's own transaction classification. With MPP, it is especially easy to turn one letter into an operational rule for the whole process, and that is exactly the shortcut worth avoiding.

A good procedure is simple: first identify the transaction, then set the field in XML, then validate the structure, and only at the end send the invoice to KSeF. If the case is unusual, stop submission and confirm the decision with accounting or an adviser.

KSeFGPT should be treated as a tool for working with invoices, FA(3) XML, status, UPO and complete data, not as a source of an individual tax interpretation. The application can help organize the process and reduce manual mistakes, but the decision whether a transaction meets mandatory MPP conditions remains an accounting or advisory decision.

In practice, separating two steps is useful. First, the company determines the tax decision for a given invoice. Then the tool helps keep consistent data: invoice, XML, submission status, KSeF number, UPO and documentation needed by accounting. When working technically with a file, the KSeF XML validator may also help.

If you issue invoices in a regular process, check the KSeFGPT invoices module. In one place, you can work with documents, statuses and data needed for settlements instead of keeping invoice decisions in separate emails, spreadsheets and folders.

If you want to go deeper without repeating the whole KSeF process, start with these four materials:

How to issue a VAT invoice in KSeF step by step - helps organize decisions before a regular sales invoice, including data, document type, validation and submission.

KSeF number on invoice - explains when the KSeF number is created and how not to confuse it with your own invoice number.

KSeF invoice payment term - shows how to separate issue date, receipt date and buyer-side settlements.

Sending invoices to KSeF - describes the technical submission process, statuses, UPO and pre-submission control.