Where does the return data come from? The eVAT XML in plain terms: content, data sets, mandatory elements
The eVAT return XML block by block: header, statements, VAT analytics, summaries and supplementary sheets, with mandatory fields, based on NAV's spec.
When a VAT return goes to NAV by XML upload or over the eVAT M2M connection, NAV does not receive a completed form but a data file. It states who the return is for and which period it covers, which statements the taxpayer makes, lists every invoice and other document that affects VAT, and gives the return’s totals. NAV builds the return from it.
The file is produced by filing software; nobody has to fill it in by hand. It is still worth knowing what data goes into it and where that data comes from: this determines how much preparation the migration needs, and what to look for when choosing and implementing software.
What does an eVAT return contain?
Header: who files, for which period, how often, and whether it is a base return or a self-revision.
Statements: for example, for a refund, where and how NAV should pay out the amount.
Transaction-level VAT records (vatAnalytics): every document affecting VAT payable or deductible, item by item — the core of the return.
Summary: the return’s totals: tax payable, refundable, or carried forward to the next period.
Supplementary sheets and attachment: only for certain transactions, such as reverse charge, self-revision or factoring.
The detailed description follows the same order. The names in brackets are those of NAV’s data structure — you will meet them in the specification and in software settings.
The return structure in detail
| Block | Mandatory | Contents |
|---|---|---|
| 1. Header (declarationInfo) | Yes | Taxpayer, return period, frequency, type of return and version number |
| 2. Statements (declarationStatements) | Content-dependent | Refund decision, procedural statements, refund instructions |
| 3. VAT analytics (vatAnalytics) | Yes | The document-level line items and their count |
| 4. Summary (declarationSummary) | Yes | The return’s totals, rounded to thousands of HUF |
| Original return summary (originalDeclarationSummary) | For self-revisions, corrections and fixes | The totals of the return being modified |
| 5. Supplementary sheets (sheetList) | For certain tax codes and statements | Reverse charge, self-revision, bad debt and other sheets |
| 6. Attachment (attachment) | No | Factoring contract |
1. Header (declarationInfo)
The header identifies the return. If it contradicts the sender’s permissions or the parameters of the return period, processing fails immediately.
| Field | Mandatory | Contents |
|---|---|---|
| taxNumber | Yes | The 8-digit base of the tax number, without VAT code and county code |
| declarationType | Yes | Type of return: NONE, or a special reason (e.g. termination, transformation, liquidation) |
| declarationKind | Yes | Kind of return; in liquidation, voluntary winding-up or compulsory strike-off, the phase of the procedure |
| declarationFrequency | Yes | MONTHLY, QUARTERLY or ANNUAL — must match NAV’s records |
| declarationPeriodStart, declarationPeriodEnd | Yes | First and last day of the return period |
| version | Yes | Version number of the upload: starts at 1 and increases by exactly one with every further upload |
| declarationMethod | Yes | Nature of the return: base return (BASE), self-revision (SELF_CHECK) or correction (CORRECTION) |
| navCorrection | Yes | Flags a fix made at NAV’s request |
| refundEntitlementCode | Conditional | For refunds, the entitlement code (A–D) under VAT Act ss. 153/A and 186 |
| vpid | Conditional | The 12-digit customs ID; mandatory for certain tax types on sheet 170 |
| modificationReference | Conditional | For self-revisions, corrections and fixes: processing ID of the modified return, sequence number of the modification, and for fixes the barcode sent by NAV |
For a given combination of taxpayer, type, frequency, period, version and method, only one submitted return can exist. Self-revisions, corrections and fixes can only be filed for a previously submitted (SUBMITTED) return; for a fix, the method must match that of the original. NAV’s developers have also answered separately on version numbering. NAV’s answer on versioning
2. Statements (declarationStatements)
This block holds the statements and refund instructions of the return form. It only needs data where the taxpayer claims a special status, procedure or refund.
| Field | When needed | Contents |
|---|---|---|
| returnDecision | With a negative balance | NO_RETURN (no refund requested), FULL_RETURN (full refund) or TAX_ACCOUNT_TRANSFER (transfer request — sheet 170 is then mandatory) |
| taxpayerStatusCode | For special taxpayer groups | Code for persons liable to tax who are not VAT-registered taxable persons (CODE_1, 3, 4, 5) |
| procedureStatements | In special procedural situations | Threshold exceeded, mid-year change of frequency, mid-year EU VAT number, out-of-turn return code, return to active status, payment deferral due to animal disease, tax liability despite exempt status |
| returnStatements | Mandatory for refunds | Public limited company flag, the statement under Art. 64 (3), and the refund method: domestic bank account, foreign bank account or postal payment |
3. VAT analytics (vatAnalytics)
The analytics are the substantive core of the return: they list every document — invoice, receipt, customs decision and other document — that affects the tax payable or deductible. What is sent is the company’s VAT records, at document level.
Number of analytics lines (totalRowCount): mandatory in every return and must match the actual number of lines. For a nil return it is 0 and there are no line items. Related message
Agricultural compensation premium (agriculturalCompensationPremium): if the analytics contain a 7% or 12% compensation premium, the number of purchase notes has to be given separately.
Line items (vatAnalyticsItem): one line per document and tax code, with the data structure below.
Line item data structure
| Field | Mandatory | Contents |
|---|---|---|
| lineNumber | Yes | Line number: sequential from 1, without gaps or repeats |
| sourceDocumentId | Yes | The document’s original number |
| sourceDocumentIssueDate | Yes | Issue date of the document |
| sourceDocumentType | Yes | INVOICE, RECEIPT, CUSTOMS_DECLARATION (import decision), DAILY_SUMMARY (cash register daily closing), OTHER (other document) |
| taxpointDate | Yes | Date on which the tax liability or the right of deduction arises |
| invoiceModificationOrCancellation | Yes | false by default; true only together with tax code MP31 |
| generalLedgerInformation | No | GL account, posting date, posting ID — if used, all three |
| partnerInfo.partnerStatus | Yes | DOMESTIC, OTHER, PRIVATE_PERSON or NOT_AVAILABLE |
| partnerInfo.partnerTaxData | Conditional | Domestic tax number (and group member’s), EU or third-country tax number — only one of them |
| partnerInfo.partnerName | Conditional | Wherever the tax number is mandatory, the name is too |
| partnerInfo.partnerAddress | No | Simple or detailed address — only one of the two |
| taxInformation.standardTaxCode | Yes | NAV’s standard tax code |
| taxInformation.ownTaxCode | No | Your own system’s VAT code |
| taxInformation.importerTaxNumber | Conditional | For indirect customs representation, the importer’s tax number |
| taxPosition.positionType | Yes | PAYABLE, DEDUCTIBLE or OTHER; at most one payable and one deductible position per line |
| taxPosition.taxBase, taxAmount | Yes | Tax base and tax in HUF, with at most two decimals |
| taxPosition.deductionOptions | Conditional | For partial deduction: the deduction rate and the deductible amount |
Tax point date (taxpointDate)
taxpointDate is the date on which, under the VAT Act, the tax liability or the right of deduction arises. In many cases it coincides with the supply date on the invoice, but not always — under cash accounting, for example, it is the payment date, so one document can have several tax point dates. The specification therefore explicitly does not consider it correct to copy the tax point date automatically from the supply date in Online Invoice; it has to be derived under the VAT Act. If the source system does not store it to the day, the last day of the return period is also accepted. For payable items the tax point date has to fall within the return period; for deductible items it may be earlier, but not earlier than the VAT Act allows. Related warning
Document ID and document type
sourceDocumentId is the original number of the invoice, receipt or decision — it links the line to Online Invoice data, and for self-revisions it is how original and corrected lines are paired. For documents booked in aggregate (for example purchase notes and handwritten receipts), the accounting document’s number and date are used; invoices, import decisions and cash register closings, however, cannot be recorded in aggregate. From version 2.0, one document can appear on several lines, so items with different tax codes no longer need to be combined in advance. For imports under indirect customs representation, the document ID is typically the decision number (MRN).
Partner data
The partner’s status determines which further data are mandatory. A partner with a Hungarian tax number — including organisations that are not VAT-registered — has DOMESTIC status, and its 8-digit base number and name are mandatory. Foreign organisations or those without a Hungarian tax number have OTHER status; an EU or third-country tax number can be given for them. The specification requires that, if the taxpayer does not have the partner’s EU VAT number, the value “0000” is entered in the field. Personal data of private individuals must not appear. The address is not mandatory: version 2.0 removed the earlier rule requiring it for domestic partners. Related message
Tax code, tax position and amounts
Every line must contain NAV’s standard tax code; your own system’s VAT code is recommended alongside it, as it speeds up troubleshooting. A line can have at most one payable and one deductible position; an OTHER position cannot be combined with any other. Tax base and tax are given in HUF with at most two decimals, and the system checks their ratio against the tax rate of the tax code — if they do not match, submission fails. According to the specification, any rounding to whole forints has to be done per line, not on the document or period total. There is no rounding to thousands in the analytics: that applies only to the summary data.
Partial deduction
Deduction data (deductionOptions) can only be given for a deductible position, and is needed when input VAT is only partly deductible. If the tax is fully deductible or fully non-deductible, it is not filled in. The specification gives two base cases:
| Case | Tax code | Tax base | Tax | Deduction rate | Deductible tax |
|---|---|---|---|---|---|
| Telephone service, 30% non-deductible (VAT Act s. 124) | MD66 | 370 | 100 | 0.7 | 70 |
| Apportionment with an 82% deduction ratio (VAT Act s. 123 (3)) | MD68 | 20,000 | 5,400 | 0.82 | 4,428 |
For tax codes MD64, MD65 and MD66, if deduction data is given, the deduction rate is also mandatory. If one item on an invoice is subject to an item-specific restriction and another to apportionment, the two items are recorded under two tax codes. For the year-end apportionment adjustment, not every affected invoice has to be repeated: it can be settled with one accounting document. Related message
4. Summary data (declarationSummary)
The summary contains the return’s totals, rounded to thousands of HUF by standard rounding; the system validates them at error level. The calculation logic:
Totals are summed per tax code, and only then rounded to thousands of HUF.
For items with restricted deduction, only the actually deductible tax counts.
The amount carried forward from the previous period (sumResidualTax) adjusts the result.
A positive balance gives tax payable (sumPayableTax); a negative balance gives an amount refundable (sumDeductibleTax) or carried forward to the next period (sumTransferableTax). For refunds, the statements block also has to be filled in.
For self-revisions, corrections and fixes, the totals of the original return must also be given (originalDeclarationSummary): from them the system determines whether the liability increased or decreased, and checks the supplementary sheets accordingly.
5. Supplementary sheets (sheetList)
In version 2.0, supplementary sheets no longer follow the logic of the ÁNYK form. For certain tax codes — for example some reverse-charge transactions — and certain statements, the relevant sheet is mandatory, which a separate validation checks. Sheet 03 is generated by NAV itself. Related message
| Sheet | XML node | Contents |
|---|---|---|
| 02 | animalDisease | Payment deferral due to compensation for animal disease measures |
| 04 | selfCheckAttachment | Self-revision annex |
| 06 | badDebt | Bad debt |
| 07 | reverseChargeSupply | Reverse-charge sales |
| 08 | reverseChargeService | Certain reverse-charge purchases |
| 09 | chassisNumberOfTheCar | Passenger car chassis number (VAT Act Annex 4/A) |
| A88 | newMeansOfTransport | Sale of new means of transport |
| 170 | requestForTransferAndRefund | Transfer and refund request |
6. Attachment (attachment)
Currently a factoring contract can be attached to the return. The document is uploaded in a separate operation (up to 100 MB), and the return refers to it by the ID received on upload (claimCheckId), which is valid for 72 hours.
Which data sets make up the return?
Behind the structure above are a few clearly separable data sets. For each, it has to be clear which system is the authoritative source and how the data reaches the filing software:
| Data set | Typical source | XML block |
|---|---|---|
| Issued and received invoices | Invoicing system, ERP, invoice receipt process | VAT analytics (INVOICE) |
| Cash register sales | Online cash registers, eReceipt | VAT analytics (DAILY_SUMMARY or RECEIPT / INVOICE) |
| Imports | Customs decisions | VAT analytics (CUSTOMS_DECLARATION) |
| Other documents | VAT records: purchase notes, handwritten receipts, adjustments | VAT analytics (OTHER) |
| Partner data | Partner master data | VAT analytics — partner data |
| Tax codes | Internal VAT code → NAV standard tax code mapping | VAT analytics — tax information |
| Filing decisions | Chief accountant, finance management | Header, statements, supplementary sheets |
| Previous-period data | Earlier returns | Summary data |
What does this mean for you?
For companies
In a company, most of the data already exists in the ERP, the invoicing systems and the cash register data. The key implementation question is whether the software takes over every data set from a clear source, applying consistent rules:
One document type, one authoritative source: if the same document appears in several systems (for example invoicing and ERP), it has to be decided in advance which one is authoritative — otherwise duplicate or missing lines appear.
A maintained tax-code mapping: the mapping between internal VAT codes and NAV’s standard tax codes is best managed as a table, not in program code, because NAV’s catalogue can grow with changes in the law.
Traceability: passing the optional general ledger identifiers means a line-level NAV message can be traced straight to the source record, and for self-revisions the original and corrected analytics can be compared automatically.
The implementation should accept transaction-level VAT data from a controlled source, apply the approved tax-code mapping and validate the resulting XML before submission.
For accounting firms
In an accounting firm, the same XML structure is produced from different accounting systems and practices for each client. The main risk therefore lies in how data is taken over differently from client to client:
Tax-code mapping per client: as many mappings as there are accounting systems and VAT-code lists. Start from a shared, versioned base table and handle only the differences per client.
Retail clients with cash registers: daily closings and the split between receipts and invoices can differ by client, depending on booking practice.
Documents booked in aggregate: purchase notes and handwritten receipts can be aggregated; invoices, import decisions and cash register closings cannot. This needs checking client by client.
Reconciliation: the documents NAV holds can be queried per client, so missing lines show up before submission.
For accounting firms, the filing process should keep client data and permissions separate while providing a consistent workflow across the client portfolio.
Suggested division of responsibilities
The eVAT rules do not prescribe an internal responsibility structure. It is advisable, however, to designate who maintains each data set and investigates NAV feedback — so that an error message quickly reaches someone who can fix it. The split below is a starting point to adapt to your own organisation:
| Task | Typically in a company | Typically in an accounting firm |
|---|---|---|
| Complete recording of documents | Invoicing (issued), procurement and payables (received) | The client hands them over, the firm checks completeness |
| Maintaining partner master data | Finance or master data owner | The firm, per client |
| Tax-code mapping | Chief accountant, with a tax adviser where needed; recorded in the filing software | The firm’s lead accountant, per accounting system |
| Tax point date and period allocation | Accounting | The responsible accountant |
| Partial deduction (apportionment, restrictions) | Chief accountant, with a tax adviser where needed | The responsible accountant, based on the client’s data |
| Producing and validating the return file | Filing software, overseen by finance | The firm’s filing software |
| Technical user and permissions | Finance department, chief accountant, the company’s representative or authorised agent | The client’s representative, or the firm under an authorisation |
| Investigating NAV feedback | By message type: accounting, chief accountant, or the software operator for technical errors | The firm, involving the client where needed |
| Decision to submit | Finance director or chief accountant | Agreed with the client |
The specification itself notes that, depending on their nature, warnings may be worth making available to the user, the accounting function, technical support or the software developer. eVAT validation messages, by area
How does the file reach NAV?
Over M2M, the filing software sends not only the return data but also an accompanying request that identifies the sender and describes the upload. NAV defines the two in separate data structures: the return content in earData.xsd, and the submission requests in earAPI.xsd and the related shared schemas.
Submission step by step: the software announces the upload, uploads the file — split into at most 16 parts for large files, up to 128 MB each — and then closes the upload. NAV then processes and validates the data; if everything is in order, the return has to be submitted in a separate step. The sender is identified by the technical user’s credentials. Validation is covered in part 2 of the series.
Reconciling with the data NAV holds
Over M2M, the data NAV holds can also be queried, so missing lines in the analytics show up before submission. The document-list query returns, for a tax period, the invoice, cash register and customs decision digests NAV has on record. For each invoice and customs decision, you can also query which tax code NAV assigns to it and which VAT-related warnings belong to it. These require the technical user to have the “VM2M Convenience services, queries” permission.
Practical cases: which value goes into the XML?
Which value goes into the XML?
Six situations that come up in almost every implementation. The question is always what data the software has to produce; the explanations are based on the specification.
- Cash-accounting invoice: supply in March, the customer pays in April. What is in the taxpointDate field in the April return?
- The invoice’s supply date (March) — No. taxpointDate is the date on which, under the VAT Act, the tax liability or the right of deduction arises. Under cash accounting that is the payment date, so one document can have several tax point dates.
- The posting date — No. The posting date belongs to the optional general ledger data (glPostingDate); it does not indicate when the tax falls due.
- Correct: The payment date (April) — Correct. According to the specification, for cash-accounting transactions taxpointDate is the date of payment.
- Landline telephone invoice: tax base HUF 370, VAT HUF 100, of which HUF 70 is deductible by law. What data does it carry in the analytics?
- taxAmount = 70, without the difference — No. taxAmount is the full tax on the invoice; the restriction is described by the deduction data.
- Two lines: 70 deductible and 30 non-deductible — No. The restriction is marked on one line with the deduction data. Two tax codes are needed when different rules apply to different items of one invoice (e.g. MD66 and MD68).
- Correct: MD66, taxBase 370, taxAmount 100, deductionRate 0.7, deductionAmount 70 — Correct — this is the specification’s own example. With a percentage restriction on deduction (VAT Act s. 124), the deduction data must also be given; for tax codes MD64–MD66 the deduction rate is then mandatory.
- A German partner’s EU VAT number is missing from your records, although the transaction requires one. What partner data goes into the line?
- Correct: OTHER status, with “0000” in communityVatNumber — Correct. The specification requires that, if the taxpayer does not have the partner’s EU VAT number, the value “0000” is entered in the field. Only an EU VAT number may appear there, and only one of the domestic, EU and third-country tax numbers may be given.
- DOMESTIC status, without a tax number — No. DOMESTIC status is only for partners with a Hungarian tax number, and there the tax number is mandatory.
- The partner data can be omitted — No. Partner data is mandatory on every line, at least the partner status.
- Purchase notes (felvásárlási okirat) are booked monthly in a single accounting document. Which document ID goes into the line?
- Every note on its own line with its own number — mandatory — Not mandatory. For document types booked in aggregate (e.g. purchase notes, handwritten receipts), the specification allows them to be recorded via the accounting document.
- Correct: The number of the accounting document — Correct. The number and issue date of the accounting document are used. This does not apply to invoices, import decisions and cash register closings: recording those in aggregate may trigger a warning.
- The internal ID of the accounting software — No. sourceDocumentId is the document’s original number. The accounting system’s internal ID belongs in the general ledger data (glTransactionId).
- A purchase invoice contains items at both 27% and 5%. How does it appear in the analytics?
- On one line with a combined tax base — No. Items with different tax codes cannot be combined, because the system checks the ratio of tax base and tax per tax code.
- Correct: On two lines with the same document ID — Correct. From version 2.0, one document ID can appear on several lines, so items with different tax codes can be sent on separate lines without prior aggregation.
- On two lines, the second document number with a “-2” suffix — No. The document ID must contain the original number; with a suffix, matching against Online Invoice data would not work either.
- In one quarter there were no taxable transactions and no deductions. What do the analytics contain?
- No XML needs to be sent — No. A return is still due, and the analytics node is mandatory in every return.
- One line with zero amounts — No. Analytics without line items is correct; a zero line without a real document would be incorrect data.
- Correct: totalRowCount = 0, without line items — Correct. A nil return is described by totalRowCount = 0 and by omitting the node containing the line items.
How SimplyX supports this
With SimplyX there is no need to work with a finished XML. The VAT analytics can be loaded as an Excel file; after mapping the columns and tax codes, SimplyX generates the eVAT XML NAV expects, validates it before submission, displays NAV’s validation results, and the user submits the return from the SimplyX interface over the eVAT M2M connection. Processing status and NAV responses can be followed in one place. Accounting firms and groups can manage multiple companies in a shared system, with per-company permissions, separated data, role-based access and a full audit log. How SimplyX eVAT M2M works
Related resources
Standard tax-code catalogue — all NAV standard tax codes, searchable
eVAT validation messages — every message with its conditions
eVAT M2M registration — technical user, keys and permissions
eVAT XML checker — schema validation in the browser
Next step
The most sensitive point of the analytics is the tax code: part 4 of the series covers mapping internal VAT codes to NAV’s standard tax codes, with practical cases. Channel selection and the validation process are covered in part 2.
Sources
NAV: eVAT M2M 2.0 interface specification, v1.1 (July 2026, in Hungarian)