Tjekkiets EET 2.0 fra 1. januar 2027: hvad specialudviklet kasse- og kiosksoftware skal kunne

Tjekkisk salgsregistrering er tilbage. Præsident Petr Pavel underskrev loven om EET 2.0 den 17. september 2026, og skatteforvaltningens meddelelse er klar om datoen: pligten til at registrere salg starter 1. januar 2027. Den dækker betalinger ved fysisk kontakt mellem virksomhed og kunde, inklusive alle kontante betalinger. Kontant, kort, telefon eller QR-kode: betaler kunden personligt eller i jeres lokaler, går salget til skattemyndigheden, i det øjeblik det sker.

For de fleste små erhvervsdrivende betyder det en opdatering fra leverandøren eller en gratis statslig webapp. For kæder, der kører deres egen kassesoftware, selvbetjeningskiosker eller en betalingsapp, som personalet har med rundt i butikken, er det et integrationsprojekt med omkring 90 dage tilbage. Denne artikel er til dem.

Hvad der har ændret sig siden den første EET

Den oprindelige EET blev afskaffet i 2022. EET 2.0 beholder kerneideen (hvert omfattet salg sendes online og kvitteres af staten) og skærer meget af vægten fra:

• Minimale data. Det gamle system opdelte hvert salg efter momssats. EET 2.0 sender én total inklusive moms, uanset satserne.
• Ingen pligt til kvittering. Virksomheder skal ikke længere udstede en kvittering af hensyn til EET, og kvitteringskoden behøver ikke stå på en.
• Et snævrere anvendelsesområde. Kun betalinger ved fysisk kontakt mellem kunde og virksomhed registreres; det gamle system dækkede flere typer betalinger.
• En gratis statslig mulighed. MOJE eet, en webapp til de mindste virksomheder, plus en fravalgsordning kaldet EET OFF for visse enkeltmandsvirksomheder med fast skat.

Den tekniske ændring er større, end listen antyder. Transporten er velkendt: SOAP 1.1 over HTTPS med WS-Security-signaturer, som før. Meddelelsen er ikke. Den nye grænseflade er version 4.1, den gamle var 3.1, og specifikationen siger, at ændringerne fra 2026 »ikke er kompatible med det tidligere system«. Præsentationen fra udviklerseminaret nævner sikkerhedskoden BKP, flaget for forenklet tilstand og momsposterne som fjernet. Gammel EET-kode er en reference for rørføringen og intet andet.

Hvad der er omfattet

Den officielle side om, hvem der skal registrere salg, stiller tre betingelser: betalingen sker ved fysisk kontakt eller er en kontant betaling, den er erhvervsindkomst, og ingen undtagelse gælder.

En betaling ved fysisk kontakt sker enten i personlig kontakt med jer eller jeres personale eller i jeres lokaler eller køretøj i forbindelse med varen eller ydelsen. Seminarpræsentationen siger direkte, at den anden regel er rettet mod selvbetjeningskasser og selvbetjente lokaler. En kiosk inde i jeres butik er omfattet, selvom ingen medarbejder rører transaktionen. Kontanter registreres altid, også uden for jeres lokaler, undtagen ved efterkrav, der opkræves af en posttjeneste.

Betalingsmåden er ligegyldig. Kontanter, kort, QR-kode, bankoverførsel eller direkte debitering foretaget ved salgsstedet, kryptoaktiver, gavekort, spisebilletter og forudbetalte kort er alle nævnt.

Betalinger på afstand er ikke omfattet: en webshop, der betales gennem en betalingsgateway, eller en faktura, kunden betaler fra sit kontor. Det afgørende er, hvordan pengene faktisk flyttede sig, ikke hvad der står på fakturaen. Betaler en kunde 200 CZK med kort ved disken og de resterende 800 CZK med overførsel hjemmefra næste dag, registreres kun de 200 CZK.

Automater, der i sig selv udgør lokaler (kaffeautomaten er det officielle eksempel), er undtaget, og det samme er selvbetjente stande uden for jeres lokaler, hvor registrering ville være upraktisk. Listen over undtagelser dækker blandt andet også offentlige organer, banker, spil og energi.

Hvem der kan springe det meste af dette over

Mikrovirksomheder kan bruge MOJE eet, som lanceres 1. december 2026. Udviklerseminaret i juni rettede den mod virksomheder med op til to registreringsenheder og to ansatte. Enkeltmandsvirksomheder med fast skat i første trin og en indkomst på op til 1 million CZK kan fravælge ordningen via EET OFF.

Virksomheder med et udbredt kassesystem bør få en opdatering fra leverandøren. Spørg, hvornår den kommer, og hvad der sker under et nedbrud, og registrér jer derefter på skatteportalen og installér certifikatet.

Alle andre bør læse videre: egenudviklet eller tilpasset kassesoftware, kiosker I selv har bygget, betalingsapps til personalet eller en koncern, hvor én betaling kan høre til to virksomheder.

Hvad der skal bygges

Alt findes på siden med dokumenter til udviklere: beskrivelsen af grænsefladen (den engelske version er ikke bindende), XSD og WSDL, eksempler på signerede anmodninger og testcertifikater til playground-miljøet.

Registreringsenheder og enheds-id'er

Hver meddelelse indeholder et id for registreringsenheden. I opretter enheder (en butik, en mobil stand, et leveringskøretøj) i DIS+, skatteportalen, og systemet tildeler hver enhed et nummer. Kæder kan importere enheder samlet, og ændringer skal meldes inden for 15 dage. Jeres kassesystem har brug for en vedligeholdt kobling fra hvert sted til dets enheds-id samt et id for udstyret på op til 20 tegn, der er unikt inden for enheden.

Certifikater

Det er her, specialudviklede systemer som regel taber tid. Proceduren for certifikater beskriver trinene:

• Nøgleparret dannes af EET's certificeringsmyndighed, ikke på jeres udstyr. I henter en adgangskodebeskyttet PKCS#12-fil, som er tilgængelig, indtil I bekræfter hentningen, og højst i 30 dage.
• Filen bruger ældre 3DES-kryptering af hensyn til gamle kasser. Dokumentet advarer om, at den måske ikke kan indlæses i OpenSSL 3 uden legacy provider, og anbefaler at pakke den om eller flytte nøglen ind i en vault.
• Certifikater er gyldige i et år. Ét certifikat kan betjene ét eller flere apparater; hvor mange I udsteder, er jeres beslutning.
• Fornyelse kan automatiseres over et REST-API: en kortlivet JWT, der er signeret med det certifikat, der skal fornyes, derefter polling af anmodningen, hentning og bekræftelse. Myndigheden anbefaler at forny to til tre uger før udløb. Når et certifikat er udløbet, er API-vejen lukket, og nogen skal forny det manuelt.
• Beskyttelse af den private nøgle er den skattepligtiges juridiske pligt. Én nøglefil kopieret over på fyrre kasser er en tilbagekaldelse, der venter på at ske.

Datameddelelsen

Hovedet indeholder et nyt UUID for hvert forsøg, afsendelsestidspunktet, et flag for første forsøg og et valgfrit verifikationsflag. Datadelen indeholder den skattepligtiges EIČ, enheds-id'et, udstyrets id, et løbenummer (op til 25 tegn, unikt pr. enhed og apparat), salgstidspunktet med tidszoneforskydning og totalen i CZK med præcis to decimaler. To valgfrie beløb dækker opfyldning og forbrug af forudbetalt saldo; to andre felter dækker registrering på vegne af en anden skattepligtig.

Registrér det, der faktisk blev modtaget: en kontant regning på 78,90 afrundet til 79 indberettes som 79,00, den samme regning betalt med kort som 78,90. En regning, der betales delvist med spisebilletter og delvist med kort, er én meddelelse med totalen.

Signering og afsendelse

Hver meddelelse signeres med XML Signature i WS-Security-hovedet: eksklusiv kanonisering, en SHA-256-digest, RSA-SHA256, certifikatet vedhæftet som BinarySecurityToken, og kun SOAP-kroppen signeres. Udelad ekstra headers som Timestamp eller WS-Addressing: meddelelser over 12 kB afvises, og en meddelelse, der ligner et angreb, får måske slet intet svar. TLS 1.2 eller nyere er obligatorisk, og klienten skal verificere servercertifikatet. Produktion bruger DNS-balancering, så slå værtsnavnet op ved hver forbindelse i stedet for at låse en IP-adresse.

Siden version 1.2 understøtter endpointet CORS, så et browserbaseret kassesystem kan kalde det direkte. Beslut, hvor den private nøgle skal ligge, før nogen skriver den JavaScript.

Svar, nedbrud og 48-timersreglen

En gyldig meddelelse får et synkront svar med en kvitteringskode (POK) på 39 tegn, signeret af skattemyndigheden. Verificér signaturen, og gem POK sammen med salget. En ugyldig meddelelse får en fejlkode; -1 betyder en midlertidig fejl, så send igen senere. Mindre problemer kommer tilbage som advarsler, blandt andet når salgstidspunktet ligger mere end to timer foran serverens ur. Uret i kiosker driver. Synkronisér dem.

I fastsætter selv svartiden, dog mindst to sekunder. Kommer der ingen POK i tide, går salget i en kø. Ifølge seminarpræsentationen genbruger genforsøget den oprindelige krop med et nyt hoved: nyt UUID, flaget for første forsøg sat til false, nyt afsendelsestidspunkt og det oprindelige salgstidspunkt. Det sendes, så snart forbindelsen er tilbage, og senest 48 timer efter salget. Pligten bortfalder heller ikke efter 48 timer: en forsinket meddelelse skal stadig sendes.

Køen skal altså overleve en genstart og udløse en alarm i god tid, før de 48 timer er gået. Endnu en fælde: udløber certifikatet, mens salg venter, skal de signeres med et certifikat, der er gyldigt nu.

Refunderinger, rettelser og dubletter

En refundering eller annullering er en ny meddelelse med et negativt beløb, dateret nu og ikke koblet til den oprindelige. En rettelse er enten en annullering efterfulgt af den rigtige meddelelse eller en enkelt differencemeddelelse. Dubletter genkendes på seks felter (EIČ, enhed, apparat, løbenummer, salgstidspunkt og total), så et genforsøg med samme krop er sikkert. Et genforsøg, der danner et nyt løbenummer, er et salg nummer to.

Kvitteringer

Mindre arbejde end under den første EET: der kræves ingen kvittering af hensyn til EET, og POK behøver ikke stå på den. Fjern al kode, der holder udskrivningen tilbage, indtil POK er modtaget. Hvor I udsteder kvitteringer efter forbrugerlovgivningen, så hold løbenummeret i EET på linje med kvitteringsnummeret; specifikationen bemærker, at de to i praksis som regel er ens.

Særtilfælde, kæder løber ind i

• Forudbetalte kort, armbånd og tegnebøger: opfyldningen og hvert forbrug registreres med de ekstra beløbsfelter udfyldt.
• Én betaling, to skattepligtige: præsentationens eksempel med en tankstation (brændstof solgt på vegne af en anden virksomhed, kaffe for egen regning) kræver to meddelelser, hver med data for sin egen skattepligtige.

Tidslinjen

• 5. juni 2026: den tekniske dokumentation offentliggjort.
• 1. juli 2026: playground-miljøet åbnede. Mellem 26. juli og 26. august behandlede det 170.389 testtransaktioner fra 624 klient-IP-adresser, hvoraf 94,6 % blev behandlet uden fejl.
• 1. november 2026: EET i DIS+, registreringsenheder og certifikater til produktion.
• 1. december 2026: MOJE eet lanceres.
• 1. januar 2027: pligten starter for alle på én gang, uden indfasning.

Den officielle tidsplan kalder januar for en pilotmåned og tilføjer så, at det allerede vil være almindelig registrering. En tidligere meddelelse beskrev piloten som frivillig. Indtil det er afklaret, så planlæg at sende rigtige meddelelser fra 1. januar.

Ét formelt skridt mangler: da underskriften blev meldt ud den 22. september, manglede offentliggørelsen i lovtidende (Sbírka zákonů) stadig. Det er rutine.

En plan på 90 dage

Oktober: afgrænsning og udvikling.

1. List hvert sted, hvor penge skifter hænder: kasser, kiosker, håndholdte apparater, bestilling ved bordet med betaling på stedet og jeres egne chauffører, der opkræver kontanter. Tildel hvert sted en skattepligtig og en fremtidig registreringsenhed.
2. Vælg arkitekturen: signér på hvert apparat, eller kør én tjeneste, der signerer og sætter i kø for dem alle. Systemet accepterer begge. For en kæde vinder den centrale løsning som regel: ét nøglelager, én kø og ét sted at holde øje.
3. Byg meddelelsesbyggeren, signeringen og køen mod playground-miljøet med de fælles testcertifikater. Validér hver meddelelse mod XSD'en i CI.

November: adgang til produktion.

4. Fra 1. november: aktivér EET i DIS+, opret enhederne (samlet import, hvis I har mange), og udsted certifikater til produktion. Læg dem i en vault, ikke på USB-nøgler.
5. Specifikationen fastsætter 1. november 2026 som den tidligste gyldige salgsdato i produktion. Send meddelelser i verifikationstilstand med det rigtige certifikat: de tester hele kæden uden at registrere et salg.
6. Gør refunderinger, forløb for forudbetaling, fornyelse af certifikater og alarmer på køens alder færdige.

December: generalprøve.

7. Rul ud til ét sted. Træk netværkskablet ud midt i frokostspidsen, og se køen blive tømt bagefter.
8. Belastningstest jeres travleste time gennem signeringen.
9. Frys ændringer før julespidsen. Fortæl personalet, hvordan et nedbrud ser ud; virker køen, skal de ingenting gøre.

Januar: pilotmåneden.

10. Afstem dagligt. Sammenlign totalerne i jeres kassesystem med de samlede summer i DIS+, hvor I også kan bestille en detaljeret CSV-eksport med hver POK.

Hvor I kan få hjælp

Vi bygger og ændrer kasseintegrationer: meddelelsesbyggeren og signeringen, køen ved nedbrud, lagring og fornyelse af certifikater, koblingen til enheder og afstemningen mod DIS+. Når kassesoftwaren er gammel, og dens forfattere er gået videre, starter det arbejde med vores service til vedligeholdelse af ældre systemer. Kender jeres eget team systemet, men mangler hænder før januar, kan vi tilføje udviklere.

Kører I jeres egne kasser eller kiosker i Tjekkiet og har endnu ikke sendt en meddelelse til playground-miljøet, så skriv til office@c9group.dev.