Leverandørfakturaen fra indbakke til godkendelse: fem trin

En leverandørfaktura kan godt komme automatisk ind i regnskabet, uden at den bliver bogført automatisk. Det sikre mønster har fem trin: kend jeres indgange, læs felterne, regn totalen efter i almindelig kode, læg fakturaen ind som kladde til godkendelse og stop afvigelser og dubletter hos en navngiven medarbejder. Trinene herunder følger en tænkt faktura, F-1042, fra indbakken til godkendelsen.

Emnet er aktuelt. Med bekendtgørelse nr. 811 af 22. september 2026 skal registrerede digitale standard bogføringssystemer kunne sende og modtage e-fakturaer og kreditnotaer gennem den fælles digitale infrastruktur. Fra 1. marts 2027 skal systemerne kræve MitID ved første login for at bekræfte, hvilken virksomhed der bruger dem. Virksomheder, der ikke allerede er tilmeldt e-fakturering, skal derefter have besked om, at de bliver tilmeldt, medmindre de fravælger det inden for fire uger. Erhvervsstyrelsen skriver samtidig, at en tilmeldt virksomhed fortsat kan aftale andre fakturaformer, og at e-fakturering mellem danske virksomheder ikke er et lovkrav. Et fakturaflow skal derfor kunne håndtere både e-fakturaer og PDF'er i en længere periode.

Trin 1: kend jeres indgange

Skriv alle de veje ned, en leverandørfaktura kan komme ind ad. De falder typisk i tre grupper, og de kræver forskelligt arbejde, før der kan oprettes en kladde.

• E-faktura via bogføringssystemet. I modtager en struktureret faktura med felter og linjer. Intet skal læses ud, men felterne skal stadig kontrolleres.
• PDF på mail. I modtager et bilag vedhæftet en mail. Leverandør, fakturanummer, datoer, linjer, moms og total skal læses ud.
• Portal eller papir. I modtager et bilag, der skal hentes eller scannes. Det kræver det samme som en PDF, ofte fra en dårligere kilde.

Vi anbefaler at samle PDF-fakturaerne i en fælles indbakke, før flowet bygges, og at spørge de leverandører, der sender mange fakturaer, om de kan sende e-faktura, når I er tilmeldt. Indgange, der kun bruges et par gange om året, skal også stå på listen. Ellers bliver de ved med at være manuelt arbejde uden overblik.

Trin 2: læs felterne som et forslag

Lav en feltliste: leverandør med CVR-nummer, fakturanummer, fakturadato, forfaldsdato, linjer, moms, total, valuta og betalingsoplysninger som kontonummer eller FIK-kode. Skriv ved hvert felt, hvad det skal matches mod, fx leverandørkartoteket eller en indkøbsordre. Ved en PDF kan en sprogmodel læse bilaget og foreslå felterne. Behandl resultatet som et forslag, der kan afvises, og ikke som en sandhed.

Trin 3: regn totalen efter i almindelig kode

Vi anbefaler, at summen af linjerne og momsen regnes efter af almindelig kode, før fakturaen bliver til en kladde. Regn i øre som hele tal, så afrunding ikke giver falske afvigelser, og sammenlign med den total, der står på fakturaen. Kontrollér også, at momsen passer til linjernes momssats, så en linje uden moms ikke bliver regnet med 25 %. Stemmer tallene ikke, stopper flowet med en konkret grund, fx at summen og totalen afviger med et bestemt antal øre, og sagen går videre til trin 5. Kontrollen gælder også e-fakturaer: de er strukturerede, men det betyder ikke, at de er rigtige.

Trin 4: læg fakturaen ind som kladde til godkendelse

Skeln mellem at lægge en faktura ind og at bogføre den. Vi anbefaler, at flowet opretter fakturaen som kladde eller ubogført post, så intet er bogført, før en medarbejder har sagt ja. Godkenderen skal kunne se tre ting side om side: det originale bilag, de udlæste felter og resultatet af totalkontrollen. Det er samme princip, som vi beskriver på vores side om integration for et fakturaudkast fra en webshop: bogholderen kontrollerer udkastet i regnskabet før bogføring.

Aftal på forhånd, hvad der må ske automatisk, og hvor en medarbejder skal godkende. Vil I senere lade små fakturaer fra kendte leverandører gå direkte igennem, så skriv grænsen ned og aftal den, før flowet sættes i drift. Ændr den ikke løbende, mens flowet kører, og lad aldrig en faktura med ændrede betalingsoplysninger gå automatisk igennem.

Trin 5: stop afvigelser og dubletter

Lav en liste over de situationer, hvor flowet skal stoppe og give sagen til et menneske: en ukendt leverandør, en faktura uden fakturanummer, en kreditnota, et bilag, der ikke kan læses, en total, der ikke stemmer, og betalingsoplysninger, der afviger fra leverandørkartoteket. Bekræft ændrede betalingsoplysninger direkte hos leverandøren på et nummer, I kender i forvejen. Skriv for hver undtagelse, hvem der får sagen, og hvad de får med: bilaget, de udlæste felter og grunden til stoppet. En undtagelse uden en navngiven modtager bliver liggende.

Den samme faktura kan også komme ind mere end en gang: som rykker med fakturaen vedhæftet, som en videresendt mail og i overgangen til e-faktura måske både som e-faktura og som PDF. Flowet skal derfor slå op, om fakturaen allerede er modtaget, før det opretter en kladde. En praktisk nøgle er leverandørens CVR-nummer sammen med fakturanummeret. En udenlandsk leverandør har ikke et CVR-nummer, så brug momsnummeret eller jeres eget leverandørnummer. Skriv fakturanummeret ens før sammenligningen, fx uden mellemrum og foranstillede nuller.

Et opslag alene holder ikke, hvis to kørsler af flowet arbejder samtidig: begge kan nå at slå op, få tomt svar og oprette. Gør derfor nøglen til en unikhedsregel i flowets egen database, eller brug bogføringssystemets egen dubletkontrol, hvis det har en. Det samme gælder genforsøg. HTTP-standarden RFC 9110 (åbner i ny fane) kalder en metode idempotent, hvis flere ens forespørgsler har samme tilsigtede virkning som en enkelt, og POST er ikke blandt dem. Et kald, der opretter en kladde, kan altså give to kladder, hvis det sendes igen. Vi har skrevet mere om det i Sådan bygger I en automatisering, der tåler at køre to gange. Vi anbefaler, at en mulig dublet vises for en medarbejder i stedet for at blive slettet automatisk.

Endelig skal nogen have besked, hvis selve flowet holder op med at køre. På integrationssiden beskriver vi overvågning som fejlbeskeder, der siger til, før I selv opdager problemet. Aftal, hvem der får alarmen.

Et prøvesæt før drift

Vi anbefaler at samle ti fakturaer fra den seneste måned og gå de fem trin igennem med dem på papiret, før noget bygges. Tag de besværlige med:

• en kreditnota
• en scannet faktura med skæv tekst
• en faktura, der kom to gange
• en e-faktura, hvis I allerede er tilmeldt
• en faktura fra en leverandør, der ikke findes i kartoteket

På integrationssiden står der, at forløbet testes med både normale sager og fejl, før det sættes i drift. Et prøvesæt med begge dele gør den test konkret. Vil I have os til at se på jeres fakturaflow, kan I beskrive det på ide-siden, som I ville forklare det for en kollega.

Ofte stillede spørgsmål