Odoo, n8n és AI: egy magyar KKV automatizálási ütemterve 2026 utolsó negyedévére

Egy magyar KKV automatizálása 2026 őszén már nem technológiai kérdés, sokkal inkább sorrendi. Július végén megújult a Model Context Protocol (MCP) specifikációja, augusztus vége és szeptember közepe között pedig szinte egymás sarkát taposva érkezett az n8n három kiadása, az OpenAI Agents API nyilvános bétája és a Salesforce „munkára kész” ügynökportfóliója. Aki most indul, annak minden eszköz a kezében van, csak azt kell eldöntenie, mivel kezdjen, ki feleljen érte és mikor élesítsen úgy, hogy az év végi zárás ne boruljon fel.

Az alábbi ütemterv egy képzeletbeli, 18 fős székesfehérvári épületgépészeti cég példáján mutatja meg, hogyan lehet október 1-je és december 23-a között, nagyjából 60 munkanap alatt három folyamatot rendbe tenni Odoo-val, n8n-nel és egy nyelvi modellel: a beérkező leveleket, a szállítói számlákat és az ajánlatkérések utánkövetését. A cég és a számai szemléltető jellegűek, a dátumok viszont a valódi 2026-os naptárhoz igazodnak, a technológiai adatok pedig a 2026. szeptember 22-i állapotot tükrözik.

Röviden

• Egy 5 és 50 fő közötti magyar cégnél a legjobb sorrend 2026 utolsó negyedévében a beérkező e-mail, utána a szállítói számla, végül a lead-utánkövetés, mert így minden lépés a korábbira épül, a kockázat pedig fokozatosan nő.
• A 90 napos terv három, egyenként nagyjából 30 napos szakaszra bomlik, az október 30-i, november 30-i és december 17-i mérföldkövekkel, december 18-a után pedig változtatási tilalom jön az ünnepek és az év végi zárás miatt.
• Saját becslésünk szerint egy 18 fős cégnél a három folyamat havi nagyjából 60 munkaórát szabadít fel, ami körülbelül 258 000 Ft bérköltségnek felel meg, a nagyjából 1,07 millió forintos egyszeri bevezetési költség pedig teljes üzemben öt hónap körül térülhet meg.
• Az AI-modell díja ebben a méretben elhanyagolható: az OpenAI árlapja szerinti gpt-6-luna modellel a becsült havi tokenköltség 300 Ft körül marad, a valódi költséget a bevezetés és a karbantartás munkaórái adják.
• A projektek többsége nem a technológián csúszik el, hanem a túl széles jogosultságokon, a rendezetlen Odoo-partnertörzsön és azon, hogy senki nem felel név szerint a folyamatért.
• Kis volumennél, például napi 15 levél és havi 30 számla mellett a teljes csomag nem térül meg belátható időn belül, ilyenkor a beépített Odoo-funkciók és egyetlen jól megválasztott folyamat a jobb választás.

Miért most érdemes elkezdeni egy KKV automatizálását?

Azért, mert 2026 őszére minden építőelem elérhető és megfizethető: az n8n három kiadásban erősítette meg az AI- és biztonsági funkcióit, a kis nyelvi modellek ára egy KKV tipikus levélforgalmánál havi néhány száz forint, a negyedik negyedév naptára pedig pont elég egy háromlépcsős bevezetéshez. A szűk keresztmetszet ma a sorrend és a felelős, nem a technológia.

A szeptemberi hírfolyam jól mutatja, milyen gyorsan érett be a terület. Az OpenAI szeptember 10-én nyilvános bétába tette az Agents API-t, amely munkamenet-kezelést, automatikus kontextustömörítést és alügynököket kínál külön orchestration-díj nélkül. Az n8n az augusztus 25-i 2.37-es és a szeptember 15-i 2.40-es verzió között három kiadásban hozott adminisztrátor által kezelt hitelesítő adatokat, szigorúbb titokkitakarást és jobb MCP-hibakezelést. A Salesforce szeptember 15-én olyan ügynököket jelentett be, amelyek akár hetekig tartó célokat is követnek, a HubSpot pedig szeptember 19-én közölte, hogy Pro Plus ügyfeleinek 19%-a használt már ügynököt augusztusban, az ügynöki műveletek száma pedig havonta 3,5-szeresére nőtt.

A nagyvállalati hírekből egy 18 fős cégnek annyi következik, hogy az ügynökök a nagy CRM-rendszerekben egyre inkább a mindennapi működés részévé válnak, a különbséget pedig nem a licencekre költött összeg, hanem a bevezetés fegyelme adja: ki mit mér, ki hagy jóvá és mi történik, ha valami elromlik.

Hogy a fegyelem miért nem túlzás, azt az Artificial Analysis és a Zapier 2026. július 6-án közzétett AutomationBench-AA tesztje mutatja meg a legjobban. A 657 feladatból, hat üzleti területből és 40 szimulált SaaS-alkalmazásból álló mérésen a legjobb modell, a Claude Fable 5 is csak a feladatok 48,6%-át oldotta meg szabályosan, ráadásul mindegyik vizsgált modell megsértett üzleti szabályokat, feladatonként 0,46 és 1,26 közötti gyakorisággal. A pénzügyi feladatoknál a sikerességi arány feleakkora volt, mint az ügyfélszolgálati és operációs feladatoknál. Azóta érkeztek újabb modellek, az üzenet mégis érvényes: a gép gyors és olcsó, de jóváhagyási pontok nélkül nem bízható rá a cég pénze.

A mostani kezdés mellett a naptár is szól. A 2026-os negyedik negyedévben október 1-je és december 23-a között 60 munkanap van, ha az október 23-i pénteki ünnepet kivesszük és a december 12-i szombati munkanapot beszámítjuk. December 24-e az idei naptárban áthelyezett pihenőnap, 25-e és 26-a ünnep, a két ünnep közötti hét pedig a legtöbb cégnél félgőzzel megy. Ez pont három, egyenként négy-öt hetes szakaszra elég. Ha minden rendben megy, januárban már egy tiszta, mért rendszerrel indulhat az új év, épp akkor, amikor a könyvelőnek az éves zárás mellett a legkevesebb ideje jut bármi újra.

Odoo, n8n és AI: így osztják fel egymás között a munkát

A három eszköz nem egymás versenytársa, hanem egy csapat három tagja, akiknek világosan elhatárolt feladatuk van. Ha ezt az elején tisztázod, a későbbi döntések nagy része magától megszületik.

Az Odoo egy moduláris, nyílt forráskódú alapokra épülő vállalatirányítási (ERP) rendszer, amelyben a számlázás, a könyvelés, a CRM, az értékesítés és a készlet ugyanabban az adatbázisban él. Az Odoo hivatalos GitHub-tárolója szerint 2026. szeptember 22-én a legfrissebb stabil főverzió a 19.0, a fejlesztői ágon pedig már a következő kiadás készül. Az Odoo évente ad ki új főverziót, ezért egy negyedéves projektnél azt javasoljuk, hogy maradj a futó verzión, a verzióváltást pedig külön, az automatizmusok újratesztelésével együtt ütemezd. Magyar szempontból lényeges, hogy a 19.0-s verzióban elérhető magyar e-számlázási modul (Hungary E-invoicing) a manifestje szerint elvégzi a számlák adatszolgáltatását a NAV felé, valamint NAV 3.0 formátumú adóhatósági ellenőrzési adatexportot készít.

Az n8n egy munkafolyamat-automatizáló platform, amelyben a folyamatokat vizuális csomópontokból (node-okból) raksz össze: egy indító esemény (trigger) elindítja, a további lépések adatot kérnek le, átalakítanak, döntenek vagy üzenetet küldenek. Több mint 1 500 integrációt kínál, fair-code licenc alatt fut, a saját szerveren futó ingyenes Community Edition és a felhős előfizetés között pedig szabadon választhatsz. Az n8n dokumentációja szerint a beépített Odoo node partnereket (Contact), jegyzeteket (Note), lehetőségeket (Opportunity) és tetszőleges egyedi erőforrásokat (Custom Resource) tud létrehozni, lekérdezni, módosítani és törölni, ráadásul AI-ügynök eszközeként is használható. Az utóbbi azt jelenti, hogy egy nyelvi modell maga döntheti el, mikor kérdezzen le vagy hozzon létre valamit az Odoo-ban, ezért kell majd nagyon pontosan beállítani, mihez férhet hozzá.

A nyelvi modell (LLM, large language model) olyan AI-rendszer, amely szöveget ért meg és állít elő: kategorizál, adatot nyer ki egy számla szövegéből, összefoglal és levélvázlatot ír. Ebben a felállásban a modell soha nem közvetlenül dolgozik az Odoo-ban, hanem az n8n-en keresztül kap feladatot, a kimenetét pedig az n8n ellenőrzi, mielőtt bármi a rendszerbe kerülne.

Egy konyhai hasonlattal az Odoo a kamra és a receptkönyv, ahol minden adat egy helyen, rendben van. Az n8n a konyhafőnök, aki tudja, mikor mit kell elővenni és kinek továbbadni. Az AI pedig egy nagyon gyors, de néha túl magabiztos szakácsgyakornok, aki remekül szeletel és kóstol, a számlát viszont nem írhatja alá. Amíg ez a munkamegosztás megmarad, a rendszer átlátható és javítható, ha pedig összemosódik, jellemzően ott kezdődnek a bajok.

Zapier vagy Make helyett azért esik a választás ebben a példában az n8n-re, mert futtatásonként számláz, függetlenül attól, hány lépésből áll a folyamat, mert saját szerveren is futtatható, ami adatvédelmi szempontból kényelmes, végül mert kész Odoo-kapcsolata van. A platformok részletes összevetése külön témát érdemel, de ha nálad már Zapier vagy Make fut, az ütemterv logikája azokkal is ugyanúgy működik.

Mit érdemes elsőként automatizálni: e-mailt, számlát vagy lead-utánkövetést?

Az e-maillel érdemes kezdeni, mert ott a legnagyobb a volumen, a legkisebb a hiba ára, ráadásul ez a másik két folyamat bejárata is, hiszen a számlák és az ajánlatkérések nagy része levélben érkezik. Második a szállítói számla, a harmadik a lead-utánkövetés, amely a legtöbb üzleti hasznot hozhatja, de a legtisztább CRM-adatot igényli.

A sorrendet nem megérzésből érdemes felállítani, hanem néhány egyszerű szempont alapján. A képzeletbeli székesfehérvári cégünknél, ahol a napi munkát egy irodavezető, egy pénzügyi munkatárs és két értékesítő viszi, a három jelölt így néz ki:

A táblázatból az is látszik, miért nem a leglátványosabb folyamattal indulunk. A lead-utánkövetés hozhatja a legtöbb pénzt, hiszen egy elfelejtett ajánlat ára akár egy teljes megrendelés lehet, csakhogy ehhez az Odoo CRM-nek már rendben kell lennie, a leadeknek pedig jórészt a már automatizált postafiókon keresztül kell beérkezniük. Ha fordított sorrendben haladnál, az első hónapban adattisztítással telne az idő, látható eredmény nélkül, ami a csapat lelkesedését gyorsabban elviszi, mint bármilyen technikai hiba.

Beérkező e-mail: címke, prioritás, vázlat

Az első folyamat a közös postafiókokat (például info@ és ajanlat@) rendezi. Az n8n minden új levélnél lekéri a feladót, megkeresi az Odoo partnertörzsében, a nyelvi modell pedig a tartalom alapján besorolja egy előre rögzített kategóriába: ajánlatkérés, számla, reklamáció, szerviz, szállítói levél vagy egyéb. A besorolás mellé a modell rövid összefoglalót és sürgősségi jelzést ad, a gyakori kérdésekre pedig válaszvázlatot készít, amelyet egy ember küld el vagy dob el. Semmi nem megy ki automatikusan, a folyamat az első hónapban csak rendez, javasol és mér.

Szállítói számla: kinyerés, egyeztetés, piszkozat

A második folyamat a „számla” címkét kapott leveleket veszi át. A PDF-mellékletből a modell kinyeri a szállító adószámát, a számlaszámot, a teljesítés dátumát, a nettó és bruttó összeget, valamint az ÁFA-kulcsokat, az n8n pedig ezek alapján piszkozat állapotú szállítói számlát hoz létre az Odoo-ban. A könyvelésbe és a fizetési sorba csak emberi jóváhagyás után kerül, az eltéréseket (ismeretlen szállító, nem egyező összeg, hiányzó mező) pedig külön listán kapja meg a pénzügyi munkatárs. A beolvasott, nem kereshető PDF-ek kezeléséhez külön OCR-lépés kellhet, ezt a mintagyűjtésnél érdemes felmérni.

Lead-utánkövetés: a CRM-ben nem vész el semmi

A harmadik folyamat az „ajánlatkérés” kategóriájú levelekből és a weboldal űrlapjából lehetőséget (Opportunity) hoz létre az Odoo CRM-ben, a felelős értékesítőhöz rendeli, majd figyeli a határidőket. Ha egy ajánlatra három munkanapja nem jött válasz, a modell személyre szabott utánkövető levelet fogalmaz az Odoo-ban tárolt előzmények alapján, amelyet az értékesítő egy kattintással jóváhagy vagy átír. Hetente egyszer összesítő is érkezik az értékesítési vezetőnek a beragadt lehetőségekről, így a hét eleji megbeszélés nem emlékezetből megy.

Hogyan készülj fel még szeptember utolsó napjaiban?

A felkészülésre egy hét elég, de ezen a héten dől el a legtöbb projekt sorsa. Szeptember 23-a és 30-a között jelöld ki a felelősöket, mérd meg a kiinduló állapotot, rendezd a hozzáféréseket és egyeztess a könyvelővel, így október 1-jén már építeni lehet, nem vitatkozni.

• Jelöld ki a szponzort és a folyamatgazdákat. A szponzor jellemzően az ügyvezető, aki a prioritásokról és a keretről dönt. Mindhárom folyamatnak legyen egy név szerinti gazdája: a példacégnél a postafiókért az irodavezető, a számlákért a pénzügyi munkatárs, a leadekért az értékesítési vezető felel.
• Mérd meg a kiinduló állapotot egy teljes héten át. Számold meg, hány levél érkezik naponta a közös címekre, mennyi ideig tart egy szállítói számla rögzítése, továbbá hány óra telik el egy ajánlatkérés beérkezése és az első válasz között. Egy egyszerű táblázat elég, a lényeg, hogy decemberben legyen mihez hasonlítani.
• Írd le a mostani folyamatokat egy-egy oldalon. Ki nyitja meg a levelet, hová továbbítja, ki rögzíti a számlát, ki hagyja jóvá, mi történik szabadság idején. A leírásból derül ki, hol vannak a kivételek, amelyekre az automatizmust fel kell készíteni.
• Leltározd a hozzáféréseket. Nézd át, kinek van adminisztrátori joga az Odoo-ban, a Google Workspace- vagy a Microsoft 365-fiókban, majd hozz létre egy külön, technikai Odoo-felhasználót az integrációnak, amelyhez saját API-kulcs tartozik. Az előfizetésednél ellenőrizd, hogy a csomagod engedi-e a külső API-hozzáférést, valamint azt, hogy a technikai felhasználó külön felhasználói helynek számít-e.
• Tisztítsd meg az Odoo partnertörzsét. Keresd meg a duplikált partnereket, a hiányzó adószámokat és az elírt cégneveket, mert az automatizmus ezek alapján azonosít, a szemét pedig itt hatványozottan jön vissza.
• Döntsd el a futtatási környezetet és a modellt. Az n8n futhat felhőben vagy saját szerveren, a nyelvi modellnél pedig már most döntsd el, melyik szolgáltatót használod és kell-e EU-s adattárolás. Ezek a döntések határozzák meg az adatfeldolgozói szerződéseket is.
• Egyeztess a könyvelővel. Kérd el tőle az ÁFA-kódok, a költséghelyek és a jóváhagyási értékhatárok aktuális listáját, majd beszéljétek meg, milyen formában szeretné látni a gépi előkészítésű számlákat. November elején ez a lista lesz a számlafolyamat gerince.
• Rögzítsd a sikerkritériumokat. Írd le mérhetően, mit tekintesz sikernek az egyes szakaszok végén, például hogy a levelek 90%-a a helyes kategóriába kerüljön, vagy hogy egy számla rögzítése átlagosan két perc alá csökkenjen.

Tipp: a kiinduló mérést ne hagyd ki azzal, hogy „úgyis tudjuk, mennyi idő megy el rá”. Tapasztalatunk szerint a becslések rendszeresen a valós érték felét vagy dupláját adják, a megtérülés számítása pedig csak annyit ér, amennyit a kiinduló adat.

30, 60, 90 nap: mérföldkövek és felelősök a negyedik negyedévben

A 90 napos terv három szakaszra bomlik, mindegyik ugyanazt a ritmust követi: előkészítés, építés, árnyékmód, élesítés emberi jóváhagyással, végül mérés és döntés. Az árnyékmód azt jelenti, hogy az automatizmus már dolgozik, de az eredményét csak összevetjük a kézi munkával, éles hatása még nincs.

A táblázat dátumai tudatosan kerülik a kockázatos napokat. Az október 23-i ünnep miatt az e-mailes élesítés hete csak négynapos, ezért ott nincs új fejlesztés, csak bekapcsolás és figyelés. A december 12-i szombati munkanapra nem teszünk élesítést, mert ilyenkor sok cégnél alacsony a jelenlét, egy hibát pedig nincs, aki észrevegye. A kilencvenedik nap formálisan december 29-ére esne, ez viszont a két ünnep közötti holt időszak, ezért az értékelést december 17-re hozzuk előre, a tartalék napokat pedig a befagyasztás előtti hétre hagyjuk.

Első szakasz: október 1-jétől 30-áig, a postafiók

Az első hónap célja nem a megtakarítás, hanem a bizalom. Ha az irodavezető két hét után azt látja, hogy a gép tíz levélből kilencet jó helyre tesz, a maradék egyet pedig ő javítja egy kattintással, akkor ő lesz a projekt legnagyobb szószólója. Ha viszont az első napokban téves továbbítások és furcsa hangnemű vázlatok jönnek, a projekt elvérzik, mielőtt a számlákig érne.

A fejlesztő október első másfél hetében megépíti a folyamatot, a kategórialistát pedig az irodavezető adja, nem a fejlesztő találja ki. A kategóriák száma maradjon hat és tíz között, mert a túl finom felosztásnál a gép és az ember is bizonytalanná válik. Az árnyékmódban minden levélnél rögzítjük, mit javasolt a gép és mit döntött az ember, így október 16-án már valódi, nem érzésen alapuló találati arány van a kezünkben. A 30 napos mérföldkő döntése egyszerű: ha a pontosság eléri a 90%-ot és a csapat használja a rendszert, mehet a következő szakasz, ha nem, novemberben még a postafiókot finomítjuk.

Második szakasz: november 2-ától 30-áig, a számlák

November a számlák hónapja, mert ilyenkor a könyvelő még nem az éves zárással foglalkozik, van ideje a szabályokat átnézni. Az első héten 50 valódi, a korábbi hónapokból vett szállítói számlán teszteljük a kinyerést, köztük szándékosan a problémásakkal: több ÁFA-kulcsos, devizás és helyesbítő számlákkal, valamint kézzel kiegészített példányokkal. Ha a PDF-ek jelentős része beszkennelt kép, itt derül ki, hogy kell-e külön OCR-lépés.

Az árnyékmód hetében a pénzügyi munkatárs továbbra is kézzel rögzít, a gép pedig párhuzamosan elkészíti ugyanazt piszkozatként. A kettő összevetéséből mezőnkénti hibaarány jön ki. Arra számíts, hogy az adószám és a végösszeg könnyebben megy, a teljesítési dátum és a költséghely viszont több figyelmet kér, hiszen az utóbbi nem is szerepel a számlán, azt a könyvelési szabályokból kell levezetni. Az élesítés után a piszkozat soha nem válik magától könyvelt számlává, a jóváhagyás a pénzügyi munkatárs vagy az általa kijelölt helyettes kezében marad.

Harmadik szakasz: december 1-jétől 17-éig, a leadek

December a lead-utánkövetésre azért jó, mert a karácsony előtti ajánlatkérések jelentős része januárban válik megrendeléssé, egy elfelejtett utánkövetés tehát ilyenkor a legdrágább. A szakasz eleje nem fejlesztés, hanem rendrakás az Odoo CRM-ben: egységes szakaszok (új, felmérés, ajánlat kiküldve, tárgyalás, megnyert, elvesztett), minden nyitott lehetőséghez felelős és következő lépés.

Az utánkövető vázlatokat az értékesítők hagyják jóvá, a heti összesítő pedig az értékesítési vezetőhöz megy. A tilalom alatt a fejlesztő ügyeletben figyeli a hibanaplót, a rendszerhez pedig csak akkor nyúl, ha egy folyamat leállt.

Ki miért felel?

A felelősségi mátrix (angolul RACI) azt rögzíti, ki végzi a munkát, ki dönt, kivel kell egyeztetni és kit kell tájékoztatni.

A táblázat legfontosabb sora az, amelyik a legkevésbé látványos: a folyamatgazdáé. Ő az, aki eldönti, hogy egy furcsa levél reklamáció vagy szervizkérés, aki szól, ha a gép rendszeresen ugyanabban téved, végül aki szabadság előtt kijelöli a helyettesét.

Mennyibe kerül és mikor térül meg forintban?

Saját becslésünk szerint a képzeletbeli 18 fős cégnél a három folyamat bevezetése nagyjából 1,07 millió forint egyszeri költség, a havi üzemeltetés pedig 40 000 és 53 000 Ft között mozog. A felszabaduló munkaidő havi 258 000 Ft körüli bérköltségnek felel meg, így teljes üzemben öt hónap körüli a megtérülés, óvatosabb feltevésekkel viszont 14 hónap is lehet.

Az alábbi számítás becslés, a menetét azért mutatjuk meg lépésenként, hogy a saját számaiddal újra tudd számolni. Az euróban és dollárban megadott árakat 2026. szeptember 21-i árfolyammal számoltuk át (1 euró nagyjából 364 Ft, 1 dollár kerekítve 320 Ft). Az Odoo-előfizetés nem szerepel a számításban, mert a példacég már használja. Ha nálad még nincs Odoo, a felhasználónkénti havidíjat a hivatalos árlapon nézd meg, majd add hozzá a havi költségekhez.

A megtakarítás becslése

A megtakarítást folyamatonként a mért volumen és az egy tételen megspórolt idő szorzataként számoljuk:

• Beérkező e-mail: napi 60 levél, havi 21 munkanappal 1 260 levél. Ha a kézi osztályozás, továbbítás és partnerkeresés levelenként 3 percről 1,5 percre csökken, az 1 890 perc, vagyis 31,5 óra havonta.
• Szállítói számla: havi 250 számla. Ha a rögzítés 6 percről 2 perc ellenőrzésre csökken, az 1 000 perc, azaz nagyjából 16,7 óra.
• Lead-utánkövetés: havi 80 új ajánlatkérés. Ha a CRM-rögzítés, az emlékeztetők és az utánkövető levelek leadenként 15 percről 5 percre csökkennek, az 800 perc, vagyis körülbelül 13,3 óra.

A három együtt havi 61,5 óra. Az óradíjhoz tegyük fel, hogy egy adminisztratív munkatárs bruttó bére 650 000 Ft, erre jön a 13%-os szociális hozzájárulási adó, így a munkáltatói költség 734 500 Ft. Havi nagyjából 174 munkaórával osztva ez körülbelül 4 200 Ft óránként, a 61,5 óra tehát nagyjából 258 300 Ft havi bérköltségnek felel meg.

A költségek becslése

Az n8n árai a hivatalos árlapról származnak: éves számlázással a Starter havi 20, a Pro havi 50 euró, a táblázatban a drágább, havi számlázású árral számoltunk. Egy futtatás az n8n szerint a teljes munkafolyamat egyszeri lefutása, függetlenül a lépések számától. A példacégnél a havi igény nagyjából 1 900 futtatás (1 260 levél, 250 számla, 320 lead-esemény és néhány tucat napi összesítő), ez belefér a Starter keretébe, a növekedés és a tesztfuttatások miatt azonban érdemes figyelni. Ha saját szerveren futtatod az ingyenes Community Editiont, a licencdíj elmarad, cserébe a szerver díja, a frissítések és a mentések a te feladatod lesznek.

Mennyibe kerül valójában az AI?

Az OpenAI árlapja szerint 2026. szeptember 22-én a gpt-6-luna modell millió bemeneti tokenenként 0,10 dollárba, millió kimeneti tokenenként 0,50 dollárba kerül. A token a szöveg feldolgozási egysége, egy magyar szó jellemzően több tokenre bomlik, mint egy angol, ezért a becslésnél bőkezűen számoltunk.

• E-mail: 1 260 levél, levelenként 2 000 bemeneti és 400 kimeneti token. Ez 2,52 millió bemeneti token (0,252 dollár) és 0,504 millió kimeneti token (0,252 dollár), összesen 0,504 dollár, vagyis nagyjából 161 Ft.
• Számla: 250 számla, darabonként 5 000 bemeneti és 800 kimeneti token. Ez 0,125 és 0,10 dollár, összesen 0,225 dollár, körülbelül 72 Ft.
• Lead: 320 vázlat és összefoglaló, egyenként 2 500 bemeneti és 600 kimeneti token. Ez 0,08 és 0,096 dollár, összesen 0,176 dollár, nagyjából 56 Ft.

A három együtt havi 0,905 dollár, ami nagyjából 290 Ft. Az árlap szerint az EU-s adattárolású (data residency) végpontok a 2026. március 5-én vagy azután megjelent, erre jogosult modelleknél 10%-os felárral járnak, ezzel együtt is 320 Ft körül maradunk. Ha a számlakinyerésnél a pontosság miatt erősebb modell kell, a gpt-6-sol a lista szerint pontosan hússzor annyiba kerül, ami a teljes forgalomra vetítve is csak havi 6 000 Ft körüli tétel. A tanulság egyértelmű: egy KKV-nál a modell díja szinte mellékes, a pénz a bevezetésre és a gondozásra megy el.

Megtérülés két forgatókönyvvel

Az optimista forgatókönyvben a teljes, 258 300 Ft-os havi megtakarítás megvalósul, a Starter csomaggal számolt havi költség nagyjából 39 700 Ft. A havi nettó haszon így körülbelül 218 600 Ft, az 1 068 000 Ft-os egyszeri költség pedig nagyjából 4,9 hónap alatt térül meg. Mivel a három folyamat fokozatosan áll üzembe, a teljes megtakarítás januártól jelentkezik, az októberi és novemberi részleges megtakarítással együtt a megtérülés tehát 2027 tavasza körül várható.

Az óvatos forgatókönyvben csak a becsült megtakarítás fele valósul meg, ráadásul a drágább Pro csomaggal számolunk. Ekkor a havi megtakarítás 129 150 Ft, a költség 52 840 Ft, a nettó haszon 76 310 Ft, a megtérülés pedig 14 hónap körül alakul. Ez még mindig vállalható befektetés, de már látszik, milyen érzékeny a számítás a valódi időmegtakarításra.

Van egy csapda, amelyet a táblázatok ritkán mutatnak meg: a felszabaduló munkaidő csak akkor pénz, ha valamire fel is használod. Ha az irodavezető a megspórolt heti hét órát ügyfélhívásokra, a pénzügyes a kintlévőségek behajtására fordítja, vagy elmarad egy tervezett felvétel, a megtakarítás valódi. Ha viszont az idő szétfolyik, a könyvelésben semmi nem változik, ezért a 90 napos értékelésnél azt is írd le, mire ment el a felszabadult idő.

Mikor nem éri meg?

Vegyünk egy képzeletbeli, 5 fős debreceni tervezőirodát, ahová naponta 15 levél, havonta 30 szállítói számla és 15 ajánlatkérés érkezik. Ugyanazzal a módszerrel számolva a megtakarítás havi nagyjából 12,4 óra, ami 4 200 Ft-os óradíjjal körülbelül 52 000 Ft. Ebből a nagyjából 40 000 Ft-os havi üzemeltetés levonása után 12 000 Ft körüli nettó haszon marad, amellyel ugyanakkora, 1,07 millió forintos bevezetési költség mellett a beruházás hét évnél is tovább térülne meg.

Ilyen méretnél ezért nem a teljes csomagot érdemes megépíteni, hanem egyetlen folyamatot, lehetőleg a legfájdalmasabbat, azt is a lehető legegyszerűbben. Sokszor elég az Odoo beépített funkcióit rendesen beállítani, a levelezőben néhány szűrőt és sablont használni, vagy csak a számlafolyamatot automatizálni. Az automatizálás nem státuszszimbólum, hanem befektetés, a kis volumenű cégnél pedig néha az a legjobb befektetés, amit nem építesz meg.

Hol kell ember a folyamatban és hol dönthet a gép?

A gép ott dönthet, ahol a hiba olcsó és könnyen visszafordítható: címkézésnél, kategorizálásnál, piszkozatok és emlékeztetők létrehozásánál. Ember kell mindenhol, ahol pénz mozdul, adat véglegesen megváltozik vagy a cég nevében megy ki valami az ügyfélhez, legalábbis addig, amíg mért adat nem igazolja a megbízhatóságot.

Ugyanezt az elvet erősíti két szeptemberi hír is. A Moveworks szeptember 14-én úgy frissítette a rendszerét, hogy a sikertelen eszközhívás explicit hibaállapotot adjon vissza látszólagos siker helyett, a Meta Muse Spark 1.3 modellje pedig tisztázó kérdést tesz fel, jelzi, ha elakadt, a következményes lépések előtt pedig megerősítést kér. A saját folyamataidban ugyanez úgy néz ki, hogy a modell minden döntése mellé bizonyossági jelzést ad, a bizonytalan tételek pedig egy kézi sorba kerülnek, nem a rendszerbe.

A mérést érdemes egyetlen számra egyszerűsíteni: hány gépi javaslatot fogad el az ember változtatás nélkül. Az Anthropic szeptember 19-én közölte, hogy nagyjából 30 000 belső ügynöke augusztusban több mint egymilliárd döntést hozott, ezek körülbelül 0,002%-át blokkolták. Egy 18 fős cégnél nyilván nem milliárdokról van szó, a logika viszont ugyanaz: ha tudod, milyen arányban kell beavatkozni, akkor adatra alapozva döntheted el, hol adsz több önállóságot a rendszernek.

Buktatók: jogosultság, adatminőség, hiányzó folyamatgazda

A legtöbb automatizálási projekt nem látványosan bukik el, hanem csendben kopik ki: az első hetek lelkesedése után egyre több tétel kerül a kézi sorba, végül mindenki visszatér a régi módszerhez. Ennek három fő oka van, szerencsére mindhárom megelőzhető.

Jogosultság: a technikai felhasználó ne legyen adminisztrátor

A legkisebb szükséges jogosultság elve szerint az n8n által használt Odoo-felhasználó csak ahhoz férhet hozzá, amire a folyamatnak ténylegesen szüksége van: partnerek olvasásához, szállítói számla piszkozatához és CRM-lehetőségekhez, de nem könyveléshez, utaláshoz vagy törléshez. Az n8n 2.37-es kiadása óta a hitelesítő adatokat az adminisztrátor példányszinten kezelheti, így nem kell minden folyamatépítőnek látnia az API-kulcsokat.

A szeptemberi esetek megmutatták, miért számít ez. Szeptember 7-én vált ismertté, hogy a LiteLLM MCP-hitelesítésében egy bejelentkezés-megkerülési hibát aktívan kihasználtak, amelyen keresztül a csatolt eszközök is elérhetővé váltak. A spanyol adatvédelmi hatóság szeptember 17-én egy lehetséges, ügynök által végrehajtott adatszivárgást jelentett, a kiváltó ok vizsgálata még tart, az ENSZ független tudományos panelje pedig szeptember 21-én elővigyázatosságot sürgetett az AI-ügynökökkel kapcsolatban. A tanulság egy KKV-nak egyszerű: ha egy automatizmus kulcsa illetéktelen kézbe kerül, a támadó pontosan azt teheti meg, amit az automatizmus, ezért a jogosultság legyen szűk, az API-kulcsokat pedig rendszeresen cseréld.

Adatminőség: amit rossz adatra építesz, az gyorsan rosszul működik

Ha az Odoo-ban mondjuk három „Kovács Épületgépész” partner szerepel eltérő adószámmal, az automatizmus nem fogja kitalálni, melyik a valódi. Az ember ilyenkor rákérdez vagy emlékszik, a gép viszont vagy rosszul választ, vagy mindent a kézi sorba tesz. Érdemes azt is rögzíteni, hogy az automatizmus soha nem hoz létre új partnert duplikációellenőrzés nélkül.

Hiányzó folyamatgazda: az árva automatizmus

A harmadik ok a legemberibb. Ha senki nem felel név szerint a kivételek listájáért, az két hét alatt megtelik, a csapat pedig csendben visszaáll a kézi munkára. Az árulkodó jelek: a kézi sor hétről hétre nő, a heti összesítőt senki nem nyitja meg, a hibás kategóriákat pedig mindenki magában javítja, ahelyett hogy jelezné. A megoldás egy név, egy helyettes és heti tizenöt perc, amelyben a folyamatgazda átnézi a kivételeket és jelzi a fejlesztőnek, mit kell módosítani.

Két további csapda: a néma hiba és a túl korai önállóság

A néma hiba az, amikor egy folyamat napokig nem fut, de senki nem veszi észre, mert nem jön hibaüzenet, csak nem jön semmi. Ez ellen két egyszerű eszköz véd: az n8n hibakezelő munkafolyamata, amely minden elakadásnál értesítést küld, valamint egy napi életjel-ellenőrzés, amely szól, ha két munkanapja egyetlen számla sem ment át a rendszeren. A túl korai önállóság pedig az a kísértés, hogy három jó hét után engedjük a gépet önállóan leveleket küldeni. A három hét alatt összegyűlt adat erre kevés, a bizalmat hónapok mérései alapozzák meg, nem egy jól sikerült október.

Adatvédelem, NAV és AI Act: mire figyelj a bevezetésnél?

Három dologra: minden szolgáltatóval, amely személyes adatot kezel helyetted (felhős n8n, AI-szolgáltató), legyen adatfeldolgozói szerződésed, a számlák adóügyi útja maradjon a hivatalos csatornákon, az ügyfélnek pedig jelezni kell, ha közvetlenül egy AI-rendszerrel kommunikál. Az emberi jóváhagyásra épülő ütemterv mindhármat megkönnyíti.

A GDPR szempontjából a beérkező levelek tele vannak személyes adattal, ezért a modellnek csak azt küldd el, ami a feladathoz kell, az n8n futtatási naplóinak megőrzési idejét pedig állítsd be tudatosan, mert ezekben a levelek tartalma is ott lehet. Az OpenAI árlapja szerint a gpt-6-sol és a gpt-6-luna modellnél az EU-s adattárolás csak a Standard feldolgozási szinten érhető el, az adattárolási végpontok pedig 10%-os felárral járnak, ami a fenti becslésben havi néhány tíz forint. Az adatkezelési tájékoztatót frissítsd, hogy szerepeljen benne az AI-alapú feldolgozás, így egy esetleges NAIH-megkeresés sem ér felkészületlenül.

A NAV oldaláról a beérkező számla egyszerűbb eset, mint a kimenő, mert az adatszolgáltatás a kiállító feladata. A NAV Online Számla rendszerében viszont a cégednek kiállított, adatszolgáltatás alá eső számlák adatai is lekérdezhetők, ami remek kontrollt ad. Havonta vesd össze a NAV-ban látható bejövő számlák számát az Odoo-ban rögzített szállítói számlákéval, a belföldi számláknál pedig a különbség megmutatja, mi maradt ki. A kimenő számlák adatszolgáltatását továbbra is az Odoo magyar e-számlázási modulja végezze, ehhez az automatizmusnak nem kell hozzányúlnia.

Az Európai Unió mesterségesintelligencia-rendeletének (EU AI Act) 50. cikke a Gibson Dunn összefoglalója szerint 2026. augusztus 2-a óta előírja, hogy jelezni kell, ha a felhasználó AI-rendszerrel lép kapcsolatba. Amíg a leveleket ember nézi át és küldi el, ez a helyzet nem áll elő, ha viszont később automatikus válaszokat engedsz, a levélben egyértelműen jelezd a gépi eredetet. A rendelet magas kockázatú listájába (például toborzás, hitelbírálat, oktatás) a három folyamat egyike sem esik bele, ezekre egyébként a halasztott határidő 2027. december 2-a.

Mi jön a 90 nap után, 2027 elején?

Ha a három folyamat stabilan fut és a mérések igazolják a megtakarítást, 2027 első negyedévében jöhet a második kör: több önállóság a bizonyítottan megbízható lépéseknél, újabb folyamatok (például a kintlévőség-kezelés vagy a szervizidőpontok egyeztetése) és egy saját MCP-szerver, amelyen keresztül az AI-asszisztensek strukturáltan érik el az Odoo-t.

Az MCP (Model Context Protocol) nyílt szabvány, amellyel egy AI-alkalmazás egységes módon érhet el külső eszközöket és adatforrásokat. A július 28-i specifikáció állapotmentes kérés-válasz protokollá alakította, amely egyszerű terheléselosztó mögött is futtatható, a hitelesítésben pedig a tokenkibocsátó ellenőrzését (RFC 9207) és a dinamikus kliensregisztráció helyett metaadat-dokumentumokat (CIMD) vezetett be. Egy KKV-nak ez annyit jelent, hogy egy csak olvasási joggal rendelkező Odoo MCP-szerver 2027-ben egyszerűbben és biztonságosabban üzemeltethető, mint egy évvel korábban.

Ami nem szerepel a tervben, az a várakozás. Az OpenAI szeptember 29-i DevDay-e minden bizonnyal hoz újdonságokat, az Agents API-ból viszont egyelőre hiányzik a triggerkezelés, a kész connector-könyvtár, az OAuth, a naplózás és a költségláthatóság, vagyis éppen az, amit az n8n már ma tud. A negyedéves terv szándékosan eszközfüggetlen logikára épül: ha jövőre jobb modell vagy jobb futtatókörnyezet jön, a folyamatgazdák, a mérések és a jóváhagyási pontok maradnak, csak egy-egy csomópontot kell kicserélni.

Miben segít a Convergo?

Ha szeretnéd, hogy a fenti ütemterv a saját cégedre szabva induljon el, a Convergo workflow automatizáció szolgáltatásával az n8n-folyamatokat építjük meg, az Odoo ERP és integrációk csapatunk pedig a technikai felhasználót, a jogosultságokat és a magyar lokalizációt állítja be. A szállítói számlák kinyerését dokumentumfeldolgozás és OCR szolgáltatásunk keretében készítjük el, a fejlesztői munkát 10 000 Ft-os óradíjjal számolva. Az első lépés egy ingyenes egyeztetés, amelyen közösen kiválasztjuk az első folyamatot és megtervezzük a kiinduló mérést. Ha előbb az egész cég AI-érettségét szeretnéd átlátni, AI-felmérés, stratégia és oktatás szolgáltatásunkkal is kezdhetünk.