Økonomiansvarlige, revisorer, bogholdere og driftsansvarlige med gentagne dokumentopgaver.
Start med dokumentets vej gennem virksomheden
OCR gør billedets tegn til maskinlæsbar tekst. Det løser en del af en fakturaopgave, men ikke hele arbejdsgangen. I skal også kunne afgøre, hvilken leverandør dokumentet tilhører, hvilke beløb der betyder hvad, og hvem der må godkende resultatet. En læsbar PDF kan stadig blive koblet til den forkerte virksomhed eller behandlet to gange.
Brug et konkret forløb som udgangspunkt: En indbakke modtager en faktura, dokumentet registreres, oplysninger udtrækkes, kontroller gennemføres, og en medarbejder får et klargjort forslag i økonomisystemet. Eksemplet her er en tænkt arbejdsgang. Det indebærer hverken automatisk betaling eller en påstand om, at en bestemt virksomhed allerede har opnået en besparelse.
Beskriv først, hvor opgaven begynder og slutter. Er indbakken kun til fakturaer, eller kommer tilbud, rykkere og kreditnotaer samme sted? Skal løsningen foreslå kontering, eller alene gøre felterne klar? Hvilke systemer er autoritative for leverandørnummer og bankoplysninger? Et snævert første forløb er lettere at evaluere, fordi et korrekt resultat kan beskrives uden forbehold.
Udpeg samtidig en ejer af undtagelserne. En kø med uklare bilag er en del af løsningen og skal have både ansvarlig og forventet behandlingstid. Ellers flytter automatiseringen blot arbejdet fra en synlig indbakke til en usynlig bunke fejl.
Saml et testmateriale med variation og facit
Byg ikke vurderingen på tre pæne PDF-fakturaer fra samme leverandør. Saml et lovligt og nødvendigt udvalg af de dokumenttyper, løsningen faktisk skal møde. Medtag flersidede bilag, forskellige sprog, komma og punktum i beløb, skæve scanninger og fakturaer med flere momssatser. Et dokument, der slet ikke er en faktura, er også et nyttigt testeksempel.
Lav et facit for de felter, der har betydning for processen. En fagperson skal kunne pege på fakturanummer, dato, valuta, nettobeløb og total i originalen. Hvis to personer tolker et felt forskelligt, bør uenigheden afklares, før den bruges til at bedømme systemet. Ellers kommer testen til at måle en uklar intern regel.
Hold et særskilt sæt dokumenter tilbage til den afsluttende prøve. Når en fejl fører til en ny regel eller prompt, skal I ikke kun genteste det dokument, der udløste ændringen. Brug også tidligere eksempler, så en forbedring for én leverandør ikke ødelægger en anden.
Del resultater efter dokumenttype og problem. Et samlet gennemsnit kan skjule, at systemet læser normale fakturaer godt, men overser negative beløb på kreditnotaer. Registrér desuden, hvor materialet kommer fra, hvem der har adgang, og hvornår kopier kan slettes. Testdata er også data, som skal håndteres bevidst.
Skeln mellem tekstgenkendelse, layout og fakturafelter
En fakturaudtrækker kombinerer ofte flere trin. Tekstgenkendelsen læser tegnene, layoutanalysen finder eksempelvis tabeller og tekstblokke, og udtrækningen forbinder værdier med betydninger som fakturadato eller betalingsbeløb. Microsofts fakturamodel beskriver udtræk af felter og linjeposter. Googles Document AI beskriver desuden, hvordan tekst og positioner hænger sammen i et dokumentobjekt.
Bevar denne forbindelse i jeres egen løsning. Når medarbejderen ser et foreslået totalbeløb, bør vedkommende kunne åbne den relevante side og finde den oprindelige tekst. Det gør kontrollen hurtigere og gør det muligt at skelne en OCR-fejl fra en forkert fortolkning. En forkert læst decimal kræver en anden forbedring end et korrekt læst beløb, der blev taget fra den forkerte kolonne.
Undgå at kaste al struktur væk og sende én lang tekststreng videre, hvis tabellerne har betydning. Et varenummer og en pris kan stå tæt i den flade tekst uden at høre til samme linje. Undersøg først, hvilke oplysninger den valgte udtrækker allerede leverer.
Hvis en sprogmodel bruges efter OCR, skal dens opgave være afgrænset. Den kan foreslå en fortolkning af tvetydige felter, men manglende værdier skal forblive ukendte. Et flydende og komplet svar er ikke dokumentation for, at felterne findes på fakturaen.
Fra første afklaring til noget, der virker.
Kortlæg dokumentets vej
Vælg dokumenttyper, systemer og et gennemgået testmateriale.
Definér en feltkontrakt før integrationen bygges
Aftal en intern struktur, som er uafhængig af udtrækkerens feltnavne. For hvert felt beskrives datatype, tilladte værdier, om det er nødvendigt, og hvor det stammer fra. Det bliver jeres kontrakt mellem dokumentbehandling, kontrol og økonomisystem. En udskiftning af model må ikke ubemærket ændre, hvad et tomt felt betyder.
Opbevar både den rå tekst og den normaliserede værdi for kritiske felter. En dato som 03/04/2026 kan ikke altid fortolkes sikkert uden kontekst. Beløb skal behandles med en præcis repræsentation og en kendt valuta; almindelig afrunding eller et gættet decimaltegn kan give en gyldig datastruktur med et forkert økonomisk indhold.
Brug en særskilt ukendt-værdi frem for nul eller en tom standarddato. Et manglende momsbeløb er ikke automatisk lig med ingen moms. Lad heller ikke modellen udfylde et leverandørnummer ud fra et firmanavn alene, hvis flere poster kan passe. Det er et opslag med egne matchregler.
Tabellen er et forslag til et lille første skema. Udvid det kun med felter, som faktisk bliver brugt, og dokumentér ændringer med en version. Gem et konkret eksempel på en accepteret og en afvist post ved siden af skemaet, så udvikler og økonomiansvarlig vurderer samme kontrakt.
| Felt | Repræsentation | Kontrol |
|---|---|---|
| document_id | Stabilt internt id | Samme fil kan spores gennem hele forløbet |
| invoice_number | Tekst eller ukendt | Bevar tegn og foranstillede nuller |
| invoice_date | ISO-dato eller ukendt | Tvetydig dato går til kontrol |
| currency | Aftalt valutakode | Må ikke gættes ud fra et beløb |
| gross_amount | Præcist decimalbeløb | Kontrolleres mod original og summer |
| supplier_id | Id fra leverandørregister | Uklart match kræver vurdering |
Lad faste kontroller afgøre, hvad der må fortsætte
Et udtræk kan se troværdigt ud og stadig være forkert. Brug derfor faste kontroller efter modellen: Er de nødvendige felter til stede? Er beløbene indbyrdes forenelige efter jeres aftalte regler? Passer valuta og leverandørmatch? Er dokumenttypen understøttet? Hver kontrol skal give en forståelig årsag, hvis dokumentet stoppes.
For et enkelt bilag kan nettoposter, moms og total forventes at hænge sammen. Men afrunding, rabatter, fragt og flere momssatser kan ændre det præcise regnestykke. Lad økonomiansvarlige definere reglerne for de dokumenttyper, I understøtter. En generel regel om altid at gange med én bestemt momssats er ikke en forsvarlig genvej.
Vurder felterne efter konsekvens. Et manglende telefonnummer kan være uvæsentligt, mens en ændret bankkonto kræver en særskilt kontrolproces. Et korrekt format på et kontonummer beviser ikke, at det tilhører den rigtige leverandør. Modellen skal ikke kunne godkende en betalingsændring, fordi fakturaens tekst beder den om det.
Brug systemets confidence som ét signal, der skal kalibreres på jeres materiale. En høj score er ikke det samme som en dokumenteret sandsynlighed for korrekt bogføring. Sammenlign scores med faktisk fejlrate pr. felt, og test også de tilfælde, hvor systemet er sikkert, men tager fejl. Disse tilfælde er ofte mere lærerige end de åbenlyst ulæselige dokumenter.
Håndtér dubletter og afbrudte integrationer bevidst
En leverandør kan sende samme faktura igen, og en mail kan blive importeret to gange. Dokumentet kan også være gemt som både original PDF og en ny scanning. Et filhash hjælper med at finde identiske filer, men er ikke nok til alle forretningsmæssige dubletter. Sammenlign derfor flere relevante oplysninger under en aftalt regel.
Et muligt dubletsignal er kombinationen af leverandør, fakturanummer, valuta og beløb. Det er ikke et universelt bevis: fakturanumre kan være læst forkert, og to legitime dokumenter kan ligne hinanden. Lad usikre matches gå til en kø, hvor medarbejderen kan se begge originaler og årsagen til markeringen.
Afbrudte kald kræver en anden kontrol. Hvis økonomisystemet oprettede posten, men svaret forsvandt på netværket, kan et blindt genforsøg oprette en ekstra post. Undersøg systemets støtte for idempotens eller et stabilt eksternt reference-id. Stripes dokumentation illustrerer princippet med idempotensnøgler; det dokumenterer ikke, at jeres økonomisystem har samme funktion eller begrænsninger.
Gem status for hvert trin og afklar udfaldet, før en skrivning gentages. En medarbejder skal kunne se forskel på et dokument, der afventer udtræk, et afvist forslag og en bekræftet oprettelse. Tilføj en test, hvor forbindelsen afbrydes umiddelbart efter skrivningen, og vis, at løsningen kan komme videre uden at skabe en dublet.
Byg en kontrolkø, som medarbejderen faktisk kan bruge
Kontrolskærmen bør vise dokumentet, de foreslåede felter og den konkrete årsag til, at en vurdering er nødvendig. Hvis medarbejderen skal åbne tre systemer for at forstå én afvigelse, kan udtrækningen spare tastning og samtidig gøre kontrollen langsommere. Mål derfor hele håndteringen, inklusive opslag og rettelser.
Giv handlingerne tydelige betydninger: ret et felt, godkend et forslag, markér dublet, afvis dokumenttype eller send tilbage til afsender efter den normale proces. En godkendelse af dataudtrækket er ikke automatisk en godkendelse af udgift eller betaling. Hold rollerne adskilt, hvis jeres eksisterende proces kræver det.
Registrér rettelser med den nødvendige sporbarhed. Det er nyttigt at vide, at et totalbeløb blev ændret fra en bestemt værdi, og hvilken fejltype der blev valgt. Men systemet behøver ikke kopiere alle bilag ind i hver loglinje. Begræns indholdet til det, der skal bruges til undersøgelse og kvalitetsarbejde.
Brug rettelserne til et regelmæssigt review. Hvis samme leverandør igen og igen kræver manuel ændring, undersøg layout, udtræk og regler før I blot sænker tærsklen for godkendelse. En travl medarbejders klik må ikke blive jeres eneste kvalitetsmål. Stikprøver af accepterede dokumenter er nødvendige for at opdage fejl, der ellers passerer lydløst.
Mål korrekt klargøring og samlet arbejdstid
Definér en godkendt opgave som et dokument, der er klargjort korrekt efter de aftalte krav. Mål derefter både feltnøjagtighed, andel til manuel behandling og tidsforbrug fra modtagelse til afsluttet kontrol. En løsning med høj OCR-nøjagtighed kan stadig være dårlig, hvis de få fejl rammer de vigtigste beløb.
Begynd med en parallel prøve, hvor systemets forslag ikke udløser en økonomisk handling. Sammenlign resultatet med den eksisterende behandling. Registrér også dokumenter, som fejler helt, og de minutter, det tager at rette eller genstarte dem. Udelades fejlene, bliver både kvalitet og økonomi kunstigt pæne.
Lav en fejloversigt med konkrete eksempler: forkert dokumenttype, forkert leverandør, manglende side, beløbsfejl, dublet og integrationsfejl. Prioritér efter konsekvens og hyppighed. En enkelt alvorlig fejlkobling kan kræve en ændret adgangs- eller godkendelsesregel, selv om gennemsnittet ellers ser godt ud.
Aftal på forhånd, hvilke resultater der er tilstrækkelige til at gå videre. Der findes ikke én generel acceptprocent for alle virksomheder. Beslutningen afhænger af dokumenternes variation, kontrolprocessen og konsekvensen ved fejl. Gem testversion og beslutning, så I kan gentage prøven ved ændringer i model, feltskema eller økonomisystem.
Aflever en driftsklar proces med en tydelig stopknap
En aflevering bør omfatte mere end en fungerende import. Beskriv forbindelser, adgang, dokumenttyper, kontrolregler og ansvar for fejl. Vis, hvordan en kollega finder et bestemt dokument, retter en afvist post og opdager, at en integration har mistet adgang. Aftal også, hvordan opdateringer bliver testet og rullet tilbage.
Sæt grænser for kølængde, gentagne fejl og forbrug. Hvis en leverandør ændrer sit layout, må tusindvis af dokumenter ikke fortsætte gennem et svigtende forløb uden opmærksomhed. En kontrolleret pause skal bevare status og gøre det muligt at bruge den almindelige manuelle proces.
Gennemgå datavejen med de ansvarlige for jeres aftaler og personoplysninger. Hvilke bilag forlader virksomheden, hvor gemmes originaler og afledte værdier, og hvem kan tilgå dem? Tekniske valg som region og kryptering indgår i vurderingen, men dokumenterer ikke alene, at den samlede behandling er lovlig.
Til en første afklaring med Mosel Studio er et anonymiseret eller konstrueret eksempel, en liste over systemer og en beskrivelse af kontrolarbejdet nok. Send ikke følsomme bilag i en almindelig kontaktformular. Vi kan starte med at gennemgå processen og derefter aftale en egnet måde at vurdere dokumentgrundlaget og opgavens omfang på.
Det bliver vi ofte spurgt om.
Er OCR det samme som automatisk bogføring?
Nej. OCR læser tekst. Fakturafelter, leverandørmatch, kontroller, kontering og godkendelse er yderligere trin med egne regler. Definér præcist, hvilke trin jeres løsning må udføre, og hvem der godkender det økonomiske resultat.
Kan løsningen håndtere alle leverandørers fakturaer?
Det skal afprøves på et varieret grundlag. En udtrækker kan understøtte mange layouts uden at være fejlfri på netop jeres materiale. Start med kendte dokumenttyper og en tydelig kø for det, løsningen ikke kan behandle sikkert.
Hvordan undgår vi, at en faktura oprettes to gange?
Kombinér identifikation af dokumenter med forretningsmæssige dubletkontroller og en integration, der afklarer udfaldet af afbrudte skrivninger. Et filhash alene finder ikke en ny scanning af den samme faktura. Test genforsøg i det konkrete økonomisystem.
Hvad skal vi have klar til en vurdering?
Beskriv modtagelse, systemer, dokumenttyper og hvem der kontrollerer felterne i dag. Brug konstruerede eller forsvarligt anonymiserede eksempler til den første dialog. Adgang til rigtige bilag og integrationer kan aftales, når rammer og ansvar er afklaret.
Læs videre ved kilden.
Vores beslutningsmodeller er rådgivning fra Mosel Studio. Tekniske fakta og rammer understøttes af kilderne her.
- Microsoft: Invoice model i Document Intelligence
Primær dokumentation for fakturafelter og linjeposter; gennemgået 7. september 2026.
- Google Cloud: Handle processing response
Primær dokumentation for tekst, layout, positioner og kvalitetsoplysninger; gennemgået 7. september 2026.
- Stripe: Idempotent requests
Konkret API-eksempel på idempotens, ikke dokumentation for økonomisystemets funktioner; gennemgået 7. september 2026.
