Convertir les relevés bancaires japonais en Excel (MUFG, SMBC, Mizuho et plus)
Les relevés bancaires japonais combinent des descriptions en kanji, l'encodage Shift_JIS, du katakana en demi-chasse et des dates à l'ère japonaise qui posent problème dans Excel hors du Japon. Voici comment les convertir correctement.
Votre 取引明細 (relevé de transactions) de MUFG semble parfaitement structuré dans le PDF. Mais ouvrez-le dans Excel hors du Japon et les problèmes s'accumulent : les caractères kanji se transforment en caractères incompréhensibles (mojibake 文字化け), la date de l'ère Reiwa "令和8年3月2日" n'a aucun sens pour votre tableur anglais, les noms d'expéditeurs en katakana demi-chasse comme "ﾔﾏﾀﾞ ﾀﾛｳ" deviennent illisibles, et les nombres pleine chasse "１２３，４５６" ne peuvent pas être calculés car ce sont des caractères Unicode différents de leurs équivalents demi-chasse.
Le problème fondamental est le suivant : les opérations bancaires japonaises reposent sur des conventions d'encodage de caractères et de formatage qui supposent un système avec une locale japonaise. Le réseau interbancaire Zengin — qui traite environ 6,5 millions de transactions et 12 billions de yens par jour — exigeait historiquement le katakana en demi-chasse pour tous les noms, un héritage qui se retrouve encore sur les relevés bancaires modernes. Lorsque vous déplacez ces données vers un ordinateur non japonais, les erreurs d'encodage sont presque garanties.
Que vous soyez un résident étranger à Tokyo traitant des relevés MUFG pour la déclaration fiscale dans votre pays d'origine, un zeirishi (expert-comptable fiscal) important des données clients dans freee ou Money Forward, une entreprise internationale consolidant des données d'une filiale japonaise, ou un freelance gérant la comptabilité Blue Return (青色申告) — le problème principal est identique : extraire des données structurées et prêtes pour un tableur à partir de relevés bancaires PDF japonais.
Ce guide couvre les défis de formatage spécifiques des relevés japonais, les principales banques que vous rencontrerez et comment les convertir avec précision.
Pourquoi les relevés bancaires japonais posent problème dans Excel
Les relevés bancaires japonais créent un ensemble unique de défis qui vont au-delà du simple formatage des nombres. Les problèmes concernent l'encodage des caractères, les systèmes de numérotation, les conventions de date et les formats interbancaires hérités.
1. Encodage Shift_JIS vs. UTF-8 (Mojibake)
C'est le problème le plus important pour quiconque traite des données financières japonaises en dehors du Japon.
La plupart des banques japonaises exportent des fichiers CSV en Shift_JIS (code page 932) — une norme d'encodage qui précède l'UTF-8 et ne couvre que les caractères japonais. Lorsque vous ouvrez un fichier Shift_JIS sur un système attendant l'UTF-8, chaque caractère japonais devient illisible. Les Japonais ont un mot pour cela : 文字化け (mojibake), littéralement "transformation de caractères".
| Ce que vous devriez voir | Ce que l'UTF-8 affiche |
|---|---|
| 振込 カ）ヤマダ タロウ | 振込 カ）ヤマダ |
| 三菱UFJ銀行 | 三è±UFJ銀行 |
| 口座振替 電気代 | å£åº§æŒ¯æ›¿ 電気代 |
L'inverse est également vrai : les fichiers UTF-8 ouverts dans Excel avec une locale japonaise peuvent produire une sortie illisible différente.
Le problème est aggravé par le fait que les fichiers Shift_JIS n'ont pas de Byte Order Mark (BOM) — il n'y a pas d'en-tête indiquant au logiciel quel encodage utiliser. La détection automatique est peu fiable, surtout lorsque le fichier contient un mélange de caractères japonais et de texte latin (ce que font tous les relevés bancaires).
2. Caractères pleine chasse vs. demi-chasse (全角 vs. 半角)
Ceci est propre au Japon et déconcerte pratiquement tous les développeurs non japonais.
L'informatique japonaise utilise deux largeurs pour de nombreux caractères. Les caractères pleine chasse (全角) occupent l'espace de deux caractères latins ; les caractères demi-chasse (半角) en occupent un.
| Pleine chasse (全角) | Demi-chasse (半角) | Même caractère ? |
|---|---|---|
| １２３，４５６ | 123,456 | Même nombre, octets différents |
| カード | ｶｰﾄﾞ | Même mot ("carte"), encodage différent |
| ，（コンマ） | , (virgule) | Même ponctuation, octets différents |
| （スペース） | (espace) | Même espace, octets différents |
Une cellule contenant "１２３，４５６" (pleine chasse) ressemble à "123,456" à l'écran, mais Excel traite la version pleine chasse comme du texte, pas un nombre. Vous ne pouvez pas faire la SOMME, trier ou utiliser dans des formules. Une recherche-remplacement standard pour les virgules ne correspondra pas non plus aux virgules pleine chasse.
Les relevés bancaires peuvent mélanger les largeurs : les montants peuvent être en demi-chasse tandis que les descriptions utilisent des caractères pleine chasse. Le convertisseur doit tout normaliser en demi-chasse cohérente pour les calculs.
3. Katakana demi-chasse du système Zengin
Le système de compensation des paiements interbancaires Zengin — l'épine dorsale des paiements domestiques du Japon — exigeait historiquement que tous les noms soient transmis en katakana demi-chasse (半角カナ) dans une limite de 20 caractères.
Cela crée un problème spécifique : sur votre relevé bancaire, le nom de l'expéditeur d'un virement apparaît comme ﾔﾏﾀﾞ ﾀﾛｳ au lieu de 山田 太郎 (Yamada Taro). Même les lecteurs japonais natifs trouvent le katakana demi-chasse plus difficile à lire.
Pire : en katakana demi-chasse, les marques de consonnes voisées (dakuten) sont des caractères séparés. Le caractère ガ (ga) en pleine chasse est un seul caractère, mais en demi-chasse, il devient deux : ｶﾞ (ka + marque voisée). Cela double la longueur apparente des noms contenant des sons voisés et perturbe tout traitement de texte qui compte les positions des caractères.
4. Dates à l'ère japonaise (和暦)
Le Japon utilise son propre calendrier basé sur les ères en plus du calendrier grégorien. L'ère actuelle est Reiwa (令和), qui a commencé le 1er mai 2019.
| Date à l'ère japonaise | Équivalent grégorien |
|---|---|
| 令和8年3月2日 | 2 mars 2026 |
| R8.03.02 | 2 mars 2026 |
| 令和7年12月15日 | 15 décembre 2025 |
Excel en anglais n'a aucune notion des ères japonaises. Il ne peut pas analyser "令和8年" comme 2026. Même le format abrégé "R8.03.02" est méconnaissable.
Bonne nouvelle : le Japon utilise l'ordre Année-Mois-Jour (du plus grand au plus petit), ce qui est conforme à la norme ISO 8601. Lorsque les relevés utilisent des dates occidentales, elles apparaissent comme 2026/03/02 — moins ambigu que le format européen JJ/MM/AAAA. Le défi réside uniquement lorsque des dates d'ère sont utilisées.
Problème de frontière d'ère : les relevés historiques de 2019 peuvent chevaucher la transition Heisei-Reiwa (Heisei s'est terminé le 30 avril 2019). La même année, 2019, est à la fois Heisei 31 et Reiwa 1. Un convertisseur doit gérer correctement les deux ères.
5. Devise en nombres entiers (pas de décimales)
Le yen n'a pas de sous-unité — il n'y a pas de centimes. Tous les montants sur les relevés bancaires japonais sont des nombres entiers : ¥1 234 567 signifie exactement 1 234 567 yens.
Cela simplifie en fait un aspect de la conversion (pas besoin de gérer les décimales) mais en introduit d'autres :
- Les grands nombres sont courants. Un salaire typique est de 300 000 à 500 000 ¥ par mois. Le loyer peut être de 80 000 à 200 000 ¥. Les nombres atteignent fréquemment six ou sept chiffres.
- Pensée en unités de 10 000. Les Japonais pensent en unités de 万 (man, 10 000). Un salaire de 3 000 000 ¥ est mentalement "300万円". Mais les relevés bancaires affichent le nombre complet.
- Virgules tous les 3 chiffres sur les relevés — même si le système numérique japonais regroupe par 4 chiffres (万 = 10 000, 億 = 100 000 000). Les documents financiers suivent la convention internationale.
6. Colonnes séparées pour dépôts et retraits
Contrairement aux relevés bancaires occidentaux qui utilisent une seule colonne de montant (positive pour les crédits, négative pour les débits), les relevés japonais utilisent généralement deux colonnes séparées :
- 入金 (nyūkin) — Dépôts/crédits
- 出金 (shukkin) — Retraits/débits
Une colonne est toujours vide pour chaque transaction. Lors de la conversion vers Excel, vous devez décider : conserver le format à deux colonnes, ou fusionner en une seule colonne de montant signé ? L'un ou l'autre choix nécessite que le convertisseur comprenne la structure des colonnes japonaises.
Principales banques japonaises et leurs relevés
MUFG (三菱UFJ銀行)
La plus grande banque du Japon par actifs (~2,9 billions de dollars) avec environ 57 millions de comptes de dépôt individuels. Fait partie du Mitsubishi UFJ Financial Group. Propose des relevés PDF et des exportations CSV via la banque en ligne (BizSTATION pour les entreprises, 三菱UFJダイレクト pour les particuliers). Les exportations CSV utilisent l'encodage Shift_JIS.
SMBC (三井住友銀行)
Deuxième plus grande banque commerciale du Japon avec environ 27 millions de clients particuliers. Fait partie du Sumitomo Mitsui Financial Group. La banque en ligne (SMBCダイレクト) propose des téléchargements de relevés PDF et CSV.
Mizuho (みずほ銀行)
Troisième mégabanque avec environ 24 millions de clients particuliers et 12,6 millions d'abonnés à la banque en ligne. La banque en ligne (みずほダイレクト) propose des téléchargements de transactions.
Japan Post Bank (ゆうちょ銀行)
La plus grande par le nombre de comptes avec environ 120 millions de comptes clients et plus de 205 billions de yens d'actifs totaux. Opère via environ 24 000 agences (principalement des bureaux de poste sous contrat). Atteint pratiquement toutes les municipalités du Japon. L'application "Yucho Tsucho" donne accès à un livret numérique. Système de numérotation de compte unique qui diffère des numéros de compte bancaire japonais standard.
Rakuten Bank (楽天銀行)
La plus grande banque en ligne du Japon avec plus de 17,6 millions de comptes et des dépôts dépassant 13 billions de yens. Les dépôts ont augmenté de 16,5 % par an, contre 3,8 % pour les mégabanques. Entièrement numérique avec capacité d'exportation CSV.
Banques régionales (地方銀行)
Le Japon compte environ 97 banques régionales — 61 banques de premier rang et 36 banques de second rang. Chaque préfecture a généralement au moins une banque régionale dont le siège est dans sa capitale. Exemples : Yokohama Bank (横浜銀行), Chiba Bank (千葉銀行), Shizuoka Bank (静岡銀行). Les formats de relevés varient considérablement d'une banque régionale à l'autre.
SBI Shinsei Bank / Sony Bank
SBI Shinsei Bank et Sony Bank sont notables pour offrir une banque en ligne en anglais — rare au Japon. Populaires auprès des résidents étrangers pour cette raison. Les deux proposent des exportations PDF et CSV.
Méthode 1 : Utiliser PDFSub (Recommandé)
PDFSub gère nativement les relevés bancaires japonais — y compris tous les défis d'encodage et de formatage ci-dessus.
Comment ça marche
-
Téléchargez votre 取引明細書 — Faites glisser et déposez le PDF de n'importe quelle banque japonaise. PDFSub détecte automatiquement le format de la banque parmi plus de 20 000 modèles pris en charge.
-
Gestion automatique du format — Le convertisseur effectue automatiquement les actions suivantes :
- Détecte et convertit l'encodage Shift_JIS en UTF-8
- Normalise les nombres pleine chasse (１２３) en demi-chasse (123) pour le calcul
- Convertit les virgules, espaces et ponctuations pleine chasse en caractères standard
- Analyse les dates à l'ère japonaise (令和8年3月2日) en dates standard (2026-03-02)
- Traduit les noms en katakana demi-chasse en pleine chasse lisible
- Fusionne les colonnes de dépôt/retrait ou les conserve comme colonnes séparées
- Reconnaît la terminologie bancaire japonaise (振込, 振替, 口座振替, etc.)
-
Vérifiez et validez — Examinez les transactions extraites dans l'aperçu. Les soldes sont validés par rapport au solde d'ouverture et de clôture du relevé, le 残高 (solde).
-
Téléchargez — Exportez en Excel (.xlsx), CSV (UTF-8), QBO (QuickBooks), OFX (Xero, Wave), QFX (Quicken) ou JSON.
Pourquoi PDFSub fonctionne pour les relevés japonais
133 langues, dont le japonais. Le moteur d'extraction comprend la terminologie bancaire japonaise — 振込, 振替, 入金, 出金, 口座振替, 手数料, 利息 — et les mappe à des champs structurés.
Encodage géré automatiquement. Pas besoin de détecter ou de convertir manuellement entre Shift_JIS et UTF-8. PDFSub identifie l'encodage et normalise tout en UTF-8 avec une gestion correcte des kanji, hiragana, katakana et caractères de largeur mixte.
Toutes les principales banques japonaises prises en charge. Des trois mégabanques (MUFG, SMBC, Mizuho) à la Japan Post Bank avec ses 120 millions de comptes, Rakuten Bank, les banques régionales dans les 47 préfectures, et les banques conviviales en anglais comme SBI Shinsei et Sony Bank.
Confidentialité axée sur le navigateur. Pour les PDF numériques provenant de la banque en ligne, l'extraction de texte se fait entièrement dans votre navigateur. Le fichier ne quitte jamais votre appareil. Le traitement côté serveur n'est utilisé que pour les documents numérisés ou les photos de passeports bancaires.
Normalisation pleine chasse. Les nombres, virgules, espaces et ponctuations sont tous normalisés de pleine chasse à demi-chasse automatiquement — garantissant que les montants sont traités comme des nombres, et non comme du texte, dans votre tableur.
Méthode 2 : Export CSV de votre banque
La plupart des grandes banques japonaises proposent des téléchargements de transactions CSV via leur banque en ligne. Voici ce à quoi vous attendre :
Ce que vous obtiendrez
- Encodage : Presque toujours Shift_JIS (pas UTF-8)
- Délimiteur : Virgule standard (,)
- Format de date : Généralement AAAA/MM/JJ (occidental), bien que certaines banques utilisent des dates d'ère
- Colonnes : Typiquement 日付 (Date), 摘要 (Description), 入金額 (Dépôt), 出金額 (Retrait), 残高 (Solde)
Limites
Encodage Shift_JIS. L'ouverture du CSV sur tout système non japonais produit du texte illisible. Vous devez explicitement définir l'encodage lors de l'importation : Dans Excel, utilisez Données → Obtenir les données → À partir de texte/CSV → Sélectionnez l'encodage "Japonais (Shift-JIS)".
Noms en katakana demi-chasse. Les noms d'expéditeurs/destinataires apparaîtront en katakana demi-chasse du système Zengin. Ils sont difficiles à lire même pour les Japonais natifs et impossibles pour les non-locuteurs.
Historique limité. Les exportations CSV de la banque en ligne couvrent généralement 3 à 12 mois. Un historique plus long nécessite de télécharger les relevés pour chaque période séparément.
Format non standardisé. Contrairement aux normes allemandes CAMT.053/MT940 ou françaises CAMT.053/FEC, les CSV bancaires japonais n'ont pas de format universel. Chaque banque utilise son propre ordre de colonnes, sa nomenclature et sa structure.
Caractères pleine chasse dans les descriptions. Les descriptions de transactions peuvent contenir des nombres et des ponctuations pleine chasse qui nécessitent une normalisation avant analyse.
Méthode 3 : Copier-coller manuel (Non recommandé)
Les problèmes sont graves avec les relevés japonais :
- Les caractères kanji et katakana peuvent ne pas être correctement collés entre les applications
- La conversion d'encodage échoue silencieusement — les caractères qui semblent corrects peuvent être des points de code Unicode erronés
- Les nombres pleine chasse collent comme du texte qui ne peut pas être calculé
- Les noms en katakana demi-chasse collent mais sont illisibles sur les systèmes non japonais
- Les dates d'ère n'ont pas de conversion automatique en dates grégoriennes dans Excel en anglais
- Les colonnes séparées de dépôt/retrait nécessitent une fusion manuelle
- Aucune validation par rapport aux soldes d'ouverture/clôture
Pour tout volume de transactions, cette approche est impraticable.
Systèmes financiers japonais à connaître
Système Zengin (全銀システム)
Le réseau central de compensation des paiements interbancaires domestiques du Japon, établi en 1973. Il relie pratiquement toutes les banques privées au Japon, traitant environ 6,5 millions de transactions par jour pour un total d'environ 12 billions de yens.
Le format de fichier Zengin utilise des enregistrements de 120 octets de largeur fixe avec un encodage en katakana demi-chasse pour les noms. Ce format hérité explique pourquoi les noms d'expéditeurs/destinataires sur les relevés bancaires apparaissent en katakana demi-chasse plutôt qu'en kanji. Le nouveau système ZEDI (Zengin EDI) prend en charge les kanji complets et évolue vers la messagerie XML conforme à la norme ISO 20022, mais le formatage hérité persiste sur de nombreux relevés.
Blue Return (青色申告) vs. White Return (白色申告)
La déclaration fiscale japonaise comporte deux niveaux :
| Caractéristique | Blue Return (青色申告) | White Return (白色申告) |
|---|---|---|
| Demande | Doit être faite à l'avance | Statut par défaut |
| Comptabilité | Double entrée détaillée | Revenus/dépenses simples |
| Déduction spéciale | Jusqu'à 650 000 ¥ (avec e-Tax) | Aucune |
| Report des pertes | Oui, jusqu'à 3 ans | Non |
Les déclarants Blue Return — qui bénéficient de la déduction fiscale plus importante — sont tenus de tenir des registres financiers détaillés, ce qui rend la conversion précise des relevés bancaires essentielle pour leur comptabilité.
Système de facturation qualifiée (インボイス制度)
Lancé le 1er octobre 2023, ce système oblige les entreprises à s'enregistrer en tant qu'"émetteurs de factures qualifiées" pour émettre des factures valides pour les crédits de taxe sur la consommation. Auparavant, les entreprises dont les ventes imposables annuelles étaient inférieures à 10 millions de yens étaient exemptées de la taxe sur la consommation. Ce changement a considérablement accru le besoin de tenue de registres financiers précis parmi les petites entreprises et les freelances.
Logiciels de comptabilité japonais
| Logiciel | Statistiques clés | Cible |
|---|---|---|
| freee | ~600 000 abonnés | PME, freelances, startups |
| Money Forward | 27,96 milliards de yens d'ARR SaaS | PME, particuliers |
| Yayoi (弥生) | Comptabilité de bureau n°1 pendant 24 années consécutives | PME, indépendants |
| TKC | Sert ~11 500 cabinets d'experts-comptables | Cabinets d'experts-comptables |
Les trois principales plateformes cloud (freee, Money Forward, Yayoi Online) prennent en charge l'importation CSV des données de transactions bancaires. Les exportations Excel et CSV de PDFSub peuvent être importées directement dans ces outils.
Qui a besoin de la conversion de relevés bancaires japonais ?
Experts-comptables (税理士). Le Japon compte environ 82 276 experts-comptables enregistrés (en décembre 2025). Ils traitent les relevés bancaires des clients pour la comptabilité, la déclaration fiscale et la préparation d'audits. La Fédération Nationale TKC à elle seule compte 11 500 cabinets membres.
Résidents étrangers. En juin 2025, 3,96 millions de résidents étrangers vivaient au Japon — près du double du chiffre de 2012. La plupart des relevés bancaires sont entièrement en japonais sans option anglaise. Les résidents étrangers ont besoin de relevés convertis pour la déclaration fiscale dans leur pays d'origine, le renouvellement de visa et l'envoi de documentation financière à des institutions étrangères.
Freelances déclarant le Blue Return. Les travailleurs indépendants et les freelances qui maintiennent le statut Blue Return (青色申告) doivent tenir des registres comptables détaillés en partie double. La conversion des relevés bancaires en Excel est le point de départ pour catégoriser les dépenses professionnelles et calculer la déduction spéciale de 650 000 ¥.
Entreprises internationales. Les entreprises ayant des filiales japonaises doivent consolider les données bancaires japonaises avec les systèmes comptables mondiaux. Les trois mégabanques servent collectivement de banque principale pour 19,3 % des entreprises japonaises, et la banque d'entreprise passe généralement par BizSTATION de MUFG ou des portails similaires.
Étudiants et titulaires de visas vacances-travail. Le Japon a accueilli plus de 30 millions de visiteurs internationaux en 2024. Les étudiants de longue durée et les titulaires de visas vacances-travail ouvrent des comptes bancaires japonais (souvent à la Japan Post Bank, la plus accessible) et ont besoin de traiter les relevés lors de la gestion de leurs finances ou de la déclaration fiscale dans leur pays d'origine.
Conseils pour travailler avec des données financières japonaises dans Excel
Vérifiez d'abord le mojibake. Si du texte japonais apparaît sous forme de caractères illisibles (ä, â€, é, etc.), le fichier a été ouvert avec le mauvais encodage. Réimportez en utilisant l'encodage Shift_JIS ou utilisez l'exportation Excel UTF-8 de PDFSub pour éviter complètement le problème.
Vérifiez les types de nombres. Après l'importation, testez que les montants sont de vrais nombres : cliquez sur une cellule et vérifiez si Excel affiche un nombre dans la barre de formule, ou essayez =SOMME() sur une colonne. Si SOMME renvoie 0 mais que les cellules affichent des nombres, les valeurs sont du texte pleine chasse se faisant passer pour des nombres.
Comprenez le format à deux colonnes. Les relevés japonais utilisent des colonnes séparées pour 入金 (dépôt) et 出金 (retrait). Si votre analyse nécessite un seul montant signé, créez une formule : =SI(cellule_depot<>"", cellule_depot, -cellule_retrait).
Convertissez les dates d'ère. Si vous recevez des dates d'ère : année Reiwa + 2018 = année grégorienne. Donc 令和8年 = 2026, 令和7年 = 2025. Pour les dates Heisei (avant mai 2019) : année Heisei + 1988 = année grégorienne.
Conservez le PDF original. La loi fiscale japonaise exige la conservation des documents financiers. Pour les déclarants Blue Return, le relevé bancaire original (ou le livret) est une pièce justificative requise. Conservez toujours le PDF à côté de votre fichier Excel converti.
Attention aux caractères de largeur mixte. Si le tri ou le filtrage produit des résultats inattendus, vérifiez la présence de caractères pleine chasse et demi-chasse mixtes dans la même colonne. Un seul espace pleine chasse dans une cellule par ailleurs demi-chasse provoquera des incohérences.
Foire aux questions
Puis-je convertir les relevés MUFG (三菱UFJ銀行) en Excel ?
Oui. MUFG est la plus grande banque du Japon avec environ 57 millions de comptes individuels. PDFSub gère nativement les relevés PDF MUFG, convertissant le formatage japonais — y compris l'encodage Shift_JIS, les noms d'expéditeurs en katakana demi-chasse et les colonnes séparées de dépôt/retrait — en données de tableur propres et encodées en UTF-8.
Comment corriger les caractères japonais illisibles (mojibake) ?
Le mojibake se produit lorsqu'un fichier encodé en Shift_JIS est ouvert en UTF-8 (ou vice versa). PDFSub évite cela entièrement en détectant automatiquement l'encodage et en exportant en UTF-8. Si vous travaillez avec des fichiers CSV bruts, spécifiez l'encodage "Japonais (Shift-JIS)" lors de l'importation dans Excel : Données → Obtenir les données → À partir de texte/CSV → sélectionnez l'encodage.
Les PDF bancaires japonais ont-ils des problèmes d'OCR ?
Les relevés téléchargés depuis la banque en ligne sont des PDF numériques natifs avec du texte sélectionnable — l'extraction est rapide et précise. L'OCR est nécessaire pour les relevés papier numérisés ou les photos de livrets bancaires (通帳の写真). La culture du livret bancaire au Japon fait que de nombreux utilisateurs photographient les pages de leur livret plutôt que de télécharger des PDF. PDFSub gère les deux : PDF numériques et documents numérisés.
Qu'en est-il des entrées de livret bancaire (通帳) ?
Les livrets bancaires physiques sont encore courants au Japon, bien que leur utilisation diminue car les banques facturent des frais pour les nouveaux livrets (MUFG facture 550 ¥/an). Les entrées de livret sont généralement plus abrégées que les PDF de relevés en ligne, ne montrant que des descriptions raccourcies. Si vous photographiez des pages de livret, le mode OCR de PDFSub peut extraire les transactions.
Puis-je exporter des données bancaires japonaises vers freee ou Money Forward ?
PDFSub exporte vers Excel, CSV (UTF-8), QBO, OFX, QFX et JSON. Pour les logiciels de comptabilité japonais (freee, Money Forward, Yayoi), exportez en CSV et importez en utilisant la fonction d'importation de transactions bancaires intégrée au logiciel. Les données correctement encodées et normalisées de PDFSub garantissent une importation propre sans problèmes de mojibake ou de formatage.
Comment gérer les dates à l'ère japonaise (令和) ?
PDFSub convertit automatiquement les dates à l'ère japonaise en dates grégoriennes standard. Pour une conversion manuelle : année Reiwa + 2018 = année grégorienne (令和8年 = 2026, 令和7年 = 2025). Pour les dates Heisei (avant mai 2019) : année Heisei + 1988 = année grégorienne.
Combien de banques japonaises PDFSub prend-il en charge ?
PDFSub prend en charge plus de 20 000 formats bancaires dans le monde, y compris toutes les principales banques japonaises : les trois mégabanques (MUFG, SMBC, Mizuho), Japan Post Bank, Rakuten Bank, les banques régionales dans les 47 préfectures, et les banques conviviales en anglais comme SBI Shinsei et Sony Bank.
Puis-je convertir plusieurs relevés japonais à la fois ?
Oui. Téléchargez plusieurs 取引明細書 (relevés de transactions) et PDFSub les traitera séquentiellement. Chaque relevé est détecté et converti automatiquement indépendamment, même s'ils proviennent de banques différentes avec des mises en page et des conventions d'encodage différentes.
Essayez PDFSub gratuitement pendant 7 jours — accès complet au Convertisseur de relevés bancaires et à plus de 77 autres outils PDF. Annulez à tout moment.