Konverter japanske kontoutskrifter til Excel (MUFG, SMBC, Mizuho og mer)
Japanske kontoutskrifter kombinerer kanji-beskrivelser, Shift_JIS-koding, halvbredde katakana og japanske æradatoer som feiler i ikke-japansk Excel. Slik konverterer du dem korrekt.
Din 取引明細 (transaksjonsutskrift) fra MUFG ser perfekt strukturert ut i PDF-en. Men åpne den i Excel utenfor Japan, og problemene hoper seg opp: kanji-tegn blir til uleselig mojibake (文字化け), Reiwa-æraens dato "令和8年3月2日" betyr ingenting for regnearket ditt på engelsk, avsendernavn i halvbredde katakana som "ヤマダ タロウ" blir uleselige symboler, og fullbredde tall "123,456" vil ikke beregne fordi de er andre Unicode-tegn enn sine halvbredde-ekvivalenter.
Hovedproblemet er: Japansk bankdrift baseres på tegnkoding og formateringskonvensjoner som forutsetter et japansk-lokalisert system. Zengin interbank-betalingsnettverket – som behandler omtrent 6,5 millioner transaksjoner og 12 billioner yen daglig – krevde historisk halvbredde katakana for alle navn, en arv som fortsatt vises på moderne kontoutskrifter. Når du flytter disse dataene til en ikke-japansk datamaskin, er kodingsfeil nesten garantert.
Enten du er en utenlandsk bosatt i Tokyo som behandler MUFG-utskrifter for skatterapportering til hjemlandet, en zeirishi (skatterevisor) som importerer klientdata til freee eller Money Forward, en internasjonal bedrift som konsoliderer data fra et japansk datterselskap, eller en frilanser som administrerer Blue Return (青色申告) bokføring – kjerneproblemet er identisk: å trekke ut strukturerte, regnearkklare data fra japanske kontoutskrifts-PDF-er.
Denne guiden dekker de spesifikke formateringsutfordringene med japanske utskrifter, de store bankene du vil møte, og hvordan du konverterer dem nøyaktig.

Hvorfor japanske kontoutskrifter feiler i Excel
Japanske kontoutskrifter skaper et unikt sett med utfordringer som går utover enkel tallformatering. Problemene spenner over tegnkoding, nummersystemer, datokonvensjoner og eldre interbankformater.
1. Shift_JIS vs. UTF-8-koding (Mojibake)
Dette er det aller største problemet for alle som behandler japanske finansdata utenfor Japan.
De fleste japanske banker eksporterer CSV-filer i Shift_JIS (kode side 932) – en kodestandard som er eldre enn UTF-8 og kun dekker japanske tegn. Når du åpner en Shift_JIS-fil på et system som forventer UTF-8, blir hvert japanske tegn uleselig. Japanerne har et ord for dette: 文字化け (mojibake), bokstavelig talt "tegn-transformasjon."
| Hva du burde se | Hva UTF-8 viser |
|---|---|
| 振込 カ)ヤマダ タロウ | 振込 カ)ヤマダ |
| 三菱UFJ銀行 | 三è±UFJ銀行 |
| 口座振替 電気代 | å£åº§æŒ¯æ›¿ é›»æ° - 代 |
Det motsatte er også sant: UTF-8-filer åpnet i japansk-lokalisert Excel kan gi et annet uleselig resultat.
Problemet forsterkes av at Shift_JIS-filer har ingen Byte Order Mark (BOM) – det er ingen header som forteller programvaren hvilken koding som skal brukes. Automatisk deteksjon er upålitelig, spesielt når filen inneholder en blanding av japanske tegn og latinsk tekst (som alle kontoutskrifter gjør).
2. Fullbredde vs. Halvbredde tegn (全角 vs. 半角)
Dette er unikt japansk og overrasker nesten alle ikke-japanske utviklere.
Japansk databehandling bruker to bredder for mange tegn. Fullbredde tegn (全角) opptar plassen til to latinske tegn; halvbredde tegn (半角) opptar én.
| Fullbredde (全角) | Halvbredde (半角) | Samme tegn? |
|---|---|---|
| 123,456 | 123,456 | Samme tall, forskjellige bytes |
| カード | カード | Samme ord ("kort"), forskjellig koding |
| ,(コンマ) | , (komma) | Samme skilletegn, forskjellige bytes |
| (スペース) | (mellomrom) | Samme mellomrom, forskjellige bytes |
En celle som inneholder "123,456" (fullbredde) ser identisk ut med "123,456" på skjermen, men Excel behandler fullbredde-versjonen som tekst, ikke et tall. Du kan ikke summere den, sortere den eller bruke den i formler. Standard søk-og-erstatt for komma vil heller ikke matche fullbredde-komma.
Kontoutskrifter kan blande bredder: beløp kan være halvbredde mens beskrivelser bruker fullbredde tegn. Konvertereren må normalisere alt til konsistent halvbredde for beregninger.
3. Halvbredde Katakana fra Zengin-systemet
Zengin interbank-betalingssystemet – Japans innenlandske betalingsryggrad – krevde historisk at alle navn ble overført i halvbredde katakana (半角カナ) innenfor en grense på 20 tegn.
Dette skaper et spesifikt problem: på kontoutskriften din vises avsenderens navn for en overføring som noe slikt som ヤマダ タロウ i stedet for 山田 太郎 (Yamada Taro). Selv innfødte japanske lesere finner halvbredde katakana vanskeligere å lese.
Verre: i halvbredde katakana er stemte konsonantmerker (dakuten) separate tegn. Tegnet ガ (ga) i fullbredde er ett tegn, men i halvbredde blir det to: ガ (ka + stemt merke). Dette dobler den tilsynelatende lengden på navn som inneholder stemte lyder og bryter enhver tekstbehandling som teller tegnposisjoner.
4. Japanske Æradatoer (和暦)
Japan bruker sin egen æra-baserte kalender ved siden av den gregorianske kalenderen. Den nåværende æraen er Reiwa (令和), som begynte 1. mai 2019.
| Japansk Æradato | Gregoriansk Ekvivalent |
|---|---|
| 令和8年3月2日 | 2. mars 2026 |
| R8.03.02 | 2. mars 2026 |
| 令和7年12月15日 | 15. desember 2025 |
Engelsk Excel har ingen kjennskap til japanske æraer. Den kan ikke tolke "令和8年" som 2026. Selv det forkortede formatet "R8.03.02" er uforståelig.
De gode nyhetene: Japan bruker År-Måned-Dag-rekkefølge (størst til minst), som er ISO 8601-kompatibel. Når utskrifter bruker vestlige datoer, vises de som 2026/03/02 – mindre tvetydig enn det europeiske DD/MM/ÅÅÅÅ-formatet. Utfordringen er utelukkende når æradatoer brukes.
Æra-grenseproblem: Historiske utskrifter fra 2019 kan spenne over overgangen fra Heisei til Reiwa (Heisei sluttet 30. april 2019). Samme år, 2019, er både Heisei 31 og Reiwa 1. En konverterer må håndtere begge æraene korrekt.
5. Heltallig Valuta (Ingen Desimaler)
Yen har ingen underenhet – det er ingen cent. Alle beløp på japanske kontoutskrifter er heltall: ¥1,234,567 betyr nøyaktig 1 234 567 yen.
Dette forenkler faktisk én aspekt av konverteringen (ingen desimalhåndtering nødvendig), men introduserer andre:
- Store tall er normale. En typisk lønn er ¥300 000–500 000 per måned. Leie kan være ¥80 000–200 000. Tallene når ofte seks eller syv sifre.
- 10 000-enheters tenkning. Japanere tenker i enheter av 万 (man, 10 000). En lønn på ¥3 000 000 er mentalt "300万円." Men kontoutskrifter viser det fulle tallet.
- Komma hvert 3. siffer på utskrifter – selv om det japanske tallsystemet grupperer etter 4 sifre (万 = 10 000, 億 = 100 000 000). Finansdokumenter følger internasjonal konvensjon.
6. Separate Innskudds- og Uttaks-kolonner
I motsetning til vestlige kontoutskrifter som bruker én enkelt beløpskolonne (positiv for kreditter, negativ for debiter), bruker japanske utskrifter typisk to separate kolonner:
- 入金 (nyūkin) – Innskudd/kreditter
- 出金 (shukkin) – Uttak/debiter
Én kolonne er alltid tom for hver transaksjon. Ved konvertering til Excel må du bestemme: beholde to-kolonneformatet, eller slå sammen til én enkelt signert beløpskolonne? Begge valg krever at konvertereren forstår den japanske kolonnestrukturen.
Store Japanske Banker og Deres Utskrifter
MUFG (三菱UFJ銀行)
Japans største bank etter eiendeler (~2,9 billioner dollar) med omtrent 57 millioner individuelle depositumskontoer. Del av Mitsubishi UFJ Financial Group. Tilbyr PDF-utskrifter og CSV-eksport via nettbank (BizSTATION for bedrifter, 三菱UFJダイレクト for privatkunder). CSV-eksport bruker Shift_JIS-koding.
SMBC (三井住友銀行)
Japans nest største kommersielle bank med omtrent 27 millioner privatkunder. Del av Sumitomo Mitsui Financial Group. Nettbank (SMBCダイレクト) tilbyr PDF- og CSV-nedlastinger.
Mizuho (みずほ銀行)
Tredje megabank med omtrent 24 millioner privatkunder og 12,6 millioner nettbankabonnenter. Nettbank (みずほダイレクト) tilbyr transaksjonsnedlastinger.
Japan Post Bank (ゆうちょ銀行)
Den største etter kontotall med omtrent 120 millioner kundekontoer og over 205 billioner yen i totale eiendeler. Opererer gjennom omtrent 24 000 filialer (for det meste kontrakterte postkontorer). Dekker praktisk talt alle kommuner i Japan. "Yucho Tsucho"-appen gir digital tilgang til passboken. Unikt kontonummersystem som skiller seg fra standard japanske bankkontonumre.
Rakuten Bank (楽天銀行)
Japans største nettbank med 17,6+ millioner kontoer og innskudd som overstiger 13 billioner yen. Innskudd har vokst med 16,5% årlig sammenlignet med 3,8% for megabanker. Fullstendig digital med CSV-eksportkapasitet.
Regionale Banker (地方銀行)
Japan har omtrent 97 regionale banker – 61 banker av første rang og 36 banker av andre rang. Hver prefektur har vanligvis minst én regional bank med hovedkontor i sin hovedstad. Eksempler: Yokohama Bank (横浜銀行), Chiba Bank (千葉銀行), Shizuoka Bank (静岡銀行). Utskriftsformater varierer betydelig mellom regionale banker.
SBI Shinsei Bank / Sony Bank
SBI Shinsei Bank og Sony Bank er bemerkelsesverdige for å tilby nettbank på engelsk – sjeldent i Japan. Populære blant utenlandske bosatte av denne grunn. Begge tilbyr PDF- og CSV-eksport.
Metode 1: Bruk PDFSub (Anbefalt)
PDFSub håndterer japanske kontoutskrifter direkte – inkludert alle kodings- og formateringsutfordringene ovenfor.

Slik Fungerer Det
-
Last opp din 取引明細書 – Dra og slipp PDF-en fra en hvilken som helst japansk bank. PDFSub oppdager automatisk bankformatet fra de 20 000+ støttede malene.
-
Automatisk format-håndtering – Konvertereren gjør automatisk: - Oppdager og konverterer Shift_JIS-koding til UTF-8 - Normaliserer fullbredde tall (123) til halvbredde (123) for beregning - Konverterer fullbredde komma, mellomrom og skilletegn til standard tegn - Tolker japanske æradatoer (令和8年3月2日) til standard datoer (2026-03-02) - Oversetter halvbredde katakana avsendernavn til lesbar fullbredde - Slår sammen innskudds-/uttaks-kolonner eller beholder dem som separate kolonner - Gjenkjenner japansk bankterminologi (振込, 振替, 口座振替, etc.)
-
Gjennomgå og verifiser – Sjekk de utpakkede transaksjonene i forhåndsvisningen. Saldoer valideres mot utskriftens åpnings- og sluttsaldo 残高 (balance).
-
Last ned – Eksporter som Excel (.xlsx), CSV (UTF-8), QBO (QuickBooks), OFX (Xero, Wave), QFX (Quicken) eller JSON.
Hvorfor PDFSub Fungerer for Japanske Utskrifter
130+ språk inkludert japansk. Ekstraksjonsmotoren forstår japansk bankterminologi – 振込, 振替, 入金, 出金, 口座振替, 手数料, 利息 – og mapper dem til strukturerte felt.
Koding håndteres automatisk. Ingen behov for manuell deteksjon eller konvertering mellom Shift_JIS og UTF-8. PDFSub identifiserer kodingen og normaliserer alt til UTF-8 med korrekt håndtering av kanji, hiragana, katakana og blandede bredde-tegn.
Alle store japanske banker støttes. Fra de tre megabankene (MUFG, SMBC, Mizuho) til Japan Post Banks 120 millioner kontoer, Rakuten Bank, regionale banker i alle 47 prefekturer, og engelskvennlige banker som SBI Shinsei og Sony Bank.
Nettleser-først personvern. For digitale PDF-er fra nettbank, skjer tektekstraksjon utelukkende i nettleseren din. Filen forlater aldri enheten din. Server-side prosessering brukes kun for skannede dokumenter eller passbok-bilder.
Fullbredde normalisering. Tall, komma, mellomrom og skilletegn normaliseres alle fra fullbredde til halvbredde automatisk – og sikrer at beløp behandles som tall, ikke tekst, i regnearket ditt.
Metode 2: Bankens CSV-eksport
De fleste store japanske banker tilbyr CSV-transaksjonsnedlastinger via nettbank. Her er hva du kan forvente:
Hva Du Får
- Koding: Nesten alltid Shift_JIS (ikke UTF-8)
- Avgrenser: Standard komma (,)
- Datoformat: Vanligvis ÅÅÅÅ/MM/DD (vestlig) i CSV, selv om noen banker bruker æradatoer
- Kolonner: Typisk 日付 (Dato), 摘要 (Beskrivelse), 入金額 (Innskudd), 出金額 (Uttak), 残高 (Saldo)
Begrensninger
Shift_JIS-koding. Åpning av CSV-en på et ikke-japansk system gir uleselig tekst. Du må eksplisitt angi kodingen ved import: I Excel, bruk Data → Hent data → Fra tekst/CSV → Velg "Japansk (Shift-JIS)" koding.
Halvbredde katakana-navn. Avsender-/mottaker-navn vil vises i halvbredde katakana fra Zengin-systemet. Disse er vanskelige å lese selv for innfødte japanske talere og umulige for ikke-talere.
Begrenset historikk. CSV-eksport fra nettbank dekker vanligvis 3-12 måneder. Lengre historikk krever nedlasting av utskrifter for hver periode separat.
Ingen standardisert format. I motsetning til tyske CAMT.053/MT940 eller franske CAMT.053/FEC-standarder, har japanske bank-CSV-er ingen universell format. Hver bank bruker sin egen kolonnerekkefølge, navngivning og struktur.
Fullbredde tegn i beskrivelser. Transaksjonsbeskrivelser kan inneholde fullbredde tall og skilletegn som trenger normalisering før analyse.
Metode 3: Manuell Kopiering/Liming (Ikke Anbefalt)
Problemene er alvorlige med japanske utskrifter:
- Kanji- og katakana-tegn kan ikke kopieres/limet korrekt mellom applikasjoner
- Kodingskonvertering feiler stille – tegn som ser korrekte ut kan være feil Unicode-kodepunkter
- Fullbredde tall limes inn som tekst som ikke kan beregnes
- Halvbredde katakana-navn limes inn, men er uleselige på ikke-japanske systemer
- Æradatoer har ingen automatisk konvertering til gregorianske datoer i engelsk Excel
- Separate innskudds-/uttaks-kolonner krever manuell sammenslåing
- Ingen validering mot åpnings-/sluttsaldoer
For ethvert volum av transaksjoner er denne metoden upraktisk.
Japanske Finanssystemer Du Bør Kjenne Til
Zengin System (全銀システム)
Japans kjerne innenlandske interbank-betalingsnettverk, etablert i 1973. Kobler sammen praktisk talt alle private banker i Japan, og behandler omtrent 6,5 millioner transaksjoner per dag til en verdi av rundt 12 billioner yen.
Zengin filformatet bruker faste 120-bytes poster med halvbredde katakana-koding for navn. Dette eldre formatet er grunnen til at avsender-/mottaker-navn på kontoutskrifter vises i halvbredde katakana i stedet for kanji. Det nyere ZEDI (Zengin EDI)-systemet støtter full kanji og beveger seg mot ISO 20022-kompatibel XML-meldinger, men det eldre formatet vedvarer på mange utskrifter.
Blue Return (青色申告) vs. White Return (白色申告)
Japansk skatterapportering har to nivåer:
| Funksjon | Blue Return (青色申告) | White Return (白色申告) |
|---|---|---|
| Søknad | Må søkes på forhånd | Standardstatus |
| Bokføring | Detaljert dobbel bokføring | Enkel inntekt/utgift |
| Spesialfradrag | Opptil ¥650 000 (med e-Tax) | Ingen |
| Fremføring av tap | Ja, opptil 3 år | Nei |
Blue Return-innleverere – som mottar det større skattefradraget – er pålagt å føre detaljerte finansielle opptegnelser, noe som gjør nøyaktig konvertering av kontoutskrifter essensielt for deres bokføring.
Qualified Invoice System (インボイス制度)
Lansert 1. oktober 2023, krever dette systemet at bedrifter registrerer seg som "kvalifiserte fakturautstedere" for å utstede gyldige fakturaer for merverdiavgiftskreditter. Tidligere var bedrifter med årlig skattepliktig salg under 10 millioner yen unntatt fra merverdiavgift. Denne endringen har betydelig økt behovet for nøyaktig finansiell registrering blant små bedrifter og frilansere.
Japansk Regnskapsprogramvare
| Programvare | Nøkkeltall | Målgruppe |
|---|---|---|
| freee | ~600 000 abonnenter | SMB-er, frilansere, startups |
| Money Forward | 27,96 milliarder yen SaaS ARR | SMB-er, enkeltpersoner |
| Yayoi (弥生) | #1 desktop-regnskap i 24 år på rad | SMB-er, enkeltpersonforetak |
| TKC | Betjener ~11 500 revisorbyråer | Revisorbyråer |
Alle de tre store skyplattformene (freee, Money Forward, Yayoi Online) støtter CSV-import av banktransaksjonsdata. PDFSubs Excel- og CSV-eksport kan importeres direkte inn i disse verktøyene.
Hvem Trenger Konvertering av Japanske Kontoutskrifter?
Skatte-revisorer (税理士). Japan har omtrent 82 276 registrerte skatterevisorer (per desember 2025). De behandler klienters kontoutskrifter for bokføring, skatterapportering og revisjonsforberedelser. Alene TKC National Federation har 11 500 medlemsbyråer.
Utenlandske bosatte. Per juni 2025 bor 3,96 millioner utenlandske statsborgere i Japan – nesten dobbelt så mange som i 2012. De fleste kontoutskrifter er helt på japansk uten engelsk alternativ. Utenlandske bosatte trenger konverterte utskrifter for skatterapportering til hjemlandet, fornyelse av visum og for å sende finansiell dokumentasjon til utenlandske institusjoner.
Frilansere som leverer Blue Returns. Selvstendig næringsdrivende og frilansere som opprettholder Blue Return (青色申告) status, må føre detaljerte regnskaper med dobbel bokføring. Konvertering av kontoutskrifter til Excel er startpunktet for å kategorisere forretningsutgifter og beregne spesialfradraget på ¥650 000.
Internasjonale bedrifter. Selskaper med japanske datterselskaper trenger å konsolidere japanske bankdata med globale regnskapssystemer. De tre megabankene fungerer kollektivt som hovedbank for 19,3 % av japanske selskaper, og bedriftsbanktjenester går vanligvis via MUFGs BizSTATION eller lignende portaler.
Studenter og innehavere av working holiday-visum. Japan hadde over 30 millioner internasjonale besøkende i 2024. Langtidsstudenter og innehavere av working holiday-visum åpner japanske bankkontoer (ofte hos Japan Post Bank, den mest tilgjengelige) og trenger å behandle utskrifter når de administrerer finanser eller leverer skatt i hjemlandet.
Tips for Arbeid med Japanske Finansdata i Excel
Sjekk for mojibake først. Hvis japansk tekst vises som uleselige tegn (ä, â€, é, etc.), ble filen åpnet med feil koding. Importer på nytt ved å bruke Shift_JIS-koding eller bruk PDFSubs UTF-8 Excel-eksport for å unngå problemet helt.
Verifiser talltyper. Etter import, test at beløp er faktiske tall: klikk på en celle og sjekk om Excel viser et tall i formellinjen, eller prøv =SUM() på en kolonne. Hvis SUM returnerer 0, men cellene viser tall, er verdiene fullbredde tekst som utgir seg for å være tall.
Forstå to-kolonneformatet. Japanske utskrifter bruker separate 入金 (innskudd) og 出金 (uttak) kolonner. Hvis analysen din trenger ett enkelt signert beløp, lag en formel: =IF(deposit_cell<>"", deposit_cell, -withdrawal_cell).
Konverter æradatoer. Hvis du mottar æradatoer: Reiwa-år + 2018 = Gregoriansk år. Så 令和8年 = 2026, 令和7年 = 2025. For Heisei-datoer (før mai 2019): Heisei-år + 1988 = Gregoriansk år.
Behold den originale PDF-en. Japansk skattelov krever oppbevaring av finansielle opptegnelser. For Blue Return-innleverere er den originale kontoutskriften (eller passboken) nødvendig dokumentasjon. Behold alltid PDF-en sammen med din konverterte Excel-fil.
Se opp for blandede bredde-tegn. Hvis sortering eller filtrering gir uventede resultater, sjekk for blandede fullbredde og halvbredde tegn i samme kolonne. Et enkelt fullbredde mellomrom i en ellers halvbredde celle vil forårsake feil.
Ofte Stilte Spørsmål
Kan jeg konvertere MUFG (三菱UFJ銀行) utskrifter til Excel?
Ja. MUFG er Japans største bank med omtrent 57 millioner individuelle kontoer. PDFSub håndterer MUFG PDF-utskrifter direkte, og konverterer japansk formatering – inkludert Shift_JIS-koding, halvbredde katakana avsendernavn, og separate innskudds-/uttaks-kolonner – til rene, UTF-8-kodede regnearkdata.
Hvordan fikser jeg uleselige japanske tegn (mojibake)?
Mojibake oppstår når en Shift_JIS-kodet fil åpnes som UTF-8 (eller omvendt). PDFSub unngår dette helt ved å oppdage kodingen automatisk og eksportere i UTF-8. Hvis du jobber med rå CSV-filer, spesifiser "Japansk (Shift-JIS)" koding når du importerer til Excel: Data → Hent data → Fra tekst/CSV → velg kodingen.
Har japanske bank-PDF-er OCR-problemer?
Utskrifter lastet ned fra nettbank er native digitale PDF-er med valgbar tekst – ekstraksjon er rask og nøyaktig. OCR er nødvendig for skannede papirutskrifter eller passbok-bilder (通帳の写真). Japans passbok-kultur betyr at mange brukere fotograferer passbok-sidene sine i stedet for å laste ned PDF-er. PDFSub håndterer både digitale PDF-er og skannede dokumenter.
Hva med passbok (通帳) oppføringer?
Fysiske passbøker er fortsatt vanlige i Japan, selv om bruken synker ettersom banker tar gebyr for nye passbøker (MUFG tar ¥550/år). Passbok-oppføringer er typisk mer forkortede enn online utskrifts-PDF-er, og viser kun forkortede beskrivelser. Hvis du fotograferer passbok-sider, kan PDFSubs OCR-modus trekke ut transaksjonene.
Kan jeg eksportere japanske bankdata til freee eller Money Forward?
PDFSub eksporterer til Excel, CSV (UTF-8), QBO, OFX, QFX og JSON. For japansk regnskapsprogramvare (freee, Money Forward, Yayoi), eksporter til CSV og importer ved hjelp av programvarens innebygde importfunksjon for banktransaksjoner. De korrekt kodede, normaliserte dataene fra PDFSub sikrer ren import uten mojibake eller formateringsproblemer.
Hvordan håndterer jeg japanske æradatoer (令和)?
PDFSub konverterer automatisk japanske æradatoer til standard gregorianske datoer. For manuell konvertering: Reiwa-år + 2018 = Gregoriansk år (令和8年 = 2026). Heisei-år + 1988 = Gregoriansk år (平成31年 = 2019). Æraene endret seg 1. mai 2019.
Hvor mange japanske banker støtter PDFSub?
PDFSub støtter 20 000+ bankformater globalt, inkludert alle store japanske banker: de tre megabankene (MUFG, SMBC, Mizuho), Japan Post Bank, Rakuten Bank, regionale banker i alle 47 prefekturer, og engelskvennlige banker som SBI Shinsei og Sony Bank.
Kan jeg konvertere flere japanske utskrifter samtidig?
Ja. Last opp flere 取引明細書 (transaksjonsutskrifter) og PDFSub behandler dem sekvensielt. Hver utskrift blir automatisk oppdaget og konvertert uavhengig, selv om de er fra forskjellige banker med ulike layout og kodingskonvensjoner.
Prøv PDFSub gratis i 7 dager - full tilgang til Bank Statement Converter og 84+ andre PDF-verktøy på All-In-One-planen ($20/bruker/mnd årlig). Kanseller når som helst.