There are many e-tax requirements in force in Hungary, headed by real-time invoice reporting (RTIR). However, SAF-T obligation has not yet been introduced. This status is going to be changed, as Hungary is planning to introduce SAF-T still in 2022.
Background
Hungary started its SAF-T journey at the end of 2019, when tax authorities (NAV) published a proposal of SAF-T structure.
In the beginning, introduction of SAF-T was planned to take place in 2021. However, due to COVID-19 pandemic, it has been postponed. Although there is no official go-live date provided yet, there are leaks that SAF-T may come into force still in 2022 or early in 2023.
Above dates sound reasonable, considering it is already more than 2 years since the project started. Also, there is detailed technical documentation on SAF-T HU provided by NAV already.
SAF-T HU structure
SAF-T Hungary is divided in many structures covering various taxpayer finance and accounting areas. That is a similar model to Polish SAF-T (JPK). However, SAF-T HU consists of more different structures than Polish JPK. NAV underlines that such design will simplify generating of SAF-T files from various sources such as: ERP, warehouse system, billing system etc.
On top of SAF-T HU structure hierarchy there is the Table of Contents (TOC) with the information about files to be provided to NAV. Actual SAF-T data are divided into three main sections:
- Master Data – contains general information about suppliers, customers, chart of accounts, products, company stakeholders;
- Transactional data – contains detailed information about taxpayer general ledger entries, sales and purchase invoices, payments, stock movements;
- Reporting data – contains information about specific reporting obligations such as disclosure of outstanding sales/ purchase invoices or VAT analytics.
Technical outline
As most of electronic tax requirements, SAF-T HU will be reported in XML format. Generated XML files will have to be in line with the structures described in previous paragraph. The structures themselves are provided in XSD format, which defines how XML files should be built.
NAV imposes strict restrictions on naming of SAF-T files submitted to tax authorities. Each file needs to follow the logic below:
SAFTHU_TaxpayerNumber_StructureCode_PartNumber_NumberOfParts.xml
For example, a file named SAFTHU_HU12345_SUP_1_3_xml describes a first part out of three of the files generated by a taxpayer with VAT ID HU12345 covering master data of suppliers.
Unfortunately, one of the biggest unknown of Hungarian SAF-T is how generated files will be submitted to NAV. It is expected that myNAV/ NAV Online solutions will be adjusted to SAF-T, but no details are available at this moment.
Mappings are required
The main purpose of introducing digital tax reporting requirements is to reduce tax frauds. However, unifying the way of reporting is also important. In case of Standard Audit File for Tax, as the name suggests, standardization of format of data reported to tax authorities takes place as well. All taxpayers have to submit their detailed finance and accounting data in exactly the same format set by NAV.
However, many companies, especially large corporations following international finance standards, often do not have data in the required local format. Therefore, one of the key activities enabling correct SAF-T reporting is mapping of data from taxpayer ERP to SAF-T format.
For example, businesses often use their individual chart of accounts. Whereas, SAF-T HU requires in such cases mapping of taxpayer chart of account to Hungarian Standard Chart of Accounts (SCoA). The table above presents only the example of Hungarian SCoA. Total number of standard accounts is nearly one thousand.
Another example of mapping, which might be required for SAF-T purposes is related to taxes. Hungarian companies should follow tax types provided in Annex II to SAF-T HU documentation. For instance: code 101 indicates CIT, 104 indicates VAT, 300 indicates advertising tax, 901 indicates custom duties. All pieces of information about taxes should be in line with these standard codes.
Is SAF-T last stage of Hungarian e-tax story?
Two years ago, we published the article about Hungarian e-tax journey from VAT Ledger requirement to Real-Time Invoice Reporting (RTIR). SAF-T seems to be a missing puzzle piece in this story. However, will SAF-T be the last digital tax reporting requirement introduced in Hungary?
I presume, it will not. Indeed, Hungary is probably the country with the highest number of various comprehensive tax reporting requirements. However, there is still a space to introduce new obligation. For example, electronic invoicing in clearance model may in the future replace RTIR. Although Hungary RTIR is considered to be real-time requirement, in fact it is still post-audit type of reporting. Whereas, clearance model (examples: Italy, Turkey, very soon Poland) gives an instant information to tax authorities on transaction performed, before an invoice is shared with a customer. Anyway, it is never boring in taxes!
