Structured e-invoices – Q&A

To answer this question, it is crucial to find out whether a foreign entity has a fixed establishment for VAT purposes in the territory of Poland and whether they are involved in a given transaction. It follows that the status of a VAT-registered taxable person in Poland is not the deciding factor in this case.  

As the MF underlines, the implementation of e-invoices will not affect Polish tax authorities’ practice in respect of examining the circumstances/criteria used in finding out whether a fixed establishment (FE) test is met or not (which, however, the taxable persons have not found easy to grasp so far); the MF does not plan to publish any other explanatory memorandum/general tax ruling in this respect. Another thing contemplated during the KSeF legislative work which the lawmaker gave up is the implementation of a publicly available label (on the so-called whitelist) showing whether a given foreign entity has an FE set up in Poland. As a result, the only reliable form of confirming a foreign entity’s and their contractors’ status in this respect is to file for and obtain an individual tax ruling.

Getting the company ready for embracing the new requirements governing the issue and receipt of invoices is not merely the adequate technology resources/standards to be provided (whether through changes implemented directly in the finance and accounting system or distinct tools designed to support the invoicing process). What is equally important is e.g. the implementation of adequate procedures (or revisiting and updating those already in operation), providing training to staff members or a verification of the accuracy of the data to be transmitted in detail to inspectors in the form of e-invoices. Furthermore, given the broad range of data to be supplied and the imprecise requirements concerning the completion of non-mandatory boxes (designed for data that companies often gather in their systems to some extent only), it may turn out that additional decisions are necessary on how data are to be gathered and presented. 

In addition, the logical structure of an e-invoice features items that are optional, yet may be necessary in the light of a given business practice which is typical of certain categories of taxable persons and/or the type of their business operations. 

In practical terms, a project designed to help a medium-sized/large enterprise effectively handle e-invoices takes from 6 to 9 months (this encompasses not only the implementation of an adequate IT solution but also appropriate processes and tax requirements, the testing of the new solutions and providing the invoicing staff with training on the KSeF rules). It is therefore advisable to make the most of the months to come before the system becomes mandatory and launch preparations in advance so as not to be taken aback.

Yes, a taxable person will be offered the self-billing option, i.e. the acquirer will be able to issue an invoice in the name of and for the supplier. Per the MF explanations, first the supplier will have to agree to the self-billing arrangement with the acquirer in the KSeF; once they do it, the acquirer or the entities authorised by the acquirer to issue self-billed invoices will make out e-invoices in the supplier’s name.

Electronic Data Interchange (EDI) is a standard for transmitting/exchanging commercial and financial documents (in addition to invoices, EDI is used for exchanging documents such as orders, order confirmations, dispatch notes etc.). Taxable persons sending/receiving traditional electronic invoices they have used so far will also be required to get their systems/procedures aligned with the KSeF requirements. They also face an important change, but may find it easier to implement the new system compared with taxable persons who have not put an electronic flow of documents into operation yet. What is important is to work out a customised approach and consider how an electronic flow of documents should be delivered alongside the handling of the KSeF and to what extent the KSeF will take over its functionalities.

Per the current version of the schema, generally there is no option to attach any external files to an invoice issued in the KSeF. As the amendments to the VAT Act are now worded, attachments to invoices are planned for selected sectors, i.e. utilities, telecom services and other “master” (aggregate) invoices (the fuel sector only). In all other cases, all additional data affixed to an invoice so far (e.g. summaries of the goods supplied or reports) will have to be either sent independently of the invoice itself, i.e. outside the KSeF (e.g. by email), or an invoice issued in the KSeF will also be delivered outside the system along with the attachments. 

Alternatively, attachments may be placed and stored in a dedicated repository created by the issuer and, additionally, individual links to attachments may be added to the invoice made out in the KSeF to enable the recipient to quickly download and correctly match attachments with the invoices they accompany. 

What might indicate that attachments are available for an invoice is the “Additional data” node (up to 12 times for a single invoice). This item features the Key-Value tag pairs where any text values can be input. In this case, if the data to be provided in an attachment can be embodied in a text, the cited node may simplify things to some extent. What is not available is the option to match an e-invoice with a distinct file that is to serve as an attachment.

Whether the acquirer will receive an invoice directly from the KSeF before mandatory e-invoices come into force depends on whether they agree to receiving invoices in this form. 

If no such consent is given, the supplier will still be allowed to make out invoices in the KSeF but will then be required to deliver the document to the acquirer in another form to be agreed with them (the VAT Act is silent on this issue), e.g. deliver or send the printed copy by post, send a scanned copy by email or issue an electronic invoice (as long as the acquirer has agreed to receiving invoices in electronic form although no KSeF invoicing arrangements are in place). What is important is that both transaction parties must have documents with the same data content, i.e. the data included in the invoice delivered to the acquirer must be identical with that the supplier provided in the KSeF (the supplier may e.g. provide the acquirer with the invoice issued in the KSeF in visual form, i.e. as an image). Importantly, if an invoice is issued in the KSeF and the financial system at the same time, this means that two invoices have been generated as valid legal documents concerning the same supply of services or goods. This in turn implies that both invoices are chargeable to VAT.

The first thing to note is that the KSeF law does not set out any new items to be included on an invoice. As a result, there is no requirement for the taxable person to provide information on their e-invoices which goes beyond the mandatory data required under the VAT Act. 

At the same time, the scope of information required for the e-invoice schema is broader than the data provided in the JPK_VAT, JPK_V7M or even JPK_FA files. 

Many fields in the schema of a structured invoice are optional fields, so leaving them with no data supplied will not cause any technical issue in terms of getting the file validated (the system will accept the invoice even if those fields are left blank). Per the MF replies, these fields also include the so-called optional invoice items not derived from VAT law; they are not forbidden but are fully discretionary. However, optional fields also include those designed for information required as content- (as in the case of the JPK_FA schema) or business-type data. With this in mind, in the course of making preparations for the implementation stage an essential thing is to correctly identify and classify the cited optional fields. 

Importantly, each e-invoice must reflect the logical structure (now FA(2)) and any possible errors (e.g. leaving some mandatory fields in the structure with no information filled in) will result in the e-invoice being rejected. It is also noteworthy that the structure features fields that will not become mandatory until the point when data is provided in specified tags/sequence areas (although they are generally optional) which include these fields, although they involve information not required by the VAT Act. As a result, if optional nodes are filled out in an invoice, the mandatory fields must be completed in this node to ensure that the invoice file is transmitted effectively.

Per the explanations provided by the MF and the service provider in charge of the development of the KSeF system (Aplikacje Krytyczne), the KSeF gateway will only check the technical accuracy of the data by comparing it with the model XSD template and will find out whether the invoice issuer holds the required authorization. This means that invoices with content errors, including arithmetical errors, will be issuable in the KSeF because the system will not verify them. In such cases a correction e-invoice will have to be raised. With this in mind, it is advisable to implement appropriate mechanisms to verify the accuracy of the data before it is sent to the KSeF, reducing the risk of inspections thereby. Moreover, during workshops provided at the Mazowiecki Branch of the National Chamber of Tax Advisors an MF official announced that additional checks would be carried out to find out whether a given invoice sent to the KSeF was not a duplicate original.

Per the MF explanations, no change in the data on a KSeF invoice can be made unless a correction invoice is issued to rectify the error. As a result, to reverse the effect of an invoice that has been raised correctly (and was assigned a reference number in the KSeF), it should be adjusted to nil.

All invoices issued under the Polish VAT Act, i.e. those documenting sales in the territory of Poland (to Polish and foreign entities having a fixed establishment in the territory of Poland) but also those documenting transactions such as export of goods or an intra-Community supply of goods (ICS), will be obligatorily issued in the KSeF. However, if a supply is made to a foreign entity with no FE in Poland (and if the FE that actually exists is not involved in a given transaction), the supplier will be additionally required to provide the acquirer with an image of the invoice issued in the KSeF (i.e. one that already has a KSeF identification number and the QR code to find out whether a given invoice was actually issued correctly in the KSeF and whether the data in it is accurate). 

Generally, yes. However, one should not overlook those cases in which taxable persons are required by law to retain such documents for periods longer than 10 years, as the retention period of KSeF e-invoices will be 10 years. When this term lapses, the taxable person will have to ensure retention of e-invoices otherwise (in compliance with the standard requirements applicable for the retention of electronic invoices). 

It is worth noting at this point that the system gives the option of downloading invoices in bulk, which will certainly make the subsequent retention of e-invoices easier. However, please note that e-invoices will be downloadable in this way in XML format only. It follows that if PDF files with invoice images are to be generated in bulk, this will not be feasible using the standard KSeF functionality.

The idea behind the KSeF is to make it possible for the supplier to issue, and for the acquirer to receive, e-invoices in the system. It follows that the acquirer will not receive any notification that there is a new invoice issued with their NIP waiting in the KSeF; it is therefore the acquirer’s duty to regularly check (in a manner that is more or less automated) whether their business partners have (not) issued any new invoices to them. 

In addition, the MF has designed special backup procedures to issue and send invoices outside the KSeF during the MF platform downtime, when it’s offline and where the invoice issuer’s system is affected by a breakdown (however, this does not impact the requirement to subsequently send any non-KSeF invoices to the KSeF system within strict deadlines). 

Before the KSeF becomes mandatory, in the absence of the acquirer’s agreement to receiving invoices in the KSeF or where the acquirer has trouble downloading an e-invoice directly from the system, the e-invoice can be sent to the contractor otherwise, including by email (to the extent that the parties have made such arrangements). 

Yes, even if a taxable person is not ready to make out structured invoices, they have been in a position to receive invoices of that type since 1 January 2022 whenever their suppliers issued e-invoices in the KSeF. 

It is also noteworthy that the process of downloading e-invoices may also carry uncertainties and require that the company’s processes be adequately set up/adjusted.

No notification of that type will be generated. The responsibility for checking whether any new invoices have been issued to a company will lie with the company itself. It should also be pointed out that the acquirer does not have to know the KSeF number of an e-invoice to receive it (the only exception is the so-called anonymous access to an e-invoice; cf. the answer to the next question below).

Naturally, an arrangement can be made with a supplier to notify the company that new invoices have been issued to it; this is particularly important before the KSeF becomes mandatory, but will certainly be useful also in the transitional period before companies make the necessary preparations and get used to using the KSeF smoothly.

Acquisition invoices will be downloaded by a given taxable person or the entity authorized by the taxable person for the purpose. This entity may be either the entrepreneur’s employee or the bookkeeping provider that has been given the authorization. Invoices are issued between entrepreneurs (companies), which means that access rights will be granted (and accepted) at company level. Importantly, the option will be available to restrict a user’s rights to specified operations only (e.g. the accountant/bookkeeping provider may access invoices only, with no authorization to issue them). 

What is also planned is the option of “anonymous” access to an invoice preview using a link to be provided by the invoice issuer/supplier through an API. Whoever has access to this link, whether they have a KSeF account or not, will be able to access the invoice. 

Furthermore, as the draft regulation now states, such anonymous access is first to be given to each entity to which various data identifying a given invoice is available, namely: 

• the identification number of the invoice in the KSeF; 
• a unique identification number of the invoice; 
• the NIP or other number identifying the acquirer or a note saying that no identification number is available; 
• the acquirer’s first name and surname or business name or a note saying that such data is not available; 
• the total amount owed.

The MF has already provided software to handle the e-invoicing process. However, please note that this software will prove useful to smaller companies, as it requires the manual handling of the process (Aplikacja Podatnika KSeF and new Mikrofirma functionalities). Large entrepreneurs or SMEs will have to align their tax and accounting systems to the new requirements on their own.

Invoices raised in the KSeF will have to be corrected in the system. Any correction invoice raised otherwise (e.g. directly in the company’s financial/accounting systems) will not have any commercial or legal effect.

The date of an invoice (P_1) should be specified already in XML files sent to the KSeF, and the date of an invoice is taken to be the point when a KSeF number is assigned to it. Please remember that the P_1 field is mandatory in the logical structure, so it must be filled out to ensure that the KSeF accepts the invoice. Per the MF explanations, an e-invoice may be sent at a date other than that provided in the P_1 field, within the invoicing deadlines set out in the VAT Act. As a result, it seems that if a taxable person provides a specific date in the P_1 field, they will not be required to send the invoice to the KSeF on the same date. Two ways of data transmission should be distinguished:

• As the MF has explained, an invoice will be deemed to have been issued on the date when it is sent to the KSeF (under Article 106na(1) of the VAT Act), i.e. at the point when it is uploaded to the system regardless of the point when it is subsequently processed. In addition, if the date provided in the P_1 field (which is mandatory in the logical structure of an e-invoice) is not the same as the date of transmission, the invoice will not be rejected in the KSeF. It follows that a document identified in the P_1 field as one with e.g. a Monday as the issue date, which is sent and processed on a Tuesday, will not be rejected on the ground that the date of issue declared in the XML file transmitted (Monday) is not consistent with the issue date in the KSeF (Tuesday). 
• Where the taxable person chooses the so-called bulk transmission, which means that multiple invoices are sent at a time, the date of issue of an invoice, as the MF explains, is the point when a KSeF session is opened and the bulk transmission initiated. This means that where a session is opened and a batch of invoices sent on a Monday and the transmission closes on a Tuesday, the date of issue of a given invoice is taken to be Monday (as long as the invoice is transmitted during the session opened on Monday).

One of the first steps that are advisable is to make a tentative evaluation of how complex and complicated the process of implementing the new e-invoicing rules will be, namely how many and what business units will be affected, the volume of transactions documented using invoices and those for which invoices are not raised, but they do impact VAT accounts, the number of document types, how varied the business operations and the invoicing process are. Other important things include the volume of correction invoices, the frequency of annulling invoices, the type of data provided in attachments, the key or specific arrangements with contractors in terms of the invoice content. A key item that determines the difficulty connected with the implementation task is the level of detail of the internal documents flow and tax compliance procedures and the extent to which these procedures are actually followed. 

For multi-layered projects, it may often turn out that external assistance is needed, e.g. focused support in areas such as legal, tax compliance, system, IT or end-to-end support with comprehensive legal and business assistance along with project management. 

The scope of necessary work will certainly involve content-related issues to help the invoicing staff gain an understanding of how e-invoices work, examine internal procedures and systems in place to identify the areas in which to tailor them to the new requirements, along with an adequate data mapping involving the e-invoices schema and the company’s transactional data. 

An important item on the project agenda should also be getting in touch with the company’s contractors to discuss how to transition to e-invoices and make appropriate arrangements considering the actual circumstances of the business relationship between the parties.

The length of the project may vary markedly and is determined by a variety of factors. Large business organisations with complex ERP systems in place, several data sources, massive volumes of documents, cross-border IT teams, long waiting times to implement a system change, understaffing, a broad portfolio of contractors with non-standard agreements etc. are often aware that even as much as several months may prove too short to carry out a project of that type. As a result, the 1-year period left before structured e-invoices are scheduled to become obligatory is a time to plan and phase the project in.

In addition to the tax team, the project will require involvement of the people in charge of operating tasks and those responsible for booking acquisition and supply invoices. Invoices are often made out by sales and procurement staff who will be forced to modify their methods of working and be able to handle new invoices. What may also prove necessary is to modify the procedure governing the flow of documents within the organisation.

Another thing that may prove essential is to engage IT teams, experts in accounting/ bookkeeping systems, ERP system specialists and people in charge of contractor relationships, particularly at the point where invoices will have to be raised on external entities (e.g. in the self-billing process).

It is also necessary to tailor the company’s IT systems while maintaining the operating capabilities to carry out business processes and ensuring that the mapping of source data in the e-invoice schema reflects all the required transactions that the taxable person carries out in their business.

Engagement of IT staff and post-implementation system maintenance consultants is not unlikely, as they may be required to provide updates and respond to the MF’s changing requirements.

An aspect not to be overlooked is to embrace the changes at the system user rights level and ensure security in terms of data access rights. The taxable person should carefully choose the individuals to be granted the KSeF rights and the methods to ensure safety of the data transmitted to the KSeF to prevent its unauthorised use.

Both the timeframe and the budget may vary according to the level of complexity of the project. The overall budget figure can hardly be assessed, because each implementation project is different and there are multiple factors contributing to it such as the tool, time, involvement of internal and external teams, testing, etc. Another factor of considerable importance is the human factor, as it impacts the particular phases of the project, the time needed for testing and enabling the change in terms of training. There are multiple factors that cannot be systematised, predicted or valued in the initial phases; when planning the overall implementation cost, one may only rely on an estimate, which may – when confronted with the real purpose, assumptions, projections and, importantly, the scale and complexity of the implementation task – prove to be considerably below the actual cost. 

Data is mapped for the purpose of preparing financial and accounting systems for the issue of invoices in structured form. Data mapping requires the analysis of the systems, tax laws, and business needs, and the mapping process itself requires coordination of tasks of the tax-and-accounting team and those of the supplier of IT solutions. The purpose is to identify all the data in the financial and accounting systems which is to be included in an e-invoice made out by the entrepreneur. The mapping process may also extend for purchases; whenever the automation of inputting purchase invoices data is sought, this part of the process should also be mapped during the implementation stage.

In addition to the boxes required for technical reasons, entrepreneurs should also examine other fields to find out whether they are obligatory under the existing law (particularly tax law) and from the perspective of their business needs. Analysing the boxes businesswise is important particularly because there is no option to add any attachments to an e-invoice; it is not until all the fields in the schema are examined that the full scope of the data to be supplied in the new documents can be identified.

The data determined as a basis for making out an e-invoice should then be taken from the company’s financial and accounting system and matched with the particular fields in the FA(2) schema, in compliance with the technical requirements of the schema such as the proper data format or the maximum number of characters.

If the required data is not available in the company’s financial and accounting systems or if the option of generating e-invoice files cannot be implemented, the company’s solution might possibly be upgraded through integration with external solutions that, while working alongside default system solutions, enhance them with the required functionality added, providing a bridge between the company’s internal system and the MF platform.

This option helps avoid modification of the financial and accounting systems, which are often customised to handle operations in multiple areas, and thus limit the scope of interference. In practical terms, such decisions are popular where globally centralised ERP systems are in place, as they fail to keep pace with local regulatory developments. When seeking a balance between global corporate standards and local requirements, one often struggles to find a golden mean. This is why companies increasingly rely on solutions serving as a bridge between ministerial platforms and their source systems, as they do not require any ERP changes while using the data available from these systems. This both helps reduce the time necessary to modify the company’s systems and often improves cost-effectiveness, all the more if you remember that shifting the liability for the implementation of such a critical solution onto an external provider is one of the quantifiable benefits of this model.

The current KSeF requirements reflect the specific features of VAT groups and local self-governments.

What is particularly noteworthy is the special rights given to centralised units within local governments as well as members of VAT groups. It is possible to grant an internal unit of a local government or a VAT group member as well as persons representing them certain limited rights.

These rights involve authorisation to: 

• manage the rights/competencies of a local government’s internal unit/member of a VAT group;
• restrict the right to inspect invoices to one specified entity only (a local government’s internal unit or a VAT group’s member). 

As regards the FA(2) logical structure itself, one should pay attention to the optional item named Podmiot3 (ThirdParty), which is to feature the data of all third parties other than Podmiot1 (Party1) and Podmiot2 (Party2) connected with the invoice. As a result, invoices issued to a VAT group as a taxable person will feature the data identifying the group, including the group’s NIP. In addition to the group’s data, they may feature particulars of the entities economically involved in the operations of the group (group members) as additional data provided in the Podmiot3 field. 

The purpose behind this solution is to continue the existing practice, which consists in providing data such as the particulars of the remitter, the recipient of the goods, the factor, the acquired company or VAT group members/ local government units on an invoice on a voluntary basis.

According to the information provided by the MF in the Q&A section of its website, suppliers must keep the KSeF invoice numbers because of the requirement to quote them in correction invoices should any such invoices be necessary. In the case of acquirers, there is no provision requiring them to do so, but this number is worth keeping as evidence, since the fact that it has been assigned proves that the invoice has been issued. Per the MF regulation published on 4 January 2024, the KSeF invoice number will have to be quoted in the JPK_VAT declaration; however, since the mandatory KSeF has now been postponed, the date when this requirement is to take effect is not known yet. As the MF has announced, this obligation will affect supply transactions only and is not intended at this point to cover acquisition transactions.

The implementation of the KSeF covers self-billed invoices. As the MF has explained, in this case the supplier will have to give the acquirer adequate authorisation in the system to enable the self-billing process. Within the self-billing procedure invoices will be issued directly by the acquirer and by entities with the acquirer’s authorisation to make out self-billed invoices in the KSeF. Additionally, the .xsd schema requires the invoice issuer to mark it with a tag which makes a document a self-billed invoice.

The structured e-invoices schema now in effect is FA(2). As the MF officials have announced, no additional changes are planned now which would affect the e-invoice schema. 

We provide answers to entrepreneurs’ questions concerning structured invoices (e-invoices). Taxable persons are in a position to make out their e-invoices under the law implemented on 1 January 2022.  Since the beginning of 2024, e-invoices have been one of the available forms of documenting supplies alongside hard copy and electronic invoices. 

Access to structured e-invoices issued will also be available on an anonymous basis, i.e. as long as the QR code and the data necessary to identify the invoice in the KSeF are provided or the invoice is labelled using the code.