EZD med KSeF-støtte er ennå ikke fakturaflyt

Dette innlegget er for kommunesekretærer og kasserere (skarbnik) som hører fra en leverandør at «vårt EZD-system støtter KSeF», og lurer på om det avslutter temaet fakturaflyt.

Hva integrasjonen mellom EZD og KSeF egentlig gjør

Fra 1. februar 2026 mottar offentlige etater strukturerte fakturaer gjennom det nasjonale e-fakturasystemet KSeF. Enkelte EZD-klassesystemer, blant annet EZD RP, kan hente en slik faktura og vise den som en innkommende forsendelse. Dette er en reell fordel: fakturaen forsvinner ikke i en e-postboks, den har et KSeF-nummer og en mottaksdato, og den er synlig i systemet. Vanligvis går den likevel ikke direkte inn i en sak. Først ser ekspedisjonskontoret den, som sender den videre til den faglige enheten, og det er først denne enheten som knytter fakturaen til saken. Og vet ekspedisjonskontoret med en gang hvilken organisatorisk enhet en slik faktura skal rutes til? Man må også huske at fakturaens metadata beskriver selve fakturaen: poster, netto- og bruttobeløp, mva-satser. Dette samsvarer ikke alltid med det som står i registreringsskjemaet for innkommende post, hvis omfang av metadata er fastsatt i arkivinstruksen.

Her stopper imidlertid integrasjonen. Fakturaen ligger i systemet, til og med i saken, men ingen har ennå beskrevet den, godkjent den, kontrollert den eller bokført den. Veien videre avhenger av hvordan etaten har organisert flyten av regnskapsbilag. I mange etater ser det fortsatt ut som før KSeF: utskrift, signaturer på baksiden eller på et stempel, mappe til økonomiavdelingen, manuell registrering i økonomi- og regnskapssystemet.

Fakturaens vei fra mottak til betaling

Hver etat har denne veien beskrevet i instruksen for flyt og kontroll av regnskapsbilag. Detaljene varierer, men trinnene er vanligvis like.

1. Mottak. Fakturaen kommer inn gjennom KSeF, men ikke bare der. Frem til utgangen av 2026 kan enkelte mindre leverandører fortsatt utstede fakturaer utenfor KSeF, og utenlandske leverandører utsteder dem utenfor systemet også senere. Fakturaer kommer fortsatt inn per e-post og på papir, og papirfakturaer må skannes og leses med tekstgjenkjenning (OCR) slik at dataene ikke må skrives av for hånd. I KSeF er det som regel ikke plass til vedlegg (strukturen FA(3) tillater bare et begrenset vedlegg i form av data, og bruken av det må meldes), så leverandøren sender ofte den samme fakturaen i tillegg per e-post sammen med dokumenter som hører til: overtakelsesprotokoll, oversikt over utført arbeid eller spesifikasjon. Det hender også at leverandøren sender en utskrift eller PDF av en faktura som allerede ligger i KSeF, uten noen vedlegg. Ved driftsstans i KSeF eller i offline-modus kommer en faktura med QR-kode til etaten før den er i systemet. Etaten må derfor vite at den allerede har mottatt denne fakturaen, slik at den ikke blir behandlet to ganger. I tillegg er fakturaen ikke det eneste kostnadsdokumentet. Forsikringspoliser, honorarer knyttet til sivilrettslige avtaler, noter, gebyrer og vedtak om fordringer følger en lignende vei: beskrivelse, godkjenning, klassifisering, bokføring, betaling. Alle kostnadsdokumenter, uavhengig av inngangskanal og type, bør gå inn i én og samme flyt. Ellers ender etaten opp med én separat sti for fakturaer fra KSeF og en annen, papirbasert, for alt det øvrige.
2. Kobling til avtale eller bestilling. Fakturaen gjelder en konkret avtale, oppdrag eller bestilling. Noen ganger er det nok å pare den med avtalen. Noen ganger med bestillingen, som ikke har noen egen avtale. Og det hender også at det under en rammeavtale legges inn flere bestillinger, og fakturaen gjelder én av dem, slik at den må kobles til bestillingen og gjennom den til avtalen. En god kobling peker umiddelbart på riktig faglig enhet, beløpet som skal avregnes, og hvor mye som gjenstår av bestillingen og avtalen. Uten et avtaleregister og oversikt over bestillinger må noen lete manuelt etter dette.
3. Beskrivelse og godkjenninger. Enheten som bestilte, bekrefter at tjenesten er utført eller varen levert i samsvar med avtalen eller bestillingen. Ofte stopper det ikke her. Hvis innkjøpet er finansiert fra flere budsjetter som ulike enheter har ansvar for, bør hver av dem godkjenne den delen av fakturaen som belaster deres budsjett. Hvis utgiften er IT-relatert, krever flytinstruksen vanligvis også godkjenning fra IT-avdelingen, selv om en annen avdeling er den faglig ansvarlige enheten. Tilsvarende gjelder ofte for investeringsutgifter, EU-finansierte prosjekter eller offentlige anskaffelser. Én faktura kan dermed kreve tre, fire godkjenninger, og det å samle inn alle disse, særlig på papir, er ofte den mest tidkrevende delen av flyten: fakturaen venter på pulten til en person som er på ferie, kommer tilbake etter en manglende signatur, og ingen vet hvor den befinner seg akkurat nå.
4. Finansieringskilde og budsjettklassifisering. Man må angi avdeling, kapittel og post, oppgave fra finansplanen, og noen ganger prosjekt og finansieringskilde. Noen kontrollerer at det finnes midler til dette i planen.
5. Kontroll, attestering og godkjenning for utbetaling. Regnskapsavdelingen kontrollerer fakturaen formelt og regnskapsmessig, og hovedregnskapsføreren (i kommuner/fylker: kassereren, skarbnik) bekrefter den innledende kontrollen. Bilaget blir kvalifisert for bokføring. Etter kassererens kontroll krever flytinstruksen ofte ytterligere godkjenning fra et medlem av ledelsen som har tilsyn med den faglige enheten (i en kommune: ordfører/borgermester/byens president eller en stedfortreder), og i dennes fravær av et annet ledelsesmedlem. Dette er enda en person, enda en signatur og enda et sted der fakturaen kan bli liggende dersom flyten ikke tydelig angir hvem som trer inn for hvem.
6. Registrering i økonomi- og regnskapssystemet. En godkjent faktura må inn i regnskapsavdelingen. Dette er det viktigste berøringspunktet mellom systemene: hvis det ikke finnes en kobling her, må noen skrive av dataene fra fakturaen – som kom inn som en strukturert fil – fra en utskrift.
7. Betaling. Betalingen er en separat prosess, knyttet til fakturaen, men ikke en del av den. Vanligvis håndteres den av økonomi- og regnskapssystemet: betalinger fra mange fakturaer samles i én betalingsbunke, med overvåking av frister og, der det kreves, delt betaling. Fakturaflyten bør bare levere et komplett datasett til regnskapsavdelingen, og deretter få vite at fakturaen er betalt.
8. Arkivering. Fakturaen, med beskrivelse, godkjenninger og betalingsbekreftelse, skal forbli ett sted, klar for kontroll.

KSeF med EZD håndterer det første trinnet og en del av det åttende. De øvrige seks foregår utenfor.

Et eksempel på prosess, illustrert i én tegning

Nedenfor er den samme veien vist i BPMN-notasjon, en standardisert måte å beskrive prosesser på. Hvert spor representerer én rolle i etaten. Svarte piler viser hvem som jobber etter hvem, og stiplede linjer viser datautveksling med systemer som ligger ved siden av flyten: KSeF, leverandørregister, avtale- og bestillingsregister samt økonomi- og regnskapssystemet. Oppgaver med et tannhjulsymbol kan utføres av systemet uten menneskelig innblanding. En bevegelig markør viser veien til én faktura: fra KSeF gjennom de påfølgende godkjenningene til registrering i regnskapsavdelingen, mens mindre markører viser data som utveksles underveis med systemene. Dette er et eksempel, ikke en mal: i hver enkelt etat vil sporene, godkjenningene og koblingene se noe annerledes ut.

Det er lurt å lage en slik tegning for egen etat før man velger verktøy. Da ser man umiddelbart hvor mange godkjenninger som kreves, hvor fakturaen kan bli liggende, og på hvor mange steder data flyttes mellom systemer.

Hvor mange systemer berører én faktura

Når man kartlegger fakturaens vei, viser det seg at den går gjennom KSeF, et EZD-klassesystem, leverandørregisteret, avtaleregisteret og bestillingsoversikten (hvis de finnes), finansplanen og budsjettsystemet, økonomi- og regnskapssystemet, nettbanken, og noen ganger også et eget system for prosjekter eller offentlige anskaffelser. I tillegg kommer regneark der enkelte enheter fører sine egne oversikter over avtaler og budsjettbindinger.

Hver overgang mellom systemer som ingen har koblet sammen, blir en manuell handling: å skrive av et nummer, kopiere et beløp, skrive ut, skanne, ringe og spørre. Disse handlingene krever ingen beslutning, men de tar tid fra flere personer i flere enheter. Ingen ser helheten, fordi hver enkelt bare utfører sin egen del.

Hvor tiden egentlig forsvinner

Faglig godkjenning eller kassererens kontroll er beslutninger og bør fortsatt ligge hos mennesker. Tiden forsvinner et annet sted, i støttehandlinger:

• å avklare om fakturaen allerede har kommet inn via en annen kanal,
• å skrive av papirfakturaer og fakturaer fra e-post, samt andre kostnadsdokumenter som ikke kom gjennom KSeF,
• å lete etter avtalen eller bestillingen og enheten som bestilte,
• å legge til budsjettklassifisering som kan leses direkte ut av avtalen,
• å samle inn godkjenninger fra flere enheter, bære rundt på mapper og finne ut hvor fakturaen befinner seg,
• å opprette samme leverandør i to systemer,
• å skrive av data fra fakturaen inn i økonomi- og regnskapssystemet.

Det er nettopp disse handlingene som er verdt å automatisere. Ikke fordi de er vanskelige, men fordi de gjentar seg for hver eneste faktura, og en etat har tusenvis av dem i året.

Hvordan nærme seg fakturaflyten med fornuft

Rekkefølgen betyr noe. Først prosessen, så verktøyet.

Målet er ikke å innføre elektronisk fakturaflyt. Målet er å endre måten man håndterer kostnadsdokumenter på, i en verden der gjentakende støttehandlinger kan utføres av systemer. Dette endrer arbeidsmåten til mange mennesker, og en endring i arbeidsmåte begynner med å forestille seg hvordan den kunne vært annerledes. Det er dette digital transformasjon handler om, og det er verdt å holde fast ved dette prinsippet ved enhver investering i IT-systemer. Selve kjøpet av et system er ennå ikke en endring.

Beskriv flyten fra mottak til betaling. Sammen med kassereren, regnskapsavdelingen, sekretæren og flere faglige enheter. Hvem gjør hva, i hvilket system, hvor lang tid tar det, hvor blir fakturaen liggende. En slik beskrivelse avdekker ofte trinn som er blitt værende i instruksen fra papirtiden, og som ingen lenger husker hensikten med. Om hvordan man forbereder en slik beskrivelse før man velger system, skriver jeg på siden om behovsanalyse.

Avgjør hvor godkjenningen skal foregå. Det trenger ikke være i EZD. Godkjenningene kan foregå i EZD-klassesystemet, i et eget arbeidsflytverktøy (workflow) eller i en modul i økonomi- og regnskapssystemet. Det viktige er at de foregår ett sted, med et fullstendig spor, og at resultatet går videre uten ny innskriving. En godt utformet flyt velger selv godkjenningsstien basert på hvilke budsjetter utgiften finansieres fra og hva slags utgift det er, kjører godkjenninger parallelt der rekkefølgen ikke har betydning, og har stedfortredere for ferieperioder. Forskjellen mellom et system for prosesser og et regnskapssystem beskriver jeg i innlegget om BPM og fagsystemer.

Koble flyten til økonomi- og regnskapssystemet. Dette er den viktigste integrasjonen: data fra en godkjent faktura, med beskrivelse, klassifisering og godkjenninger, skal gå inn i regnskapsavdelingen som et ferdig dokument, ikke en utskrift. Dette kan gjøres på tre måter. Den beste er et programmeringsgrensesnitt (API) som leverandøren av regnskapssystemet stiller til rådighet. Den andre er direkte skriving til databasen til regnskapssystemet, som krever leverandørens samtykke og medvirkning, fordi en feil i en slik skriveoperasjon er vanskelig å oppdage i ettertid. Den tredje, når systemet mangler et grensesnitt, er en robot (RPA): et enkelt program som på vegne av brukeren legger inn fakturaen gjennom skjermbildet, slik et menneske ville gjort. En robot kan være rask og billig å komme i gang med, men er skjør, fordi en endring i skjermbildets utseende etter en oppdatering kan stanse den. Den bør betraktes som en bro inntil leverandøren tilbyr et grensesnitt. Betalinger og betalingsbunker kan fortsatt ligge der de ligger i dag, i økonomi- og regnskapssystemet.

Samkjør leverandørregisteret. Fakturaen i regnskapsavdelingen må knyttes til riktig motpart, så flyten og økonomi- og regnskapssystemet må omtale de samme partene. I et EZD-klassesystem er det vanligvis langt flere motparter: innbyggere, søkere og institusjoner som skriver til etaten, men som aldri vil sende den en faktura. I økonomi- og regnskapssystemet finnes kun de partene etaten har et økonomisk mellomværende med. Derfor trengs klare regler for livssyklusen til leverandørdata i etatens systemer helt fra starten: hvem som oppretter en motpart, når og i hvilket system, hvem som oppdaterer dataene og når, og hvordan en endring i ett system skal overføres til de øvrige. I tillegg trengs en måte å gjenkjenne samme leverandør på, for eksempel på organisasjonsnummer, slik at en ny leverandør fra en faktura kommer inn i regnskapsavdelingen uten å bli opprettet manuelt på nytt.

Koble fakturaen til avtale- og bestillingsregisteret. En slik kobling antyder automatisk riktig faglig enhet, budsjettklassifisering og hvor mye som gjenstår å avregne av avtalen.

Oppdater flytinstruksen. Elektronisk godkjenning som ikke er forankret i instruksen, ender likevel med at fakturaen blir skrevet ut «for sikkerhets skyld». Når man endrer prosesser og instruks, er det lurt å først forestille seg den ideelle tilstanden: en arbeidsmåte der ingen lenger utfører unødvendige støttehandlinger. Det er denne tilstanden instruksens bestemmelser bør tilpasses til, og ikke omvendt.

Kilder

• Finansdepartementet (Polen): omfanget av obligatorisk KSeF
• Lov av 29. september 1994 om regnskap, ISAP (art. 21, 22)
• Lov av 27. august 2009 om offentlige finanser, konsolidert tekst fra Sejmens kanselli (art. 54)
• Krogis' kalender over plikter: KSeF, e-Doręczenia, EZD

Rettslig status per 30. oktober 2026.