The final filing of a Hungarian VAT return happens through ANYK (Általános Nyomtatványkitöltő), the official desktop form-filler maintained by NAV. The Netorigo Finance module does not replace ANYK — final submission stays with the bookkeeper — but it eliminates the manual data entry by exporting a NAV-conformant XML that ANYK loads directly.
Three forms
The module supports the three forms that cover most SMEs:
-
65A return (monthly) — the most common VAT return, due the 20th of each month. The module aggregates the full month's invoicing per VAT line (27%, 18%, 5%, 0%, exempt, out-of-scope, domestic reverse charge, EU acquisition, third country) and fills every field marked mandatory in the 65A XML schema.
-
1065 declaration (annual) — the December summary plus any year-wide corrections, due 20 January.
-
A60 EU recapitulative statement — a monthly or quarterly statement of intra-EU sales with the buyer's VAT number and amounts. This is what makes EU reverse-charge VAT auditable.
XML validation before download
Before the user can download the XML, a Zod-based frontend validator checks every field against the official NAV xsd schema. If anything is wrong (missing SZJ code, malformed tax number, negative VAT amount) the user sees a cleanly formatted list of errors and cannot download the broken file. This eliminates the 'we ship a broken XML, then ANYK complains' cycle that plagues most filing tools.
The xsd schemas are version-stamped in the repo (/lib/anyk/schemas/65a-v3.0.xsd), and a weekly CI cron (nav-schema-check.yml) hits the NAV publication endpoint to detect new versions. When a change is published, the team gets an automatic PR.
The two fields the bookkeeper still hand-edits
Even with 92% automation, two fields on the 65A form regularly need manual editing:
-
elszamolasi-modositas(line 17) — corrections from prior months are written here. We cannot fully automate this because the bookkeeper decides whether to correct a two-week-old error in the original month's return (as an amendment) or fold it into the current return. The module proposes a suggested amount, but the final number is a judgement call. -
onellnori-pothelyettesites(line 23) — a rare succession-substitution line that mostly appears in M&A situations. The logic is too complex and the volume too small to justify a code path.
The story from March 2026
On a Monday at 23:00 in March 2026, NAV published a new version of the 65A form (65A-v3.1.xsd) with 14 field changes. After 31 March, ANYK no longer accepted the old v3.0 XML. We caught the change on Wednesday morning via the weekly cron and shipped the fix in four hours: schema update, field mapping, integration test sweep, deploy. Every tenant had the update by 17 March, well ahead of the 20 March monthly filing deadline.
The lesson is uncomfortable: NAV publishes new form versions with short deadlines, sometimes during off-hours. A weekly schema-check baked into CI saved a four-hour scramble — but more importantly, saved the bookkeeper a frantic same-day rewrite of last month's filings.
What we do not do
We do not submit the final return through any NAV portal. ANYK is a standalone desktop application, and submission requires the bookkeeper's personal digital signature. We deliver the XML; the bookkeeper loads it into ANYK, reviews, signs, and submits. This separation matters both for audit posture and for ethical accountability — the human is in the loop on the formal act of filing.
At a typical 200-invoice-per-month tenant the module saves roughly 18 hours of bookkeeper time per year — manual data entry, recomputation, error correction. At Hungarian rates of around 10,000 HUF per hour, that is 180,000 HUF of recovered capacity per year.