En kund betalar för en flat white på ett kafé i München. Surfplattan på disken skickar försäljningen till en signeringstjänst, får tillbaka en signatur och skriver ut den på kvittot innan mjölken har skummats klart. Ingen vid disken tänker på det, men i det sekundlånga steget är alla fyra aktörer i fiskaliseringen inblandade: kaféet, bolaget som byggt kassaprogrammet i surfplattan, leverantören av säkerhetskomponenten som signerade försäljningen och skattemyndigheten, som upprätthåller reglerna som gjorde signaturen nödvändig.
Var och en sköter en egen del av jobbet, och lagen fördelar delarna olika från land till land. Att veta vem som ansvarar för vad är viktigast om du bygger kassaprogramvara, eftersom din produkt är platsen där de tre andra möts.
I korthet
Företaget registrerar försäljningen och behåller det rättsliga ansvaret för sina försäljningsuppgifter, även när det köper in varje teknisk del. EPOS- eller MPOS-leverantören levererar systemet och har på flera marknader egna rättsliga skyldigheter. Leverantören av säkerhetskomponenten signerar varje transaktion så att den inte kan ändras obemärkt. Skattemyndigheten får uppgifterna antingen genom överföring (dagligen i Italien, post för post i Verifactu-läge i Spanien) eller på begäran vid en kontroll (Tyskland, Österrike, Frankrike, Sverige).
Vilka är aktörerna i fiskaliseringen?
Fiskaliseringen har fyra aktörer: företaget som registrerar försäljningen, EPOS- eller MPOS-leverantören som bygger dess kassasystem, leverantören av säkerhetskomponenten vars signatur gör varje manipulation av en försäljning upptäckbar, och skattemyndigheten, som ser till att reglerna följs och tar emot uppgifterna. De tre första är förbundna genom avtal och integrationer; lagen lägger skyldigheter direkt på var och en av dem.
Det hjälper att tänka sig en triangel. Företaget, kassaleverantören och leverantören av säkerhetskomponenten sitter i hörnen, förbundna med licenser och API-anrop. Skattemyndigheten sitter i mitten, eftersom reglerna den upprätthåller når varje hörn på egen hand i stället för att föras vidare längs kedjan.
Uppdelningen har ett skäl: ingen enskild part kan på egen hand göra en försäljningspost trovärdig. En post som företaget kontrollerar från början till slut bevisar lite för en granskare, eftersom det är företaget som betalar skatt på den. Leverantören skriver programvaran men kan inte gå i god för varje försäljning som görs med den. Säkerhetsmekanismen tillför beviset för att en post inte har ändrats sedan den skapades: på de flesta marknader en signatur från en komponent som företaget inte kontrollerar.
Företaget: äger skyldigheten och försäljningsuppgifterna
De flesta fiskaliseringslagar vänder sig först till företaget. Enligt § 146a i den tyska skatteordningen (Abgabenordnung, AO) måste den som registrerar affärshändelser i ett elektroniskt system skydda det med en TSE (Technische Sicherheitseinrichtung, den tyska tekniska säkerhetsanordningen) certifierad av BSI och hålla uppgifterna tillgängliga för skattekontroller. Samma paragraf kräver att företaget anmäler de system det använder till sitt skattekontor. Österrikiska företag registrerar sina signaturenheter hos FinanzOnline, och svenska företag anmäler sina kassaregister till Skatteverket, och ändringar ska anmälas inom två veckor.
Kort sagt: företaget är skyldigt skatten, så det äger beviset.
Det gäller även när varje teknisk del är inköpt. En restaurang kan licensiera sitt kassasystem från ett bolag och sin signeringstjänst från ett annat, men när en kontrollant dyker upp och begär transaktionsuppgifterna går begäran till restaurangen. Att lägga ut tekniken innebär inte att man lägger ut skyldigheten.
Det styr vad företaget behöver från de två andra hörnen. Det behöver ett system som registrerar varje försäljning så som reglerna kräver. Och systemet måste lämna ut allt som företaget ska anmäla eller visa upp: registreringsuppgifter, exporter, kvitton. fiskalys engelskspråkiga guider till KassenSichV i Tyskland och RKSV i Österrike går igenom de skyldigheterna marknad för marknad.
EPOS- eller MPOS-leverantören: bygger systemet som de andra kopplas in i
Leverantörer bygger och levererar kassasystemet: en EPOS (electronic point of sale) på en fast kassa eller en backoffice-server, eller en MPOS (mobile point of sale) på en mobil eller surfplatta. Det är hörnet som gör ett lagkrav till en knapp som kassapersonalen trycker på. Det är också där de två andra hörnen kopplas ihop, eftersom företaget arbetar i systemet och säkerhetskomponenten körs inuti det.
Det är lätt att anta att skyldigheten stannar hos handlaren. På flera marknader säger lagen något annat:
- Tyskland: § 146a första stycket AO förbjuder att system, programvara eller TSE:er som inte uppfyller kraven yrkesmässigt marknadsförs eller släpps ut på marknaden.
- Spanien: enligt artikel 13 i kungligt dekret 1007/2023 intygar tillverkaren varje version av sin faktureringsprogramvara i en declaración responsable, en undertecknad försäkran om överensstämmelse som tillverkaren lämnar till kunderna. Tillverkare har varit skyldiga att erbjuda anpassad programvara sedan den 29 juli 2025. Företagens egna skyldigheter ska enligt planerna börja gälla i oktober 2028, men det är ännu inte officiellt bekräftat (oktober 2026).
- Frankrike: kassaprogramvaran måste själv visa att den uppfyller kraven, antingen genom tredjepartscertifiering eller genom ett intyg i två delar. Programvaruutgivaren undertecknar den första delen och handlaren den andra. Intyget gäller bara med båda delarna.
- Sverige: själva kassaregistret omfattas av en tillverkardeklaration enligt SKVFS 2014:9, Skatteverkets föreskrifter om krav på kassaregister.
Handlare som bygger sitt eget kassasystem sitter i två hörn samtidigt, med handlarens och leverantörens skyldigheter i samma bolag. Frankrike visar vad det kan innebära: en utgivare som säljer till tredje part får själv intyga att programvaran uppfyller kraven, men programvara som bara byggts för internt bruk kräver tredjepartscertifiering.
Leverantören av säkerhetskomponenten: signerar varje transaktion
En säkerhetskomponent är den del av systemet som gör en post bevisbar. Den signerar varje transaktion när den registreras och länkar den på flera marknader till den föregående, så att en senare ändring eller radering bryter kedjan och syns vid en granskning. Beroende på marknad är den en hårdvarumodul, ett smartkort eller en molntjänst som kassan anropar via ett API.
Tysklands BSI (Bundesamt für Sicherheit in der Informationstechnik, den federala myndigheten för informationssäkerhet) beskriver arbetsfördelningen tydligt: kassatillverkare integrerar vanligtvis en befintlig certifierad TSE i stället för att utveckla och certifiera en egen, och certifieringen omfattar bara TSE:n, inte kassan eller dess programvara. Där en marknad har en separat komponent upprepas mönstret: kassan integrerar den, och det godkännande marknaden kräver följer med komponenten snarare än med kassan.
Vad det godkännandet består av varierar mer än ordet ”certifierad” antyder, från ett BSI-certifikat i Tyskland till ingen produktcertifiering alls i Österrike, och i Spanien och Frankrike har lagen ingen separat komponent. Tabellen längre ned ställer sex marknader bredvid varandra.
För leverantören innebär det oftast en egen uppsättning krav och pappersarbete på varje marknad. För företaget innebär det att komponenten oftast är osynlig: den syns som en kod eller signatur på kvittot och, där registrering krävs, i uppgifterna som lämnas till skattemyndigheten.
Skattemyndigheten: ser till att reglerna följs och tar emot uppgifterna
På de flesta marknader är den fjärde aktören en nationell skattemyndighet: Österrikes finansministerium via FinanzOnline, Agenzia delle Entrate (AdE) i Italien, AEAT i Spanien, DGFiP i Frankrike och Skatteverket i Sverige. Spanien har regionala undantag: de baskiska provinsernas skattemyndigheter (Haciendas Forales) driver TicketBAI, och Navarras Hacienda Foral driver NaTicket.
Tyskland delar upp rollen ytterligare. Det federala finansministeriet (BMF) utfärdar förordningen KassenSichV, BSI fastställer de tekniska kraven i samråd med det (§ 5 KassenSichV), och delstaternas skattekontor (Finanzämter) tar emot varje företags anmälan och genomför kontroller.
Hur uppgifterna når myndigheten följer en av två modeller. I överföringsmodellen får myndigheten uppgifterna utan att be om dem. Italiens registratori telematici (RT) skickar dagens försäljningsuppgifter till AdE en gång per dag. I Spanien skickar programvara i Verifactu-läge varje fakturapost till AEAT, medan system som inte använder det läget lagrar posterna i stället.
I modellen på begäran stannar uppgifterna hos företaget tills en kontrollant ber om dem. Enligt Österrikes RKSV (§ 7 och § 19) exporterar företaget sin datainsamlingslogg (DEP) för den begärda perioden. Även Tyskland, Frankrike och Sverige granskar uppgifterna vid kontroller.
De två modellerna lägger tyngden på olika ställen. I modellen på begäran vilar allt på signaturen, eftersom myndigheten ser uppgifterna månader eller år senare och förlitar sig på den för att bevisa att inget har ändrats däremellan. Överföring kräver uppkoppling och korrekt hantering av omsändningar.
Så ser de fyra rollerna ut på sex marknader
De fyra rollerna är desamma överallt; det som skiljer är säkerhetskomponentens form, vem som går i god för den och hur uppgifterna når myndigheten.
| Marknad | Säkerhetskomponent | Vem som går i god för den | Hur skattemyndigheten får uppgifterna |
|---|---|---|---|
| Tyskland | Teknisk säkerhetsanordning (TSE), hårdvara eller moln | BSI-certifiering | På begäran, vid kontroller |
| Österrike | Signaturskapande enhet, smartkort eller moln | Kvalificerat certifikat från en tillhandahållare av betrodda tjänster enligt eIDAS; enheten måste uppfylla eIDAS-kraven, ingen separat fiskal certifiering | På begäran, som DEP-export (§ 7, § 19 RKSV) |
| Italien | Registratore telematico (RT) | RT-modell godkänd av AdE | Daglig överföring till AdE |
| Spanien | Krav inbyggda i faktureringsprogramvaran | Tillverkarens declaración responsable (art. 13, RD 1007/2023) | Varje post i Verifactu-läge; annars lagrad för kontroll (företagens skyldigheter från 2028) |
| Frankrike | Krav inbyggda i kassaprogramvaran | Tredjepartscertifiering (LNE eller InfoCert) eller utgivarens egenintyg (återinfört sedan den 21 februari 2026) | På begäran, vid granskning av DGFiP |
| Sverige | Kontrollenhet (hårdvara) eller molnbaserat kontrollsystem | Ackrediterat certifieringsorgan | På begäran, vid Skatteverkets kontrollbesök |
Läser du mittenkolumnen uppifrån och ned framträder en sak: skattemyndigheten godkänner sällan själva säkerhetskomponenten. Italien är det tydliga fallet där den gör det, genom AdE:s godkännande av RT-modeller. Överallt annars är det ett certifieringsorgan, en tillhandahållare av betrodda tjänster eller tillverkarens egen undertecknade försäkran som går i god för komponenten. fiskalys engelskspråkiga guider om tredjepartscertifiering kontra egencertifiering och om hårdvaru- kontra molnkomponenter går djupare i båda frågorna.
Vad det betyder om du bygger kassaprogramvara
”Regelefterlevnad är handlarens sak, inte vår.” Juridiskt stämmer det till stor del: skyldigheten ligger hos företaget, och i Tyskland, Österrike och Sverige är det företaget som anmäler sina system till skattemyndigheten.
Men handlaren kan bara uppfylla den skyldigheten genom systemet du levererar, så tre beslut hamnar på din sida av triangeln:
- Vilken säkerhetskomponent du använder på varje marknad, och om dess godkännande täcker hur du driftsätter den.
- Om varje transaktion passerar genom den. En försäljning som hoppar över signeringssteget, på grund av en otestad kodväg eller ett avbrott som programvaran inte hanterar, lämnar en lucka i handlarens försäljningsuppgifter som handlaren inte kan se.
- Vad företaget behöver från dig för att kunna göra sina anmälningar. En österrikisk handlare som registrerar sig hos FinanzOnline måste uppge certifikatets serienummer, typen av signaturenhet och kassaregistrens id-nummer. Om ditt system inte visar dem, eller om din leverantör inte automatiserar registreringen, kan handlaren inte slutföra den.
Om du är kassaleverantör är regelefterlevnad både handlarens rättsliga skyldighet och en funktion i din produkt.
Viktigaste slutsatserna
- Skyldigheten stannar hos företaget. Att köpa kassaprogramvara och en signeringstjänst flyttar det tekniska arbetet, inte den rättsliga skyldigheten eller försäljningsuppgifterna.
- Leverantörer har egna skyldigheter. På flera marknader har den part som tillverkar eller säljer systemet skyldigheter enligt lag, så ”handlaren är ansvarig” är aldrig hela svaret.
- ”Certifierad” behöver preciseras. Kontrollera vad som går i god för säkerhetskomponenten på varje marknad innan du förlitar dig på ordet.
- Datamodellen styr utvecklingen. Där uppgifter överförs behöver du planera för avbrott och omsändningar; där de väntar på en kontrollant måste signaturen och exporten hålla i flera år.
Så passar fiskaly in
fiskaly är en leverantör av moln-API:er för fiskalisering och momsefterlevnad: hörnet för säkerhetskomponenten i triangeln. fiskaly säljer inte kassasystem och hanterar inte betalningar.
I Tyskland är SIGN DE den marknadsledande och BSI-certifierade Cloud-TSE:n. SIGN SE är ett molnbaserat kontrollsystem enligt SKVFS 2020:9, certifierat av ett ackrediterat certifieringsorgan, och SIGN ES täcker Verifactu, TicketBAI och NaTicket via ett och samma API. SIGN AT signerar kvitton, skapar DEP:n och automatiserar registreringen hos FinanzOnline.
Hörnen är desamma på varje marknad; det är regelboken i mitten som ändras.
