Forståelse af kontoudtog-formater: Den tekniske guide

Et kontoudtog i PDF-format ser simpelt ud: datoer, beskrivelser, beløb, saldi i pæne kolonner. Men bag dette udseende ligger et dokumentformat (PDF), der aldrig var designet til at gemme strukturerede data – og en konverteringsproces, der kræver forståelse af både inputformatet og de mange tilgængelige outputformater.

Denne guide dækker de 12 sektioner, der findes på ethvert kontoudtog (uanset bank), den tekniske virkelighed bag kontoudtog-PDF'er, layoutvariationer på tværs af banker, alle outputformater, du vil støde på (Excel, CSV, QBO, OFX, QFX, QIF, JSON), internationale formateringsforskelle og industristandarder, der styrer udveksling af finansielle data.

Anatomi af et Kontoudtog

Ethvert kontoudtog – Chase, Bank of America, Wells Fargo, HSBC, Deutsche Bank, you name it – er bygget op af de samme 12 sektioner. Mærkaterne ændrer sig ("Subtraktioner" vs "Hævninger"), kolonnearrangementerne varierer, men den underliggende struktur er konsistent. Når du først kan identificere disse sektioner, ser ethvert udtog velkendt ud.

Vil du bruge denne infografik på din blog? Kopier denne indlejringskode:

For bankspecifikke dybdegående analyser, der dækker præcis, hvordan hver større bank arrangerer disse 12 sektioner, se:

• Chase kontoudtog forklaret
• Bank of America kontoudtog forklaret
• Wells Fargo kontoudtog forklaret
• Citi kontoudtog forklaret
• Capital One kontoudtog forklaret

Hvorfor PDF Ikke Er Et Dataformat

PDF står for Portable Document Format, standardiseret som ISO 32000 (version 2.0 blev ISO 32000-2:2020). Det blev designet til ét formål: at få dokumenter til at se identiske ud på enhver skærm og printer. Det er fantastisk for visuel trofasthed – og forfærdeligt for dataudtræk.

Hvad er Der Faktisk Inde i en Kontoudtog-PDF?

Inde i hver PDF-side er en indholdsstrøm – en sekvens af tegneoperatorer skrevet i et PostScript-lignende sprog. Tekst gengives ved hjælp af specifikke operatorer:

• BT / ET – Begynd Tekst / Afslut Tekst: grænser for et tekstobjekt
• Tf – Indstil skrifttype og størrelse
• Td / Tm – Flyt tekstposition eller indstil den fulde teksttransformationsmatrix
• Tj – Vis en tekststreng
• TJ – Vis tekst med individuel glyph-positionering (kerningjusteringer)

Den afgørende indsigt: Der er intet koncept om en "tabel", "række" eller "kolonne" i PDF-specifikationen. Hvad der ligner en pænt formateret transaktionstabel, er faktisk dusinvis af tekstfragmenter placeret på specifikke x,y-koordinater på siden. Udtrækningsværktøjet skal:

1. Parse indholdsstrømsoperatorerne
2. Opløse skrifttype-encodninger for at mappe glyph-indekser til Unicode-tegn
3. Bruge tekstmatricen (Tm/Td) til at bestemme x,y-positionen for hvert tegn
4. Rekonstruere ord, linjer og kolonner ud fra disse koordinater

En kolonne, der ser perfekt justeret ud, kan være på x=72.0 på én linje og x=72.5 på den næste. Udtrækningsalgoritmen skal definere kolonne-grænser med tolerance for disse sub-pixel variationer.

Taggede vs. Ikke-taggede PDF'er

Taggede PDF'er inkluderer et skjult logisk strukturtræ (svarende til HTML-tags), der markerer indhold som overskrifter, afsnit, tabeller, tabelrækker og tabelceller. Dette gør udtræk betydeligt lettere.

Ikke-taggede PDF'er har ingen strukturel metadata – udtrækningsværktøjet får kun rå positionsdata og skal selv udlede alt.

De fleste kontoudtog-PDF'er genereret af banker er ikke-taggede. Banker genererer udtog ved hjælp af batch-behandlingssystemer (Oracle BI Publisher, SAP Crystal Reports eller brugerdefinerede print-til-PDF-pipelines). Tilgængelighedsregler (ADA/WCAG) presser banker mod taggede PDF'er, men adoptionen er langsom. Standarddownloads fra de fleste større banker forbliver ikke-taggede.

Variationer i Kontoudtog-Layout

Der er ingen industristandard for, hvordan banker formaterer deres PDF-kontoudtog. De samme fem informationsstykker – dato, beskrivelse, debet, kredit, saldo – er arrangeret forskelligt af hver bank.

Enkelt Beløbskolonne (Med fortegn)

Dato Beskrivelse Beløb Saldo
15/01/26 DIREKTE LØN +3.500,00 5.200,00
16/01/26 POS KØB DAGLIGVARER -87,50 5.112,50

Debetposter er negative, kreditposter er positive (eller omvendt). Almindeligt hos mindre banker, kreditforeninger og digitale banker. Simpel at parse, da der kun er én beløbskolonne at udtrække.

Separate Debet-/Kreditkolonner

Dato Beskrivelse Hævninger  Indbetalinger Saldo
15/01/26 DIREKTE LØN 3.500,00 5.200,00
16/01/26 POS KØB DAGLIGVARER 87,50 5.112,50

Bruges af Chase, Bank of America og mange traditionelle banker. Udtrækningsværktøjet skal identificere, hvilken kolonne der indeholder beløbet, og bestemme fortegnet derefter.

Grupperet efter Transaktionstype

Erhvervs- og firmakonti grupperer ofte transaktioner:

INDLÆG OG ANDRE KREDITTER 15/01  Bankoverførsel Ind REF#12345 10.000,00 18/01  Checkindbetaling #4567 2.500,00 Total Indbetalinger 12.500,00
 
UDSTEDTE CHECKS 16/01  Check #1234 850,00 17/01  Check #1235 1.200,00 Total Checks 2.050,00
 
ELEKTRONISKE TRANSAKTIONER 19/01  ACH PYMT - Leverandør A/S 3.200,00 20/01  Online Overførsel til Opsparing 1.000,00 Total Elektronisk 4.200,00

Sektionsoverskrifterne bestemmer, om transaktioner er debet eller kredit. Opsummeringslinjer ("Total Indbetalinger") skal identificeres og udelades fra transaktionsdata.

Bankspecifikke Karakteristika

• Chase – Separate debet-/kreditkolonner; grupperer efter "DEPOSITS AND ADDITIONS" og "ELECTRONIC PAYMENTS" og "FEES"; flertrinsbeskrivelser almindelige for forhandlerdetaljer
• Bank of America – Separate hæve-/indbetalingskolonner; inkluderer en "Daily Balance"-sektion til sidst; omfattende header med kontonummer, kontoudtog-periode, routingnummer
• Wells Fargo – Separate kolonner; inkluderer "DAILY BALANCE SUMMARY"-sektion; kalder deres CSV-download "Comma Delimited"
• Capital One – Rent enkelt-beløbslayout for forbrugerkort; minimal headerinformation
• Citi – Inkluderer ofte internationale transaktionsdetaljer med oprindelige valuta-beløb og vekselkurser på separate linjer

Variationer i Kolonnearrangement

Ud over spørgsmålet om debet/kredit er kolonneordenen ikke standardiseret:

• Kolonneorden: Dato-Beskrivelse-Beløb-Saldo vs. Dato-Beløb-Beskrivelse-Saldo
• Checknummer: Til stede i erhvervskonti, fraværende i personlige
• Referencenummer: Almindeligt i erhvervskontoudtog, sjældent i personlige
• Løbende saldo: Per transaktion (mest almindeligt) vs. daglige delsummer vs. helt fraværende

Digitale vs. Scanning-PDF'er

Den absolut vigtigste faktor, der påvirker konverteringsnøjagtigheden, er, om din PDF er digital eller scannet.

Digitale (Native) PDF'er

Oprettet programmatisk af din banks system, når du downloader et udtog. Tekst gemmes som indholdsstrømsoperatorer med skrifttype-encodninger.

• Nøjagtighed: 99 %+ for tekstudtræk – ingen genkendelsesfejl
• Hastighed: Millisekunder pr. side
• Privatliv: Kan behandles fuldstændigt i din browser – filen forlader aldrig din enhed
• Filstørrelse: Typisk 50KB–500KB pr. side
• Sådan identificeres: Du kan markere og fremhæve individuelle ord

Scannede PDF'er

Billeder af papir-kontoudtog – oprettet ved at scanne eller fotografere et fysisk dokument. Indhold gemmes som rasteriserede billeder (JPEG, JPEG2000, CCITT eller Flate komprimeret).

• Nøjagtighed: 95–99 % med professionel OCR; 65–70 % med generisk OCR
• Hastighed: Sekunder pr. side (kræver billedbehandling)
• Privatliv: Kræver typisk server-side behandling (filen skal uploades til OCR)
• Filstørrelse: 200KB–2MB+ pr. side
• Sådan identificeres: Du kan ikke markere nogen tekst; zoomer du til 400 %, ser du pixelering

Hvorfor Scannet Nøjagtighed Betyder Mere for Finansielle Data

En 97 % tegn-nøjagtighed lyder fremragende, indtil du anvender den på finansielle data. På et udtog med 1.000 tegn af beløb er det 30 fejl-aflæste tegn. Et enkelt fejl-aflæst ciffer ændrer et transaktionsbeløb: "1.234,56 kr." bliver til "1.234,86 kr." eller "7.234,56 kr.". Avanceret OCR opnår næsten 99 % nøjagtighed, men de resterende fejl falder uforholdsmæssigt på tegn, der ligner hinanden: 0/O, 1/l/I, 5/S, 8/B, 6/G, og kritisk, komma/punktum.

Foretræk altid digitale downloads. Download udtog fra din banks hjemmeside i stedet for at scanne papir. Dette eliminerer OCR-fejl fuldstændigt.

Output Formater: Dybdegående

Når du konverterer et kontoudtog, vælger du et outputformat. Hvert format har forskellige styrker, begrænsninger og ideelle anvendelsesscenarier.

Excel (.xlsx)

Standard: Office Open XML (OOXML), standardiseret som ECMA-376 og ISO/IEC 29500.

Hvad det er: En .xlsx-fil er faktisk et ZIP-arkiv, der indeholder XML-filer – arbejdsbogsstruktur, celldata, stilarter og delte strenge. Derfor kan den gemme datatyper (datoer som datoer, tal som tal), formatering, formler og flere ark.

Hvorfor den er populær til kontoudtog:

• Datoer forbliver datoer (sorterbare, filtrerbare)
• Tal forbliver tal (summerbare, formaterbare)
• Formler til afstemning (SUM, VLOOKUP)
• Pivot-tabeller til kategorisering af forbrug
• Betinget formatering til at fremhæve uoverensstemmelser
• Del med kunder, der har brug for et læsbart regneark

Begrænsninger:

• Maksimalt 1.048.576 rækker (sjældent relevant for kontoudtog)
• Ikke direkte importerbar i de fleste regnskabsprogrammer (brug QBO/OFX i stedet)
• Kræver Excel, Google Sheets eller LibreOffice Calc for at åbne

Bedst til: Manuel gennemgang, brugerdefineret analyse, afstemning, arkivering, kundrapportering.

CSV (Comma-Separated Values)

Standard: RFC 4180 (2005) – "Common Format and MIME Type for Comma-Separated Values."

Kerne-regler:

• Poster adskilt af CRLF (vognretur + linjeskift)
• Felter adskilt af kommaer
• Felter, der indeholder kommaer, anførselstegn eller linjeskift, skal omgives af dobbelte anførselstegn
• Dobbelte anførselstegn inden i felter skal escapes ved at fordoble dem

Separator-variationer i praksis:

• Komma (,) – Standard, brugt i USA/UK
• Semikolon (;) – Brugt i lande, hvor komma er decimal-separator (Frankrig, Tyskland, Italien, Spanien, Brasilien)
• Tab (\t) – TSV-format, undgår separator-konflikter

Encoding-problemer:

• UTF-8 anbefales til interoperabilitet
• UTF-8 BOM (Byte Order Mark): Ikke påkrævet af standarden, men Excel på Windows kræver det for korrekt at vise ikke-ASCII-tegn (accenterede bogstaver, valutasymboler). Uden BOM kan Excel fortolke UTF-8 som Windows-1252, hvilket korrumperer tegn.
• Excel bruger semikoloner i stedet for kommaer som feltseparatorer i europæiske lokaliteter

Begrænsninger:

• Ingen datatyper – alt er tekst (tal med ledende nuller bliver korrumperet, lange kontonumre bliver til videnskabelig notation)
• Ingen understøttelse af flere ark
• Ingen formatering eller formler
• Ingen metadata (ingen kontooplysninger, ingen ID'er til duplikatdetektion)

Bedst til: Maksimal kompatibilitet – næsten alle regnskabsprogrammer, databaser og regneark kan importere CSV. Universel fallback, når QBO/OFX ikke er tilgængelig.

QBO (QuickBooks Web Connect)

Hvad det er: Importformatet for QuickBooks (både Desktop og Online). QBO-filer er baseret på OFX-specifikationen med QuickBooks-specifikke udvidelser.

Vigtig afklaring: ".QBO" betyder IKKE "QuickBooks Online" – det står for QuickBooks Web Connect-format og fungerer med både QuickBooks Desktop og QuickBooks Online.

Påkrævede felter pr. transaktion:

• TRNTYPE – Transaktionstype (DEBIT, CREDIT, CHECK, DEP, DIRECTDEP, DIRECTDEBIT, ATM, POS, XFER, PAYMENT, FEE, SRVCHG, INT, OTHER)
• DTPOSTED – Dato i YYYYMMDD format
• TRNAMT – Beløb (negativt for debet)
• FITID – Finansiel institutions transaktions-ID
• NAME – Betalingsmodtager/beskrivelse

Hvorfor FITID er vigtig: QuickBooks sporer alle FITID'er, der nogensinde er importeret for hver konto. Hvis en transaktion med samme FITID importeres igen, springer QuickBooks den stille og roligt over – hvilket forhindrer dubletter, når brugere genimporterer overlappende udtragsperioder. Denne automatiske duplikatdetektion er den største fordel ved QBO frem for CSV.

Yderligere data: QBO indeholder også konto-ID, bank-ID (routingnummer), valuta, checknummer, memo og slutsaldo – det rigeste datasæt af alle importformater for QuickBooks.

Bedst til: QuickBooks-brugere (Desktop og Online). Giver den rigeste importoplevelse med automatisk duplikatdetektion og klassificering af transaktionstyper.

OFX (Open Financial Exchange)

Historie: Oprettet af Microsoft, Intuit og CheckFree. Version 1.0 udgivet februar 1997.

Versionsudvikling:

• OFX 1.0–1.6 (1997–1999): SGML-baseret syntaks (ingen afsluttende tags påkrævet)
• OFX 2.0+ (2000–nu): XML-baseret (korrekte afsluttende tags, velformateret XML)

Mange banker producerer stadig OFX 1.x (SGML) for maksimal kompatibilitet.

Nuværende styring: I 2019 blev OFX-konsortiet fusioneret ind i Financial Data Exchange (FDX)-konsortiet, som nu administrerer specifikationen. FDX har over 200 medlemsorganisationer og 76 millioner forbrugerkonti.

Hvorfor OFX er den universelle standard: OFX er det samme format, der bruges, når du forbinder din bankkonto direkte til regnskabssoftware via bankfeeds – det samme format fungerer til filimport.

Bedst til Xero-brugere: Xero importerer automatisk OFX-filer uden behov for manuel kolonne-mapping. Upload filen, og transaktionerne vises med det samme med korrekte datoer, beløb og beskrivelser. Fungerer også med Wave, Sage, FreshBooks og de fleste regnskabsprogrammer.

QFX (Quicken Financial Exchange)

Hvad det er: Intuits proprietære variant af OFX, brugt udelukkende med Quicken. En QFX-fil er en standard OFX-fil med yderligere proprietære felter.

Vigtigt proprietært felt: INTU.BID – Quicken Bank Identifier. Dette numeriske ID mapper til en bank i Quickens interne database. Uden det nægter Quicken at importere filen.

Forskelle fra standard OFX:

• Kræver INTU.BID i headeren
• Kan indeholde andre felter med præfikset INTU.*
• Finansielle institutioner betaler Intuit et licensgebyr for at levere QFX-downloads
• Quicken importerer ikke standard OFX-filer uden INTU.BID-feltet

Bedst til: Quicken personlig finanssoftware-brugere. Nødvendigt format – ingen alternativ virker.

QIF (Quicken Interchange Format)

Hvad det er: Et ældre, almindeligt tekstformat, oprindeligt udviklet af Intuit til Quicken. Tag-værdi-par, ét pr. linje, med enkelt-tegns tags: D for dato, T for beløb, P for betalingsmodtager, L for kategori, M for memo, N for checknummer, ^ for slut-på-post.

Hvorfor det blev erstattet: QIF mangler en mekanisme til duplikatdetektion (ingen FITID-ækvivalent), har ingen kontoidentifikationsfelter, ingen bank-routinginformation, ingen saldodata og inkonsistent datoformatering på tværs af implementeringer.

Stadig relevant: Nogle regnskabsprogrammer (Xero, Sage, GnuCash) accepterer stadig QIF-import. Nyttigt til migrering af ældre systemer.

JSON (JavaScript Object Notation)

Nuværende status: JSON er endnu ikke en standard for kontoudtog-filer, men bruges i stigende grad i:

• Open Banking API'er (UK Open Banking Standard, PSD2 Berlin Group)
• FDX API (Financial Data Exchange – efterfølger til OFX, 200+ medlemsorganisationer)
• Plaid, Yodlee, MX og andre dataaggregator API'er
• Udvikler- og automatiserings-workflows

Voksende adoption: Open Banking-regulativer (PSD2 i Europa, CFPB Section 1033 i USA) accelererer JSON API-adoptionen. FDX API bruger JSON/REST med OAuth 2.0, hvilket repræsenterer fremtidens retning for udveksling af finansielle data.

Bedst til: Udviklere, der bygger automatiserede workflows, fintech-integrationer, brugerdefinerede dashboards og Open Banking API-integrationer.

Format Sammenligning i Oversigt

Kompatibilitet med Regnskabssoftware

Hvilket format accepterer dit regnskabsprogram?

Tommelfingerregel: Brug QBO til QuickBooks, QFX til Quicken, OFX til alt andet, og CSV som en universel fallback.

Internationale Formateringsforskelle

Hvis du arbejder med internationale kontoudtog, vil du støde på formateringsforskelle, der driller de fleste konverteringsværktøjer.

Datoformater

Problemet med tvetydighed: "15/03/2026" er 15. marts i USA, men 3. april i Europa. Når alle datoer i et udtog har dagsværdier på 12 eller derunder, er der ingen algoritmisk måde at bestemme det korrekte format på uden at kende oprindelseslandet. Konverteringsværktøjer skal scanne alle datoer i udtoget og lede efter værdier større end 12 for at bestemme formatet.

Talformater

"10.000,45" fra en europæisk bank betyder ti tusind og 45 cents – ikke ti punktum nul nul nul fire fem. At få dette forkert giver fejl på 10.000 gange størrelsen.

Placering af Valutasymbol

• USA/UK: Symbol før beløb: $1.234,56 / £1.234,56
• Frankrig, Tyskland, Spanien: Symbol efter beløb: 1.234,56 €
• Irland, Holland: Symbol før: €1.234,56
• Japan: Symbol før: ¥123.456

Tegnkodninger

• UTF-8 – Universel standard, understøtter alle skrifttyper
• GBK/GB2312 – Forenklet kinesisk (brugt af kinesiske banker)
• Shift_JIS – Japansk (brugt af japanske banker)
• Big5 – Traditionelt kinesisk (Taiwan, Hong Kong)
• EUC-KR – Koreansk
• ISO 8859-1 – Vesteuropæisk
• Windows-1252 – Vesteuropæisk (ældre)
• Windows-1256 – Arabisk

Åbning af et kinesisk eller japansk kontoudtog på et amerikansk system uden korrekt kodningsdetektion giver uforståelige tegn. PDFSub håndterer over 130 sprog med automatisk detektion af datoformater, talformater og tegnkodninger – inklusive højre-til-venstre arabisk og hebraisk, CJK-tegn og alle europæiske tegnsæt.

Almindelige Elementer i Kontoudtog

Transaktionsdato vs. Bogføringsdato vs. Værdi-dato

Kontoudtog kan indeholde flere datoer for en enkelt transaktion:

• Transaktionsdato – hvornår købet eller overførslen faktisk fandt sted
• Bogføringsdato – hvornår banken behandlede og registrerede den (typisk 1–3 hverdage senere for kreditkortkøb)
• Værdi-dato – hvornår midlerne faktisk blev tilgængelige (påvirker renteberegninger, almindeligt i international bankvirksomhed)

De fleste forbrugerkontoudtog viser kun bogføringsdatoen. Erhvervskontoudtog inkluderer ofte både transaktions- og bogføringsdatoer.

Repræsentation af Debet/Kredit

Banker repræsenterer debet og kredit forskelligt:

• Beløb med fortegn: -87,50 kr. for debet, +3.500,00 kr. for kredit
• Separate kolonner: "Hævninger" og "Indbetalinger"
• Forkortelser: "DR" for debet, "CR" for kredit (almindeligt i UK/Commonwealth)
• Parenteser: (87,50 kr.) for debet (regnskabskonvention)

Løbende Saldo

• Saldo pr. transaktion – opdateret efter hver transaktion (mest almindeligt i amerikanske forbrugerkontoudtog)
• Kun daglig saldo – saldo vist ved slutningen af hver dag (almindeligt i erhvervskontoudtog)
• Ingen løbende saldo – kun åbnings- og slutsaldi (nogle internationale kontoudtog)

Løbende saldi er værdifulde til validering: du kan verificere, at hver transaktion korrekt flytter saldoen fra én linje til den næste.

Standard Header Information

De fleste kontoudtog inkluderer: kontohavernavn, kontonummer (ofte delvist maskeret), udtragsperiode, åbnings- og slutsaldi, samlede indbetalinger og hævninger, samt bankens routing-/sortkode/SWIFT BIC.

Adgangskodebeskyttelse

Sådan Krypterer Banker PDF'er

Banker bruger typisk AES-128 eller AES-256 kryptering. To beskyttelsestilstande findes:

• Brugeradgangskode (åbningsadgangskode): Kræves for at åbne filen
• Ejeradgangskode (tilladelsesadgangskode): PDF'en åbnes, men redigering/kopiering kan være begrænset

Almindelige Adgangskodemønstre

Andre almindelige mønstre inkluderer de sidste 4 cifre af kontonummeret, kundenummer eller medlemsnummer. Banker kommunikerer typisk adgangskodemønsteret, når du først aktiverer elektroniske kontoudtog.

Udfordringer med Flersidede Kontoudtog

Lange kontoudtog (erhvervskonti med hundredvis af transaktioner) skaber flere udtrækningsudfordringer:

Opdelte Transaktioner

En transaktionsbeskrivelse kan starte nederst på én side og fortsætte øverst på den næste. Konverteren skal registrere fortsættelseslinjer og flette dem til en enkelt transaktion.

Gentagne Headers og Footers

De fleste banker gentager kolonneoverskrifter på hver side, plus sidenumre, juridiske ansvarsfraskrivelser og marketingtekst. Disse skal identificeres og udelades fra transaktionsdata.

Fortsættelseslinjer

Mange transaktioner har flertrinsbeskrivelser:

15/01  ACH ELEKTRONISK DEBET LEVERANDØR A/S 3.200,00 kr.  2.000,00 kr. REF#123456789 FAKTURA 2026-001 LEVERANDØR A/S BETALING AF FAKTURAER

Linje 2 og 3 er fortsættelseslinjer, der hører til transaktionen på linje 1. De mangler typisk en dato og et beløb og vises indrykket på samme x-koordinat som beskrivelseskolonnen.

Saldo Overførsel

Nogle banker inkluderer linjer som "Saldo Overført" eller "Saldo Medbragt" øverst på fortsættelsessider. Disse er informative, ikke transaktioner, og skal udelades fra de udtrukne data.

Almindelige Forkortelser i Kontoudtog

Kontoudtog bruger forkortelser, der varierer på tværs af institutioner:

Industristandarder Du Bør Kende

Disse formater bruges i erhvervsbankvirksomhed og treasury management. Du vil sjældent støde på dem direkte, men at forstå dem forklarer, hvorfor kontoudtog fungerer, som de gør.

BAI2 (Bank Administration Institute)

Bruges til automatiseret cash management og bankafstemning i ERP-systemer (SAP, Oracle). Et fast-bredde ASCII-format med transaktionstypekoder (f.eks. 165 = forhåndsgodkendt ACH-kredit, 455 = ACH-debet, 495 = bankoverførsel ud). Oprindeligt udgivet i 1987, nu vedligeholdt af ASC X9.

SWIFT MT940 / MT942

Slut-på-dagen (MT940) og intradag (MT942) kontoudtog brugt af banker verden over til erhvervskunder og treasury-afdelinger. SWIFT behandler ca. 45 millioner beskeder om dagen. Tag-baseret format med kolon-adskilte feltidentifikatorer.

ISO 20022 (camt.053)

Den moderne XML-baserede erstatning for MT940. Del af ISO 20022 universelle finansielle beskedstandard. Rigere data end MT940, ingen feltlængdegrænser, maskinlæsbar XML med XSD-validering. SWIFT migrerer fra MT-beskeder til ISO 20022. SEPA (Single Euro Payments Area) kræver camt-format for europæiske betalinger.

NACHA ACH

Filformatet for Automated Clearing House-transaktioner i USA. Fast-bredde ASCII, præcis 94 tegn pr. linje. ACH behandler ca. 30 milliarder transaktioner årligt i USA. Når dit kontoudtog viser "ACH CREDIT" eller "ACH DEBIT", blev den underliggende transaktion transmitteret i NACHA-format mellem banker.

Valg af det Rigtige Format til Din Arbejdsgang

Beslutningsguide

Brug QBO, hvis: Du bruger QuickBooks (Desktop eller Online). Du får klassificering af transaktionstyper, duplikatdetektion via FITID og den rigeste importmetadata.

Brug OFX, hvis: Du bruger Xero, Sage, Wave eller anden OFX-kompatibel software. Xero mapper automatisk felter uden manuel kolonnekonfiguration.

Brug QFX, hvis: Du bruger Quicken. Det er det eneste format, Quicken accepterer.

Brug Excel, hvis: Du har brug for at gennemgå, analysere eller manipulere data, før du importerer. Opret pivot-tabeller, kør formler eller forbered rapporter.

Brug CSV, hvis: Din software ikke er angivet ovenfor, eller du har brug for maksimal kompatibilitet på tværs af systemer. Vær forberedt på at mappe kolonner manuelt.

Brug JSON, hvis: Du bygger automatiserede workflows, API-integrationer eller brugerdefinerede rapporteringssystemer.

Pro Tips

• Brug altid QBO/OFX frem for CSV, når din software understøtter det – alene duplikatdetektionen forhindrer timers oprydning
• Behold den originale PDF sammen med din konverterede fil – det er din revisionsspor og kildedokument
• Verificer efter hver import – stikprøvekontrol af åbnings-/slutsaldi og et par tilfældige transaktioner
• Match format til software – brug af det native format til din regnskabsplatform undgår manuel kolonne-mapping og muliggør automatiske funktioner

Prøv Gratis

Klar til at konvertere dit første kontoudtog? Upload en PDF nu – PDFSub konverterer til Excel, CSV, QBO, OFX, QFX og JSON. Digitale kontoudtog behandles fuldstændigt i din browser for maksimal privatliv. Start en 7-dages gratis prøveperiode med fuld adgang til alle formater.