Sådan starter det, næsten hver gang
Et nyt regnskabssystem, der vil differentiere sig på, hvor lidt indtastning kunden selv skal lave, bygger tidligt et OCR-lag. Det giver mening: konkurrenterne har det, kunderne forventer det, og de første testfakturaer bliver læst fint. Denne artikel handler om, hvad der sker derefter — for et mærkbart antal af de teams, der starter denne vej.
Den praktiske version af denne artikels konklusion findes i trin-for-trin-guiden — denne artikel er ræsonnementet bag, hvorfor den guide er skåret til, som den er.
Hvorfor et regnskabssystem bygger sit eget OCR til at starte med
Beslutningen ser fornuftig ud fra starten: en generel OCR-tjeneste er tilgængelig, teamet har udviklerkapacitet, og en intern løsning virker som den, der giver mest kontrol over produktoplevelsen. For et team, der endnu ikke har set den fulde variation i, hvad kunder rent faktisk uploader, er det en helt rimelig konklusion at drage.
Den tidlige version fungerer også reelt godt nok til at bekræfte beslutningen — en håndfuld testfakturaer fra kendte leverandører bliver læst korrekt, og produktet kan vise funktionen frem for første kunder uden problemer.
Ingen af det er en fejlvurdering på det tidspunkt — det er ganske enkelt for tidligt i produktets liv til, at den reelle vedligeholdelsesomkostning har vist sig endnu.
Konkurrenterne, teamet sammenligner sig med, har typisk gennemgået præcis den samme cyklus, blot på et andet tidspunkt — hvilket gør det svært at bruge deres nuværende tilgang som pejlemærke for, hvad der er rigtigt lige nu.
De første måneder, hvor det virker fint
I starten er kundebasen lille og forholdsvis ens — ofte koncentreret om nogle få brancher eller virksomhedsstørrelser, med et overskueligt antal leverandørformater. OCR-laget klarer det fint, og udviklingstiden på det aftager, mens teamet flytter fokus til andre dele af produktet.
Det er præcis her, beslutningen om at bygge selv føles endegyldigt bekræftet — hvilket gør det næste skridt sværere at se komme.
Et team, der stopper og evaluerer på netop dette tidspunkt, har det sværeste udgangspunkt for at se problemet komme — alt tyder på, at beslutningen var rigtig, fordi den endnu ikke er blevet testet af den variation, der senere viser sig.
Hvor revnerne først viser sig
Kundebasen vokser, og med den kommer variationen: en kunde med en udenlandsk leverandør, hvis fakturalayout ikke ligner noget, systemet er testet mod før. En kunde, der uploader fotograferede kvitteringer i stedet for rene PDF'er. En kunde i en branche med usædvanligt komplekse fakturaer — mange linjer, sammensatte momssatser. Hver enkelt tilfælde er en lille fejlrapport; det akkumulerede mønster er noget andet.
Hver enkelt sag bliver typisk løst — en udvikler tilføjer en regel, tester mod det specifikke dokument, og lukker sagen. Problemet er ikke, at sagerne ikke bliver løst. Problemet er, at der aldrig kommer et tidspunkt, hvor der ikke er en næste sag, fordi kundebasens mangfoldighed er en bevægelig størrelse, ikke en, der stabiliserer sig.
Det, der ikke er problemet: OIOUBL og NemHandel
Det er værd at være tydelig om, hvad denne artikel ikke handler om. Strukturerede fakturaer, der kommer gennem NemHandel som OIOUBL eller Peppol-XML, er allerede data — der er ikke noget at genkende, kun noget at parse fra et veldefineret format. Intet regnskabssystem bruger tid på at bygge OCR til den type dokument, og det er ikke der, revnerne fra forrige afsnit opstår.
Problemet ligger konsekvent i den anden halvdel af dokumentflowet — de dokumenter, der aldrig gik gennem NemHandel, fordi leverandøren er udenlandsk, eller fordi det slet ikke er en faktura, men en kvittering eller et kontoudtog.
Denne skelnen er værd at holde helt klar internt i teamet, for uden den er det let at fejlvurdere, hvor stor en del af det samlede dokumentflow der reelt kræver genkendelse — og dermed også fejlvurdere, hvor stor vedligeholdelsesbyrden faktisk kommer til at være.
Det, der reelt driller: alt det andet
Fakturaer fra udenlandske leverandører, kvitteringer fra fysiske butikker, kontoudtog gemt som PDF fra en netbank — det er dokumenterne, der aldrig kommer struktureret, og det er dem, der reelt belaster et internt OCR-lag. Hver ny leverandørs layout, hver ny banks kontoudtogsformat er en potentiel ny sag at håndtere.
Det er ikke, fordi teamet gjorde noget forkert i den oprindelige udvikling — det er, fordi dokumentvariation i sagens natur vokser med kundebasen, og intet indledende testsæt kan dække, hvad der endnu ikke er set.
Kvitteringer er ofte den mest undervurderede af de tre. En faktura følger i det mindste en løs konvention — leverandørnavn øverst, beløb nederst, et fakturanummer et sted. En kvittering fra en fysisk butik har ingen tilsvarende konvention overhovedet: kassestrimlens layout varierer fra butikskæde til butikskæde, og selv inden for samme kæde kan det ændre sig med et systemskifte, uden varsel til nogen, der bygger genkendelse mod det.
Vedligeholdelsesbyrden, ingen budgetterede med
Den oprindelige udviklingsomkostning ved at bygge OCR-laget er synlig og budgetteret fra starten. Den løbende vedligeholdelsesomkostning — hver ny leverandørs layout, hver kundeklage over en fejlgenkendt linje, hver justering af en usikkerhedsgrænse — er ikke, og den vokser typisk hurtigere end teamets kapacitet til at absorbere den ved siden af resten af produktudviklingen.
Det er sjældent én stor fejl, der udløser en revurdering — det er summen af mange små, gentagne justeringer, der langsomt æder sig ind i den tid, der ellers var afsat til nye funktioner.
Den byrde er også ujævnt fordelt hen over kalenderen: den koncentrerer sig typisk omkring årsafslutning og momsperioder, netop når kundernes eget behov for pålidelig bogføring er størst, og netop når teamets tid til at fejlrette et internt genkendelseslag er allerknappest.
Det er den type timing, der gør byrden værre, end den ser ud til på papiret — den rammer konsekvent, når den mindst kan bæres.
En kendt analogi: at drive sin egen mailserver
Der findes stadig virksomheder, der driver deres egen mailserver i stedet for at bruge en hostet tjeneste. Det virker fint i starten — indgående og udgående mail, en kalender, det hele fungerer. Det, der viser sig over tid, er ikke selve serveren, men alt det omkring den: spamfiltrering, der skal holdes opdateret dagligt, sikkerhedsrettelser, der ikke må glemmes, og en voksende liste over sortlister, der kræver aktiv overvågning for ikke at ende på.
Dokumentgenkendelse følger samme mønster. Selve genkendelsen af en enkelt, ren faktura er den overkommelige del — ligesom at sende og modtage en enkelt mail. Det, der akkumuleres, er alt det omkring: nye leverandørformater der dukker op, kvitteringstyper der aldrig blev testet, scannede dokumenter af varierende kvalitet. Ingen af delene er dramatiske hver for sig. Tilsammen er de grunden til, at et hostet alternativ til sidst vinder for de fleste — ikke fordi den oprindelige beslutning var forkert, men fordi vedligeholdelsesbyrden vokser hurtigere end de fleste forventer.
Øjeblikket, hvor beslutningen vender
Der er sjældent ét dramatisk øjeblik — mere typisk en gradvis erkendelse, ofte udløst af en sprint-planlægning, hvor en uforholdsmæssig stor andel af tiden konsekvent går til dokumentgenkendelsesrettelser i stedet for nye funktioner. På det tidspunkt begynder et team at spørge, om den løbende vedligeholdelse reelt er værd at bære, sammenlignet med at kalde et API, der allerede har løst det samme problem for mange andre kunder.
Hvad der reelt ændrer sig ved skiftet
Selve genkendelseslaget bliver udskiftet — men alt, der ligger nedstrøms for det, ændrer sig ikke. Kontering, godkendelsesflow, brugerfladen kunden ser, forbliver produktets egen logik. Det, der flytter, er ansvaret for at holde genkendelsen opdateret med nye leverandørformater — fra teamets eget backlog til en leverandør, hvis kerneprodukt netop er det.
Den frigjorte udviklertid går sjældent til ingenting — den flytter typisk direkte til de funktioner, der oprindeligt var årsagen til, at teamet valgte at bygge sit eget produkt frem for at bruge en konkurrents. Det er, ironisk nok, ofte først efter skiftet, at et team for alvor mærker, hvor meget af deres kapacitet der reelt var bundet i vedligeholdelse frem for udvikling.
Kunderne mærker sjældent selve skiftet direkte — for dem ser produktet blot ud til stille og roligt at blive bedre, hurtigere, end det plejede.
Et regnskabssystem, før og efter
Et mellemstort dansk regnskabssystem gennemgår sit interne OCR-lag efter atten måneder med en voksende kundebase.
| Før | Efter |
|---|---|
| Cirka en tredjedel af en udviklers tid brugt på genkendelsesrettelser hver måned | Ingen — genkendelseskvalitet er leverandørens ansvar |
| Nyt leverandørlayout = ny sag i backloggen | Nyt leverandørlayout = ingen ændring nødvendig |
| Kundeklager over fejlgenkendte linjer | Sikkerhedsniveau pr. felt ruter usikre linjer til gennemgang i stedet |
Selve integrationen tog under en uge — langt kortere end den oprindelige udvikling af det interne lag, fordi arbejdet med at forstå dokumentstrukturerne allerede var lavet én gang, blot i den forkerte retning.
Hvad det reelt koster at blive ved sammenlignet med at skifte
Sat op ved siden af hinanden bliver forskellen mellem at blive og at skifte mere konkret end en generel fornemmelse af, at "det tager for meget tid".
| Opgave | At blive ved det interne lag | At skifte til et API |
|---|---|---|
| Håndtering af en ny leverandørs layout | En ny sag i backloggen, typisk dage til uger | Ingen ændring nødvendig |
| Onboarding af en ny udvikler til genkendelseskoden | Ugers oplæring i en kodebase, kun få kender i detalje | Ingen særlig oplæring — det er en API-kontrakt, ikke intern kode |
| Svar på et revisionsspørgsmål om bilagshåndtering | Dokumentation af et system, ingen har skrevet ned undervejs | Et dokumenteret API med kendte garantier |
| Skalering til dobbelt så mange kunder | Vedligeholdelsesbyrden vokser typisk mere end proportionalt | Ingen ændring i selve integrationen |
Myter, der er værd at lægge fra sig
"At bygge det selv giver mere kontrol"
Man beholder fuld kontrol over, hvad der sker med resultatet. Man mister kun kontrollen over selve genkendelseslogikken — som sjældent er, hvor produktets reelle differentiering ligger.
"Et API er kun for store virksomheder"
Et lille team har typisk mindre kapacitet til at bære vedligeholdelsesbyrden end et stort — mønstret rammer et lille team lige så hårdt, ofte hurtigere.
"Det, vi allerede har bygget, er spildt, hvis vi skifter"
Forståelsen af dokumentstrukturerne, teamet opnåede undervejs, er ikke spildt — den gør integrationen mod et API hurtigere, ikke langsommere.
"NemHandel løser det meste af dette alligevel"
NemHandel løser de strukturerede fakturaer. Det løser ikke kvitteringer, udenlandske fakturaer eller kontoudtog — den del af problemet, der reelt driller.
"Vores dokumenter er for specielle til et generelt API"
De fleste teams, der tror dette, har aldrig faktisk testet et dokumentspecifikt API mod deres egne rigtige bilag — det er en antagelse værd at afprøve konkret, ikke en konklusion at drage på forhånd.
"Skiftet er for risikabelt midt i en vækstperiode"
Det modsatte er ofte tilfældet — vækst er præcis, når vedligeholdelsesbyrden vokser hurtigst, og udsættelse betyder blot at bære den længere.
Hvornår det stadig giver mening selv at bygge det
Der findes reelle undtagelser: et produkt, hvor dokumentgenkendelse selv er kerneproduktet og den primære konkurrencefordel, eller et meget snævert afgrænset dokumentsæt, der aldrig forventes at vokse i variation. For de fleste regnskabssystemer, hvor dokumentgenkendelse er en funktion, der understøtter det egentlige produkt — bogføring, rapportering, afstemning — holder den undtagelse sjældent ved kundebasens vækst.
Den ærlige test er ikke, om teamet kan bygge det — de fleste erfarne udviklingsteams kan. Testen er, om det er den bedste brug af netop det teams tid, sammenlignet med alt det andet, produktet også skal kunne. For et regnskabssystem er produktets egentlige differentiering sjældent dokumentgenkendelsen selv — det er, hvor godt resten af flowet, bygget oven på den, fungerer.
Et lille team vs. et etableret system
Et lille team, der overvejer dette tidligt, sparer sig selv for atten måneders vedligeholdelse, der aldrig blev til noget produktivt. Et etableret system, der revurderer det sent, har en større praktisk opgave — at udfase et lag, resten af produktet er blevet bygget omkring — men konklusionen er den samme: dokumentgenkendelsens vedligeholdelse hører bedst hjemme hos en leverandør, hvis kerneprodukt netop er det.
For et lille team er argumentet om noget stærkere — den udviklertid, et stort system har råd til at afsætte til intern vedligeholdelse, findes ganske enkelt ikke i en tidlig fase, hvor hver time tæller for at nå frem til et produkt, kunderne rent faktisk vil betale for.
Hvad der nok ikke ændrer sig
Efterhånden som flere danske virksomheder går digitale med deres bogføring, og NemHandel-dækningen vokser, bliver den strukturerede del af dokumentflowet en stadig større andel — men den vil aldrig dække alt. Udenlandske leverandører, kvitteringer og kontoudtog forsvinder ikke som dokumenttyper, og det er præcis dér, dokumentgenkendelse fortsat vil være nødvendig, uanset hvor moden den øvrige infrastruktur bliver.
Det, der nok ændrer sig, er hvor lidt et regnskabssystem behøver bekymre sig om selve genkendelsen — efterhånden som specialiserede leverandører fortsætter med at forbedre nøjagtigheden uafhængigt af noget enkelt regnskabssystems egen udviklingscyklus.
Det er, i sidste ende, det samme mønster som al anden specialisering i software — infrastruktur, der engang blev bygget af hvert enkelt produkt for sig, ender typisk med at blive et fælles, velafprøvet lag, alle bygger ovenpå i stedet for at genopfinde.
Hvad der sker med teams, der aldrig skifter
Ikke alle regnskabssystemer, der bygger deres eget OCR, ender med at skifte — nogle bliver ved, år efter år, og retfærdiggør det med, at systemet trods alt fungerer. Det, der oftest kendetegner den gruppe, er ikke, at deres genkendelse er bedre end gennemsnittet. Det er, at vedligeholdelsesbyrden er blevet en så indarbejdet del af teamets hverdag, at den ikke længere føles som en omkostning — den er bare "sådan er det".
Det er præcis den vane, der er værd at bryde jævnligt: at stille det samme spørgsmål igen, med frisk blik, i stedet for at lade svaret fra sidste år stå uprøvet. Et team, der aldrig genbesøger beslutningen, mister ikke nødvendigvis noget dramatisk — men det går glip af en løbende forbedring, der var tilgængelig hele vejen igennem.
Det enkleste modtræk er at sætte en fast dato i kalenderen — én gang om året er nok — til bevidst at genbesøge netop dette spørgsmål, i stedet for at stole på, at nogen tilfældigt kommer til at tænke over det på et travlt tidspunkt, hvor det alligevel bliver skubbet til senere.
Det, en revisor eller kontrollant reelt spørger til
Et nyttigt realitetstjek, når man overvejer dette: tænk igennem, hvad en revisor eller en kontrollant fra Erhvervsstyrelsen reelt ville spørge til, hvis de undersøgte, hvordan et regnskabssystem håndterer bilag. Spørgsmålene er typisk konkrete — hvordan bliver et bilag læst, hvad sker der, hvis et beløb er usikkert, hvor længe opbevares originaldokumentet. Næsten ingen af de spørgsmål handler om, hvorvidt genkendelsen er bygget internt eller kaldt gennem et API — det er ikke det, der bliver undersøgt.
At bygge dokumentgenkendelsen omkring det, der faktisk bliver undersøgt — nøjagtighed, sporbarhed, hvad der sker med et usikkert felt — frem for omkring, hvem der ejer koden, giver typisk et flow, der holder bedre under reelt tilsyn, netop fordi det er designet mod de rigtige spørgsmål fra starten.
Et team, der allerede kan svare klart på de spørgsmål, har reelt intet at frygte fra en gennemgang — uanset hvordan genkendelsen internt er bygget.
Et hurtigt selvtjek til jeres eget produkt
Hvor stor en andel af sidste måneds udviklertid gik til genkendelsesrettelser?
Hvis tallet konsekvent ligger over en femtedel af én udviklers tid, er det værd at regne på, hvad den tid faktisk koster over et år.
Er der en liste over kendte layoutproblemer, der aldrig bliver prioriteret?
En voksende backlog af "mindre" genkendelsesfejl, der aldrig når toppen af prioriteringen, er ofte et tegn på, at byrden allerede er større end teamet erkender.
Kan en ny udvikler overtage genkendelseskoden uden en oplæringsperiode?
Hvis svaret er nej, er viden om systemet koncentreret hos få personer — en sårbarhed, der forsvinder ved at flytte ansvaret til en dedikeret leverandør.
Hvornår blev genkendelseslogikken sidst testet mod et helt nyt leverandørformat?
Hvis svaret er "det ved vi ikke," er det værd at afsætte tid til en systematisk test, før konklusionen om at blive eller skifte drages.
Er der én bestemt person, uden hvem genkendelsen ikke kan vedligeholdes?
Hvis ja, er det en organisatorisk risiko uafhængig af selve kodens kvalitet — og et argument for at flytte ansvaret til et produkt, der ikke afhænger af én person.
Hvad hvis I allerede er langt inde i byggeriet?
Et team, der er seks måneder inde i at bygge sit eget genkendelseslag, og som netop nu læser dette, står ikke over for en alt-eller-intet-beslutning. Det arbejde, der allerede er lagt i at forstå, hvordan fakturaer, kvitteringer og kontoudtog rent faktisk er struktureret, er ikke spildt — det er præcis den viden, der gør en evaluering af et alternativ hurtig og konkret, i stedet for at starte fra bunden af en teoretisk sammenligning.
At skifte på det tidspunkt betyder at kassere den tilpassede parsingkode, men beholde alt, hvad der er bygget nedstrøms for den — konteringslogikken, gennemgangsflowet, brugerfladen ændrer sig ikke, kun det, der fylder dem.
Den sværeste del af den samtale er sjældent teknisk — det er at indrømme over for sig selv og resten af teamet, at seks måneders arbejde bedst bruges som læring frem for som færdigt produkt. Det er en reel, ubehagelig beslutning, men den bliver ikke lettere af at vente yderligere seks måneder.
Kort fortalt
Næsten alle regnskabssystemer starter med at bygge deres eget dokumentgenkendelse, og det er en helt rimelig beslutning i starten. Det, der ændrer sig, er vedligeholdelsesbyrden, mens kundebasen vokser og dokumentvariationen med den — og for et mærkbart antal teams bliver den byrde til sidst tungere end værdien af at eje laget selv.
Den vane, der er værd at tage med herfra, er at spørge jævnligt, hvor stor en andel af udviklingstiden der reelt går til at vedligeholde genkendelsen versus at bygge nye funktioner — det tal fortæller mere om, hvornår det er tid til at skifte, end noget enkeltstående dokument nogensinde vil. Det er også et tal, der er let at måle, og endnu lettere at ignorere, hvis ingen bevidst holder øje med det.
Det er den vane, der i sidste ende afgør, om beslutningen om at bygge selv forbliver rigtig, eller stille og roligt bliver forkert uden nogen, der lægger mærke til det — og det er en vane, der koster minutter og sparer måneder.