Transfer pricing data reporting: What does the Hungarian Tax Authority actually see on the ATP forms?

Below we summarise the types of conclusions the tax authority may draw from the transfer pricing data reporting and highlight the key points to watch out for when filling in the ATP forms, which form part of the corporate income tax return.

Transaction-by-transaction breakdown – Full transparency in related party transactions

One of the main features of the ATP forms is that each related party transaction must be reported separately.

The company must:

• report each related party transaction individually,
• apply transaction grouping only under strict conditions,
• indicate the transfer pricing method applied,
• specify the transaction value and direction (income or cost).
• the number and type of related parties,
• the volume of the transactions, and
• the method applied by the company to justify the arm’s length price.

Based on this, the NAV obtains an accurate picture of:

• the number and type of related parties,
• the volume of the transactions, and
• the method applied by the company to justify the arm’s length price.

Detecting discrepancies between accounting data and transfer pricing data

The NAV does not examine only the data reported in the transfer pricing forms. The information provided on the ATP forms can be cross-checked against other sources, such as online invoice data, tax returns, or other external datasets.

Although the algorithms used are not public, practical experience suggests that the following discrepancies are highly likely to attract attention:

• Differences between revenue and cost figures reported in the ATP forms and those in other NAV databases (e.g. online invoice system),
• The volume of related party transactions and their proportion to the total business activity,
• The internal consistency of tax base adjustments and the alignment of applied pricing methods.

Risk Screening: Automated algorithms and targeted focus

Based on the data reporting, the NAV establishes risk profiles.

Factors that play a role include:

• Type of transfer pricing method applied (e.g. internal vs. external benchmark),
• Pricing outside the interquartile range,
• Loss-making operations alongside related party transactions,
• Frequent adjusting (debit/credit) entries.

Although the operation of the analytical algorithms is not disclosed, in practice certain patterns (e.g. repeated losses, inconsistency in transfer pricing methods) often lead to targeted inquiries, documentation requests, or audits by the tax authority.

Common Errors in Transfer Pricing Data Reporting – What NAV Monitors

Based on practical experience, the NAV is particularly sensitive to the following issues:

• Missing data (e.g. transaction group without description),
• Methodological inconsistencies (e.g. arm’s length price without benchmark),
• Logical anomalies (e.g. loss-making operations with a positive markup),
• Lack of comparability (e.g. different currencies, periods).

Even a single technical error or inconsistency can trigger a series of questions from the tax authority.

Best practices for completing the ATP forms correctly

Understanding the authority’s logic is essential for successful compliance.

Best practices include:

• Aligning the content of the data reporting with the transfer pricing documentation,
• Preparing the rationale and explanation behind the figures in advance,
• At least internally validating the arm’s length price for each transaction,
• Incorporating benchmarks or other substantiating evidence into the background analyses related to the forms.

Data reporting is not just administration – It’s a mirror

Transfer pricing data reporting has elevated the transparency of related party transactions to a new level. What was previously hidden in the documentation system now goes directly to the authority – in a structured, processable format.

The question is no longer what the NAV will ask – but what it can infer. And what it sees behind the numbers.

Request transfer pricing advisory support

This is why data reporting should not be treated as a routine, after-the-fact task. It requires deliberate preparation, a unified data and logical framework – otherwise, it will not be the documentation but the inconsistencies that will speak on behalf of the company.