Dokumentgenkendelse for udviklere

Hvorfor typet data betyder mere, end det lyder

"Typet" lyder som en teknisk detalje, indtil det er forskellen på, om jeres bogføringslogik virker eller går ned på ét enkelt bilag. Et beløb returneret som teksten 1.840,00 kræver regional fortolkning, før jeres kode trygt kan sammenligne det med noget — og den fortolkning skal gætte rigtigt på, om komma betyder decimal eller tusindtalsseparator. Returneret som et rigtigt tal findes den tvetydighed slet ikke.

Det samme gælder datoer. En faktura trykt med "03/06/2026" er reelt tvetydig mellem 3. juni og 6. marts, uden at kende dokumentets oprindelsesland — en fejl her flytter ikke bare formatet, den kan stille flytte en postering uden for den periode, jeres system afstemmer mod. Hver dato kommer tilbage som ISO 8601, allerede afklaret.

For et regnskabssystem, der modtager dokumenter fra kunder på tværs af flere lande og leverandørforhold, betyder det, at jeres egen kode aldrig skal bygge eller vedligeholde et regionalt fortolkningslag for at håndtere den variation — det er allerede løst, én gang, centralt.

Samme princip gælder for beløb med forskelligt fortegn — et negativt beløb skrevet i parentes på en faktura kommer tilbage som et almindeligt negativt tal, uden at jeres kode selv skal genkende den notation.

Hvad dette ikke gør

De tre grænser er bevidste — hver af dem er et problem, en anden slags leverandør allerede løser bedre, og at forsøge at dække dem her ville gøre funktionen bredere, men svagere på det, den faktisk er bygget til.

Fakturaens JSON-skema

{
  "type": "invoice",
  "data": {
    "vendor_name": "Example GmbH",
    "invoice_number": "INV-2201",
    "invoice_date": "2026-06-03",
    "due_date": "2026-07-03",
    "total_amount": 1840.00,
    "vat_amount": 368.00,
    "line_items": [
      { "description": "Konsulentydelse, juni", "quantity": 8,
        "unit_price": 200.00, "amount": 1600.00 }
    ]
  }
}

Momsbeløbet returneres separat fra totalbeløbet, hvilket gør det direkte anvendeligt til momsafstemning uden en ekstra udregning i jeres egen kode.

Hver linje kommer med beskrivelse, antal, enhedspris og beløb — klar til at blive matchet mod en kontoplan eller en indkøbsordre, uden at jeres kode selv skal genopbygge tabellen fra rå tekst.

Kontoudtogets JSON-skema

{
  "type": "bank_statement",
  "data": {
    "bank_name": "Example Bank",
    "account_holder": "Acme ApS",
    "statement_period": "2026-06-01 to 2026-06-30",
    "transactions": [
      { "date": "2026-06-03", "description": "Kundeindbetaling",
        "amount": 4200.00, "balance": 18940.55 }
    ]
  }
}

Hver postering kommer med dato, tekst, beløb og løbende saldo — den samme struktur, uanset hvilken bank kontoudtoget kommer fra.

Kontohaverens navn er det mest nyttige felt til et navnematch-tjek — det læses præcis som trykt på udtoget, klar til at sammenligne mod det virksomhedsnavn, jeres system allerede har registreret.

Hvordan det rigtige skema vælges

Klassificeringen sker automatisk som en del af samme /extract-kald, ud fra dokumentets egen struktur. En kunde kan uploade hvilken som helst af de fire typer gennem den samme upload-flade, og jeres pipeline får det skema tilbage, der faktisk matcher, hvad der blev sendt.

flowparse.io

Det betyder også, at jeres eget uploadflow kan forblive ét generelt felt frem for fire separate upload-veje — en simplere brugeroplevelse for kunden og mindre kode at vedligeholde i jeres eget produkt.

Klassificeringen fejler heller ikke stille — kommer et dokument ind, der ikke matcher nogen af de fire typer, markeres det som sådan, i stedet for at blive tvunget ind i det nærmeste skema.

Hvorfor typerne selv er vigtige

Når en integration er bygget mod en bestemt feltstruktur, er en ændring af den struktur en bagudinkompatibel ændring — et omdøbt felt eller en ændret datatype kan stille ødelægge en sammenligning eller en kontering, der virkede fint dagen før. Skemaerne vist ovenfor er den stabile, dokumenterede kontrakt — nye valgfrie felter kan tilføjes over tid, men eksisterende felter beholder navn, type og betydning.

For jeres eget produkt betyder det, at en integration bygget i dag fortsætter med at virke, mens nøjagtigheden forbedres i baggrunden — jeres kode behøver ikke opdateres, hver gang genkendelseskvaliteten bliver bedre.

Flersidede dokumenter

Et kontoudtog for en hel måned løber ofte over flere sider, og en årsrapport kan være betydeligt længere. Begge dele læses som ét samlet dokument — transaktionslisten eller sektionerne strækker sig automatisk over alle sider, så jeres integration får ét komplet, korrekt sorteret resultat i stedet for selv at skulle samle svar fra flere sider.

Sådan opfører det sig ved høj volumen

Intet ved skemaet eller klassificeringstrinnet ændrer sig, mens antallet af kald vokser — det samme typede svar kommer tilbage, uanset om det er det første dokument, jeres integration nogensinde har sendt, eller det hundredetusindende. Der er ikke noget batch-krav, og der findes ikke et separat højvolumen-niveau at forhandle — pris og gennemløb skalerer automatisk med forbruget.

Den finansielle rapports totalkontrol

{
  "type": "financial_report",
  "data": {
    "title": "Årsrapport",
    "entity": "Acme Trading ApS",
    "period": "Regnskabsår 2025",
    "currency": "DKK",
    "sections": [
      { "name": "Omsætning", "rows": [ { "label": "Nettoomsætning", "amount": 842000 } ] },
      { "name": "Omkostninger", "rows": [ { "label": "Vareforbrug", "amount": 511000 } ] }
    ],
    "report_check": { "ties_out": true }
  }
}

Hver finansiel rapport kommer tilbage med en report_check-vurdering — om summen af de læste linjer faktisk stemmer med dokumentets egne trykte totaler. En rapport, der ikke går op, bliver markeret, hvilket er værd at vide, før det data fylder ind i en beslutning, uanset om uoverensstemmelsen viser sig at være en genkendelsesfejl eller en reel uoverensstemmelse i det indsendte dokument.

Denne kontrol bekræfter ikke, at regnskabet er korrekt i nogen absolut forstand — en virksomhed kunne indsende internt konsistente tal, der stadig fejlrepræsenterer dens reelle finansielle stilling. Den bekræfter det snævrere, konkrete, et dokumentlæsende værktøj faktisk kan bekræfte: at de trykte totaler matcher de summerede totaler.

En note om scannede og fotograferede dokumenter

Ikke alle kunder uploader en ren digital eksport — en scannet faktura eller et foto af en kvittering taget med en telefon er almindeligt, især fra mindre virksomheder eller ældre leverandørforhold. Begge dele går gennem samme klassificerings- og udtrækspipeline som et digitalt dokument, med sikkerhedsvurdering kalibreret til at afspejle den ekstra usikkerhed, en scanning eller et foto reelt indebærer, i stedet for stiltiende at behandle det som ligeværdigt med en ren digital kilde.

For jeres uploadflade betyder det, at I kan tillade begge dele fra dag ét, uden at skulle bygge en separat, strengere valideringssti for scannede dokumenter.

Sådan fungerer det

En blandet aflevering, udtrukket

En kunde uploader tre fakturaer, to kvitteringer og ét kontoudtog i samme session — seks separate kald til /extract, hver klassificeret og returneret som sit eget skema.

Ingen af de seks krævede, at kunden eller jeres pipeline på forhånd angav dokumenttypen — genkendelsen fandt den selv, hver gang.

For jeres uploadflade betyder det, at kunden kan sende blandet indhold i én omgang — hele bunken fra en skuffe, fotograferet i træk — uden at skulle sortere den efter type først.

Dokumenter, dette er bygget til at klare

Ingen af de fire kræver en særskilt funktion bygget specifikt til den situation — den samme generelle genkendelsesproces håndterer dem alle, hvilket er præcis pointen med at bygge på dokumentets egen struktur frem for en samling af skabeloner.

Rå OCR-tekst vs. typet dokumentdata

Forskellen bliver størst i den lange hale af kanttilfælde — en linje, der fortsætter over et sideskift, et beløb skrevet i negativt format, en dato uden årstal fordi den står i et kolonneoverskrift. Rå OCR-tekst efterlader alt det til jeres egen parsingkode; typet dokumentdata har allerede håndteret det.

Hvem bruger dette

Fælles for dem alle er, at genkendelsen fylder ind som en byggeklods i noget større, der allerede findes — ingen af dem bygger sit produkt omkring dette API, de bygger det ind i et produkt, der allerede handler om noget andet: bogføring, betalinger, kunderapportering.

Hvorfor en generel OCR-tjeneste ikke er en genvej her

En generel dokument-AI-tjeneste kan trække tekst og tabelkoordinater ud af en side — en reel og nyttig egenskab, men ikke det samme som denne funktion. Den har ingen forståelse for en fakturas linjestruktur specifikt, ingen indbygget totalkontrol for en rapports linjer, og ingen sikkerhedsvurdering kalibreret til, hvilke felter der faktisk betyder noget for en navnematchning.

At komme fra rå OCR-output til skemaerne vist ovenfor er selv et betydeligt byggeri — at genopbygge en transaktionstabel på tværs af sideskift, beslutte hvordan et signeret beløb repræsenteres konsistent, validere at en rapports totaler faktisk går op. Det lag er præcis, hvad denne funktion allerede er, tilgængeligt som ét typet svar i stedet for et internt projekt over flere måneder oven på en generel tjeneste.

Hvorfor bilag er sværere, end de ser ud til

En faktura ser enkel ud ved første øjekast — leverandør, beløb, en dato — men den faktiske variation på tværs af leverandører, lande og systemgenerationer er betydelig: forskellige kolonnerækkefølger, forskellig håndtering af moms, forskellige måder at bryde en linje over to sider på. Et kontoudtog varierer endnu mere, fordi der ikke findes ét fælles layout for, hvordan en bank viser sine posteringer.

Det er præcis grunden til, at en generel OCR-tjeneste alene ikke er nok — den læser teksten, men at gøre den tekst til et pålideligt vendor_name-felt eller en korrekt summeret linjeliste er et betydeligt fortolknings- og valideringslag, der skal bygges og vedligeholdes ovenpå. Det lag er, hvad denne funktion allerede er.

Den variation er også, hvorfor et skabelonbaseret internt forsøg typisk holder fint i starten og først bliver et reelt problem, når kundebasen vokser sig bredere end det oprindelige testsæt af dokumenter.

Det er også derfor, en evaluering af denne funktion er mest overbevisende, når den køres mod jeres egne, reelle dokumenter — ikke rene, udvalgte eksempler.

Kom i gang

Send en rigtig faktura eller et kontoudtog gennem /extract og se det typede skema selv. Se den fulde API-oversigt for, hvordan det passer ind i resten af et regnskabsflow.

Sikkerhed og privatliv

Fulde detaljer findes på sikkerhedssiden — værd at have parat, hvis en kunde eller revisor spørger til, hvordan uploadede dokumenter håndteres.

Spørgsmål og svar

Læs videre