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

Hatályos: 2026. augusztus 4.·Verzió: 1.1

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

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 saját (NAV-közvetlen) útra 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 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.

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 Szolgáltató belföldi szolgáltatóként a 10. § (6) alapján gondoskodik arról, hogy a magyar nyelvű dokumentáció 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).

[TISZTÁZANDÓ · T-33] Az appon belüli, verziózott letöltési pont még nincs megépítve. Amíg nincs, a dokumentum átadása kizárólag e fájl kézi átadásával (illetve a nyilvános közzététellel) történik, és géppel nem igazolható.

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 szamlazz.hu-n és a Billingón keresztüli működésre pedig a „külső számlázós út” megnevezést.

1.3 Mire NEM terjed ki – a külső számlázós út elhatárolása

A titkar.ai-ban három, egymást kizáró kimenő-számlázási út létezik:

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, nem a mai beállításodból

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, nem azt, hogy a fiókod ma melyik útra van állítva.

Ennek a gyakorlati következménye: ha átváltasz saját számlázásra, 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 a régi úton, a régi fiókodból megy. A dokumentum tehát arra a bizonylatra alkalmazandó, amelyik a saját úton keletkezett – függetlenül attól, hogy a fiókod éppen melyik beállításon áll.

[TISZTÁZANDÓ · T-01] Mely naptól hatályos ez a dokumentum, azaz mikortól élesedett a saját számlázás? A kódban nincs hatálybalépési dátum-mező, és nincs olyan adat, amiből az első saját úton kiállított számla kelte általánosan levezethető lenne. A hatályt vagy dátummal, vagy „a fiókod első saját úton kiállított számlájától” megfogalmazással kell rögzíteni. Ugyanez a kérdés a párhuzamos (strangler) időszakra is: a 10. § szerinti dokumentációs kötelezettség a Szolgáltatót a saját NAV-úton terheli, a külső számlázós felhasználóknál a számlázó program az adott szolgáltató terméke – a dokumentumot a saját út élesítésével együtt kell kiadni.

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 Fokozatos bevezetés

A saját számlázás nem minden fióknál választható: a felületen csak akkor jelenik meg, ha a fiókod már ezen az úton van, vagy ha az üzemeltető a fokozatos bevezetéskor megnyitotta. Ha nálad nem látszik a „titkár.ai · saját számlázás” kártya, akkor a fiókod még a külső számlázós úton van, és erre a dokumentumra jelenleg nincs szükséged.

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

A 23/2014. (VI. 30.) NGM rendelet 10. § (1) bekezdése előírja, hogy a dokumentációnak tartalmaznia kell a program nevét, azonosítóját, a fejlesztő adatait és elérhetőségét. 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.

[TISZTÁZANDÓ · T-02] A 10. § (1) szerinti „elérhetőség” alatt elegendő-e az e-mail-cím, vagy a székhely-címet is kötelező feltüntetni? A NAV-nak beküldött blokkban cím nincs, csak softwareDevContact (e-mail); a székhelyet a fenti táblázat az ÁSZF közzétételéből veszi át.

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 – korlát

A softwareMainVersion értéke fixen 1.0, és a program jelenleg nem lépteti automatikusan. Nincs olyan beépített szabály vagy felület, amely a szoftver verzióját a felhasználónak megmutatná, vagy a felhasználói dokumentáció verziójához kötné. A hiányzó verziópolitikát a 27.4 pont részletezi, a nyitott döntést pedig a T-32 tétel 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).

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),
• helyesbítő (módosító) számla (13.5),
• előlegszámla és a hozzá tartozó végszámla,
• kiállított díjbekérő törlése és a díjbekérő PDF-je (10.6),
• számla behúzása külső számlázó fiókjából.

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

A helyesbítés hiánya nem jelent jogi hátrányt: a sztornó + új számla eredménye ugyanaz, csak két bizonylat keletkezik egy helyett.

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át ne helyesbíts – 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.

[TISZTÁZANDÓ · T-03] A nyugta a saját úton marad-e a fejlesztési tervben (a terv a kihagyást javasolja)? Ettől függ, hogy a dokumentum nyugtáról szóló fejezete (11.) mit állíthat.

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.

[TISZTÁZANDÓ · T-04] Kimondható-e ez így korlátként, vagy a dokumentumnak explicit ki kell jelentenie, hogy a fiókhoz egyetlen természetes személy fér hozzá, és minden művelet az övé? A dokumentáció nem írhat le nem létező jogosultsági rendszert – vagy megépül a szerepkör-kezelés, vagy ki kell mondani, hogy a fiókhoz hozzáférő minden felhasználó jogosult kiállítani.

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 saját számlázás kártyáján nincs „Kapcsolat bontása” gomb: ezen az úton nincs külső számlázó-kulcs, amit bontani lehetne. Vissza bármikor válthatsz szamlazz.hu-ra vagy Billingóra; a már kiállított saját számláid ettől a saját útjukon maradnak (lásd 1.4).

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.

[TISZTÁZANDÓ · T-38] Kiterjesszük-e az azonosítókulcsos megerősítést az automatikus ismétlődő kiállításra (kiállításonkénti igazolás, vagy a felhatalmazás lejárata), vagy marad a mai, bekapcsoláskori egyszeri igazolás?

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.

[TISZTÁZANDÓ · T-05] Elfogadható-e ez a 10. § szempontjából, vagy a dokumentumnak kifejezetten ki kell mondania, hogy a fiókhoz egyetlen felhasználó tartozik, és emiatt minden művelet hozzá rendelhető?

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 törölheti a cserekulcsot. A mentés felülíró (upsert) művelet: ha a cserekulcs mezőt üresen hagyod, a rendszer a korábban eltárolt cserekulcsot null-ra írja. Ilyenkor a céged a saját úton marad, a kiállítás tovább megy, a NAV-beküldés viszont „A beküldéshez XML cserekulcs is kell…” hibával elakad. Ha bármikor frissíted a NAV-adataidat, a cserekulcsot is add meg újra.
• 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 – sőt, a fenti felülírás miatt egy onnan indított frissítés törli a meglévő cserekulcsot is. 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.
• Nincs kézi kiállítói cégadat-megadás. Áfakód, megyekód, közösségi adószám, alanyi adómentesség, pénzforgalmi elszámolás: ezekre nincs saját beviteli felület, kizárólag a NAV queryTaxpayer válaszából származhatnak. Amit a NAV nem ad vissza, azt a rendszer nem tudja a számlára tenni (lásd még T-37).
• 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.
• Ha másik számlázóhoz (pl. Billingo) is bekötsz kulcsot, az nem kapcsolja le a saját úton lévő céget: a váltás mindig tudatos, kézi lépés.

[TISZTÁZANDÓ · T-06] Van-e dokumentált eljárás a NAV-kulcsok cseréjére / a kapcsolat megszüntetésére a saját úton lévő cégnél – a kódban nincs bontó ág a saját útra, csak a szamlazz.hu és a Billingo kulcsára.

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 – helyesbítő számla a saját úton nem állítható ki; a járható út a sztornó és az új, helyes számla (13.5, 26.1). A kártya szövege ebben a pontban a külső számlázós utat írja le, nem a sajátot.

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).

[TISZTÁZANDÓ · T-07] Dokumentálható-e a „lezárás” pillanataként a tranzakció véglegesítése, ha feléd a visszaigazolás csak a hálózati válasszal érkezik meg – a kettő között elveszett válasznál a számla létezik, a kártya viszont hálózati hibát mutat.

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. A Beállításokban látható „számlaszám-előtag” mező a szamlazz.hu hitelesítő adatait írja, nem ezt. Következmény: a saját út előtagja 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).

[TISZTÁZANDÓ · T-08] Dokumentálható-e egyáltalán a saját előtag választhatóságaként – a felületen ma nincs beviteli pont hozzá.

[TISZTÁZANDÓ · T-09] Mi a szándékolt viselkedés, ha a felhasználó év közben előtagot vált (folytatás vagy új tartomány) – a kód új tartományt nyit, szabály nincs kimondva.

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 saját úton ezek ma nem elérhetők – lásd 26.1).
• 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

• Harmadik országbeli vevő címe. A vevő címéhez nincs országmező, a rendszer belföldi (HU) országkódot ír ki. Az EU-n kívüli vevő címe így hibás országkóddal menne ki.
• 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, a közmű- és a pénzforgalmi jelölés. A NAV-adatszerkezet ezeket ismeri, de a vázlat-bemenetben nincs mező hozzájuk.
• Nincs időszakos elszámolás és gyűjtőszámla a saját úton.
• 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 alanyi adómentesség-jelölése ma nem tölthető (nincs forrása). Ez alanyi adómentes (AAM) tételeknél problémát okozhat, mert a NAV a jelölést elvárhatja – a nyitott kérdést a T-37 tétel tartalmazza.
• 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);
• 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.

[TISZTÁZANDÓ · T-11] Külföldi (nem EU) vevő címének országkódja – a kód fixen HU-t ír ki; dokumentálandó-e ez korlátként, vagy javítás előtt áll.

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 nem érhető el. A rendszer két helyen is elutasítja, ezzel a mondattal: „A saját (NAV-közvetlen) számlázáson a díjbekérő PDF-je még nem érhető el (a számláké igen). Az adatait a részletek-kártyán meg tudom mutatni.”
• Ebből következően a díjbekérő e-mailben sem küldhető ki a saját úton. A kiküldés a saját számlakép-renderelőt használja, az pedig díjbekérőnél hibát ad – a küldés elakad, a fenti üzenettel.
• 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. Ezzel szemben a díjbekérő megerősítő kártyájának lábszövege azt mondja, hogy a bizonylat „később törölhető” – ez a mondat a külső számlázós útra igaz, a sajátra nem. A mérvadó a fenti elutasítás.
• 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.

[TISZTÁZANDÓ · T-12] A DIJB előtag rögzített – dokumentálandó-e külön szabályként, hogy a felhasználó ezt nem tudja megváltoztatni.

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 Elhatárolás a külső számlázós úttól

Ha a fiókod nem a saját NAV-úton, hanem külső számlázó szolgáltatón (szamlazz.hu vagy Billingo) keresztül működik, a nyugta változatlanul elérhető – de ott a bizonylatot teljes egészében a külső szolgáltató állítja elő, a sorszámot is ő adja, nem a titkár.ai kiosztója. A saját úton nincs mire visszaesni: ezen az úton a program szándékosan nem épít külső szolgáltató-kapcsolatot, és soha nem esik vissza rá.

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.

[TISZTÁZANDÓ · T-13] A doksinak ki kell-e mondania, hogy a titkár.ai a saját úton NEM nyugtaadási program a 23/2014. NGM rendelet 2. §-a értelmében – ez a 10. § (2) szerinti funkciólista-fejezetet (21.) is érinti; a kódból csak a funkcióhiány igazolható, a jogi minősítés nem.

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.

[TISZTÁZANDÓ · T-14] A napi automatikus futás 06:15 UTC-kor indul, és az esedékességet is UTC-nap alapján számolja – a dokumentációban magyar idő szerint mikorra ígérjük a kiállítást?

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

A saját (NAV-közvetlen) úton érvénytelenítés (sztornó) érhető el; helyesbítő (módosító) okirat nem. Ez a fejezet előbb a mögöttes lánc-modellt írja le, mert a sztornó helyessége ezen áll vagy bukik, majd a sztornó folyamatát, végül a hiányzó funkciók 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 összes hatásos tételsora szerepel benne negálva – nemcsak az eredeti számláé, hanem a korábbi módosítók által hozzáadott soroké is –, folytatólagos lánc-indexszel.
• 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 nincs

A saját úton helyesbítő számla nem állítható ki. A korlát két, egymástól független ponton áll: a szándék jelzésekor (amikor helyesbítőt kérsz) és a kiállítás-szolgáltatásban biztonsági hálóként.

Amit látsz:

„A saját (NAV-közvetlen) számlázáson a helyesbítő számla még nem érhető el. Amíg elkészül: ha a számla adata hibás, sztornózd, és állítsd ki újra a helyes adatokkal – az eredmény jogilag ugyanaz.”

A módosítás–érvénytelenítés körében a két út így viszonyul egymáshoz:

A saját úton 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

• A saját úton csak sztornó van; módosító (MODIFY) okiratot a program ezen az úton egyáltalán nem állít elő.
• 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 egyik úton sem sztornózható innen – ezekről csak a NAV összesítő adatai állnak rendelkezésre.
• Gyakorlatilag ma csak a saját úton kiállított számla sztornózható a saját úton. A külső vagy migrált gyökér NAV-ból történő felvételére van eljárás, de a sztornó folyamata nem hívja meg: felvett lánc nélkül a kiosztó elutasít.
• A sztornó nem vonható vissza. A lánc állapota egyirányú: nyitott → lezárt. A lánc újranyitására nincs funkció.
• Ha a sztornó NAV-beküldése elhasal, a helyi állapot már megváltozott (az eredeti számla sztornózott, a sztornó okirat létrejött, a lánc lezárt). 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 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á. Ilyenkor a számlát sztornózni kell, és a helyes adatokkal újra kiállítani.
• 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: sztornózz, majd állítsd ki újra a helyes adatokkal. A jogi eredmény ugyanaz, mint a helyesbítőnél.
• Sztornó 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), ne az újraküldéssel próbálkozz: sztornózz és állíts ki új, helyes bizonylatot.

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.

[TISZTÁZANDÓ · T-16] A külső számlázós időszakból származó, a saját nyilvántartásunkban lévő számla sztornózható-e a saját úton – a sztornó folyamata nem hívja a lánc-szinkronizálást, tehát ma nem; kimondjuk-e ezt explicit, önálló korlátként?

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 mindig normál (NORMAL) számlát küld. Ebből következően a saját úton nem érhető el: egyszerűsített számla, áfatartalom szerinti elszámolás, különbözeti adózás (MARGIN) és a NO_VAT besorolás. Az adatszolgáltatás-előállító ismeri az egyszerűsített és a gyűjtőszámla-kategóriát, de a saját kiállítás nem használja.
• 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

• Díjbekérőhöz a saját úton nincs PDF. Amit látsz: „A díjbekérő PDF-je a saját úton még nem elérhető.” Ennek oka szerkezeti: a díjbekérőhöz nem tartozik NAV-adatszolgáltatás, tehát nincs az az eltárolt XML, amiből a kép épülne. A díjbekérő adatait a részletek kártyán meg tudja mutatni a program.
• 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.

[TISZTÁZANDÓ · T-18] Állíthatja-e a dokumentáció, hogy az újragenerált PDF bitre azonos – a PDF-motor verziófrissítése a sablon-verzió léptetése nélkül is megváltoztathatja a kimenetet; van-e verzió-rögzítés vagy a lenyomatra futó determinizmus-regressziós teszt? A jelenlegi tesztek csak azt mérik, hogy valódi PDF keletkezik és a kötelező mezők jelen vannak.

(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) útra 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. Ha a fiókod még külső számlázón (szamlazz.hu vagy Billingo) keresztül állít ki számlát, az adatszolgáltatást az a program végzi, és arról az ő dokumentációja szól – az alábbiak akkor 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

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.

Korlát, kimondva: 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 a gyakorlatban azt jelenti: a legelső saját kiállításodat nem tudod megcsinálni, ha épp NAV-üzemzavar van. A rendszer kézi cégadat-megadást nem kínál.

[TISZTÁZANDÓ · T-19] Ez ellentétes a 13/B. § szellemével (a NAV kiesése ne akadályozza a számlázást) – a döntés az, hogy ezt korlátként dokumentáljuk, vagy a kiállítási utat javítjuk?

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 pillanatában nem kapsz automatikus visszajelzést az adatszolgáltatásról. A kiállítás eredménye a számlaszám – a beküldés státusza nincs benne. (A kártya a számlaszám mellé írt „· NAV-nak jelentve” felirata a bizonylat létrejöttét jelzi, nem a NAV visszaigazolását – lásd 7.6.) Az első beküldési kísérlet hibája a szerver naplójába kerül, nem a felületre. A tudomásszerzés útja: rákérdezés (16.8), vagy a kontroll-sáv jelzése, ami 4 óra elteltével jelenik meg. [TISZTÁZANDÓ · T-20] A 4 óra a rendszer saját küszöbe, nem jogszabályi határidő – a doksi megfogalmazása („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 elakadt”) elfogadható-e?
• Nincs helyesbítő (MODIFY) számla a saját úton. A rendszer csak CREATE és STORNO műveletet állít elő. Hibás adat esetén az út: sztornó + újra kiállítás a helyes adatokkal.
• Nincs előlegszámla és végszámla a saját úton.
• 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).

A számlázási út későbbi megváltoztatása nem zárja el a funkciót. A hozzáférés a számla kibocsátóján dől el, nem a fiókod mai beállításán: ha egy időszakban a saját úton számláztál, majd külső számlázóra váltottál, a régi, saját kibocsátású számláidra továbbra is le tudod kérni az adatszolgáltatást – a chatben is, a letöltő útvonalon is. Ez így helyes: a 11/A. § szerinti kötelezettség a kibocsátáshoz tapad, nem a jelenlegi beállításhoz.

Elutasítás egyetlen esetben van, és az a chatben indított útra vonatkozik: ha a fiókod külső számlázón áll, és a kért szűrőre egyetlen exportálható saját számla sem jön ki (tehát olyan sem, amelyhez van visszaolvasható eltárolt adat – 17.5). Ilyenkor a rendszer magyar mondattal megmondja, hogy az adatszolgáltatást a számláidat ténylegesen kibocsátó programban kell lekérned – üres fájl helyett, mert egy ellenőrzésen egy néma, üres export félrevezető volna. A közvetlen letöltő útvonalon ez a terelés nincs meg: ott ugyanez az eset számlát nem tartalmazó, üres XML-t ad.

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.

[TISZTÁZANDÓ · T-21] A fejlesztési terv az export „időbeli hatályát” döntendőként hagyta nyitva; a kód forrás-alapú hatályt valósít meg. A doksi ezt a megfogalmazást rögzítse-e véglegesként?

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 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.”

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. (Kivétel a 17.1 pont végén leírt eset: külső számlázón álló fióknál az üres eredmény helyett a terelő mondat jelenik meg.)

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 két dolgot tesz:

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.

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).
• 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.

[TISZTÁZANDÓ · T-24] Megépüljön-e a 3 munkanapos határidő követése (munkanap-számláló és külön figyelmeztetés a manuális teljesítésre), vagy marad a kötelezettség kimondása?

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.

[TISZTÁZANDÓ · T-42] A kézi (nyomtatvány) számla adatszolgáltatási határideje: a 13/A. § (1) szerinti azonnali kötelezettség a gép-gép kapcsolatra vonatkozik, a kézi számlára naptári napban mért határidő él (4 naptári nap, magasabb áthárított adónál rövidebb). A pontos értéket jogi ellenőrzéssel kell rögzíteni, mielőtt ez a dokumentum számot ír le.

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. [TISZTÁZANDÓ · T-23] A doksi leírja-e lépésről lépésre a NAV-felületi kézi érvénytelenítés menetét, vagy elég a korlát kimondása és a NAV-felületre irányítá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 sztornó + újra kiállítás (helyesbítő számla nincs – lásd 16.9); 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 még nem épült meg.
• 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. [TISZTÁZANDÓ · T-25] A doksi kimondja-e, hogy az adatszolgáltatás nyilvántartása a beküldési napló, vagy a tevékenységnaplót ki kell egészíteni a 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.

[TISZTÁZANDÓ · T-26] Ez a fejezet a 10. § (2) szerinti „nem-számlázási funkció” elhatárolásaként szerepeljen-e (ahogy fent), vagy önálló funkcióleírásként a fő részben?

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).

A saját (NAV-közvetlen) úton 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 (jelölve, hogy külső rendszerbe nem ment fel). A napló ellenőrzési nyom, nem marketingszöveg.

Külső számlázón (szamlazz.hu) kiállított számlánál a befizetés a számlázó fizetési jegyzékébe is felmegy, és a helyi „kifizetve” jelölés csak teljes kiegyenlítésnél billen át – a részfizetést ott a számlázó tartja nyilván.

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 107 eszközből áll, és minden felhasználónál, minden csomagban ugyanez a 107 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 – alapértelmezésben nincs bekapcsolva, tehát ez a két eszköz nincs jelen (26.4).

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

Ezek a funkciók nem küldenek adatot a NAV-hoz, és tájékoztató jellegűek. Az áfa minősítése, a bevallás összeállítása és beadása a te (illetve a könyvelőd) feladata. Az eÁFA gépi beadása alapértelmezésben ki van kapcsolva (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

A rendszer semmilyen bevallást nem ad be és semmilyen adót nem fizet be – sem iparűzési adót, sem áfát. Ezek a funkciók kizárólag emlékeztetnek.

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

10. Asszisztens-funkciók – mind minden csomagban

11. Külső számlázóból történő import – a saját úton nem értelmezett

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 107 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, storno_receipt),
• minden törlés (delete_partner, delete_proforma, delete_recurring_invoice),
• minden e-mail-küldés a vevőnek (prepare_send_invoice_email, prepare_bulk_email, send_receipt),
• 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 asszisztensnek nincs eÁFA-beadó eszköze (alapállapotban a beadási eszközök nincsenek is a készletben), és nincs fizetésindító eszköze.
• 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 (12 funkció): díjbekérő készítése és törlése, számla-import, 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ő (60 funkció): az alap kimenő számlázás, a nyugta, 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 107 eszközt (31 + 12 + 60 + 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.

23.5 Nyitott kérdés

[TISZTÁZANDÓ · T-28] A Free csomag 3 mentett partneres kerete az ÁSZF 5. pontjának csomagtáblázatában nem szerepel. Felvegyük-e ide működési korlátként – és ha igen, az ÁSZF-et is ki kell egészíteni, hogy a két dokumentum ne mondjon mást?

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 a saját úton kevesebb jog elég. A program minden felületen ugyanazt mondja, útonként megkülönböztetve:

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 a saját (NAV-közvetlen) úton nincs PDF-je és nincs eltárolt XML-forrása (a díjbekérő nem számla, adatszolgáltatás nem tartozik hozzá).

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 Nyitott kérdések

[TISZTÁZANDÓ · T-30] Vállalunk-e ebben a dokumentációban bármilyen konkrét megőrzési időt a program oldalán (pl. „az előfizetés fennállása alatt korlátlanul, a fiók törlése után nem”)? A kérdés két másik ponton is felmerül: meddig őrizzük az eltárolt számlaadat-XML-t (ezen múlik a számlakép előállíthatósága és így a 8 éves megőrzés teljesíthetősége – 15.6), és a fiók törlésekor kaszkádoló törlés (19.5, 25.2). A megőrzés hitelesség- és sértetlenség-kérdése a fejlesztési tervben még nyitott.

[TISZTÁZANDÓ · T-31] Az Adatkezelési tájékoztató 12. pontja a törlési jog gyakorlási módjaként „fiók törlése a beállításokban” utat ígér; a kódban ilyen önkiszolgáló út nincs. Melyik igazodjon melyikhez – épüljön meg a felület, vagy javítsuk a tájékoztatót?

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, sztornó, 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 és gyűjtőszámla – a lefedettség-bővítés még hátra van.
• 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ó. 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.
• 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.
• Az eÁFA gépi beadása ki van kapcsolva. Az áfabevallást a NAV eÁFA-felületén kell beadnod. Az ok: a beküldési lánc a NAV éles környezetében még nincs igazolva, és egy csendben elhasaló beadás rosszabb, mint a hiánya. A helyi áfa-analitika, az adókód-javaslat és az áfakód-lekérdezés ettől függetlenül működik – 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 sztornózása első körben megtagadva.
• 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 = 1.0). 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 verziószám a dokumentum saját számozása; a NAV felé jelentett softwareMainVersion ettől független (2.4, T-32).

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

• A softwareMainVersion értéke rögzített 1.0. A programkódban nincs olyan mechanizmus, amely léptetné, és nincs kapcsolatban a csomagverzióval.
• 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.
• Nincs kódszintű mechanizmus a dokumentum átadásának igazolására (például regisztrációkori tudomásulvétel időbélyeggel).
• A korábbi verziók verziószám szerinti, önálló letöltési pontja még nincs megépítve (T-33). Amíg nincs, a korábbi verziót 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 (1.1).

27.6 Nyitott kérdések

[TISZTÁZANDÓ · T-32] Verziópolitika – mi lépteti a softwareMainVersion értékét, és hogyan kapcsolódik ehhez a dokumentum verziószáma? A 10. § (3) miatt ezt kimondott szabályként kell rögzíteni (lásd még 2.4).

[TISZTÁZANDÓ · T-33] Az átadás bizonyítása – appon belüli, verziózott, letölthető dokumentum és regisztrációkori tudomásulvétel időbélyeggel. Ez még nincs megépítve; a megépítéséig a dokumentum átadása nem igazolható géppel.

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 Nyitott kérdések – a jogi dokumentumokkal való ütközések

Az alábbiakat a dokumentum kiadása előtt rendezni kell, mert a hatályos jogi dokumentumok jelenleg mást állítanak, mint amit a saját (NAV-közvetlen) út csinál.

[TISZTÁZANDÓ · T-34] ÁSZF 3. pont – „a szolgáltatás használatához a Felhasználónak saját szamlazz.hu fiókja és Számla Agent kulcsa szükséges. A számlák a Felhasználó saját szamlazz.hu fiókján keresztül… kerülnek kiállításra.” A saját úton ez nem igaz: nincs külső számlázó-fiók, a számlát a titkár.ai állítja ki. Az ÁSZF 2. pont „Számla Agent kulcs” fogalma és az 5.2 díj-elkülönülés is külső számlázót feltételez.

[TISZTÁZANDÓ · T-35] Adatkezelési tájékoztató 5. pont – „A számlák kiállítását és a NAV felé történő adatszolgáltatást a szamlazz.hu (KBOSS.HU Kft.) végzi”, és a KBOSS.HU az adatfeldolgozói táblázatban is így szerepel. A saját úton az adatszolgáltatást a BITNEX GROUP Kft. saját programja végzi közvetlenül.

[TISZTÁZANDÓ · T-36] ÁSZF 8.1 – a felelősség-kizárás „a szamlazz.hu vagy a NAV rendszereinek működéséből” fordulata a saját úton csak a NAV-ra értelmezhető.

[TISZTÁZANDÓ · T-37] Kiállítói törzsadatok. A programban nincs fiók-szintű saját cégadat-séma (áfakód, megyekód, közösségi adószám, alanyi adómentesség, pénzforgalmi elszámolás); a kiállítói blokkot ma a NAV adóalany-lekérdezésének pillanatképe adja (6.8, 16.6). Ebből következik, hogy a kiállító közösségi adószáma és alanyi adómentesség-jelölése nem tölthető (9.12, 14.7) – az üzembe helyezési fejezet ehhez sémát igényel.

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-10, T-15, T-17, T-22, T-27, T-29, T-39, T-40, T-41) megoldott, lezárt tételek: a programban megtörtént a javítá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.

Hatálybalépés: 2026. augusztus 4. · Verzió: 1.1