EZD med stöd för KSeF är ännu inte ett fakturaflöde

Det här inlägget vänder sig till kommunsekreterare och skattmästare som hör leverantören säga att "vårt EZD har stöd för KSeF" och undrar om det löser hela frågan om fakturaflödet.

Vad EZD-integrationen med KSeF faktiskt gör

Från den 1 februari 2026 tar myndigheterna emot strukturerade fakturor via Polens nationella e-fakturasystem (KSeF). En del EZD-system (system för elektronisk dokument- och ärendehantering), däribland EZD RP, kan hämta en sådan faktura och visa den som ett inkommande dokument. Det är en reell fördel: fakturan försvinner inte i e-postinkorgen, den har ett KSeF-nummer och ett ankomstdatum, och den syns i systemet. Vanligtvis hamnar den dock inte direkt i ärendet. Först ser registratorskontoret den och skickar den vidare till den ansvariga avdelningen, och det är den avdelningen som sedan kopplar fakturan till ärendet. Men vet registratorskontoret direkt till vilken avdelning en sådan faktura ska dirigeras? Man måste också komma ihåg att fakturans metadata beskriver själva fakturan: poster, netto- och bruttobelopp, momssatser. De stämmer inte alltid överens med det som finns i registreringsformuläret för inkommande post, vars omfattning av metadata regleras i myndighetens diarieföringsinstruktion.

Där tar dock integrationen slut. Fakturan finns i systemet, till och med i ärendet, men ingen har ännu beskrivit, godkänt, kontrollerat eller bokfört den. Den fortsatta vägen beror på hur myndigheten har organiserat sitt flöde för bokföringsunderlag. På många myndigheter ser det likadant ut som före KSeF: utskrift, underskrifter på baksidan eller på en stämpel, en mapp som skickas till ekonomiavdelningen, manuell inmatning i ekonomisystemet.

Fakturans väg från ankomst till betalning

Varje myndighet har denna väg beskriven i instruktionen för flöde och kontroll av bokföringsunderlag. Detaljerna varierar, men stegen är oftast likartade.

1. Ankomst. Fakturan kommer via KSeF, men inte bara därifrån. Fram till slutet av 2026 kan en del mindre leverantörer fortfarande utfärda fakturor utanför KSeF, och utländska leverantörer gör det utanför systemet även senare. Fakturor kommer fortfarande in via e-post och i pappersform, och pappersfakturor måste skannas och tolkas (OCR) för att uppgifterna inte ska behöva skrivas av för hand. I KSeF finns det som regel inget utrymme för bilagor (strukturen FA(3) tillåter bara en begränsad bilaga i form av data, och användningen av den måste anmälas), så leverantören skickar ofta samma faktura separat via e-post tillsammans med tillhörande dokument: mottagningsprotokoll, sammanställning av utfört arbete eller specifikation. Det händer också att leverantören skickar en utskrift eller en PDF av en faktura som redan finns i KSeF, utan några bilagor. Vid driftstopp i KSeF eller i offlineläge når fakturan med QR-kod myndigheten innan den når systemet. Myndigheten måste därför veta att den redan har fakturan, så att den inte behandlas två gånger. Dessutom är fakturan inte det enda kostnadsdokumentet. Försäkringsbrev, räkningar kopplade till civilrättsliga avtal, noteringar, avgifter och beslut om fordringar genomgår en liknande väg: beskrivning, godkännande, klassificering, bokföring, betalning. Alla kostnadsdokument, oavsett inkommande kanal och typ, bör gå in i ett och samma flöde. Annars har myndigheten en separat väg för fakturor från KSeF och en annan, pappersbaserad, för allt det övriga.
2. Koppling till avtal eller beställning. Fakturan avser ett specifikt avtal, uppdrag eller en beställning. Ibland räcker det att para ihop den med avtalet. Ibland med en beställning som inte har något separat avtal. Det förekommer också att flera beställningar görs mot ett ramavtal och att fakturan avser en av dem, så den måste kopplas till beställningen och därigenom till avtalet. En bra koppling pekar direkt ut den ansvariga avdelningen, det belopp som ska regleras och hur mycket som återstår av beställningen och avtalet. Utan ett avtalsregister och en beställningsförteckning måste någon leta efter det manuellt.
3. Beskrivning och godkännanden. Den avdelning som gjorde beställningen bekräftar att tjänsten har utförts eller varan levererats, i enlighet med avtalet eller beställningen. Det slutar ofta inte där. Om inköpet finansierades från flera budgetar som olika avdelningar ansvarar för, bör var och en av dem godkänna den del av fakturan som belastar deras budget. Om utgiften är av IT-karaktär kräver flödesinstruktionen oftast dessutom ett godkännande från IT-avdelningen, även när den ansvariga avdelningen är en annan. Detsamma gäller ofta investeringsutgifter, EU-finansierade projekt eller offentliga upphandlingar. En och samma faktura kan alltså kräva tre, fyra godkännanden, och att samla in dem alla, särskilt på papper, brukar vara den mest tidskrävande delen av flödet: fakturan ligger på skrivbordet hos en person som är på semester, skickas tillbaka för en saknad underskrift, och ingen vet var den befinner sig just då.
4. Finansieringskälla och budgetklassificering. Man måste ange avdelning, kapitel och paragraf, en uppgift ur budgetplanen, och ibland ett projekt och en finansieringskälla. Någon kontrollerar om det finns medel avsatta för detta i planen.
5. Kontroll, kontering och godkännande för utbetalning. Ekonomiavdelningen kontrollerar fakturan formellt och bokföringsmässigt, och den ekonomiansvariga chefen (i en JST – en polsk kommun eller region – skattmästaren) bekräftar den preliminära kontrollen. Verifikationen klassificeras för bokföring. Efter skattmästarens kontroll kräver flödesinstruktionen ofta dessutom ett godkännande från den styrelseledamot som har tillsyn över den ansvariga avdelningen (i en kommun av borgmästaren eller en ställföreträdare), och i dennes frånvaro av en annan styrelseledamot. Det är ännu en person, ännu en underskrift och ännu ett ställe där fakturan kan fastna, om flödet inte vet vem som ersätter vem.
6. Registrering i ekonomisystemet. Den godkända fakturan måste nå ekonomiavdelningen. Det är den viktigaste kontaktpunkten mellan systemen: om det saknas en koppling här skriver någon av fakturauppgifterna, som kommit som en strukturerad fil, av från en utskrift.
7. Betalning. Betalningen är en separat process, kopplad till fakturan men inte en del av den. Den hanteras vanligen av ekonomisystemet: flera fakturors betalningar samlas i en och samma betalningsfil, med bevakning av förfallodatum och, när det krävs, delad betalning (split payment). Fakturaflödet ska bara leverera en komplett uppsättning data till ekonomiavdelningen och sedan få veta att fakturan har betalats.
8. Arkivering. Fakturan med beskrivning, godkännanden och betalningsbekräftelse ska finnas samlad på ett ställe, redo för granskning.

KSeF tillsammans med EZD hanterar det första steget och en del av det åttonde. De återstående sex sker vid sidan av.

Ett exempel på process i en enda bild

Nedan visas samma väg i BPMN-notation, en standardiserad metod för att beskriva processer. Varje bana motsvarar en roll inom myndigheten. De svarta pilarna visar vem som arbetar efter vem, och de streckade linjerna visar datautbyte med system som ligger vid sidan av flödet: KSeF, leverantörsregistret, avtals- och beställningsregistret samt ekonomisystemet. Uppgifter med en kugghjulssymbol kan utföras av systemet utan mänsklig inblandning. En rörlig markör visar en enskild fakturas väg: från KSeF genom de olika godkännandena fram till registreringen i bokföringen, medan mindre markörer visar de data som utbyts med systemen längs vägen. Det här är ett exempel, inte en mall: på varje myndighet kommer banorna, godkännandena och kopplingarna att se lite annorlunda ut.

Det är värt att skapa en sådan bild för sin egen myndighet innan man väljer verktyg. Då syns det direkt hur många godkännanden som krävs, var fakturan kan fastna och på hur många ställen data förs över mellan system.

Hur många system berör en enda faktura

När man kartlägger fakturans väg visar det sig att den passerar genom KSeF, ett EZD-system, leverantörsregistret, avtals- och beställningsregistret (om sådana finns), budgetplanen och budgetsystemet, ekonomisystemet, internetbanken, och ibland även ett separat system för projekt eller offentlig upphandling. Dessutom kalkylblad där enskilda avdelningar för egna sammanställningar av avtal och ekonomiska åtaganden.

Varje övergång mellan system som ingen har kopplat samman innebär en manuell åtgärd: att skriva av ett nummer, kopiera ett belopp, skriva ut, skanna eller ringa för att fråga. Dessa åtgärder kräver inga beslut, men de tar tid från flera personer på flera avdelningar. Ingen ser dem i sin helhet, eftersom var och en bara utför sin egen del.

Var tiden egentligen försvinner

Det sakliga godkännandet eller skattmästarens kontroll är beslut och bör ligga kvar hos människor. Tiden försvinner på andra håll, i stödmoment:

• att fastställa om fakturan inte redan har kommit in via en annan kanal,
• att skriva av pappersfakturor och fakturor från e-post samt andra kostnadsdokument som inte kommit via KSeF,
• att leta efter avtal eller beställning och vilken avdelning som gjort beställningen,
• att lägga till en budgetklassificering som går att läsa ut ur avtalet,
• att samla in godkännanden från flera avdelningar, bära runt mappar och ta reda på vem som har fakturan för tillfället,
• att registrera samma motpart i två olika system,
• att skriva av fakturadata till ekonomisystemet.

Det är just dessa moment som är värda att automatisera. Inte för att de är svåra, utan för att de upprepas vid varje faktura, och en myndighet hanterar tusentals fakturor om året.

Hur man bör angripa fakturaflödet med förstånd

Ordningen spelar roll. Först processen, sedan verktyget.

Målet är inte att införa ett elektroniskt fakturaflöde. Målet är att förändra hur kostnadsdokument hanteras i en värld där repetitiva stödmoment kan utföras av system. Det förändrar arbetssättet för många människor, och en förändring av arbetssättet börjar med att föreställa sig hur det skulle kunna se ut på ett annat sätt. Det är vad digital transformation handlar om, och det är värt att hålla fast vid detta synsätt vid varje investering i IT-system. Att bara köpa ett system innebär ännu ingen förändring.

Beskriv flödet från ankomst till betalning. Med medverkan av skattmästaren, ekonomiavdelningen, kommunsekreteraren och flera ansvariga avdelningar. Vem som gör vad, i vilket system, hur lång tid det tar och var fakturan väntar. En sådan beskrivning visar ofta steg som finns kvar i instruktionen från papperstiden och som ingen längre minns syftet med. Hur man tar fram en sådan beskrivning innan man väljer system skriver jag om på sidan om behovsanalys.

Besluta var godkännandet ska ske. Det måste inte vara EZD. Godkännanden kan ske i ett EZD-system, i ett separat flödesverktyg (workflow) eller i en modul i ekonomisystemet. Det viktiga är att de sker på ett och samma ställe, med ett fullständigt spår, och att resultatet förs vidare utan att skrivas av manuellt. Ett väl utformat flöde bestämmer själv godkännandevägen utifrån de budgetar som finansierar utgiften och dess typ, kör godkännanden parallellt där ordningen saknar betydelse, och har ersättare inlagda för semestertider. Skillnaden mellan ett processystem och ett ekonomisystem beskriver jag i inlägget om BPM och verksamhetssystem.

Koppla samman flödet med ekonomisystemet. Det här är den viktigaste integrationen: uppgifterna om en godkänd faktura, med beskrivning, klassificering och godkännanden, ska nå ekonomiavdelningen som ett färdigt dokument, inte som en utskrift. Det går att göra på tre sätt. Bäst är ett programmeringsgränssnitt (API) som tillhandahålls av systemleverantören. Det andra är direkt skrivning till ekonomisystemets databas, vilket kräver leverantörens godkännande och medverkan, eftersom ett fel i en sådan skrivning är svårt att upptäcka i efterhand. Det tredje, när systemet saknar gränssnitt, är en robot (RPA): ett enkelt program som för användarens räkning matar in fakturan via skärmen, precis som en människa skulle göra. En robot kan vara snabb och billig att komma igång med, men är skör, eftersom en ändring av skärmens utseende efter en uppdatering kan få den att stanna. Det är klokt att se den som en tillfällig bro tills leverantören tillhandahåller ett gränssnitt. Betalningar och betalningsfiler kan förbli där de finns i dag, i ekonomisystemet.

Samordna leverantörsregistret. Fakturan i bokföringen måste kopplas till rätt motpart, så flödet och ekonomisystemet måste referera till samma parter. I ett EZD-system finns det vanligtvis betydligt fler parter: invånare, sökande och institutioner som skriver till myndigheten men aldrig kommer att utfärda en faktura till den. I ekonomisystemet finns bara de parter som myndigheten har ekonomiska mellanhavanden med. Därför behövs redan från start tydliga regler för hela livscykeln för motpartsdata i myndighetens system: vem som registrerar en motpart och när, i vilket system, vem som uppdaterar uppgifterna och när, samt hur en ändring i ett system ska föras över till de övriga. Dessutom behövs en metod för att identifiera samma leverantör, till exempel via organisationsnumret (NIP), så att en ny leverantör från en faktura når ekonomiavdelningen utan att behöva registreras manuellt en andra gång.

Koppla fakturan till avtals- och beställningsregistret. En sådan koppling pekar ut den ansvariga avdelningen, budgetklassificeringen och hur mycket som återstår att reglera på avtalet.

Uppdatera flödesinstruktionen. Ett elektroniskt godkännande som inte finns föreskrivet i instruktionen slutar ofta med att fakturan ändå skrivs ut "för ordningens skull". När man ändrar processer och instruktion är det värt att först föreställa sig ett idealtillstånd: ett arbetssätt där ingen längre utför onödiga stödmoment. Det är till detta som instruktionens formuleringar sedan anpassas, inte tvärtom.

Källor

• Finansministeriet: omfattningen av det obligatoriska KSeF
• Lagen av den 29 september 1994 om räkenskaper, ISAP (art. 21, 22)
• Lagen av den 27 augusti 2009 om offentliga finanser, konsoliderad text från Sejmens kansli (art. 54)
• Krogis skyldighetskalender: KSeF, e-Doręczenia, EZD

Rättsläget per den 30 oktober 2026.