eÁFA átállás és ÁNYK kivezetés 2027: útmutató Business Central és Navision rendszerekhez

Utoljára frissítve: 2026. július 6.

Az ÁNYK kivezetése miatt a magyar vállalatok áfabevallási folyamata 2027-től érdemben átalakul. Az áfabevallásnál a NAV kommunikációja szerint az eÁFA lesz az egyértelmű irány, nagyobb számlaforgalomnál pedig a gép-gép, vagyis M2M kapcsolat jelenti a fenntartható vállalati megoldást.

A Microsoft Dynamics 365 Business Central és a korábbi Navision / Dynamics NAV rendszerek esetében az átállás nem egyszerű nyomtatványcsere. Az eÁFA tranzakciószintű adatokat, standard adókódokat, validációkat, jogosultságkezelést és ERP-oldali adatminőséget igényel. Emiatt a felkészülést pénzügyi, számviteli és informatikai projektként egyszerre érdemes kezelni.

A Loginformnál ezt a témát nem pusztán technikai interfészként látjuk. Az eÁFA átállás lényege az, hogy a vállalat áfaanalitikája, könyvelési logikája és ERP-rendszere olyan állapotban legyen, hogy a NAV felé küldött adatok nemcsak beküldhetők, hanem szakmailag is védhetők legyenek.

Tartalomjegyzék

1. Mi változik az ÁNYK kivezetésével?
2. Mi az eÁFA és miért más, mint az ÁNYK?
3. Webes eÁFA vagy M2M: melyik való vállalatoknak?
4. Mit jelent az eÁFA átállás Business Central rendszerben?
5. Mit jelent az eÁFA átállás Navision / Dynamics NAV rendszerben?
6. Business Central vagy Navision: melyik eÁFA útvonalat válassza?
7. eÁFA átállási checklist
8. Gyakori hibák és kockázatok
9. Hogyan segít a Loginform az eÁFA átállásban?
10. GYIK
11. Kapcsolatfelvétel

1. Mi változik az ÁNYK kivezetésével?

Mi történik 2026. december 31. után?

Az Általános Nyomtatványkitöltő Keretprogram, vagyis az ÁNYK 2026. december 31-én leáll, a NAV pedig 2027. január 1-jétől új, adatalapú környezetet tesz kizárólagossá. Ez minden olyan vállalkozást érint, amely jelenleg ÁNYK-n keresztül ad be bevallásokat vagy adatszolgáltatásokat.

Az áfabevallás esetében a váltás különösen fontos, mert az eÁFA nem egyszerűen egy új beküldési felület. A NAV szerint az áfabevallásnál „egyértelmű a választás”: az eÁFA komplex digitális megoldás, amely a NAV-nál rendelkezésre álló adatok kiajánlására és validációkra épül.

Ez azt jelenti, hogy a 2026-os év nem haladék, hanem felkészülési időszak. Aki 2027-ben is biztonságosan akar áfabevallást beadni, annak még 2026-ban ellenőriznie kell az ERP-rendszerét, az áfakódjait, az analitikáját, a NAV-kapcsolatát és a belső jóváhagyási folyamatát.

Miért nem elég az eddigi ÁNYK-rutin?

Az ÁNYK-alapú működés nyomtatványlogikára épült, míg az eÁFA adatlogikára. A korábbi folyamatban sok vállalat a bevallási sorok végső kitöltésére koncentrált; az eÁFA-ban viszont a tételes adatok minősége, az adókódolás, az analitika és a validáció lesz a megfelelés alapja.

A NAV az eÁFA-rendszert azért vezette be, hogy az áfabevallás összeállítását és benyújtását elektronikus, adatalapú módon támogassa, csökkentve az adminisztrációt és erősítve a folyamatba épített hibakeresést. A rendszer lényege, hogy az adózók a releváns adóhatósági adatokat is felhasználhatják az áfaanalitika összeállításához és validálásához.

A gyakorlati különbség az, hogy 2027-től az áfabevallás nem a hónap végi „ÁNYK-exporttal” kezdődik. Már a számla rögzítésekor, az áfakód kiválasztásakor, a partneradatok karbantartásakor és a könyvelési logika kialakításakor eldől, hogy az eÁFA folyamat zökkenőmentes lesz-e.

2. Mi az eÁFA és miért más, mint az ÁNYK?

Mi az eÁFA?

Az eÁFA a NAV elektronikus áfarendszere, amely az áfabevallás összeállítását, ellenőrzését és benyújtását támogatja webes felületen vagy gép-gép kapcsolaton keresztül. A rendszer nemcsak beküldési csatorna, hanem validációs és adatfeldolgozási környezet is.

Az eÁFA egyik legnagyobb különbsége az ÁNYK-hoz képest, hogy az adóhatósági adatok — például online számlaadatok, online pénztárgépi adatok és vámhatározatok — közvetlenül felhasználhatók az áfabevallási folyamatban. A NAV emellett kiterjedtebb validációkat is alkalmaz, amelyek a beadás előtt jelezhetnek logikai vagy formai eltéréseket.

Ez különösen fontos azoknak a cégeknek, amelyek sok bejövő és kimenő számlát kezelnek, több telephelyen működnek, több ERP-integrációval dolgoznak, vagy speciális áfakezelést alkalmaznak.

Miért üzleti kockázat az eÁFA halogatása?

Az eÁFA átállás halogatása azért kockázatos, mert a probléma nem a beküldési határidő napján jelentkezik, hanem az adatok előkészítésében. Ha az ERP-ben hibásak a partnertörzsek, rendezetlenek az áfakódok vagy nincs egységes áfaanalitika, akkor az M2M kapcsolat technikailag működhet, de a bevallási folyamat mégis elakadhat.

A NAV 2026 májusában közzétette az eÁFA M2M adatstruktúra 2.0-s verziójához tartozó interfészspecifikációt, amely részletesebb adószakmai magyarázatokat tartalmaz. A 2.0-s verzió 2026 júliusától tesztkörnyezetben is elérhető, vagyis a fejlesztőknek és ERP-üzemeltetőknek már 2026-ban érdemes tesztelniük saját megoldásaikat.

A legbiztonságosabb megközelítés az, ha a vállalat nem 2026 végén kezd el fejlesztőt keresni, hanem még az év során elvégez egy ERP- és áfaanalitika-auditot, majd tesztidőszakban próbálja ki a folyamatot.

3. Webes eÁFA vagy M2M: melyik való vállalatoknak?

Mikor elég a webes eÁFA felület?

A webes eÁFA felület kisebb számlaforgalmú vállalatoknak lehet megfelelő, ahol az áfabevallás kézi ellenőrzése és jóváhagyása még kezelhető mennyiségű munkát jelent. A NAV tájékoztatása szerint a webes felület azoknak az adózóknak használható, akik egy bevallási időszakban összesen 100 ezernél kevesebb számlát kezelnek.

A webes felület előnye, hogy gyorsabb belépést adhat az eÁFA működésébe. Hátránya, hogy nagyobb adatmennyiség, több telephely, több üzleti ág vagy összetett áfakódolás esetén a kézi ellenőrzés és javítás hamar szűk keresztmetszetté válhat.

Közép- és nagyvállalatoknál ezért a webes felület gyakran csak átmeneti vagy ellenőrző megoldás. A hosszú távú cél inkább az, hogy az ERP-rendszer közvetlenül állítsa elő és kezelje az eÁFA M2M-hez szükséges adatokat.

Mikor szükséges az eÁFA M2M kapcsolat?

Az eÁFA M2M kapcsolat akkor szükséges vagy célszerű, ha a vállalat nagy számlamennyiséget kezel, automatizált ERP-folyamatokra épít, vagy minimalizálni akarja a kézi beavatkozásokat. A NAV szerint 100 ezer számla felett az eÁFA rendszer gép-gép kapcsolaton keresztül használható, de M2M ennél kisebb mennyiségnél is választható, ha ez előnyösebb a vállalatnak.

M2M esetén az ERP-rendszer és a NAV eÁFA-rendszere strukturált adatcserével kommunikál. A folyamat nemcsak a bevallás beküldéséről szól, hanem az adókódok, forrásadatok, áfaanalitika, validációk és jóváhagyási lépések kezeléséről is.

A NAV felkészülési útmutatója alapján M2M használatakor az ügyviteli rendszernek alkalmasnak kell lennie az eÁFA-M2M sajátosságainak kezelésére, technikai felhasználót kell létrehozni, jogosultságokat kell beállítani, valamint aláíró- és cserekulcsokat kell rögzíteni az alkalmazott programban.

Szempont	eÁFA webes felület	eÁFA M2M kapcsolat
Tipikus felhasználó	kisebb számlaforgalmú vállalat	közép- és nagyvállalat, cégcsoport, nagy számlaforgalom
Adatkezelés	több kézi ellenőrzés	ERP-alapú automatizáció
Skálázhatóság	korlátozottabb	nagy számlamennyiségre alkalmas
ERP-integráció	nem feltétlenül szükséges	elengedhetetlen
Fő előny	gyors belépés az eÁFA világába	kevesebb kézi munka, jobb kontroll, auditálható folyamat
Fő kockázat	manuális hibák, kapacitáshiány	fejlesztési és adatminőségi felkészülés szükséges

4. Mit jelent az eÁFA átállás Business Central rendszerben?

Hogyan készíthető fel a Business Central az eÁFA-ra?

Business Central rendszerben az eÁFA átállás kulcsa a magyar lokalizáció, az áfakódok helyes leképezése, az analitika tisztasága és a NAV M2M-kapcsolat technikai előkészítése. A modern Business Central környezet előnye, hogy a magyar jogszabályi és adózási működés a lokalizációs csomagokon keresztül kezelhető és frissíthető.

A Microsoft Dynamics 365 Business Central jelenleg támogatott termék, modern életciklus-politikával. A Microsoft szerint a Business Central támogatott státuszban van, az on-premises 2019 release wave 2 és későbbi verziók pedig a Modern Lifecycle Policy alá tartoznak, amely bugfixeket, új funkciókat és aktuális adófrissítéseket is biztosít, ha a rendszer naprakészen tartott.

Magyar környezetben a Business Central működésének egyik fontos eleme a magyar lokalizáció. A HRP-Extended-Localization a Microsoft Marketplace leírása szerint a magyar Business Centralhoz készült kiterjesztett lokalizáció, amely a magyar számviteli és adójogi megfelelés támogatását szolgálja.

Mi a HRP lokalizáció szerepe az eÁFA átállásban?

A HRP magyar lokalizáció szerepe az, hogy a Business Central a magyar számviteli, adózási és adminisztratív sajátosságokhoz illeszkedjen. Ez az eÁFA átállásnál azért fontos, mert a NAV felé küldött adatok mögött nem elég technikai XML-t előállítani: az ERP-ben lévő adózási logikának is helyesnek kell lennie.

A HRP dokumentációs oldala több magyar lokalizációs területet is felsorol, például áfa analitika riportot, áfa árfolyamkezelést, áfa dátumkezelést, NAV számlaletöltő modult és online számla funkciókat. Ezek jól mutatják, hogy a magyar Business Central működésben az áfa- és NAV-kapcsolatok nem utólagos kiegészítések, hanem a lokalizáció központi részei.

A gyakorlati feladat projektindításkor az, hogy meg kell vizsgálni: az adott Business Central verzió, az aktuális HRP lokalizáció, az egyedi fejlesztések és a vállalat áfakód-struktúrája együtt alkalmasak-e az eÁFA M2M működésre. Ezt nem érdemes pusztán verziószám alapján eldönteni; szükség van adat- és folyamatoldali auditálásra is.

Mit kell ellenőrizni Business Centralban?

Business Centralban az eÁFA átállás előtt elsősorban az áfakódokat, könyvelési csoportokat, partneradatokat, számlaadatokat, egyedi fejlesztéseket és NAV-kapcsolatokat kell ellenőrizni. A cél az, hogy a rendszer ne csak könyvelési szempontból működjön, hanem eÁFA-adatszerkezeti szempontból is megfeleljen.

A legfontosabb ellenőrzési pontok:

1. Áfakódok és adókönyvelési beállítások: megfeleltethetők-e a NAV standard adókódlogikájának.
2. Partnertörzs: adószámok, csoportos adószámok, közösségi adószámok, országkódok és címadatok pontossága.
3. Számlaadatok: a bejövő és kimenő számlákban szereplő áfaadatok konzisztenciája.
4. Egyedi fejlesztések: módosítanak-e olyan mezőket vagy folyamatokat, amelyek az áfaanalitikát érintik.
5. Jóváhagyási folyamat: ki ellenőrzi, ki javítja és ki hagyja jóvá az eÁFA-bevallást.
6. Tesztelés: működik-e a folyamat tesztkörnyezetben, valós adatokhoz hasonló mintán.

A Loginform megközelítése szerint a Business Central eÁFA projekt akkor sikeres, ha a pénzügyi csapat nem „informatikai fejlesztést” kap, hanem olyan működési folyamatot, amely a havi zárásban is használható.

5. Mit jelent az eÁFA átállás Navision / Dynamics NAV rendszerben?

Miért külön téma a Navision eÁFA átállás?

A Navision, illetve Dynamics NAV rendszerek eÁFA átállása azért külön téma, mert ezek a rendszerek sok vállalatnál stabilan működnek, de életciklusuk és technológiájuk eltér a modern Business Centraltól. Emiatt az eÁFA M2M megfelelés jellemzően nem egyszerű frissítés, hanem célzott fejlesztési és integrációs feladat.

A Microsoft hivatalos életciklusadatai szerint a Dynamics NAV 2016 kiterjesztett támogatása 2026. április 14-én véget ért, a Dynamics NAV 2017 kiterjesztett támogatása 2027. január 11-én, a Dynamics NAV 2018-é pedig 2028. január 11-én jár le.

A kiterjesztett támogatás önmagában sem jelent teljes funkcionalitásfejlesztést. A Microsoft Fixed Lifecycle Policy szerint Extended Support alatt a dizájnmódosítások és új funkciókérések nem érhetők el, a nem biztonsági frissítések pedig nem támogatottak.

Ezért a NAV 2016–2018 környezetben az eÁFA átállást külön kell megtervezni: vagy Business Central migrációval, vagy a meglévő NAV rendszer célzott eÁFA M2M felkészítésével.

Mikor érdemes megtartani a meglévő Navision rendszert?

A meglévő Navision rendszer megtartása akkor lehet racionális döntés, ha az ERP stabilan működik, az üzleti folyamatok erősen testreszabottak, és a teljes Business Central migráció 2026 végéig túl nagy kockázatot vagy költséget jelentene. Ilyenkor az eÁFA megfelelés célzott modul- vagy interfészfejlesztéssel is kezelhető lehet.

Ez különösen azoknál a vállalatoknál reális forgatókönyv, ahol:

• sok egyedi NAV-fejlesztés működik;
• a felhasználók jól ismerik a jelenlegi rendszert;
• a vállalatnál rövid távon nem fér bele teljes ERP-migráció;
• az eÁFA megfelelés sürgősebb, mint a stratégiai rendszerváltás;
• a NAV rendszerből megbízhatóan kinyerhető az áfaanalitika.

Ilyen esetekben a cél nem az, hogy a régi rendszert örökre konzerváljuk. A cél az, hogy a vállalat 2027-ben is biztonságosan teljesítse az áfabevallási kötelezettségét, miközben nyer időt egy későbbi, jól előkészített Business Central átállásra.

Hogyan segíthet egy saját fejlesztésű Navision eÁFA modul?

Egy saját fejlesztésű Navision eÁFA modul feladata az, hogy a meglévő Dynamics NAV rendszerből előállítsa, ellenőrizze és továbbítsa az eÁFA M2M működéshez szükséges adatokat. Ez akkor értékes, ha a vállalat nem akar teljes ERP-cserét végrehajtani csak az eÁFA miatt, de a megfelelőséget nem szeretné kézi kerülőutakkal megoldani.

A modulnak vagy célzott fejlesztésnek ideális esetben az alábbi területeket kell kezelnie:

Terület	Elvárt működés Navision környezetben
Adatkivonat	áfaanalitika, számlaadatok, könyvelési tételek kinyerése
Adókód-leképezés	NAV standard adókódokhoz illeszthető belső áfakód-struktúra
Validáció	hiányos partneradatok, hibás adószámok, áfaeltérések jelzése
M2M kapcsolat	technikai felhasználóval és kulcsokkal működő NAV kommunikáció
Naplózás	beküldések, hibák, javítások és jóváhagyások visszakövethetősége
Üzemeltetés	frissítések, specifikációváltozások és tesztelés kezelése

A publikálás előtt érdemes pontosan véglegesíteni, hogy a Loginform saját Navision eÁFA megoldása mely NAV-verziókat, milyen adatstruktúrákat és milyen M2M műveleteket támogat. Marketingoldalon a legerősebb, de szakmailag is biztonságos ígéret így hangzik: „Felmérjük a meglévő Navision rendszerét, és célzott eÁFA M2M megoldással készítjük fel a 2027-es működésre.”

6. Business Central vagy Navision: melyik eÁFA útvonalat válassza?

Mi a döntési logika?

A megfelelő eÁFA útvonalat nem a rendszer neve, hanem a vállalat működése, számlaforgalma, adatminősége, fejlesztési múltja és 2027-es kockázata alapján érdemes kiválasztani. Ugyanaz az eÁFA-követelmény más megoldást igényelhet egy friss Business Central rendszerben és egy 10 éve testreszabott Navision környezetben.

ERP-helyzet	Javasolt eÁFA irány	Mikor ideális?
Modern Business Central, aktuális magyar lokalizációval	HRP lokalizáció + eÁFA M2M konfiguráció és tesztelés	ha a rendszer verziója és lokalizációja naprakész
Business Central sok egyedi fejlesztéssel	lokalizációs ellenőrzés + egyedi fejlesztések eÁFA auditja	ha az egyedi logika érinti az áfaanalitikát
Dynamics NAV 2016	sürgős audit + célzott eÁFA modul vagy migrációs döntés	mert a kiterjesztett támogatás már lejárt
Dynamics NAV 2017	gyors döntés: célzott modul vagy Business Central migráció	mert a támogatás 2027 januárjában lejár
Dynamics NAV 2018	eÁFA felkészítés + középtávú migrációs terv	mert még van idő, de a technológiai út záródik
Navision 2009 / régebbi NAV	egyedi felmérés, magasabb technikai kockázattal	mert a támogatási és integrációs kockázat jelentős

A Loginform javaslata: először ne szoftvert válasszon, hanem kockázati képet készítsen. Egy jól vezetett eÁFA audit megmutatja, hogy a vállalatnak konfigurációra, fejlesztésre, modulra, migrációra vagy ezek kombinációjára van szüksége.

7. eÁFA átállási checklist

Milyen lépésekből álljon az eÁFA felkészülés?

Az eÁFA átállás legbiztonságosabb útja egy hatlépéses felkészülési folyamat: helyzetfelmérés, adatminőség-javítás, áfakód-leképezés, technikai M2M előkészítés, tesztelés és élesítési terv. Így a vállalat nem az első 2027-es bevallásnál találkozik a hibákkal.

1. ERP- és verzióaudit

Első lépésként rögzíteni kell, hogy a vállalat pontosan milyen ERP-verziót használ, milyen magyar lokalizációval, milyen egyedi fejlesztésekkel és milyen külső integrációkkal. Business Centralnál az aktuális verzió és lokalizáció a döntő, Navisionnél pedig a támogatási állapot és az egyedi fejlesztések kockázata.

Ellenőrző kérdések:

• Business Central vagy Dynamics NAV / Navision fut?
• Melyik verzió?
• Felhős vagy on-premises környezet?
• Milyen lokalizációs csomag van telepítve?
• Vannak-e áfát érintő egyedi fejlesztések?
• Mely külső rendszerek adnak át számlázási vagy könyvelési adatot?

2. Áfakódok és könyvelési csoportok tisztítása

Az eÁFA M2M egyik kritikus pontja az adókódlogika. A NAV szerint az adókódlista az adókötelezettség megállapításának logikáját követi, és az adatok az adókódok alapján kerülnek a bevallás egyes soraiba.

Ezért a vállalat belső áfakódjait össze kell vetni a NAV standard adókódjaival. Külön figyelmet igényelnek a fordított adózású ügyletek, részleges levonások, külföldi számlák, tárgyi eszközök, előlegek, korrekciók és speciális iparági folyamatok.

3. Partnertörzs és számlaadatok ellenőrzése

A partneradatok minősége közvetlenül befolyásolja az eÁFA validáció sikerét. Hibás adószám, hiányos cím, rossz országkód vagy következetlen közösségi adószám esetén a technikai beküldés ugyan elindulhat, de a validáció és az egyeztetés hibákat jelezhet.

Tipikus tisztítandó mezők:

• magyar adószám;
• csoportos adószám;
• közösségi adószám;
• partner neve és címe;
• országkód;
• fizetési és teljesítési dátumok;
• számlatípusok;
• korrekciós bizonylatok kapcsolatai.

4. M2M jogosultságok és technikai felhasználó beállítása

M2M használathoz technikai felhasználóra, megfelelő jogosultságokra, aláírókulcsra és cserekulcsra van szükség. A NAV felkészülési útmutatója szerint a technikai felhasználót az Online Számla rendszerben kell létrehozni vagy megfelelő jogosultsággal ellátni, és a kulcsokat az alkalmazott programban kell rögzíteni.

Ez nem csak informatikai feladat. A pénzügynek, az IT-nak és az ERP-partnernek közösen kell eldöntenie, ki milyen jogosultsággal dolgozik, ki fér hozzá a teszt- és éles környezethez, és hogyan történik a beküldések jóváhagyása.

5. Tesztelés valós üzleti mintákkal

Az eÁFA tesztelést nem elég egy egyszerű, hibátlan számlával kipróbálni. A valós működésben éppen a speciális esetek okozzák a problémát: előlegek, jóváírások, fordított adózás, részleges levonás, devizás ügyletek, import, csoportos adóalanyiság vagy kézi könyvelési tételek.

A tesztelési mintának tartalmaznia kell:

• normál belföldi értékesítést;
• belföldi beszerzést;
• fordított adózású ügyletet;
• devizás számlát;
• előleget;
• jóváíró számlát;
• tárgyieszköz-beszerzést;
• kézi vegyes könyvelést;
• speciális iparági ügyletet.

6. Élesítési és üzemeltetési terv

Az eÁFA átállás nem zárul le az első sikeres beküldéssel. A vállalatnak üzemeltetési tervre van szüksége: ki figyeli a NAV-specifikáció változásait, ki kezeli a hibákat, hogyan történik a havi zárás, és milyen gyorsan lehet reagálni, ha a validáció elakad.

Az eÁFA M2M 2.0-s specifikáció megjelenése is azt mutatja, hogy a rendszer fejlődik, az ERP-oldali megoldásokat pedig karban kell tartani.

8. Gyakori hibák és kockázatok

Mi a legnagyobb eÁFA kockázat?

A legnagyobb eÁFA kockázat nem a technikai kapcsolat, hanem az, ha a vállalat hibás vagy hiányos adatokból próbál automatizált bevallást készíteni. Az M2M kapcsolat csak azt tudja továbbítani és validálni, amit az ERP-rendszer előállít.

Gyakori hibák:

• túl sok, egymással átfedő belső áfakód;
• nem dokumentált egyedi fejlesztések;
• kézi Excel-korrekciók a havi zárásban;
• hiányos partnertörzs;
• nem egyeztetett NAV Online Számla és ERP-adat;
• nem egyértelmű felelősségi körök pénzügy és IT között;
• tesztelés hiánya speciális ügyletekkel.

A jó eÁFA projekt ezért nem azzal kezdődik, hogy „kössük rá a rendszert a NAV-ra”, hanem azzal, hogy „nézzük meg, az ERP-ben lévő áfaanalitika alkalmas-e a NAV előtti validációra”.

Miért nem szabad csak IT-projektként kezelni?

Az eÁFA átállás azért nem tisztán IT-projekt, mert a NAV felé küldött adatok értelmezése számviteli és adózási kérdés. Az informatikai csapat meg tudja építeni az interfészt, de az áfakódok, könyvelési logika, levonási szabályok és korrekciók helyességét pénzügyi-számviteli oldalról kell validálni.

A sikeres projektben három szereplő dolgozik együtt:

1. Pénzügy / számvitel: meghatározza a szakmai logikát.
2. IT / ERP-üzemeltetés: biztosítja a rendszer- és jogosultsági hátteret.
3. Business Central / Navision partner: összeköti a szakmai igényt a rendszertechnikai megvalósítással.

A Loginform erőssége éppen itt jelenik meg: nemcsak Business Central és Navision rendszert értünk, hanem azt is, hogy a számok mögött milyen pénzügyi és számviteli logika áll.

9. Hogyan segít a Loginform az eÁFA átállásban?

Miben más a Loginform megközelítése?

A Loginform az eÁFA átállást ERP-, pénzügyi és számviteli projektként kezeli, nem pusztán interfészfejlesztésként. Ez azért fontos, mert a NAV M2M kapcsolat önmagában nem oldja meg az adatminőségi, áfakódolási és folyamatbeli problémákat.

A Business Central és Navision rendszereknél a Loginform három szinten tud segíteni:

1. Felmérés és audit: ERP-verzió, lokalizáció, áfakódok, egyedi fejlesztések, adatminőség.
2. Megoldástervezés: HRP lokalizációs útvonal, egyedi fejlesztés, Navision modul, M2M kapcsolat.
3. Bevezetés és támogatás: tesztelés, hibajavítás, élesítés, havi zárási támogatás.

A cél nem az, hogy a vállalat „valahogy beküldje” a bevallást. A cél az, hogy a pénzügyi vezető, a főkönyvelő és az IT-vezető is lássa: a folyamat ellenőrzött, dokumentált és fenntartható.

Kinek érdemes most konzultációt kérnie?

Most azoknak a vállalatoknak érdemes eÁFA konzultációt kérniük, amelyek Business Central vagy Navision rendszerben kezelik az áfabevalláshoz szükséges adatokat, és 2027-ben nem akarnak kapkodva átállni. Minél több az egyedi folyamat, annál korábban kell kezdeni.

Különösen indokolt az előzetes felmérés, ha:

• Dynamics NAV 2016, 2017 vagy 2018 rendszert használnak;
• Navision 2009 vagy régebbi rendszer fut;
• Business Centralban sok egyedi fejlesztés van;
• több rendszerből érkeznek számlaadatok;
• a havi áfabevallás Excel-korrekciókra épül;
• sok a fordított adózású vagy devizás ügylet;
• a pénzügy és IT között nincs dokumentált eÁFA felelősségi mátrix.

10. GYIK

Kötelező lesz az eÁFA 2027-től?

Az ÁNYK 2026. december 31-i leállása miatt az áfabevallásnál 2027-től az eÁFA kerül előtérbe. A NAV kommunikációja szerint az áfabevallásnál az eÁFA az egyértelmű választás, mert az ÁNYK helyett adatalapú működésre áll át a rendszer.

Mi a különbség az eÁFA webes felület és az eÁFA M2M között?

Az eÁFA webes felület inkább kisebb számlaforgalmú cégeknek alkalmas, míg az M2M kapcsolat ERP-ből történő, automatizált adatcserét jelent. A NAV tájékoztatása szerint 100 ezer számla felett a rendszer gép-gép kapcsolaton keresztül használható, de M2M kisebb mennyiségnél is választható.

Business Central rendszerben elég a HRP lokalizáció?

Business Central rendszerben a magyar lokalizáció alapvető kiindulópont, de önmagában nem helyettesíti az eÁFA projektfelmérést. Ellenőrizni kell az aktuális Business Central verziót, a HRP lokalizáció verzióját, az áfakódokat, az egyedi fejlesztéseket és az M2M működéshez szükséges technikai beállításokat.

Navision rendszerrel is megoldható az eÁFA átállás?

Igen, de egyedi felmérést igényel. Régebbi Dynamics NAV / Navision rendszereknél meg kell vizsgálni a verziót, a támogatási állapotot, az egyedi fejlesztéseket és az áfaanalitika kinyerhetőségét. Sok esetben célzott eÁFA modul vagy interfészfejlesztés lehet a rövid távú megoldás.

Kell teljes ERP-csere az eÁFA miatt?

Nem minden esetben kell teljes ERP-csere. Business Centralban jellemzően lokalizációs és konfigurációs felkészítés, Navisionben pedig célzott fejlesztés vagy modul is elegendő lehet. Ugyanakkor régi, erősen testreszabott vagy támogatáson kívüli rendszereknél a Business Central migráció középtávon stratégiailag indokolt lehet.

Mikor érdemes elkezdeni az eÁFA felkészülést?

Az eÁFA felkészülést 2026-ban érdemes elkezdeni, mert az ÁNYK 2026. december 31-én leáll. A vállalatoknak időre van szükségük az ERP-auditra, adattisztításra, áfakód-leképezésre, M2M beállításra, tesztelésre és az éles működés stabilizálására.

11. Készüljön fel időben az eÁFA átállásra

Az eÁFA átállás nemcsak jogszabályi megfelelési feladat, hanem lehetőség is: kevesebb kézi munka, tisztább áfaanalitika, jobb adatminőség és átláthatóbb pénzügyi folyamatok építhetők ki.

A Loginform segít felmérni, hogy Business Central vagy Navision rendszere milyen állapotban van az eÁFA átállás szempontjából, és milyen megoldással készíthető fel biztonságosan a 2027-es működésre.

Kérdése van a Business Central vagy Navision eÁFA felkészítésével kapcsolatban?

Vegye fel a kapcsolatot szakértőinkkel, és nézzük meg együtt, milyen lépésekre van szükség az Ön rendszerében.