Hvordan vi byggede en OCR-proces til dokumenter, der faktisk fungerer til international handel

Atlas Verified-teamet
·
15. oktober 2025
·
6 min. læsning
Hvordan vi byggede en OCR-proces til dokumenter, der faktisk fungerer til international handel

Hvis du nogensinde har forsøgt at udtrække strukturerede data fra et konnossement ved hjælp af en generel OCR-tjeneste, kender du allerede pointen: Det fungerer ikke. I hvert fald ikke pålideligt. Og ved overholdelse af internationale handelsregler er "ikke pålideligt" det samme som "slet ikke".

Hos Atlas Verify behandler vi tusindvis af handelsdokumenter — konnossementer, økologiske certifikater, plantesundhedscertifikater, oprindelsescertifikater, handelsfakturaer, pakkelister og snesevis af andre. Tidligt evaluerede vi alle større OCR-platforme på markedet. De fejlede alle den samme test: Giv dem et dokument, de ikke specifikt er blevet trænet på, og resultatet spænder fra ufuldstændigt til farligt forkert.

Dette indlæg forklarer, hvorfor vi byggede en tilpasset dokumentbehandlingsproces, hvad der gør handelsdokumenter særligt vanskelige, og de tekniske principper, der styrer vores tilgang.

Problemet med dokumenternes mangfoldighed

De fleste OCR-tjenester er optimeret til et snævert udvalg af dokumenttyper. Google Document AI er fremragende til fakturaer og kvitteringer. AWS Textract håndterer strukturerede formularer godt. Azure Form Recognizer kan trænes på tilpassede skabeloner. Men international handel genererer en overvældende mangfoldighed af papirarbejde.

Alene i vores system håndterer vi over 35 forskellige dokumenttyper. Et konnossement ligner slet ikke et økologisk certifikat. Et plantesundhedscertifikat fra USDA har næsten ingen strukturel lighed med et udstedt af EU. En ankomstmeddelelse fra ét rederi kan være en struktureret PDF med tydelige tabeller; fra et andet er den en scannet fax med håndskrevne noter.

Den afgørende indsigt er, at hver dokumenttype har sit eget skema — et specifikt sæt felter, der er vigtige for verifikation af regeloverholdelse. Et konnossement kræver afsender, modtager, part der skal underrettes, containernumre, skibsnavn, laste- og lossehavne samt varebeskrivelser. Et økologisk certifikat kræver certificeringsorgan, virksomhedsnavn, NOP-id, certificerede produkter og gyldighedsdatoer.

Generelle OCR-værktøjer forstår ikke disse skemaer. De udtrækker tekst. De kan måske identificere tabeller. Men de ved ikke, at strengen "MEDU4107760" er et containernummer, eller at "NOP ID: 7880315519" er en kritisk identifikator, som skal verificeres mod USDA Organic Integrity Database. Uden forståelse af skemaer er OCR blot dyr tekstkonvertering.

Hvorfor "godt nok" er farligt

I de fleste softwareapplikationer er en nøjagtighed på 95% fremragende. Ved overholdelse af handelsregler er den en risiko.

Overvej et containernummer. Standardformatet (ISO 6346) er fire bogstaver efterfulgt af syv cifre, hvor det sidste ciffer er et kontrolciffer. Hvis OCR fejllæser et enkelt tegn — et "0" bliver til et "O", et "8" bliver til et "B" — er containernummeret ugyldigt. Efterfølgende systemer, der forsøger at spore containeren, returnerer ingen resultater, og verifikationskæden brydes lydløst.

Det samme princip gælder for NOP-id'er, HS-koder, IMO-numre og certificeringsdatoer. En fejl på ét enkelt tegn kan ændre betydningen fuldstændigt. En HS-kode på 0901.11 (kaffe, ikke ristet, ikke koffeinfri) kontra 0901.12 (kaffe, ikke ristet, koffeinfri) udløser forskellige toldsatser, forskellige myndighedskrav og forskellige risikoprofiler.

Vores arkitektur

Vores dokumentbehandlingsproces har tre trin, som hver er designet til at maksimere nøjagtigheden ved de specifikke udfordringer i handelsdokumentation.

Trin 1: Dokumentklassificering — Før vi udtrækker data, identificerer vi først, hvilken type dokument vi ser på. Denne klassificering bestemmer, hvilket udtræksskema der skal anvendes, hvilke felter der skal søges efter, og hvordan resultaterne skal valideres.

Trin 2: Udtræk med forståelse af skemaer — Når dokumentet er klassificeret, anvender vi en typespecifik udtræksmodel, der ved præcis, hvilke felter den skal lede efter, og hvor de typisk optræder i den dokumenttype. Dette er grundlæggende forskelligt fra generel OCR, som udtrækker alt og overlader fortolkningen til brugeren.

Trin 3: Krydsvalidering — Udtrukne data krydskontrolleres automatisk mod eksterne datakilder. Containernumre valideres mod rederiernes API'er. NOP-id'er kontrolleres mod USDA Organic Integrity Database. Havnekoder verificeres mod World Port Index. Dette trin opdager både OCR-fejl og svigagtige data.

Erfaringer

Efter behandling af titusindvis af handelsdokumenter er flere principper blevet tydelige:

1. Fagspecifikt slår generelt. Hvert forsøg på at bruge en generel OCR-tjeneste krævede så meget efterbehandling, at vi brugte mere udviklingstid på at rette dens output, end vi ville have brugt på at bygge en tilpasset løsning.

2. Klassificering er fundamentet. En forkert dokumenttype forplanter sig til hvert efterfølgende trin. Vi investerer kraftigt i klassificeringens nøjagtighed, fordi alt efterfølgende afhænger af den.

3. Validering er vigtigere end udtræk. Det er nyttigt at udtrække et containernummer. At bekræfte, at det er en rigtig container på et rigtigt skib i den korrekte havn, er det, der faktisk betyder noget for regeloverholdelsen.

4. Struktureret output muliggør automatisering. Målet er ikke at digitalisere dokumenter, så mennesker kan læse dem. Det er at producere maskinlæsbare, strukturerede data, der føres direkte ind i automatiserede verifikationsarbejdsgange.

At bygge en pålidelig dokumentbehandlingsproces til international handel er virkelig svært. Dokumenterne er forskellige, nøjagtighedskravene er ekstreme, og konsekvenserne af fejl er betydelige. Men det er også grundlæggende — hver verifikationsfunktion, vi bygger, afhænger af at kunne læse og forstå de dokumenter korrekt, der følger varer gennem globale forsyningskæder.

Kunne du lide denne artikel?

Del den med dit netværk