Save

How to create valid XML for real time invoice reporting?

As you may know from 1 July 2018 the Hungarian Tax Authority (HU TA) expects the real-time invoice reporting (RTIR) to be done in XML file format. The structure of the data file is described by the XSD scheme published by the HU TA.

This XSD schema contains more than 2,000 lines and describes as many scenarios as possible. For example it also contains the structure of the data of the address of the fiscal representative. However most of these lines may not be applicable in your specific case. The fiscal representative example is a good one – you will not need this data unless you have fiscal representative.

What needs to be in the reportable XML file?

Only the mandatory data prescribed to be on the tax invoice by the Hungarian VAT Act should be in the reportable XML file as well as some technical data prescribed by the XSD schema, such line number, invoice type. Other data is not mandatory to report, but may be reported on a voluntary basis.

What is the mandatory data prescribed to be on the invoice by the Hungarian VAT Act?

You can find the list of compulsory invoice items in Section 169 (and related sections) of the Hungarian VAT Act. You can find this list here:  https://onlineszamla-test.nav.gov.hu/laws.

As you may see some data must be on the invoice in all cases (such as the date of issue of the invoice),other data must be on the invoice only in certain cases (for example the words “pénzforgalmi elszámolás” (“cash accounting”) need to be on the invoice only when using the special taxation scheme defined under Chapter XIII/A). Another good example of such item is the VAT ID number of the Customer, which is mandatory by the VAT Act in cases where the VAT exceeds HUF 100,000 and voluntary in other cases. Therefore the XSD schema describes the Customer VAT ID item as non-mandatory, whereas in some cases it may be mandatory,

What are the examples of the details one must pay attention to?

A good example of this would be the tax point on the invoice, describe in point g) of Article 169 of the VAT Act as the date referred to in Paragraphs a) and b) of Subsection (1) of Section 163, if other than the date of issue of the invoice. You may need to do some further reading of the VAT Act only to find out that the Paragraphs a) and b) of Subsection (1) of Section 163 actually mean the delivery date or the tax point.

The next step would be to understand the difference between the tax point and the invoice issue date. The tax point rules are very complicated in Hungary and depend on the nature of the specific transaction you wish to invoice. There are different tax point rules for normal deliveries, partial deliveries, periodic supplies and advance payments. You need to know these VAT rules, understand the nature of your transactions to be able to draw conclusions from the rules in order to set up the right date in the XML.

What about the data prescribed by other tax laws?

To add to the complexity there is also data which is prescribed to be on the invoice by other tax or non-tax laws. For example, did you know that the intermediated services should be mentioned on the invoice if you are recharging services – this obligation is detailed in the Local Business Tax law, not in the VAT Act. How about putting the reference to the Environmental Product Fee (EPF) Act in case of some transactions that involve supplies of goods that contain materials that deemed to be harmful by the Hungarian EPF law? This data should be on the invoice, but this obligation is prescribed by laws other than the VAT Act. This means it is not mandatory to include them into the reportable XML but you may include them and report on a voluntary basis.

Are there different rules for various types of invoices? 

While most of the data is similar, yes, there are some different XML rules for various types of invoices. Typically businesses issue these types of invoices:

  • advance payment invoices
  • credit/debit notes
  • aggregate invoices
  • periodic supply invoices
  • discounts/vouchers
  • electronic invoices
  • cancelation invoices

It can also be a combination of the above. For example, you may be issuing an invoice that cancels a discounted advance payment electronic invoice.

Conclusions:

Consider the following subsets of data:

  • Mandatory to be on the invoice by VAT Act in all cases (such as the date of issue) – must include in XML
  • Mandatory to be on the invoice by the VAT Act in some cases (such as tax point) and non-mandatory in other cases – in some cases you must include it XML, in other cases, you may include it if you wish so
  • Mandatory technical data prescribed by the XSD schema such as line number or invoice type – include this data into the XML file, despite the fact that it is not mandatory by the VAT Act
  • Mandatory invoice items prescribed by other tax or non-tax Acts in some cases (such as intermediated services or EPF) and non-mandatory in other cases – it is not mandatory to include it in the reportable XML, but you may include these items on a voluntary basis
  • Other non-mandatory information that is on the invoice, such as “ship to address” or bank account number - it is not mandatory to include these items in the reportable XML, but you may include it if you wish so. The XSD schema would provide fields for non-mandatory items too.

Here is the list of questions we think is important to ask:

  • What is the structure of the XSD schema?
  • What part of the XSD scheme is relevant to me?
  • What is mandatory data by the VAT Act to be on the invoice in general?
  • What is mandatory data by the VAT Act to be on the invoice in my specific case in the specific transaction I am invoicing?
  • Is the VAT treatment of the transactions my organisation invoices correct?
  • What else should be on the invoice, prescribed by other laws?
  • Do I want to include non-mandatory data in the reportable XML?
  • Are there any other purposes I will use the XML data, besides reporting, that I will use it for – your business partners may kindly ask you to send them the XML data in addition of the invoice, so that they process your invoices faster (and potentially pay you faster)
  • Do I also wish to comply with the “data export requirement” set up by the Hungarian VAT law – a “two solutions in one go” approach.

How can you design the correct XML format yourself?

  1. Please read the guidance issued by the Hungarian Tax Authority (HU TA) here: https://onlineszamla-test.nav.gov.hu/dokumentaciok
  2. It contains xsd schema and detailed description of the what needs to be on the invoice.
  3. Once you are ready with your own XML file, check your XML file at our website: XML validator.

Need help?

Our XML VAT IT advisors can help you to answer the above questions – a dedicated team of VAT professionals experienced in VAT laws and processes with the great sense of technology. We can help you to design your own XML data based on the actual invoices you issue in full understanding of the VAT treatment of your transactions. 

    Related posts

    We use cookies for the operation of our website in order to make the individual functions more easily accessible for visitors and to receive statistical data on the usage of our website. The statistical data pertaining to the usage of our website is provided to us by Google Analytics. The statistical data does not allow us to identify the visitors of the website and to record any personal data on them. The picture given on user habits does not contain information concerning either the individual or all of the visitors. When considering consent, please take into account that by enabling cookies we can get a more accurate understanding of what visitors of our website are interested in, due to which we can upload material that will attract more interest. If cookies are enabled, based on the websites visited, Google will display ads that may interest you more. The information provided via cookies does not contain any personal data in this case either. The Help section of your browser can provide more information on the application of cookies. Read more on our updated data protection policy here. More