Hvad en konvertering egentlig er
At konvertere et kontoudtog vil sige at genskabe den tabel, der aldrig har eksisteret i filen. Banken har layoutet sit udtog, så et menneske kan læse det, og gemt det som en PDF. Din opgave er den modsatte: at få det tilbage til rækker og kolonner, en maskine kan regne på.
Det lyder mekanisk og er det ikke. Undervejs skal noget afgøre, hvor en kolonne slutter, om et beløb er hævet eller indsat, hvornår to linjer i virkeligheden er én postering, og om en linje overhovedet er en postering eller bare en overskrift, der gentager sig på hver side.
Det er de afgørelser, siden her handler om. Ikke fordi du skal kunne træffe dem selv, men fordi det er dem, der afgør, om resultatet er til at bruge — og fordi det er de samme afgørelser, der går galt, når man gør det i hånden.
En PDF indeholder ikke en tabel
Det er den enkeltoplysning, der forklarer næsten alt andet. En PDF gemmer tegn og deres koordinater på siden — det her tegn her, det tegn der. Der er ingen information om, at fire tal i træk hører til samme række, eller at en kolonne begynder ved en bestemt position.
Tabellen er noget, dit øje laver. Du ser en kolonne, fordi tallene står under hinanden, og du ser en række, fordi tegnene står ved siden af hinanden i samme højde. Fjern øjet, og tilbage er en pose tegn med positioner.
Derfor giver markér-og-kopiér sjældent noget brugbart. Du får teksten i den rækkefølge, den ligger i filen, ikke i den rækkefølge, du læser den — og på et kontoudtog med flere kolonner er de to rækkefølger næsten aldrig ens.
Hvad der sker, når man gør det i hånden
Den manuelle metode har tre varianter, og de fejler hver sin vej. Kopiér-indsæt giver rod, som beskrevet ovenfor. At taste af er langsomt og introducerer tastefejl. At bruge en generisk PDF-til-Excel-funktion giver ofte celler, der er delt forkert, fordi værktøjet gætter på kolonnegrænser uden at vide, hvad et kontoudtog er.
Den dyre fejl er ikke den, du opdager. Det er den, du ikke opdager: en linje, der aldrig kom med, fordi den lå ved et sideskift, eller et beløb, der er tastet med cifrene byttet om. Arket ser rigtigt ud, summerne ser plausible ud, og fejlen dukker op måneder senere, når noget ikke kan afstemmes.
Regn tiden efter for en enkelt måned og gang op med antal konti og måneder. De fleste opdager, at afskrivningen af kontoudtog er den enkeltopgave i bogholderiet, der koster mest og giver mindst — og den er samtidig den letteste at automatisere, fordi svaret kan kontrolleres.
Kolonneproblemet
Kolonner i et kontoudtog er ikke markeret, de er underforstået. Beløb står højrestillet, tekst venstrestillet, og grænsen mellem dem er bare et mellemrum. Det gør en bestemt fejl meget almindelig: et stort beløb fylder mere i bredden og begynder derfor længere til venstre end et lille — så langt til venstre, at et naivt værktøj lægger det i tekstkolonnen.
Resultatet er et ark, hvor små beløb ligger rigtigt og store beløb er forsvundet ind i posteringsteksten. Det er værre end en tom celle, fordi det ser ud, som om alt er gået godt, mens summen er forkert.
Løsningen er at placere et ord efter dets midte frem for dets venstrekant, og at udlede kolonnegrænserne af hele dokumentet i stedet for af den første side. Det lyder som en detalje. Det er forskellen på et regneark, du kan bruge, og et du skal rette igennem.
Hævning eller indsætning — fire skrivemåder
Banker angiver retning på mindst fire måder, og de skal alle ende samme sted. To kolonner, hvor kun den ene er udfyldt pr. linje. Én kolonne med minus foran. Én kolonne med minus bagefter, som stadig bruges af ældre systemer. Eller en markering som D og K, hvor bogstavet afgør retningen.
Alt bliver normaliseret til én beløbskolonne med fortegn: penge ud er negative, penge ind er positive. Det er den eneste form, hvor SUM, filtrering og pivottabeller virker uden efterbehandling, og det er den form, regnskabsprogrammer forventer ved import.
Der er en faldgrube værd at kende: saldokolonnen er ikke beløbet. Eksporterer man den løbende saldo i beløbsfeltet, får man en fil, der importerer pænt og er fuldstændig forkert — hver postering bærer kontoens saldo i stedet for sin egen værdi. Det er en klassiker, og den fanges af saldokontrollen.
Linjerne, der forsvinder ved sideskift
Kontoudtog med flere sider har et svagt punkt lige dér, hvor siden slutter. En postering, hvis tekst fortsætter på næste side; et afsnit, der starter forfra uden at gentage kolonneoverskrifterne; en sum midt i dokumentet, der ligner en postering men ikke er det.
Værktøjer, der behandler hver side for sig, taber her. De kræver typisk en overskriftsrække for at forstå en blok, og en blok uden overskrift bliver derfor sprunget over — uden fejlmeddelelse, for der er ikke noget, der er gået i stykker.
Derfor læses hele dokumentet under ét, og strukturen udledes på tværs af sider i stedet for pr. side. Gentagne overskrifter og sidefødder springes over, men en linje med dato og beløb bliver aldrig betragtet som en overskrift. Og bagefter kontrollerer regnestykket, om noget alligevel mangler.
Danske tal og datoer
1.234,56 er tolv hundrede og fireogtredive kroner. Læst med engelsk konvention bliver det til 1,23456 eller 1234,56 alt efter hvem der gætter — og en fil, der blander de to konventioner, er værre end en, der bruger den forkerte konsekvent.
Datoer har samme problem. 03-06-2026 er 3. juni i Danmark og 6. marts i USA, og begge dele parser uden fejl. Konventionen bliver derfor afgjort pr. dokument ud fra hele udtoget, ikke gættet pr. linje, og datoerne normaliseres, så sortering virker bagefter.
Det betyder også, at et dansk og et udenlandsk udtog kan ligge i samme ark uden at ødelægge hinanden. Uden normalisering ville en blandet fil være ubrugelig til at regne på, uanset hvor pænt den så ud.
Tekster, der brækker over flere linjer
Danske posteringstekster er lange. En MobilePay-overførsel med afsendernavn, en bankoverførsel med reference eller et Betalingsservice-træk med aftalenummer fylder ofte to eller tre linjer i PDF-filen, selv om det er én postering.
Håndteres det ikke, får du en af to fejl: teksten bliver klippet af efter første linje, eller fortsættelseslinjerne bliver til selvstændige rækker uden dato og beløb. Den første koster dig muligheden for at filtrere senere. Den anden ødelægger antallet af posteringer.
Fortsættelseslinjer samles derfor tilbage i den postering, de hører til, så teksten er hel. Det er præcis den detalje, der afgør, om du kan finde alle indbetalinger fra én kunde i marts med et filter — eller skal læse dig igennem.
Tre slags PDF-filer — og hvad de kræver
Ikke alle PDF-filer er ens, og forskellen afgør, hvor meget der skal til. Det er værd at vide, hvilken slags du sidder med, før du vurderer resultatet.
| Type | Sådan genkender du den | Hvad der kræves |
|---|---|---|
| Digital PDF fra netbanken | Du kan markere teksten med musen | Læses direkte — bedste kvalitet |
| Scannet papirudtog | Teksten kan ikke markeres | OCR først, derefter struktur |
| Foto taget med telefon | Skævt, ujævnt lys, skygger | OCR — flest felter at se efter |
| Print gemt som PDF igen | Kan markeres, men rodet layout | Læses, men kolonnerne skal udledes |
| Beskyttet PDF med kodeord | Kan ikke åbnes uden kode | Fjern beskyttelsen først |
Den digitale PDF fra netbanken er langt den bedste udgangsposition, og den er også den, de fleste har. Kan du vælge, så hent udtoget fra netbanken frem for at scanne et print — kvaliteten i den anden ende følger direkte med.
Konverteringen trin for trin
Først bestemmes dokumenttypen: er det et kontoudtog, en faktura eller noget helt tredje. Det afgør, hvilke felter der overhovedet giver mening at lede efter, og det er derfor, du ikke skal vælge noget på forhånd.
Derefter læses siderne — én ad gangen, så et udtog på otte sider ikke ender med kun at aflevere den første. Ordene grupperes i rækker efter deres lodrette placering og i kolonner efter deres midte, fortsættelseslinjer samles, og fortegnene normaliseres.
Til sidst køres kontrollen, og først derefter ser du noget. Rækkefølgen er med vilje: det er bedre at få et flag med det samme end et pænt ark, der viser sig at mangle en linje.
Kontrollen, der kører inden du ser noget
Et kontoudtog kan kontrollere sig selv, og det er den egenskab, alt andet hviler på. Primosaldo plus summen af posteringerne skal give ultimosaldoen, banken har trykt. Går regnestykket op, mangler der beviseligt ingen linje.
Går det ikke op, bliver udtoget markeret sammen med de rækker, der ser forkerte ud. Det er en langt mere brugbar besked end en sikkerhedsprocent, for den peger på noget konkret at kigge på.
Kontrollen kører pr. konto og pr. valuta. Et udtog med to konti har to regnestykker, og et samlet tal på tværs kan gå op, mens begge konti hver for sig er forkerte — derfor holdes de adskilt.
Ret det, du er uenig i — inden eksport
Ingen automatisk læsning er ufejlbarlig, og det ærlige svar er ikke at love det modsatte, men at gøre rettelser nemme. Alle felter kan redigeres, før filen bliver bygget.
Rettelserne følger med i alle formater. Retter du et beløb, er det rettet i Excel, i CSV og i bankfeed-filen — du skal ikke huske at gøre det samme tre gange, og der findes ikke to versioner af sandheden.
Kig især på det, systemet selv har markeret: felter med lav sikkerhed og udtog, hvor saldoen ikke går op. Resten behøver du ikke læse igennem, og det er hele pointen med at have en kontrol.
Hvad du får ud
Excel er standardvalget: formler, filtre, pivottabeller og plads til en konteringskolonne. CSV er den neutrale variant, når en anden maskine skal læse filen — og den, de fleste importfunktioner tager imod.
Bankfeed-filerne — OFX, QBO og QFX — er rigtige filer af den type, en del regnskabsprogrammer importerer som bankposteringer frem for som regneark. Det sparer kolonnemapning, men kræver at dit program understøtter formatet, så tjek importvejledningen først.
Ud over selve tabellen får du kontooplysningerne — bank, kontonummer som det står, periode, valuta og de to saldi — fordi de er dokumentationen for, hvilken konto og hvilken periode arket dækker.
Når banken selv kan levere XML
Så brug bankens fil. Dansk erhvervsnetbank kan i vidt omfang levere kontoudtog som XML i ISO 20022-familien, og en fil fra kilden skal ikke læses af nogen — den er allerede data. Det er den rigtige rækkefølge, også selv om vi sælger det modsatte.
Konvertering er til det, eksporten ikke dækker: perioder ældre end netbankens vindue, lukkede konti, banker og kort uden eksport, og de udtog, du får tilsendt som PDF af en kunde eller en tidligere bogholder.
Det er også værd at vide, at vi går den ene vej. Vi laver ikke betalingsfiler til banken — FIK, Bankdata-V3, BEC og SDC er virksomhed-til-bank-formater og hører hjemme i økonomisystemet.
Kortudtog opfører sig anderledes
Kreditkortudtog har deres egen logik: en periode, der ikke følger måneden, en samlet betaling der udligner saldoen, og ofte ingen løbende saldo pr. linje overhovedet.
Det giver en klassisk dobbeltbogføring i bogholderiet: kortkøbene bogføres som udgifter, og betalingen fra bankkontoen bogføres som en udgift én gang til. Betalingen er en udligning, ikke en omkostning — og fejlen er nem at lave, når de to udtog konverteres hver for sig.
Kortudtog uden saldokolonne kan ikke kontrolleres på samme måde som et bankudtog, og det siger vi hellere end at lade som om. Her er totalsummen og antallet af posteringer den kontrol, du har.
Flere filer på én gang
Et helt regnskabsår er sjældent én fil. Det er tolv måneder gange antallet af konti, og de skal samles ét sted, før noget kan afstemmes.
Batchbehandling tager op til 100 filer i én arbejdsgang og lægger dem i ét ark med en kolonne, der viser, hvilken fil hver linje kom fra. Overlapper to filer, bliver dubletterne fanget — det sker hver gang, nogen genhenter en måned, de troede manglede.
Hold konti adskilt i arket, også når de kommer fra samme fil, og kør månedskiftskontrollen bagefter: den ene måneds ultimosaldo skal være den næstes primosaldo. Det er den test, der finder det udtog, ingen fik hentet.
Hvad konverteringen ikke er
Ikke et bogføringssystem. FlowParse står ikke i Erhvervsstyrelsens fortegnelse over registrerede digitale bogføringssystemer, har ingen kontoplan, konterer ikke og bogfører ikke. Kravene i bogføringsloven opfyldes med det registrerede system, du bogfører i — vi leverer data til det.
Ikke et arkiv. Originalfilen slettes umiddelbart efter udtrækket. Opbevaringspligten for dit regnskabsmateriale er din, og de udtrukne data er et arbejdsdokument — bankens udtog er dokumentationen.
Ikke en revisor. Vi tager ikke stilling til moms, fradrag eller kontering, og vi indberetter ikke til SKAT. De spørgsmål hører til hos din revisor, og et værktøj, der påstod andet, ville være til mere skade end gavn.
De fejl, der oftest ødelægger et konverteret ark
Der er fem, og de går igen uanset hvilket værktøj folk har brugt. Kender du dem, kan du kontrollere et hvilket som helst resultat på et par minutter.
| Fejl | Sådan ser den ud | Sådan fanger du den |
|---|---|---|
| Manglende linje ved sideskift | Arket ser fint ud | Saldoen går ikke op |
| Saldo i beløbskolonnen | Alle beløb ligner kontoens saldo | Sammenlign to linjer med udtoget |
| Fortegn vendt forkert | Summen er positiv, men burde være negativ | Tjek én hævning manuelt |
| Afkortet posteringstekst | Navne og referencer mangler slutningen | Filtrér på en kendt modtager |
| Manglende måned i et årsark | Ingenting ser forkert ud | Ultimosaldo mod næste primosaldo |
Læg mærke til, at tre af de fem kun kan findes med et regnestykke. Det er derfor, kontrollen betyder mere end præcisionsprocenten — den fanger netop de fejl, øjet ikke opdager.
Kom i gang
Tag det udtog, der plejer at være besværligt. Det scannede, det med to konti, det fra den udenlandske bank — ikke det pæne. Det er det eneste, der fortæller dig noget.
Se på tre ting i resultatet: er alle posteringer med, går saldoen op, og er teksterne hele. Er svaret ja tre gange, kan du roligt køre resten af året igennem. Er svaret nej, har du fundet det ud på et minut.
Skal det ind i et system eller køre fast hver måned, findes der et API. Skal du bare igennem ét regnskabsår, er en batch nok.
Vi lover dig ikke 99 % — vi viser dig, hvilke rækker du skal se på
Alle konvertere i det her marked reklamerer med et tal: 99 %, 99,5 %, 99,8 %. Ingen af dem skriver, hvordan det er målt eller på hvilke dokumenter — og ingen af dem kan fortælle dig, hvilke rækker der ligger i resten. Det finder du ud af bagefter, når to beløb er klistret sammen til ét, en kolonne er skredet én plads, og en afstemning ikke vil gå op.
Vores udtræk er stærkt. Det er heller ikke magi — og det er ingen andres.
At læse en PDF er ikke et løst problem. Et layout, ingen har set før, en falmet termobon, en bank der markerer kreditposteringer på sin egen måde — hver af dem kan give en række, der ser fuldstændig almindelig ud og er forkert. Vi bygger hårdt imod det, og vi nægter stadig at sælge dig et tal, for tallet er ikke det, der beskytter dig. Det gør det at vide præcis, hvor du skal kigge.
Hvad der faktisk går galt, når en PDF bliver læst
Det er ikke hypotetiske eksempler. Hver eneste er en fejl, vi har fundet i rigtige dokumenter, gentaget og bygget en kontrol imod — og det er netop derfor, vi nu kan pege på dem i stedet for at gemme dem i en procent.
| Fejlen | Hvad du ser i eksporten | Hvad det koster |
|---|---|---|
| To beløb klistret sammen til ét | Ét plausibelt tal i stedet for to rækker | En total, der mangler en hel postering |
| En kolonne skrider én plads | Datoer i teksten, beløb i saldoen | Alle rækker derefter er forkerte — og ingen ser forkert ud |
| Et referencenummer læst som beløbet | “Payment 910015” bogført som 831,00 | Et femcifret hul på et langt udtog |
| Et kreditfortegn tabt | En udgift bogført som en indtægt | Fejlen er to gange beløbet, den forkerte vej |
| Opgørelsesblokken talt som posteringer | “Forrige saldo / Ny saldo” lagt til som rækker | Totaler oppustet med præcis den dobbelte ultimosaldo |
| En side sprunget over i stilhed | En måned, der bare er kortere | Intet at se — og det er derfor, den er den værste |
Så vi byggede laget, der fanger dem
En anden motor, deterministisk — vores egen, og den kører på hvert dokument
Efter AI har læst dokumentet, gentager et separat lag dokumentets egen aritmetik. Primosaldo plus alle posteringer skal give den ultimosaldo, banken har trykt. Hver linjes løbende saldo skal følge af den foregående. Varelinjer skal summere til fakturaens total. Ingen AI, intet sikkerhedstal, ingen gæt — det er beviser, og et dokument, der fejler ét af dem, er beviseligt læst forkert.
Den nævner rækkerne, ikke en procent
Når en kontrol fejler, får du ikke en lavere score. Du får række 48, række 133, række 1.902 — markeret på plads, rødt hvor en kontrol beviste læsningen forkert og gult hvor den ikke kunne bekræfte den, med den kolonne, kontrollen nævnte, endnu tydeligere. Åbn række- eller JSON-visningen, ret dem, eksportér. Det er hele sløjfen, og den tager som regel under et minut.
Dokumentet dømmer, ikke vi
Et kontoudtog bærer sit eget bevis: det kan fange en fejl uden et menneske, uden facitliste og uden en mening fra os. Det er derfor, vi bygger på det. Hvor et dokument reelt ikke kan kontrollere sig selv — ingen løbende saldo, ingen trykt total — siger vi det rent ud i stedet for at lade tavsheden antyde, at alt er i orden.
Hvorfor procenten er det forkerte tal at købe på
| Udtogets størrelse | Hvad “99 % præcist” stiltiende tillader | Hvad det betyder for dig |
|---|---|---|
| 300 rækker | 3 forkerte rækker | En eftermiddag — hvis du finder dem |
| 1.200 rækker | 12 forkerte rækker | En afstemning, der ikke vil gå op |
| 3.400 rækker | 34 forkerte rækker | En sekscifret fejl — set i virkeligheden |
Arbejde med tal belønner at være nærig med detaljen
Læs de markerede rækker, før du eksporterer. Det er ikke et forbehold — det er det ene skridt, der gør et godt udtræk til et korrekt, og vi har brugt vores udviklingstid på at gøre det kort og præcist målrettet frem for på at runde et tal op. Alle kan trykke 99 %. At fortælle dig præcis, hvor den sidste procent ligger, er det svære løfte — og det er dét, vi er villige til at give.