Förstå format för bankkontoutdrag: Den tekniska guiden

Ett bankkontoutdrags-PDF ser enkelt ut: datum, beskrivningar, belopp, saldon i prydliga kolumner. Men bakom det utseendet ligger ett dokumentformat (PDF) som aldrig var avsett för att lagra strukturerad data – och en konverteringsprocess som kräver förståelse för både indataformatet och de många tillgängliga utdataformaten.

Den här guiden täcker de 12 avsnitten som finns på varje bankkontoutdrag (oavsett bank), den tekniska verkligheten av PDF-filer för bankkontoutdrag, layoutvariationerna mellan banker, alla utdataformat du kommer att stöta på (Excel, CSV, QBO, OFX, QFX, QIF, JSON), internationella formateringsskillnader och branschstandarderna som styr utbyte av finansiell data.

Anatomi av ett bankkontoutdrag

Varje bankkontoutdrag – Chase, Bank of America, Wells Fargo, HSBC, Deutsche Bank, du namn – är uppbyggt av samma 12 avsnitt. Etiketterna ändras ("Subtraktioner" vs "Uttag"), kolumnarrangemangen varierar, men den underliggande strukturen är konsekvent. När du väl kan identifiera dessa avsnitt ser varje utdrag bekant ut.

Vill du använda den här infografiken på din blogg? Kopiera den här inbäddningskoden:

För bankspecifika djupdykningar som exakt täcker hur varje stor bank lägger upp dessa 12 avsnitt, se:

• Chase bankkontoutdrag förklarat
• Bank of America bankkontoutdrag förklarat
• Wells Fargo bankkontoutdrag förklarat
• Citi bankkontoutdrag förklarat
• Capital One bankkontoutdrag förklarat

Varför PDF inte är ett dataformat

PDF står för Portable Document Format, standardiserat som ISO 32000 (version 2.0 blev ISO 32000-2:2020). Det designades för ett syfte: att få dokument att se identiska ut på varje skärm och skrivare. Det är utmärkt för visuell trohet – och fruktansvärt för dataextrahering.

Vad som faktiskt finns inuti ett bankkontoutdrags-PDF

Inuti varje PDF-sida finns en innehållsström – en sekvens av ritningsoperatorer skrivna i ett PostScript-liknande språk. Text renderas med specifika operatorer:

• BT / ET – Börja text / Sluta text: gränser för ett textobjekt
• Tf – Ange teckensnitt och storlek
• Td / Tm – Flytta textposition eller ställ in hela texttransformationsmatrisen
• Tj – Visa en textsträng
• TJ – Visa text med individuell glyfpositionering (justeringar av kerning)

Den avgörande insikten: det finns inget koncept av en "tabell", "rad" eller "kolumn" i PDF-specifikationen. Vad som ser ut som en prydligt formaterad transaktionstabell är faktiskt dussintals textfragment placerade på specifika x,y-koordinater på sidan. Extraheringsverktyget måste:

1. Parsa innehållsströmsoperatorerna
2. Lösa teckensnittskodningar för att mappa glyfindex till Unicode-tecken
3. Använda textmatrisen (Tm/Td) för att bestämma x,y-positionen för varje tecken
4. Återskapa ord, rader och kolumner från dessa koordinater

En kolumn som verkar perfekt anpassad kan vara på x=72.0 på en rad och x=72.5 på nästa. Extraheringsalgoritmen måste definiera kolumnbegränsningar med tolerans för dessa sub-pixelvariationer.

Tagged vs. Untagged PDF-filer

Tagged PDF-filer inkluderar ett dolt logiskt strukturträd (liknande HTML-taggar) som markerar innehåll som rubriker, stycken, tabeller, tabellrader och tabellceller. Detta gör extraheringen betydligt enklare.

Untagged PDF-filer har ingen strukturell metadata – extraheringsverktyget får bara rå positionsdata och måste härleda allt.

De flesta bankgenererade kontoutdrags-PDF:er är otaggade. Banker genererar utdrag med hjälp av batchbehandlingssystem (Oracle BI Publisher, SAP Crystal Reports eller anpassade print-to-PDF-pipelines). Tillgänglighetsregler (ADA/WCAG) driver banker mot taggade PDF:er, men adoptionen är långsam. Standardnedladdningar från de flesta stora banker förblir otaggade.

Layoutvariationer för bankkontoutdrag

Det finns ingen industristandard för hur banker formaterar sina PDF-kontoutdrag. Samma fem informationsbitar – datum, beskrivning, debet, kredit, saldo – arrangeras olika av varje bank.

Enkel beloppkolumn (med tecken)

Datum Beskrivning Belopp Saldo
15/01/26 DIREKT INSÄTTNING LÖN +3 500,00 5 200,00
16/01/26 POS KÖP LIVSMEDEL -87,50 5 112,50

Debet är negativt, kredit är positivt (eller vice versa). Vanligt hos mindre banker, kreditföreningar och digitala banker. Enklare att parsa eftersom det bara finns en beloppkolumn att extrahera.

Separata debet-/kreditkolumner

Datum Beskrivning Uttag Insättningar Saldo
15/01/26 DIREKT INSÄTTNING LÖN 3 500,00 5 200,00
16/01/26 POS KÖP LIVSMEDEL 87,50 5 112,50

Används av Chase, Bank of America och många traditionella banker. Extraheringsverktyget måste identifiera vilken kolumn som innehåller beloppet och bestämma tecknet därefter.

Grupperat efter transaktionstyp

Företags- och kommersiella konton grupperar ofta transaktioner:

INSÄTTNINGAR OCH ANDRA KREDITER 15/01  Banköverföring In REF#12345 10 000,00 18/01  Checkinsättning #4567 2 500,00 Total Insättningar 12 500,00
 
CHECKAR BETALDA 16/01  Check #1234 850,00 17/01  Check #1235 1 200,00 Total Checkar Betalda 2 050,00
 
ELEKTRONISKA TRANSAKTIONER 19/01  ACH BETALNING - Leverantör AB 3 200,00 20/01  Onlineöverföring till Sparkonto 1 000,00 Total Elektroniska 4 200,00

Avsnittsrubrikerna avgör om transaktioner är debet eller kredit. Sammanfattningsrader ("Total Insättningar") måste identifieras och exkluderas från transaktionsdata.

Bankspecifika egenskaper

• Chase – Separata debet-/kreditkolumner; grupperar efter "INSÄTTNINGAR OCH TILLÄGG" och "ELEKTRONISKA BETALNINGAR" och "AVGIFT"; flerradiga beskrivningar vanliga för handlardetaljer
• Bank of America – Separata uttags-/insättningskolumner; inkluderar ett avsnitt "Dagligt saldo" i slutet; omfattande rubrik med kontonummer, kontoutdragsperiod, clearingnummer
• Wells Fargo – Separata kolumner; inkluderar avsnittet "DAGLIG SALDOSAMMANFATTNING"; kallar sin CSV-nedladdning "Comma Delimited"
• Capital One – Ren layout med ett belopp för konsumentkort; minimal rubriktext
• Citi – Inkluderar ofta detaljer om internationella transaktioner med ursprungliga valutabelopp och växlingskurser på separata rader

Variationer i kolumnarrangemang

Utöver frågan om debet/kredit är kolumnordningen inte standardiserad:

• Kolumnordning: Datum-Beskrivning-Belopp-Saldo vs. Datum-Belopp-Beskrivning-Saldo
• Checknummer: Finns på företagskonton, saknas på personliga
• Referensnummer: Vanligt på företagsutdrag, sällsynt på personliga
• Löpande saldo: Per transaktion (vanligast) vs. dagliga delsummor vs. helt saknas

Digitala vs. Skannade PDF-filer

Den absolut viktigaste faktorn som påverkar konverteringsnoggrannheten är om din PDF är digital eller skannad.

Digitala (ursprungliga) PDF-filer

Skapas programmatiskt av din banks system när du laddar ner ett utdrag. Text lagras som innehållsströmsoperatorer med teckensnittskodningar.

• Noggrannhet: 99 %+ för textextrahering – inga igenkänningsfel
• Hastighet: Millisekunder per sida
• Integritet: Kan bearbetas helt i din webbläsare – filen lämnar aldrig din enhet
• Filstorlek: Vanligtvis 50 KB–500 KB per sida
• Hur man identifierar: Du kan markera och välja enskilda ord

Skannade PDF-filer

Bilder av pappersutdrag – skapade genom att skanna eller fotografera ett fysiskt dokument. Innehåll lagras som rasteriserade bilder (JPEG, JPEG2000, CCITT eller Flate-komprimerade).

• Noggrannhet: 95–99 % med professionell OCR; 65–70 % med generell OCR
• Hastighet: Sekunder per sida (kräver bildbehandling)
• Integritet: Kräver vanligtvis serverbaserad bearbetning (filen måste laddas upp för OCR)
• Filstorlek: 200 KB–2 MB+ per sida
• Hur man identifierar: Du kan inte markera någon text; zoomar du till 400 % ser du pixlar

Varför noggrannhet vid skanning är viktigare för finansiella data

En teckennoggrannhet på 97 % låter utmärkt tills du tillämpar den på finansiella data. På ett utdrag med 1 000 tecken av belopp blir det 30 felaktigt lästa tecken. En enda felaktigt läst siffra ändrar ett transaktionsbelopp: "1 234,56 kr" blir "1 234,86 kr" eller "7 234,56 kr". Avancerad OCR uppnår nära 99 % noggrannhet, men de återstående felen hamnar oproportionerligt på tecken som ser lika ut: 0/O, 1/l/I, 5/S, 8/B, 6/G, och kritiskt, komma/punkt.

Föredra alltid digitala nedladdningar. Ladda ner utdrag från din banks webbplats istället för att skanna papper. Detta eliminerar OCR-fel helt.

Utdataformat: Djupdykning

När du konverterar ett bankkontoutdrag väljer du ett utdataformat. Varje format har olika styrkor, begränsningar och idealiska användningsfall.

Excel (.xlsx)

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

Vad det är: En .xlsx-fil är faktiskt ett ZIP-arkiv som innehåller XML-filer – arbetsboksstruktur, cell data, stilar och delade strängar. Det är därför den kan lagra datatyper (datum som datum, siffror som siffror), formatering, formler och flera blad.

Varför det är populärt för bankkontoutdrag:

• Datum förblir datum (sorterbara, filtrerbara)
• Siffror förblir siffror (summerbara, formaterbara)
• Formler för avstämning (SUM, VLOOKUP)
• Pivottabeller för utgiftskategorisering
• Villkorlig formatering för att markera avvikelser
• Dela med kunder som behöver ett läsbart kalkylblad

Begränsningar:

• Maximalt 1 048 576 rader (sällan relevant för bankkontoutdrag)
• Kan inte importeras direkt till de flesta redovisningsprogram (använd QBO/OFX istället)
• Kräver Excel, Google Sheets eller LibreOffice Calc för att öppna

Bäst för: Manuell granskning, anpassad analys, avstämning, arkivering, kundrapportering.

CSV (Comma-Separated Values)

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

Grundregler:

• Poster avgränsade med CRLF (vagnretur + radmatning)
• Fält separerade av kommatecken
• Fält som innehåller kommatecken, citattecken eller radbrytningar måste omges av dubbla citattecken
• Dubbla citattecken inom fält escapas genom att dubblera dem

Avgränsningsvariationer i praktiken:

• Komma (,) – Standard, används i USA/Storbritannien
• Semikolon (;) – Används i länder där kommatecken är decimalavgränsare (Frankrike, Tyskland, Italien, Spanien, Brasilien)
• Tab (\t) – TSV-format, undviker avgränsningskonflikter

Kodningsproblem:

• UTF-8 rekommenderas för interoperabilitet
• UTF-8 BOM (Byte Order Mark): Krävs inte av standarden, men Excel på Windows kräver det för att korrekt visa icke-ASCII-tecken (accentuerade bokstäver, valutasymboler). Utan BOM kan Excel tolka UTF-8 som Windows-1252, vilket skadar tecken.
• Excel använder semikolon istället för kommatecken som fältavgränsare i europeiska lokaler

Begränsningar:

• Inga datatyper – allt är text (siffror med ledande nollor skadas, långa kontonummer blir vetenskaplig notation)
• Inget stöd för flera blad
• Ingen formatering eller formler
• Ingen metadata (ingen kontoinformation, inga ID:n för dubblettdetektering)

Bäst för: Maximal kompatibilitet – nästan alla redovisningsprogram, databaser och kalkylprogram kan importera CSV. Universellt reservalternativ när QBO/OFX inte är tillgängligt.

QBO (QuickBooks Web Connect)

Vad det är: Importformatet för QuickBooks (både Desktop och Online). QBO-filer baseras på OFX-specifikationen med QuickBooks-specifika tillägg.

Viktig förtydligande: ".QBO" betyder INTE "QuickBooks Online" – det står för QuickBooks Web Connect-format och fungerar med både QuickBooks Desktop och QuickBooks Online.

Obligatoriska fält per transaktion:

• TRNTYPE – Transaktionstyp (DEBIT, CREDIT, CHECK, DEP, DIRECTDEP, DIRECTDEBIT, ATM, POS, XFER, PAYMENT, FEE, SRVCHG, INT, OTHER)
• DTPOSTED – Datum i formatet YYYYMMDD
• TRNAMT – Belopp (negativt för debet)
• FITID – Finansiell institutions transaktions-ID
• NAME – Betalningsmottagare/beskrivning

Varför FITID är viktigt: QuickBooks spårar varje FITID som någonsin importerats för varje konto. Om en transaktion med samma FITID importeras igen, hoppar QuickBooks tyst över den – vilket förhindrar dubbletter när användare återimporterar överlappande utdragsperioder. Denna automatiska dubblettdetektering är den enskilt största fördelen med QBO jämfört med CSV.

Ytterligare data: QBO bär också med sig konto-ID, bank-ID (clearingnummer), valuta, checknummer, memo och slutligt saldo – den rikaste datamängden av alla importformat för QuickBooks.

Bäst för: QuickBooks-användare (Desktop och Online). Ger den rikaste importupplevelsen med automatisk dubblettdetektering och klassificering av transaktionstyp.

OFX (Open Financial Exchange)

Historia: Skapad av Microsoft, Intuit och CheckFree. Version 1.0 släpptes i februari 1997.

Versionsutveckling:

• OFX 1.0–1.6 (1997–1999): SGML-baserad syntax (inga avslutande taggar krävs)
• OFX 2.0+ (2000–nutid): XML-baserad (korrekta avslutande taggar, välformaterad XML)

Många banker producerar fortfarande OFX 1.x (SGML) för maximal kompatibilitet.

Nuvarande styrning: År 2019 slogs OFX-konsortiet samman med Financial Data Exchange (FDX)-konsortiet, som nu hanterar specifikationen. FDX har över 200 medlemsorganisationer och 76 miljoner konsumentkonton.

Varför OFX är den universella standarden: OFX är samma format som används när du ansluter ditt bankkonto direkt till redovisningsprogram via bankflöden – samma format fungerar för filimporter.

Bäst för Xero-användare: Xero importerar OFX-filer automatiskt utan att kräva manuell kolumnmappning. Ladda upp filen och transaktionerna visas omedelbart med korrekta datum, belopp och beskrivningar. Fungerar även med Wave, Sage, FreshBooks och de flesta redovisningsprogram.

QFX (Quicken Financial Exchange)

Vad det är: Intuits proprietära variant av OFX, som endast används med Quicken. En QFX-fil är en standard OFX-fil med ytterligare proprietära fält.

Viktigt proprietärt fält: INTU.BID – Quicken Bank Identifier. Detta numeriska ID mappar till en bank i Quickens interna databas. Utan det vägrar Quicken att importera filen.

Skillnader från standard OFX:

• Kräver INTU.BID i rubriken
• Kan inkludera andra fält med prefixet INTU.*
• Finansiella institutioner betalar en licensavgift till Intuit för att tillhandahålla QFX-nedladdning
• Quicken importerar inte standard OFX-filer utan INTU.BID-fältet

Bäst för: Quicken personliga finansprogramvaruanvändare. Obligatoriskt format – inget alternativ fungerar.

QIF (Quicken Interchange Format)

Vad det är: Ett föråldrat ren textformat som ursprungligen utvecklades av Intuit för Quicken. Tag-värdepar, ett per rad, med enskilda tecken som taggar: D för datum, T för belopp, P för betalningsmottagare, L för kategori, M för memo, N för checknummer, ^ för slut på post.

Varför det ersattes: QIF saknar en mekanism för dubblettdetektering (ingen FITID-motsvarighet), har inga fält för kontoidentifiering, ingen bankroutinginformation, inga saldon och inkonsekvent datumformatering mellan implementationer.

Fortfarande relevant: Viss redovisningsprogramvara (Xero, Sage, GnuCash) accepterar fortfarande QIF-importer. Användbart för migrering från äldre system.

JSON (JavaScript Object Notation)

Nuvarande status: JSON är ännu inte en standard för bankkontoutdragsfiler, men används i ökande grad i:

• Open Banking API:er (UK Open Banking Standard, PSD2 Berlin Group)
• FDX API (Financial Data Exchange – efterföljare till OFX, 200+ medlemsorganisationer)
• Plaid, Yodlee, MX och andra dataaggregator-API:er
• Utvecklar- och automatiseringsflöden

Ökad adoption: Open Banking-regleringar (PSD2 i Europa, Section 1033 i USA) påskyndar adoptionen av JSON API:er. FDX API använder JSON/REST med OAuth 2.0, vilket representerar framtida riktning för utbyte av finansiell data.

Bäst för: Utvecklare som bygger automatiserade arbetsflöden, fintech-integrationer, anpassade instrumentpaneler och Open Banking API-integrationer.

Formatjämförelse i korthet

Kompatibilitet med redovisningsprogram

Vilket format accepterar din redovisningsprogramvara?

Tumregel: Använd QBO för QuickBooks, QFX för Quicken, OFX för allt annat och CSV som ett universellt reservalternativ.

Internationella formatsskillnader

Om du arbetar med internationella bankkontoutdrag kommer du att stöta på formateringsskillnader som ställer till det för de flesta konverteringsverktyg.

Datumformat

Problemet med tvetydighet: "03/04/2026" är 3 april i USA men 4 mars i Europa. När alla datum i ett utdrag har dagsvärden på 12 eller mindre, finns det inget algoritmiskt sätt att bestämma rätt format utan att känna till ursprungslandet. Konverteringsverktyg måste skanna alla datum i utdraget och leta efter värden större än 12 för att bestämma formatet.

Talformat

"10.000,45" från en europeisk bank betyder tio tusen och fyrtiofem cent – inte tio punkt noll noll noll fyra fem. Att göra fel här ger fel på 10 000 gånger storleksordningen.

Placering av valutasymbol

• USA/Storbritannien: Symbol före belopp: $1 234,56 / £1 234,56
• Frankrike, Tyskland, Spanien: Symbol efter belopp: 1 234,56 €
• Irland, Nederländerna: Symbol före: €1 234,56
• Japan: Symbol före: ¥123 456

Teckenkodningar

• UTF-8 – Universell standard, stöder alla skriftspråk
• GBK/GB2312 – Förenklad kinesiska (används av kinesiska banker)
• Shift_JIS – Japanska (används av japanska banker)
• Big5 – Traditionell kinesiska (Taiwan, Hongkong)
• EUC-KR – Koreanska
• ISO 8859-1 – Västeuropeiska
• Windows-1252 – Västeuropeiska (äldre)
• Windows-1256 – Arabiska

Att öppna ett kinesiskt eller japanskt bankkontoutdrag på ett amerikanskt system utan korrekt kodningsdetektering ger förvrängda tecken. PDFSub hanterar över 130 språk med automatisk detektering av datumformat, talformat och teckenkodningar – inklusive höger-till-vänster arabiska och hebreiska, CJK-tecken och alla europeiska teckenuppsättningar.

Vanliga element i bankkontoutdrag

Transaktionsdatum vs. Bokföringsdatum vs. Värdedatum

Bankkontoutdrag kan inkludera flera datum för en enda transaktion:

• Transaktionsdatum – När köpet eller överföringen faktiskt skedde
• Bokföringsdatum – När banken behandlade och registrerade det (vanligtvis 1–3 arbetsdagar senare för kreditkortsköp)
• Värdedatum – När medel faktiskt blev tillgängliga (påverkar ränteberäkningar, vanligt i internationell bankverksamhet)

De flesta konsumentutdrag visar bara bokföringsdatumet. Företagsutdrag inkluderar ofta både transaktions- och bokföringsdatum.

Representation av debet/kredit

Banker representerar debet och kredit på olika sätt:

• Belopp med tecken: -87,50 för debet, +3 500,00 för kredit
• Separata kolumner: "Uttag" och "Insättningar"
• Förkortningar: "DR" för debet, "CR" för kredit (vanligt i Storbritannien/Commonwealth)
• Parenteser: (87,50) för debet (bokföringsstandard)

Löpande saldo

• Saldo per transaktion – Uppdateras efter varje transaktion (vanligast i amerikanska konsumentutdrag)
• Endast dagligt saldo – Saldo visas i slutet av varje dag (vanligt i företagsutdrag)
• Inget löpande saldo – Endast öppnings- och slutgiltiga saldon (vissa internationella utdrag)

Löpande saldon är värdefulla för validering: du kan verifiera att varje transaktion korrekt flyttar saldot från en rad till nästa.

Standard rubriktext

De flesta bankkontoutdrag inkluderar: kontoinnehavarens namn, kontonummer (ofta delvis maskerat), utdragsperiod, öppnings- och slutgiltiga saldon, totala insättningar och uttag, samt bankens clearingnummer/sort code/SWIFT BIC.

Lösenordsskydd

Hur banker krypterar PDF-filer

Banker använder vanligtvis AES-128 eller AES-256 kryptering. Två skyddslägen finns:

• Användarlösenord (öppningslösenord): Krävs för att öppna filen
• Ägarlösenord (behörighetslösenord): PDF öppnas men redigering/kopiering kan vara begränsad

Vanliga lösenordsmönster

Andra vanliga mönster inkluderar de sista 4 siffrorna i kontonumret, kund-ID eller medlemsnummer. Banker kommunicerar vanligtvis lösenordsmönstret när du först aktiverar elektroniska utdrag.

Utmaningar med flersidiga utdrag

Långa utdrag (företagskonton med hundratals transaktioner) skapar flera extraheringsutmaningar:

Delade transaktioner

En transaktionsbeskrivning kan börja längst ner på en sida och fortsätta högst upp på nästa. Konverteraren måste upptäcka fortsättningsrader och slå ihop dem till en enda transaktion.

Upprepade rubriker och sidfötter

De flesta banker upprepar kolumnrubriker på varje sida, plus sidnummer, juridiska friskrivningar och marknadsföringstext. Dessa måste identifieras och exkluderas från transaktionsdata.

Fortsättningsrader

Många transaktioner har flerradiga beskrivningar:

15/01  ACH ELEKTRONISK DEBET LEVERANTÖR AB 3 200,00 kr  2 000,00 kr REF#123456789 FAKTURA 2026-001 LEVERANTÖR AB LEVERANTÖRSBETALNINGAR

Rad 2 och 3 är fortsättningsrader som tillhör transaktionen på rad 1. De saknar vanligtvis datum och belopp, och visas indragna på samma x-koordinat som beskrivningskolumnen.

Saldotillförsel

Vissa banker inkluderar rader som "Saldo framåt" eller "Saldo medfört framåt" högst upp på fortsättningssidor. Dessa är endast informativa, inte transaktioner, och måste exkluderas från extraherad data.

Vanliga förkortningar i bankkontoutdrag

Bankkontoutdrag använder förkortningar som varierar mellan institutioner:

Branschstandarder du bör känna till

Dessa format används i företagsbankverksamhet och kassahantering. Du kommer sällan att stöta på dem direkt, men att förstå dem förklarar varför bankkontoutdrag fungerar som de gör.

BAI2 (Bank Administration Institute)

Används för automatiserad kassahantering och bankavstämning i ERP-system (SAP, Oracle). Ett ASCII-format med fast bredd med transaktionstypskoder (t.ex. 165 = förhandsgodkänd ACH-kredit, 455 = ACH-debet, 495 = banköverföring ut). Ursprungligen släppt 1987, nu underhållen av ASC X9.

SWIFT MT940 / MT942

Slut-på-dagen (MT940) och intradag (MT942) bankkontoutdrag som används av banker världen över för företagskunder och kassadepartement. SWIFT behandlar cirka 45 miljoner meddelanden per dag. Tag-baserat format med kolondelimiterade fältidentifierare.

ISO 20022 (camt.053)

Den moderna XML-baserade ersättningen för MT940. Del av ISO 20022 universella standard för finansiella meddelanden. Rikare data än MT940, inga gränser för fältlängd, maskinläsbar XML med XSD-validering. SWIFT migrerar från MT-meddelanden till ISO 20022. SEPA (Single Euro Payments Area) kräver camt-format för europeiska betalningar.

NACHA ACH

Fformatet för Automated Clearing House-transaktioner i USA. Fast bredd ASCII, exakt 94 tecken per rad. ACH behandlar cirka 30 miljarder transaktioner per år i USA. När ditt bankkontoutdrag visar "ACH CREDIT" eller "ACH DEBIT", överfördes den underliggande transaktionen i NACHA-format mellan banker.

Välja rätt format för din arbetsflöde

Beslutsguide

Använd QBO om: Du använder QuickBooks (Desktop eller Online). Du får klassificering av transaktionstyp, dubblettdetektering via FITID och den rikaste importmetadatan.

Använd OFX om: Du använder Xero, Sage, Wave eller annan OFX-kompatibel programvara. Xero mappar automatiskt fält utan manuell kolumnkonfiguration.

Använd QFX om: Du använder Quicken. Det är det enda formatet Quicken accepterar.

Använd Excel om: Du behöver granska, analysera eller manipulera data innan import. Skapa pivottabeller, kör formler eller förbered rapporter.

Använd CSV om: Din programvara inte finns med ovan, eller om du behöver maximal kompatibilitet mellan system. Var beredd på att mappa kolumner manuellt.

Använd JSON om: Du bygger automatiserade arbetsflöden, API-integrationer eller anpassade rapporteringssystem.

Proffstips

• Använd alltid QBO/OFX framför CSV när din programvara stöder det – enbart dubblettdetekteringen förhindrar timmar av städning
• Behåll den ursprungliga PDF-filen tillsammans med din konverterade fil – det är din revisionskedja och källdokument
• Verifiera efter varje import – stickprovskolla öppnings- och slutgiltiga saldon och några slumpmässiga transaktioner
• Matcha format till programvara – att använda det ursprungliga formatet för din redovisningsplattform undviker manuell kolumnmappning och möjliggör automatiska funktioner

Prova gratis

Redo att konvertera ditt första utdrag? Ladda upp en PDF nu – PDFSub konverterar till Excel, CSV, QBO, OFX, QFX och JSON. Digitala utdrag bearbetas helt i din webbläsare för maximal integritet. Starta en 7-dagars gratis provperiod med full tillgång till alla format.