Hvad et regnskabssystem faktisk skal læse
Et dansk regnskabssystem, der lever op til bogføringslovens krav til digitale systemer, skal kunne registrere, opbevare og eksportere bogføringen korrekt. Loven stiller ikke krav om, at systemet selv skal kunne læse en faktura ud af en PDF-fil eller genkende posteringerne på et scannet kontoudtog — men det er præcis den funktion, kunderne i praksis forventer, fordi det er den, der sparer dem for indtastning.
Den forventning er, hvad denne side handler om: dokumentgenkendelse som en separat, veldefineret API-funktion, som et regnskabssystem kan bygge oven på, i stedet for selv at udvikle og vedligeholde et OCR-lag ved siden af sit egentlige produkt.
Hvorfor dette ikke handler om OIOUBL og NemHandel
Et naturligt første spørgsmål fra et dansk regnskabssystem er, om dette overlapper med NemHandel, OIOUBL eller Peppol — Danmarks infrastruktur til strukturerede e-fakturaer mellem virksomheder og det offentlige. Svaret er nej, og det er værd at være tydelig om hvorfor: en OIOUBL-faktura, der kommer gennem NemHandel, er allerede struktureret data. Den skal læses fra sin XML, ikke genkendes med OCR — det ville være at gøre arbejdet om.
Det, langt de fleste danske virksomheder faktisk sidder med hver måned, er noget andet: en udenlandsk leverandørs faktura uden for NemHandel, en kvittering fra en fysisk butik, et kontoudtog fra banken, et udlæg fotograferet med en telefon. Ingen af dem kommer struktureret. Det er dét dokumentgenkendelse løser — og det er det, dette API er bygget til.
Det er værd at gentage denne skelnen tydeligt, for den kommer ofte op igen senere — hos en ny udvikler på teamet, hos en kunde, der spørger, eller hos en revisor, der skal forstå flowet. Jo klarere skellet er fra starten, jo mindre forvirring opstår senere.
Hvad dette ikke gør
Udsteder ikke OIOUBL-, NemHandel- eller Peppol-fakturaer
Det er en helt anden infrastruktur — strukturerede fakturaer, der allerede eksisterer som data, skal læses fra deres XML, ikke genkendes med dette API.
Gør ikke jeres system til et registreret bogføringssystem
Registreringen hos Erhvervsstyrelsen handler om jeres systems egne funktioner som helhed — dette API er én byggeklods, ikke en genvej til registreringen.
Sender intet til SKAT
Udtrækket returnerer strukturerede tal til jeres eget system. Indberetning, moms og SAF-T-eksport forbliver jeres systems ansvar.
Bogfører ikke selv posteringerne
Det læser og strukturerer dokumentet. Kontering, modkonti og selve bogføringen sker i jeres eget system, ud fra den struktur, I får tilbage.
Hvor det passer ind i dit produkt
Et regnskabssystems fulde dokumentflow dækker typisk tre kilder: strukturerede e-fakturaer gennem NemHandel, banktransaktioner gennem en bankforbindelse eller CAMT/MT940-fil, og alt det resterende — fakturaer, kvitteringer og kontoudtog, der ikke kommer på nogen af de to strukturerede veje. Dette API er bygget specifikt til den tredje kategori, som i praksis udgør en stor del af, hvad en bogholder eller virksomhedsejer uploader manuelt hver måned.
Jo bedre et regnskabssystem dækker alle tre kilder konsistent, jo mindre af bogføringen ender med at stå tilbage som ren manuel indtastning — hvilket i praksis er det, der oftest afgør, om en kunde oplever produktet som et reelt tidsbesparende værktøj eller som endnu en digital udgave af en papirbunke.
Hvorfor det virker uden en skabelon pr. leverandør
En almindelig tidlig antagelse om dokumentgenkendelse er, at den kræver en skabelon pr. leverandør eller pr. bank — en fastlagt kortlægning af, hvor på siden hvert felt plejer at stå. Den tilgang bryder sammen, i det øjeblik en kunde uploader en faktura fra en leverandør, ingen skabelon endnu er bygget til, hvilket for et bogføringssystem med kunder på tværs af mange brancher og leverandørrelationer ikke er et sjældent kanttilfælde — det er en jævnlig hændelse.
Genkendelsen arbejder i stedet ud fra dokumentets egen struktur — den læser en fakturas layout, sådan som en person ville, i stedet for at matche den mod en fast skabelon for én bestemt leverandør. En faktura fra en leverandør, der behandles for første gang, læses på samme måde som en fra en leverandør, der er set tusind gange før, hvilket betyder direkte noget for et bogføringssystem, hvis kundekreds ikke er begrænset til en håndfuld velkendte leverandørforhold.
Det samme gælder kontoudtog og finansielle rapporter — et kontoudtogs posteringsliste eller en rapports flersektionsstruktur læses ud fra dokumentets egne trykte sektioner og totaler, ikke ud fra en skabelon knyttet til én bestemt bank eller ét bestemt regnskabsprograms eksportformat.
Kaldene, der betyder noget
Fire endpoints dækker selve udtrækket, dokumenteret i sin helhed på API-dokumentationssiden — herunder er de kald, I reelt vil bruge fra en produktionspipeline.
curl -X POST https://flowparse.io/api/v1/extract \
-H "Authorization: Bearer pf_live_xxx" \
-H "Content-Type: application/json" \
-d '{ "file": "JVBERi0xLjcK...", "filename": "supplier-invoice.pdf" }'
# → { "type":"invoice", "pages":2, "billedPages":2,
# "price": { "eur":0.07, "perPageEur":0.035, "complexity":"standard" },
# "data": { "type":"invoice", "data": {
# "vendor_name":"Example GmbH", "invoice_number":"INV-2201",
# "total_amount":1840.00, "line_items":[ ... ] } } }curl -X POST https://flowparse.io/api/v1/validate \
-H "Authorization: Bearer pf_live_xxx" \
-H "Content-Type: application/json" \
-d '{ "type": "invoice", "data": { "vendor_name": "Example GmbH",
"total_amount": 1840.00 } }'
# → { "valid": true, "issues": [] }/validate er gratis på alle planer — det rigtige sted at afprøve jeres datakontrakt, før noget koster noget.
Hvad bliver læst
| Dokumenttype | Hvad kommer tilbage |
|---|---|
| Faktura | Leverandør, fakturanummer, dato, forfaldsdato, momsbeløb og hver linje med beskrivelse, antal og pris |
| Kvittering | Butik, dato, beløb, momssats og de enkelte varelinjer, hvor de findes |
| Kontoudtog | Bank, kontohaver, periode og hver postering med dato, tekst, beløb og saldo |
| Finansiel rapport | Virksomhed, periode, valuta og hver linje i regnskabets sektioner, plus en kontrol af, om totalerne går op |
Hvordan det rigtige dokument genkendes
Jeres pipeline behøver ikke fortælle API'et på forhånd, om der kommer en faktura, en kvittering eller et kontoudtog — klassificeringen sker automatisk som en del af samme /extract-kald, ud fra dokumentets egen struktur. En kunde kan uploade hvad som helst gennem den samme flade, og I får det skema tilbage, der faktisk matcher det, der blev sendt.
Sådan fungerer prisen
Udtræk afregnes pr. side, i kompleksitetstrin — et rent, digitalt genereret dokument koster mindre end en tæt, flersidet rapport eller en scanning af lav kvalitet. Ingen licens pr. bruger, ingen minimumsforpligtelse for at komme i gang.
curl https://flowparse.io/api/v1/usage \
-H "Authorization: Bearer pf_live_xxx"
# → { "plan":"PRO", "pageRangeEur": { "minEur":0.01, "maxEur":0.15 },
# "balance": { "pages":812, "monthlyRemaining":712, "bonusPages":100 } }For et regnskabssystem oversættes det direkte til en kendt omkostning pr. kunde eller pr. bilag — et tal, I kan bygge direkte ind i jeres egen prissætning, i stedet for en uforudsigelig infrastrukturpost.
Sådan fungerer det i dit produkt
Kunden uploader et dokument
Fakturaen, kvitteringen eller kontoudtoget, dér hvor jeres produkt allerede modtager bilag.
Jeres pipeline kalder /extract
Ét POST-kald med filen; struktureret JSON med felter, linjer og sikkerhedsniveau kommer tilbage.
Data ruter efter sikkerhedsniveau
Høj-sikkerhed går videre automatisk; lav-sikkerhed sendes til jeres egen kø til gennemgang.
Data lander i jeres eget bogføringsflow
Klar til kontering og postering — selve bogføringslogikken forbliver jeres.
Et gennemregnet eksempel
En kunde hos et regnskabssystem uploader ti udenlandske leverandørfakturaer og ét scannet kontoudtog i forbindelse med en månedlig bogføring.
| Dokument | Resultat |
|---|---|
| 10 udenlandske fakturaer | Alle klassificeret korrekt, linjer og momsbeløb læst, 0,4 sekunder pr. faktura |
| 1 scannet kontoudtog | 42 posteringer læst, saldoen går op, sikkerhedsniveau 0,97 |
| Manuel gennemgang nødvendig | Nej — alt gik videre automatisk |
Havde kunden i stedet uploadet en OIOUBL-faktura fra NemHandel, ville den slet ikke skulle igennem dette API — den er allerede data, og skal læses direkte fra sin XML.
Værd at bemærke: det samme kald håndterede alle ti udenlandske fakturaer, uden at noget af dem havde behøvet en forhåndsdefineret skabelon — hver leverandørs layout blev læst, som det var, første gang systemet så det.
Byg selv eller integrér
| At bygge det selv | At kalde dette API |
|---|---|
| En generel OCR-tjeneste plus jeres egen feltgenkendelse, linjegenopbygning og sikkerhedslogik | Ét typet skema tilbage fra ét kald |
| Ingeniørtid målt i måneder, plus løbende vedligehold når nye layouts dukker op | Integration typisk oppe at køre inden for en dag eller to |
| Egen infrastruktur til hosting, overvågning og skalering | Ingen infrastruktur — forbrugsbaseret pris, ingen servere at drive |
| Jeres eget team ejer enhver nøjagtighedsregression | Udtrækskvaliteten er kerneproduktet, forbedret uafhængigt af jeres udgivelsescyklus |
Almindelige integrationsfejl
At behandle et lavt sikkerhedsniveau som en afvisning
En lav score på ét felt betyder, at netop det felt er reelt usikkert og værd at kigge på — ikke at hele dokumentet eller kunden skal afvises. De fleste teams ruter efter feltniveau, ikke én samlet dokumentdom.
At sammenligne navne med en streng eksakt matchning
"Acme Trading Aps" og "ACME TRADING APS" er samme virksomhed. Et matchningstrin, der normaliserer store/små bogstaver, tegnsætning og selskabsformer, før det sammenligner, undgår en bølge af falske mismatches, der intet har med reel risiko at gøre.
At springe /validate over under udviklingen
At teste jeres datakontrakt mod det gratis /validate-endpoint, før I kører rigtig udtræksvolumen, fanger integrationsfejl — et manglende felt jeres kode forventer, en typemismatch — uden at bruge penge, mens I stadig fejlfinder jeres egen pipeline.
At antage, at en totalkontrol, der ikke går op, betyder et forfalsket dokument
En mismatch kan lige så godt skyldes en side, der ikke scannede rent, som et reelt manipuleret dokument. Det er et stærkt signal til gennemgang, ikke bevis på noget i sig selv.
Nøjagtighed og sikkerhedsniveau
Feltnøjagtigheden ligger omkring 99 % på almindelige layouts — digitalt genererede fakturaer og kvitteringer. En scannet eller fotograferet aflevering varierer mere, hvilket er præcis hvorfor hvert felt har sit eget sikkerhedsniveau.
Den granularitet betyder, at én usikker linje på en ellers klar faktura ikke kræver samme gennemgangsindsats som et dokument, hvor genkendelsen har haft svært ved det som helhed — hvilket holder jeres kø til manuel gennemgang proportional med den faktiske usikkerhed.
Eksportformater
Ud over rå JSON til direkte integration kan det samme udtrukne dokument eksporteres til xlsx eller csv.
curl -X POST https://flowparse.io/api/v1/export \
-H "Authorization: Bearer pf_live_xxx" \
-H "Content-Type: application/json" \
-d '{ "format": "xlsx", "type": "invoice", "data": { ... } }'
# → { "format":"xlsx", "filename":"invoice.xlsx",
# "encoding":"base64", "content":"UEsDBB..." }Fejl og grænser
| Kode | Betydning |
|---|---|
| 400 | Ugyldig forespørgsel eller ikke-understøttet format |
| 401 | Manglende, ugyldig eller tilbagekaldt API-nøgle |
| 422 | Intet udtrækbart data i det indsendte dokument |
| 429 | Sidesaldo opbrugt — fyld op for at fortsætte |
Der er ingen grænse for kald pr. sekund at designe efter — den eneste grænse er jeres sidesaldo, som fyldes op med det samme ved betaling, så en travl måned ikke kræver særlig håndtering i jeres pipeline.
Fra pilot til fuld kundebase
Et regnskabssystem, der integrerer dette for første gang, starter typisk med at sende en håndfuld testdokumenter manuelt gennem /extract, bekræfter at skemaet matcher, hvad deres eget bogføringsflow forventer, og kobler det derefter ind i den rigtige pipeline, når sikkerhedsniveau-tærsklen er tilpasset.
Derfra skalerer det uden nogen ændring i integrationen — det samme kald håndterer ti dokumenter om dagen eller ti tusind, fordi pris og gennemløb er forbrugsbaseret frem for bundet til en fast infrastruktur.
Det betyder, at et regnskabssystem, der lancerer i et nyt segment eller pludselig vinder en stor ny kunde, ikke behøver planlægge en infrastrukturopgradering forud for det — volumen skalerer, som den kommer.
Hvem det er til
Danske regnskabssystemer og bogføringsplatforme
Dokumentgenkendelsen, uden selv at bygge og vedligeholde et OCR-lag ved siden af produktet.
Regnskabsbureauer med eget værktøj
En genkendelseslag til jeres interne system, i stedet for manuel indtastning på tværs af klienter.
Fintech- og betalingsplatforme med bogføringsfunktioner
Dokumentudtræk til de bilag, der ligger uden for jeres bankforbindelse.
Udviklere, der bygger ovenpå et eksisterende system
Et enkelt API-kald i stedet for en intern OCR-afdeling.
Fælles for alle fire er, at dokumentgenkendelse er en nødvendig understøttende funktion, ikke selve kerneproduktet — hvilket er præcis den type opgave, der bør løses af en dedikeret leverandør frem for at optage udviklerkapacitet, der ellers kunne gå til produktets egentlige differentiering.
Kom i gang
Hent en gratis API-nøgle og send en rigtig faktura eller et kontoudtog gennem /extract, før I forpligter jer til noget — intet betalingskort krævet for at se, hvordan svaret ser ud.
De fleste teams har et konkret svar på, om det passer til deres behov, inden for en enkelt eftermiddags test — hurtigere, end de fleste forventer, før de rent faktisk prøver det.
Sikkerhed og privatliv
Uploads er krypteret med TLS hele vejen igennem.
Behandlingen kører på infrastruktur med SOC 2-tilpassede kontroller.
Originale dokumenter slettes kort tid efter behandlingen.
Intet, I uploader, bruges nogensinde til at træne AI-modeller.
Fulde detaljer findes på sikkerhedssiden. For et regnskabssystem, der selv skal kunne stå inde for sin datahåndtering over for kunder og revisorer, betyder det direkte noget at have et konkret, dokumenteret svar klar.