ה-取引明細 (דוח העסקאות) שלך מ-MUFG נראה מובנה בצורה מושלמת ב-PDF. אבל פתח אותו באקסל מחוץ ליפן והבעיות מתחילות: תוויי קאנג'י הופכים ל-mojibake (文字化け) מקולקל, תאריך עידן רייווה "令和8年3月2日" לא אומר כלום לגיליון האקסל שלך באנגלית, שמות שולחים בקאטאקנה ברוחב חצי כמו "ﾔﾏﾀﾞﾀﾛｳ" הופכים לסמלים בלתי קריאים, ומספרים ברוחב מלא "１２３，４５６" לא יחושבו מכיוון שהם תווים שונים ביוניקוד מהמקבילים שלהם ברוחב חצי.

הבעיה המרכזית כאן: בנקאות יפנית פועלת על קידוד תווים ומוסכמות עיצוב שמתבססות על מערכת עם לוקאל יפני. רשת התשלומים הבין-בנקאית Zengin - המעבדת כ-6.5 מיליון עסקאות ו-12 טריליון ין מדי יום - דרשה היסטורית קאטאקנה ברוחב חצי לכל השמות, מורשת שעדיין מופיעה בדוחות בנק מודרניים. כאשר מעבירים את הנתונים האלה למחשב שאינו יפני, שגיאות קידוד כמעט מובטחות.

בין אם אתה תושב זר בטוקיו המעבד דוחות MUFG לצורך דיווח מס למדינת האם, רואה חשבון (zeirishi) המייבא נתוני לקוחות ל-freee או Money Forward, עסק בינלאומי המאחד נתונים מחברה בת יפנית, או פרילנסר המנהל הנהלת חשבונות Blue Return (青色申告) - הבעיה המרכזית זהה: הפקת נתונים מובנים ומוכנים לגיליון אלקטרוני מדוחות בנק יפניים ב-PDF.

מדריך זה מכסה את אתגרי העיצוב הספציפיים של דוחות יפניים, הבנקים העיקריים שתפגוש, וכיצד להמיר אותם במדויק.

Convert Japanese bank statements to Excel - handling kanji, Shift_JIS encoding, and Japanese era dates

למה דוחות בנק יפניים נשברים באקסל

דוחות בנק יפניים יוצרים סט ייחודי של אתגרים שחורגים מעיצוב מספרים פשוט. הבעיות כוללות קידוד תווים, מערכות מספרים, מוסכמות תאריכים, ופורמטים בין-בנקאיים ישנים.

1. קידוד Shift_JIS לעומת UTF-8 (Mojibake)

זו הבעיה הגדולה ביותר עבור כל מי שמעבד נתונים פיננסיים יפניים מחוץ ליפן.

רוב הבנקים היפניים מייצאים קבצי CSV ב-Shift_JIS (קוד דף 932) - תקן קידוד שקדם ל-UTF-8 ומכסה רק תווים יפניים. כאשר אתה פותח קובץ Shift_JIS במערכת שמצפה ל-UTF-8, כל תו יפני הופך למקולקל. ליפנים יש מילה לכך: 文字化け (mojibake), מילולית "שינוי תווים".

מה שאתה אמור לראות	מה ש-UTF-8 מציג
振込カ）ヤマダタロウ	æŒ¯è¾¼ ã‚«ï¼‰ãƒ¤ãƒžãƒ€
三菱UFJ銀行	ä¸‰è±UFJéŠ€è¡Œ
口座振替電気代	å£åº§æŒ¯æ›¿ é›»æ° - ä»£

ההפך גם נכון: קבצי UTF-8 שנפתחים באקסל עם לוקאל יפני עשויים להפיק פלט מקולקל שונה.

הבעיה מורכבת מהעובדה שלקבצי Shift_JIS אין Byte Order Mark (BOM) - אין כותרת שאומרת לתוכנה באיזה קידוד להשתמש. זיהוי אוטומטי אינו אמין, במיוחד כאשר הקובץ מכיל שילוב של תווים יפניים וטקסט לטיני (שכל דוחות הבנק מכילים).

2. תווים ברוחב מלא לעומת ברוחב חצי (全角 vs. 半角)

זהו מאפיין יפני ייחודי שתופס כמעט כל מפתח שאינו יפני לא מוכן.

מחשוב יפני משתמש בשני רוחבים עבור תווים רבים. תווים ברוחב מלא (全角) תופסים את המקום של שני תווים לטיניים; תווים ברוחב חצי (半角) תופסים אחד.

רוחב מלא (全角)	רוחב חצי (半角)	אותו תו?
１２３，４５６	123,456	אותו מספר, בתים שונים
カード	ｶｰﾄﾞ	אותה מילה ("כרטיס"), קידוד שונה
，（קומא）	, (פסיק)	אותו סימן פיסוק, בתים שונים
（רווח）	(רווח)	אותו רווח, בתים שונים

צמצם המכיל "１２３，４５６" (רוחב מלא) נראה זהה ל-"123,456" על המסך, אך אקסל מתייחס לגרסה ברוחב מלא כאל טקסט, לא מספר. אינך יכול לסכום אותו, למיין אותו, או להשתמש בו בנוסחאות. חיפוש והחלפה רגילים עבור פסיקים גם לא יתאימו לפסיקים ברוחב מלא.

דוחות בנק יכולים לערבב רוחבים: סכומים עשויים להיות ברוחב חצי בעוד תיאורים משתמשים בתווים ברוחב מלא. הממיר חייב לנרמל הכל לרוחב חצי עקבי לחישובים.

3. קאטאקנה ברוחב חצי ממערכת Zengin

מערכת הניקוי של תשלומים בין-בנקאית Zengin - עמוד השדרה של התשלומים המקומיים ביפן - דרשה היסטורית שכל השמות יועברו ב-קאטאקנה ברוחב חצי (半角カナ) במגבלה של 20 תווים.

זה יוצר בעיה ספציפית: בדוח הבנק שלך, שם השולח להעברה מופיע כמשהו כמו ﾔﾏﾀﾞﾀﾛｳ במקום 山田太郎 (Yamada Taro). אפילו קוראים יפנים ילידים מוצאים קאטאקנה ברוחב חצי קשה יותר לקריאה.

גרוע מכך: בקאטאקנה ברוחב חצי, סימני עיצורים קוליים (dakuten) הם תווים נפרדים. התו ガ (ga) ברוחב מלא הוא תו יחיד, אך ברוחב חצי הוא הופך לשניים: ｶﾞ (ka + סימן קולי). זה מכפיל את האורך הנראה של שמות המכילים צלילים קוליים ושבור כל עיבוד טקסט שסופר מיקומי תווים.

4. תאריכים בסגנון עידן יפני (和暦)

יפן משתמשת בלוח שנה מבוסס עידנים משלה לצד הלוח הגרגוריאני. העידן הנוכחי הוא Reiwa (令和), שהחל ב-1 במאי 2019.

תאריך עידן יפני	מקביל גרגוריאני
令和8年3月2日	2 במרץ 2026
R8.03.02	2 במרץ 2026
令和7年12月15日	15 בדצמבר 2025

לאקסל באנגלית אין מושג של עידנים יפניים. הוא לא יכול לנתח "令和8年" כשנת 2026. אפילו הפורמט המקוצר "R8.03.02" אינו מוכר.

החדשות הטובות: יפן משתמשת בסדר שנה-חודש-יום (מהגדול לקטן), התואם ל-ISO 8601. כאשר דוחות משתמשים בתאריכים מערביים, הם מופיעים כ-2026/03/02 - פחות דו-משמעי מהפורמט האירופאי DD/MM/YYYY. האתגר הוא אך ורק כאשר משתמשים בתאריכי עידן.

בעיית גבול עידן: דוחות היסטוריים משנת 2019 עשויים לחצות את המעבר מהייסי לרייווה (הייסי הסתיים ב-30 באפריל 2019). באותה שנה, 2019, היא גם הייסי 31 וגם רייווה 1. ממיר חייב לטפל בשני העידנים כראוי.

5. מטבע מספרים שלמים (ללא עשרונים)

לין אין יחידת משנה - אין סנטים. כל הסכומים בדוחות בנק יפניים הם מספרים שלמים: ¥1,234,567 פירושו בדיוק 1,234,567 ין.

זה למעשה מפשט היבט אחד של ההמרה (אין צורך בטיפול בעשרונים) אך מציג אחרים:

מספרים גדולים הם נורמליים. שכר טיפוסי הוא 300,000-500,000 ין לחודש. שכירות עשויה להיות 80,000-200,000 ין. מספרים מגיעים לעיתים קרובות לשש או שבע ספרות.
חשיבה ביחידות של 10,000. יפנים חושבים ביחידות של 万 (מאן, 10,000). שכר של 3,000,000 ין הוא מבחינה מנטלית "300万円". אך דוחות בנק מציגים את המספר המלא.
פסיקים כל 3 ספרות בדוחות - למרות שמערכת המספרים היפנית מקבצת לפי 4 ספרות (万 = 10,000, 億 = 100,000,000). מסמכים פיננסיים עוקבים אחר קונבנציה בינלאומית.

6. עמודות הפקדה ומשיכה נפרדות

בניגוד לדוחות בנק מערביים המשתמשים בעמודת סכום אחת (חיובית לזיכויים, שלילית לחובות), דוחות יפניים משתמשים בדרך כלל בשתי עמודות נפרדות:

入金 (nyūkin) - הפקדות/זיכויים
出金 (shukkin) - משיכות/חובות

עמודה אחת תמיד ריקה עבור כל עסקה. בעת המרה לאקסל, עליך להחליט: לשמור על פורמט שתי העמודות, או למזג לעמודת סכום חתומה אחת? כל בחירה דורשת מהממיר להבין את מבנה העמודות היפני.

בנקים יפניים עיקריים והדוחות שלהם

MUFG (三菱UFJ銀行)

הבנק הגדול ביפן לפי נכסים (~2.9 טריליון דולר) עם כ-57 מיליון חשבונות הפקדה פרטיים. חלק מקבוצת Mitsubishi UFJ Financial Group. מציע דוחות PDF וייצוא CSV דרך בנקאות מקוונת (BizSTATION לתאגידים, 三菱UFJダイレクト לקמעונאים). ייצוא CSV משתמש בקידוד Shift_JIS.

SMBC (三井住友銀行)

הבנק המסחרי השני בגודלו ביפן עם כ-27 מיליון לקוחות קמעונאיים. חלק מקבוצת Sumitomo Mitsui Financial Group. בנקאות מקוונת (SMBCダイレクト) מספקת הורדות PDF ו-CSV.

Mizuho (みずほ銀行)

מגה-בנק שלישי עם כ-24 מיליון לקוחות קמעונאיים ו-12.6 מיליון מנויי בנקאות מקוונת. בנקאות מקוונת (みずほダイレクト) מציעה הורדות עסקאות.

Japan Post Bank (ゆうちょ銀行)

הגדול ביותר לפי מספר חשבונות עם כ-120 מיליון חשבונות לקוחות ולמעלה מ-205 טריליון ין בנכסים כוללים. פועל דרך כ-24,000 סניפים (בעיקר סניפי דואר חוזיים). מגיע כמעט לכל רשות מקומית ביפן. אפליקציית "Yucho Tsucho" מספקת גישה לפנקס דיגיטלי. מערכת מספור חשבונות ייחודית השונה ממספרי חשבון בנק יפניים סטנדרטיים.

Rakuten Bank (楽天銀行)

הבנק המקוון הגדול ביפן עם 17.6+ מיליון חשבונות והפקדות העולות על 13 טריליון ין. ההפקדות גדלו ב-16.5% בשנה בהשוואה ל-3.8% עבור מגה-בנקים. דיגיטלי לחלוטין עם יכולת ייצוא CSV.

בנקים אזוריים (地方銀行)

ביפן יש כ-97 בנקים אזוריים - 61 בנקים מדרגה ראשונה ו-36 בנקים מדרגה שנייה. כל מחוז בדרך כלל יש לפחות בנק אזורי אחד שמשרדו הראשי בעיר הבירה שלו. דוגמאות: Yokohama Bank (横浜銀行), Chiba Bank (千葉銀行), Shizuoka Bank (静岡銀行). פורמטים של דוחות משתנים באופן משמעותי בין בנקים אזוריים.

SBI Shinsei Bank / Sony Bank

SBI Shinsei Bank ו-Sony Bank בולטים בכך שהם מציעים בנקאות מקוונת בשפה האנגלית - נדיר ביפן. פופולריים בקרב תושבים זרים מסיבה זו. שניהם מספקים ייצוא PDF ו-CSV.

שיטה 1: שימוש ב-PDFSub (מומלץ)

PDFSub מטפל בדוחות בנק יפניים באופן טבעי - כולל כל אתגרי הקידוד והעיצוב שלעיל.

Step-by-step process for converting Japanese bank statements with PDFSub

איך זה עובד

העלה את ה-取引明細書 שלך - גרור ושחרר את ה-PDF מכל בנק יפני. PDFSub מזהה אוטומטית את פורמט הבנק מתוך למעלה מ-20,000 תבניות נתמכות.
טיפול אוטומטי בפורמט - הממיר באופן אוטומטי: - מזהה וממיר קידוד Shift_JIS ל-UTF-8 - מנרמל מספרים ברוחב מלא (１２３) לחצי רוחב (123) לחישוב - ממיר פסיקים, רווחים וסימני פיסוק ברוחב מלא לתווים סטנדרטיים - מנתח תאריכי עידן יפניים (令和8年3月2日) לתאריכים סטנדרטיים (2026-03-02) - מתרגם שמות שולחים בקאטאקנה ברוחב חצי לקאטאקנה קריא ברוחב מלא - ממזג עמודות הפקדה/משיכה או שומר אותן כעמודות נפרדות - מזהה טרמינולוגיה בנקאית יפנית (振込, 振替, 口座振替, וכו')
בדוק ואמת - בדוק את העסקאות שחולצו בתצוגה המקדימה. יתרות מאומתות מול יתרת הפתיחה והסגירה (残高) של הדוח.
הורד - ייצא כ-Excel (.xlsx), CSV (UTF-8), QBO (QuickBooks), OFX (Xero, Wave), QFX (Quicken), או JSON.

למה PDFSub עובד עבור דוחות יפניים

130+ שפות כולל יפנית. מנוע החילוץ מבין טרמינולוגיה בנקאית יפנית - 振込, 振替, 入金, 出金, 口座振替, 手数料, 利息 - וממפה אותם לשדות מובנים.

קידוד מטופל אוטומטית. אין צורך לזהות או להמיר ידנית בין Shift_JIS ל-UTF-8. PDFSub מזהה את הקידוד ומנרמל הכל ל-UTF-8 עם טיפול נכון בקאנג'י, היראגאנה, קאטאקנה ותווים ברוחב מעורב.

כל בנק יפני עיקרי נתמך. מהשלושה מגה-בנקים (MUFG, SMBC, Mizuho) ועד ל-120 מיליון החשבונות של Japan Post Bank, Rakuten Bank, בנקים אזוריים בכל 47 המחוזות, ובנקים ידידותיים לאנגלית כמו SBI Shinsei ו-Sony Bank.

פרטיות בדפדפן תחילה. עבור קבצי PDF דיגיטליים מבנקאות מקוונת, חילוץ טקסט מתבצע כולו בדפדפן שלך. הקובץ לעולם לא עוזב את המכשיר שלך. עיבוד בצד השרת משמש רק למסמכים סרוקים או תצלומי פנקסי בנק.

נורמליזציה של רוחב מלא. מספרים, פסיקים, רווחים וסימני פיסוק מנורמלים כולם מרוחב מלא לחצי רוחב באופן אוטומטי - מבטיח שסכומים יטופלו כמספרים, לא כטקסט, בגיליון האלקטרוני שלך.

שיטה 2: ייצוא CSV של הבנק שלך

רוב הבנקים היפניים הגדולים מציעים הורדות עסקאות CSV דרך בנקאות מקוונת. הנה מה לצפות:

מה תקבל

קידוד: כמעט תמיד Shift_JIS (לא UTF-8)
מפריד: פסיק סטנדרטי (,)
פורמט תאריך: בדרך כלל YYYY/MM/DD (מערבי) ב-CSV, אם כי בנקים מסוימים משתמשים בתאריכי עידן
עמודות: בדרך כלל 日付 (תאריך), 摘要 (תיאור), 入金額 (הפקדה), 出金額 (משיכה), 残高 (יתרה)

מגבלות

קידוד Shift_JIS. פתיחת ה-CSV בכל מערכת שאינה יפנית מפיקה טקסט מקולקל. עליך להגדיר במפורש את הקידוד בעת הייבוא: באקסל, השתמש ב-Data → Get Data → From Text/CSV → בחר קידוד "Japanese (Shift-JIS)".

שמות בקאטאקנה ברוחב חצי. שמות שולחים/נמענים יופיעו בקאטאקנה ברוחב חצי ממערכת Zengin. אלה קשים לקריאה אפילו לדוברי יפנית שפת אם ובלתי אפשריים למי שאינו דובר.

היסטוריה מוגבלת. ייצוא CSV מבנקאות מקוונת מכסה בדרך כלל 3-12 חודשים. היסטוריה ארוכה יותר דורשת הורדת דוחות לכל תקופה בנפרד.

אין פורמט סטנדרטי. בניגוד לתקנים הגרמניים CAMT.053/MT940 או הצרפתיים CAMT.053/FEC, לקבצי CSV של בנקים יפניים אין פורמט אוניברסלי. כל בנק משתמש בסדר עמודות, שמות ומבנה משלו.

תווים ברוחב מלא בתיאורים. תיאורי עסקאות עשויים להכיל מספרים וסימני פיסוק ברוחב מלא הדורשים נורמליזציה לפני ניתוח.

שיטה 3: העתק-הדבק ידני (לא מומלץ)

הבעיות חמורות עם דוחות יפניים:

תווים של קאנג'י וקאטאקנה עשויים לא להיות מודבקים כראוי בין יישומים
המרת קידוד נכשלת בשקט - תווים שנראים תקינים עשויים להיות נקודות קוד Unicode שגויות
מספרים ברוחב מלא מודבקים כטקסט שלא ניתן לחשב
שמות בקאטאקנה ברוחב חצי מודבקים אך אינם קריאים במערכות שאינן יפניות
לתאריכי עידן אין המרה אוטומטית לתאריכים גרגוריאניים באקסל באנגלית
עמודות הפקדה/משיכה נפרדות דורשות מיזוג ידני
אין אימות מול יתרות פתיחה/סגירה

עבור כל נפח של עסקאות, גישה זו אינה מעשית.

מערכות פיננסיות יפניות שכדאי להכיר

מערכת Zengin (全銀システム)

רשת הניקוי המרכזית לתשלומים פנים-ארציים ביפן, הוקמה בשנת 1973. מחברת כמעט את כל הבנקים הפרטיים ביפן, ומעבדת כ-6.5 מיליון עסקאות ביום בסך של כ-12 טריליון ין.

פורמט הקובץ Zengin משתמש ברשומות קבועות-רוחב של 120 בתים עם קידוד קאטאקנה ברוחב חצי לשמות. פורמט מורשת זה הוא הסיבה ששמות שולחים/נמענים בדוחות בנק מופיעים בקאטאקנה ברוחב חצי במקום בקאנג'י. מערכת ZEDI החדשה יותר (Zengin EDI) תומכת בקאנג'י מלא ועוברת להודעות XML תואמות ISO 20022, אך הפורמט המורשת נמשך בדוחות רבים.

Blue Return (青色申告) לעומת White Return (白色申告)

דיווח מס ביפן כולל שני רמות:

מאפיין	Blue Return (青色申告)	White Return (白色申告)
בקשה	יש להגיש מראש	סטטוס ברירת מחדל
הנהלת חשבונות	רישום כפול מפורט	הכנסות/הוצאות פשוטות
ניכוי מיוחד	עד 650,000 ¥ (עם e-Tax)	אין
העברת הפסדים	כן, עד 3 שנים	לא

מגישי Blue Return - המקבלים את ניכוי המס הגדול יותר - נדרשים לנהל רשומות פיננסיות מפורטות, מה שהופך המרה מדויקת של דוחות בנק לחיונית להנהלת החשבונות שלהם.

מערכת חשבוניות מוסמכות (インボイス制度)

הושקה ב-1 באוקטובר 2023, מערכת זו דורשת מעסקים להירשם כ"מנפיקי חשבוניות מוסמכות" כדי להנפיק חשבוניות תקפות עבור זיכוי מס צריכה. בעבר, עסקים עם מכירות חייבות במס שנתיות מתחת ל-10 מיליון ין היו פטורים ממס צריכה. שינוי זה הגדיל משמעותית את הצורך ברישום פיננסי מדויק בקרב עסקים קטנים ופרילנסרים.

תוכנות הנהלת חשבונות יפניות

תוכנה	נתונים עיקריים	קהל יעד
freee	~600,000 מנויים	עסקים קטנים ובינוניים, פרילנסרים, סטארט-אפים
Money Forward	27.96 מיליארד ין SaaS ARR	עסקים קטנים ובינוניים, יחידים
Yayoi (弥生)	הנהלת חשבונות דסקטופ מספר 1 במשך 24 שנים רצופות	עסקים קטנים ובינוניים, עצמאים
TKC	משרת כ-11,500 משרדי רואי חשבון	משרדי רואי חשבון

כל שלוש הפלטפורמות הענן העיקריות (freee, Money Forward, Yayoi Online) תומכות בייבוא CSV של נתוני עסקאות בנקאיות. ייצוא ה-Excel וה-CSV של PDFSub יכולים להיות מיובאים ישירות לכלים אלה.

מי צריך המרת דוחות בנק יפניים?

רואי חשבון (税理士). ביפן יש כ-82,276 רואי חשבון רשומים (נכון לדצמבר 2025). הם מעבדים דוחות בנק של לקוחות להנהלת חשבונות, דיווח מס והכנה לביקורת. פדרציית TKC הלאומית לבדה מונה 11,500 משרדים חברים.

תושבים זרים. נכון ליוני 2025, 3.96 מיליון תושבים זרים חיים ביפן - כמעט כפול מהנתון של 2012. לרוב דוחות הבנק הם ביפנית בלבד ללא אפשרות באנגלית. תושבים זרים זקוקים לדוחות מומרים לצורך דיווח מס למדינת האם, חידוש ויזה, ושליחת מסמכים פיננסיים למוסדות בחו"ל.

פרילנסרים המגישים Blue Returns. עובדים עצמאיים ופרילנסרים השומרים על סטטוס Blue Return (青色申告) חייבים לנהל רשומות הנהלת חשבונות מפורטות ברישום כפול. המרת דוחות בנק לאקסל היא נקודת ההתחלה לקטלוג הוצאות עסקיות וחישוב הניכוי המיוחד של 650,000 ¥.

עסקים בינלאומיים. חברות עם חברות בנות יפניות צריכות לאחד נתונים בנקאיים יפניים עם מערכות הנהלת חשבונות גלובליות. שלושת המגה-בנקים משמשים כבנק הראשי עבור 19.3% מהחברות היפניות, ובנקאות תאגידית פועלת בדרך כלל דרך BizSTATION של MUFG או פורטלים דומים.

סטודנטים ובעלי ויזות חופשת עבודה. יפן ראתה למעלה מ-30 מיליון מבקרים בינלאומיים בשנת 2024. סטודנטים לטווח ארוך ובעלי ויזות חופשת עבודה פותחים חשבונות בנק יפניים (לעתים קרובות ב-Japan Post Bank, הנגיש ביותר) וצריכים לעבד דוחות בעת ניהול כספים או דיווח מס במדינות המוצא שלהם.

טיפים לעבודה עם נתונים פיננסיים יפניים באקסל

בדוק קודם כל mojibake. אם טקסט יפני כלשהו מופיע כתווים מקולקלים (Ã¤, â€, Ã©, וכו'), הקובץ נפתח עם הקידוד הלא נכון. ייבא מחדש תוך שימוש בקידוד Shift_JIS או השתמש בייצוא Excel ב-UTF-8 של PDFSub כדי להימנע מהבעיה לחלוטין.

אמת סוגי מספרים. לאחר הייבוא, בדוק שסכומים הם מספרים אמיתיים: לחץ על צמצם ובדוק אם אקסל מציג מספר בשורת הנוסחאות, או נסה =SUM() על עמודה. אם SUM מחזיר 0 אך הצמצמים מציגים מספרים, הערכים הם טקסט ברוחב מלא המתחפש למספרים.

הבן את פורמט שתי העמודות. דוחות יפניים משתמשים בעמודות נפרדות 入金 (הפקדה) ו- 出金 (משיכה). אם הניתוח שלך דורש סכום חתום יחיד, צור נוסחה: =IF(deposit_cell<>"", deposit_cell, -withdrawal_cell).

המר תאריכי עידן. אם קיבלת תאריכי עידן: שנת Reiwa + 2018 = שנה גרגוריאנית. אז 令和8年 = 2026, 令和7年 = 2025. עבור תאריכי Heisei (לפני מאי 2019): שנת Heisei + 1988 = שנה גרגוריאנית.

שמור את ה-PDF המקורי. חוק המס היפני דורש שמירת רשומות פיננסיות. עבור מגישי Blue Return, דוח הבנק המקורי (או פנקס הבנק) הוא מסמך נדרש. תמיד שמור את ה-PDF לצד קובץ האקסל המומר שלך.

שים לב לתווים ברוחב מעורב. אם מיון או סינון מפיקים תוצאות בלתי צפויות, בדוק תווים ברוחב מלא וחצי רוחב מעורבים באותה עמודה. רווח בודד ברוחב מלא בתא שכל השאר בו ברוחב חצי יגרום לאי-התאמות.

שאלות נפוצות

האם ניתן להמיר דוחות MUFG (三菱UFJ銀行) לאקסל?

כן. MUFG הוא הבנק הגדול ביפן עם כ-57 מיליון חשבונות פרטיים. PDFSub מטפל בדוחות PDF של MUFG באופן טבעי, ממיר את הפורמט היפני - כולל קידוד Shift_JIS, שמות שולחים בקאטאקנה ברוחב חצי, ועמודות הפקדה/משיכה נפרדות - לנתוני גיליון אלקטרוני נקיים ומקודדי UTF-8.

איך לתקן תווים יפניים מקולקלים (mojibake)?

Mojibake מתרחש כאשר קובץ מקודד Shift_JIS נפתח כ-UTF-8 (או להיפך). PDFSub נמנע מכך לחלוטין על ידי זיהוי הקידוד אוטומטית וייצוא ב-UTF-8. אם אתה עובד עם קבצי CSV גולמיים, ציין את קידוד "Japanese (Shift-JIS)" בעת הייבוא לאקסל: Data → Get Data → From Text/CSV → בחר את הקידוד.

האם לקבצי PDF של בנקים יפניים יש בעיות OCR?

דוחות שהורדו מבנקאות מקוונת הם קבצי PDF דיגיטליים מקוריים עם טקסט בר בחירה - החילוץ מהיר ומדויק. OCR נדרש עבור דוחות נייר סרוקים או תצלומי פנקסי בנק (通帳の写真). תרבות פנקסי הבנק ביפן גורמת למשתמשים רבים לצלם את דפי פנקס הבנק שלהם במקום להוריד קבצי PDF. PDFSub מטפל גם בקבצי PDF דיגיטליים וגם במסמכים סרוקים.

מה לגבי רשומות פנקס בנק (通帳)?

פנקסי בנק פיזיים עדיין נפוצים ביפן, אם כי השימוש בהם יורד מכיוון שבנקים גובים עמלות עבור פנקסים חדשים (MUFG גובה 550 ¥ לשנה). רשומות פנקס בנק הן בדרך כלל מקוצרות יותר מדוחות PDF מקוונים, ומציגות רק תיאורים מקוצרים. אם אתה מצלם דפי פנקס בנק, מצב ה-OCR של PDFSub יכול לחלץ את העסקאות.

האם ניתן לייצא נתונים מבנק יפני ל-freee או Money Forward?

PDFSub מייצא ל-Excel, CSV (UTF-8), QBO, OFX, QFX ו-JSON. עבור תוכנות הנהלת חשבונות יפניות (freee, Money Forward, Yayoi), ייצא ל-CSV וייבא באמצעות תכונת ייבוא עסקאות בנקאיות המובנית בתוכנה. הנתונים המקודדים כראוי והמנורמלים מ-PDFSub מבטיחים ייבוא נקי ללא בעיות mojibake או עיצוב.

איך לטפל בתאריכי עידן יפניים (令和)?

PDFSub ממיר אוטומטית תאריכי עידן יפניים לתאריכים גרגוריאניים סטנדרטיים. להמרה ידנית: שנת Reiwa + 2018 = שנה גרגוריאנית (令和8年 = 2026). שנת Heisei + 1988 = שנה גרגוריאנית (平成31年 = 2019). העידנים השתנו ב-1 במאי 2019.

כמה בנקים יפניים PDFSub תומך בהם?

PDFSub תומך ביותר מ-20,000 פורמטים של בנקים ברחבי העולם, כולל כל הבנקים היפניים העיקריים: שלושת המגה-בנקים (MUFG, SMBC, Mizuho), Japan Post Bank, Rakuten Bank, בנקים אזוריים בכל 47 המחוזות, ובנקים ידידותיים לאנגלית כמו SBI Shinsei ו-Sony Bank.

האם ניתן להמיר מספר דוחות יפניים בבת אחת?

כן. העלה מספר取引明細書 (דוחות עסקאות) ו-PDFSub יעבד אותם ברצף. כל דוח מזוהה ומומר אוטומטית באופן עצמאי, גם אם הם מבנקים שונים עם פריסות ומוסכמות קידוד שונות.

נסה את PDFSub בחינם למשך 7 ימים - גישה מלאה ל-ממיר דוחות בנק ול-84+ כלי PDF נוספים בחבילת All-In-One (20 $/משתמש/חודש שנתי). בטל בכל עת.