המר דפי בנק יפניים לאקסל (MUFG, SMBC, Mizuho ועוד)

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

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

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

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

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

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

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. תאריכים בסגנון עידן יפני (和暦)

יפן משתמשת בלוח שנה מבוסס עידנים משלה לצד הלוח הגרגוריאני. העידן הנוכחי הוא רייווה (令和), שהחל ב-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. מציע דפי PDF וייצוא CSV דרך בנקאות מקוונת (BizSTATION לתאגידים, 三菱UFJダイレクト ללקוחות פרטיים). ייצוא CSV משתמש בקידוד Shift_JIS.

SMBC (三井住友銀行)

הבנק המסחרי השני בגודלו ביפן עם כ-27 מיליון לקוחות פרטיים. חלק מקבוצת Sumitomo Mitsui Financial. בנקאות מקוונת (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 מטפל בדפי בנק יפניים באופן טבעי — כולל כל אתגרי הקידוד והעיצוב שהוזכרו לעיל.

איך זה עובד

1. העלה את ה-取引明細書 שלך — גרור ושחרר את ה-PDF מכל בנק יפני. PDFSub מזהה אוטומטית את פורמט הבנק מתוך למעלה מ-20,000 תבניות נתמכות.

2. טיפול אוטומטי בפורמט — הממיר באופן אוטומטי:

   • מזהה וממיר קידוד Shift_JIS ל-UTF-8
   • מנרמל מספרים ברוחב מלא (１２３) לרוחב חצי (123) לצורך חישוב
   • ממיר פסיקים, רווחים וסימני פיסוק ברוחב מלא לתווים סטנדרטיים
   • מנתח תאריכי עידן יפניים (令和8年3月2日) לתאריכים סטנדרטיים (2026-03-02)
   • מתרגם שמות בקאטאקנה ברוחב חצי לקאטאקנה קריאה ברוחב מלא
   • ממזג עמודות הפקדה/משיכה או שומר אותן כעמודות נפרדות
   • מזהה טרמינולוגיה בנקאית יפנית (振込, 振替, 口座振替, וכו')

3. בדוק ואמת — בדוק את העסקאות שחולצו בתצוגה המקדימה. יתרות מאומתות מול יתרת הפתיחה והסגירה (残高) של הדף.

4. הורד — ייצא כ-Excel (.xlsx), CSV (UTF-8), QBO (QuickBooks), OFX (Xero, Wave), QFX (Quicken), או JSON.

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

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

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

כל בנק יפני מרכזי נתמך. מהשלושה מגה-בנקים (MUFG, SMBC, Mizuho) ועד Japan Post Bank עם 120 מיליון חשבונות, 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: העתק-הדבק ידני (לא מומלץ)

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

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

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

---

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

מערכת 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 מיליארד ין ARR של SaaS	עסקים קטנים ובינוניים, יחידים
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).

המר תאריכי עידן. אם קיבלת תאריכי עידן: שנת רייווה + 2018 = שנה גרגוריאנית. אז 令和8年 = 2026, 令和7年 = 2025. עבור תאריכי הייסי (לפני מאי 2019): שנת הייסי + 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 ממיר אוטומטית תאריכי עידן יפניים לתאריכים גרגוריאניים סטנדרטיים. להמרה ידנית: שנת רייווה + 2018 = שנה גרגוריאנית (令和8年 = 2026). שנת הייסי + 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 ימים — גישה מלאה ל-ממיר דפי בנק ול-77+ כלי PDF נוספים. בטל בכל עת.