The second week of KSeF consultations at the Ministry of Finance is behind us – report from the meetings.

During last week’s consultations with various industries of the Ministry of Finance, several issues related to introducing the National e-Invoice System (KSeF) were raised. Industry representatives expressed their concerns and submitted many proposals regarding the system’s operation and impact on daily business operations.

Payment ID in the transfer title

During the consultations, the validity of using the payment identifier was raised due to the lack of benefits for taxpayers, the burden on the KSeF system, the additional complexity of integration, the need to modify the payment process, etc.

The Ministry of Finance’s statement shows that the position and requirements are unlikely to change, as payment constitutes a complete set of invoice information for VAT control/sealing purposes. Similar mechanisms are used in other European implementations with positive results, e.g., in France, although more in the payment reporting mode concerning the e-invoice and not in the content of the transfer.

The lack of punishment for non-compliance with the regulations was also discussed, which may mean the regulation is dead and the expected effect will not be achieved. It was also expected that the implementation date of the obligation to use a payment identifier would be postponed so that the dust could settle after the implementation of e-invoices, and only then would the application be extended to include payments.

It was also proposed that the algorithm for generating the payment identifier be disclosed to create the transfer content without communicating with KSeF. The postulate is justified, but in practice, more is needed because, in the case of one payment for mass invoices, the recipient of the transfer will not be able to identify what the transfer concerns. There are no practical limitations when using the payment identifier generated by KSeF, and one identifier can be mapped to many invoices.

One idea would be to be able to provide an invoice along with the payment amount so that the payment identifier would de facto constitute a “transfer specification”. The mere reference to the invoice number must be sufficient for the recipient to settle the issue correctly, as one invoice may be paid in instalments. Similarly, in transfers, contractors make payments for events unrelated to the invoice, e.g. for an interest note. The option to add a comment to the payment identifier so that the contractor could provide additional information to the transfer recipient was considered valuable.

Doubts were also raised regarding the control of payments in compensation cases because the payment identifier does not cover them, and the tax office will not be able to identify such settlements based on the information in the KSeF.

The issues of payments by a third party other than the buyer and the standardization of payment identifiers in the international environment were also discussed.

Operational challenges for small taxpayers are of concern due to additional activities, such as the need to copy the KSeF number and paste it into the transfer title in the banking application. Applying the regulations may not generate additional work because the invoice visualization will include the KSeF number required in the transfer title. It was pointed out that entering the payment ID may generate many errors due to the length of the code (errors occur with codes of several characters, hence the fear that the problem will be even more frequent with 35-character codes).

Questions were also asked about using the payment identifier in the case of other forms of payment, e.g., credit card, Blik, etc., where it may not be possible to operationally meet the requirement because the KSeF number may not be known during online payments yet, similarly, in the case of direct debit (the bank knows the amount due; it does not have to know the KSeF number) and instant transfers on the Internet.

The technical issues discussed included how the taxpayer should fulfil the obligation to use the payment identifier when KSeF is not working or when there is KSeF emergency mode, which is a problem when generating a transfer and when posting the transfer by the recipient. According to the Ministry of Finance’s declaration, the payment ID will soon be available in the KSeF test application. Attention was also drawn to the inconsistency between the specification and the API implementation in KSeF and the inability to download payment identifiers from KSeF in batch mode.

Factoring industry requirements

During the consultations, industry demands were raised specific to the participants of the factoring process. Much attention was paid to discussing the possibility of collective processing of invoices for which transfers are generated, but this is not a payment to the supplier but financing a factoring operation as part of a global assignment, which is in contradiction with the obligation to include the payment identifier in the invoice transfer title.

Representatives of the factoring industry drew attention to the massive volume of processed invoices and the need to automate processing.

The industry’s demands concerned the possibility of access in KSeF to invoices in which the factor is not explicitly indicated – neither as Entity 1, Entity 2, nor Entity 3. However, business practice can significantly complicate the situation when one factor takes over invoices from another, and then the legal perspective changes, but the data in KSeF stays the same. The Ministry of Finance thinks that it does not examine relationships between contractors, and the content of the invoice is protected by law and cannot be made available to third parties, even if they have a legitimate interest because the issuer decides this and not the tax office.

The possibility of access to part of the data in KSeF for the factor was discussed for selective invoices, e.g. per the buyer’s NIP or in anonymous mode. Representatives of the Ministry of Finance informed about the planned change in anonymous access – the use of a QR code will replace the current mode; in short, it can be said that providing the contractor’s name, currently required in anonymous mode, will be replaced with a cryptographic abbreviation of the XML file.

During the meeting, various fraud cases were discussed, e.g. a client transferred the same invoice to several factors to extort payment. Here, KSeF fits well in reducing the grey zone and fraud control because all invoices are collected in one place, allowing cross-checking. Another type of fraud is submitting an invoice to a factor, obtaining payment, and correcting the invoice. However, while the factor may be explicitly indicated on the sales invoice if the correction does not include a factor marking, the factor does not see such a correction in the KSeF.

The meeting discussed possible solutions to address the issues mentioned above. Problems include an additional API indicating binary information that a correction has been issued for a given invoice and the need to implement an invoice assignment register (indicating the assignee who could access the invoice and corrections).

The case of a foreign factor was also discussed. For example, a Polish company issued an invoice to a Polish company, which was transferred to a foreign factor that does not have access to KSeF and, therefore, is not obliged to provide the ID of KSeF in the transfer title (because Polish regulations do not apply to it).

According to the Ministry of Finance announcements, specifications (including the QR code and payment ID) and appropriate regulations should be available around March 18.

Consultations with utility providers

One of the main topics was communication with mass customers who received complex sales documents that went far beyond VAT issues.

The simplified image of the invoice described in the proposed regulation of November 23, 2023, was discussed. This invoice will significantly reduce the number of items sent to KSeF and is supported by invoice issuers.

There was much discussion about limiting invoice printing to data in KSeF – the Ministry of Finance noted the need for clear guidelines on how much data other than those sent in KSeF can be included in the invoice visualization. It was argued that the issuer must provide customers with data that fits outside the e-invoice scheme, which results, among others, from industry regulations such as telecommunications law for Telkom companies or energy law for electricity suppliers.

It is a standard business practice to provide additional data in attachments, which may be extensive if, for example, the invoice concerns thousands of items and each item contains several pieces of information about the meter number, reading, reactive and active energy, etc. Theoretically, the FA scheme allows such information to be sent to KSeF. Still, its visualization needs to be legible, and industry standards have yet to be developed on how to communicate such data that do not appear in the FA schema in a structured way.

Much space was devoted to discussing the possibility of handling attachments by KSeF, which led to the question of what KSeF’s global purpose is—is it a central tax register of invoices (contractors outside KSeF exchange and business details) or a national EDI system that serves as a business data repository?

Another aspect of consistency between KSeF and the invoice is the case of visualizing the invoice in a foreign language or bilingual – the possibility of placing translations, including data such as the name of the product/service, will be analyzed.

The Ministry of Finance emphasized that the invoice’s QR code gives the buyer a simple opportunity to check the content of the data in KSeF.

Industry representatives also raised the issue of the KSeF implementation schedule, which should consider other changes in the law requiring changes in IT systems and enterprise processes overlapping with the launch of the mandatory KSeF.

The media industry’s specificity is the invoicing of historical economic events that are settled in different billing periods. The current level of the invoice header does not allow for issuing different periods at the item level, e.g., different subscription periods, different roaming fees, and other overdue fees.

The industry pointed out that large entities issue hundreds of thousands of invoices, and the occurrence of a KSeF failure stops mass communication. There is a risk that when KSeF is restored, everyone will rush to transfer overdue invoices, which will cause congestion and processing. KSeF should be prepared to handle such situations, perhaps ordering the distribution of traffic from taxpayers in advance.

According to the Ministry of Finance declarations, legislative work should be completed by the end of June; the mandatory KSeF will start on January 1, 2025, at the earliest, and a minimum of six-month vacation legis.

There was also a request not to withdraw corrective notes to retain the possibility of correcting minor non-tax errors using notes and not to force all changes through corrective invoices.

The topic of consumer invoices comes up at virtually every meeting, and there were voices in support of B2C invoices as well as arguments against including them in the KSeF. Still, the common denominator is the need for clear guidelines on how the taxpayer (or preferably the taxpayer’s system) can distinguish a B2B from a B2C invoice.

Similarly, the issue of payment deadline often arises, which must be consistent with the contract concluded between the contractors and depends on the date of delivery of the invoice, which is conditional on issuing an invoice to KSeF, which the seller has no influence on. Therefore, if an invoice in KSeF is issued contrary to the contract, it may not be formally paid. Hence, greater freedom is requested when determining the invoice issue date and payment terms.

Challenges related to the fuel industry

The biggest industry challenge discussed at the meeting was customer service at a gas station that expects a formal sales document received on-site. Since during the mandatory KSeF period, the invoice is considered issued and entered into legal circulation by being registered in KSeF, the KSeF processing time is critical, which, in the case of on-site customer service, should be counted in seconds.

While a Polish recipient can still download invoices from KSeF (and formally, it is delivered to him when the KSeF number is assigned), a foreign recipient does not have access to KSeF, and the law requires that the invoice be sent to him in an “other, agreed manner”. However, if there is a KSeF number, there is an invoice. In discussion with the Ministry of Finance, there were ideas to allow taxpayers to issue invoices offline unless KSeF issues an invoice within X seconds. Then the wolf is satisfied (the buyer receives a formal VAT invoice), and the sheep is safe (the invoice will go to KSeF because the seller is obliged to deliver the invoice to KSeF within a short time). In practice, while KSeF can process invoices significantly longer than seconds, sending a single invoice to KSeF and confirming by KSeF that the document has been accepted for issuance is done relatively quickly, which ensures consistency of the date of issue of the invoice sent to the client with the date of issue in KSeF (by law it is this is the moment of sending the invoice to KSeF).

Until such an invoicing mode is officially confirmed, a document that is not formally a VAT invoice is issued, e.g., a sales confirmation, which in terms of content is identical to the invoice but cannot be officially called an invoice until it is registered in KSeF. The buyer cannot settle VAT based on such a document; the seller cannot correct such a document, etc.

Representatives of retail chains at the meeting had similar requirements regarding the service of an ‘interactive’ customer. In this case, a VAT invoice needs to be issued at the point of sale—the customer cannot wait at the cash register for the invoice.

In the case of fleet customers, a tax interpretation from several years ago allows for the issuance of collective invoices at the end of the settlement period with an attachment documenting the complete list of transactions of a given customer for a given settlement period. If attachments are not supported in KSeF, all details must be included in the KSeF structure, and there are situations where there are several dozen thousand such detailed transactions for one invoice. Hence, the demand to abolish or increase the limit on the number of items on an invoice because 10K items is insufficient.

It should be noted that in the FA(2) schema, there is no dedicated place to provide the car registration number for refuelling transactions (there is a registration number, but it is in the node regarding the sale of a means of transport).

The possibility of issuing a VAT invoice on a fiscal printer as a non-fiscal printout was also raised because currently, a widely used form of invoice at gas stations is a fiscal invoice, i.e., a fiscal document that will be withdrawn as of January 1, 2025, by the VAT Act (the date will most likely be postponed due to the postponement of the mandatory KSeF).

Common topics arise at various meetings, such as the staging of the KSeF implementation, where the issue of identifying whether the obligation at a given stage covers a given contractor is raised. This is a problem with the phased implementation of the KSeF. The implementation of Big Bang has its negative advantages, but it results in the possibility of switching to KSeF as the source of incoming invoices.

Similarly, a common topic discussed during consultations is employee settlements – typically, an employee with an invoice from a business trip brings the documents attached to the settlement of the business trip to the accounting office. In the case of the obligatory KSeF, all purchase documents are downloaded, and entrepreneurs report difficulty in recognizing which invoice concerns what and who. Additionally, B2B contractors’ invoices contain sensitive remuneration data and should be additionally protected against unauthorized access.

To sum up, the Ministry of Finance’s consultations raised several important issues regarding the National e-Invoice System that require consideration in further legislative and technical work. It will be necessary to continue dialogue with representatives of various industries to ensure the system’s effective and balanced implementation, taking into account the specificity of each economic sector.