Kassaleverantörer i Europa står inför två regelkrav på samma gång. Fiskalisering är känd mark: land efter land kräver nu att varje transaktion signeras manipuleringssäkert i kassan. E-fakturering kommer snabbt. Italien har krävt strukturerade fakturor sedan 2019, Belgien, Frankrike och Polen följde efter 2026, och Tyskland och Spanien står på tur 2027.
Med två krav bygger de flesta leverantörer två integrationer. Fiskaliseringen stannar i kassasystemet, medan e-faktureringen flyttar till backoffice, avskuren från kassan där försäljningen skedde.
På papperet fungerar det. I praktiken hamnar en försäljning i två databaser, med två verifieringskedjor som kanske inte stämmer överens och, i värsta fall, samma moms som ska betalas två gånger.
Så här fungerar det när båda i stället går genom kassasystemet, med ett API, en leverantör och en verifieringskedja.
Vad händer egentligen när fakturan ligger i ett andra system?
”Frikopplat” betyder sällan penna och papper längre. Oftast är e-faktureringsverktyget kopplat till affärssystemet, ekonomisystemet eller ett mellanlager däremellan. Varje transaktion exporteras, synkroniseras eller matas in på nytt, och på en presentationsbild ser det ut som ett löst problem.
I verkligheten delar nu flera system på uppgiften att registrera en enda försäljning, och varje överlämning mellan dem är ett ställe där sanningen kan dela sig.
Låt oss följa en B2B-försäljning genom den kedjan:
- Försäljningen börjar i kassasystemet. Rader, momssatser, betalning och fiskal signatur registreras vid disken. Det här är det juridiskt bindande underlaget.
- Uppgifterna lämnar kassasystemet. De flyttas via nattlig export, synk i ett mellanlager eller CSV-import, eller så skriver någon av dem från ett kvitto. I varje steg mappas momskoder, avrundningsregler, varugrupper och rabatter till ett annat systems datamodell. Varje mappning är en översättning, inte en kopia.
- Fakturan skapas på nytt. Det andra systemet skapar e-fakturan från de uppgifter det har fått, inte från själva försäljningen. Om en rad tappas bort, en momskod mappas om eller en rabatt tillämpas i en annan ordning stämmer fakturan inte längre med det fiskala underlaget.
- Rättelser drar isär systemen. Säg att en försäljning makuleras i kassasystemet efter att synken har körts, eller att en faktura krediteras i affärssystemet utan att kassasystemet berörs. Då är de två systemen för alltid oense om vad som såldes, och ingenting i den här uppsättningen får dem att stämma överens igen.
- Skatterevisorn ser två versioner. Den fiskala journalen registrerar en version av försäljningen och fakturaarkivet en annan. Att stämma av dem transaktion för transaktion, över lagringstider på upp till tio år, hamnar på handlaren. Det märks oftast i sämsta tänkbara ögonblick: under granskningen.
Det finns en allvarligare följd än underlag som inte stämmer: samma försäljning, beskattad två gånger.
I EU:s momssystem ska moms som anges på ett utfärdat dokument i regel betalas till skattemyndigheten. När kassasystemet utfärdar ett kvitto med moms och ett andra system senare utfärdar en fullständig faktura för samma försäljning, utan att de två är kopplade som en och samma leverans, riskerar handlaren att vara skyldig den momsen två gånger tills dubbletten upptäcks och rättas. Tyskland skriver ut det i § 14c UStG: felaktigt eller extra angiven moms ska betalas, punkt. Det som börjar som en lucka i flödet slutar som en skatteskuld.
Inget av detta är ett undantagsfall. Det är vardagen i uppsättningen med två system, och varje e-faktureringsverktyg i backoffice är byggt kring den.
Varför fakturan hör hemma där försäljningen sker
Det integrerade alternativet är enkelt. Samma molnlager som signerar transaktionen för fiskaliseringen utfärdar också e-fakturan, med transaktionens aktuella data i försäljningsögonblicket.
Tre vardagliga situationer visar skillnaden:
Affärsmiddagen. En gäst betalar för en teammiddag långt över gränsen för förenklad faktura.
- Integrerat: E-fakturan utfärdas vid bordet eller landar i gästens inkorg några sekunder senare. Den byggs från den signerade transaktionen och är kopplad till kvittot, så avdraget för utgiften är säkrat från första dagen.
- Frikopplat: Veckor senare mejlar gästen och ber om en faktura. Någon bygger upp middagen i ekonomisystemet utifrån ett foto av kvittot. Restaurangen har nu utfärdat två dokument med moms för en måltid. Om de inte är kopplade som en och samma leverans kan restaurangen bli skyldig den momsen två gånger. Det är en skatterisk, inte bara ett serviceproblem.
Fackhandelsdisken. En företagskund uppger sitt momsregistreringsnummer i kassan i en butik.
- Integrerat: Kassan som skriver ut kvittot utfärdar också e-fakturan, och köparens leverantörsreskontra hanterar den automatiskt.
- Frikopplat: Försäljningen hamnar i affärssystemet med den nattliga exporten. Där ger en ommappad momskod och en annan avrundningsregel en faktura som inte längre stämmer på öret med det fiskala underlaget. Ingen märker det förrän en skatterevisor jämför de två systemen.
Utcheckningen på hotellet. En företagsgäst checkar ut.
- Integrerat: Receptionen utfärdar e-fakturan för hela vistelsen direkt. Turisten bakom i kön får bara ett kvitto. Det är samma flöde, med en enda fråga.
- Frikopplat: Hotellsystemet synkar notan till ekonomiavdelningen under natten. Nästa morgon justerar ekonomi företagspriset, så fakturan som till slut skickas stämmer inte längre med receptionens uppgifter.
I varje fall börjar uppgifterna i kassasystemet. Att flytta fakturan till ett andra system innebär att bygga upp dem någon annanstans, med allt som går fel när en synk, en mappning eller en person bygger upp data i stället för att återanvända den.
Integrerat eller frikopplat: jämförelsen
| Kriterium | Integrerat (i kassasystemet via molnet) | Frikopplat (uppsättning i backoffice) |
|---|---|---|
| Uppgifternas korrekthet | Fakturan byggs från den aktuella transaktionen: samma rader, samma momsfördelning, ett enda styrande system | Översätts till ett annat systems datamodell, och översättningar glider isär: momskoder, avrundning och radstruktur slutar efter hand att stämma med det fiskala underlaget |
| Verifieringskedja | Fiskal signatur, kvitto och XML-faktura kopplade i ett system och arkiverade enligt reglerna | Två verifieringskedjor i två databaser som måste stämmas av transaktion för transaktion |
| Risk för dubbel moms | En kopplad dokumentkedja per försäljning: kvitto och faktura hänvisar till samma leverans | Kvitto plus en senare, okopplad faktura för samma försäljning: moms som anges två gånger kan behöva betalas två gånger (i Tyskland: § 14c UStG) tills den rättas |
| Köparens momsavdrag | Korrekt e-faktura i kassan eller några sekunder senare | Köparen jagar fakturan i veckor, och ofta kommer den aldrig |
| Arbetsbörda för personalen | En fråga i kassan, inget andra steg att komma ihåg | Upptäcka B2B-fallet, skriva ner uppgifterna på papper, lämna över till backoffice |
| Beredskap för rapportering i realtid | Molnlagret sitter redan i transaktionsflödet: rapportering läggs till utan att röra kassasystemet | Kan inte rapportera vid transaktionstillfället på grund av sin konstruktion; kräver en strukturell ombyggnad när rapporteringen kommer |
| Skalning till flera marknader | En integration hanterar XRechnung, ZUGFeRD, Factur-X, FatturaPA, Peppol och fler system | Varje lands format och kanaler hanteras separat i varje backoffice-verktyg |
Ett API, en leverantör: vad samordningen sparar
Under ytan löser fiskalisering och e-fakturering samma typ av problem. Båda tar en transaktion, gör om den till ett lagstadgat format, överför den och lagrar den granskningssäkert i flera år.
Kör du dem som två separata system dubblerar du varje lager:
- två datamodeller att hålla synkade
- två autentiseringslösningar och organisationsstrukturer
- två verifieringskedjor att stämma av
- två leverantörer och supportköer att samordna
- två uppsättningar regeländringar att bevaka i varje land
I den integrerade modellen körs e-faktureringen på det du redan har för fiskaliseringen: samma transaktionsdata, autentisering, organisationsstruktur, manipuleringssäkra journal, arkiv och supportavtal. Två krav, en integration. Att lägga till det andra kravet kostar betydligt mindre, och detsamma gäller nästa land.
ViDA är på väg och flyttar efterlevnaden närmare försäljningen
Det starkaste skälet att få den här arkitekturen rätt är det som kommer härnäst. EU:s paket VAT in the Digital Age (ViDA) gör digitala rapporteringskrav obligatoriska för gränsöverskridande transaktioner senast 2030, och medlemsstaterna lägger sina egna nationella realtidssystem ovanpå.
Riktningen är tydlig: rapporteringen flyttar närmare transaktionen. Ett backoffice-verktyg som får uppgifterna flera dagar efter försäljningen kan bara hänga med genom att korta sin synk, och varje synk är ytterligare ett ställe där de två underlagen kan glida isär. När rapporteringsfristen krymper behöver den frikopplade uppsättningen ingen uppdatering. Den måste byggas om.
Ett integrerat molnlager sitter redan i transaktionsflödet. Det signerar transaktionen i dag, och ett rapporteringssteg i morgon bygger ut samma flöde, utan att kassaintegrationen behöver röras igen. Det är samma arkitekturval som avgjorde den förra vågen av regelkrav: molnbaserad fiskalisering ersatte hårdvara just för att en central, versionshanterad plattform tar hand om regeländringar för varje ansluten kassa.
Där den frikopplade modellen fortfarande håller
Integrerad e-fakturering är inget lagkrav i dag, och den frikopplade modellen är fortfarande rimlig på några ställen:
- Små kvitton förblir enkla. Under gränsen för förenklad faktura (250 € i Tyskland) räcker ett kvitto. Men försäljning över den gränsen är just de B2B-transaktioner som bär risken vid granskning och för dubbel moms.
- Tidsfristerna är stegvisa. På flera marknader är det frivilligt att utfärda e-fakturor från kassasystemet i ytterligare ett eller två år. Men det tar tid att bygga integrationen, och leverantörer som börjar nu slipper bygga den i all hast det sista året.
Den frikopplade modellen är laglig, men den är dyr på sätt som prislistan inte visar: avstämningsarbete, friktion vid granskningar, risk för dubbel moms, frustrerade köpare, dubbelt utvecklingsarbete och en ombyggnad när rapporteringen flyttar närmare försäljningen före 2030.
Viktigaste slutsatserna
- En enda B2B-försäljning i kassan kan omfattas av både fiskalisering och e-fakturering, så att dela upp dem på två system skapar två underlag för en transaktion.
- Om ett kvitto och en separat faktura inte är kopplade som en och samma leverans kan samma moms behöva betalas två gånger. I Tyskland framgår det av § 14c UStG.
- När båda kraven går genom ett API delar de autentisering, verifieringskedja och arkiv, så att nästa land kostar mindre.
- ViDA flyttar momsrapporteringen närmare transaktionen till 2030. Ett molnlager som redan sitter i transaktionsflödet kan lägga till rapportering utan ombyggnad.
Här passar fiskaly in
fiskaly bygger molnbaserad infrastruktur för momsefterlevnad för just den här situationen. Vårt API för e-fakturering, fiskaly E-INVOICE, körs på samma plattform som våra fiskaliseringsprodukter, så båda kraven delar en autentisering, en organisationsstruktur och en verifieringskedja. EN 16931-format, Peppol-åtkomst och arkivering enligt reglerna täcks av en enda integration.
