הבנת פורמטים של דפי בנק: המדריך הטכני

דף בנק בפורמט PDF נראה פשוט: תאריכים, תיאורים, סכומים, יתרות בעמודות מסודרות. אך מאחורי המראה הזה מסתתר פורמט מסמך (PDF) שלעולם לא תוכנן לאחסון נתונים מובנים - ותהליך המרה הדורש הבנה הן של פורמט הקלט והן של פורמטי הפלט הרבים הזמינים.

מדריך זה מכסה את 12 הסעיפים המופיעים בכל דף בנק (ללא קשר לבנק), המציאות הטכנית של דפי בנק בפורמט PDF, וריאציות הפריסה בין בנקים, כל פורמט פלט שתפגוש (Excel, CSV, QBO, OFX, QFX, QIF, JSON), הבדלים בעיצוב בינלאומי, והתקנים התעשייתיים המסדירים את חילופי נתונים פיננסיים.

אנטומיה של דף בנק

כל דף בנק - Chase, Bank of America, Wells Fargo, HSBC, Deutsche Bank, לא משנה איזה - בנוי מ-12 הסעיפים זהים. התוויות משתנות ("הוצאות" לעומת "משיכות"), סידורי העמודות משתנים, אך המבנה הבסיסי עקבי. ברגע שתוכל לזהות את הסעיפים הללו, כל דף ייראה מוכר.

רוצה להשתמש באינפוגרפיקה הזו בבלוג שלך? העתק את קוד ההטמעה:

לצלילה עמוקה ספציפית לבנקים, המכסה בדיוק כיצד כל בנק מרכזי מסדר את 12 הסעיפים הללו, ראה:

• הסבר על דף בנק של Chase
• הסבר על דף בנק של Bank of America
• הסבר על דף בנק של Wells Fargo
• הסבר על דף בנק של Citi
• הסבר על דף בנק של Capital One

מדוע PDF אינו פורמט נתונים

PDF מייצג Portable Document Format, שעוגן בתקן ISO 32000 (גרסה 2.0 הפכה ל-ISO 32000-2:2020). הוא תוכנן למטרה אחת: לגרום למסמכים להיראות זהים בכל מסך ומדפסת. זה מצוין לנאמנות ויזואלית - ונורא לחילוץ נתונים.

מה באמת נמצא בתוך דף בנק בפורמט PDF

בתוך כל דף PDF נמצא זרם תוכן (content stream) - רצף של פקודות ציור הכתובות בשפה דמוית PostScript. טקסט מוצג באמצעות פקודות ספציפיות:

• BT / ET - התחל טקסט / סיים טקסט: גבולות של אובייקט טקסט
• Tf - הגדר גופן וגודל
• Td / Tm - הזז מיקום טקסט או הגדר את מטריצת הטרנספורמציה המלאה של הטקסט
• Tj - הצג מחרוזת טקסט
• TJ - הצג טקסט עם מיקום גליפים אינדיבידואלי (התאמות רווחים)

התובנה הקריטית: אין מושג של "טבלה", "שורה" או "עמודה" במפרט ה-PDF. מה שנראה כמו טבלת עסקאות מעוצבת להפליא הוא למעשה עשרות מקטעי טקסט הממוקמים בקואורדינטות x,y ספציפיות בדף. כלי החילוץ חייב:

1. לנתח את פקודות זרם התוכן
2. לפתור קידודי גופנים כדי למפות אינדקסים של גליפים לתווי Unicode
3. להשתמש במטריצת הטקסט (Tm/Td) כדי לקבוע את מיקום ה-x,y של כל תו
4. לשחזר מילים, שורות ועמודות מהקואורדינטות הללו

עמודה שנראית מיושרת באופן מושלם עשויה להיות ב-x=72.0 בשורה אחת וב-x=72.5 בשורה הבאה. אלגוריתם החילוץ חייב להגדיר גבולות עמודות עם סובלנות לווריאציות תת-פיקסל אלו.

PDF מתויגים לעומת PDF לא מתויגים

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

PDF לא מתויגים אין מטא-נתונים מבניים - כלי החילוץ מקבל רק נתוני מיקום גולמיים וחייב להסיק הכל.

רוב דפי הבנק המוצגים ב-PDF אינם מתויגים. בנקים מייצרים דפי חשבון באמצעות מערכות עיבוד אצווה (Oracle BI Publisher, SAP Crystal Reports, או צינורות הדפסה ל-PDF מותאמים אישית). תקנות נגישות (ADA/WCAG) דוחפות בנקים ל-PDF מתויגים, אך האימוץ איטי. הורדות סטנדרטיות מרוב הבנקים הגדולים נשארות לא מתויגות.

וריאציות פריסה של דפי בנק

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

עמודת סכום יחידה (עם סימן)

תאריך תיאור סכום יתרה
15/01/26 משכורת הפקדה ישירה  +3,500.00 5,200.00
16/01/26 רכישת סופרמרקט POS -87.50 5,112.50

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

עמודות חיוב/זיכוי נפרדות

תאריך תיאור משיכות הפקדות יתרה
15/01/26 משכורת הפקדה ישירה 3,500.00 5,200.00
16/01/26 רכישת סופרמרקט POS 87.50 5,112.50

בשימוש על ידי Chase, Bank of America, ובנקים מסורתיים רבים. כלי החילוץ חייב לזהות איזו עמודה מכילה את הסכום ולקבוע את הסימן בהתאם.

מקובץ לפי סוג עסקה

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

הפקדות וזיכויים אחרים 15/01  העברת בנק נכנסת REF#12345 10,000.00 18/01  הפקדת צ'ק #4567 2,500.00 סה"כ הפקדות 12,500.00
 
צ'קים ששולמו 16/01  צ'ק #1234 850.00 17/01  צ'ק #1235 1,200.00 סה"כ צ'קים ששולמו 2,050.00
 
עסקאות אלקטרוניות 19/01  תשלום ACH - חברת ספק 3,200.00 20/01  העברה מקוונת לחשבון חיסכון 1,000.00 סה"כ אלקטרוני 4,200.00

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

מאפיינים ספציפיים לבנק

• Chase - עמודות חיוב/זיכוי נפרדות; מקבץ לפי "הפקדות ותוספות" ו-"תשלומים אלקטרוניים" ו-"עמלות"; תיאורים מרובי שורות נפוצים עבור פרטי סוחר
• Bank of America - עמודות משיכה/הפקדה נפרדות; כולל סעיף "יתרה יומית" בסוף; כותרת מקיפה עם מספר חשבון, תקופת דוח, מספר ניתוב
• Wells Fargo - עמודות נפרדות; כולל סעיף "סיכום יתרה יומית"; קורא להורדת ה-CSV שלו "Comma Delimited"
• Capital One - פריסה נקייה של סכום יחיד עבור כרטיסי צרכנים; מידע כותרת מינימלי
• Citi - לעיתים קרובות כולל פרטי עסקאות בינלאומיות עם סכומים במטבע מקורי ושערי המרה בשורות נפרדות

וריאציות סידור עמודות

מעבר לשאלת החיוב/זיכוי, סדר העמודות אינו סטנדרטי:

• סדר עמודות: תאריך-תיאור-סכום-יתרה לעומת תאריך-סכום-תיאור-יתרה
• מספר צ'ק: קיים בחשבונות עסקיים, נעדר בחשבונות אישיים
• מספר סימוכין: נפוץ בדוחות עסקיים, נדיר בדוחות אישיים
• יתרה מתגלגלת: לכל עסקה (הנפוץ ביותר) לעומת סיכומי יום לעומת נעדר לחלוטין

PDF דיגיטלי לעומת סרוק

הגורם החשוב ביותר המשפיע על דיוק ההמרה הוא האם ה-PDF שלך דיגיטלי או סרוק.

PDF דיגיטלי (מקור)

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

• דיוק: 99%+ לחילוץ טקסט - ללא שגיאות זיהוי
• מהירות: מילי-שניות לדף
• פרטיות: ניתן לעבד לחלוטין בדפדפן שלך - הקובץ לעולם לא עוזב את המכשיר שלך
• גודל קובץ: בדרך כלל 50KB–500KB לדף
• כיצד לזהות: ניתן לבחור ולהדגיש מילים בודדות

PDF סרוק תמונות של דפי חשבון פיזיים - נוצר על ידי סריקה או צילום של מסמך פיזי. התוכן מאוחסן כתמונות רסטר (JPEG, JPEG2000, CCITT, או דחוס Flate).

• דיוק: 95–99% עם OCR מקצועי; 65–70% עם OCR כללי
• מהירות: שניות לדף (דורש עיבוד תמונה)
• פרטיות: בדרך כלל דורש עיבוד בצד השרת (יש להעלות את הקובץ ל-OCR)
• גודל קובץ: 200KB–2MB+ לדף
• כיצד לזהות: לא ניתן לבחור טקסט כלשהו; התקרבות ל-400% מראה פיקסליזציה

מדוע דיוק OCR חשוב יותר לנתונים פיננסיים

שיעור דיוק תווים של 97% נשמע מצוין עד שתחיל אותו על נתונים פיננסיים. בדף חשבון עם 1,000 תווים של סכומים, זה 30 תווים שנקראו לא נכון. ספרה אחת שנקראה לא נכון משנה סכום עסקה: "1,234.56$" הופך ל-"1,234.86$" או "7,234.56$". OCR מתקדם משיג דיוק של כמעט 99%, אך השגיאות הנותרות נופלות באופן לא פרופורציונלי על תווים דומים: 0/O, 1/l/I, 5/S, 8/B, 6/G, ובאופן קריטי, פסיק/נקודה.

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

פורמטי פלט: צלילה עמוקה

כשאתה ממיר דף בנק, אתה בוחר פורמט פלט. לכל פורמט יש חוזקות, מגבלות ומקרי שימוש אידיאליים שונים.

Excel (.xlsx)

תקן: Office Open XML (OOXML), שעוגן בתקן ECMA-376 ו-ISO/IEC 29500.

מה זה: קובץ .xlsx הוא למעשה ארכיון ZIP המכיל קבצי XML - מבנה חוברת עבודה, נתוני תאים, סגנונות ומחרוזות משותפות. זו הסיבה שהוא יכול לאחסן סוגי נתונים (תאריכים כתאריכים, מספרים כמספרים), עיצוב, נוסחאות, וגיליונות מרובים.

מדוע הוא פופולרי עבור דפי בנק:

• תאריכים נשארים תאריכים (ניתנים למיון, לסינון)
• מספרים נשארים מספרים (ניתנים לסיכום, לעיצוב)
• נוסחאות ליישוב (SUM, VLOOKUP)
• טבלאות ציר לסיווג הוצאות
• עיצוב מותנה להדגשת אי-התאמות
• שיתוף עם לקוחות הזקוקים לגיליון אלקטרוני קריא

מגבלות:

• מקסימום 1,048,576 שורות (נדיר רלוונטי לדפי בנק)
• לא ניתן לייבא ישירות לרוב תוכנות הנהלת החשבונות (השתמשו ב-QBO/OFX במקום)
• דורש Excel, Google Sheets, או LibreOffice Calc לפתיחה

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

CSV (ערכים מופרדים בפסיק)

תקן: RFC 4180 (2005) - "פורמט נפוץ וסוג MIME עבור ערכים מופרדים בפסיק."

כללי ליבה:

• רשומות מופרדות על ידי CRLF (החזרת כרכרה + שורה חדשה)
• שדות מופרדים בפסיקים
• שדות המכילים פסיקים, מרכאות או שורות חדשות חייבים להיות עטופים במרכאות כפולות
• מרכאות כפולות בתוך שדות מוכפלות כדי לברוח מהן

וריאציות מפרידים בשימוש:

• פסיק (,) - תקן, בשימוש בארה"ב/בריטניה
• נקודה-פסיק (;) - בשימוש במדינות בהן הפסיק הוא מפריד עשרוני (צרפת, גרמניה, איטליה, ספרד, ברזיל)
• טאב (\t) - פורמט TSV, נמנע מקונפליקטים של מפרידים

בעיות קידוד:

• UTF-8 מומלץ לתאימות
• UTF-8 BOM (סימן סדר בתים): אינו נדרש על פי התקן, אך Excel ב-Windows דורש אותו כדי להציג כראוי תווים שאינם ASCII (אותיות עם סימני דיאקריטיים, סמלי מטבע). ללא BOM, Excel עשוי לפרש UTF-8 כ-Windows-1252, מה שמשחית תווים.
• Excel משתמש בנקודות-פסיק במקום בפסיקים כמפרידי שדות במקומות אירופאיים

מגבלות:

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

הכי טוב עבור: תאימות מקסימלית - כמעט כל תוכנת הנהלת חשבונות, מסד נתונים וגיליון אלקטרוני יכולים לייבא CSV. פתרון גיבוי אוניברסלי כאשר QBO/OFX אינם זמינים.

QBO (QuickBooks Web Connect)

מה זה: פורמט הייבוא עבור QuickBooks (גם Desktop וגם Online). קבצי QBO מבוססים על מפרט OFX עם הרחבות ספציפיות ל-QuickBooks.

הבהרה חשובה: ".QBO" אינו אומר "QuickBooks Online" - הוא מייצג את פורמט QuickBooks Web Connect ועובד עם QuickBooks Desktop וגם עם QuickBooks Online.

שדות נדרשים לכל עסקה:

• TRNTYPE - סוג עסקה (DEBIT, CREDIT, CHECK, DEP, DIRECTDEP, DIRECTDEBIT, ATM, POS, XFER, PAYMENT, FEE, SRVCHG, INT, OTHER)
• DTPOSTED - תאריך בפורמט YYYYMMDD
• TRNAMT - סכום (שלילי לחיובים)
• FITID - מזהה עסקה של המוסד הפיננסי
• NAME - מוטב/תיאור

מדוע FITID חשוב: QuickBooks עוקב אחר כל FITID שייובא אי פעם עבור כל חשבון. אם עסקה עם אותו FITID מיובאת שוב, QuickBooks מדלג עליה בשקט - מונע כניסות כפולות כאשר משתמשים מייבאים מחדש תקופות דוח חופפות. זיהוי כפילויות אוטומטי זה הוא היתרון הגדול ביותר של QBO על פני CSV.

נתונים נוספים: QBO נושא גם מזהה חשבון, מזהה בנק (מספר ניתוב), מטבע, מספר צ'ק, תזכיר, ויתרה סופית - מאגר הנתונים העשיר ביותר מכל פורמט ייבוא עבור QuickBooks.

הכי טוב עבור: משתמשי QuickBooks (Desktop ו-Online). מספק את חווית הייבוא העשירה ביותר עם זיהוי כפילויות אוטומטי וסיווג סוגי עסקאות.

OFX (Open Financial Exchange)

היסטוריה: נוצר על ידי Microsoft, Intuit ו-CheckFree. גרסה 1.0 שוחררה בפברואר 1997.

התפתחות גרסאות:

• OFX 1.0–1.6 (1997–1999): תחביר מבוסס SGML (אין צורך בתגיות סגירה)
• OFX 2.0+ (2000–הווה): מבוסס XML (תגיות סגירה תקינות, XML תקין).

בנקים רבים עדיין מייצרים OFX 1.x (SGML) לתאימות מקסימלית.

ממשל נוכחי: בשנת 2019, קונסורציום OFX התמזג לתוך קונסורציום Financial Data Exchange (FDX), אשר מנהל כעת את המפרט. ל-FDX יש למעלה מ-200 ארגוני חבר ו-76 מיליון חשבונות צרכנים.

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

הכי טוב עבור משתמשי Xero: Xero מייבא אוטומטית קבצי OFX ללא צורך במיפוי עמודות ידני. העלו את הקובץ והעסקאות יופיעו מיד עם תאריכים, סכומים ותיאורים נכונים. עובד גם עם Wave, Sage, FreshBooks, ורוב תוכנות הנהלת החשבונות.

QFX (Quicken Financial Exchange)

מה זה: וריאנט קנייני של OFX של Intuit, המשמש באופן בלעדי עם Quicken. קובץ QFX הוא קובץ OFX סטנדרטי עם שדות קנייניים נוספים.

שדה קנייני מרכזי: INTU.BID - מזהה בנק של Quicken. מזהה מספרי זה ממפה לבנק במסד הנתונים הפנימי של Quicken. בלעדיו, Quicken מסרב לייבא את הקובץ.

הבדלים מ-OFX סטנדרטי:

• דורש INTU.BID בכותרת
• עשוי לכלול שדות אחרים עם קידומת INTU.*
• מוסדות פיננסיים משלמים ל-Intuit דמי רישיון כדי לספק הורדות QFX
• Quicken לא ייבא קבצי OFX סטנדרטיים ללא שדה INTU.BID

הכי טוב עבור: משתמשי תוכנת ניהול כספים אישי Quicken. פורמט נדרש - אין חלופה שעובדת.

QIF (Quicken Interchange Format)

מה זה: פורמט טקסט פשוט מדור קודם שפותח במקור על ידי Intuit עבור Quicken. זוגות תג-ערך, אחד לכל שורה, עם תגיות בנות תו בודד: D לתאריך, T לסכום, P למוטב, L לקטגוריה, M לתזכיר, N למספר צ'ק, ^ לסוף רשומה.

מדוע הוא הוחלף: QIF חסר מנגנון זיהוי כפילויות (אין מקבילה ל-FITID), אין שדות זיהוי חשבון, אין מידע ניתוב בנק, אין נתוני יתרה, ועיצובי תאריכים לא עקביים בין יישומים.

עדיין רלוונטי: תוכנות הנהלת חשבונות מסוימות (Xero, Sage, GnuCash) עדיין מקבלות ייבוא QIF. שימושי להעברות ממערכות ישנות.

JSON (JavaScript Object Notation)

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

• ממשקי API של Open Banking (תקן Open Banking בבריטניה, קבוצת ברלין PSD2)
• API של FDX (Financial Data Exchange - יורשת OFX, 200+ ארגוני חבר)
• Plaid, Yodlee, MX וממשקי API אחרים של אגרגטורי נתונים
• תהליכי עבודה של מפתחים ואוטומציה

אימוץ גובר: תקנות Open Banking (PSD2 באירופה, סעיף 1033 של ה-CFPB בארה"ב) מאיצות את אימוץ ממשקי ה-API של JSON. ה-API של FDX משתמש ב-JSON/REST עם OAuth 2.0, המייצג את הכיוון העתידי של חילופי נתונים פיננסיים.

הכי טוב עבור: מפתחים הבונים תהליכי עבודה אוטומטיים, אינטגרציות פינטק, לוחות מחוונים מותאמים אישית, ואינטגרציות API של Open Banking.

השוואת פורמטים במבט חטוף

תאימות לתוכנות הנהלת חשבונות

איזה פורמט תוכנת הנהלת החשבונות שלכם מקבלת?

כלל אצבע: השתמשו ב-QBO עבור QuickBooks, QFX עבור Quicken, OFX עבור כל השאר, ו-CSV כפתרון גיבוי אוניברסלי.

הבדלים בעיצוב בינלאומי

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

פורמטי תאריכים

בעיית העמימות: "03/04/2026" הוא 3 באפריל בארה"ב, אך 4 במרץ באירופה. כאשר כל התאריכים בדף חשבון הם עם ערכי יום של 12 או פחות, אין דרך אלגוריתמית לקבוע את הפורמט הנכון ללא ידיעת מדינת המקור. כלי המרה חייבים לסרוק את כל התאריכים בדף, ולחפש ערכים גדולים מ-12 כדי לקבוע את הפורמט.

פורמטי מספרים

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

מיקום סמל המטבע

• ארה"ב/בריטניה: סמל לפני הסכום: $1,234.56 / £1,234.56
• צרפת, גרמניה, ספרד: סמל אחרי הסכום: 1.234,56 €
• אירלנד, הולנד: סמל לפני: €1,234.56
• יפן: סמל לפני: ¥123,456

קידודי תווים

• UTF-8 - תקן אוניברסלי, תומך בכל הכתבים
• GBK/GB2312 - סינית פשוטה (בשימוש בנקים סיניים)
• Shift_JIS - יפנית (בשימוש בנקים יפניים)
• Big5 - סינית מסורתית (טייוואן, הונג קונג)
• EUC-KR - קוריאנית
• ISO 8859-1 - מערב אירופאי
• Windows-1252 - מערב אירופאי (ישן)
• Windows-1256 - ערבית

פתיחת דף בנק סיני או יפני במערכת אמריקאית ללא זיהוי קידוד נכון מייצרת תווים מקולקלים. PDFSub מטפל ב-130+ שפות עם זיהוי אוטומטי של פורמטי תאריכים, פורמטי מספרים וקידודי תווים - כולל ערבית ועברית מימין לשמאל, תווים CJK, וכל מערכות התווים האירופאיות.

אלמנטים נפוצים בדפי בנק

תאריך עסקה לעומת תאריך רישום לעומת תאריך ערך

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

• תאריך עסקה - מתי הרכישה או ההעברה התרחשו בפועל
• תאריך רישום - מתי הבנק עיבד ורשם אותה (בדרך כלל 1–3 ימי עסקים לאחר מכן עבור רכישות בכרטיס אשראי)
• תאריך ערך - מתי הכספים הפכו זמינים בפועל (משפיע על חישובי ריבית, נפוץ בבנקאות בינלאומית)

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

ייצוג חיוב/זיכוי

בנקים מייצגים חיובים וזיכויים באופן שונה:

• סכומים עם סימן: -87.50 לחיובים, +3,500.00 לזיכויים
• עמודות נפרדות: "משיכות" ו-"הפקדות"
• קיצורים: "DR" לחיוב, "CR" לזיכוי (נפוץ בבריטניה/חבר העמים)
• סוגריים: (87.50) לחיובים (מוסכמת הנהלת חשבונות)

יתרה מתגלגלת

• יתרה לכל עסקה - מתעדכנת לאחר כל עסקה (הנפוץ ביותר בדפי צרכנים בארה"ב)
• יתרה יומית בלבד - יתרה המוצגת בסוף כל יום (נפוץ בדפי עסקים)
• ללא יתרה מתגלגלת - רק יתרות פתיחה וסגירה (חלק מדפי בנק בינלאומיים)

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

מידע כותרת סטנדרטי

רוב דפי הבנק כוללים: שם בעל החשבון, מספר חשבון (לרוב מוסתר חלקית), תקופת דוח, יתרות פתיחה וסגירה, סך הפקדות ומשיכות, וקוד ניתוב בנק/קוד מיון/SWIFT BIC.

הגנה באמצעות סיסמה

כיצד בנקים מצפינים קבצי PDF

בנקים משתמשים בדרך כלל הצפנת AES-128 או AES-256. קיימים שני מצבי הגנה:

• סיסמת משתמש (סיסמת פתיחה): נדרשת לפתיחת הקובץ
• סיסמת בעלים (סיסמת הרשאות): ה-PDF נפתח אך עריכה/העתקה עשויות להיות מוגבלות

דפוסי סיסמאות נפוצים

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

אתגרים של דפי חשבון מרובי עמודות

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

עסקאות מפוצלות

תיאור עסקה עשוי להתחיל בתחתית עמוד אחד ולהמשיך בראש העמוד הבא. הממיר חייב לזהות שורות המשך ולמזג אותן לעסקה אחת.

כותרות וכותרות תחתונות חוזרות

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

שורות המשך

לעסקאות רבות יש תיאורים מרובי שורות:

15/01  חיוב אלקטרוני ACH חברת ספק $3,200.00  $2,000.00 REF#123456789 חשבונית 2026-001 חברת ספק מחלקת תשלומים

שורות 2 ו-3 הן שורות המשך השייכות לעסקה בשורה 1. הן בדרך כלל חסרות תאריך וסכום, ומופיעות בהזחה באותה קואורדינטה x כמו עמודת התיאור.

העברת יתרות

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

קיצורים נפוצים בעסקאות

דפי בנק משתמשים בקיצורים המשתנים בין מוסדות:

תקנים תעשייתיים שכדאי להכיר

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

BAI2 (Bank Administration Institute)

משמש לניהול מזומנים אוטומטי ויישוב בנקאות במערכות ERP (SAP, Oracle). פורמט ASCII ברוחב קבוע עם קודי סוגי עסקאות (למשל, 165 = אשראי ACH מאושר מראש, 455 = חיוב ACH, 495 = העברה בנקאית יוצאת). שוחרר במקור בשנת 1987, כעת מתוחזק על ידי ASC X9.

SWIFT MT940 / MT942

דפי בנק לסוף יום (MT940) ותוך-יומיים (MT942) המשמשים בנקים ברחבי העולם עבור לקוחות תאגידיים ומחלקות אוצר. SWIFT מעבדת כ-45 מיליון הודעות ביום. פורמט מבוסס תגיות עם מזהי שדות מופרדים בנקודות.

ISO 20022 (camt.053)

החלופה המודרנית מבוססת XML ל-MT940. חלק מתקן ההודעות הפיננסי האוניברסלי ISO 20022. נתונים עשירים יותר מ-MT940, ללא מגבלות אורך שדה, XML ניתן לניתוח מכונה עם אימות XSD. SWIFT עוברת מהודעות MT להודעות ISO 20022. SEPA (Single Euro Payments Area) מחייבת את פורמט camt עבור תשלומים אירופאיים.

NACHA ACH

פורמט הקבצים עבור עסקאות Automated Clearing House בארה"ב. ASCII ברוחב קבוע, בדיוק 94 תווים בשורה. ACH מעבדת כ-30 מיליארד עסקאות בשנה בארה"ב. כאשר דף הבנק שלכם מציג "ACH CREDIT" או "ACH DEBIT", העסקה הבסיסית הועברה בפורמט NACHA בין בנקים.

בחירת הפורמט הנכון לתהליך העבודה שלך

מדריך החלטות

השתמשו ב-QBO אם: אתם משתמשים ב-QuickBooks (Desktop או Online). אתם מקבלים סיווג סוג עסקה, זיהוי כפילויות באמצעות FITID, ואת מטא-הנתונים העשירים ביותר לייבוא.

השתמשו ב-OFX אם: אתם משתמשים ב-Xero, Sage, Wave, או תוכנות אחרות התומכות ב-OFX. Xero ממפה אוטומטית שדות ללא צורך בתצורה ידנית של עמודות.

השתמשו ב-QFX אם: אתם משתמשים ב-Quicken. זהו הפורמט היחיד ש-Quicken מקבל.

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

השתמשו ב-CSV אם: התוכנה שלכם אינה מופיעה ברשימה למעלה, או שאתם זקוקים לתאימות מקסימלית בין מערכות. היו מוכנים למפות עמודות באופן ידני.

השתמשו ב-JSON אם: אתם בונים תהליכי עבודה אוטומטיים, אינטגרציות API, או מערכות דיווח מותאמות אישית.

טיפים מקצועיים

• תמיד השתמשו ב-QBO/OFX על פני CSV כאשר התוכנה שלכם תומכת בכך - זיהוי הכפילויות לבדו מונע שעות של ניקוי
• שמרו את ה-PDF המקורי לצד הקובץ המומר שלכם - זהו מסלול הביקורת ומסמך המקור שלכם
• ודאו לאחר כל ייבוא - בדקו מדגמית את יתרות הפתיחה/סגירה וכמה עסקאות אקראיות
• התאימו פורמט לתוכנה - שימוש בפורמט המקורי של פלטפורמת הנהלת החשבונות שלכם מונע מיפוי עמודות ידני ומאפשר תכונות אוטומטיות

נסו בחינם

מוכנים להמיר את הדוח הראשון שלכם? העלו PDF עכשיו - PDFSub ממיר ל-Excel, CSV, QBO, OFX, QFX, ו-JSON. דוחות דיגיטליים מעובדים לחלוטין בדפדפן שלכם לפרטיות מקסימלית. התחילו תקופת ניסיון בחינם של 7 ימים עם גישה מלאה לכל הפורמטים.