Konverter japanske kontoutskrifter til Excel (MUFG, SMBC, Mizuho og mer)
Japanske kontoutskrifter kombinerer kanji-beskrivelser, Shift_JIS-koding, halvbredde katakana og japanske tidsdateringer 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 uforståelig mojibake (文字化け), Reiwa-tidsdateringen "令和8年3月2日" betyr ingenting for regnearket ditt på engelsk, navn på avsendere i halvbredde katakana som "ﾔﾏﾀﾞ ﾀﾛｳ" blir uleselige symboler, og fullbredde tall "１２３，４５６" vil ikke beregne fordi de er andre Unicode-tegn enn sine halvbredde-ekvivalenter.
Hovedproblemet er: Japansk bankdrift baserer seg på tegnkoding og formateringskonvensjoner som forutsetter et system med japansk lokalisering. 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 kodingfeil nesten garantert.
Enten du er en utenlandsk bosatt i Tokyo som behandler MUFG-utskrifter for skatterapportering til hjemlandet, en zeirishi (skatterådgiver) 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 omfatter tegnkoding, nummersystemer, datokonvensjoner og eldre interbankformater.
1. Shift_JIS vs. UTF-8-koding (Mojibake)
Dette er det desidert største problemet for alle som behandler japanske finansdata utenfor Japan.
De fleste japanske banker eksporterer CSV-filer i Shift_JIS (kodeside 932) — en kodestandard som går foran 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 uforståelig. Japanerne har et ord for dette: 文字化け (mojibake), bokstavelig talt "tegntransformasjon."
| 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 ulikt uforståelig 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. Autodeteksjon er upålitelig, spesielt når filen inneholder en blanding av japanske tegn og latinsk tekst (noe 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 | Samme tall, forskjellige bytes |
| カード | ｶｰﾄﾞ | Samme ord ("kort"), forskjellig koding |
| ，（コンマ） | , (komma) | Samme skilletegn, forskjellige bytes |
| （スペース） | (mellomrom) | Samme mellomrom, forskjellige bytes |
En celle som inneholder "１２３，４５６" (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-betalingsklareringssystemet — 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 navnet på avsenderen 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 diakritiske tegn (dakuten) separate tegn. Tegnet ガ (ga) i fullbredde er ett tegn, men i halvbredde blir det to: ｶﾞ (ka + diakritisk tegn). Dette dobler den tilsynelatende lengden på navn som inneholder stemte lyder og bryter all tekstbehandling som teller tegnposisjoner.
4. Japanske Tidsdateringer (和暦)
Japan bruker sin egen tidsbaserte kalender ved siden av den gregorianske kalenderen. Den nåværende tidsalderen er Reiwa (令和), som startet 1. mai 2019.
| Japansk Tidsdatering | 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 tidsaldre. Den kan ikke tolke "令和8年" som 2026. Selv det forkortede formatet "R8.03.02" er uigenkjennelig.
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 rent når tidsaldre brukes.
Tidsaldersgrenseproblem: 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 tidsaldre korrekt.
5. Heltallig Valuta (Ingen Desimaler)
Yen har ingen underenhet — det finnes ingen cent. Alle beløp på japanske kontoutskrifter er heltall: ¥1 234 567 betyr nøyaktig 1 234 567 yen.
Dette forenkler faktisk ett 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-enhets 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 hver 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 Kolonner for Innskudd og Uttak
I motsetning til vestlige kontoutskrifter som bruker en enkelt beløpskolonne (positiv for kreditter, negativ for debiter), bruker japanske utskrifter vanligvis 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 en enkelt kolonne med fortegn? 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 nedlasting av transaksjoner.
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 kontraktsbaserte postkontorer). Nå nesten alle kommuner i Japan. "Yucho Tsucho"-appen gir tilgang til digitalt passbok. Unikt kontonummersystem som skiller seg fra standard japanske bankkontonumre.
Rakuten Bank (楽天銀行)
Japans største nettbank med 17,6+ millioner kontoer og innskudd over 13 billioner yen. Innskudd har vokst med 16,5 % årlig sammenlignet med 3,8 % for megabanker. Fullstendig digital med CSV-eksportmulighet.
Regionale Banker (地方銀行)
Japan har omtrent 97 regionale banker — 61 banker av første nivå og 36 banker av andre nivå. 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 koding- og formateringsutfordringene nevnt ovenfor.
Slik Fungerer Det
-
Last opp din 取引明細書 — Dra og slipp PDF-en fra en hvilken som helst japansk bank. PDFSub autodetekterer bankformatet fra de over 20 000 støttede malene.
-
Automatisk formatbehandling — Konvertereren gjør automatisk:
- Detekterer og konverterer Shift_JIS-koding til UTF-8
- Normaliserer fullbredde tall (１２３) til halvbredde (123) for beregning
- Konverterer fullbredde komma, mellomrom og skilletegn til standard tegn
- Tolker japanske tidsdateringer (令和8年3月2日) til standard datoer (2026-03-02)
- Oversetter halvbredde katakana-navn på avsendere til lesbar fullbredde
- Slår sammen innskudds-/uttaks-kolonner eller beholder dem som separate kolonner
- Gjenkjenner japansk bankterminologi (振込, 振替, 口座振替, etc.)
-
Gjennomgå og verifiser — Sjekk de uthentede transaksjonene i forhåndsvisningen. Saldoer valideres mot utskriftens åpnings- og sluttsaldo (残高).
-
Last ned — Eksporter som Excel (.xlsx), CSV (UTF-8), QBO (QuickBooks), OFX (Xero, Wave), QFX (Quicken) eller JSON.
Hvorfor PDFSub Fungerer for Japanske Utskrifter
133 språk inkludert japansk. Utvinningmotoren forstår japansk bankterminologi — 振込, 振替, 入金, 出金, 口座振替, 手数料, 利息 — og mapper dem til strukturerte felt.
Koding håndteres automatisk. Ingen manuell deteksjon eller konvertering mellom Shift_JIS og UTF-8 er nødvendig. PDFSub identifiserer kodingen og normaliserer alt til UTF-8 med korrekt håndtering av kanji, hiragana, katakana og tegn med blandet bredde.
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 engelskspråklige banker som SBI Shinsei og Sony Bank.
Nettleser-først personvern. For digitale PDF-er fra nettbank, skjer tekstutvinning utelukkende i nettleseren din. Filen forlater aldri enheten din. Server-basert prosessering brukes kun for skannede dokumenter eller passbokbilder.
Normalisering av fullbredde. Tall, komma, mellomrom og skilletegn normaliseres alle fra fullbredde til halvbredde automatisk — noe som sikrer at beløp behandles som tall, ikke tekst, i regnearket ditt.
Metode 2: Bankens CSV-eksport
De fleste store japanske banker tilbyr CSV-nedlasting av transaksjoner 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 tidsaldre
- Kolonner: Typisk 日付 (Dato), 摘要 (Beskrivelse), 入金額 (Innskudd), 出金額 (Uttak), 残高 (Saldo)
Begrensninger
Shift_JIS-koding. Åpning av CSV-en på et ikke-japansk system gir uforståelig tekst. Du må eksplisitt angi kodingen ved import: I Excel, bruk Data → Hent data → Fra tekst/CSV → Velg "Japanese (Shift-JIS)"-koding.
Halvbredde katakana-navn. Avsender-/mottaker-navn vil vises i halvbredde katakana fra Zengin-systemet. Disse er vanskelige å lese selv for japansktalende og umulige for ikke-talende.
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 kolonne-rekkefølge, navngivning og struktur.
Fullbredde tegn i beskrivelser. Transaksjonsbeskrivelser kan inneholde fullbredde tall og skilletegn som må normaliseres 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
- Kodingkonvertering 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
- Tidsaldre 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 betalingsklareringsnettverk, etablert i 1973. Kobler sammen nesten 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-byte 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 | Standard status |
| 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 registre, 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 avgiftspliktig 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 skatterådgiverfirmaer | Skatterådgiverfirmaer |
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?
Skatteadvokater (税理士). Japan har omtrent 82 276 registrerte skatteadvokater (per desember 2025). De behandler klienters kontoutskrifter for bokføring, skatterapportering og revisjonsforberedelser. Den nasjonale TKC-føderasjonen alene har 11 500 medlemsfirmaer.
Utenlandske bosatte. Per juni 2025 bor 3,96 millioner utenlandske innbyggere 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 Return. 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 ¥650 000 spesialfradraget.
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 arbeidsferievisum-innehavere. Japan hadde over 30 millioner internasjonale besøkende i 2024. Langtidsstudenter og innehavere av arbeidsferievisum å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 uforståelige 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 et enkelt fortegnsbeløp, lag en formel: =IF(deposit_cell<>"", deposit_cell, -withdrawal_cell).
Konverter tidsaldre. Hvis du mottar tidsaldre: Reiwa-år + 2018 = Gregoriansk år. Så 令和8年 = 2026, 令和7年 = 2025. For Heisei-datoer (før mai 2019): Heisei-år + 1988 = Gregoriansk år.
Behold original PDF. Japansk skattelov krever oppbevaring av finansielle registre. For Blue Return-innleverere er den originale kontoutskriften (eller passboken) påkrevd 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 Stillete 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 den japanske formateringen — inkludert Shift_JIS-koding, halvbredde katakana-avsendernavn og separate innskudds-/uttaks-kolonner — til rene, UTF-8-kodede regnearkdata.
Hvordan fikser jeg uforståelige 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 å detektere kodingen automatisk og eksportere i UTF-8. Hvis du jobber med rå CSV-filer, spesifiser "Japanese (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 — utvinning er rask og nøyaktig. OCR er nødvendig for skannede papirutskrifter eller passbokbilder (通帳の写真). Japans passbokkultur betyr at mange brukere tar bilde av 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 betalt for nye passbøker (MUFG tar ¥550/år). Passbok-oppføringer er vanligvis mer forkortede enn online utskrifts-PDF-er, og viser kun forkortede beskrivelser. Hvis du tar bilde av 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 tidsaldre (令和)?
PDFSub konverterer automatisk japanske tidsaldre til standard gregorianske datoer. For manuell konvertering: Reiwa-år + 2018 = Gregoriansk år (令和8年 = 2026). Heisei-år + 1988 = Gregoriansk år (平成31年 = 2019). Tidsaldrene endret seg 1. mai 2019.
Hvor mange japanske banker støtter PDFSub?
PDFSub støtter over 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 engelskspråklige 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 detekteres og konverteres uavhengig, selv om de er fra forskjellige banker med ulike layouter og kodingkonvensjoner.
Prøv PDFSub gratis i 7 dager — full tilgang til Bank Statement Converter og 77+ andre PDF-verktøy. Avslutt når som helst.