Så här hanterar du bankkontoutdrag i flera valutor
Internationella kunder innebär bankkontoutdrag i euro, pund, yen och rupier – med olika datumformat, decimalavgränsare och valutasymboler. Här är hur du hanterar dem alla.
Din kundlista sträcker sig över tre länder. En kund har bank i Tyskland, en annan i Japan och en tredje i Indien. Varje månad får du bankkontoutdrag i euro, yen och rupier – med datum skrivna på olika sätt, decimaler hanterade olika och belopp formaterade på sätt som skulle ställa till det för vilket verktyg som helst som är utformat för en enda region.
Välkommen till verkligheten av internationell bokföring. Bearbetning av bankkontoutdrag i flera valutor handlar inte bara om växelkurser. Det handlar om de grundläggande skillnaderna i hur länder formaterar siffror, datum och finansiella dokument. Om du gör fel här kommer din import till QuickBooks, Xero eller Zoho Books antingen att misslyckas helt eller – värre – tyst importera felaktiga data.
Den här guiden täcker utmaningarna med bankkontoutdrag i flera valutor och ger praktiska arbetsflöden för att hantera dem korrekt.

Sex länder, sex konventioner – en överblick
Innan vi går in på detaljerna, här är en jämförelse sida vid sida som visar hur samma utdrag med tre transaktioner ser ut i sex länder. Datumformat, decimalavgränsare, tusentalsavgränsare och valutasymbolens placering varierar alla oberoende av varandra – vilket är anledningen till att generiska "internationella" verktyg vanligtvis bara får två av de fyra rätt per region.

Vill du använda den här guiden på din blogg? Kopiera den här inbäddningskoden:
De tre lagren av internationell formatering
När du bearbetar bankkontoutdrag från olika länder hanterar du tre oberoende formateringssystem som varierar beroende på region.
Lager 1: Datumformat
Samma sex siffror – 03, 06 och 2026 – representerar helt olika datum beroende på var kontoutdraget utfärdades:
| Format | Konvention | Används i | Exempel |
|---|---|---|---|
| MM/DD/ÅÅÅÅ | Månad-Dag-År | USA, Filippinerna | 03/06/2026 = 6 mars |
| DD/MM/ÅÅÅÅ | Dag-Månad-År | Storbritannien, EU, Indien, Australien | 03/06/2026 = 3 juni |
| ÅÅÅÅ/MM/DD | År-Månad-Dag | Japan, Kina, Korea | 2026/03/06 = 6 mars |
| DD.MM.ÅÅÅÅ | Dag.Månad.År | Tyskland, Österrike, Schweiz | 03.06.2026 = 3 juni |
| DD-MM-ÅÅÅÅ | Dag-Månad-År | Indien (alternativ) | 03-06-2026 = 3 juni |
| ÅÅÅÅ-MM-DD | ISO 8601 | Internationell standard | 2026-03-06 = 6 mars |
Fällan ligger i de två första. När dagen är 12 eller mindre är 03/06/2026 tvetydigt – det kan vara 6 mars eller 3 juni. Om ditt konverteringsverktyg gissar fel är varje datum i kontoutdraget fel med månader. Detta orsakar inte ett fel – det orsakar tyst felaktiga data som du kanske inte upptäcker förrän vid avstämning (eller värre, vid deklarationen).
Lager 2: Sifferformat
Sättet som länder formaterar siffror på är en av de vanligaste källorna till konverteringsfel:
| Land/Region | Tusentalsavgränsare | Decimalavgränsare | Exempel (en miljon och 50 cent) |
|---|---|---|---|
| USA, Storbritannien, Australien | Komma | Punkt | 1,000,000.50 |
| Tyskland, Frankrike, Italien, Spanien | Punkt | Komma | 1.000.000,50 |
| Frankrike (alternativ) | Mellanslag | Komma | 1 000 000,50 |
| Indien | Komma (lakhs/crores) | Punkt | 10,00,000.50 |
| Schweiz | Apostrof | Punkt | 1'000'000.50 |
| Japan, Kina | Ingen (eller komma) | Ingen (ingen decimal, yen är hela enheter) | 1,000,000 |
Det indiska numreringssystemet förtjänar särskild uppmärksamhet. Indien använder lakh (1,00,000 = 100 000) och crore (1,00,00,000 = 10 000 000) grupperingar istället för den västerländska tusentalsgrupperingen. Ett tal som ser ut som 12,34,567.89 för en indisk revisor är 1,234,567.89 i västerländsk notation. Standardkonverteringsverktyg som antar tre-siffrig gruppering kommer att feltolka indiska siffror.
Lager 3: Valutasymboler och placering
| Valuta | Symbol | Placering | Exempel |
|---|---|---|---|
| US Dollar | $ | Före beloppet | $1,234.56 |
| Euro | EUR | Före eller efter | EUR1.234,56 eller 1.234,56 EUR |
| Brittiskt pund | GBP | Före beloppet | GBP1,234.56 |
| Japansk yen | JPY | Före beloppet | JPY1,234 |
| Indisk rupie | INR eller Rs | Före beloppet | INR12,34,567 |
| Saudiarabisk riyal | ر.س | Efter beloppet (RTL) | ١٢٣٤ ر.س |
| Brasiliansk real | R$ | Före beloppet | R$1.234,56 |
| Schweizisk franc | CHF | Före beloppet | CHF1'234.56 |
Vissa valutor använder inga decimaler alls (japansk yen, koreansk won). Andra använder tre decimaler (Bahrainsk dinar, Kuwaitisk dinar). Och höger-till-vänster-språk som arabiska lägger till ytterligare en dimension – själva kontoutdraget kan läsas från höger till vänster medan siffror läses från vänster till höger.
Varför standardverktyg misslyckas med flera valutor
De flesta verktyg för konvertering av bankkontoutdrag är byggda för en enda region – vanligtvis USA. De antar:
- Datum är MM/DD/ÅÅÅÅ
- Kommatecken separerar tusental, punkter separerar decimaler
- Valutasymboler placeras före beloppet
- Text läses från vänster till höger
När du matar dessa verktyg med ett tyskt bankkontoutdrag med datum formaterade som 15.03.2026 och belopp som 1.234,56 EUR, kraschar de, producerar skräpdata eller – i värsta fall – byter tyst kommatecken och punkter, vilket förvandlar 1.234,56 till 1,234.56 (korrekt) eller 1.234 (och tappar allt efter decimalen som faktiskt var ett kommatecken).
Hur PDFSub hanterar kontoutdrag i flera valutor
PDFSubs bankkontoutdragsomvandlare är byggd för internationell användning från grunden. Så här hanterar den varje lager av komplexitet:
Automatisk språk- och formatdetektering
PDFSub stöder över 130 språk och upptäcker automatiskt språket i ditt bankkontoutdrag. När den identifierar ett tyskspråkigt kontoutdrag tillämpar den automatiskt tyska formateringskonventioner. Ett japanskt kontoutdrag utlöser japanska konventioner. Ett indiskt kontoutdrag från SBI utlöser indisk siffergruppering.
Denna detektering sker på dokumentnivå, så du behöver inte manuellt konfigurera regionen för varje kontoutdrag.
Intelligent datumtolkning
När PDFSub stöter på ett tvetydigt datum använder den kontextuella ledtrådar från kontoutdraget för att lösa det:
- Datum i kontoutdragets sidhuvud – datum för kontoutdragsperioden är oftast entydiga (t.ex. "Kontoutdragsperiod: 1 januari – 31 januari 2026")
- Sekventiell logik – om transaktioner visas i kronologisk ordning och datum följer ett mönster, kan formatet härledas
- Bankmalligenkänning – PDFSub känner igen mallar från över 20 000 banker, varav många har kända konventioner för datumformat
Normalisering av sifferformat
Under extraheringen normaliserar PDFSub alla siffror till ett standardformat som är lämpligt för din måltillämpning:
- Tyska
1.234,56blir1234.56i CSV-utdata - Indiska
12,34,567.89blir1234567.89 - Franska
1 234 567,89blir1234567.89 - Schweiziska
1'234.56förblir1234.56
Målet för normaliseringen beror på ditt exportformat och din målinriktade redovisningsprogramvara. Om du importerar till en QuickBooks med amerikansk region formateras siffror med punkter som decimaler. Om du importerar till ett system med tysk region kan verktyget behålla formatet med kommatecken som decimaler.
Hantering av valutasymboler
PDFSub tar bort valutasymboler under extraheringen samtidigt som den bevarar valutainformationen i metadata. Detta förhindrar att symboler bryter siffertolkningen i din redovisningsprogramvara (som vanligtvis förväntar sig råa siffror).
Praktiskt arbetsflöde för bearbetning av flera valutor
Här är ett steg-för-steg-arbetsflöde för revisorer som hanterar kontoutdrag från flera länder.
Steg 1: Organisera kontoutdrag efter valuta
Skapa en mappstruktur:
Kundnamn/ USD/ checking_2026-01.pdf checking_2026-02.pdf EUR/ sparkasse_2026-01.pdf sparkasse_2026-02.pdf INR/ sbi_2026-01.pdf sbi_2026-02.pdfSteg 2: Konvertera varje kontoutdrag
Bearbeta varje kontoutdrag genom PDFSubs bankkontoutdragsomvandlare:
- Ladda upp PDF-filen
- PDFSub upptäcker automatiskt språk och format
- Granska extraherade transaktioner – verifiera datum och belopp mot originalet
- Exportera i ditt måformat (CSV, Excel, OFX, QBO, QIF)
Kritiskt granskningssteg: För varje konvertering, stickprovskontrollera minst 3-5 transaktioner:
- Jämför ett datum från original-PDF:en med den konverterade utdatan
- Jämför ett stort belopp (med tusentalsavgränsare) med den konverterade utdatan
- Jämför ett litet belopp (med decimaler) med den konverterade utdatan
- Verifiera att transaktionsantalet stämmer
Steg 3: Standardisera för din redovisningsprogramvara
Innan du importerar till din redovisningsprogramvara, säkerställ konsekvens:
- Alla datum i samma format – ÅÅÅÅ-MM-DD är säkrast för kompatibilitet mellan regioner
- Alla belopp i samma sifferformat – decimalpunkt, inga tusentalsavgränsare
- Valuta identifierad per konto – varje bankkonto i din programvara bör vara inställt på rätt valuta
- Konsekvent kolumnstruktur – Datum, Beskrivning, Belopp (eller Datum, Beskrivning, Debet, Kredit)
Steg 4: Importera och stäm av
Importera varje valutas transaktioner till motsvarande bankkonto i din redovisningsprogramvara. Viktiga punkter:
- Separata konton per valuta – blanda inte EUR- och USD-transaktioner i samma konto
- Hantering av växelkurser – ställ in växelkursen på transaktionsnivå eller använd din programvaras inbyggda kurstjänst
- Stäm av varje konto oberoende – matcha konverterade transaktioner mot banksaldon i originalvalutan
Överväganden kring växelkurser
Bearbetning av flera valutor innebär ofta valutakonvertering vid någon tidpunkt. Några viktiga principer:
Konvertera inte under extraheringen. Behåll transaktioner i sin originalvaluta under konverteringssteget för bankkontoutdrag. Konvertera växelkurser i din redovisningsprogramvara, där kurserna kan spåras, granskas och justeras.
Registrera originalbeloppet. Dina böcker ska alltid visa originalbeloppet i valuta tillsammans med eventuella konverterade belopp. Detta är avgörande för revisionsspår och för avstämning mot originalkontoutdrag.
Dags- vs. månadsräntor. För de flesta bokföringsändamål är dagliga växelkurser vid transaktionsdatumet mest exakta. Månatliga genomsnittskurser är acceptabla för skatteändamål i många jurisdiktioner men mindre precisa.
Din redovisningsprogramvara hanterar detta. QuickBooks, Xero, Zoho Books och de flesta moderna plattformar har inbyggda funktioner för flera valutor. Låt programvaran hantera valutakonvertering – försök inte göra det i filen för bankkontoutdraget.
Kontoutdrag på höger-till-vänster-språk
Bankkontoutdrag på arabiska, hebreiska, farsi och urdu presenterar ytterligare en utmaning: textriktning från höger till vänster (RTL). Kontoutdragets layout kan spegla vad du förväntar dig – kontoinformation till höger, belopp till vänster och text som läses från höger till vänster.
PDFSub hanterar RTL-kontoutdrag inbyggt. Extraheringsmotorn läser den underliggande textdatan (som har explicita riktningsmarkörer i PDF:en) istället för att försöka tolka den visuella layoutriktningen. Detta innebär att arabiska bankkontoutdrag extraheras med samma noggrannhet som engelska.
Om du arbetar med arabiska eller hebreiska kontoutdrag är arbetsflödet identiskt med alla andra språk – ladda upp, upptäck automatiskt, granska, exportera.
Vanliga misstag vid konvertering av flera valutor
Misstag 1: Anta MM/DD för alla datum
Ett datum som 03/06/2026 på ett brittiskt bankkontoutdrag är 3 juni, inte 6 mars. Om ditt verktyg antar amerikanskt format är varje datum i kontoutdraget fel. Verifiera alltid datumformatet genom att kontrollera mot kontoutdragsperiodens sidhuvud.
Misstag 2: Ignorera konventioner för tusentalsavgränsare
Ett tyskt belopp på 1.234 är ettusen tvåhundra trettiofyra, inte ett komma två tre fyra. Om ditt verktyg behandlar punkten som en decimalavgränsare har du precis dividerat beloppet med tusen.
Misstag 3: Konvertera valuta under extraheringen
Att konvertera EUR-belopp till USD under extraheringen av bankkontoutdraget bakar in en växelkurs i dina data som inte kan granskas eller justeras senare. Behåll originalvalutabeloppen; konvertera i din redovisningsprogramvara.
Misstag 4: Blanda valutor i en import
Att importera tyska EUR-transaktioner till ett USD-bankkonto i QuickBooks skapar felaktiga poster. Varje valuta behöver sitt eget bankkonto i din redovisningsprogramvara.
Misstag 5: Inte verifiera indisk siffergruppering
Indisk lakh- och crore-gruppering feltolkas ofta. 10,00,000 är 1 000 000 (tio lakh = en miljon) – inte 100,000 eller 1,000,000.0.
Vanliga frågor och svar
Hur upptäcker PDFSub språket i ett bankkontoutdrag?
PDFSub analyserar PDF:ens textinnehåll för att identifiera språket – genom att titta på vanliga banktermer, sidhuvudsmönster och teckenuppsättningar. Den känner igen över 130 språk och tillämpar motsvarande regionala konventioner för datum- och siffertolkning. För kontoutdrag från de över 20 000 bankerna i sin databas använder den också bankmalligenkänning för ytterligare noggrannhet.
Kan jag bearbeta bankkontoutdrag som blandar flera språk?
Ja. Vissa internationella banker utfärdar kontoutdrag med sidhuvuden på lokalt språk och transaktionsbeskrivningar på engelska. PDFSub hanterar blandade språk genom att upptäcka huvudspråket för formateringskonventioner (datum, siffror) samtidigt som den bevarar den ursprungliga texten i transaktionsbeskrivningar oavsett språk.
Vad händer med valutor utan decimaler (JPY, KRW)?
PDFSub känner igen valutor som inte använder decimaler och hanterar dem korrekt. Ett japanskt bankkontoutdrag som visar 15,000 extraheras som 15000 utan decimaldel. Detta förhindrar det vanliga felet där verktyg lägger till .00 till yen-belopp, vilket är tekniskt korrekt men kan orsaka formateringsproblem i viss redovisningsprogramvara.
Hur hanterar jag växelkurser vid import till QuickBooks eller Xero?
Både QuickBooks och Xero har inbyggda funktioner för flera valutor. Skapa bankkonton i varje valuta, importera transaktioner i deras originalvaluta och låt programvaran tillämpa växelkurser. QuickBooks använder dagliga kurser från sin integrerade tjänst. Xero tillåter manuell eller automatisk inmatning av kurser. Nyckeln är att importera beloppet i originalvalutan, inte ett förkonverterat belopp.
Vad händer om bankkontoutdragets PDF är på ett icke-latinskt skriftspråk (arabiska, kinesiska, japanska)?
PDFSub extraherar text från PDF:ens datalager, som innehåller den faktiska teckendatan oavsett skrift. Arabiska, kinesiska, japanska, koreanska, hindi och andra icke-latinska skriftspråk stöds alla. De extraherade transaktionerna bevarar originalskriften i beskrivningar samtidigt som datum och belopp normaliseras till ditt valda utdataformat.
Sammanfattning
Bearbetning av bankkontoutdrag i flera valutor handlar om mer än bara växelkurser. Det handlar om att hantera de grundläggande formateringsskillnaderna i hur länder skriver datum, siffror och valutabelopp. Att göra fel här leder till tysta datafel som ackumuleras över tid.
PDFSub eliminerar denna komplexitet genom att automatiskt upptäcka språk, datumformat och sifferkonventioner från över 20 000 banker på över 130 språk. Oavsett om din kund har bank i Frankfurt, Tokyo eller Mumbai är arbetsflödet detsamma: ladda upp PDF:en, granska extraheringen och exportera i det format din redovisningsprogramvara förväntar sig.
Bearbeta bankkontoutdrag i flera valutor – upptäck automatiskt språk och format för alla banker i världen.