From VAT codes to NAV tax codes: how to map them for eVAT
How to map internal VAT codes to NAV standard tax codes for eVAT: how the codes are built, the steps, partial deduction and the most common exceptions.
In eVAT, every item in the VAT analytics must carry NAV’s standard tax code. It tells NAV’s system which line and field of the return the item’s amount belongs to. Accounting systems, however, work with their own VAT codes, so before filing, every internal VAT code has to be assigned the matching NAV code. The specification calls this one of the key preparation tasks for eVAT.
Mapping is more than a two-column list. Internal VAT codes usually describe transaction types, whereas NAV’s standard tax codes determine the relevant return lines. This article explains that distinction, the structure of NAV codes, the mapping process and the most common exceptions.
NAV’s standard tax-code catalogue in numbers
- 234 standard tax codes in the catalogue of 4 September 2026
- 8 code element types: main lines, detail lines, sheet and additional marker
- ≤ 2 tax positions per code: at most one payable and one deductible
Source: NAV standard tax-code catalogue and eVAT M2M 2.0 specification
What changes compared with ÁNYK?
In the ÁNYK VAT return, the taxpayer filled in the lines of the return — directly or through their accounting software. Each line held the aggregated tax base and VAT of the transactions belonging to it; the return did not show which documents a line was made up of.
eVAT reverses this division of work. The taxpayer no longer submits line totals, but the documents behind them, item by item, each with a standard tax code. The return lines are produced by NAV’s system: it aggregates the items by standard tax code and derives the tax base and VAT of each line from them. The taxpayer still reports the main totals of the return — VAT payable, refundable or carried forward — but NAV checks them against the values calculated from the items.
| Question | ÁNYK | eVAT |
|---|---|---|
| What does the taxpayer submit? | Tax base and VAT aggregated per line | Documents item by item, with a standard tax code |
| Who builds the return lines? | The taxpayer or their accounting software | NAV’s system, aggregating by tax code |
| What role does the tax code play? | An internal classification in the accounting software, not shown in the return | The classification that determines the content of the return |
As a result, in eVAT the tax code is not supplementary data: if it is wrong, the item’s amount lands in the wrong return line, even if the document itself is reported correctly. The accuracy of the mapping therefore directly determines whether the return is correct.
Why does the internal VAT code differ from NAV’s code?
Businesses typically set up internal VAT codes by transaction type: separate codes for phone bills, fuel, entertainment, company car costs or tangible assets. That way the books show at a glance what kind of event it is, and the deductible share can be calculated automatically.
NAV’s standard tax code answers a different question: which line or lines of the return the item affects. According to NAV’s developers, the standard tax code is a unique identifier that determines which field of the return the item’s amount goes to. The catalogue therefore essentially maps combinations of return lines, not transaction types.
This leads to the most important practical point: where the transaction type does not change the return line, NAV has no separate code either. Phone bills are a good example. Internally they usually have their own code, because only 70% of the VAT is deductible. In the return, though, they go to the same line as any other 27% domestic purchase. In NAV’s analytics they get the general MD66 code, and the partial deduction is described not by the code but by the deduction data given for the item (deduction rate and deductible amount).
| Internal VAT code (example) | NAV standard tax code | Needed in addition to the code |
|---|---|---|
| Purchase 27%, general expense | MD66 | — |
| Purchase 27%, phone (30% non-deductible) | MD66 | Deduction rate 0.7 and deductible amount — VAT Act §124(3) |
| Purchase 27%, company car running costs or rental (50% non-deductible) | MD66 | Deduction rate 0.5 and deductible amount — VAT Act §124(4) |
| Purchase 27%, deductible by apportionment | MD68 | Deduction rate and deductible amount |
| Purchase 27%, tangible asset | MD66 DD77 | The asset nature is carried by the code |
| Purchase, non-deductible (parking, catering) | KL V00 — or the item can be left out | — |
| Domestic reverse-charge purchase, with deduction | MP29 MD66 | One payable and one deductible position |
| Sale 27%, advance payment | MP07 DP45 | — |
The table shows the two most common mismatches. Several internal codes map to the same NAV code (phone, general expense, car services → MD66), and one generic internal code can hide several NAV codes (“purchase 27%” → MD66 or MD66 DD77). The first case is fine; the second needs a decision: either finer-grained internal codes, or a mapping that also looks at another attribute, such as the GL account.
How is a NAV standard tax code built?
A standard tax code consists of elements separated by spaces. Each element refers to a return line, a sheet or an additional marker, so the code itself shows where the item goes.
| Element | Meaning | Example |
|---|---|---|
| MPxxx | Main payable line | MP07 — domestic sale at 27% |
| DPxxx | Payable detail line | DP45 — advance payment |
| MDxxx | Main deductible line | MD66 — deductible VAT on domestic purchases at 27% |
| DDxxx | Deductible detail line | DD77 — tangible asset purchase |
| DHxxx | Detail highlight line | DH90 — supply of goods outside the territorial scope |
| PGxxx | Supplementary sheet | PG08 — sheet for reverse-charge purchases |
| Kxxx / Vxxx | Key–value pair for an additional marker | VV — iron and steel, VM — agricultural products |
A combined example: MP29 DP101 MD66 PG08 VV denotes a reverse-charge purchase of iron and steel products at 27% with deduction. MP29 is the line for VAT payable under reverse charge, DP101 the related detail line, MD66 the deductible VAT, PG08 the mandatory supplementary sheet and VV the product group. One code thus drives five return data points at once.
Which elements can appear together?
NAV’s description also sets out how elements can be combined. Every code contains at least one main line; whether it is payable, deductible or both depends on the transaction:
Payable VAT only: if the code has no main deductible line, it must contain exactly one main payable line. An example is an intra-Community acquisition of goods at 27% without deduction: MP14.
Deductible VAT only: if the code has no main payable line, it must contain exactly one main deductible line. An example is the deductible VAT on a 27% domestic purchase: MD66.
Both: if the transaction creates both payable and deductible VAT, the code contains both main lines — for example an intra-Community acquisition of goods at 27% with deduction: MP14 MD69.
A code can have at most two tax positions: at most one payable and at most one deductible. The OTHER position, typically used for items that create no Hungarian VAT liability, cannot be combined with any other position.
Standard code and short code
Next to every standard code, the catalogue also lists a shorter, so-called descriptive code — for example F07 next to MP07, L66 next to MD66. According to NAV’s developers, the short code only appears in the web interface, as a label mapped one-to-one to the standard code. XML upload and the machine connection always use the standard tax code.
Where your own VAT code goes in the XML
Each item can carry two codes: the mandatory standard tax code and the optional company code (ownTaxCode). The schema imposes no format on the company code. The specification still recommends including it, because without it, tracing a rejected item back to the internal code and mapping behind it is harder.
The catalogue: fixed, but it can change
NAV publishes the standard tax codes as an Excel table in the nav-gov-hu/eVAT GitHub repository and on the eVAT documentation site, and they can also be queried over the machine connection. According to NAV’s description, only the currently valid standard tax codes can be used in eVAT, but the list can be extended based on user proposals and when the law changes.
A code’s meaning does not change. According to NAV’s developers, the same tax code always means the same thing; if the content changes, a new code is created. A mapping therefore does not go stale “silently”.
Validity is tied to dates. The catalogue query returns the codes valid on a given day, with the start and end of validity. NAV measures a code’s validity against the item’s tax point date.
Not every transaction has a code. A business software developer reported on NAV’s developer forum that 254 of its 274 internal VAT types could be mapped unambiguously, while for 20 it found no matching code in the catalogue. In such cases it is worth contacting NAV: according to the Readme, the catalogue can be extended on request.
The catalogue can contain errors too. Public reports in the repository have included swapped descriptions, a missing code element and a double space inside a code. It is therefore best to take the catalogue from the machine query and compare each new version with the previous one.
According to NAV, the catalogue of 4 September 2026 brought no substantive code changes, only corrections. The current list can be searched in our tax code database.
The mapping, step by step
| Step | Task | Why it matters |
|---|---|---|
| 1. Inventory | Collect the internal VAT codes actually in use, based on the last one or two years of activity | According to NAV’s developers, map the codes the business uses, not the whole catalogue |
| 2. Return line | For each internal code, record which return line or lines it has fed so far | The standard code maps return lines, so this is the most reliable starting point |
| 3. Assignment | Choose the NAV code from the catalogue based on those lines | For complex transactions (reverse charge, intra-Community acquisition) one code covers several lines |
| 4. Split | Where one internal code splits into several NAV codes, decide whether to split the internal code or add a condition | For example tangible assets, contributions in kind, advance payments |
| 5. Deduction data | For partial deduction, define how the deduction rate and deductible amount are derived | This is data, not a code; for MD64–MD66 the rate is then mandatory |
| 6. Testing | A test return on a closed period, comparing NAV feedback and NAV’s suggested codes | A wrong mapping surfaces before the live return |
| 7. Maintenance | A versioned table with validity dates; review on every new catalogue and new internal code | According to NAV, no return can be built from an invalid code |
Within a document, items do not have to be passed invoice line by invoice line. According to NAV’s developers, eVAT is document-based: items with the same tax code can be combined, and items with different codes appear as separate tax data or on separate lines with the same document ID. One point needs care, though: if one item on an invoice falls under an item-specific deduction rule and another under apportionment, the two cannot be merged — the specification requires two codes (for example MD66 and MD68).
Partial deduction: data, not a code
The most common misunderstanding in mapping is partial deduction. Internal systems often use a separate VAT code for it, whereas at NAV the deductible share sits in the item’s deduction data:
Percentage restriction (VAT Act §124(3)–(4)): 30% of the VAT on phone and internet-based voice services, and 50% on services needed to run and maintain a passenger car and on car rental, is non-deductible. The item uses MD66 with the full VAT, plus the deduction rate and deductible amount.
Apportionment (VAT Act §123): code MD68 with the deduction rate. The year-end adjustment does not require repeating every affected invoice; it can be settled with a single accounting document.
Full prohibition (VAT Act §124(1)–(2)): the item can be left out, or reported with KL V00. No deduction rate is needed; its value could only be above 0 anyway.
If the deductible amount exceeds the VAT, or for MD64–MD66 the rate is missing next to deduction data, NAV’s system rejects the item with an error. Related validation messages
What does this mean for you?
For companies
In a company, the mapping looks like a one-off project, but it is really master data that needs ongoing maintenance. The specification itself recommends handling NAV codes as external, editable configuration rather than hard-coding them.
A designated owner: the content of the mapping table is typically owned by the chief accountant or the tax function, with a tax adviser where needed — the technical setup is the software’s job.
No new internal code without a mapping: when a new VAT code is created in the ERP, assign its NAV code straight away, otherwise the gap only shows up in the first return.
Pass your own code: the internal VAT code (ownTaxCode) is optional, but when NAV flags an item it shows at once which internal code and mapping caused it.
Treat the mapping as editable, versioned master data so that new internal codes and changes to NAV’s catalogue can be reviewed and introduced in a controlled way.
For accounting firms
In an accounting firm, the mapping repeats for every client, but it does not have to start from scratch each time. Clients’ books typically run in a handful of accounting programs, with similar VAT-code lists.
A base table per accounting program: start from a shared, reviewed mapping and record only the differences per client.
Higher-risk clients: clients using apportionment, affected by reverse charge, importing or buying tangible assets need extra attention for both the mapping and the deduction data.
Annual review: when a new catalogue is published, check client by client whether the change affects the codes in use.
For accounting firms, mappings may differ by client and should therefore be maintained and approved separately for each company.
What can the software query from NAV?
Three queries over the machine connection support the mapping. All three require the technical user to have the “VM2M convenience services, queries” permission.
| Query | What it returns | What it is for |
|---|---|---|
| Tax-code catalogue (queryTaxCodeCatalog) | The codes valid on a given day, with validity period, payable/deductible flags, description, return lines and mandatory sheet | Keeping the catalogue in the software up to date |
| Invoice tax codes (queryInvoiceTaxCode) | The tax codes NAV assigns to an invoice — per line on request — and VAT-relevant warnings | Comparing your own mapping with NAV’s classification |
| Customs decision tax codes (queryCustomsDeclarationTaxCode) | The tax codes assigned to an eVÁM customs decision | For import items; NAV typically processes the decision within 24 hours |
The code NAV suggests is a good checkpoint, but it does not replace your own classification. The suggestion is based on invoice data, so it cannot know circumstances that depend on the taxpayer’s decisions — for example whether a purchase is a tangible asset, or what share of its VAT is deductible.
NAV feedback related to tax codes
A wrong mapping is caught by NAV’s checks. The key tax-code messages:
| Message | Severity | When it occurs |
|---|---|---|
| INVALID_TAXCODE | Blocking | The code is not in the catalogue, or the item’s tax point date is outside its validity |
| STANDARDTAXCODE_PAYABLE / DEDUCTIBLE / OTHER_NOT_ALLOWED | Blocking | The position does not fit the code, e.g. a deductible position on a payable code |
| MISSING_DEDUCTION_RATE | Blocking | For MD64–MD66, the rate is missing next to deduction data |
| INVALID_DEDUCTION_AMOUNT | Blocking | The deductible amount exceeds the VAT |
| MISSING_STANDARD_TAX_CODE | Blocking | A supplementary sheet is present without a related tax code |
| INCOMPATIBLE_TAXCODES | Warning | Incompatible codes on one document, e.g. domestic and intra-Community supply |
| CONFLICTING_STANDARDTAXCODE | Warning | The item carries VAT, but Online Invoice data shows it as exempt |
| TAX_CODE_NOT_SELF_CHECK | Warning | An MP31 item in a self-revision, although it is typically settled in the current return |
Explanations, fixes and related answers from NAV’s developers can be searched in the validation message database. eVAT validation messages
Practical cases: which NAV tax code fits the item?
Which NAV tax code fits the item?
Six situations where the internal VAT code and NAV’s standard tax code typically diverge. The explanations are based on NAV’s specification and on public answers from NAV’s developers.
- The company receives a mobile phone invoice: net 10,000 HUF, VAT 2,700 HUF. Internally it has a dedicated “phone, 70% deductible” VAT code. What goes into the analytics?
- A separate NAV tax code for phone services — No. NAV’s catalogue has no dedicated phone code, because in the return a phone invoice goes to the same line as any other 27% domestic purchase.
- Correct: MD66, taxAmount 2,700, deductionRate 0.7, deductionAmount 1,890 — Correct. The 30% deduction restriction (VAT Act §124(3)) is not a tax code but deduction data: the item uses MD66 with the full VAT, and the deductible part is given by the deduction rate and deductible amount. The rate is then mandatory.
- MD66, taxAmount 1,890, no deduction data — No. taxAmount is the full VAT on the invoice. If only the deductible part were reported, the system would find the base-to-tax ratio inconsistent with the 27% rate.
- A parking invoice arrives; its VAT is non-deductible under VAT Act §124(2)(e). What is the correct treatment?
- MD66 with deduction rate 0 — No. The deduction rate must be greater than 0 and less than 1; a full prohibition is not reported this way.
- Correct: It may be reported with KL V00, or left out — Correct. According to NAV’s developers, an invoice subject only to a deduction prohibition can be left out of the analytics; if the taxpayer does include it, KL V00 must be used. The specification states that non-deductible items can be reported this way.
- OTHER position on MD66 — No. MD66 is a deductible code; with an OTHER position the system rejects it (STANDARDTAXCODE_OTHER_NOT_ALLOWED).
- The company buys a laptop domestically at 27% VAT and capitalises it as a tangible asset. The internal VAT code is “purchase 27%”. Which NAV code is correct?
- MD66 — Incomplete. MD66 is the main line for deductible VAT, but the return also shows tangible asset purchases on a separate detail line, so they have their own code.
- MD66 DD78 — No. DD78 marks assets acquired as a contribution in kind.
- Correct: MD66 DD77 — Correct. The DD77 element marks a tangible asset purchase. A generic “purchase 27%” code is therefore not enough: either a separate internal code is needed for assets, or the mapping has to take an additional attribute — such as the GL account — into account.
- A domestic reverse-charge purchase (VAT Act §142) at 27%, with full right of deduction. How does it appear in the analytics?
- Correct: MP29 MD66, with one payable and one deductible position — Correct. If a code can take both a payable and a deductible position, the line needs both positions. No more than two can be given.
- On two lines: MP29 payable and MD66 deductible — That is not the catalogue’s solution. There is a single combined code covering both return lines, describing the transaction as one item.
- MP29 only, with deduction in the next period — No. MP29 on its own denotes reverse charge without deduction; if the taxpayer exercises the right of deduction in the period, the combined code is the right one.
- An item with a tax point date of 20 September is submitted, and a new tax-code catalogue has been published in the meantime. What decides whether the code is valid?
- Correct: The item’s tax point date (taxpointDate) — Correct. INVALID_TAXCODE is raised if the code is not in the catalogue, or if the item’s tax point date falls outside the code’s validity period. The mapping table should therefore carry validity dates too.
- The submission date — No. NAV does not check code validity against the date of submission.
- The first day of the return period — No. Validity is checked item by item, based on the tax point date.
- In the web interface, 27% sales appear with the code “F07”. What goes into the XML submitted via M2M?
- F07 — No. F07 is the short (“descriptive”) code that only appears as a label in the web interface.
- The company’s own VAT code — No. The internal code can go into the ownTaxCode field, but it does not replace the standard tax code.
- Correct: MP07 — Correct. XML upload and the machine connection use the standard tax code. According to NAV’s developers, the short code is simply a shorter label mapped one-to-one to it.
How SimplyX supports this
In SimplyX, the VAT analytics can be loaded as an Excel file. The mapping of columns and internal VAT codes to NAV tax codes is stored as configuration, so it does not have to be redone every period. From this, 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. Accounting firms and groups can manage several companies in one system, with per-company permissions and separated data. How SimplyX eVAT M2M works
Related resources
Standard tax-code catalogue — a searchable database of all NAV standard tax codes
eVAT validation messages — every message with its conditions
eVAT M2M registration — technical user, keys and permissions
Next step
Once the mapping is defined, the filing side also needs the correct users and permissions. Part 5 explains how access is configured in companies and accounting firms. The XML structure and source data are covered in part 3.
Sources
NAV: eVAT M2M 2.0 interface specification, v1.1 (July 2026, in Hungarian)
NAV: standard tax-code catalogue (nav-gov-hu/eVAT)
NAV: standard tax-code elements and rules (Readme, in Hungarian)
NAV developers: line totals can be calculated from the items (#31)
NAV developers: a tax code’s meaning does not change (#35)
NAV developers: standard and short tax codes (issue #70)
NAV developers: map only the codes in use (issue #19)