A titkár.ai számlázó program felhasználói dokumentációja

Hatályos: 2026. augusztus 18.·Verzió: 1.8

Letöltés és megőrzés (.md)

Számlázó program: „titkár.ai” (https://titkar.ai) Fejlesztő és üzemeltető: BITNEX GROUP Kft. Hatályos: 2026. augusztus 18. · Verzió: 1.8

Jelen dokumentum a számla és a nyugta adóigazgatási azonosításáról, valamint az elektronikus formában megőrzött számlák adóhatósági ellenőrzéséről szóló 23/2014. (VI. 30.) NGM rendelet 10. §-a szerinti magyar nyelvű felhasználói dokumentáció a titkar.ai számlázó programhoz.

A rendelet 10. §-a a számlázó program fejlesztőjétől megköveteli, hogy a programhoz magyar nyelvű felhasználói dokumentációt biztosítson, amely a program működését és használatát írja le; a dokumentációt az adózónak – tehát neked, a program használójának – adóhatósági ellenőrzéskor be kell tudnia mutatnia. A dokumentum ezért nem marketinganyag: minden állítása a program tényleges működését írja le, és ahol a program valamit nem tud, azt kimondottan, alternatívával együtt jelöli.

A dokumentum a titkar.ai saját, NAV-közvetlen számlázására vonatkozik: arra a működésre, amelyben a számlát maga a titkar.ai állítja ki, és közvetlenül a NAV Online Számla rendszerébe szolgáltat adatot. A 2026. augusztus 8. előtt, külső számlázó programon (szamlazz.hu, Billingo) keresztül kiállított számlákra ez a dokumentum nem alkalmazandó – az elhatárolást az 1. fejezet tartalmazza.

A dokumentum végén „Tisztázandó tételek az élesítés előtt” címmel munkajellegű szakasz áll: ez a program jelenlegi állapotából fakadó, még eldöntendő kérdéseket gyűjti egy helyre. A tételek a saját fejezetükben is szerepelnek, [TISZTÁZANDÓ · T-nn] jelöléssel — a v1.7-es kiadással minden tétel lezárult, a 29. fejezet a lezárások nyilvántartásaként marad meg.

1. Jogalap és a dokumentum hatálya

1.1 Miért készült ez a dokumentum

A számla- és nyugtaadási kötelezettség kapcsán a 23/2014. (VI. 30.) NGM rendelet 10. §-a előírja, hogy a számlázó programhoz a fejlesztőnek magyar nyelvű felhasználói dokumentációt kell biztosítania, amely a program működését és használatát írja le. A dokumentációt az adózónak (neked, mint a program használójának) ellenőrzéskor be kell tudnia mutatni.

Ez a dokumentum ezt a kötelezettséget teljesíti a titkar.ai számlázó programra.

Ez a dokumentum egyben a 10. § (1) bekezdése szerinti tájékoztatás a program nevéről és azonosítójáról is; a pontos adatokat a 2. fejezet tartalmazza. A dokumentum eredetileg is magyar nyelven készült, ezért a 10. § (6)–(7) bekezdése szerinti fordítási kötelezettség nem merül fel; a Szolgáltató belföldön nyilvántartásba vett adóalanyként gondoskodik arról, hogy folyamatosan rendelkezésre álljon.

A te kötelezettséged. A 10. § (4) szerint a dokumentációt az adó megállapításához való jog elévüléséig meg kell őrizned, és adóhatósági ellenőrzéskor be kell mutatnod; a megőrzés elektronikus úton is teljesíthető. Ezért töltsd le ezt a dokumentumot abban a verzióban, amely a számláid kiállításának napján hatályos volt, és őrizd meg a bizonylataid mellett (27.5).

A dokumentum verziózott letöltési pontja: https://titkar.ai/szamlazo-dokumentacio/letoltes (a hatályos változat; korábbi kiadás a ?verzio= paraméterrel, pl. ?verzio=1.6 — lásd 27.5). A tudomásulvétel tényét a program a regisztrációkor időbélyeggel és a dokumentum akkori verziószámával rögzíti a fiókhoz.

1.2 Mire terjed ki

A dokumentum arra az útra vonatkozik, amelyen a számlát maga a titkar.ai állítja ki, és közvetlenül a NAV Online Számla rendszerébe szolgáltat adatot – külső számlázó program közbeiktatása nélkül. A rendszer ezt az utat belül saját számlázásnak (invoiceProvider = nav) nevezi; a felületen „titkár.ai · saját számlázás” néven jelenik meg.

Ebben a dokumentumban végig a „saját (NAV-közvetlen) út” – röviden „saját út” – megnevezést használjuk erre. A 2026. augusztus 8. előtti, szamlazz.hu-n vagy Billingón keresztüli működésre a „korábbi, külső számlázós bizonylatok” megnevezést használjuk.

1.3 Mire NEM terjed ki – a korábbi, külső számlázós bizonylatok

2026. augusztus 8. előtt a titkar.ai a számlát a felhasználó saját, külső számlázó-fiókján (szamlazz.hu, Billingo) keresztül is ki tudta állítani. Ez a lehetőség megszűnt; a program azóta kizárólag saját, NAV-közvetlen úton állít ki bizonylatot.

Ha a számlád a szamlazz.hu-n vagy a Billingón keresztül készült, akkor jogilag az a program a számlázó program, és a 10. § szerinti dokumentáció is annak a fejlesztőjét terheli. Az ő dokumentációjukat kell bemutatnod azokra a számlákra. Ez a dokumentum azokra nem érvényes.

1.4 A hatály bizonylatonként dől el

Minden számlasoron eltároljuk, hogy melyik úton keletkezett – és a későbbi műveletek (PDF, sztornó, fizetés jelölése, NAV-státusz lekérdezése, valamint a 11/A. § szerinti adóhatósági ellenőrzési adatszolgáltatás) ezt nézik.

Ennek a gyakorlati következménye: a korábbi, külső számlázón át kiállított számláid visszamenőleg nem kerülnek ennek a dokumentumnak a hatálya alá, és a sztornójuk is abban a rendszerben (vagy a NAV Online Számla felületén) intézhető, amelyben keletkeztek – a titkar.ai ezeket nyilvántartja és megjeleníti, de nem érvényteleníti és számlaképet sem állít elő hozzájuk.

A dokumentum időbeli hatálya: 2026. augusztus 8. — a saját (NAV-közvetlen) számlázási út élesedésének, egyben a külső számlázós utak megszűnésének napja. E naptól minden, a titkar.ai-ban kiállított számlára ez a dokumentum az irányadó; a korábbi, külső számlázón kiállított bizonylatokra az akkori szolgáltató programja a számlázó program (1.3).

1.5 Egy dolog akkor is a titkar.ai-tól megy, ha nem ő állítja ki a számlát

A titkar.ai a NAV felé küldött minden kérésben megnevezi magát a 2. fejezet szerinti szoftver-azonosító blokkal – akkor is, ha az adott számlát nem ő bocsátotta ki. Ez a helyzet a számlatörténet-behúzásnál, az adószám-ellenőrzésnél, a számlaadat-lekérdezésnél és az eÁFA (M2M) kéréseknél. Ezek lekérdezések és bevallás-műveletek, nem számlakibocsátás: attól, hogy a NAV-naplóban ott a titkar.ai név, a külső számlázón kiállított számla kibocsátója változatlanul a külső számlázó marad.

1.6 Az adóhatósági ellenőrzési adatszolgáltatás hatálya

A rendelet 11/A. §-a szerinti adóhatósági ellenőrzési adatszolgáltatást a program csak azokra a számlákra adja ki, amelyeket ez a program bocsátott ki: kizárólag a saját úton, az alkalmazáson keresztül kiállított számlákra. Kimarad belőle a külső számlázón kiállított, a NAV-ból utólag importált számla és a díjbekérő. Ez nem hiányosság, hanem a hatály pontos követése – a részleteket, az indoklást és a beszerzés helyét a 17.3 pont tartalmazza.

1.7 Minden fiókra ez vonatkozik

2026. augusztus 8. óta a saját, NAV-közvetlen kiállítás az egyetlen út: nincs fiókonként eltérő számlázási beállítás, és nincs mit választani. A felületen a kiállítás „titkár.ai · saját számlázás” néven jelenik meg.

2. A szoftver neve és azonosítója

A 23/2014. (VI. 30.) NGM rendelet 10. § (1) bekezdése szerint a felhasználót tájékoztatni kell a program nevéről és azonosítójáról — ezt e fejezet teljesíti. A fejlesztő adatait és elérhetőségét a rendelet nem írja elő kötelező tartalomként; ezeket a dokumentum az átláthatóság kedvéért, önként közli. Az alábbi adatok szó szerint azok, amelyeket a program minden NAV-kérés software blokkjában elküld.

2.1 A NAV-nak beküldött szoftver-azonosító adatok

Ezek az értékek a program forráskódjában egyetlen, központi helyen vannak rögzítve, és minden NAV-kérésbe azonos formában kerülnek bele. A pontos kimenetet automatikus teszt őrzi: ha bármelyik érték megváltozna, a változtatás nem tud észrevétlenül élesedni.

A softwareDevTaxNumber a 8 jegyű törzsszám, nem a teljes, 11 jegyű adószám – a NAV interfésze így kéri. Ugyanez vonatkozik a saját adószámodra is: a felületen a teljes adószámot adod meg, a NAV-nak az első 8 számjegy megy.

A softwareId és a softwareName szándékosan nem egyezik. Az azonosító egy korábbi terméknév-tagot hordoz (…SZAMLAI001), a név viszont titkar.ai. Ez nem elírás: az azonosító a NAV-nál nyilvántartott előzmény miatt marad változatlan. Ez a páros a NAV felé következetesen ugyanígy megy ki; ellenőrzéskor mindkettőt ezen a néven kell keresni.

A program neve a rendelet 10. § (1) bekezdése értelmében: titkar.ai – ékezet nélkül, pontosan úgy, ahogy a NAV-adatszolgáltatás softwareName mezőjében szerepel. A felületen és a kommunikációban használt „titkár.ai” írásmód ugyanennek a terméknek a megjelenítési alakja, nem külön program. Ellenőrzéskor a titkar.ai alakot kell keresni.

2.2 A fejlesztő és üzemeltető adatai (10. § (1))

Cégnév: BITNEX GROUP Korlátolt Felelősségű Társaság (BITNEX GROUP Kft.) Székhely: 4400 Nyíregyháza, Dózsa György utca 9. 3. emelet Cégjegyzékszám: 15-09-069325 (Nyíregyházi Törvényszék Cégbírósága) Adószám: 13311908-2-15 Közösségi (EU) adószám: HU13311908 Képviselő: Nánási Tamás Sándor E-mail: info@titkar.ai Weboldal / szolgáltatás: https://titkar.ai

A fejlesztő és a szolgáltatás üzemeltetője ugyanaz a társaság – nincs külön forgalmazó. A támogatási és jogorvoslati csatornákat a 28. fejezet tartalmazza.

2.3 Melyik NAV-rendszerrel kommunikál a program

Éles használatban a környezet fixen az Éles – a Teszt/Éles kapcsoló kizárólag a fejlesztői buildben jelenik meg, a nyilvános szolgáltatásban nem választható (lásd 6.5). Az adatszolgáltatás tehát nem tud véletlenül a NAV homokozójába menni.

Az interfész az Online Számla 3.0: requestVersion 3.0, headerVersion 1.0, névtér http://schemas.nav.gov.hu/OSA/3.0/api.

2.4 Verziószám – a verziópolitika

A NAV felé jelentett softwareMainVersion e dokumentum verziószámát követi (jelenleg 1.7), egyetlen közös forrásból: a kettő EGYÜTT lép, amikor a program dokumentált viselkedése érdemben változik. A szabály részleteit a 27.3 pont tartalmazza.

3. A működési modell: online szolgáltatás (SaaS)

3.1 Mit jelent az ONLINE_SERVICE üzemmód

A program a NAV felé softwareOperation = ONLINE_SERVICE üzemmódot deklarál, és ez a valóságot írja le: a titkar.ai kizárólag online szolgáltatásként (SaaS) érhető el. Nincs letölthető, telepíthető változat, nincs helyi (on-premise) telepítés, és nincs olyan mód, amelyben a program a te gépeden vagy a saját szervereden futna.

Neked böngésző és internetkapcsolat kell – semmi más. Telepítés, verziófrissítés, szerverüzemeltetés és adatbázis-karbantartás nem terhel: a frissítéseket és az adatbázis- migrációkat az üzemeltető futtatja, a szolgáltatás folyamatos működése mellett.

3.2 Hol fut és hol tárolódik az adat

A NAV technikai felhasználód jelszava, XML aláírókulcsa és XML cserekulcsa – csakúgy, mint a külső számlázók kulcsai – mindig titkosítva (AES-256-GCM) tárolódnak az adatbázisban, és a kiszolgálót nem hagyják el: a felületre, a kérésekbe és a beépített AI-asszisztensnek sem kerülnek be. A visszafejtés kizárólag szerveroldalon, a NAV felé menő kérés összeállításakor történik (részletesen: 6.6 és 24.3).

3.3 A felület

A titkar.ai kezelőfelülete egyetlen, folytonos chat: a bizonylatokat természetes nyelven kéred, és a rendszer kártyákon (előnézet, megerősítés, lista, PDF) válaszol. A beállítások nem külön oldalon, hanem a fiók-menüből nyíló ablakban élnek. A felület magyar és angol nyelven használható.

3.4 Háttérfolyamatok

A saját számlázást két ütemezett folyamat szolgálja ki:

3.5 A kiállítás és az adatszolgáltatás két külön lépés – ezt tudnod kell

A számla nálunk, a lezáráskor jön létre, egyetlen adatbázis-tranzakcióban. A NAV felé menő adatszolgáltatás viszont nem része ennek a tranzakciónak: a beküldés a számla létrejötte után indul, és ha a NAV éppen nem elérhető, az ütemezett folyamat viszi tovább.

Ennek két következménye van, és mindkettő rád tartozik:

1. A NAV kiesése nem akadályozza a számlázást. Ki tudsz állítani számlát akkor is, ha a NAV rendszere nem elérhető. (Egy kivétel van: a legelső kiállítás előtt a kiállítói törzsadatot a NAV-tól kell megszerezni – lásd 16.6.)
2. A kiállítás sikeréből nem következik, hogy az adatszolgáltatás is megtörtént. Ezt külön kell ellenőrizned. A rendszer erre eszközt ad (16.8), és a beépített asszisztens is így válaszol. A jogszabály szerinti határidő kezelését a 18. fejezet írja le.

3.6 Korlátok

• Nincs offline működés. Internetkapcsolat nélkül a program nem használható.
• Nincs „saját szerverre” telepíthető változat, és nincs olyan funkció, amely a teljes adatbázisodat átadná egy másik rendszernek. Az adatkiadás a program által biztosított exportokon keresztül történik (adóhatósági ellenőrzési adatszolgáltatás, PDF, könyvelői csomag – lásd 25.3).
• A Szolgáltató rendelkezésre állási (SLA) vállalást nem tesz, és telefonos ügyfélszolgálat nincs. A támogatás csatornáit és a nevesített határidőket a 28.2 pont tartalmazza.

4. A kezelt bizonylattípusok

4.1 Amit a saját út kiállít

Számla. A sorszám a saját, elkülönített tartományból megy, kihagyás és ismétlés nélkül (23/2014. NGM 8. § (1) a)). A kiállítással együtt elkészül a NAV-nak szóló adatszolgáltatás (CREATE művelet), és a rendszer a bizonylatot a számlaláncba is beköti.

Díjbekérő. A díjbekérő nem számla: nem megy a NAV-hoz, nincs hozzá számlalánc, és nem készül hozzá árfolyam-lekérdezés sem. A sorszáma fixen DIJB előtaggal megy – ez elkülönített, nem-számla tartomány, és a felhasználó nem tudja átállítani. Részletesen: 10. fejezet.

Sztornó okirat. A sztornó önálló bizonylat, saját sorszámmal, a számlákkal azonos tartományból – nem az eredeti számla „törlése”. Az eredeti számla állapota sztornózott-ra vált, a sztornó okirat pedig negatív végösszegekkel, a NAV felé STORNO műveletként megy ki (13. fejezet).

Díjbekérőből végszámla. Ez az út a saját számlázáson működik: a rendszer a mentett tételekből és vevőadatokból állítja össze a végszámlát, és belsőleg rögzíti, melyik díjbekérőhöz tartozik. A díjbekérő száma a végszámla számlaképére és a NAV-adatszolgáltatásba nem kerül rá (10.4).

Ismétlődő (havi) számla. Az ismétlődő számlázás a saját úton is működik; a sikeres kiállítás után a rendszer a következő esedékességet is lépteti. Az ütemezés létrehozása a Pro és az Ultra csomag funkciója, az automatikus (megerősítés nélküli) kiállítás pedig Ultra csomagot kíván (12.1).

Számlakép (PDF). A saját úton kiállított számlához a titkar.ai maga készíti a számlaképet, és azt abból az adatból, amit a NAV-nak jelentett – így a kép garantáltan a bevallott tartalmat mutatja (15. fejezet).

Előlegszámla és végszámla. A saját úton elérhető: a beérkezett előlegről előlegszámla állítható ki, a teljesítés után pedig az azt beszámító végszámla. Mindkettő rendes számla, a számlák közös sorszám-tartományából, teljes NAV-adatszolgáltatással; a különbséget a tételekre kerülő előleg-jelölés, végszámlán pedig a beszámított előlegszámla hivatkozása adja. A feltételeket és a folyamatot a 9.13 pont írja le.

Gyűjtőszámla és egyszerűsített számla. Szintén elérhető, kifejezett kérésre: a gyűjtőszámla (Áfa tv. 164. §) több, külön napokon történt teljesítést fog egy bizonylatra, tételenkénti teljesítési dátummal; az egyszerűsített adattartalmú számla (Áfa tv. 176. §) azonnali készpénzes vagy bankkártyás fizetésnél a bruttó árat és az áfatartalmat közli, nettó-áfa bontás nélkül. A szabályokat és a korlátaikat a 9.13 pont tartalmazza.

4.2 Amit a saját út NEM tud – ki kell mondani

Az alábbiak a saját úton jelenleg nem érhetők el. A rendszer nem próbálja meg és nem hasal el félúton: a korlátot már akkor kimondja, amikor jelzed a szándékodat, és megmondja, mi a járható út helyette. A beépített asszisztens is előre közli ezeket, és nem ígéri meg őket.

• nyugta (11. fejezet),
• időszakos elszámolású (folyamatos teljesítésű) számla,
• kiállított díjbekérő törlése (10.6).

A teljes felsorolás az indoklással és a járható alternatívával a 26.1 pontban áll.

A helyesbítő (módosító) számla a saját úton elérhető (13.5): a hibás adat sztornó nélkül, módosító okirattal javítható, és ugyanaz a számla többször is helyesbíthető.

4.3 A sztornó feltétele

Sztornózni csak azt a számlát lehet, amelynek a NAV-adatszolgáltatása már lezárult (done), és egy számla kétszer nem sztornózható. Az előfeltételeket, a folyamatot és a korlátokat a 13. fejezet írja le.

4.4 A te teendőid

• Hibás számlánál válaszd meg a javítás útját: ha csak egy adat hibás, a helyesbítő számla a jobb út (a számla él tovább, a NAV a különbözetet kapja); ha az egész számla érvénytelen, sztornózd, és állítsd ki újra a helyes adatokkal.
• Készpénzes vevőnek rendes számlát állíts ki, „készpénz” fizetési móddal.
• Előlegnél díjbekérőt készíts, és abból csináld meg a végszámlát.
• Sztornó előtt győződj meg róla, hogy az eredeti számla adatszolgáltatása lezárult.

A nyugta véglegesen nincs a programban: a titkar.ai nem nyugtaadó program, és a fejlesztési terv sem irányoz elő nyugta-funkciót a saját úton (11.).

5. Hozzáférés, felhasználók, jogosultságok

5.1 Egy felhasználó – egy fiók

A titkar.ai-ban egy felhasználóhoz pontosan egy fiók (bérlő) tartozik, és ezt az adatbázis egyedi indexszel is kikényszeríti. A regisztrációkor a fiók automatikusan létrejön; ha ez valamiért elakadna, a rendszer a következő kérésnél magától pótolja.

Nincs többfelhasználós hozzáférés. Ezt egyértelműen ki kell mondani:

• nincs meghívó-folyamat és nincs felhasználó-hozzáadó felület,
• nincs „csak megtekintő”, „könyvelő” vagy más korlátozott hozzáférés,
• az adatbázisban létezik ugyan tulajdonos / tag szerep-mező, de viselkedésbeli különbsége nincs: sem a kiállítás, sem a sztornó, sem a beállítások nem néznek szerepet.

Ennek a gyakorlati következménye: a könyvelőd ma nem tud külön hozzáférést kapni a fiókodhoz. Az adatait a program exportjain keresztül kapja meg (adóhatósági ellenőrzési adatszolgáltatás, PDF-ek, könyvelői csomag), nem saját belépéssel.

Kimondva: a fiókhoz egyetlen természetes személy fér hozzá, és minden művelet az övé — a fiókhoz hozzáférő felhasználó jogosult kiállítani, sztornózni és a beállításokat módosítani. Szerepkör-alapú jogosultsági rendszer nincs, és ez a dokumentum nem is ír le ilyet.

5.2 Belépési módok

A munkamenet 7 napig él, aktív használat mellett naponta megújul. Jelszó-visszaállításkor a rendszer minden korábbi munkamenetet megszüntet, és a sikeres visszaállításról biztonsági értesítőt küld. A hitelesítés technikai védelmeit (kérés-korlátok, szerveroldali fiók-feloldás) a 24.1 pont írja le.

5.3 Platform-adminisztrátor

Az üzemeltető oldalán létezik egy külön, platform-admin kategória (a szolgáltatás üzemeltetéséhez, például jutalék-elszámoláshoz). Ez szándékosan független a fiókok szerepköreitől, kizárólag előre rögzített, megerősített e-mail-címekhez köthető, és alapértelmezetten üres – beállítás nélkül senki nem admin. A te számláid adataihoz ez a kategória nem ad automatikus hozzáférést.

5.4 A saját számlázás bekapcsolásának feltételei

A saját útra váltás csak akkor engedélyezett, ha a fiókodhoz be van kötve egy NAV technikai felhasználó (login név, adószám, jelszó, XML aláírókulcs), és meg van adva az XML cserekulcs is. A cserekulcs nélkül a számla kiállítása menne, az adatszolgáltatás viszont nem – ezért a rendszer a váltást ilyenkor elutasítja, és megmondja, mi hiányzik.

A NAV-oldali jogosultságok (legkisebb jogosultság elve):

A bekötés lépéseit, a kulcsok tárolását és a saját úthoz tartozó korlátokat a 6. fejezet részletezi. A számlázás kártyáján nincs „Kapcsolat bontása” gomb: nincs külső számlázó-kulcs, amit bontani lehetne — a NAV-hozzáférés visszavonása a NAV oldalán, illetve a tárolt adatok törlésének kérésével történik (lásd 6. fejezet).

5.5 Biztonsági korlátok a kiállításra (választható)

A beállítások Biztonság pontja alatt korlátokat kapcsolhatsz be: megerősítés azonosítókulccsal (step-up), egy számla bruttó plafonja és napi darabszám-plafon. Alapértelmezetten egyik sincs bekapcsolva – ilyenkor semmilyen extra korlát nem érvényes.

A két kemény korlát – az egy számlára vonatkozó bruttó összegplafon és a napi darabszám-plafon – minden kiállítási úton érvényesül: az egyedi, a tömeges és az ütemezett (automatikus ismétlődő) kiállításon egyaránt; ezeket egyik út sem kerüli meg.

A megerősítés azonosítókulccsal (step-up) ezzel szemben csak az általad indított utakon fut: az egyedi és a tömeges kiállításon. Az Ultra csomag automatikus ismétlődő kiállítása nem kér kiállításonként azonosítókulcsos igazolást – ott az igazolás egyszer, az automatikus mód bekapcsolásakor történik (12.1). Ha tehát „mindig” megerősítés-módot állítasz be, az az automatikus ütemezésekre nem terjed ki.

A beállítások pontos jelentését, a döntési sorrendet és az atomi foglalást a 24.2 pont írja le.

Vállalt döntés (T-38 lezárva): marad a bekapcsoláskori egyszeri igazolás, mert a felhatalmazás a konkrét ütemezés tartalmához kötött: az ütemezés vevője, tételei és összege utólag nem módosítható — tartalmi változtatás csak törlés + újrafelvétel útján lehetséges, ami új azonosítókulcsos igazolást kíván; az automatikus mód kikapcsolása a felhatalmazást törli; meglévő felhatalmazás alatt egyedül a hónap napja állítható át. Az agent (és így egy esetleges prompt injection) az automatikus módot bekapcsolni nem tudja — az kizárólag a megerősítő kártya védett, azonosítókulcsot kérő útján kapcsolható.

5.6 Csomaghoz kötött korlátok

A csomagok számszerű keretei (Free havi 5 éles számla, mentett partnerek száma, napi AI-üzenetkeret) és a funkció-korlátok a 23. fejezetben állnak. Két dolgot itt is érdemes tudni a havi keretről:

• A számláló minden számlát beleszámol az adott naptári hónapban – beleértve a sztornó okiratot is (az önálló számla-bizonylat), valamint a NAV-ból importált számlákat. A díjbekérő és a nyugta nem számít bele.
• A kereten belül a később sztornózott számla is „elhasznált” marad – a kiállítás ténye a metrika, így nincs „sztornózd és állítsd ki újra” kerülőút.

5.7 A blokkolt kiállítás nem oszt sorszámot

Ez a sorszámozás folyamatossága (23/2014. NGM 8. § (1) a)) miatt fontos, ezért kimondjuk: ha a kiállítás bármely okból elakad, sorszám nem használódik el, és lyuk nem keletkezik a sorszám-tartományban. A rendszer ezt két, egymástól független módon biztosítja: a korlátok a sorszám-kiosztás előtt döntenek, a kiosztás pedig a mentés tranzakcióján belül történik. A teljes levezetés a 8.3 és 8.6 pontban, a csomag-kapuk sorrendje a 23.3 pontban áll.

5.8 Napló – és a naplózás korlátja

A rendszer a bizonylat-műveletekről (vázlat, megerősítés, kiállítás, sztornó, hiba) naplót vezet a fiókodhoz, a bizonylatszámmal és a művelet adataival együtt (24.4).

Korlát, amit ki kell mondani: a kiállítási és sztornó-naplóbejegyzések nem rögzítik, hogy melyik felhasználó végezte a műveletet – a napló a fiókhoz kötött, nem a személyhez. Mivel a fiókhoz jelenleg egyetlen felhasználó tartozhat (5.1), ez a gyakorlatban nem okoz kétértelműséget: minden művelet a fiók egyetlen felhasználójáé. A „ki állította ki” kérdésre azonban a napló önmagában nem válaszol.

Kimondva: mivel a fiókhoz egyetlen felhasználó tartozik (5.1), minden művelet ehhez a felhasználóhoz rendelhető — a napló fiók-szintű bejegyzése így személyhez köthető.

5.9 A te teendőid

• Hozz létre a NAV Online Számla felületén technikai felhasználót „Számlák kezelése” joggal, és add meg a beállításokban a login nevet, adószámot, jelszót, XML aláírókulcsot és XML cserekulcsot; ezután aktiváld a „titkár.ai · saját számlázás” kártyát.
• Erősítsd meg az e-mail-címedet (ez kötelező), és kapcsold be az azonosítókulcsot vagy a kétlépcsős azonosítást.
• Megfontolandó (nem kötelező): állíts be a Biztonság alatt összeg-plafont és napi darabszám-korlátot – ezek az elgépelt nagy összeg és a futótűz-szerű, hibás sorozat ellen védenek.

6. Üzembe helyezés: a NAV technikai felhasználó és a kulcsok

Ez a fejezet azt írja le, mit kell egyszer beállítanod ahhoz, hogy a titkár.ai a saját útján – külső számlázó program nélkül, közvetlenül a NAV Online Számla rendszere felé – működjön. Amíg ez az üzembe helyezés nincs kész, a saját út nem kapcsolható be.

6.1 Mire van szükség

A saját úthoz egyetlen külső azonosító-készlet kell, a NAV Online Számla rendszeréből:

Az aláírókulcsot és a cserekulcsot a NAV állítja elő a technikai felhasználóhoz; a titkár.ai egyiket sem generálja és nem is tudja kitalálni.

A cserekulcs a NAV specifikációja szerint pontosan 16 karakter – a rendszer ezzel a kulccsal fejti vissza a NAV-tól kapott adatszolgáltatási tokent.

6.2 A NAV-oldali lépések

1. Lépj be a NAV Online Számla rendszerébe (Ügyfélkapuval), a céged adózói fiókjába.
2. Hozz létre egy technikai felhasználót.
3. Add meg neki a megfelelő jogosultságokat. A rendszer erről szó szerint ezt közli veled a bekötő űrlapon: a számlatörténet-importhoz csak lekérdező jog kell („Számlák lekérdezése”), ha viszont a saját (titkár.ai-os) számlázást is használod, ahhoz a „Számlák kezelése” jog ÉS az XML cserekulcs is kell.
4. Generáld és másold ki az aláírókulcsot és a cserekulcsot.

Ugyanezt a követelményt mondja ki a chatben megjelenő NAV-bekötő kártya és a nyilvános Biztonság-oldal is: a bejövő számlák beolvasásához elég a lekérdező jog, a „Számlák kezelése” (beküldés, módosítás) jog viszont kell, ha a saját, NAV-közvetlen számlázást is használod – mert az adatszolgáltatást ilyenkor a titkár.ai küldi be a nevedben (24.6).

A Beállítások NAV-szekciójában két külső hivatkozás segít: a NAV Online Számla megnyitása, illetve a NAV hivatalos regisztrációs útmutatója.

A NAV-oldali nyilvántartásba vétel (a technikai felhasználó létrehozása) a 13/A. § (2) szerint az adatszolgáltatás megkezdésének előfeltétele. Ez a te feladatod az adózói fiókodban; a titkár.ai ezt nem tudja helyetted elvégezni.

6.3 A bekötés a titkár.ai-ban

A bekötő űrlap a Beállítások → NAV-szekcióban van. Mezők: login név, adószám, jelszó, XML aláírókulcs. A cserekulcs mezője alapból rejtve van, és „(opcionális)” címkével jelenik meg – a „+ XML cserekulcs (opcionális, későbbi beküldéshez)” gombra kattintva nyílik ki.

Ez a jelölés a számlatörténet-import szempontjából igaz, a saját számlázás szempontjából nem: a cserekulcs a saját úton kötelező. Nélküle a rendszer nem enged át a saját számlázásra, és ha valahogy mégis oda kerülnél, a kiállítás menne, az adatszolgáltatás viszont nem.

A jelszó mezőbe a technikai felhasználó bejelentkezési jelszava kell, nem valamelyik kulcs. Ha a NAV INVALID_SECURITY_USER hibával elutasít, a felület célzott terelő szöveget mutat: éles fiókban jött-e létre a felhasználó, a jelszó mezőben tényleg a bejelentkezési jelszó van-e, és pontos-e a login név.

6.4 Mit ellenőriz a rendszer mentés előtt – és mit nem

Amit ellenőriz:

• Offline adószám-ellenőrzés. A megadott törzsszámot ellenőrzőszámmal validáljuk; hibás számnál a NAV-ot meg sem hívjuk, azonnal szólunk.
• Élő hitelesítés-próba. A mentés előtt a szerver egy rövid, egy oldalas queryInvoiceDigest lekérdezést futtat (kimenő irány, elmúlt 7 nap). Csak akkor mentünk, ha ez lefutott – így a rossz jelszó vagy rossz aláírókulcs azonnal kiderül.

Amit NEM ellenőriz – ezt fontos tudnod:

• A bekötési próba csak a lekérdező utat igazolja. A cserekulcs helyességét és a „Számlák kezelése” jog meglétét bekötéskor semmi nem ellenőrzi.
• Ezek hibája először az első számla beküldésénél derül ki, tehát már azután, hogy a számla nálunk létrejött. A számla ilyenkor érvényes, csak az adatszolgáltatása akad el – a rendszer újrapróbálja, és a pénzügyi teendők között jelzi (18.4).

6.5 Teszt és éles környezet

A NAV két végpontot üzemeltet, és a rendszer mindkettőt ismeri (a végpontok címét a 2.3 pont tartalmazza). Az éles szolgáltatásban a teszt-mód nem választható. A kapcsoló csak fejlesztői buildben látszik, és a szerver élesben mindig live módra kényszerít – így egy manipulált űrlap sem köthet be teszt-környezetet a valódi számláidhoz.

6.6 Hogyan tároljuk a kulcsokat

Fiókonként (céged szerint) egyetlen sor tárolja a NAV-adatokat (nav_credentials tábla, egyedi index a bérlőre). Ami titkosítva van és ami nem:

A titkosítás AES-256-GCM, base64(iv):base64(tag):base64(ciphertext) formátumban; a kulcs egy 32 bájtos, környezeti változóban tárolt alkalmazás-kulcs (APP_ENCRYPTION_KEY), ami nem az adatbázisban van.

A visszafejtés kizárólag szerver oldalon történik. A böngészőbe, a chatbe és az AI-modellhez a jelszó és a kulcsok soha nem kerülnek ki. A felület állapot-lekérdezője egyetlen titkot sem fejt vissza – csak azt adja vissza, hogy van-e eltárolt cserekulcs.

A NAV felé a kriptográfia a NAV specifikációja szerint megy: a jelszó SHA-512 lenyomata, a kérés-aláírás SHA3-512, a NAV-tól kapott token dekódolása a cserekulccsal AES-128-ECB.

6.7 A saját számlázás bekapcsolása

A Beállítások „Számlázó” váltójában a harmadik szegmens neve „titkár.ai · saját számlázás”. A leírása szó szerint:

„A számlát maga a titkár.ai állítja ki, és közvetlenül a NAV Online Számla felé szolgáltat adatot – nincs külön számlázó-előfizetés. A számlaszám saját, elkülönített tartományból megy (TITKAR-ÉÉÉÉ-N), a számlaképet is mi adjuk.”

A váltásnak szerveroldali kapuja van. Bekötött NAV technikai felhasználó és eltárolt cserekulcs nélkül a rendszer elutasít, ezzel az üzenettel:

„A saját számlázáshoz az XML cserekulcs is kell – add meg a NAV technikai felhasználónál (és a NAV-fiókban a »Számlák kezelése« jog is legyen bepipálva).”

A szegmens fokozatos bevezetés alatt áll: csak akkor jelenik meg, ha a céged már a saját úton van, vagy ha az üzemeltető a bevezetési kapcsolót kinyitotta. Ha nem látod, a saját út a te fiókodban még nem elérhető.

A teendők sorrendje:

1. NAV Online Számla fiókban technikai felhasználó létrehozása, „Számlák kezelése” joggal.
2. Az aláírókulcs és a cserekulcs kimásolása.
3. Beállítások → NAV-szekció: login, adószám, jelszó, aláírókulcs, majd a „+ XML cserekulcs” gomb alatt a cserekulcs megadása.
4. Beállítások → Számlázó → „titkár.ai · saját számlázás” → „Számlázás ezzel”.

6.8 A kiállító (a te céged) adatai a számlán

A számlára és a NAV-adatszolgáltatásba kerülő kiállítói törzsadat nem a mi űrlapunkról jön: a rendszer a saját adószámodra lekérdezi a NAV queryTaxpayer szolgáltatását, és onnan veszi a hivatalos nevet, a címet, az áfakódot és a megyekódot. Így garantáltan az az érték megy vissza a NAV-nak, amit a NAV maga tart nyilván.

Minden sikeres lekérdezés eltárol egy pillanatképet (supplier_snapshot). Ha a NAV épp nem érhető el, a kiállító-blokk ebből épül fel – a NAV kiesése így nem akadályozza a számlakiállítást (13/B. §). Kivétel: ha pillanatkép sincs (például a legelső kiállításnál), a kiállítás meghiúsul – lásd 16.6.

A törzsadatból egyetlen mező a miénk: a bankszámlaszám, amit a beállításaidnál adsz meg (ez kerül a számlaképre és az átutalási QR-kódba).

6.9 Korlátok – amit ezen az úton tudnod kell

• A NAV-adatok újbóli mentése a cserekulcsot megőrzi. A mentés felülíró (upsert) művelet, de a cserekulcs mező üresen hagyása a korábban eltárolt cserekulcsot nem törli – az érintetlenül megmarad. A cserekulcs cseréje új érték megadásával történik; üres mezővel törölni nem lehet.
• A chatben megjelenő NAV-bekötő kártyán nincs cserekulcs mező (csak login, adószám, jelszó, aláírókulcs). Onnan a saját számlázás nem hozható működésbe – a meglévő cserekulcsot azonban egy onnan indított frissítés nem bántja (lásd az előző pontot). A saját úthoz mindig a Beállítások NAV-szekcióját használd.
• A NAV-kapcsolat bontására a saját úton nincs felület. A számlázó-kártyán nincs „Kapcsolat bontása” gomb, mert a saját útnak nincs külső számlázó-kulcsa; a NAV technikai felhasználó törlésére sincs külön UI.
• A NAV-nyilvántartott cégadat kézzel nem írható felül. Név, cím, adószám, áfakód, megyekód: kizárólag a NAV queryTaxpayer válaszából származhatnak. Amit a NAV nem ad vissza, az fiók-szintű beállítás: a közösségi adószám és a pénzforgalmi elszámolás a számlázási alapértékek között adható meg, az alanyi adómentesség-jelölés a tételek AAM-jogcíméből származik (28.6).
• A pillanatkép nem tárol mindent. A supplier_snapshot a nevet, a címet, az áfakódot és a megyekódot őrzi meg – a közösségi adószámot és az alanyi adómentesség jelölését nem.

Kimondva: a NAV-kapcsolat megszüntetésére nincs önkiszolgáló eljárás — a bontást a Szolgáltatótól kell kérned (info@titkar.ai), aki a tárolt kulcsokat törli. A kulcsok cseréje rendezett: új érték megadása felülír, az üresen hagyott cserekulcs-mező a meglévőt megőrzi.

7. A számlakiállítás folyamata és állapotai

7.1 A három szakasz

A saját úton a számla útja mindig ugyanaz a három szakasz:

vázlat → megerősítés → lezárás

A vázlat egy külön táblában él (invoice_drafts), és soha nem számla. A számla a lezáráskor születik meg.

7.2 A vázlat

Amikor számlát kérsz, a rendszer vázlatot állít össze. Ez:

• nem állít ki semmit, és nem oszt sorszámot;
• a szerver számolja ki belőle a nettó, áfa és bruttó összegeket (nem az AI-modell);
• kap egy külső azonosítót;
• awaiting_confirmation (megerősítésre vár) állapotban mentődik.

A külső azonosító csak az egyik úton véd a duplikátum ellen. A tömeges kiállításnál ez a köteghez kötött, stabil kulcs, ezért ott a köteg ismételt beküldése (dupla kattintás, oldal-újratöltés) nem hoz létre második bizonylatot (12.2). Az egyedi kiállításnál viszont az azonosító véletlenszerű: ott a duplikátum ellen a megerősítés atomi állapotváltása véd (egy vázlatból egy számla – 7.4), valamint a percenkénti 10-es kérés-korlát (7.9). Ha ugyanazt a számlát kétszer kéred meg, két külön vázlat készül – ezt a megerősítő kártyán neked kell észrevenned.

7.3 A megerősítő kártya

A vázlat egy interaktív kártyaként jelenik meg a beszélgetésben. A kártya mutatja: a vevőt, a tételeket, a nettó/áfa/bruttó összeget, a pénznemet, a fizetési módot, a teljesítés dátumát, a fizetési határidőt, a kiállítási út jelét, és – ha van – figyelmeztetéseket (lásd 9.11).

A kártyán két dolgot tehetsz:

• „Szerkesztem” – a vázlat a kiállítás előtt módosítható (tételek, fejléc). A módosítás ugyanazon az ellenőrző kapun megy át, mint az eredeti vázlat, és ugyanaz a vázlat-azonosító és idempotencia-kulcs marad (nem keletkezik második bizonylat). Csak awaiting_confirmation állapotban lehetséges.
• „Kiállítom” – ez a tudatos megerősítés. A gomb egy szerveroldali végpontot hív a vázlat azonosítójával. Ez a kattintás indítja a lezárást.

Az AI-asszisztens önmagában nem tud számlát kiállítani: a kiállítás mindig a te kattintásodra indul (22.3).

7.4 A lezárás (a rendelet 8. § (6) bekezdése szerint)

A rendelet szerint a számla akkor minősül kiállítottnak, amikor a program az adatait lezárja; az adatszolgáltatási kötelezettség is ehhez az időponthoz kötődik.

A titkár.ai saját útján a lezárás egyetlen adatbázis-tranzakció. A folyamat:

1. A rendszer először atomi állapotváltással foglalja le a vázlatot (awaiting_confirmation → issuing). Csak ebből az egy állapotból enged – így egy dupla kattintásból sem lesz két számla.
2. Lefutnak a kiállítás előtti kapuk (csomagkeret, biztonsági korlátok, passkey-s megerősítés – lásd 8.6).
3. A tranzakción kívül, még előtte, a rendszer beszerzi a hálózatot igénylő adatokat: a kiállítói törzsadatot (élő NAV-lekérdezés vagy a tárolt pillanatkép) és devizás számlánál az MNB-árfolyamot. A tranzakcióban már csak adatbázis-írás és számítás van.
4. Megnyílik a tranzakció, és egyben megtörténik:
   1. a sorszám kiosztása,
   2. a NAV InvoiceData XML felépítése és ellenőrzése – még mielőtt bármi tartósan mentődne,
   3. a számla sorának létrehozása (állapot: kiállítva),
   4. a tételsorok létrehozása, lánc-tételindexszel,
   5. a számlalánc magjának létrehozása (a későbbi sztornó/módosítás horgonya),
   6. a NAV-beküldés sorba állítása pending állapotban, a beküldendő XML-lel és annak SHA3-512 lenyomatával együtt,
   7. a vázlat issued-re állítása a számlaszámmal, és az audit-napló bejegyzés.
5. A számla a tranzakció véglegesítésének (commit) pillanatában jön létre. Ez a lezárás pillanata – nálunk, nem egy távoli rendszerben.

Ha a tranzakció bármely lépése elhasal, a visszagörgetés mindent visszavon: nem marad se kiosztott sorszám, se félkész számla, se árva beküldési szándék. Ezért a hiba utáni újrapróbálkozás veszélytelen: nem keletkezhet duplikátum és nem keletkezhet sorszám-lyuk.

7.5 A vázlat állapotai

A failed vázlat nem indítható újra. A kiállítás csak awaiting_confirmation állapotból enged, tehát ilyenkor új vázlatot kell kérned. Ez szándékos: az újraindítás elmosná, hogy melyik kísérlet melyik adattal futott.

7.6 A NAV-adatszolgáltatás nem része a lezárásnak

A kiállítás és a NAV-adatszolgáltatás két külön lépés. A tényleges beküldés a tranzakció véglegesítése után indul, „legjobb szándék” alapon; ha nem sikerül, azt naplózzuk, és az újrapróbáló sor viszi tovább. A NAV kiesése így soha nem akadályozza a számla kiállítását (13/B. §).

Ebből következik a legfontosabb szabály, amit a rendszer az AI-asszisztensre is rákényszerít:

A kiállítás sikeréből soha nem következik, hogy az adatszolgáltatás is teljesült.

Ezt mondja a megerősítő kártya szövege is: a kiállítás előtti mondat úgy szól, hogy „A kiállítás végleges, és a NAV-adatszolgáltatás azonnal indul” – nem úgy, hogy „azonnal jelentjük a NAV-nak”. A különbség nem stilisztikai: a beküldés megindul, a teljesüléséhez viszont a NAV visszaigazolása kell (16.3). Ugyanez a megfogalmazás áll a sztornó megerősítő kártyáján is (13.7).

Korlát, kimondva: ez a megfogalmazás a magyar felületen, a megerősítés előtti mondatra igaz. Az angol felületen a kártya változatlanul befejezett tényt állít („we report it to NAV right away”), és a kiállítás közbeni, majd utáni jelzés is így fogalmaz: „Jelentem a NAV-nak…”, utána a számlaszám mellett „· NAV-nak jelentve” (sztornónál „Sztornózom és jelentem a NAV-nak…”, illetve „· érvénytelenítve, jelentve a NAV-nak”). Ezek a feliratok a bizonylat létrejöttét jelzik, nem az adatszolgáltatás teljesülését. A mérvadó mindig az adatszolgáltatás lekérdezett állapota (16.4, 16.8), nem a kártya felirata.

Ugyanennek a kártyának a záró mondata a későbbi javításra „sztornó vagy helyesbítő számla” lehetőséget kínál – mindkettő elérhető (13.4, 13.5).

A beküldés önálló állapotgépen fut (pending → submitted → done / aborted / failed); az állapotok pontos jelentését, a „teljesült-e” és a „magától rendeződik-e” kérdést a 16.4 pont táblázata adja meg. A NAV saját hibakódjait a rendszer magyar, cselekvésre hívó mondatokra fordítja; ismeretlen kódnál a NAV eredeti üzenete jelenik meg, hogy soha ne maradj puszta kóddal (18.5).

7.7 Automatikus utánkövetés

15 percenként fut egy ütemezett feladat, amely lekérdezi a beküldött tételek feldolgozási állapotát, és újrapróbálja az elakadt beküldéseket. Amit a rendszer soha nem küld újra: a már beküldött (submitted) és a NAV által tartalmilag elutasított (aborted) tételt. A pontos szabályokat, a türelmi időt és az indoklást a 18.2 és 18.3 pont tartalmazza.

7.8 Hogyan látod, mi történik a beküldéssel

Három út van rá – rákérdezés a chatben, egy konkrét számla adatszolgáltatásának lekérdezése, és a pénzügyi teendők sávjában magától megjelenő jelzés. A három eszközt a 16.8 pont, a jelzések küszöbeit a 18.4 pont írja le. Kézi újraküldést failed és pending állapotnál kérhetsz; aborted esetén a rendszer szándékosan megtagadja (18.6).

7.9 Amit a kiállító végpont korlátoz

• Kérés-korlát: percenként legfeljebb 10 kiállítási kérés cégenként. Ez a véletlen vagy hibás ismétlés ellen véd, és a korlátot vezérlő szolgáltatás kiesésekor is zárva marad (inkább elutasítunk, mint kockáztassuk a dupla kiállítást).
• Idempotencia: ha egy már kiállított vázlatot erősítesz meg újra (például oldal-újratöltés után), a rendszer a korábbi eredményt adja vissza, nem állít ki másodszor.

7.10 Audit-napló

A folyamat minden lépése naplóba kerül: draft (vázlat), confirm (megerősítés), issue (kiállítás), fail (sikertelen kiállítás), storno (érvénytelenítés). A napló felépítését, lekérdezését és korlátait a 24.4–24.5 pont írja le.

7.11 Korlátok – amit ezen az úton tudnod kell

• A kiállítási hiba oka nem mindig jut el hozzád. A NAV-leképező és a séma-ellenőrző részletes magyar hibaüzeneteit (pl. „a vevő adószámos, ezért a címét is meg kell adni”) a megerősítés utáni ágon a rendszer egy általános „A kiállítás nem sikerült.” mondatra cseréli, és ez kerül a vázlatra és eléd is. A vázlat összeállításakor keletkező hibák konkrét üzenete viszont eljut hozzád.
• Az elakadt beküldés nem szólal meg magától a beszélgetésben. A pending és failed állapotról a pénzügyi teendők sávjából vagy kérdésre értesülsz.
• Technikai érvénytelenítés (ANNUL) ezen az úton nincs beküldve. A rendszer ismeri az adatszerkezetét, de a beküldő kifejezetten elutasítja, és az ütemezett feladat is kihagyja. A NAV-hoz tévesen felküldött adatszolgáltatás technikai érvénytelenítését ma a NAV saját felületén kell intézni (18.9).
• A failed vázlat nem indítható újra (lásd 7.5).

Kimondva: a kiállítás lezárásának pillanata a tranzakció véglegesítése a szolgáltató rendszerében — nem a hálózati válasz megérkezése hozzád. Ez egyben a rendelet 8. § (6) bekezdése szerinti kiállítási időpont is: a számla abban az időpontban minősül kiállítottnak, amellyel a program a számla adatait lezárja. Ritka esetben (a véglegesítés és a válasz között megszakadó kapcsolatnál) a számla létezik, miközben a felület hálózati hibát mutat; a tényleges állapotot ilyenkor a számla lekérdezése adja meg, és a sorszám-folytonosság mindkét esetben sértetlen.

8. Sorszámozás

8.1 A sorszám képe

A saját úton kiállított bizonylat sorszáma:

ELŐTAG-ÉÉÉÉ-N

Például: TITKAR-2026-42.

A sorszám nincs nullákkal feltöltve: a 9. után a 10. számla …-10 lesz, nem …-0010.

Az előtag a számláknál TITKAR, a díjbekérőknél DIJB – egyik sem állítható át a felületről (lásd 8.8).

8.2 A tartomány kulcsa

Egy sorszámtartományt három adat határoz meg: a céged + az előtag + az év. Minden ilyen hármashoz külön számláló tartozik.

8.3 Kihagyás és ismétlés nélküli folyamatosság (8. § (1) a))

A rendelet 8. § (1) a) pontja folyamatos, kihagyás és ismétlés nélküli sorszámozást ír elő. Ezt a rendszer két, egymást kiegészítő mechanizmussal biztosítja:

1. Atomi kiosztás. A számláló léptetése egyetlen adatbázis-utasítás, amely zárolja a számláló sorát. Két párhuzamos kiállítás közül a második megvárja az elsőt – két számla soha nem kaphatja ugyanazt a sorszámot.
2. A kiosztás a számla mentésének tranzakcióján belül fut. Ha a kiállítás bármely későbbi lépése elhasal, a visszagörgetés a számláló léptetését is visszavonja – lyuk sem keletkezik.

Ez a két szabály a kódban is kimondott kényszer: a sorszámot a tranzakción kívül kiosztani tilos.

Igazolás valós adatbázison (2026-08-04, éles motorral azonos PostgreSQL-en):

• 25 párhuzamos kiosztás → 25 egyedi, folytonos sorszám, duplikátum nélkül;
• szimulált kiállítási hiba (visszagörgetés) után a következő sorszám a 26. → nincs lyuk;
• évváltásnál a számláló 1-től indul.

8.4 Évváltás

A számláló évenként 1-től indul újra. Az ismétlésmentesség évhatáron át azért áll fenn, mert a sorszám maga tartalmazza az évet (TITKAR-2026-1 és TITKAR-2027-1 két különböző sorszám).

Az év forrása a kiállítás dátumának éve, nem önmagában a szerver órája.

8.5 Elkülönített tartományok (8. § (2) és (5))

Az elkülönítést az előtag adja: eltérő előtag = önálló, egymástól független számsor. Ezen az alapon a számla és a díjbekérő ma is két külön tartományon fut (TITKAR-… és DIJB-…).

8.6 A sikertelen kiállítás nem oszt sorszámot

A rendszerben több, egymást követő kapu áll, és mindegyik a sorszám kiosztása előtt dönt. Ha bármelyik blokkol, sorszám nem keletkezik:

8.7 A sorszám gépi feldolgozása

A rendszer a számlaszámot az utolsó két szegmens alapján bontja vissza évre és sorszámra, így a kötőjelet tartalmazó előtag is helyesen kezelhető (BIT-NEX-2026-7).

A sorszám-intervallumra kérdező adóhatósági ellenőrzési adatszolgáltatás (11/A. §) soha nem szöveget hasonlít: TITKAR-2026-10 szövegként kisebb volna, mint TITKAR-2026-9, és az export csendben hiányos lenne. A rendezés és a tartomány-döntés mindig a kinyert (év, sorszám) páron megy.

A NAV-oldali formai kapuk közül a sorszámot kettő érinti: a számlaszám elején és végén nem lehet szóköz vagy sortörés, és a módosító okirat sorszáma nem egyezhet a módosított számla sorszámával.

A sztornó okirat önálló számlaszámot kap, ugyanabból a tartományból (tehát a sztornózás is fogyaszt egy sorszámot – ez így felel meg a folytonosságnak).

8.8 Korlátok – amit ezen az úton tudnod kell

• Az előtag ma a felületről nem állítható át. A rendszer belül ismeri a „számlaszám-előtag” beállítást, és a saját út ezt olvassa, de egyetlen felületi vagy asszisztens-funkció sem írja: sem a beállítás-mentés, sem a titkár preferencia-eszköze nem küldi. Következmény: az előtag közvetlen adatbázis-beavatkozás nélkül TITKAR marad.
• Az előtagra semmilyen formai szabály nincs kikényszerítve (hossz, engedélyezett karakterek) a saját úton.
• Az előtag év közbeni megváltoztatása új, 1-től induló tartományt nyitna – a rendszer ezt nem tiltja és nem figyelmezteti a felhasználót.
• Nyugta nincs a saját úton, ezért a 8. § (5) szerinti külön nyugta-tartomány sem létezik itt. Készpénzes vevőnek rendes számlát tudsz kiállítani, készpénz fizetési móddal (11. fejezet).
• A 8. § (2) esete ezen az úton nem áll fenn. A rendelet akkor követel meg elkülönített sorszámtartományt, ha az adóalany a programmal a magyarországi adószáma mellett más adószám alatt is bocsát ki számlát. A titkár.ai saját útján a kiállító mindig a fiókodhoz bekötött magyar adószám, mert a kiállítói törzsadat kizárólag a NAV adóalany-lekérdezéséből származik (6.8) – más adószám alatti kibocsátás nem lehetséges. Ha más tagállami adószámod alatt is számlázol, azt ezzel a programmal nem teheted. A vevő honossága ezt a szabályt nem érinti.

Időzóna: a sorszám éve a magyar naptári évet követi. A kiállítás dátumát (a keltét) a rendszer magyar idő szerinti naptári napként állapítja meg (Europe/Budapest), és a sorszám évét ebből a keltéből veszi. Ugyanebben az időzónában számol a napi darabkorlát számlálója is, így a kettő nem tud szétcsúszni. Következmény: a magyar éjfél után kiállított számla a helyes – aznapi – dátumot kapja, és szilveszter éjjel sem kerülhet vissza az előző év sorszámtartományába.

A sorszámozással kapcsolatban nincs teendőd: a sorszámot a rendszer osztja, kézzel nem adható meg és nem írható felül. Ugyanez igaz a kelte (a kiállítás dátuma) mezőre is: azt a rendszer a kiállítás magyar idő szerinti napjából állapítja meg, nem adható meg és nem írható felül (9.2).

Az előtag nem választható a felületen: a rendszer a beépített TITKAR előtagot használja; fiók-szintű saját előtagot kizárólag a Szolgáltató tud beállítani, kérésre. Ha az előtag megváltozik (év közben is), az új előtag alatt új, 1-től induló tartomány nyílik; a korábbi tartomány lezárul, és önmagában kihagyás- és ismétlésmentes marad — a 8. § (2) tartományonként követeli a folytonosságot, több párhuzamos vagy egymást váltó tartomány megengedett.

9. A számla adattartalma és kiállítása

Ez a fejezet azt írja le, milyen adatokat követel meg a rendszer, mikor és mit utasít vissza, és mi az, amit ma nem tud a számlára tenni.

9.1 Amit a vázlat szintjén kötelezően megkövetelünk

Ezek az ellenőrzések már a megerősítő kártya előtt lefutnak, és a hibaüzenetük konkrét, magyar mondat, ami hozzád is eljut:

• Legalább egy tétel kell.
• Minden tételnél kötelező: megnevezés, mennyiség, mértékegység, nettó egységár, áfakulcs.
• A mennyiség és a nettó egységár véges szám; a mennyiség pozitív.
• Negatív nettó egységár csak végszámlán és helyesbítő számlán megengedett (a végszámla a saját úton ma nem elérhető – lásd 26.1). Helyesbítő számlán a negatív sor csak akkor fogadható el, ha az eredeti számla hatályos állapotában is van negatív (engedmény-)sor – különben a rendszer különbözet-gyanús bemenetként elutasítja (13.5).
• A megadott magyar adószámot ellenőrzőszámmal validáljuk; hibás számnál a rendszer elutasítja a kiállítást, magyarázó mondattal.
• Adószámos magyar vevőnél az irányítószámnak 4 számjegyűnek kell lennie.
• A dátumok formátuma ÉÉÉÉ-HH-NN, és valódi naptári napot kell jelenteniük (a „2026-02-30” elbukik).
• A fizetési határidő nem előzheti meg a teljesítés napját.
• A pénznem, a számlanyelv és az áfakulcs zárt, ellenőrzött készletből jön.

A vevő címét a program minden vevőnél megköveteli – a magánszemélynél is. Ez az ellenőrzés nem a vázlat szintjén, hanem a kiállítási kapun fut (ugyanott, ahol az adószámos vevő címe is – 9.3, 9.8): irányítószám vagy település nélkül a számla nem jön létre. A kiállítás a NAV-adatszerkezet felépítésekor áll meg, a tranzakció visszagörgetésével, tehát sorszám sem fogy el (7.4, 8.6).

A kódba írt indoklás ugyanaz, mint a jogszabályé: a vevő neve és címe a számla kötelező eleme (Áfa tv. 169. § e)) – akkor is, ha a NAV-adatszolgáltatásba nem kerül bele (Áfa tv. 10. számú melléklet). A magánszemély vevőre a program saját, külön hibaüzenetet tart fenn:

„A(z) »X« vevő címe hiányzik (irányítószám, település, közterület). A vevő neve és címe a számla kötelező eleme, ezért enélkül a számla nem állítható ki – még akkor sem, ha a vevő magánszemély, és így a NAV-adatszolgáltatásba nem is kerül bele.”

Ennek a mondatnak a konkrét szövege a megerősítés utáni ágon nem jut el hozzád: ott – a többi leképező-hibához hasonlóan – az általános „A kiállítás nem sikerült.” üzenet jelenik meg (7.11). Ami viszont biztos: a hiányos című számla nem keletkezik meg.

Következmény: a saját úton kiállított számla képén a vevő címe mindig ott van, és a 11/A. § szerinti adóhatósági ellenőrzési adatszolgáltatásba is ezekből az adatokból kerül vissza (15.2, 17.4).

A megkövetelt mezők az irányítószám és a település; ha a közterület (utca, házszám) hiányzik, a címbe egy - kerül a helyére. A teljes cím megadása ezért itt is erősen ajánlott.

A te teendőd: a magánszemély vevőnél is rögzítsd az irányítószámot és a települést – akár a partner adatlapján, akár a számlakérésben.

9.2 Alapértelmezések

Ha nem mondasz mást, a rendszer ezekkel dolgozik:

A konkrét kérésed mindig erősebb a tartós beállításnál, a tartós beállítás pedig erősebb a fenti alapoknál.

9.3 A vevő és a vevő-adatok

A rendszer a megadott adószám alapján sorolja be a vevőt, és ehhez igazítja, mit követel meg:

A cím megadása minden vevőnél kötelező, csak az indoka más. Adószámos vevőnél a NAV követeli meg (CUSTOMER_DATA_EXPECTED), magánszemélynél a számla kötelező adattartalma – ezért a két hibaüzenet is más. Adószámos vevőnél a rendszer a beküldés előtt elutasít, ezzel a mondattal:

„A(z) »X« vevő adószámos, ezért a NAV-nak a címét is meg kell adni (irányítószám, település, közterület). Egészítsd ki a vevő adatait.”

Magánszemély vevőnél ugyanez a kapu a 9.1 pontban idézett, saját mondatával áll meg – a hibaüzenet ott nem az adószámra hivatkozik, hanem a számla kötelező adattartalmára.

Mindkét ágon az irányítószám és a település hiánya buktatja meg a kiállítást; ha a közterület (utca, házszám) hiányzik, a címbe egy - kerül a helyére. A teljes cím megadása ezért erősen ajánlott.

Külföldi vevőnél fontos csapdát kerül el a rendszer: egy külföldi adószámból (pl. DE123456789) a számjegyek kiszedésével hamis magyar adószám keletkezne – ez valótlan adatszolgáltatás lenne. Ezért a belföldi ág csak a magyar adószám-mintára nyílik meg; ha a szám nem illeszkedik és közösségi adószám sincs megadva, a rendszer megáll és pontosítást kér.

Magánszemély vevő neve és címe a NAV-adatszolgáltatásból kimarad (Áfa tv. 10. sz. melléklet), és ezt egy külön ellenőrző kapu is őrzi. Ugyanakkor a számlaképnek és a hatósági ellenőrzési adatszolgáltatásnak (11/A. §) szüksége van rá, ezért a vevő címét a rendszer a számla saját során is eltárolja – a kiállításkori állapotában, nem a később átírható partner-nyilvántartásból.

9.4 Áfakulcsok és mentességi jogcímek

Belföldi számlán a NAV csak a 0% · 5% · 7% · 12% · 18% · 27% kulcsokat fogadja el; más numerikus kulcsnál (pl. külföldi 19% vagy 21%) a rendszer érthető magyar hibával megáll. A mentességi és hatályon kívüli jogcímek teljes, elfogadott listáját (AAM, TAM, KBAET, KBAUK, EAM, NAM, ATK és a vele azonos jelentésű TAHK, EUFAD37, EUFADE, EUE, HO, valamint a belföldi fordított adózás F.AFA jelölése) a 14.3 pont tartalmazza.

Kétértelmű kódokat a rendszer nem találgat. Az EUT, EUKT, EU, EUK, MAA, K.AFA és AKK kódoknál megtagadja a leképezést, és pontosítást kér – mert ezek nem mondják meg egyértelműen a helyes NAV-jogcímet (termék vagy szolgáltatás, 37. § vagy sem, illetve a különbözeti adózás fajtája). Ez szándékos: egy rossz áfa-jogcím valótlan adatszolgáltatás.

9.5 Mértékegység

A mértékegység kötelező adat, és a rendszer nem pótolja „darab”-bal: üres mértékegységnél bekéri tőled, ezzel az indokkal, hogy „a számlán kötelező adat”.

Az ismert magyar egységeket (db, kg, tonna, óra, perc, nap, hó, liter, km, m, fm, m³, kWh, karton, csomag) NAV-kódra képezzük le; ismeretlen egységnél saját megnevezésként megy ki, legfeljebb 50 karakterre vágva.

9.6 Fizetési mód

A számla a NAV felé elektronikus megjelenésű bizonylatként megy.

9.7 Deviza és árfolyam

Devizás számlánál az árfolyam kötelező, és nem lehet nulla; HUF-nál fixen 1. Az árfolyamot a rendszer magától szerzi be az MNB napi középárfolyamából. Ha az árfolyam-forrás nem elérhető, a rendszer nem ír be némán 1-et, hanem megáll – a hibás árfolyam hibás adatszolgáltatás volna. A pénznem-készletet, az áthidalási és a tizedesjegy-szabályokat a 14.6 pont részletezi.

Ehhez nincs teendőd.

9.8 A beküldés előtti ellenőrző kapu

A NAV-nak küldendő adatszerkezetet a rendszer még a beküldés előtt ellenőrzi. Az elv a kódban is ki van mondva: „inkább itt bukjon el, mint a NAV-nál” – mert a NAV elutasításánál a beküldés meg sem történik, és a számla adatszolgáltatás nélkül maradna.

A fontosabb, kikényszerített szabályok:

• a pénznem kódja pontosan 3 nagybetű;
• az árfolyam legfeljebb 6 tizedesjegy; HUF-nál csak 1 lehet;
• a kiállító neve, a vevő neve és a tétel megnevezése legfeljebb 512 karakter, és nem lehet üres;
• természetes mértékegységű tételnél a megnevezés, a mennyiség, a mértékegység és az egységár mind kötelező; saját mértékegységnél a megnevezés kötelező;
• elszámolási időszak vége nem lehet a kezdete előtt;
• a számlaszámra vonatkozó formai szabályok (lásd 8.7);
• új számla nem hivatkozhat eredeti számlára; módosító és sztornó okirat viszont csak hivatkozással érvényes, és sztornónál a tételsorok nem hagyhatók el.

Az áfa-specifikus, determinisztikus ellenőrzéseket (adómentes tételnél nulla áfa, fordított adózás vevő-feltétele, közösségi jogcímek vevő-státusza) a 14.4 pont sorolja fel.

9.9 A kiállító adatai a számlán

A kiállító neve, címe, adószáma, áfakódja és megyekódja a NAV saját nyilvántartásából származik (lásd 6.8); a bankszámlaszám a beállításaidból. Ezeket a számlán kézzel nem írod felül.

9.10 A számlakép (PDF)

A számlaképet a rendszer a NAV-nak beküldött adatszerkezetből rendereli – így a kép bizonyíthatóan ugyanazt a tartalmat mutatja, amit a NAV-nak jelentettünk. Magánszemély vevőnél a név és a cím a kiállításkor eltárolt vevőadatból kerül vissza a képre. A számlakép felépítését, az ellenőrzött kötelező adattartalmat, a lenyomatot és a kézbesítést a 15. fejezet írja le.

9.11 Figyelmeztetések, amelyek nem blokkolnak

A megerősítő kártya kiemelten jelez, ha a vázlat a vevő korábbi bizonylataihoz képest szokatlan: kiugró összeg, első bizonylat ennek a vevőnek, szokatlan áfakulcs. Ezek tájékoztatnak, soha nem blokkolnak – a döntés a tiéd. (A tömeges és az automatikus ismétlődő úton ez az ellenőrzés nem fut – lásd 12.4.)

9.12 Korlátok – amit ezen az úton tudnod kell

• A vevő adószámának NAV-oldali érvényességét a kiállítás nem ellenőrzi. Van külön adószám-ellenőrző funkció, amit kérésre lefuttat a titkár, de a kiállítási út magától nem futtatja le.
• Ma nem tölthető mezők a saját úton: a tétel termékkódja (VTSZ/SZJ/KN), a tétel-szintű engedmény, a szállítólevél-hivatkozás, a számviteli teljesítés dátuma, az elszámolási időszak és a közmű-jelölés. A NAV-adatszerkezet ezeket ismeri, de a vázlat-bemenetben nincs mező hozzájuk.
• Nincs időszakos elszámolású (folyamatos teljesítésű) számla a saját úton. A gyűjtőszámla viszont elérhető (9.13).
• A vevő e-mail címe a NAV-nak nem megy – az csak a számla kiküldéséhez kell.
• A kiállító közösségi adószáma és a pénzforgalmi elszámolás fiók-szintű beállítás (számlázási alapértékek): kitöltve a közösségi adószám a supplier-blokkba és a számlaképre, a pénzforgalmi jelölés az adatszolgáltatásba és a számlaképre kerül. Az alanyi adómentesség-jelölést a program a tételek jogcíméből származtatja: AAM-jogcímű tételt tartalmazó számlán a jelölés automatikusan kikerül a NAV-nak; AAM-tétel nélkül a mező kimarad.
• Hibás bemenetnél a megerősítés utáni ágon a konkrét ok elveszik (lásd 7.11); a vázlat-szintű ellenőrzések üzenete viszont eljut hozzád.

A te teendőid a gyakorlatban:

• adószámos vevőnél add meg a teljes címet (irányítószám, település, közterület);
• külföldi vevőnél add meg az országot is — kétbetűs (ISO 3166-1 alpha-2) kódként, pl. DE, AT. Ország nélkül a cím belföldinek (HU) számít. A rendszer a formátumot ellenőrzi (a nem kétbetűs érték hibával elbukik, még a kiállítás előtt), és a magyar adószámú vevőhöz külföldi országot nem enged (a kettő együtt valótlan adatszolgáltatás lenne). A mentett partner országa automatikusan a számlára kerül;
• mértékegység és áfakulcs nélkül nincs számla;
• kétértelmű áfakódnál (pl. „EU”) pontosítsd a jogcímet;
• devizás számlához nincs teendőd: az árfolyamot a rendszer szerzi be.

9.13 Speciális számlafajták

Az alábbi három fajta ugyanabból a közös sorszám-tartományból megy, mint a rendes számla, és mindegyikhez teljes NAV-adatszolgáltatás tartozik. A rendszer egyiket sem választja magától: kifejezetten kérned kell, és a szabályok megsértését már a vázlat szintjén, a megerősítő kártya ELŐTT elutasítja, magyar mondattal.

Előlegszámla

Az előlegszámla a már beérkezett előlegről szól (Áfa tv. 59. §). A teljesítés dátuma az előleg kézhezvételének napja, és a bizonylat minden tétele előleg-jelölést kap az adatszolgáltatásban.

• Ha a pénz még nem érkezett meg, nem előlegszámla kell, hanem díjbekérő – a program a díjbekérőt előlegszámlaként megjelölni nem engedi, és ezt ki is mondja.
• Előlegszámla nem lehet egyszerre végszámla, és nem lehet gyűjtő- vagy egyszerűsített számla.

Végszámla (előleg beszámításával)

A végszámla a teljes ügyletet számlázza, és levonja a korábban előlegszámlázott összeget. Ehhez két dolgot kell megadnod: a beszámított előlegszámla számát, és előlegszámlánként pontosan egy negatív (levonó) tételt – a kettőt a program sorrendben párosítja. Több előleg is beszámítható, de ugyanaz az előlegszámla csak egyszer.

A beszámítás előtt a rendszer minden előlegszámlára ellenőrzi, hogy

• itt, ezen a fiókon állították-e ki (más rendszer előlegszámláját nem tudjuk hitelesen visszaolvasni),
• él-e még (sztornózott előleg nem számítható be),
• lezárult-e sikeresen a NAV-adatszolgáltatása – ez a legfontosabb feltétel: amíg a NAV vissza nem igazolta, a végszámla egy nála még nem létező bizonylatra hivatkozna. Elutasított előlegszámlánál a járható út a javítás, nem a beszámítás,
• valóban előlegszámla-e (van rajta előleg-jelölés),
• azonos-e a pénzneme a végszámláéval.

A NAV-nak menő beszámítási adatot (az előleg kézhezvételének napja, az előlegszámla árfolyama) nem tőled kérjük be: a program az előlegszámla eltárolt, hiteles adatszolgáltatásából és a számlalánc hatályos fejadatából olvassa vissza. Így az sem okoz eltérést, ha az előlegszámla dátumát közben egy fejadat-helyesbítő módosította.

Két különböző „végszámla” – ne keverd össze. Az itt leírt végszámla egy korábbi előlegszámlát számít be, és a beszámítás a NAV-adatszolgáltatásba is bekerül. A 10.4 pont szerinti „díjbekérőből végszámla” ettől független út: a díjbekérő nem számla és nincs adatszolgáltatása, ezért ott nincs mit beszámítani – a rendszer csak a díjbekérő tételeit és vevőadatait veszi át egy rendes számlába.

Gyűjtőszámla (Áfa tv. 164. §)

Több, külön napokon történt teljesítés egy bizonylaton. Ilyenkor minden tételhez kötelező a tétel saját teljesítési dátuma – a NAV ezt 2025. szeptember 15. óta blokkoló hibaként kéri számon –, és a számlaképen tételenként meg is jelenik. A számla fej-szintű teljesítési dátuma nem lehet korábbi a legkésőbbi tétel-teljesítésnél; ha üresen hagyod, a rendszer a tételekből veszi. Gyűjtőszámla nem lehet díjbekérő, előleg-, vég- vagy egyszerűsített számla.

Egyszerűsített adattartalmú számla (Áfa tv. 176. §)

Csak azonnali, készpénzes vagy bankkártyás fizetésnél állítható ki. Itt a bruttó ár az irányadó, és az áfát nem kulcsként, hanem áfatartalomként közli a bizonylat: a számlaképen ezért a nettó és az áfa oszlop szándékosan üresen marad (a „0” hamis állítás lenne egy áfás bruttó összeg mellett), a bruttó és az áfatartalom viszont ott van. A tételek áfakulcsa csak 5%, 18% vagy 27% lehet (ezeknek van áfatartalom-alakjuk), vagy adómentességi jogcím (AAM, TAM, …). Egyszerűsített számla nem lehet díjbekérő, előleg-, vég- vagy gyűjtőszámla.

Ami ezeknél a fajtáknál a javításra vonatkozik

• Egyszerűsített és gyűjtőszámla nem helyesbíthető módosító okirattal: a helyesbítő más szerkezetű bizonylat lenne (bruttó + áfatartalom, illetve tétel-szintű teljesítési dátumok). A program ezt már a szándék jelzésekor kimondja – a járható út a sztornó + új, helyes számla. Sztornózni viszont mindkettőt lehet.
• Előlegszámla és végszámla tételei nem helyesbíthetők: az újraközölt sorokról némán lemaradna az előleg-jelölés (végszámlánál a beszámított előlegszámla hivatkozása), ami valótlan adatszolgáltatás lenne. A fejadat (dátum, fizetési mód) helyesbítése ezeken a bizonylatokon is működik, tétel-hibánál pedig a sztornó + újra kiállítás az út.

10. Díjbekérő (proforma)

10.1 Mi a díjbekérő, és mi nem

A díjbekérő fizetési felszólítás, nem számla. A rendszerben külön bizonylatfajtaként él, és a legfontosabb következménye:

A díjbekérő nem megy a NAV-hoz – nem tartozik hozzá adatszolgáltatás.

Ezt a saját úton a kód is egyértelműen kizárja: díjbekérőnél nem készül NAV-adatszerkezet, nem jön létre számlalánc, és nem keletkezik beküldési sor. Sőt, díjbekérőnél a rendszer a kiállítói törzsadatot sem kérdezi le a NAV-tól, és devizás díjbekérőhöz árfolyamot sem szerez be.

10.2 Hogyan készül

Pontosan ugyanazon az úton, mint a számla: vázlat → megerősítő kártya → „Kiállítom”. A bemeneti követelmények is azonosak a számláéval (lásd 9.1).

10.3 Saját sorszámtartomány

A díjbekérő fixen a DIJB előtaggal megy, tehát DIJB-ÉÉÉÉ-N – a számlák tartományától teljesen elkülönítve, önálló, 1-től induló számsoron. Ezt az előtagot nem tudod megváltoztatni.

10.4 Díjbekérőből végszámla

Fizetés után a díjbekérőből egy lépésben rendes számla készíthető:

• a rendszer új vázlatot állít össze, számlaként, és belsőleg megjegyzi, melyik díjbekérőből készült;
• a tételeket és a vevő adatait a mentett adatból tölti, nem az AI-modell szövegéből – így a számok és a vevő adatai pontosak maradnak;
• a vázlatot ugyanúgy a megerősítő kártyán hagyod jóvá.

Korlát, kimondva: a saját (NAV-közvetlen) úton a díjbekérőre való hivatkozás kizárólag a program belső nyilvántartásában él. Két dolgot szolgál: hogy egy díjbekérőből csak egy végszámla készülhessen, és hogy a pénzügyi teendők között emlékeztetni tudjunk rá. A díjbekérő száma nem kerül rá a végszámla számlaképére, és nem kerül bele a NAV-adatszolgáltatásba sem. Ha a bizonylaton is látszódnia kell a hivatkozásnak, írd bele a tétel megnevezésébe. (A külső számlázós úton ez másképp működik: ott valódi, bizonylat-szintű hivatkozás keletkezik.)

Egyszeri-végszámla őr. Egy díjbekérőhöz egy végszámla tartozhat. Ha már készült, a rendszer elutasít, és megnevezi a meglévő végszámla számát:

„Ehhez a díjbekérőhöz (…) már készült végszámla (…) – egy díjbekérőből csak egy végszámla állítható ki. Ha módosítani kell, sztornózd a meglévő végszámlát és állíts ki újat.”

Emlékeztető. Ha egy díjbekérőt kifizettek, de nincs hozzá végszámla, ez kiemelt (magas) súlyú teendőként jelenik meg a pénzügyi teendők között: „A(z) … díjbekérőt kifizették – a végszámla kiállítása kötelező.” – egy „Végszámla kiállítása” akcióval.

A díjbekérő → végszámla út a saját úton működik; nem esik a saját út korlátai alá.

10.5 Csomag- és darabkorlátok

10.6 Korlátok a saját úton – amit tudnod kell

• A díjbekérő PDF-je letölthető, és e-mailben is kiküldhető. A kép a saját sablonnal készül, a sorszáma alatt kimondja, hogy nem számla, a záradéka pedig megadja a bankszámlát és a közleményt. Adatszolgáltatás továbbra sem tartozik hozzá.
• A díjbekérő nem törölhető. A rendszer válasza: „A saját (NAV-közvetlen) számlázáson kiállított díjbekérő törlése még nem érhető el. A díjbekérő nem számla, adatszolgáltatás nem tartozik hozzá – ha mégsem lesz belőle üzlet, egyszerűen hagyd figyelmen kívül, vagy jelezd a vevőnek, hogy visszavontad.” Következmény: a saját úton kiállított díjbekérő véglegesen „kiállítva” állapotban marad, a visszavonásának nincs rendszerbeli nyoma. A díjbekérő megerősítő kártyájának lábszövege ezért törlést nem is ígér.
• A díjbekérő nem sztornózható és nem helyesbíthető. A sztornó kifejezetten elutasítja („Ez egy díjbekérő – azt nem sztornózni, hanem törölni kell.”), a helyesbítő pedig csak kiállított számlára megy.
• Technikai megjegyzés: a díjbekérő adatbázis-sorára is rákerül egy NAV-műveletjelölés (CREATE), holott NAV-művelet nem tartozik hozzá. Ez tárolási melléktermék, nem funkció – a díjbekérőről semmilyen adat nem megy a NAV-hoz.

10.7 A te teendőid

• Fizetés után a díjbekérőből végszámlát kell kiállítani. Ez már NAV-adatszolgáltatással járó, kötelező lépés; a rendszer emlékeztet rá.
• Meghiúsult üzletnél nincs teendőd a rendszerben: a díjbekérőt nem kell (és a saját úton nem is lehet) törölni; elég a vevőt értesíteni a visszavonásról.

Szabály: a DIJB előtag rögzített – a felhasználó nem tudja megváltoztatni, és a díjbekérő-tartomány így mindig elkülönül a számla-tartománytól.

11. Nyugta

A saját (NAV-közvetlen) úton a titkár.ai nyugtát nem állít ki. Ez nem átmeneti üzemzavar és nem beállítás kérdése: a nyugta-funkció a programban ezen az úton nincs kiépítve.

11.1 Miért nem

A nyugta a számlától két ponton is elkülönül, és mindkettő önálló fejlesztést kíván:

• Elkülönített sorszámtartomány. A 23/2014. (VI. 30.) NGM rendelet 8. § (5) bekezdése szerint a nyugta sorszámozásának a számláétól elkülönített, önmagában folyamatos tartományból kell kiosztódnia. A program sorszám-kiosztója elvben tud több tartományt kezelni – a tartományt a (felhasználó, előtag, év) hármas jelöli ki, és a kiosztás atomi, kihagyás és ismétlés nélküli (8. § (1) a)) –, de a saját úton ma mindössze két előtag van kiosztva: a számláé (TITKAR) és a díjbekérőé (DIJB) – egyik sem állítható át a felületről (8.8). Nyugta-tartomány nincs.
• Külön adatszolgáltatás. A nyugta adatszolgáltatása nem az Online Számla manageInvoice útján megy. A programmal előállított (nem e-pénztárgépes) nyugta a papírnyugtával egyenértékű, adatszolgáltatása 2026. szeptember 1-jétől napi összesítésben, adómértékenkénti bontásban, 3 naptári napon belül teljesítendő (Áfa tv. 257/G. § és 11. számú melléklet B) rész). E-nyugtát kizárólag e-pénztárgéppel lehet kiállítani (8/2025. (III. 31.) NGM rendelet). A titkár.ai egyik csatornát sem szolgálja ki: a NAV-beküldő rétegben a művelet-készlet CREATE | MODIFY | STORNO | ANNUL, nyugta nem szerepel benne.

11.2 Mit tapasztalsz a felületen

Ha nyugtát kérsz, az asszisztens nem készít vázlatot és nem kér megerősítést, hanem azonnal ezt válaszolja:

„A saját (NAV-közvetlen) számlázáson a nyugta még nem érhető el – a nyugta külön sorszámtartományt és külön adatszolgáltatást kíván. Készpénzes vevőnek addig is állíthatsz ki rendes számlát (fizetési mód: készpénz).”

A korlát mind a négy nyugta-műveletnél ugyanígy, ugyanezzel a mondattal áll:

A korlát a szándék jelzésekor lép életbe, nem a megerősítés után: nem fordulhat elő, hogy végigviszel egy nyugta-vázlatot, rákattintasz a kiállításra, és csak ott derül ki, hogy nem megy.

11.3 Nincs mire visszaesni

A program szándékosan nem épít külső szolgáltató-kapcsolatot, és soha nem esik vissza rá: ha a nyugta itt nem érhető el, akkor sehol – a felület ezt mondja ki, nem kerülő utat ajánl.

11.4 Korlátok – kimondva

• A saját úton nyugta nem állítható ki, nem kérdezhető le, nem küldhető e-mailben és nem sztornózható.
• Ez akkor is így van, ha korábban, a külső szolgáltatós időszakban voltak nyugtáid: a lekérdezés is elakad a korlátnál, tehát a régi nyugták adatai a saját úton nem jelennek meg.
• A programban nincs nyugta-sorszámtartomány és nincs nyugta-adatszolgáltatás – sem a NAV KOBAK-felületére, sem e-pénztárgép felé.

11.5 A te teendőd

• Készpénzes vevőnél állíts ki rendes számlát, készpénz fizetési móddal. A program a „készpénz”, „keszpenz” és „cash” alakot egyaránt a NAV CASH fizetési módjára képezi.
• Ha az adott ügylethez jogszabály szerint valóban nyugta kell (és nem számla), azt a titkár.ai-n kívül – pénztárgéppel vagy más nyugtaadási megoldással – kell megoldanod.
• Figyelem, 2026. szeptember 1-től: a kézi (nyugtatömbös) és a számítógéppel előállított nyugtákról is adatot kell szolgáltatni a NAV-nak (a kibocsátást követő 3 naptári napon belül, napi összesítésben, adómértékenként – a NAV KOBAK-felületén vagy gépi úton). Ez a kötelezettség a titkár.ai-n kívül kiállított nyugtáidra vonatkozik, és nem ennek a programnak a funkciója – az online és e-pénztárgépek automatikusan teljesítik, a kézi nyugtatömbnél magadnak kell.

A titkár.ai nem nyugtaadási program a 23/2014. NGM rendelet 2. §-a értelmében: nyugta kiállítására szolgáló funkciója nincs, és ilyen funkciót a fejlesztési terv sem irányoz elő. A 10. § (2) szerinti funkciólista (21. fejezet) ennek megfelelően nyugta- funkciót nem tartalmaz.

12. Ismétlődő és tömeges kiállítás

Sem az ismétlődő, sem a tömeges kiállítás nem külön kiállítási út. Mindkettő ugyanazt a vázlat → megerősítés → kiállítás láncot használja, mint az egyedi számla, tehát ugyanazok a sorszám-kiosztási, NAV-adatszolgáltatási és tranzakciós szabályok vonatkoznak rájuk (7. fejezet). A különbség csak az, hogy mi indítja el a láncot: egy ütemezés vagy egy köteg.

12.1 Ismétlődő számlázás

Csomag-feltétel. Az ismétlődő ütemezés létrehozása és módosítása a Pro és az Ultra csomag funkciója – Free csomagban a rendszer már az ütemezés felvételét elutasítja, magyar mondattal. Az esedékes bizonylat automatikus (megerősítés nélküli) kiállítása ezen felül Ultra csomagot kíván.

Egy ismétlődő ütemezés a következőket rögzíti: címke, vevő, tételek, pénznem, bizonylattípus (számla vagy díjbekérő), és a hónap napja, amikor esedékessé válik.

Két üzemmód van:

• Kézi megerősítéssel (alapértelmezés). Az automatikus futás nem nyúl az ütemezéshez. Amikor esedékessé válik, a program jelzi neked, és te indítod el a kiállítást – a megerősítő kártyáról vagy külön kéréssel.
• Automatikus kiállítás. Napi egyszeri automatikus futás állítja ki az esedékes bizonylatokat.

Az automatikus mód három, egymástól független feltételt kíván. Bármelyik hiánya azt jelenti, hogy a kiállítás nem történik meg:

Az automatikus kapcsolót az asszisztens nem tudja bekapcsolni. Ha megkéred rá, a kérés az ütemezés módosításából kikerül: a kapcsolást kizárólag a felületen, a kártya gombjával, a védett útvonalon lehet elvégezni. Ez szándékos védelem – így egy beszélgetésbe csempészett utasítás sem tud automatikus, emberi jóváhagyás nélküli számlázást bekapcsolni. Kikapcsoláskor a felhatalmazás törlődik: újbóli bekapcsoláskor ismét azonosítókulcsos igazolás kell.

Korlát, kimondva: az azonosítókulcsos igazolás egyszer, a bekapcsoláskor történik. Az automatikus futás nem kér kiállításonként friss megerősítést, és a felhatalmazás korát sem vizsgálja: az egyszer megadott felhatalmazás határidő nélkül érvényes marad, amíg ki nem kapcsolod. A Beállítások → Biztonság alatt bekapcsolt „megerősítés azonosítókulccsal” beállítás erre az útra nem terjed ki (5.5).

Ha egy automatikus kiállítás elhasal, nincs néma bukás: a hiba magyar mondatként az ütemezés sorára kerül (legfeljebb 500 karakter), és a kártyán olvasható.

12.2 Tömeges kiállítás

Két, egymástól elkülönülő eset van:

A folyamat mindkét esetben ugyanaz: először előnézet készül, ami kizárólag olvasás – semmit nem ír, semmit nem állít ki, tetszőleges alkalommal megismételhető. A tényleges kiállítást a kártya „Mind kiállítása” gombja indítja.

A kötegre a következő korlátok és védelmek élnek:

12.3 Közös biztonsági korlátok

Minden kiállítási út – egyedi, tömeges és automatikus ismétlődő egyaránt – ugyanazon a két kemény korláton megy át: egy számla bruttó összegplafonja és a napi darabszám-kvóta (atomi számlálóval, tehát párhuzamos kérésekkel sem kerülhető meg). A beállítások leírása a 24.2 pontban.

Az azonosítókulcsos megerősítés (step-up) viszont nem közös: az az egyedi és a tömeges kiállításon fut, az automatikus ismétlődő kiállításon nem (5.5 és 12.1).

A blokkolt kiállítás magyar mondattal utasít el, és a Beállítások → Biztonság menüpontra utal. A blokkolt kiállítás nem oszt sorszámot, és nem hagy nyomot (8.6): a vázlat ilyenkor visszaáll megerősítésre váró (vagy hibás) állapotba, az újrapróbálkozás veszélytelen, és a napi kvótából lefoglalt hely is visszakerül.

Tömeges kiállításnál a NAV-adatszolgáltatás bizonylatonként külön előjegyzés, és a beküldés a tranzakció lezárása után, bizonylatonként fut.

12.4 Korlátok – kimondva

• Az ismétlődő ütemezés a hónap 29., 30. és 31. napjára nem állítható be.
• Egy ütemezés = egy vevő + egy rögzített tétel-pillanatkép. A rendszer az összeget nem indexálja, nem inflálja és nem arányosítja (nincs időarányos részszámlázás): a mentett tételek és vevőadatok változatlanul mennek ki.
• Tömeges kiállításnál minden bizonylat egysoros. Több tételsoros számlát a tömeges úton nem lehet készíteni – arra az egyedi kiállítás való.
• A tömeges és az ismétlődő út a saját úton is ugyanabból az egyetlen, folyamatos sorszámtartományból oszt, mint az egyedi kiállítás. Köteg-külön tartomány nincs.
• A tömeges és az automatikus ismétlődő úton nem fut a szokatlan összegre figyelmeztető ellenőrzés (9.11) – ezeken az utakon nincs emberi szem a kártyán, amelyik a figyelmeztetést elolvasná.
• Automatikus módban a NAV-beküldés hibája nem jelenik meg az ütemezés hibamezőjében: a kiállítás ilyenkor sikeres volt, a beküldés pedig külön csatornán (újrapróbálkozó sor és külön jelzés) él tovább.

12.5 A te teendőd

• Automatikus ismétlődő kiállításhoz: Ultra csomag, a kártyán az automatikus módra kapcsolás, és azonosítókulcsos igazolás. Ha kikapcsolod, újbóli bekapcsoláskor ismét igazolnod kell magad.
• Ha egy köteg tételei a havi keret miatt maradtak ki: vagy csomagot váltasz, vagy a következő hónapban állítod ki őket. A kimaradt tételekről soronkénti visszajelzést kapsz.

A napi automatikus futás 06:15 UTC-kor indul — magyar idő szerint reggel 7:15-kor (nyáron 8:15-kor) —, az esedékességet pedig a program a magyar naptári nap szerint számítja: a hónap választott napján reggel készül el a bizonylat.

13. Módosítás és érvénytelenítés

A saját (NAV-közvetlen) úton érvénytelenítés (sztornó) és helyesbítő (módosító) okirat is elérhető. Ez a fejezet előbb a mögöttes lánc-modellt írja le, mert mindkét okirat helyessége ezen áll vagy bukik, majd a sztornó és a helyesbítés folyamatát, végül a korlátok pontos határát.

13.1 A lánc-modell

A NAV-nál a bizonylatlánc az adószámhoz kötődik, nem a programhoz. Ezért a program a láncot a gyökér-bizonylat sorszámával azonosítja, nem belső azonosítóval – elvben így egy másik programmal kiállított számla is sztornózható lenne innen (a gyakorlati korlátról lásd a 13.6 pontot).

Két lánc-szintű számlálót a programnak kell nyilvántartania, mert a NAV mindkettőt tőlünk várja:

A kiosztás egyetlen atomi adatbázis-művelet, a bizonylat rögzítésének tranzakcióján belül: a sorzár sorosítja a párhuzamos kéréseket, a visszagörgetés pedig a léptetést is visszavonja.

A NAV ezen felül elvárja, hogy egy gyökérre egyszerre csak egy okirat legyen úton. Ezt a program nem külön nyilvántartással biztosítja – nincs „úton lévő okirat” jelölés a láncon –, hanem két, közvetett módon: (a) a lánc-számlálók kiosztása adatbázis-sorzárral sorosítja a párhuzamos kéréseket, és (b) az érvénytelenítés az eredeti számla állapotát atomi összehasonlítás-és-írással billenti át, tehát két egyidejű sztornó közül a második elakad („Ezt a számlát időközben már sztornózták”).

A program nem tippel. Ha egy gyökérhez nincs felvett lánc, a kiosztó nem talál ki számlálókat, hanem elutasít:

„Ehhez a számlához (…) még nincs felvett számlalánc – külső gyökérnél előbb a NAV-ból kell szinkronizálni, tippelni tilos.”

Saját kiállításnál a lánc a számlával egy tranzakcióban jön létre: a következő módosítási index 1, a következő tételsor-hivatkozás pedig a számla tételszáma + 1. Az újbóli felvétel nem nullázza a számlálókat.

Külső gyökér felvételekor a következő szabad tételsor-index a NAV lánc-kivonatából számolódik: a létrehozó (CREATE) elem legmagasabb tételszáma és az összes újonnan létrehozott tétel-intervallum végének maximuma + 1. A „legmagasabb tételszám” önmagában félrevezető lenne, mert az az adott dokumentum saját számozása (az interfész-specifikáció 1.8.3 pontja külön figyelmeztet erre).

Sikeres sztornó után a lánc lezárt állapotba kerül.

13.2 A sztornó folyamata

1. Kérés. Megmondod, melyik számlát kell sztornózni.
2. Megerősítő kártya. A program megmutatja, mit fog tenni, és a te kattintásodra indul. (Gyakorisági korlát: 10 sztornó / perc; a korlát-ellenőrzés kiesésekor is zár.)
3. Előfeltétel-ellenőrzés. Lásd 13.3.
4. Tükör felépítése. A sztornó okirat tartalma a lánc jelenlegi állapotának teljes, ellentétes előjelű tükre.
5. Rögzítés egy tranzakcióban. Új, önálló sorszám a folyamatos tartományból; az eredeti számla kiállított → sztornózott állapotra vált; a lánc lezárul; a NAV-adatszolgáltatás előjegyződik; a művelet pedig bekerül az audit-naplóba.
6. Beküldés. A NAV-adatszolgáltatás a tranzakció lezárása után indul, és ha elakad, az újrapróbálkozó sor viszi tovább.

13.3 Előfeltételek

• Az eredeti számla adatszolgáltatásának le kell zárulnia (done). Amíg nem, a program ezt mondja: „Az eredeti számla NAV-adatszolgáltatása még nem zárult le (DONE) – a sztornót csak utána lehet beküldeni. Próbáld pár perc múlva.” Ez a NAV sorrend-szabályából következik: lánc-okirat csak a gyökér elfogadása után mehet.
• Kell eltárolt, elfogadott adatszolgáltatás. Ha nincs: „Ehhez a számlához nincs eltárolt NAV-adatszolgáltatás – a sztornóhoz előbb az eredeti beküldésének kell rendben lennie.”
• A számla nem lehet már sztornózott. Az állapotváltás atomi összehasonlítás-és-írás, tehát két egyidejű sztornó közül a második ezt kapja: „Ezt a számlát időközben már sztornózták.”

13.4 Mi kerül a sztornóba, és mit lát a NAV

A sztornó okirat forrása nem a belső tételtábla, hanem a NAV által elfogadott, eltárolt számlaadat-XML, visszaolvasva. Ennek oka gyakorlati: a belső tételtáblában nincs mentességi jogcím, nincs termékkód és nincs előlegbeszámítási adat – azokból hiánytalan tükör nem építhető.

A tükör szabályai:

• A lánc nettó-hatásos tételsorai szerepelnek benne negálva, folytatólagos lánc-indexszel. A nettó-hatásos halmaz a lánc tényleges, érvényben lévő tételsorait jelenti: ha egy korábbi helyesbítő okirat a lánc addigi sorait pontosan kioltotta és újraközölte, a kioltott párok nem szerepelnek újra – a sztornó így akkor is kicsi marad, ha a számlát többször helyesbítették. Idegen szerkezetű okiratnál a program a teljes tételtörténetet negálja (a régi, bizonyítottan összeg-helyes viselkedés).
• Az előjelfordítás szöveges (a mínuszjel billentése), ezért a tükörben semmilyen kerekítés nem történik; fillérre pontos. A nulla előjeltelen marad.
• A mennyiség fordul, az egységár pozitív marad (interfész-specifikáció 2.5.1).
• A tételsor-művelet a 3.21-es interfész óta kizárólag létrehozás (CREATE) lehet – ezt a program típusszinten kényszeríti ki.
• A fejadat hatályosítva megy ki: a lánc későbbi okirataiban közölt blokkok felülírják a gyökérét (teljes újraközlés szabálya). A vevő adata a láncból öröklődik, nem a mai partnertörzsből – így az utólag átírt partneradat nem ír felül egy már jelentett bizonylatot.
• A teljesítési dátum a lánc aktuális dátuma. Nincs „a teljesítés nem eshet a kelte napjára” kényszer: az aznapi sztornó legitim.

A NAV felé a következők mennek:

A program a beküldés előtt elutasítja a hibás okiratot, magyar mondattal: létrehozó számlán nem lehet hivatkozás; módosító/sztornó okirat hivatkozás nélkül nem állítható ki; sztornó tételsor nélkül nem állítható ki; a módosító okirat sorszáma nem egyezhet a módosítottéval; a modificationIndex 1 és 1000 közötti egész szám; módosító okiratnál minden tételsornak hivatkoznia kell. A tükrözés maga is véd: a lánc első eleme nem lehet módosító okirat (módosító okiratot sztornózni tilos – a sztornó mindig a gyökérre hivatkozik), idegen gyökérre mutató láncelemet és tételsor nélküli láncot a program elutasít.

A sztornó okirat a nyilvántartásban önálló számlasor: saját, a folyamatos tartományból kiosztott sorszámmal, negatív végösszegekkel, és a lánc-hivatkozás mezőivel.

13.5 Helyesbítő (módosító) okirat

A saját úton a helyesbítő számla elérhető. A helyesbítő a hibás adatot sztornó nélkül javítja: a számla él tovább, a NAV pedig MODIFY műveletű módosító okiratot kap, amely a különbözetet rögzíti. Ugyanaz a számla többször is helyesbíthető – minden okirat a lánc mindenkori (a korábbi helyesbítésekkel együtt értett) állapotát javítja a kért végállapotra, hézagmentes modificationIndex-szel.

A folyamat és a garanciák:

• Te a számla ÚJ, TELJES és HELYES tételsorát adod meg (nem a különbözetet). A különbözetet a program képezi, a NAV által elfogadott, eltárolt számlaadat-XML-ekből – nem a te számításodból és nem a nyelvi modellből.
• Az okirat szerkezete: a lánc nettó-hatásos tételsorai negálva + a helyes sorok pozitívan, egy okiratban. A nettó-hatásos redukció miatt az okirat mérete a sokadik helyesbítésnél is állandó marad (nem nő a lánc hosszával).
• Ha csak a fejadat változik (teljesítési dátum, fizetési határidő, fizetési mód), a program tételsor nélküli, áfakulcsonként nullás összesítőjű fejadat-módosítót küld – a tételsorok érintetlenül maradnak.
• Ha a vázlat semmiben nem tér el a számla mostani állapotától, a kiállítás megáll: „nincs mit helyesbíteni”.
• A fejadat (vevő, teljesítés, fizetési adatok) a láncból öröklődik; csak az változik, amit kifejezetten módosítasz.
• A pénznem nem helyesbíthető – ahhoz sztornó és új számla kell. Egyszerűsített vagy gyűjtő típusú gyökér-számlát a program nem helyesbít (a szerkezetük eltér), ott is a sztornó a járható út.
• Helyesbítő vagy sztornó okirat önmagában nem helyesbíthető – a javítást mindig az eredeti (gyökér-)számlán kell kérni; a hibaüzenet meg is nevezi azt.
• A megerősítés ugyanúgy a kártyán történik, mint a kiállításnál és a sztornónál; a NAV-adatszolgáltatás automatikus.

A módosítás–érvénytelenítés körében ez a helyzet:

A nem elérhető funkciók teljes listája – az indoklással és a járható alternatívával – a 26.1 pontban áll.

13.6 Korlátok – kimondva

• Technikai érvénytelenítést (manageAnnulment) a program nem küld be. Az adatszolgáltatás-nyilvántartásban létezik ilyen művelettípus, de a beküldő ág szándékosan elutasítja, és az újrapróbálkozó sor is kihagyja (18.9).
• NAV-adatszolgáltatásból importált (nem itt kiállított) számla innen nem sztornózható és nem helyesbíthető – ezekről csak a NAV összesítő adatai állnak rendelkezésre.
• Csak a saját úton kiállított számla sztornózható/helyesbíthető a saját úton. Külső vagy migrált gyökér láncának NAV-ból való felvételére nincs eljárás a programban: a külső bizonylatot a kapuk már a szándék jelzésekor elutasítják, felvett lánc nélkül pedig a kiosztó is elutasít.
• Egy gyökéren egyszerre csak egy okirat lehet úton. Amíg egy helyesbítő vagy sztornó NAV-visszaigazolása nem érkezett meg, a következő okirat (újabb helyesbítő vagy sztornó) nem indítható – a program ezt a szándék jelzésekor mondja meg.
• A sztornó nem vonható vissza. A lánc állapota egyirányú: nyitott → lezárt. A lánc újranyitására nincs funkció.
• Egyszerűsített és gyűjtőszámla nem helyesbíthető (a helyesbítő okirat más szerkezetű bizonylat lenne) – sztornó + új számla a járható út; a sztornójuk viszont működik (9.13).
• Előlegszámla és végszámla TÉTELEI nem helyesbíthetők – az előleg-jelölés és a beszámítási hivatkozás veszne el az újraközölt sorokról. A fejadat-helyesbítés (dátum, fizetési mód) ezeken is elérhető (9.13).
• Ha az okirat NAV-beküldése elhasal, a helyi állapot már megváltozott (sztornónál az eredeti számla sztornózott, a lánc lezárt; helyesbítőnél az okirat-sor létrejött). Ilyenkor nem a kiállítást kell megismételni, hanem a beküldést – ezt az újrapróbálkozó sor automatikusan viszi, illetve kézzel is indítható.
• A NAV által tartalmilag elutasított (aborted) adatszolgáltatás újraküldését a program szándékosan megtagadja: az elutasított tartalom változatlan újraküldése ugyanazt az elutasítást hozná. Elutasított lánc-okiratnál (helyesbítő/sztornó) a program a helyi állapotot magától rendezi: az okirat számla-sora „törölt” állapotra vált, a lánc-számlálók visszaállnak (nem marad végleges hézag a modificationIndex-ben), sztornónál pedig az eredeti számla és a lánc is visszaáll élőre – a művelet a hiba javítása után újra kérhető. Elutasított létrehozó (CREATE) adatszolgáltatásnál a járható út változatlanul a sztornó + új, helyes számla.
• A lánc-nyilvántartásban létezik egy összeg-állapot mező, de a program sehol nem írja és nem olvassa: a lánc pénzügyi állapotát mindig az eltárolt, NAV-nak jelentett XML-ekből számoljuk.

13.7 A te teendőd

• Hibás számlánál válaszd meg a javítás útját: ha csak egy adat hibás (összeg, tétel, dátum), kérj helyesbítő számlát – a számla él tovább, a NAV a különbözetet kapja. Ha az egész számla érvénytelen, sztornózz, és állítsd ki újra a helyes adatokkal.
• Okirat (sztornó/helyesbítő) előtt meg kell várni az eredeti számla NAV-visszaigazolását. A program szól, ha még nem érkezett meg.
• Elakadt beküldésnél kérdezd le az adatszolgáltatás állapotát, és ha átmeneti hiba volt, indítsd újra. Ha a NAV elutasította (aborted): létrehozó számlánál sztornózz és állíts ki új, helyes bizonylatot; lánc-okiratnál a program a helyi állapotot magától rendezi, és a művelet a hiba javítása után újra kérhető (13.6).

A megerősítő kártya szövege pontosan ezt a sorrendet mondja. A sztornó kártyáján ez áll:

„A sztornó végleges, és a NAV-adatszolgáltatás azonnal indul. A számla helyett egy érvénytelenítő bizonylat keletkezik – ez a hibás számla javításának szabályos, NAV által elfogadott folyamata.”

A „megindul” és nem a „megtörtént” a helyes állítás: a beküldés a bizonylat létrejötte után, külön lépésben megy ki, és az adatszolgáltatás a NAV visszaigazolásával teljesül (7.6, 16.3). A kártya ezen a ponton tehát a folyamatban lévő lépést jelzi, nem befejezett tényt állít – a tényleges állapotot az adatszolgáltatás lekérdezésével látod (16.8). Ez a magyar felület megerősítés előtti mondatára igaz; a sztornózás közbeni és utáni feliratok, valamint az angol felület továbbra is befejezett tényként fogalmaznak – a korlátot a 7.6 pont mondja ki.

Korlát, kimondva: a külső számlázós időszakból származó számla a saját úton nem sztornózható – az érvénytelenítést abban a rendszerben (vagy a NAV Online Számla felületén) kell intézni, amelyben a számla keletkezett (1.4).

14. Áfa, kerekítés, deviza

14.1 Az áfa-elbánás nem puszta százalék

A NAV adatszolgáltatásában az áfa-elbánás hét, egymást kizáró ág egyike. A program mindegyiket ismeri az adatszolgáltatás előállításánál:

14.2 Elfogadott áfakulcsok

A NAV normál (és gyűjtő-) számlán a következő kulcsokat fogadja el: 0%, 5%, 7%, 12%, 18%, 27%. Az adatszolgáltatásban a program mindig tizedes törtként adja meg őket (27 → 0.27).

Ha nem elfogadott kulcsot adsz meg, a program a kiállítás előtt elutasít:

„A ${százalék}%-os áfakulcsot a NAV nem fogadja el belföldi számlán. Elfogadott kulcsok: 0%, 5%, 7%, 12%, 18%, 27% – vagy adómentes jogcím (pl. AAM, TAM).”

A program belső áfa-modulja ennél sokkal több (36) numerikus kulcsot ismer (19, 20, 21, 23, 25,5, 5,5 stb.), de azok külföldi áfakulcsok, és a NAV egyiket sem fogadja el. Ezért a saját úton a szűkebb halmaz az irányadó.

14.3 Mentességi és hatályon kívüli jogcímek

Kétértelmű kódot a program nem tippel meg, hanem visszakérdez. Az EUT, EUKT, EU, EUK, MAA, K.AFA és AKK kódnál ezt kapod:

„A(z) „…” áfakód nem képezhető le egyértelmű NAV-jogcímre – pontosítsd a tétel jogcímét (pl. EUFAD37 / EUE / KBAET / HO), vagy különbözeti adózásnál add meg a séma fajtáját.”

14.4 Determinisztikus áfa-ellenőrzések a beküldés előtt

A 2025. szeptember 15-e óta szigorúbb NAV-validáció blokkoló hibáinak megelőzésére a program a beküldés előtt maga ellenőrzi, és magyar mondattal utasít el:

• Mentes vagy hatályon kívüli tételnél az áfa összege csak nulla lehet.
• Egyszerűsített számlán áfatartalom kell, normál számlán áfakulcs.
• Belföldi fordított adózásnál a vevő csak belföldi adóalany lehet, magyar adószámmal.
• KBAET, EUFAD37 és EUFADE jogcímnél a vevő áfa-státusza csak „egyéb” (közösségi adószámos külföldi) lehet.
• KBAUK jogcímnél a vevő nem lehet belföldi adóalany.

Az áfakulcsonkénti összesítőt a program számolja. A külső számlázós időszakban ezt a szolgáltató végezte; a saját úton ez a mi felelősségünk, és a NAV blokkoló hibával utasítja el az adatszolgáltatást, ha az összesítő nem jön ki a tételekből. A csoportosítás kulcsa nem a százalék, hanem a teljes áfa-elbánás: a 0%-os mentesség és a 0%-os fordított adózás nem ugyanaz a csoport.

14.5 Kerekítés

A „nullától elfelé” nem elméleti finomság: a szokásos programnyelvi kerekítés a plusz végtelen felé kerekít, ezért negatív összegnél rossz eredményt ad (−12 713 464,5 esetén −12 713 464-et a helyes −12 713 465 helyett). Ez sztornó és módosító okiratoknál él, ahol az összegek negatívak – és a NAV által elfogadott referenciákkal való összevetés során ez a hiba 21 számlán okozott 1 filléres eltérést, mielőtt kijavítottuk.

Ha a vázlatban kifejezetten megadsz nettó, áfa vagy bruttó értéket, a program azt tiszteletben tartja, és nem számolja újra. Az összegek végig szövegként utaznak; számolás csak ott történik, ahol elkerülhetetlen (forintosítás, áfakulcsonkénti összesítő).

14.6 Deviza és MNB-árfolyam

A program 29 pénznemet kezel: HUF, EUR, USD, GBP, CHF, AUD, AED, BGN, BRL, CAD, CNY, CZK, DKK, HKD, HRK, ISK, JPY, NOK, NZD, PLN, RON, RSD, RUB, SEK, SGD, THB, TRY, UAH, ZAR. A „Ft” és „FT” alak HUF-ra normalizálódik; ismeretlen kódnál magyar hibaüzenetet kapsz.

Az árfolyam az MNB napi középárfolyama, közvetlenül az MNB webszolgáltatásából. Részletek:

A 100-as és 1000-es egységre jegyzett devizák kezelve vannak. Az MNB a kis értékű devizákat nem 1, hanem 100 vagy 1000 egységre jegyzi (pl. JPY, HUF-ban kifejezve). Az egy egységre jutó árfolyamot ezért osztással kell képezni, és az osztás kettes számrendszerű maradékot hagy: 99,99 / 100 a gépi számábrázolásban 0,9998999999999999. A program ezért az egy egységre jutó árfolyamot 6 tizedesjegyre kerekíti – pontosan annyira, amennyit a NAV InvoiceData sémája elfogad. Így a 100/1000 egységre jegyzett devizák a saját úton ugyanúgy számlázhatók, mint a többi: a kerekítés minden valós középárfolyamot pontosan visszaad.

Az árfolyam-lekérés a bizonylatot rögzítő tranzakción kívül fut: a tranzakcióban csak adatbázis-írás és számolás történik.

A program a beküldés előtt ellenőrzi, hogy a pénznem pontosan három nagybetű, az árfolyam pozitív, HUF-nál az árfolyam kizárólag 1 lehet, és az árfolyamnak legfeljebb 6 tizedesjegye lehet (a NAV sémája ennyit enged). Ugyanez a 6 tizedes korlát él az előlegbeszámítás és a gyűjtőszámla-tétel árfolyamára is.

Devizás számlán minden összeg párban megy ki: az eredeti pénznemben és forintban is. A számlaképen a pénznem mellett az árfolyam is szerepel, ha az nem HUF.

14.7 Korlátok – kimondva

• Az árfolyam a kelte napjára szól, nem a teljesítés napjára. Ha visszamenőleges teljesítési dátumot adsz meg, az árfolyam akkor is az aznapi. (A kelte magyar idő szerinti naptári nap – lásd 8.8.)
• A kimenő számla árfolyama nem külön oszlopban él a számlasoron, hanem az eltárolt NAV-adatszolgáltatás XML-jében és a lánc során – a számlaképre is onnan kerül.
• A saját kiállítási út alapból normál (NORMAL) számlát küld, kifejezett kérésre pedig egyszerűsített (SIMPLIFIED, áfatartalom szerinti) vagy gyűjtőszámlát (AGGREGATE) is – a feltételeket a 9.13 pont írja le. Ebből következően a saját úton nem érhető el a különbözeti adózás (MARGIN) és a NO_VAT besorolás.
• A MARGIN és a NO_VAT ághoz nincs is leképezés a tétel-áfakódról: ilyen kódnál a program elutasít.
• A 0,2 és 0,25 áfakulcs (régi, 2013 előtti teljesítésű számlák sztornója) nincs az engedélylistán. Ez a sztornót nem akadályozza: a sztornó a tükrön át megy, ott az eredeti kulcs öröklődik, nem a leképező futásán.
• A kiállítói alanyi adómentesség jelölése az adatszolgáltatásban technikailag létezik, de a program nem tölti ki: a kiállítói törzsadatot a NAV adószám-lekérdezése adja, ami áfakódot, megyekódot, nevet és címet ad, alanyi mentességi jelölést nem (lásd T-37).

14.8 A te teendőd

• Belföldi számlán ne adj meg külföldi áfakulcsot – a program elutasítja.
• Kétértelmű jogcím-kódnál (EUT, EU, MAA, K.AFA stb.) pontosítanod kell a jogcímet.
• Devizás számlánál, ha az MNB árfolyam-szolgáltatása nem elérhető, a kiállítás nem történik meg. Ez szándékos: hibás (1,0-s) árfolyammal küldött adatszolgáltatás rosszabb, mint a késés.

15. Számlakép és kézbesítés

15.1 Hogyan készül a számlakép

A saját úton a számlaképet a titkár.ai saját, magyar nyelvű PDF-sablonja állítja elő. A NAV saját megjelenítő sablonja nem része a terméknek – a NAV FO-sablonja a lábában kimondja magáról: „Ez a dokumentum a bizonylat adattartalmának standard képi megjelenítése. Ez az dokumentum nem a számla.” Vevőnek kiküldhető számlaképnek tehát alkalmatlan.

A számlakép forrása az eltárolt, NAV-nak jelentett és általa elfogadott számlaadat-XML, visszaolvasva. Ez a legfontosabb tulajdonsága: a kép nem egy második, párhuzamos adatforrásból épül, hanem pontosan abból, amit a NAV-nak jelentettünk – a kettő nem tud szétcsúszni.

Ha egy számlához nincs eltárolt adat, a program nem gyárt „valamilyen” képet, hanem elutasít: „Ehhez a számlához nincs eltárolt számla-adat, a PDF nem állítható elő.” Ha az adat nem olvasható vissza: „A számla eltárolt adata nem olvasható vissza.”

A renderelés determinisztikus, és ez itt korrektségi követelmény, nem kényelmi szempont: nincs futásidejű hálózati letöltés, nincs böngésző-motor, a betűtípusok a programmal együtt szállítottak. (A magyar elválasztás kikapcsolt, mert az alapértelmezett angol mintakészlet hibásan törné a magyar szavakat.)

15.2 Mi látszik a számlaképen

Az Áfa tv. 169. §-a szerinti kötelező adattartalom jelenlétét automatikus ellenőrzőlista-teszt őrzi, nem szemrevételezés: 12 teszt fut a modellre (kelte és sorszám; a kiállító neve, címe, adószáma; a vevő adatai – külön eset a magánszemély vevő pillanatképére; tétel megnevezése, mennyisége, mértékegysége; teljesítés időpontja, adóalap és egységár; adómérték és áthárított adó kulcsonkénti bontásban; mentességi jogcím lábjegyzete; sztornó-hivatkozás; pénznem és árfolyam; sablon-verzió), továbbá 3 renderelési próba: 1 tételes, 40 tételes (többoldalas) és sztornó-változat.

A képen szerepel: a dokumentum címe („Számla”, sztornónál „Sztornó számla”), a sorszám, sztornónál az „Érvénytelenített számla: <gyökér sorszáma>” hivatkozás, a Kiállító és a Vevő blokk (adószám, közösségi adószám, bankszámla), a Kelt / Teljesítés / Fizetési határidő / Fizetési mód / Pénznem (és HUF-tól eltérő pénznemnél az árfolyam), a tételtáblázat (Megnevezés, Mennyiség, Egység, Egységár, Áfa, Nettó, Bruttó), az áfakulcsonkénti összesítő, a „Fizetendő” bruttó összeg, a mentességi jogcímek lábjegyzetei, valamint minden oldalon állandó lábléc (a kiállító neve és adószáma, illetve „<számlaszám> · N/M. oldal”).

A számlaképen NAV-címer és „NAV” felirat szándékosan nem szerepel – a fejlécben a titkár.ai jelölés áll. A PDF metaadataiban a cím a bizonylat típusa és száma, a szerző a kiállító neve, az előállító pedig a titkár.ai a sablon-verzióval.

Magánszemély vevőnél a NAV-nak küldött adatszolgáltatás szándékosan névtelen (Áfa tv. 10. számú melléklet), a számlán viszont a vevő neve és címe kötelező (169. § e)). Ezért ezeknél a bizonylatoknál a név és a cím a számlasor kiállításkori pillanatképéből kerül a képre – és csak akkor, ha az adatszolgáltatásban valóban nincs vevőadat. A pillanatkép azért kell, mert a partnertörzs utólag átírható, a kiállított bizonylat viszont nem.

A pillanatkép nem lehet üres: a program magánszemély vevőnél is megköveteli az irányítószámot és a települést, és enélkül a kiállítás elbukik (9.1). Ezért a saját úton kiállított számla képén a vevő címe mindig szerepel – a 169. § e) szerinti kötelező adat nem hiányozhat róla.

15.3 Mi garantálja, hogy a kép a jelentett adattal azonos

Három, egymást erősítő elem:

1. Közös forrás. A kép és a NAV-adatszolgáltatás ugyanabból az XML-ből származik. Nincs második adatút, amin eltérés keletkezhetne.
2. Sablon-verzió. A sablon verziószámmal azonosított (jelenleg v1), és a verzió ráíródik a bizonylatra. A régi sablon-verziók a programban maradnak, így utólag is előállítható az akkori kép.
3. Lenyomat (pdf_sha256). Az első renderelés SHA-256 lenyomata és a sablon verziója a számlasorra kerül, és későbbi rendereléskor nem íródik felül. Eltérés tehát csak a sablon-verzió tudatos léptetésével keletkezhet.

Ellenőrzéskor ez a két adat (pdf_sha256 és pdf_template_version) a bizonyíték arra, hogy az újragenerált számlakép azonos a kiküldöttel.

15.4 Hozzáférés és kézbesítés

Letöltés. A számlakép a beszélgetésben kapott hivatkozással érhető el. A letöltés bejelentkezett munkamenethez kötött, és a program ellenőrzi, hogy a számla a te fiókodhoz tartozik-e. A fájl nem gyorsítótárazódik.

E-mail. A kiküldés külön, megerősítés-köteles lépés: a kiállítás nem küld ki automatikusan levelet. Előbb előnézetet kapsz (kinek, milyen tárggyal, milyen kísérőszöveggel megy), és a te jóváhagyásodra indul.

Ismétlődés elleni védelem. A levélnek idempotencia-kulcsa van (fiók, számlaszám, címzett és a levél tartalmi ujjlenyomata), így ugyanaz a levél ugyanannak a címzettnek kétszer nem megy ki. A kifejezett újraküldésnél szándékosan nincs kulcs – különben a levélküldő szolgáltatás 24 órán át kiszűrné, és az „Újraküldés” gomb hatástalan lenne.

Kézbesítés-követés. A levélküldő szolgáltatás azonosítója eltárolódik, így a kézbesítés vagy a visszapattanás visszavezethető az adott számlára. E nélkül a küldés utáni lánc vak lenne: egy elgépelt vevői cím némán elnyelődne. Minden kiküldés az audit-naplóba kerül.

Átutalási QR-kód csak a vevőnek szóló levélben, és csak akkor kerül a levélbe, ha minden feltétel teljesül (Pro vagy Ultra csomag, HUF, még nem fizetett számla, megadott bankszámla, engedélyezett szabvány). Bármelyik feltétel hiányában a levél QR nélkül, egyébként változatlanul kimegy. A funkció jelenleg ki van kapcsolva, mert a szabvány regisztrált aggregátort kíván (20.3).

Az adatszolgáltatás nem maga az e-számla. A bizonylat elektronikus megjelenésű jelöléssel megy a NAV felé, és az adatszolgáltatás nem teljes adattartalmú – az adatszolgáltatás és a számla két külön dolog.

15.5 Korlátok – kimondva

• A díjbekérő képe MÁS forrásból épül, mint a számláé. A díjbekérőhöz nem tartozik NAV-adatszolgáltatás, tehát eltárolt XML sincs, amiből a kép épülhetne: a bizonylat a saját nyilvántartás sorából és tételeiből áll össze, a kiállító neve, címe és adószáma pedig a megjelenítéskor, a NAV törzsadatából. A kép a sorszáma alatt ki is mondja: „Nem számla — áfa levonására nem jogosít.”, a záradéka pedig megadja, hova és milyen közleménnyel várjuk az utalást, és hogy a számla a fizetés beérkezése után készül el.
• Díjbekérőhöz nem tárolunk lenyomatot (SHA-256). Az a SZÁMLA képének bizonyítéka — azé, hogy a kép a NAV-nak jelentett tartalommal azonos. A díjbekérő kiállítói blokkja két megjelenítés között jogszerűen is változhat (pl. cégnév-változás), így egy itt tárolt lenyomat csak hamis bizonyosságot adna.
• A PDF-fájlt nem tároljuk. Minden letöltéskor és minden kiküldéskor újragenerálódik; tartósan csak a SHA-256 lenyomat és a sablon-verzió marad meg. A megőrzést tehát nem a fájl, hanem a determinizmus és a lenyomat biztosítja.
• A sablon kizárólag magyar nyelvű. A számlakép minden felirata magyar; idegen nyelvű számlakép a saját úton nincs. A vázlaton beállított nyelv a saját PDF-re nincs hatással.
• A lenyomat írása „legjobb szándékú”: ha az adatbázis-írás elhasal, a hiba elnyelődik, tehát előfordulhat, hogy egy számlához nincs eltárolt lenyomat anélkül, hogy erről értesülnél.
• A számlaképen nincs elektronikus aláírás és nincs időbélyeg. A PDF önmagában nem minősül hitelesített elektronikus dokumentumnak (25.2).
• A számlakép nem jelenít meg: fizetettségi állapotot, szabad szöveges megjegyzést, szállítólevél-hivatkozást és tétel-szintű megjegyzést.
• A NAV-adatszolgáltatásból importált (nem itt kiállított) számlának nincs PDF-je – ezekhez csak a NAV összesítő adatai érhetők el.

15.6 A te teendőd

• A számlaképet bejelentkezett munkamenetből, a beszélgetésben kapott hivatkozással nyisd meg vagy töltsd le.
• A vevőnek küldéshez mentsd el a partner e-mail-címét, vagy add meg a címet a küldéskor. Az előnézeten látod, kinek megy a levél.
• Ellenőrzéskor a pdf_sha256 és a pdf_template_version a bizonyíték arra, hogy az újragenerált számlakép azonos a kiküldöttel.

Korlát, kimondva: a dokumentáció nem állítja, hogy az újragenerált PDF bitre azonos a korábban kiadottal – a PDF-motor frissítése a sablonverzió változása nélkül is megváltoztathatja a bájtokat. Az azonosság bizonyítéka nem az újragenerálás, hanem az első generáláskor eltárolt SHA-256 lenyomat és sablonverzió: a kiküldött példány ezekkel vethető össze, a bizonylat adattartalma pedig a tárolt XML-ből mindenkor igazolható.

(A számlakép előállíthatósága az eltárolt XML megőrzésén múlik; a megőrzési idő kérdését a T-30 tétel tartalmazza – lásd 25.5.)

16. NAV-adatszolgáltatás (13/A. §)

Ez a fejezet a saját, NAV-közvetlen kiállításra vonatkozik: amikor a titkár.ai maga állítja ki a számlát, és maga szolgáltat adatot a NAV Online Számla rendszerébe. A 2026. augusztus 8. előtt, külső számlázón kiállított számlák adatszolgáltatását az a program végezte, és arról az ő dokumentációja szól – az alábbiak azokra nem alkalmazandók.

16.1 Az alapelv: a kiállítás és az adatszolgáltatás két külön lépés

A számla a 8. § (6) szerinti lezáráskor jön létre – nálunk, a saját nyilvántartásban (7.4). A NAV felé menő adatszolgáltatás ettől elváló, aszinkron lépés, és szándékosan nem része a kiállítás adatbázis-tranzakciójának.

A kiállítás egyetlen tranzakcióban rögzíti a sorszámot, a számlát, a tételsorokat, a számlaláncot és az adatszolgáltatási tételt pending (beküldésre vár) állapotban. A NAV-hívás csak ezután, a mentés véglegesítése után indul.

Ez azt jelenti: a NAV kiesése sosem akadályozza meg, hogy számlát állíts ki. A jogszabály is így épül fel – a 13/B. § (3) épp azért ad 24 órát az adatszolgáltatásra az akadály elhárultától, mert a NAV elérhetetlensége nem béníthatja meg a számlázást.

Kiállításkor a NAV-nak szóló InvoiceData XML a tranzakción belül felépül (CREATE művelettel), és szó szerint eltárolódik, a hozzá tartozó SHA3-512 lenyomattal együtt. Ez a tárolt XML később három dolgot szolgál ki: az ismételt beküldést (13/A. § (4)), a számlaképet (PDF) és a 17. fejezet szerinti adóhatósági ellenőrzési adatszolgáltatást (11/A. §).

A díjbekérőhöz nincs adatszolgáltatás, és nem is kell – a díjbekérő nem számla. Díjbekérő kiállításakor sem XML nem képződik, sem adatszolgáltatási tétel nem keletkezik.

16.2 Hogyan történik a beküldés

A tényleges beküldés két NAV-hívásból áll:

1. tokenExchange – a rendszer egyszer használatos beküldési tokent kér a NAV-tól, az XML cserekulcsod segítségével;
2. manageInvoice – a számla adata egy kötegben kimegy a NAV-hoz.

Sikeres átvételkor a tétel submitted állapotba kerül, és eltárolódik a NAV tranzakció-azonosítója (transactionId) és a beküldés időbélyege.

A NAV-hívások időkorlátja 30 másodperc. Hálózati vagy NAV-oldali hiba esetén a hívás nem próbálkozik újra azonnal – a tétel failed állapotba kerül, és a 18. fejezet szerinti újraküldési sor viszi tovább.

16.3 Mikor teljesült az adatszolgáltatás

A beküldés önmagában nem teljesítés. A submitted állapot csak annyit jelent, hogy a NAV átvette a köteget. A 13/A. § (3) szerint az adatszolgáltatás kizárólag a NAV sikeres visszaigazolásával teljesül – ezért a rendszer a beküldött tételek feldolgozási állapotát végállapotig lekérdezi (queryTransactionStatus).

A NAV válaszában:

• RECEIVED, PROCESSING, SAVED – a feldolgozás még folyamatban van, ez nem végállapot;
• DONE – a NAV feldolgozta és visszaigazolta: ekkor teljesült az adatszolgáltatás;
• ABORTED – a NAV a feldolgozást megszakította: az adatszolgáltatás nem teljesült.

A DONE-on belül a rendszer még egy megkülönböztetést tesz (a NAV interfész-specifikációjának megfelelően): teljesített az az adatszolgáltatás, amelyre invoiceStatus = DONE; üzletileg helyes pedig az, amelynél emellett a válasz nem tartalmaz üzleti validációs üzenetet.

A DONE + figyelmeztetés eset jogilag teljesített adatszolgáltatás, de a 13/A. § (5) szerint javítandó tartalomra utal. Ezt a rendszer külön mezőben tartja nyilván (nem hibaként), és megmutatja, ha rákérdezel. Érdemes komolyan venni: 2025. szeptember 15-én épp az évekig figyelmen kívül hagyott figyelmeztetésekből lettek blokkoló hibák.

Blokkoló szintnek a rendszer az ERROR és a CRITICAL üzeneteket tekinti (a technikai üzenetek CRITICAL/ERROR, az üzletiek ERROR/WARN/INFO szintűek lehetnek – mindkét blokkoló szintet kezeli).

16.4 Az adatszolgáltatás állapotai

A sending a kétszeres beküldés elleni védelem. A beküldést atomi foglalás előzi meg: a tétel pending/failed állapotból sending-be kerül, és onnantól sem a kiállítás utáni azonnali beküldés, sem az újraküldési sor nem nyúl hozzá. Enélkül ugyanaz a számla kétszer mehetne ki, a másodikra kapott INVOICE_NUMBER_NOT_UNIQUE pedig hamis „elutasítva” állapotot írna egy valójában teljesült adatszolgáltatásra. Ha a küldés úgy szakad félbe, hogy nem tudjuk, eljutott-e a NAV-hoz – a válasz időtúllépésbe fut vagy a kapcsolat megszakad, illetve a NAV már visszaigazolta, de a saját mentésünk hasal el –, a tétel sending-ben marad. Ilyenkor újraküldeni tilos: a beküldés lehet, hogy megtörtént, és a második ugyanarról a számláról duplikált adatszolgáltatás lenne. 30 perc után a rendszer a NAV-ot kérdezi meg a bizonylat lánc-kivonatával, hogy bement-e: ha a NAV ismeri, a tétel done lesz (a nyugtát vesztettük el, nem az adatszolgáltatást), ha nem ismeri, failed, azaz vissza az újraküldési sorba. Ha maga a lekérdezés hibázik, a tétel marad sending-ben: bizonytalanságból nem írunk állapotot, és a 4 órás kontroll-sáv teendő (18.4) felszínre hozza.

Bizonylatonként egyetlen adatszolgáltatási tétel keletkezik, a bizonylat létrejöttekor. Az ismételt beküldés (13/A. § (4)) ugyanezt a tételt frissíti: nő a kísérletszám, és felülíródik az állapot, a NAV tranzakció-azonosítója és a hibaüzenet.

Korlát, kimondva: a korábbi kísérletek részletei – az időpontjuk, a saját tranzakció-azonosítójuk és a hibaüzenetük – nem őrződnek meg. A nyilvántartás a kísérletek darabszámát és a legutolsó kísérlet eredményét tartja. A sztornó okirat ettől függetlenül saját, önálló adatszolgáltatási tételt kap, mert önálló számlaként keletkezik.

16.5 Sztornó – ugyanez az út, egy sorrendi feltétellel

A sztornó okirat önálló számla, saját sorszámmal, STORNO művelettel és saját adatszolgáltatási tétellel – ugyanazon az úton megy, mint egy rendes számla.

Sorrendi kényszer: a rendszer csak akkor engedi a sztornót, ha az eredeti számla adatszolgáltatása már done állapotban van. Ha még nincs, ezt a mondatot kapod:

„Az eredeti számla NAV-adatszolgáltatása még nem zárult le (DONE) – a sztornót csak utána lehet beküldeni. Próbáld pár perc múlva.”

Ez nem kényelmetlenség, hanem a lánc-modell követelménye: a módosító okirat csak lezárt gyökérre hivatkozhat (13.1).

16.6 A kiállítói (eladó) törzsadat forrása

A számlára és az adatszolgáltatásba kerülő kiállítói adatokat – áfakód, megyekód, hivatalos név és cím – a rendszer a NAV saját nyilvántartásából kérdezi le (queryTaxpayer a saját adószámodra), nem a mi adatbázisunkból. Így garantáltan az az érték megy vissza, amit a NAV elvár. Kizárólag a bankszámlaszám származik a te beállításodból (6.8).

Sikeres lekérdezéskor a rendszer pillanatképet ment a törzsadatról, és NAV-kiesés esetén ebből építi fel a kiállítói blokkot.

A cím nem lehet hiányos. A NAV sémája a kiállító irányítószámát és települését kötelezővé teszi, ezért ha a queryTaxpayer válaszában nincs használható székhelycím, a rendszer a korábbi pillanatképet használja; ha az sincs, a kiállítás megáll, magyar üzenettel – hiányos címmel ugyanis olyan adatszolgáltatás menne ki, amit a NAV már a beküldéskor visszautasít. Több cím (telephely, fióktelep) esetén a székhely kerül a számlára.

Korlát, kimondva (vállalt döntés): ha a törzsadat sem élőben nem érhető el, sem pillanatkép nincs róla, a számla kiállítása meghiúsul. Ez kizárólag a legelső saját kiállítást érintheti, ha épp NAV-üzemzavar van: az első sikeres lekérdezés után a pillanatkép átveszi a szerepet, és a NAV kiesése a további kiállítást nem akadályozza (13/B. §). A rendszer kézi cégadat-megadást szándékosan nem kínál – a kiállítói adatok egyetlen forrása a NAV nyilvántartása, így hibás kézi törzsadat nem kerülhet számlára.

16.7 Előfeltételek – mi kell a saját úthoz

A saját számlázásra váltás megtagadott, amíg a NAV technikai felhasználó nincs bekötve és az XML cserekulcs nincs megadva; a NAV-fiókban ezen felül a „Számlák kezelése” jog is kell, hiányában a beküldés FORBIDDEN hibával elakad. A bekötés lépéseit, a pontos hibaüzeneteket és a kulcsok titkosított tárolását a 6. fejezet írja le.

A technikai felhasználó adatai és a cserekulcs titkosítva (AES-256-GCM) tárolódnak, kizárólag szerveroldalon fejtődnek vissza, és soha nem kerülnek az AI-modellhez vagy a böngésződbe.

16.8 Hogyan ellenőrzöd, hogy rendben van-e minden

Három eszközöd van, mindegyik minden csomagban elérhető, előfizetéstől függetlenül:

1. Áttekintés – kérdezd a chatben: „Rendben elmentek-e a számláim a NAV-hoz?” A válasz a saját úton kiállított számláidra megadja a visszaigazolt (done), az úton lévő, az elutasított és a sikertelen beküldések darabszámát, valamint a figyelmeztetéssel elfogadottakét – a problémás tételeknél magyar mondattal. Az áttekintés adatai determinisztikusak: a darabszámokat és a problémás tételek magyar mondatait a szerver számolja a saját nyilvántartásból, nem a nyelvi modell. A modell erre a kimenetre kötelező szabályt kap – elutasított vagy sikertelen beküldés mellett nem adhat megnyugtató választ –, de ez a szabály a modell viselkedését köti, nem egy kimenet-szűrő kapu. Ezért mindig a számláló és a felsorolt számlaszám a döntő adat: ha az „elutasított” vagy a „sikertelen” mezőben nem nulla áll, az adatszolgáltatás nincs rendben – függetlenül attól, mit mond a kísérőszöveg.
2. Egy konkrét számla sorsa – „Mi történt a TITKAR-2026-12 számla NAV-adatszolgáltatásával?” Megkapod az állapotot magyar címkével, a kísérletszámot, a NAV tranzakció-azonosítóját, a hibaüzenetet vagy figyelmeztetést, és azt, hogy a tétel újrapróbálható-e.
3. A Pénzügyi teendők sáv (kontroll-sáv) – az elakadt adatszolgáltatás magától megjelenik itt, magas súllyal, a legrégebbi érintett számla számával és egy „Megnézem, mi akadt el” gombbal. Részletek a 18.4 pontban.

Ha olyan számláról kérdezel, amelyet nem a saját úton állítottunk ki, a rendszer nem hallgat és nem tagad: kimondja, hogy annak az adatszolgáltatását a külső számlázó végezte.

16.9 Amit ez a funkció nem tud – korlátok kimondva

• A kiállítás eredménye a számlaszám – az adatszolgáltatás státusza ettől elválik. A kiállítás utáni kártyán a számlaszám alatt élő státusz-sor fut („adatszolgáltatás folyamatban” → „a NAV elfogadta”), amely a saját nyilvántartásunkat kérdezi 5 másodpercenként, legfeljebb 2 percen át; a NAV-ot közben a szerver kérdezi (utókövetés + a 15 perces futás). Éles NAV-nál a visszaigazolás jellemzően másodpercek, tehát a végállapot rendszerint még a kártyán megjelenik. Ez a sor viszont nem garancia: ha a feldolgozás elhúzódik (a teszt-környezetben ez a jellemző), a sor őszintén „folyamatban”-t mond, és a figyelést a szerver viszi tovább. A díjbekérőn nincs ilyen sor (nincs adatszolgáltatása). A tudomásszerzés további útja: rákérdezés (16.8), vagy a kontroll-sáv jelzése, ami 4 óra elteltével jelenik meg. A 4 óra a rendszer saját, vállalt jelzési küszöbe, nem jogszabályi határidő – a kiállítás akkor is sikeres, ha a NAV nem elérhető, és a rendszer 4 órán belül szól, ha az adatszolgáltatás elakadt.
• Nincs nyugta a saját úton. Készpénzes vevőnek rendes számlát tudsz kiállítani (fizetési mód: készpénz).
• Nincs technikai érvénytelenítés (manageAnnulment) – lásd részletesen a 18.9 pontban.

17. Adóhatósági ellenőrzési adatszolgáltatás (11/A. §)

Ez a funkció nem azonos a 16. fejezet szerinti NAV-adatszolgáltatással. A 13/A. § szerinti adatszolgáltatás a számla kiállításakor, automatikusan megy a NAV-hoz. Az adóhatósági ellenőrzési adatszolgáltatás (a rendelet 11/A. §-a) ezzel szemben az az adat-kiadás, amelyet adóhatósági ellenőrzés esetén te kérsz le és adsz át – a rendelet a számlázó programtól megköveteli, hogy erre képes legyen.

17.1 A funkció neve és indítása

A funkciót a jogszabályi nevén találod meg. A 23/2014. (VI. 30.) NGM rendelet 8. § (1) c) pontja „adóhatósági ellenőrzési adatszolgáltatás” elnevezésű funkciót ír elő, és a program a felhasználói felületen végig ezen a néven hivatkozik rá:

A letöltés technikai címe (az az útvonal, amelyre a kártya gombja mutat) továbbra is /api/adatexport. Ez gépi cím, nem felhasználói megnevezés: a böngésző címsorában látszik, de a funkció neve a felületen mindenhol a fenti, jogszabályi megnevezés. Ellenőrzéskor tehát ezen a néven kell keresned – és ezen a néven is találod meg.

Ugyanez a technikai szó egyetlen hibaüzenetben maradt meg: ha a két szűrőt egyszerre adod meg, a rendszer az „Az adatexport vagy DÁTUM-tartományra, vagy SORSZÁM-tartományra szól…” mondattal utasít el (17.2). Ez a szó egyébként maga is a rendelet fogalma (2. § 5. pont), és a funkció megnevezését nem érinti.

A funkció önállóan, bármikor indítható, és nincs rajta csomag-kapu – sem a chatben, sem a letöltő útvonalon. Ez tudatos döntés: jogszabályi kötelezettség teljesítése nem függhet előfizetéstől. Free csomagban ugyanúgy elérhető, mint Ultrában.

Két úton indítható:

• A chatben: „NAV-ellenőrzésre kell az adatszolgáltatás 2026-01-01 – 2026-06-30-ra.” A rendszer előbb lefuttatja a szűrést (hány számla, mi maradt ki), és csak utána ad letöltési linket.
• Közvetlen letöltéssel: a /api/adatexport útvonalon, bejelentkezve, ugyanazokkal a szűrő-paraméterekkel (from, to, fromNumber, toNumber).

Maga az XML soha nem megy át az AI-modellen – a modell csak a szűrést futtatja le és a linket adja; a fájlt a szerver állítja elő közvetlenül a saját nyilvántartásból (NAV-hívás nélkül).

Az export a saját kibocsátású számlákra szól. A 11/A. § szerinti kötelezettség a kibocsátáshoz tapad: az itt kiállított számlákra ez a program adja ki az adatszolgáltatást. A 2026. augusztus 8. előtt, külső számlázó programban kibocsátott bizonylatok nincsenek benne az exportban – azokat a számláidat ténylegesen kibocsátó programból kell lekérned.

17.2 A két szűrő – dátum VAGY sorszám

A rendelet két intervallum-típust nevesít, és a rendszer is ennek megfelelően kizárólagosan kezeli őket:

A kettő egyszerre nem adható meg. Ha mégis megpróbálod:

„Az adatexport vagy DÁTUM-tartományra, vagy SORSZÁM-tartományra szól – a kettő egyszerre nem adható meg.”

A dátum-szűrő a bizonylat KELTÉJÉRE megy, és nem a rekord létrejöttének időbélyegére. A kelte a számla önálló adatmezőjében (invoices.issue_date) tárolódik, magyar idő szerinti naptári napként – ugyanaz az érték, ami a számlaképre és a NAV-nak jelentett invoiceIssueDate mezőbe kerül. Ez nem formaság: a rekord időbélyege UTC, és a kettő a nap két végén eltérhet; egy időzóna-eltolás miatt kimaradt számla az ellenőrzésre átadott adatszolgáltatást tenné hiányossá.

Mindkét nap benne van az exportban: dátum-oszlopon a szűrés egyszerű, mindkét végén inkluzív összehasonlítás, tehát a kezdő és a záró napon kiállított számla is bekerül.

A sorszám-tartomány nem szöveges összehasonlítás. A sorszám nincs nullákkal feltöltve (TITKAR-2026-9, TITKAR-2026-10), ezért a betűrendes összevetés hamis eredményt adna – egy ellenőrzésre átadott export csendben hiányos lenne. A rendszer a sorszámot (év, sorszám) párra bontja, és numerikusan dönt a tartományról, évhatáron át is (8.7).

A sorszám-szűrő ellenőrzései és magyar üzenetei:

17.3 Mi kerül az exportba és mi nem

Bekerül: kizárólag a saját (NAV-közvetlen) úton, ezzel a programmal kibocsátott valódi számla – a sztornó okirat is, mert az önálló számlaként keletkezik.

Nem kerül bele – és ezt fontos tudnod ellenőrzéskor:

Az export hatálya tehát nem időbeli, hanem forrás-alapú: azok a számlák kerülnek bele, amelyeket ez a program bocsátott ki. Ha a NAV ellenőrzése a korábbi, külső számlázós időszakra is kiterjed, azt az akkori programból kell beszerezned. Ez a forrás-alapú hatály végleges – a program a saját kibocsátású számláiért felel, a más rendszerben kibocsátottakért az a rendszer.

17.4 A dokumentum forrása és szerkezete

A forrás a beküldéskor eltárolt InvoiceData XML, nem a számlasor összegei. Így az export bizonyíthatóan ugyanaz az adat, amelyet a NAV-nak jelentettünk.

Egy kivétel van, és ez jogilag szükséges: a magánszemély vevő nevét és címét a rendszer visszateszi. A NAV-nak beküldött adatszolgáltatásból ezek tiltottak (Áfa tv. 10. számú melléklet), az adóhatósági ellenőrzési adatszolgáltatásból viszont kötelezők – a tárolt XML puszta újrajátszása tehát jogilag hibás, hiányos exportot adna. A pótlás a számlasor kiállításkori pillanatképéből történik (vevőnév, irányítószám, város, cím és a cím országkódja; a rögzített országkód nélküli, korábbi bizonylatoknál az országkód belföldi, HU), és a dokumentum export-célú jelölést kap.

A pótlás forrása garantáltan kitöltött: a kiállítás magánszemély vevőnél is megköveteli az irányítószámot és a települést (9.1), ezért a pillanatkép nem lehet cím nélküli – a vevő címe így az adatszolgáltatásban is ott van.

Az adószámos vevő adataihoz a rendszer nem nyúl: ott a tárolt, jelentett adat a hiteles, nem a később átírható partner-nyilvántartás.

A dokumentum szerkezete: egy XML-prológ, egy csoportosító <invoices> gyökérelem, alatta önálló, teljes InvoiceData elemek – az invoiceData.xsd szerkezetében (a rendelet 2. § 5. pontja szerint ez elfogadott adatexport-szerkezet).

Egy számla csak egyszer szerepelhet az exportban – az ellenőrzésre adott exportban egy kétszer szereplő számla ugyanolyan hiba, mint egy hiányzó. Ez a mai működésből egyébként is következik: bizonylatonként egyetlen adatszolgáltatási tétel keletkezik (16.4). Az egyszeres szerepeltetést az export ezen felül, védelmi jelleggel is kikényszeríti.

Letöltéskor a fájl application/xml; charset=utf-8 típusú, adohatosagi-ellenorzesi-adatszolgaltatas_<tartomány>.xml néven, és nem kerül gyorsítótárba. A fájlnév maga is a jogszabályi funkció-megnevezést viszi: az ellenőrzésre átadott fájlnak magának is meg kell mondania, mi az.

17.5 A kimaradt számlák – a rendszer nem hallgat a hiányról

Ha egy kibocsátott számlához nincs eltárolt adat, vagy az nem olvasható vissza, a számla nem tűnik el csendben: bekerül a „kimaradt” listába magyar mondattal:

„TITKAR-2026-12: nincs eltárolt számla-adat, ezért kimaradt az exportból.” „TITKAR-2026-13: az eltárolt számla-adat nem olvasható vissza.” „TITKAR-2026-14: az eltárolt számla-adatból nem állt össze érvényes export-dokumentum (…).”

Egy elakadt bizonylat nem viszi el az egész exportot: a dokumentumok számlánként épülnek fel, és ha egyikük hibára fut, csak az kerül a kimaradt listába – a fájl a többi számlával elkészül. Az ellenőrzésre kért exportnak akkor is meg kell születnie, ha egy régi bizonylat adata hiányos.

A kártya ezt figyelmeztető sávban, nem elrejtve mutatja, a darabszámmal együtt. A kártya akkor is megjelenik, ha egyetlen számla sem esik a szűrőre – az „egy számla sem esik ide” ugyanolyan érvényes válasz egy adóhatósági kérésre, mint maga a fájl.

A te teendőd: ellenőrzés előtt mindig nézd meg a kimaradt listát, és a benne szereplő számlákat külön dokumentáld.

17.6 Korlátok – kimondva

• Nincs futásidejű XSD-validáció az export-úton. Az XML-ek NAV-sémakészlet elleni ellenőrzése fejlesztői eszközben fut (ahol a 345 korpusz- és 29 példatár-XML mind érvényesnek bizonyult), de a letöltött fájl nem megy át séma-ellenőrzésen a kiadás pillanatában.
• Nincs darabszám- vagy méretkorlát és nincs lapozás. A teljes találati halmaz egyetlen válaszban épül fel; nagyon nagy állománynál ez korlátot jelenthet.

18. Hibakezelés és üzemzavar (13/A. § (4)–(7), 13/B. § (3))

18.1 Az elv

Az adatszolgáltatás elmaradása számlánként akár 1 millió forint mulasztási bírsággal járhat, és ez a bírság téged, az adózót terheli. Ezért a rendszer két dolgot csinál következetesen: amit gépi úton meg lehet oldani, azt magától megoldja; amit nem, arról kimondottan szól, és soha nem nyugtat meg tévesen.

18.2 Amit a rendszer magától csinál

Automatikus futás 15 percenként (*/15 * * * *), fiókonként elkülönített hibakezeléssel – egy fiók hibája nem állítja meg a többiét. A futás három dolgot tesz, ebben a sorrendben:

A sorrend nem véletlen: ami a tisztázásból failed-be kerül, azt még ugyanabban a futásban újraküldjük; ami done-ba, azt soha többé.

Türelmi idő: 2 perc. A 2 percnél frissebb tételekhez a futás nem nyúl – azokat a kiállítás utáni azonnali beküldés még kézben tartja.

Napi egyeztetés a NAV nyilvántartásával (nav-digest, minden hajnalban 4:40-kor): a rendszer visszakérdezi a NAV-tól, mely számlák szerepelnek NÁLUK az elmúlt 34 napból, és összeveti azzal, amit kiállítottunk. Ez a beküldési naplótól független ellenőrzés: a 15 perces futás a saját feljegyzésünket olvassa vissza, tehát vak arra az esetre, amikor beküldési tétel létre sem jött, vagy done-t mutat, de a bizonylat a NAV-nál mégsem szerepel. Az egyeztetés a 6 óránál frissebb számlákat nem kéri számon (a beküldés és a NAV indexelése is telik), az eltérést pedig kétfelé bontja: amit a saját naplónk is jelez, azt a meglévő teendő fedi, amit csak az egyeztetés talál meg, arról külön, magas súlyú kontroll-sáv teendőt kapsz („A NAV nem ismer egy kiállított számlát”).

Ha maga az egyeztetés marad el, arról is szólunk. Ha az ellenőrzés két napja nem futott le, vagy hibára futott, a kontroll-sávban külön teendő jelenik meg – a hallgatás ugyanis nem bizonyíték: nem azt jelenti, hogy nincs eltérés, hanem hogy jelenleg nem ellenőrzi senki.

18.3 Amit a rendszer szándékosan nem próbál újra

Ez nem hiányosság, hanem védelem:

• submitted tétel – már van tranzakció-azonosítója, az adatszolgáltatás a NAV-nál van. Az újraküldés duplikált adatszolgáltatás lenne: a NAV vagy INVOICE_NUMBER_NOT_UNIQUE hibával utasítaná el, vagy – rosszabb esetben – kétszer venné nyilvántartásba.
• aborted tétel – ez a NAV tartalmi elutasítása. Ugyanazt az adatot újraküldeni sosem vezet eredményre; javítani kell (lásd 18.6).
• sending tétel – azt épp egy futó küldés foglalja. Vakon újraküldeni duplikált adatszolgáltatás lenne, vakon ott hagyni pedig elmaradt adatszolgáltatás – ezért itt sem tippel a rendszer, hanem a NAV-ot kérdezi meg (16.4).
• Technikai érvénytelenítési (ANNUL) tétel – az nem ezen az úton megy (lásd 18.9).

18.4 A 24 órás határidő őrzése és a jelzések

A 4 órás küszöb tudatosan korán szól, hogy maradjon időd intézkedni. Ez a rendszer saját küszöbe, nem jogszabályi határidő. A kontroll-sáv két, eltérő természetű esetet jelöl:

Elutasított: „N számla adatszolgáltatását a NAV elutasította (SZÁMLASZÁM) – ez magától nem rendeződik, a hibás adatot javítani kell.”

Elakadt: „N számla adatszolgáltatása még nem ért célba (SZÁMLASZÁM) – a rendszer újrapróbálja, de ha az akadály nálad van (pl. a NAV-kulcsok), azt neked kell rendezni. Üzemzavar esetén a jogszabály az akadály elhárultától 24 órát ad.”

Mellette egy „Megnézem, mi akadt el” gomb, amely a legrégebbi érintett számlára kérdez rá.

A 24 óra nem általános türelmi idő. Az adatszolgáltatást a 13/A. § (1) szerint a kiállításkor, azonnal kell teljesíteni. A 13/B. § (3) szerinti 24 óra kizárólag akkor él, ha a NAV rendszere üzemzavar, karbantartás vagy az internetszolgáltatás elégtelensége miatt nem érhető el. Ha a beküldés a te NAV-beállításod hibája miatt akadt el – hiányzó vagy rossz XML cserekulcs, hiányzó „Számlák kezelése” jog (FORBIDDEN), lejárt jelszó –, a késedelem az első perctől mulasztásnak minősül, és a 24 órára nem hivatkozhatsz. Ilyenkor a beállítást azonnal rendezned kell (18.6).

A kontroll-sáv üzenete ezt a két esetet szétválasztja. Az „elakadt” mondat előbb a saját oldali akadályt nevezi meg (például a NAV-kulcsokat) mint olyat, amit neked kell rendezned, és a 13/B. § (3) szerinti 24 órát kizárólag az üzemzavarhoz, az akadály elhárultától köti. A felületi szöveg így nem sugallja azt, hogy egy saját beállítási hibánál is „van még 24 órád”.

Korlát, kimondva: a 20 órás riasztás az üzemeltetőnek szól, nem neked – a felületen és e-mailben a 20. óránál nem kapsz külön értesítést. A te jelzésed a 4 órás kontroll-sáv teendő és a napi összefoglaló e-mail (ha az állapot változott).

18.5 A NAV hibakódjai magyarul

88 NAV validációs hibakódhoz tartozik saját, cselekvésre hívó magyar mondat (forrás: a NAV interfész-specifikáció 3.0, 2026.02.12, 3.2–3.3 fejezet). Ismeretlen kódnál a rendszer a NAV hivatalos üzenetére, végső esetben magára a kódra esik vissza – kitalált magyarázatot sosem ad.

A hibaüzenet két külön mezőben áll:

• hiba (blokkoló): „A NAV elutasította az adatszolgáltatást: …”
• figyelmeztetés: „A NAV elfogadta, de figyelmeztetéssel: …”

Néhány jellemző eset:

Korlát, kimondva: a SCHEMA_VIOLATION üzenete azt ígéri, hogy „a beküldés automatikusan megismétlődik”. Ez az ígéret a jelenlegi működéssel nem tartható: a séma-sértés aborted állapotot eredményez, azt viszont a rendszer szándékosan nem küldi újra. Ilyen esetben az üzemeltető beavatkozása szükséges – jelezd az info@titkar.ai címen.

18.6 Mit kell tenned – állapotonként

Kézi újraküldés a chatből. A rendszer determinisztikus kapukkal védi ezt a műveletet – nem az AI dönti el, mikor mehet:

A művelet fiókra szűrt: más fiók adatszolgáltatását a nevedben elindítani nem lehet.

18.7 Ha a hiba 3 munkanapon belül nem hárul el – manuális teljesítés (13/A. § (6)–(7))

Ez a pont akkor lép életbe, amikor a programon belüli utak kimerültek: tartósan failed beküldés, aborted (a NAV tartalmilag elutasította) tétel, vagy olyan hiba, amelyet a program nem tud elhárítani (például a technikai érvénytelenítés hiánya – lásd 18.9).

A 13/A. § (7) nem lehetőség, hanem kötelezettség: ha a hibát az észlelésétől számított 3 munkanapon belül nem sikerül elhárítani, az adatszolgáltatást a hiba elhárultáig manuálisan kell teljesítened – az onlineszamla.nav.gov.hu felületén, a számla kézi rögzítésével, számlánként. Ez nem választható alternatíva, és a programon belüli újraküldés nem váltja ki. A titkár.ai ezt nem tudja helyetted elvégezni: a kézi rögzítés a te NAV-fiókodban, a te közreműködéseddel történik.

A megismételt adatszolgáltatást jóvá is kell hagynod. A 13/A. § (5) szerint az ismételt adatszolgáltatást a NAV rendszerében jóvá kell hagyni; ez szintén a NAV Online Számla felületén, a te feladatod.

A te teendőd sorrendben:

1. Nézd meg, mi az elakadás oka (16.8). Ha a saját NAV-beállításod hibás, rendezd – utána az újraküldés magától megy (18.6).
2. Ha a NAV tartalmilag utasította el (aborted), sztornózd a számlát, és állítsd ki újra a helyes adatokkal (13.7).
3. Ha a hiba az észleléstől számított 3 munkanapon belül nem hárul el, kezdd meg a manuális teljesítést a NAV felületén, és hagyd jóvá az ott rögzített adatszolgáltatást.
4. Jelezd nekünk az info@titkar.ai címen – a tartós elakadás üzemeltetői beavatkozást is igényelhet.

Korlát, kimondva: a programban nincs külön felület a 3 munkanapos határidő követésére: a rendszer nem számolja a munkanapokat, és nem küld erről külön figyelmeztetést. A 4 órás kontroll-sáv teendő és a napi összefoglaló e-mail jelzi, hogy egy adatszolgáltatás elakadt – a határidő figyelése innentől rád tartozik. Külön munkanap-számláló és figyelmeztetés nem épül – a kötelezettség kimondása és a meglévő jelzések (kontroll-sáv, napi összefoglaló) adják a támogatást.

18.8 Ha a titkár.ai nem érhető el

A 18.1–18.6 pont a NAV oldali kiesést kezeli. Ez a pont a saját (szolgáltatói) kiesésről szól: amikor a titkár.ai maga nem elérhető.

A program online szolgáltatás: offline mód nincs, és a Szolgáltató rendelkezésre állási (SLA) vállalást nem tesz (3.6 és 28.2). Ezért ez nem elméleti kockázat.

Ha a szolgáltatás kiesése alatt számlaadási kötelezettséged keletkezik, azt a titkár.ai-n kívül kell teljesítened: kézi (nyomtatvány) számlával, a saját, elkülönített kézi sorszámtartományodból. A kézi számla adatszolgáltatását a NAV Online Számla felületén, kézzel kell megtenned, a kézi számlára irányadó jogszabályi határidőn belül.

A kézi számla adatszolgáltatási határideje az Áfa tv. 10. számú mellékletének 2–3. pontja szerint: a kibocsátást követő négy naptári napon belül; ha a számlában áthárított adó összege eléri vagy meghaladja az 500 000 forintot, a kibocsátást követő naptári napon belül. (Forrás: Áfa tv. 10. melléklet; a NAV tájékoztatói ugyanezt mondják ki.) Ugyanez a határidő vonatkozik a kézi számlát módosító vagy érvénytelenítő okiratra is, az abban szereplő áthárított adó előjeltől független összege szerint.

A kiesés utáni visszatéréskor a kézi számlát NE rögzítsd újra a titkár.ai-ban. Ez két dolgot okozna: második adatszolgáltatást ugyanarról az ügyletről, és sorszám-ütközést a program saját tartományával. A kézi számla a kézi tartományodban marad, és a NAV-nál is ott van.

18.9 További korlátok – kimondva

• Nincs technikai érvénytelenítés (manageAnnulment). A rendszer ismeri az ANNUL műveletet, az érvénytelenítési kódot és indoklást, de a NAV felé nem küldi be – a beküldés ilyenkor hibával leáll („Technikai érvénytelenítést ez az út nem küld be”). Következmény: az INVOICE_NUMBER_NOT_UNIQUE, MULTIPLE_INVOICES_FOUND és MULTIPLE_QUERY_RESULT_FOUND hibáknál a hibaüzenet által javasolt út (érvénytelenítés + jóváhagyás) a termékből nem indítható – ezt a NAV Online Számla felületén, kézzel kell elvégezned. A NAV-felületi kézi érvénytelenítés lépésről lépésre leírása nem e dokumentum tárgya – a korlát kimondása és a NAV Online Számla felületére irányítás a vállalt tájékoztatás.
• Nincs növekvő várakozási idő és nincs kísérlet-plafon. A failed tételt a rendszer 15 percenként, korlátlanul újrapróbálja, amíg sikerül, vagy amíg valaki kézzel el nem rendezi.
• A 13/A. § (7) szerinti 3 munkanapos határidőnek nincs külön felülete. A programon belül a javítás útja a helyesbítő számla (13.5) vagy a sztornó + újra kiállítás; ha a hiba 3 munkanapon belül nem hárul el, a manuális teljesítés kötelezettségét a 18.7 pont írja le.
• A done + figyelmeztetés esetnek nincs proaktív jelzése. A figyelmeztetés eltárolódik, és megjelenik, ha rákérdezel az áttekintésre – de nem generál kontroll-sáv teendőt, és nem küld róla e-mailt. (A kiállított és a NAV által visszaigazolt számlák napi egyeztetése ettől függetlenül fut – lásd 18.2 –, de az a HIÁNYZÓ bizonylatot keresi, nem a figyelmeztetést.)
• A napi egyeztetés a NAV lekérdezésének korlátain belül dolgozik. Az ablak 34 nap (a NAV egy lekérdezésben legfeljebb 35 napot enged), tehát az ennél régebbi eltérést nem találja meg, és a számlaszám azonosságán túl nem veti össze a bizonylat tartalmát a NAV-nál tárolttal.
• Az INFO szintű NAV-üzenet nem jelenik meg figyelmeztetésként. A rendszer a blokkoló (ERROR, CRITICAL) és a figyelmeztető (WARN) szintet emeli ki; az INFO a beküldési naplóban eltárolódik, de nem kerül külön mezőbe.
• A státusz-lekérdezés hibái nem jutnak el hozzád: azok a szerver naplójába kerülnek. A tétel ilyenkor submitted marad, és a 4 órás kontroll-sáv teendő fogja meg.

19. Nyilvántartás, listák, riportok

19.1 Mit tart nyilván a rendszer

A kiállításkori vevő-pillanatkép nem kényelmi másolat. Két helyen ez az egyetlen forrás: a számlaképen (Áfa tv. 169. § e)) és a 11/A. § szerinti adóhatósági ellenőrzési adatszolgáltatásban – mert magánszemély vevőnél a NAV-nak beküldött XML-ből mindkettő tiltott, a partner-nyilvántartás pedig utólag átírható, ezért nem hiteles. A pillanatkép ezért nem lehet hiányos: a kiállítás magánszemély vevőnél is megköveteli az irányítószámot és a települést (9.1).

A beküldött XML megőrzésének három indoka: a 13/A. § (4) szerinti ismételt beküldésnek ugyanazt az adatot kell vinnie; a normalizált soraiból a visszafejtés veszteséges lenne; és a 11/A. § szerinti adóhatósági ellenőrzési adatszolgáltatás is ebből szolgál ki.

A tevékenységnapló neked is elérhető („Mi történt a fiókomban?”), időszakra szűrhetően. Ez bizalmi funkció, ezért szándékosan nincs csomag-kapuzva – minden felhasználó teljes, ellenőrizhető választ kap. A napló sorait a szerver fordítja magyar mondatokra, nem az AI-modell.

19.2 Listák

A vevő neve a mentett partner nevéből jön; ha nincs partner-kapcsolat, a kiállításkori vevőnév-pillanatképre esik vissza.

19.3 Riportok és csomagkorlátok

Két elv minden riportra érvényes:

• A rendszer különböző pénznemeket soha nem ad össze – minden összesítés pénznemenkénti bontásban áll.
• A NAV-ból importált számlák fizetettsége ismeretlen, ezért a kintlévőség-összesítések csak az itt kiállított számlákat számolják.

Az áfa-összegzés kizárólag tájékoztató: a hivatalos bevallás a könyvelőd és a NAV feladata, mert nem minden tétel áfája vonható le.

19.4 A számlakép megőrzése

A saját úton a PDF forrása szintén az eltárolt, NAV-nak beküldött XML, és az első renderelés SHA-256 lenyomata a számlasorra kerül – a részleteket a 15.1–15.3 pont írja le.

Korlát: a PDF nem tárolódik el bináris formában – minden letöltéskor újra készül. A lenyomat az azonosság bizonyítéka, nem archívum. Ha archív példányra van szükséged, töltsd le és őrizd meg (25.3).

19.5 További korlátok – kimondva

• A tevékenységnapló nem tartalmazza a NAV-adatszolgáltatás eseményeit. A kiállítás és a sztornó bekerül, a beküldés és a NAV visszaigazolása nem – az adatszolgáltatás nyilvántartása kizárólag a beküldési napló (19.1), amelyet a 16.8 pont szerinti kérdésekkel érsz el. Kimondva: az adatszolgáltatás 13/A. § szerinti nyilvántartása a beküldési napló – a tevékenységnapló nem bővül beküldési eseményekkel.
• A számlalista nem mutatja az adatszolgáltatás állapotát. A listaelemek a kiállítás útját és a forrást hordozzák, beküldés-státuszt nem – arra külön kell rákérdezni (16.8).
• A saját úton kiállított számlához nincs külső számlázó-felület: a bizonylat kizárólag itt, a saját nyilvántartásban él (a felület ilyenkor a külső hivatkozást el is rejti).
• A bevétel-idősor legfeljebb 60 időszak-pontot tölt fel hézagmentesen.
• Megőrzési idő: a rendszerben jelenleg nincs adatmegőrzési vagy automatikus törlési szabály, a fiók törlésekor viszont a számlák és a beküldési napló is törlődik. A megőrzés teljes képét és a nyitott döntést a 25. fejezet (és a T-30 tétel) tartalmazza.

20. Fizetettség és fizetési emlékeztetők

Elhatárolás: az e fejezetben leírtak nem számlázási funkciók a 23/2014. (VI. 30.) NGM rendelet 10. § (2) bekezdése értelmében. A fizetettség nyilvántartása és a fizetési emlékeztetők a saját üzletviteledet szolgálják: nem érintik a számla tartalmát, nem kerülnek a NAV-adatszolgáltatásba, és nem befolyásolják annak állapotát. A teljesség kedvéért írjuk le, hogy a dokumentáció a program teljes működését lefedje.

20.1 Fizetettség rögzítése

Mit lehet kifizetettnek jelölni: kizárólag élő (kiállított), valódi számlát. A díjbekérő, a nyugta és a sztornózott vagy törölt bizonylat nem jelölhető kifizetettnek – ez inkonzisztens adatot eredményezne.

A fizetés napja. Ahol a valódi napot megadod (befizetés rögzítése dátummal, vagy banki jóváírás), az kerül be; egyébként a rögzítés napja a közelítés. Visszavonáskor a dátum is törlődik, hogy egy tévesen bejelölt számla ne rontsa a vevő fizetési morál-statisztikáját.

Minden fizetettség-rögzítés naplózódik a tevékenységnaplóban.

Megerősítés-kötelezettség. A chatben az AI nem rögzít fizetettséget magától: csak előnézet-kártyát készít, amelyet a „Rögzítem” gombbal te véglegesítesz. Ez igaz a teljes kiegyenlítésre, a részösszeg rögzítésére és a tömeges jelölésre is. A visszavonás ezzel szemben kártya nélkül, azonnal megtörténik – befelé ható és visszafordítható művelet (22.3).

Nincs külső fizetési főkönyv: a befizetés kizárólag a helyi nyilvántartásba kerül, és a napló ezt őszintén rögzíti is. A napló ellenőrzési nyom, nem marketingszöveg. A helyi „kifizetve” jelölés teljes kiegyenlítésnél billen át; a részfizetést az audit-napló őrzi.

Banki párosítás (Ultra): banki jóváírás számlához párosítása után a rendszer fedezettségnél magától átbillenti a fizetettséget, és a tevékenységnaplóban „Banki utalás számlához párosítva” bejegyzésként jelenik meg.

Fizetési morál forrás-jelzéssel: a kintlévőség-öregedés riport a lassan fizető vevőknél megjelöli, honnan van az adat – banki jóváírás napjából (pontos), vagy a saját rögzítésekből (közelítés: ha csak utólag jelölöd be a számlákat, a csúszás nagyobbnak látszik a valósnál). A rendszer előírja, hogy ezt a korlátot a válaszban is ki kell mondani.

20.2 Fizetési emlékeztetők – a behajtási létra

A 7 napos minimum-szünet arra való, hogy ha későn kapcsolod be az automatát (a számla már régen lejárt), a vevő ne kapjon két levelet két nap alatt.

Az automata hétköznap 7:00-kor fut.

Kiket céloz az automata: kiállított, valódi, kifizetetlen számlát, amelynek van fizetési határideje, és a vevőhöz van mentett e-mail-cím.

Az automata kikapcsolt állapotból indul, és kétszeresen védett:

• Csak Pro csomagtól felfelé működik. A kapcsoló beállítása a fiókban marad csomag-visszaesésnél is, ezért az automata futása is ellenőrzi a csomagot – enélkül egy visszaesett fiók nevében menne tovább vevői levelezés.
• A bekapcsolás megerősítés-köteles: az AI nem kapcsolja be, csak megerősítő kártyát mutat, és a „Bekapcsolom” gomb hívja a védett beállítási útvonalat. Így egy beszúrt utasítás (prompt injection) nem tudja csendben elindítani a kifelé menő levelezést. A kikapcsolás azonnali.

További védelmek:

• Fizetési ígéret némítja az automatát. Ha rögzítetted, melyik napon fizet a vevő, addig (az ígért napot is beleértve) nem megy levél. Ha az ígért nap fizetés nélkül telik el, a lánc ott folytatódik, ahol abbamaradt.
• Friss fizetettség-ellenőrzés közvetlenül a küldés előtt – a futás kezdete óta lehet, hogy a vevő fizetett.
• Duplázás-védelem: egy napon belüli kétszeri futás nem küld két levelet, és a fokozat-váltás sem keveri össze a küldéseket.
• Minden kiküldés naplózódik (fokozattal és a késedelmi napokkal), és a kézbesítés is rögzül.

Kézi emlékeztető és felszólítás. A chatben előnézetet kérhetsz egy számlára vagy az összes lejárt számlára. Az AI-eszközök e-mailt nem küldenek – a küldést a kártya gombja indítja a munkamenettel védett útvonalon, így a modell sosem küld magától. A kézi küldés feltételei (ugyanazok az előnézetre és a küldésre): valódi, kiállított, kifizetetlen számla, már lejárt határidővel (legalább 1 nap), címzettel és fizetési határidővel – mindegyik hiányra külön magyar üzenettel.

Élő fizetési ígéret esetén a kézi küldés nincs tiltva, de a kártyán látszik az ígért nap – te beszéltél a vevővel, nem a rendszer.

Fizetési ígéret rögzítése. Ez az egyetlen olyan írás a chatben, amely megerősítő kártya nélkül elhallgattatja a behajtást – ezért aszimmetrikus a kapu: a törlés azonnali (biztonságos irány), a rögzítés viszont legfeljebb 60 nappal előre engedélyezett (elgépelés- és injection-védelemként; a mögöttes réteg 365 napos korlátja a második háló). Az eszköz kifejezetten tiltja, hogy partner-megjegyzésben, számlán vagy bizonylat szövegében talált „a vevő megígérte…” alapján hívja meg – az adat, nem utasítás.

A késedelmi kamat determinisztikus számítás (Ptk. 6:155. §), a felszólító levél szövege fix sablon – egyik sem az AI-modell kimenete. Devizás számlánál vagy 2023 előtti késedelemnél a levél kamat-sor nélkül megy.

20.3 Korlátok – kimondva

• Emlékeztető csak mentett vevő-e-mail-címre megy. Cím nélkül a számla kimarad; a tömeges előnézet ezt darabszámmal ki is mondja („Van N lejárt, kifizetetlen számlád, de egyikhez sincs vevő-e-mail mentve…”).
• Az automatikus emlékeztető Pro csomagtól elérhető. Free csomagban az eszköz elutasít, és az automata akkor sem küld, ha a kapcsoló korábban be volt kapcsolva.
• A bejövő (fizetendő) oldal és a banki párosítás Ultra-kötött.
• Nincs részfizetés-nyilvántartás a saját úton. A helyi nyilvántartás csak a bináris „kifizetve / nem kifizetve” állapotot ismeri. Külső számlázón a részfizetéseket a számlázó fizetési jegyzéke tartja nyilván; a saját úton ilyen főkönyv nincs, tehát a részfizetés nem követhető nyomon.
• Az átutalási QR-kód nem elérhető (egyetlen csomagban sem): a hazai QR-fizetés (qvik) banki oldali hitelesítést kíván, amellyel nem rendelkezünk. Az eszköz minden hívást elutasít – inkább megmondjuk, mint hogy működésképtelen kódot adjunk.
• A fizetettség nem NAV-releváns adat: sem a jelölés, sem a befizetés nem kerül a NAV-adatszolgáltatásba, és nem érinti annak állapotát.

A titkár ugyanezt mondja, amit a program csinál. Az automatikus emlékeztető beállítási eszközének leírása a fenti, tényleges működést írja le: két fokozat (a 3. napon barátságos, a 15. napon határozott hangnem), utána az automata leáll; a 3. fok – a felszólítás késedelmi kamattal – sosem automatikus, és élő fizetési ígéretnél az automata hallgat. Így az asszisztens sem ígérhet mást a felhasználónak, mint ami ténylegesen történik.

20.4 A te teendőid

• A fizetettség rögzítése kézi lépés (Ultra alatt banki párosítással megerősíthető) – a rendszer magától nem tudja, mi folyt be a bankszámládra.
• Az automatikus emlékeztetőt tudatosan kell bekapcsolnod a kártya gombjával, és vevői e-mail-címeket kell mentened a partnerekhez, különben az automata nem tud kihez fordulni.
• Ha megbeszélted a vevővel a fizetés napját, rögzítsd fizetési ígéretként – addig nem megy ki gépi sürgetés a nevedben.
• A 3. fok (felszólítás késedelmi kamattal) mindig a te tudatos döntésed; a rendszer csak felkínálja a Pénzügyi teendők sávban.

21. A nem számlázási célú funkciók elhatárolása

A 23/2014. (VI. 30.) NGM rendelet 10. § (2) bekezdése előírja, hogy a dokumentációnak tartalmaznia kell a program működésének részletes leírását és valamennyi funkció ismertetését – ha tehát a program a számlázáson kívül mást is ellát, a számlázási célú funkciókat el kell határolni a többitől. Ez a fejezet ezt az elhatárolást végzi el, teljes funkciólistával.

A 10. § (2) második mondata azt is kimondja, hogy „a számlázó program kizárólag a felhasználói dokumentációban szereplő funkciókat hajthatja végre”. Ebből a Szolgáltatóra kötelezettség hárul: új funkció csak akkor élesíthető, ha ebben a dokumentumban már szerepel. Ez a szabály a környezeti kapcsolóval elérhetővé tehető funkciókra is kiterjed: az eÁFA gépi beadás két eszköze mindaddig nincs a készletben, amíg a kapcsoló ki van kapcsolva, és a bekapcsolása csak e dokumentum előzetes kiegészítésével történhet meg (26.4). Ugyanez érvényes minden jövőbeli eszköz-bővítésre.

A titkár.ai egyetlen, folytonos chat-felület: nincs külön menürendszer, minden funkciót természetes nyelvű kéréssel indítasz. A felszín alatt viszont a funkciók zárt, névvel azonosított eszközkészletet alkotnak. A készlet 102 eszközből áll, és minden felhasználónál, minden csomagban ugyanez a 102 kulcs (kontraktus-teszt rögzíti). Ehhez jön két további eszköz, ha az eÁFA gépi beadás környezeti kapcsolója be van kapcsolva – az éles környezetben 2026. augusztus 18. óta be van kapcsolva, tehát ez a két eszköz jelen van (26.4 és a 21.2 pont 6. blokkja).

21.1 Ami a számlázó program része (nem tartozik az elhatárolás alá)

Az alábbi funkciók a rendelet értelmében vett számlázási cél körébe esnek: bizonylatot állítanak elő, módosítanak, olvasnak vissza, vagy a bizonylathoz kapcsolódó jogszabályi adatszolgáltatást teljesítik.

Ugyanígy a számlázó program része a jogszabályi adatszolgáltatás-réteg – ezek a funkciók egyetlen csomagban sincsenek korlátozva, mert jogszabályi kötelezettség teljesítését szolgálják:

21.2 A nem számlázási célú funkciók teljes listája

Az alábbi funkciók nem a számlázási célt szolgálják. Nem állítanak elő és nem módosítanak bizonylatot, és nem vesznek részt a NAV-adatszolgáltatásban. Ezek kényelmi, nyilvántartási és elemző funkciók.

1. Partner- és cégadat-nyilvántartás

A search_company_by_name és a get_company_profile külső, nyilvános forrásból dolgozik. Az onnan kapott adat tájékoztató jellegű, késhet vagy pontatlan lehet – a számlára kerülő vevőadatért te felelsz.

2. Fizetettség és behajtás

A fizetettség a program saját nyilvántartásában rögzül. A rendszer fizetést vagy átutalást nem indít, és erre nincs is eszköze.

3. Bejövő (szállítói) számlák és kiadás-nyilvántartás – mind Ultra csomaghoz kötött

A bejövő számlákhoz a program nem készít PDF-et és nem küld e-mailt – ezek nem a titkár.ai által kibocsátott bizonylatok.

4. Kontírozás (előkönyvelés) és tanulás – mind Ultra csomaghoz kötött

Az előkönyvelés javaslat, nem könyvelés. A számviteli és adójogi minősítés a könyvelődé; a rendszer által javasolt kontírozás nem helyettesíti azt.

5. Bank – mind Ultra csomaghoz kötött

Az automatikus banki összekötés a programban kemény kapcsolóval ki van kapcsolva. Ma kizárólag a kézzel feltöltött CSV-bankkivonat működik. A connect_bank_account erről magyar mondattal tájékoztat. A banki adat kizárólag olvasásra szolgál: a rendszer bankszámla-műveletet nem hajt végre.

6. Áfa-analitika és eÁFA-előkészítés

Az analitika-, adókód- és becslés-funkciók nem küldenek adatot a NAV-hoz, és tájékoztató jellegűek; az áfa minősítése a te (illetve a könyvelőd) feladata marad. A két beadás-előkészítő eszköz a NAV eÁFA-rendszerébe tölt, de bevallást nem nyújt be: a benyújtás kizárólag a megerősítő kártya „Beadom” gombjával, az asszisztenstől független, hitelesített végponton történik (26.4).

7. Kimutatások, riportok, könyvelői export

Az export_for_accountant nem azonos a 11/A. § szerinti adóhatósági ellenőrzési adatszolgáltatással – az utóbbi az export_invoice_data (lásd 21.1 és a 17. fejezet).

8. Kontroll, határidők, saját emlékeztetők – mind minden csomagban

Ezek a funkciók kizárólag emlékeztetnek – maguk semmilyen bevallást nem adnak be és semmilyen adót nem fizetnek be. Bevallás benyújtására egyedül az eÁFA megerősítő kártyája ad utat (a 6. blokk és 26.4), ott is a te gombnyomásoddal; adót a rendszer semmilyen formában nem fizet be.

9. Beállítás, memória, előfizetés

10. Asszisztens-funkciók – mind minden csomagban

11. Korábbi kimenő számlák behúzása a NAV-ból

12. Kikapcsolt funkció

21.3 Az elhatárolás lényege

A fenti, 21.2 pont alatti funkciók egyike sem befolyásolja:

• a bizonylat sorszámozását (8. § (1) a)),
• a bizonylat adattartalmát,
• a bizonylat állapotát (kiállított / sztornózott),
• a NAV-adatszolgáltatás tényét, tartalmát vagy időpontját.

A bizonylat-kibocsátó mag és a NAV-adatszolgáltatás a fenti kényelmi funkciók kikapcsolása vagy hibája esetén is változatlanul működik.

22. Az AI-asszisztens szerepe és korlátai

A titkár.ai kezelőfelülete természetes nyelvű: a kérésedet nagy nyelvi modell (LLM) értelmezi. Mivel ez a rendelet 10. § (2) bekezdése szempontjából is magyarázatot igényel, ez a fejezet pontosan leírja, mit tesz és mit nem tesz a modell.

22.1 A modell zárt eszközkészletből dolgozik

A modell nem fér hozzá a rendszerhez szabadon: kizárólag a 21. fejezetben felsorolt, névvel azonosított 102 eszköz valamelyikét hívhatja meg. Nem tud SQL-t futtatni, nem tud tetszőleges HTTP-kérést küldeni, nem tud fájlt írni, és nem tud a felsoroltakon kívüli műveletet végrehajtani.

Az eszközök a felhasználói fiók (bérlő) azonosítóját zárt környezetben (closure-ben) hordozzák: az azonosító sosem kerül a modell elé, és a modell nem tudja átírni. Ennek következtében a modell nem tud más felhasználó adatához nyúlni, akkor sem, ha erre utasítást kap.

A NAV technikai felhasználó adatai – jelszó, aláírókulcs, XML cserekulcs – soha nem kerülnek a modellhez. A NAV-hívások szerveroldalon, a modelltől elkülönítve futnak (6.6 és 24.3).

22.2 A NAV-adatszolgáltatás XML-jét nem a modell állítja elő

Ez a fejezet legfontosabb állítása. A NAV-nak küldött InvoiceData XML-t determinisztikus, tesztelt kód generálja, nem a nyelvi modell.

A lánc a következő, és minden lépése a kiállítási adatbázis-tranzakción belül, szerveroldalon fut:

jóváhagyott bizonylat-adat  →  NAV-leképező (mapper)  →  XML-előállító  →  NAV

Ebből következően:

• A számokat nem a modell számolja. A nettó, áfa és bruttó értékeket, az áfa-összesítőt és a HUF-ra átszámított értékeket a számítási réteg állítja elő.
• A sorszámot nem a modell adja. A sorszámot az allokátor osztja ki, a kiállítási tranzakción belül (8.3, 23.3).
• A NAV-XML-t nem a modell fogalmazza. A modell természetes nyelvű mezőket ad át (vevő neve, tétel megnevezése, mennyiség, egységár); a leképezést az áfakódra, a mennyiségi egység kódjára és a vevő-státuszra a mapper végzi, kódba írt szabályokkal.
• Az adóhatósági ellenőrzési adatszolgáltatás XML-je sem megy át a modellen. Az export_invoice_data eszköz csak a darabszámot, a tartományt és a letöltési hivatkozást adja vissza; a fájlt a szerver állítja elő (17.1).

Ha a mapper egy adatot nem tud egyértelműen leképezni, nem tippel, hanem megtagadja a műveletet és pontosítást kér (a részletes listát a 26.3 pont tartalmazza).

22.3 Minden visszafordíthatatlan lépés megerősítő kártyán megy

A bizonylat-eszközök nem állítanak ki semmit. Amit adnak, az egy előnézeti kártya a chatben. A tényleges kiállítás akkor és csak akkor indul el, amikor te a kártyán a gombra kattintasz – az a kattintás hív egy védett szerver-végpontot, amit a modell nem tud meghívni.

Ez nem egyetlen kapcsoló, hanem szerkezeti elv: a bizonylatot előállító és a kifelé ható eszközök egyike sem hajtja végre magát a műveletet – csak előnézeti kártyát adnak vissza. A végrehajtás mindig külön, munkamenettel védett szerver-végponton fut, amit a modell nem tud meghívni. Ez érvényes a számla- és díjbekérő-kiállításra és az alábbiakra:

• a sztornó (storno_invoice),
• minden törlés (delete_partner, delete_recurring_invoice),
• minden e-mail-küldés a vevőnek (prepare_send_invoice_email, prepare_bulk_email),
• minden tömeges művelet (prepare_bulk_issue, prepare_bulk_multi_issue, prepare_bulk_paid, prepare_bulk_payment_reminder),
• a befizetés-rögzítés (register_payment, mark_invoice_paid),
• a kifelé ható kapcsolók bekapcsolása (set_payment_reminders, set_accountant_auto_send),
• a támogatási jegy beküldése (contact_support),
• a csomagváltás kártyája (manage_plan).

Az elv aszimmetrikus: a biztonságos irány (egy automatizmus kikapcsolása, egy fizetési ígéret törlése) azonnal lefut, a kockázatos irány (bekapcsolás, küldés, kiállítás, törlés) megerősítést kér. Az elvet eszközönkénti automatizált tesztek rögzítik: a készlet minden darabjáról teszt mondja meg, melyik kapu alá esik.

22.4 A szövegben érkező utasítás adat, nem parancs

A rendszer kimondottan úgy van beállítva, hogy a felhasználói üzenet, a feltöltött fájl, a beérkezett e-mail, a számla szövege, a vevő neve és az eszközök visszaadott eredménye adat, nem utasítás. Egy vevő nevébe vagy egy bejövő számla megjegyzésébe rejtett „utasítás” nem vezérli a rendszert.

Ezt több, kódba írt korlát támogatja: a kézi kiadás-rögzítésnek forrás-kapuja és összeghatára van, a fizetési mód zárt értékkészletből választható, és a partner-mentés nem írja felül egy meglévő partner e-mail-címét.

22.5 Lépéskorlát

Egy beszélgetési kör legfeljebb 8 modell-lépésből áll. A keret utolsó lépésében a modell eszköz nélkül marad, tehát a kör mindig megfogalmazott válasszal zárul, nem szakad meg félbe és nem fut végtelen ciklusba.

22.6 A modell korlátai – kimondva

• A modell tévedhet. A megerősítő kártya nem formalitás: az előnézeten látható adat az, ami a számlára és a NAV felé megy. A jóváhagyás előtt ellenőrizd.
• A csomag-korlátok az eszköz futásakor érvényesülnek, nem a készlet szűrésével. Ezért a modell alacsonyabb csomagban is „ismeri” a magasabb csomag funkcióit, és fel tudja ajánlani a váltást. Ez tudatos döntés; a funkció maga ilyenkor is elutasít.
• Az asszisztens nem tudja benyújtani a bevallásodat, és nincs fizetésindító eszköze. Az eÁFA-bevallást legfeljebb ELŐKÉSZÍTI (analitika, tervezet, a NAV-hoz való feltöltés); a tényleges benyújtás egy külön gomb a megerősítő kártyán, amelyet az asszisztenstől független, hitelesített végpont futtat – így egy rosszindulatú szövegű bejövő számla vagy e-mail sem tud a nevedben bevallást beadni.
• Az adójogi és jogi kérdésekben az asszisztens tájékoztató marad; a végső minősítés a könyvelődé, illetve a NAV-é.
• Az asszisztens nem működik közre valótlan, fiktív vagy visszadátumozott bizonylat készítésében.

22.7 Mit jelent ez a felelősségre

A számlakiállítás a te kifejezett megerősítésed után, az általad jóváhagyott előnézet alapján történik, és visszafordíthatatlan (sztornózható, de nem törölhető). Nincs kizárólag automatizált döntéshozatal: ember – te – van a hurokban. A kiállított számla adattartalmáért az, aki az előnézetet jóváhagyta, tehát a felhasználó felel (ÁSZF 6.3. pont); a Szolgáltató az előnézettel és a NAV-adat visszaolvasásával segít.

23. Csomagkorlátok mint működési korlát

A titkár.ai három előfizetési csomagban érhető el: Free, Pro, Ultra. A csomagok nemcsak árban különböznek: egyes funkciók magasabb csomaghoz kötöttek, a Free csomagnak pedig havi darabszám-kerete van a kiállított számlákra. Ez a fejezet a kereteket működési korlátként írja le – nem árlistaként.

23.1 Számszerű keretek

A havi számla-keret értelmezése:

• Csak az éles számla számít bele. A díjbekérő és a nyugta nem.
• A sztornó okirat és a NAV-ból importált számla beleszámít, mert mindkettő önálló számla-bizonylatként keletkezik.
• A később sztornózott számla is beleszámít, mert a metrika a kiállítás ténye. Nincs „sztornózd és állítsd ki újra” kerülőút.
• A hónaphatárt az adatbázis szerveridő szerinti naptári hónapja adja.

A fizetős csomagok fair-use szintje nem korlát: a 75, illetve 400 darab felett a rendszer legfeljebb halkan jelez, de soha nem blokkolja a számlázást. Ezt az ÁSZF 5.1 pontja is rögzíti.

A napi AI-üzenetkeret a beszélgetést korlátozza, nem a számlázást. Ha a napi keret kimerül, az asszisztens a keret megújulásáig nem elérhető; ez nem érinti a már kiállított bizonylatokat és nem érinti a NAV-adatszolgáltatást.

23.2 Funkció-korlátok csomagonként

• Ultra csomaghoz kötött (31 funkció): a teljes bejövő (szállítói) oldal, a kézi kiadás-rögzítés, a bank, az áfa-analitika és az eÁFA-előkészítés, a mély kimutatások (időszak-összevetés, előrejelzés, kiadás-bontás, eredmény), valamint a teljes könyvelői réteg (CSV-export, könyvelői csomag, automatikus küldés, könyvelői visszajelzés, tanult profil).
• Pro és Ultra csomaghoz kötött (10 funkció): díjbekérő készítése, NAV-import, automatikus fizetési emlékeztető, alapértelmezett számlázási beállítások, tartós megjegyzés, tétel-sablonok, késedelmi kamat. A tömeges kiállítás csak díjbekérő esetén Pro-kötött: rendes számlára Free csomagban is működik.
• Minden csomagban elérhető (57 funkció): az alap kimenő számlázás, a partner-kezelés, a befizetés-rögzítés, a kimenő oldali áttekintő kimutatások, az alanyi adómentes értékhatár figyelése, valamint – kifejezetten szándékosan – a NAV-adatszolgáltatás állapota és újraküldése (get_nav_submission_status, retry_nav_submission) és az adóhatósági ellenőrzési adatszolgáltatás (export_invoice_data).
• Egyéb, feltételesen kapuzott (4 funkció): a vevő mentése és mentésre ajánlása (save_partner, propose_partner) minden csomagban elérhető, de Free csomagon legfeljebb 3 mentett partnerig; az ismétlődő ütemezés létrehozása (set_recurring_invoice) Pro és Ultra csomag funkciója (12.1); az átutalási QR-kód (get_payment_qr) pedig funkció-kapcsolóval, minden csomagban ki van kapcsolva (21.2/12. pont).

A négy felsorolás együtt adja ki a 21. fejezet szerinti 102 eszközt (31 + 10 + 57 + 4). A besorolás hiánytalanságát automatikus teszt kényszeríti ki.

Ez utóbbi elvi döntés: jogszabályi kötelezettség teljesítése nem függhet előfizetéstől. A 13/A. § szerinti adatszolgáltatás és a 11/A. § szerinti adóhatósági ellenőrzési adatszolgáltatás ezért a Free csomagban is teljes körűen elérhető.

Ha egy funkció a csomagodban nem érhető el, a rendszer magyar mondattal, a szükséges szint megnevezésével utasít el („…az Ultra csomag része”, „…a Pro és Ultra csomag része”).

23.3 A blokkolt kiállítás nem oszt sorszámot

A kiállítás sorrendje: (1) csomag- és kvótakapu – a Free havi keret ellenőrzése és a díjbekérő-kapu a kiállítási végponton, a kiállítási művelet meghívása előtt fut; elutasításnál HTTP 402 a válasz, gépi hibakóddal (free_limit), hogy a felületen csomagváltási lehetőség jelenjen meg zsákutcás hiba helyett; (2) biztonsági kapuk (24.2); (3) csak ezek után indul a kiállítási adatbázis-tranzakció, és a sorszám kiosztása ezen belül történik.

Ebből következik, hogy egy elutasított vagy elhasalt kiállítás nem oszt sorszámot és nem hagy hézagot – a levezetést és a párhuzamossági igazolást a 8.3 és 8.6 pont tartalmazza.

23.4 Csomagváltás

A csomagváltást a chatben kérheted; a rendszer a csomagkártyát nyitja meg. A fizetés minden esetben a Stripe fizetési felületén történik – az asszisztens fizetést sosem indít, és bankkártyaadatot nem lát.

Az előfizetés díjszámlája és az adószámod (9. § (2)). A rendelet szerint a számlázó program csak adóalanynak értékesíthető, és a Szolgáltató köteles a díjszámlán feltüntetni a beszerző adószámát. Ezért a fizetési felület bekéri az adószámot; ha pedig a fiókodhoz éles NAV technikai felhasználó van bekötve, a rendszer a NAV adóalany-lekérdezésével igazolt adószámodat automatikusan ráteszi a számlázási adataidra – ez az adóalanyiságod legerősebb igazolása, és így a díjszámládra biztosan a helyes adószám kerül.

23.5 A Free csomag mentett-partner kerete

A Free csomagban legfeljebb 3 mentett partner (vevő-memória) tárolható; a Pro és az Ultra csomagban a mentett partnerek száma korlátlan. A keret az ÁSZF 5. pontjának csomagtáblázatában is szerepel — a két dokumentum ugyanazt mondja.

24. Biztonsági korlátok és az audit-napló

24.1 Hitelesítés és hozzáférés

A belépési módokat (e-mail + jelszó, Google-fiók, azonosítókulcs, magic link, kétlépcsős azonosítás) és a munkamenet szabályait az 5.2 pont sorolja fel. Az azonosítókulcs a domainhez van kötve, tehát más domainről nem használható fel. A kétlépcsős azonosítás ellenőrző végpontjai percenként 5 kérésre vannak korlátozva.

A szerveroldali JSON-végpontok közös burkolón mennek át, amely egységesen kezeli a hozzáférést: 401 (nincs érvényes munkamenet) · 403 (a csomag nem jogosít) · 429 (túl sok kérés) · 500 (hiba; a részletek a hibakövető rendszerbe kerülnek, a felhasználó általános üzenetet lát).

A két fájl-letöltő végpont – a számlakép PDF-je és a 11/A. § szerinti adóhatósági ellenőrzési adatszolgáltatás – a burkolón kívül él, mert nem JSON-t ad vissza. Ezeken is szerveroldali munkamenet-ellenőrzés és tenant-hatókör-ellenőrzés fut (bejelentkezés nélkül 401, idegen bizonylatra 404), kérés-korlát (429) viszont nincs rajtuk.

A felhasználóhoz tartozó bérlő azonosítását mindig a szerver végzi, a kérésből érkező adat alapján soha.

A kiállítás és a sztornó percenként 10 kérésre korlátozott fiókonként, és ez a korlát zárt hibamódú: ha a korlátozó szolgáltatás nem elérhető, a rendszer nem enged át kérést, hanem elutasít.

24.2 Opcionális kiállítás-védelem

A Beállítások → Biztonság alatt négy, egymástól független korlátot állíthatsz be. Ezek opcionálisak: ha nem állítasz be semmit, a rendszer a teljes ellenőrzést átugorja, és a kiállítás a szokásos módon megy.

A döntés sorrendje szándékos: előbb a kemény blokkok (napi darabszám, összegplafon), csak utána a megerősítés-kérés – egy blokkolt számlát a rendszer megerősítés után se küldjön ki.

A friss hitelesítés bizonyítéka 5 percig érvényes és egyszer használható fel; kizárólag a sikeres azonosítókulcsos hitelesítés hozza létre. A napi darabszám-korlát atomi foglalással, adatbázis-szintű sorzárolással működik, a ténylegesen kiállított darabszámmal szinkronban; ha a kiállítás mégis elhasal, a foglalás visszaadódik.

Nem forint alapú számlánál a bruttó összeget a rendszer napi MNB-középárfolyamon váltja forintra az összehasonlításhoz.

A két kemény korlát (összegplafon, napi darabszám) központi ponton érvényesül: a tömeges kiállítás és az ismétlődő számlázás ütemezett futása sem tudja megkerülni őket (12.3).

A megerősítés-mód hatóköre viszont szűkebb: az az általad indított kiállítási utakon fut (az egyedi és a tömeges kiállításon), valamint az eÁFA-beadáson és az automatikus ismétlődő mód bekapcsolásán. Az automatikus ismétlődő kiállítás maga nem kér kiállításonként friss hitelesítést (5.5, 12.1).

Korlát: az előnézeti szakaszban a napi darabszám nem kerül kiszámításra (ott nullának számít); az igazságforrás a kiállításkori atomi foglalás. Ennek oka, hogy egy előre számolt darabszám téves korai blokkoláshoz vezethetne.

24.3 Titokkezelés

Minden integrációs kulcs – és a NAV technikai felhasználó jelszava, XML aláírókulcsa és XML cserekulcsa – AES-256-GCM titkosítással, kérésenként egyedi inicializáló vektorral és hitelesítő taggel tárolódik; a visszafejtés kizárólag szerveroldalon történik, és a kulcsok soha nem kerülnek a kérésbe, a böngészőbe és a nyelvi modellhez. A tárolás részleteit a 6.6 pont tartalmazza.

A NAV felé irányuló hitelesítés a hivatalos Online Számla 3.0 előírás szerint SHA-512 (jelszó-lenyomat) és SHA3-512 (kérés-aláírás) algoritmussal készül; a számla-beküldés aláírása a művelet-indexek lenyomatait is tartalmazza.

24.4 Az audit-napló

A rendszer hozzáfűzéses (append-only) audit-naplót vezet, fiókonként elkülönítve. A napló minden sora tartalmazza a cselekvő azonosítóját, a művelet típusát, az érintett bizonylatot és a művelet részleteit, időbélyeggel. (A kiállítási és sztornó-bejegyzések cselekvő-azonosító nélkül íródnak – lásd 5.8.)

A naplózott műveletek típusai: draft (vázlat), confirm (megerősítés), issue (kiállítás), storno (sztornó), fail (hiba), import (import), delete (törlés), payment (befizetés), email (e-mail), precode (előkönyvelés), security (biztonsági beállítás), evat (eÁFA), manual_expense (kézi kiadás).

A saját (NAV-közvetlen) úton a kiállítás és a sztornó naplósora a kiállítási adatbázis-tranzakción belül íródik: ha a bizonylat létrejött, a naplósor is létrejött, és fordítva. A megerősítés a biztonsági kapuk után, a hiba a hiba bekövetkezte után naplózódik.

A biztonsági beállítás módosítása külön naplósort kap, amely a korábbi és az új értéket is tartalmazza, a módosítást végző felhasználó azonosítójával.

A napló neked is lekérhető: a chatben bármikor kérheted („mi történt a fiókomban?”). A naplósorokat a szerver fordítja emberi mondatokká a tárolt adatból – nem a nyelvi modell, tehát a napló szövege nem a modell fogalmazása. Ez a funkció szándékosan nincs csomaghoz kötve.

Ezen felül a rendszer két további naplót vezet:

• Platform-adminisztrátori napló: fiók törlése, e-mail megerősítése, kétlépcsős azonosítás visszaállítása, csomag beállítása, munkamenetek visszavonása. Ez a napló a törölt fiók e-mail-címét pillanatképként is tárolja, hogy a törlés után is olvasható maradjon.
• Belépés-biztonsági eseménynapló: munkamenet létrejötte, azonosítókulcs sikeres ellenőrzése, blokkolt varázs-hivatkozás, blokkolt azonosítókulcs-módosítás, blokkolt külső bejelentkezés.

24.5 Az audit-napló korlátai – kimondva

• Az audit-napló nem kriptográfiailag láncolt és nincs rajta minősített időbélyeg. A „hozzáfűzéses” jelleg alkalmazás-szintű konvenció: a kódban nincs olyan útvonal, amely naplósort módosítana vagy törölne – de ezt adatbázis-szintű megszorítás nem kényszeríti ki.
• A fiók törlésével az audit-napló is törlődik (kaszkádolt törlés). A napló nem éli túl a fiókot (25.2).
• A kérés-korlátozás Redis-alapú. A kiállítás és a sztornó korlátja zárt hibamódú (elutasít), az egyéb helyeken nyitott hibamódú (átenged), hogy a korlátozó kiesése ne bénítsa meg a felületet.

24.6 A NAV-jogosultság kommunikációja – egységes

A „legkisebb jogosultság” elve nem jelenti azt, hogy kevesebb jog is elég. A program minden felületen ugyanazt mondja:

Következmény: a saját útra készülve a nyilvános oldalak alapján sem tudsz alul-jogosított technikai felhasználót létrehozni – a követelmény már az üzembe helyezés előtt kimondott (6.1).

25. Megőrzés és archiválás

25.1 Amit a program eltárol

A számlakép forrása maga az eltárolt XML. A PDF-et a rendszer az adatbázisból visszaolvasott, beküldött XML-ből építi, tehát a számlakép bizonyíthatóan ugyanazt mutatja, amit a NAV-nak jelentettünk – a kettő nem tud szétcsúszni. A sablon determinisztikus, futásidejű külső betűtípus- vagy erőforrás-letöltés nélkül, és a régi sablonverziók a kódban maradnak (15.1–15.3).

25.2 Amit a program NEM tesz

Ezt a pontot pontosan kell érteni, ezért kimondjuk:

• A titkár.ai nem nyújt jogszabályi értelemben vett számla-megőrzési (archiválási) szolgáltatást, és nem működtet hitelesség-biztosítási eljárást.
• A tárolt XML-en és a számlaképen nincs minősített elektronikus időbélyeg és nincs elektronikus aláírás vagy záradékolás. A rendszer lenyomatot tárol (XML: SHA3-512, PDF: SHA-256), ami az utólagos egyezés-ellenőrzést támogatja – de ez nem azonos a megőrzési szabályok szerinti hitelesség- és sértetlenség-biztosítással.
• Nincs automatikus archiváló vagy adattörlő háttérfolyamat. Az ütemezett feladatok egyike sem takarít bizonylatadatot. A bizonylatok a fiók fennállása alatt megmaradnak.
• A fiók (bérlő) törlésével a hozzá tartozó bizonylatok, NAV-beküldések, tételsorok, audit-napló és NAV-adatok kaszkádolva törlődnek. A rendszer a törlés után nem tartja fenn a nyolcéves megőrzést.
• Fiók-törlés a kódban kizárólag platform-adminisztrátori úton létezik; önkiszolgáló törlő felület jelenleg nincs.
• A díjbekérőnek nincs eltárolt XML-forrása, és nem tárolunk hozzá SHA-256 lenyomatot (a díjbekérő nem számla, adatszolgáltatás nem tartozik hozzá). A PDF-je letölthető, de az a saját nyilvántartásból épül, nem a NAV-nak beküldött adatból (15.5).

25.3 A te megőrzési kötelezettséged

A számviteli bizonylat megőrzése az adózó – tehát a te – kötelezettséged, a számvitelről szóló 2000. évi C. törvény 169. §-a alapján legalább 8 év. A titkár.ai Adatkezelési tájékoztatója ugyanezt az időt rögzíti, és az ÁSZF is fenntartja a nyolcéves megőrzést a szerződés megszűnése után.

Mielőtt megszünteted az előfizetésedet vagy a fiókodat: futtasd le a 11/A. § szerinti adóhatósági ellenőrzési adatszolgáltatást a teljes időszakra, és mentsd le a kapott XML-t, valamint minden számla PDF-jét. A 11/A. § szerinti adatszolgáltatási kötelezettség az elévülési idő végéig téged terhel, a program viszont a fiók törlésével a bizonylatokat, a beküldési naplót és a tárolt XML-eket véglegesen, visszaállíthatatlanul törli (25.2). A törlés után a titkár.ai ezt az exportot nem tudja újra előállítani.

Mivel a fenti korlátok fennállnak, a bizonylataidat a saját archívumodba is le kell mentened. A program három kimeneti utat ad ehhez:

25.4 Az adattárolás helye

Az adatbázis a Neon PostgreSQL szolgáltatásán, az EU / Frankfurt (AWS eu-central-1) régióban fut. Az alkalmazás a Vercel platformján, az EU / Frankfurt (fra1) régióban. A részleteket az Adatkezelési tájékoztató 6. pontja tartalmazza.

25.5 A megőrzés szabálya — kimondva

A 8 éves megőrzés a te kötelezettséged, nem a programé. A program a bizonylataid adatait (a beküldött számlaadat-XML-t, a PDF-lenyomatot és sablonverziót, a számlasorokat) a fiókod fennállása alatt korlátlanul őrzi, és bármikor exportálhatod (adóhatósági ellenőrzési adatszolgáltatás, PDF-letöltés, könyvelői csomag). A fiók törlése végleges és mindenre kiterjed — archiváló folyamat nincs, ezért a fiók törlése vagy az előfizetés megszűnése ELŐTT töltsd le a bizonylataidat és futtasd le a teljes időszakra az adatexportot; erre az Adatkezelési tájékoztató 10. és 12. pontja is kifejezetten figyelmeztet.

A fiók törlése az Adatkezelési tájékoztató 12. pontja szerint kérelemre, e-mailben (info@titkar.ai) kezdeményezhető — önkiszolgáló törlő felület nincs, és a tájékoztató ezt így is mondja ki. A törlés végleges és kaszkádol; a bizonylatok megőrzése a Felhasználó kötelezettsége, ezért a törlés előtt a 25.3 szerinti exportokat le kell futtatni.

26. Nem támogatott esetek

Ez a fejezet azt sorolja fel, amit a program szándékosan nem tud. A cél az, hogy ezt előre tudd, ne a művelet közepén derüljön ki.

26.1 A saját (NAV-közvetlen) úton jelenleg nem elérhető funkciók

A rendszer ezeket a szándék jelzésekor utasítja el – tehát akkor, amikor a funkciót kéred, nem a megerősítés után –, és mindegyikhez megnevezi a járható alternatívát.

Ami viszont működik: rendes számla, díjbekérő, díjbekérőből végszámla, előlegszámla és az azt beszámító végszámla, gyűjtőszámla, egyszerűsített adattartalmú számla (9.13), sztornó, helyesbítő számla (13.5), számlakép (PDF), e-mail-küldés, adószám-ellenőrzés a NAV-nál.

A korlátokat a rendszer nemcsak a művelet elutasításakor mondja ki: az asszisztens a „mit tudsz csinálni?” típusú kérdésre sem sorolja fel a nem elérhető funkciókat, és nem ígéri meg őket.

26.2 Meg nem épített NAV-XML alrendszerek

A számla-adatszolgáltatás XML-sémájának alábbi részei tudatosan nincsenek megvalósítva. Ha a tevékenységed ezeket igényli, más számlázó programot kell használnod:

• Környezetvédelmi termékdíj (termékdíj-összesítő, tételszintű termékdíj-tartalom, termékdíj-kötelezettség jelzése, termékdíj-záradék).
• Új közlekedési eszköz értékesítése (gyártmány/típus, alvázszám, motorszám, futott kilométer, üzemóra).
• Fej-szintű ERP-hivatkozások (megrendelésszám, szállítólevél-szám, EKÁER-azonosító, szerződésszám, beszállítói kód, költséghely, főkönyvi számla, munkaszám, projektszám).
• Tételek közötti kereszthivatkozás.
• Kötegelt módosítás – egy okirat, amely több számlát módosít. Erre a rendszer magyar mondattal elutasít.
• Időszakos elszámolású számla – a lefedettség-bővítés még hátra van. (A gyűjtőszámla megépült – 9.13.)
• Technikai érvénytelenítés (manageAnnulment) beküldő ága még nem él.
• Az adatszolgáltatás nem minősül magának az elektronikus számlának (completenessIndicator értéke minden esetben hamis). Ha a rendszer ezzel az értékkel próbálna beküldeni, a generátor elutasítaná.

26.3 Amit a rendszer szándékosan megtagad – nem tippel

Az alábbi esetekben a leképező réteg nem választ helyetted, hanem megtagadja a műveletet és pontosítást kér. Az ok minden esetben ugyanaz: a rossz jogcím vagy a kitalált adat hibás adatszolgáltatáshoz vezetne, aminek számlánként jelentős szankciós tétje van.

A generátor további, szigorú kapukat tart fenn: az eredeti számlánál hivatkozás nem szerepelhet, a módosításnál és a sztornónál kötelező; a sztornó tételsor nélkül nem küldhető be; a számlaszámban nem lehet csak whitespace; forintos számlánál az árfolyam csak 1 lehet; az árfolyam hat tizedesnél nem lehet hosszabb; a szabad szöveges mezőkre a séma hosszkorlátjai érvényesek; magánszemély vevőnél a név és a cím nem kerülhet az adatszolgáltatásba.

26.4 Egyéb, szándékosan nem támogatott műveletek

• A NAV-ból importált számla ezen az alkalmazáson keresztül nem sztornózható és nem helyesbíthető. Ezek valós, már bevallott bizonylatok, amelyeket nem a titkár.ai állított ki.
• A NAV által tartalmilag elutasított (aborted) beküldés újraküldése megtagadva. A tartalmi hibát javítani kell, nem ismételni. (Elutasított lánc-okiratnál a helyi állapot rendezését a 13.6 pont írja le.)
• Kiállított számla nem törölhető, csak sztornózható. (Díjbekérő törölhető – a saját úton jelenleg az sem, lásd 26.1.)
• A rendszer fizetést vagy átutalást nem indít.
• Az automatikus banki összekötés ki van kapcsolva – csak kézi CSV-bankkivonat.
• Bevallást az asszisztens önállóan nem nyújt be. Az eÁFA gépi beadás-előkészítése 2026. augusztus 18. óta elérhető (Ultra): az asszisztens a tervezetet a NAV eÁFA-rendszerébe tölti és az állapotát lekérdezi, a benyújtás viszont kizárólag a megerősítő kártya gombjával, az asszisztenstől független, hitelesített végponton fut. A lánc környezeti kapcsoló mögött marad: hiba esetén a Szolgáltató kikapcsolja, ekkor az előkészítő eszközök kikerülnek a készletből, a benyújtó végpont elutasít (fail-closed), és az áfabevallást a NAV eÁFA-felületén kell beadnod. A helyi áfa-analitika, az adókód-javaslat és az áfakód-lekérdezés ettől független – azok nem küldenek adatot a NAV-hoz.
• A hazai QR-fizetés (qvik) egyik csomagban sem érhető el (20.3).
• Egyszerűsített adattartalmú és gyűjtő számla HELYESBÍTÉSE megtagadva (a sztornójuk működik) – 9.13, 13.6.
• Sztornó csak akkor indítható, ha az eredeti számla adatszolgáltatása lezárult (done állapot).
• Migrált vagy külső eredetű gyökérszámlánál, lánc-előzmény nélkül a módosító művelet megtagadva – a rendszer nem tippeli meg a lánc előzményét.

27. Verziókövetés

A 23/2014. (VI. 30.) NGM rendelet 10. § (3) bekezdése alapján a dokumentációnak követnie kell a program változásait.

27.1 A NAV felé jelentett szoftver-azonosság

A titkár.ai minden NAV-kérésbe beépíti a 2.1 pontban szó szerint közölt azonosítót (softwareId = 13311908SZAMLAI001, softwareName = titkar.ai, softwareMainVersion = e dokumentum verziószáma, jelenleg 1.7). Az azonosító és a név eltérésének oka szintén ott olvasható: az azonosító a NAV-nál nyilvántartott előzmény miatt marad változatlan.

27.2 A számlakép sablonjának verziója

A számlakép sablonja verziózott (PDF_TEMPLATE_VERSION, jelenlegi értéke v1), és a verzió számlánként eltárolódik az első számlakép-generáláskor, a PDF SHA-256 lenyomatával együtt. A régi sablonverziók a programkódban maradnak, így utólag igazolható, hogy egy újragenerált számlakép azonos a korábban kiadottal (15.3).

27.3 A dokumentum verziózása

Ez a dokumentum a repóban bevett jogi-dokumentum mintát követi: a fejlécében szerepel a hatálybalépés dátuma és a verziószám. A mindenkor hatályos változat a https://titkar.ai oldalon érhető el; a módosításról a Szolgáltató az ÁSZF 14. pontja szerint előzetesen tájékoztat a felületen vagy e-mailben.

Verzióléptetési szabály. A Szolgáltató minden olyan funkcióváltozáskor, amely e dokumentum tartalmát érinti – új eszköz élesítése, meglévő funkció megszűnése, korlát változása –, az élesítést megelőzően kiadja a dokumentum új verzióját. Ez a 10. § (2) második mondatából következik: a program csak dokumentált funkciót hajthat végre (21. fejezet). A NAV felé jelentett softwareMainVersion ugyanezt a verziószámot viszi, egyetlen közös forrásból — a program verziója és a dokumentáció verziója nem tud széttartani (2.4).

27.4 A verziókövetés jelenlegi korlátai – kimondva

• A programban jelenleg nincs beépített változásnapló (changelog) a számlázó program funkcióváltozásaihoz; a felhasználó a felületen nem látja, mi és mikor változott. A dokumentum saját verziótörténetét a 27.5 pont tartalmazza.
• Az átadás igazolása a regisztrációkor rögzül (időbélyeg + a dokumentum akkori verziószáma a fiók adatai között). A rögzítés bevezetése előtt létrejött fiókoknál ilyen bejegyzés nincs — rájuk az átadás a nyilvános közzététellel és a letöltési ponttal teljesül.
• A korábbi verziók letöltése a ?verzio= paraméterrel érhető el (1.1, 1.5, 1.6 és a mindenkori újabb kiadások). Az 1.0, 1.2–1.4 kiadásokról nem őrződött önálló példány — ezeket a Szolgáltatótól kell kérned az info@titkar.ai címen.

27.5 Verziótörténet

Az alábbi táblázat a dokumentum minden kiadott változatát felsorolja. A számlád kiállításának napján hatályos verzió az irányadó rá – a 10. § (4) szerinti megőrzéshez ezt a verziót töltsd le a letöltési pontról (1.1, 27.4).

| 1.6 | 2026. augusztus 10. | A kód és a dokumentáció eltéréseinek átvezetése, kódjavításokkal együtt. Új leírás: a sending állapot és a félbeszakadt küldés feloldása a NAV lánc-kivonatából (16.4, 18.3) – ide tartozik az az eset is, amikor a beküldésre nem érkezik válasz: a rendszer ilyenkor nem küld újra, hanem a NAV-ot kérdezi meg; a napi NAV-egyeztetés (18.2), amely a hatóság nyilvántartását veti össze a kiállított számlákkal, és külön, magas súlyú teendőt ad, ha a NAV nem ismer egy számlát – illetve ha maga az egyeztetés marad el; a kiállítás utáni kártya élő adatszolgáltatás-státusza (16.9). Kódjavítás: a kiállítói cím hiányosan sem mehet ki – a NAV sémája az irányítószámot és a települést kötelezővé teszi, a hiányt a program a korábbi pillanatképből pótolja, végső esetben megáll (16.6); több cím esetén a székhely kerül a számlára (16.6); az adóhatósági export dokumentumai számlánként épülnek, így egyetlen hibás bizonylat nem viszi el a teljes exportot (17.5), a NAV által elutasított lánc-okirat pedig nem kerül az exportba (17.3). Kimondott korlátok: az INFO szintű NAV-üzenet nem jelenik meg figyelmeztetésként, és a napi egyeztetés ablaka 34 nap (18.9) |

| 1.7 | 2026. augusztus 14. | Verziópolitika és átadás-bizonyítás (T-32, T-33 lezárva): a NAV felé jelentett softwareMainVersion a dokumentum verziószámát követi, közös forrásból (2.4, 27.3); a dokumentum verziózott letöltési pontot kapott a korábbi kiadások elérésével (1.1, 27.4), a tudomásulvétel pedig regisztrációkor időbélyeggel és verziószámmal rögzül (27.4). Kódjavítások: az ismétlődő számlázás esedékessége a magyar naptári nap szerint számít, a napi futás magyar idő szerint reggel 7:15/8:15 (12.4, 12.5; T-14 lezárva); az adóhatósági adatexport a magánszemély vevő címének országkódját a kiállításkori pillanatképből pótolja vissza a korábbi fix HU helyett (17.4). Pontosítva: az alanyi adómentesség-jelölés a tételek AAM-jogcíméből származik (9.12). Lezárt döntések: a dokumentum időbeli hatálya 2026. augusztus 8. (1.4; T-01 lezárva); a titkár.ai nem nyugtaadási program a 23/2014. NGM rendelet 2. §-a értelmében, és nyugta-funkciót a fejlesztési terv sem irányoz elő (4.4, 11.5; T-03, T-13 lezárva); a megőrzés szabálya: a 8 éves megőrzés a felhasználóé, a program a fiók fennállása alatt őriz, a fiók törlése végleges (25.5; T-30 lezárva); az első kiállítás NAV-függősége vállalt korlát, kézi cégadat-megadás szándékosan nincs (16.6; T-19 lezárva); egy fiók – egy személy, minden művelet hozzá rendelhető (5.1, 5.8; T-04, T-05 lezárva); a NAV-kapcsolat bontása kérelemre (6.9; T-06); a lezárás pillanata a tranzakció véglegesítése (7.11; T-07); az előtag nem választható, váltásnál új tartomány nyílik, a DIJB rögzített (8.8, 10.7; T-08, T-09, T-12); a külső korszak számlája a saját úton nem sztornózható (13.7; T-16); a számlakép-azonosság bizonyítéka a lenyomat + sablonverzió, nem a bitre-azonos újragenerálás (15.6; T-18); a 4 órás jelzési küszöb vállalt megfogalmazás (16.9; T-20); az export forrás-alapú hatálya végleges (17.3; T-21); kézi érvénytelenítéshez a NAV-felületre irányítás elegendő (18.9; T-23); munkanap-számláló nem épül (18.7; T-24); az adatszolgáltatás nyilvántartása a beküldési napló (19.5; T-25); a fizetettség-fejezet elhatárolásként marad (20.; T-26). Új bizonylatfajták a saját úton (4.1, 9.13): megépült az előlegszámla és az azt beszámító végszámla (a beszámítás feltétele az előlegszámla lezárult NAV-adatszolgáltatása; a beszámítási adatok az eltárolt XML-ből és a lánc fejadatából jönnek, nem a felhasználótól), a gyűjtőszámla (tételenkénti teljesítési dátummal) és az egyszerűsített adattartalmú számla (készpénz/bankkártya, áfatartalommal, a számlaképen nettó/áfa bontás nélkül). Ezzel az érintett korlátok kikerültek a 4.2, 9.12, 14.7, 16.9 és 26.1 pontból; új korlátként kimondva: egyszerűsített és gyűjtőszámla nem helyesbíthető (a sztornójuk igen), előleg- és végszámla tételei nem helyesbíthetők, a fejadatuk igen (13.6). Fiók-szintű kiállítói törzsadat (T-37 lezárva): a közösségi adószám és a pénzforgalmi elszámolás a számlázási alapértékek között adható meg — kitöltve a supplier-blokkba/detail-jelölésbe és a számlaképre kerül (6.9, 9.12, 28.6); a NAV-nyilvántartott cégadat továbbra sem írható felül kézzel. Step-up (T-38 lezárva): marad a bekapcsoláskori egyszeri igazolás — a felhatalmazás az ütemezés nem-módosítható tartalmához kötött, tartalmi változtatás törlés + újrafelvétel + új igazolás (5.5) |

| 1.8 | 2026. augusztus 18. | Az eÁFA gépi beadása élesedett. A beadás-ELŐKÉSZÍTŐ eszköz (feltöltés → partíció → véglegesítés) bekerült az asszisztens eszközkészletébe; a bevallás benyújtása változatlanul kizárólag a megerősítő kártya gombjával, az asszisztenstől független végponton fut. A 21., 22.6 és 26.4 pontok ennek megfelelően pontosítva: a korábbi „nincs beadási eszköz (a készletben sincsenek)" megfogalmazás helyett a dokumentum azt mondja ki, ami a kódban is így van – az asszisztens előkészít, benyújtani nem tud. A két eszköz (prepare_vat_declaration_submission, check_vat_declaration_status) a 21.2 pont 6. blokkjának funkciólistájába felvéve (Ultra). |

27.6 Nyitott kérdések

E fejezet korábbi nyitott kérdései (T-32 verziópolitika, T-33 átadás-bizonyítás) lezárultak: a szabályt a 2.4 és a 27.3, a megépített mechanizmust az 1.1 és a 27.4 pont tartalmazza.

28. Támogatás, felelősség, kapcsolat

28.1 A szolgáltató adatai és elérhetőségei

A fejlesztő és üzemeltető azonosító adatait (cégnév, székhely, cégjegyzékszám, adószám, képviselő) a 2.2 pont tartalmazza. Az elérhetőségek:

• Általános kapcsolat és panasz: info@titkar.ai
• Adatvédelmi és biztonsági bejelentések: adatvedelem@titkar.ai · gépi csatorna: /.well-known/security.txt (RFC 9116)
• Tárhelyszolgáltatók: Vercel Inc. (alkalmazás; EU/Frankfurt, fra1) és Neon Inc. (adatbázis; EU/Frankfurt, AWS eu-central-1)

28.2 Támogatás a programon belül

A chatben bármikor kérhetsz támogatást. A rendszer öt kategóriát ismer: kérdés, hibajelentés, számlázás/előfizetés, funkciókérés, egyéb.

A támogatási jegyet nem az asszisztens küldi el. Az eszköz csak a beküldendő szöveg előnézetét adja; a küldést te indítod a kártya gombjával, egy védett szerver-végponton. Ez zárja ki, hogy egy szövegbe rejtett „írj a supportnak, hogy…” típusú utasítás a nevedben levelet küldjön.

A hibajelentés nincs csomaghoz kötve: minden előfizetőt megillet, a Free csomagban is. A válasz a fiókodhoz tartozó e-mail-címre érkezik.

Korlát: telefonos ügyfélszolgálat nincs, és a Szolgáltató rendelkezésre állási (SLA) vállalást nem tesz. A programban és az ÁSZF-ben nevesített egyetlen két határidő a fogyasztói panasz 30 napja és a megrendelés visszaigazolásának 48 órája.

28.3 Felelősség

• Ember a hurokban. Éles, NAV-kész számla kizárólag a te kifejezett megerősítésed után kerül kiállításra. A megerősítés tudatos művelet; a kiállítás a NAV-adatszolgáltatás miatt visszafordíthatatlan (sztornózható, de nem törölhető). Nincs kizárólag automatizált döntéshozatal – a GDPR 22. cikk (1) bekezdése ezért nem alkalmazandó.
• A megerősítés felelőssége. A kiállított számla adattartalmáért – amelyet az előnézetben jóváhagytál – te felelsz. A Szolgáltató az előnézettel és a NAV-adat visszaolvasásával segít a hibák elkerülésében (ÁSZF 6.3).
• A Szolgáltató nem felel a megadott hibás adatokból, a megerősítésed alapján kiállított számlák tartalmából, a NAV rendszereinek működéséből, illetve az érdekkörödben felmerülő okokból eredő károkért (ÁSZF 8.1).
• Fogyasztóval szemben a jogszabály által kötelezően előírt felelősséget a Szolgáltató nem zárja ki és nem korlátozza (ÁSZF 8.2).
• Vis maior, internetkimaradás vagy harmadik fél szolgáltatásának hibája miatti kiesésért a Szolgáltató nem felel (ÁSZF 8.3).
• A titkár.ai mint szolgáltatás nem rendelkezik saját SOC 2 vagy ISO 27001 tanúsítvánnyal. A Biztonság-oldalon említett tanúsítványok az alvállalkozókra (tárhely-, adatbázis- és egyéb szolgáltatókra) vonatkoznak.

28.4 Panasz és jogorvoslat

Panaszkezelés: info@titkar.ai vagy postai levél a székhelyre. Írásbeli panaszra a Szolgáltató 30 napon belül érdemi, indokolt választ ad; a panaszt és a választ 3 évig megőrzi (a fogyasztóvédelemről szóló 1997. évi CLV. tv. 17/A. §).

Békéltető testület (a Szolgáltató székhelye szerint):

Hajdú-Bihar Vármegyei Békéltető Testület 4025 Debrecen, Vörösmarty u. 13–15. · +36 52 500 745 / +36 52 500 743 bekelteto@hbkik.hu · www.hbmbekeltetes.hu

Fogyasztóvédelmi hatóság: az illetékes fővárosi/vármegyei kormányhivatal. Az Európai Bizottság online vitarendezési (ODR) platformja 2025. július 20-tól megszűnt.

Adatvédelmi jogorvoslat:

Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH) 1055 Budapest, Falk Miksa u. 9–11. · ugyfelszolgalat@naih.hu · www.naih.hu

Bírósági út a lakóhely vagy tartózkodási hely szerinti törvényszéken is kezdeményezhető. Adatvédelmi incidens esetén a Szolgáltató 72 órán belül bejelentést tesz a NAIH-nak (GDPR 33. cikk), magas kockázat esetén az érintetteket is értesíti (GDPR 34. cikk).

28.5 Üzemmód

A NAV-kapcsolat éles vagy teszt üzemmódban működhet; ez a beállítás a fiók NAV-adatai között tárolódik. A felületen nincs felhasználó által szabadon váltható éles/teszt kapcsoló – az éles üzem az alapértelmezés (2.3, 6.5).

28.6 A jogi dokumentumokkal való összhang

A korábban itt jelzett ütközések (T-34, T-35, T-36) rendeződtek: a hatályos jogi dokumentumok a saját, NAV-közvetlen számlázást már kifejezetten leírják. Az ÁSZF 3. pontja a kiállítás módját táblázatban rögzíti, 5. pontja kimondja, hogy nincs külső számlázó-fiók és nincs második díj, 8.2 pontja pedig a felelősségi határt a Szolgáltató saját funkcióira külön húzza meg (a saját beküldő lánc hibájáért nem hivatkozhat a külső-rendszer kizárásra). Az Adatkezelési tájékoztató 5.1 pontja mondja ki, ki állítja ki a számlát és ki szolgáltat adatot a NAV-nak.

Kiállítói törzsadatok (T-37 lezárva). A kiállítói adatoknak két forrása van, tudatos munkamegosztásban: amit a NAV nyilvántart (név, cím, adószám, áfakód, megyekód), az kizárólag a NAV adóalany-lekérdezéséből jön (6.8, 16.6) — kézzel nem írható felül, így hibás kézi törzsadat nem kerülhet számlára. Amit a NAV nem ad vissza, az fiók-szintű beállítás: a közösségi adószám és a pénzforgalmi elszámolás a számlázási alapértékek között adható meg (9.12, 14.7), az alanyi adómentesség-jelölést pedig a tételek AAM-jogcíme adja (9.12).

29. Tisztázandó tételek az élesítés előtt

Ez a szakasz munkajellegű. Nem a program működését írja le, hanem azokat a kérdéseket gyűjti egy helyre, amelyeket a dokumentum élesítése (közzététele) előtt el kell dönteni – vagy jogi/üzleti döntéssel, vagy kódjavítással. A tételek a saját fejezetükben is szerepelnek, ugyanezzel az azonosítóval. Amíg egy tétel nyitott, a hozzá tartozó állítás a dokumentumban a jelenlegi, kódból igazolt működést írja le – soha nem egy tervezett állapotot.

A számozás hézagos, és ez így helyes. A hiányzó azonosítók (T-02, T-10, T-11, T-15, T-17, T-22, T-27, T-28, T-29, T-31, T-34, T-35, T-36, T-39, T-40, T-41, T-42) megoldott, lezárt tételek: a programban (illetve a jogi dokumentumokban vagy a jogszabály szövegének ellenőrzésével) megtörtént a tisztázás, és a dokumentum érintett fejezetei már a javított, tényleges működést írják le (a tételenkénti helyeket a 27.5 pont verziótörténete sorolja fel). Ahol a javítás részleges – a T-15 a magyar felület megerősítés előtti mondatáig terjed –, ott a megmaradt korlátot az érintett fejezet mondja ki (7.6). A megmaradó tételek azonosítóját nem számozzuk újra – a T-számok hivatkozásként élnek a fejezetekben, a fejlesztési jegyzetekben és a korábbi verziókban.

A v1.7-es kiadással minden tétel lezárult — nincs nyitott tisztázandó kérdés. A lezárások tételes listáját (mi zárta le: döntés, kódjavítás vagy szövegrögzítés, és melyik fejezetben) a 27.5 pont verziótörténete tartalmazza.

Hatálybalépés: 2026. augusztus 14. · Verzió: 1.7