מה OCR באמת עושה — ואיפה הוא נעצר
OCR, ראשי תיבות של Optical Character Recognition, פותר בעיה אחת מוגדרת היטב: להסתכל על תמונה שיש בה טקסט ולהחזיר את התווים. זהו. הפלט הוא רצף של אותיות, ספרות וסימנים — ולעיתים גם המיקום שלהם על הדף.
מה שהוא לא עושה זה להבין מה קרא. עבור מנוע OCR, המחרוזת "חברת הדלק בע״מ" והמחרוזת "274.50" הן שתי מחרוזות. הוא לא יודע שהראשונה היא שם ספק ושהשנייה היא סכום, ובוודאי לא איזה מבין שבעת המספרים שעל הקבלה הוא הסכום לתשלום ואיזה הוא מספר החשבונית.
זו הסיבה שסורק ביתי מייצר בדרך כלל "PDF שאפשר לחפש בו" — התמונה נשארת, ומעליה שכבת טקסט. אפשר לחפש מילה, אי אפשר לסכם רבעון. הפער בין השניים הוא לא איכות ה‑OCR; הוא שלב אחר לגמרי בשרשרת.
- תמונה בלבד — אי אפשר לחפש, לסנן או לסכם
- OCR — יש תווים; אפשר לחפש מילה, אין מבנה
- שכבת חילוץ וסיווג — לכל שדה יש משמעות: ספק, תאריך, סכום, מע״מ
- רק השלב השלישי הופך מסמך לרשומה שאפשר לעבוד איתה
עיבוד התמונה — השלב שקובע את התוצאה
רוב הטעויות של OCR נקבעות עוד לפני שזוהה תו אחד. מנועי OCR מריצים סדרת עיבודים על התמונה, ואיכות הקלט היא מה שמכתיב כמה מהם יצליחו. התיעוד של Tesseract — מנוע ה‑OCR בקוד פתוח הנפוץ ביותר — מפרט את השלבים במפורש, והם מייצגים היטב את מה שכל מנוע עושה בגרסה כזו או אחרת.
ההמלצה הבסיסית שם היא רזולוציה: לפי התיעוד, Tesseract עובד במיטבו על תמונות ברזולוציה של 300 dpi לפחות. מתחת לזה, קווי התו מתחילים להתמזג והזיהוי מתדרדר — וזה בדיוק מה שקורה כשמצלמים קבלה מרחוק או בתאורה חלשה.
השלבים עצמם, כפי שהם מתועדים: שינוי קנה מידה (rescaling) להבאת התמונה לרזולוציה סבירה; בינאריזציה — המרה לשחור‑לבן, ש‑Tesseract מבצע פנימית באלגוריתם Otsu; הסרת רעש; הרחבה וכיווץ של קווי התו (dilation/erosion) כדי לפצות על גופן עבה או דק מדי; יישור הטיה (deskewing) כך ששורות הטקסט יהיו אופקיות; והסרת מסגרות כהות בשולי הדף, שאחרת נקראות כתווים נוספים.
המסקנה המעשית לצילום קבלה: לצלם מקרוב וישר, בתאורה אחידה, על רקע שאינו כהה. כל אחד מהשלבים למעלה מנסה לתקן משהו שאפשר היה לא לייצר מלכתחילה.
למה קבלות בעברית קשות במיוחד
קבלה ישראלית מצרפת כמה קשיים בבת אחת, ולכן מנוע שמצליח יפה על חשבונית באנגלית לא בהכרח יצליח כאן.
הראשון הוא כיווניות מעורבת. הטקסט העברי נקרא מימין לשמאל, אבל המספרים בתוכו נקראים משמאל לימין, ובאותו מסמך יש גם מחרוזות לטיניות (שם ספק לועזי, כתובת אתר). סדר התווים שיוצא מה‑OCR לא תמיד מייצג את הסדר החזותי, וזה משפיע במיוחד על שדות מספריים.
השני הוא הצורה של המסמך. קבלת קופה היא לרוב עמודה צרה בגופן קטן על נייר תרמי — משטח מבריק, נטול ניגודיות, שדוהה בחשיפה לחום ולאור. נייר תרמי שנשאר ברכב או בארנק כמה שבועות עלול להיות בלתי קריא גם לעין אנושית, ואז אין מה לצפות ממנו מ‑OCR.
והשלישי הוא אוצר מילים. קיצורים כמו "מע״מ", "סה״כ", "כולל מע״מ", "ע.מ." ו"ח.פ." הם המפתח להבנת המסמך — ומנוע שלא אומן עליהם יראה בהם רצף תווים ככל רצף אחר. בישראל זה לא מקרה קצה; זה רוב הקבלות.
חילוץ טקסט מול סיווג — שתי שאלות שונות
כאן נמצא ההבדל שהמדריך הזה קיים בשבילו. "מה כתוב במסמך" ו"מה המסמך הזה" הן שתי שאלות נפרדות, ורק הראשונה היא OCR.
השאלה השנייה היא סיווג: האם זו חשבונית מס, חשבונית מס‑קבלה, קבלה בלבד, חשבונית עסקה, או דווקא חשבונית זיכוי. לסיווג הזה יש תוצאה כספית ישירה — חשבונית זיכוי צריכה להיכנס כערך שלילי ולא כהוצאה נוספת, וריכוז חיובים תקופתי אינו הוצאה בפני עצמו אלא סיכום של תשלומים שכבר נספרו.
ויש שאלה שלישית, שגם היא אינה OCR ואינה סיווג המסמך: האם המע״מ במסמך הזה ניתן בכלל לקיזוז כתשומות. חשבונית עסקה, ארנונה, עמלות בנק וספק זר אינם מתנהגים כמו חשבונית מס ישראלית — וטקסט שחולץ בשלמות לא עונה על זה בשום צורה.
לכן מערכת שנשענת על OCR בלבד תמיד תשאיר את החלק הזה עליכם. השאלה כשבוחנים כלי היא לא "כמה טוב ה‑OCR" אלא "אילו מהשאלות האלה הוא בכלל שואל".
השדות שנשברים ראשונים
כשקריאה משתבשת, היא כמעט תמיד משתבשת באותם מקומות. שווה להכיר אותם, כי אלה גם השדות שכדאי לבדוק ידנית כשמסמך נראה חשוד.
- ספק — שם המנפיק מתחלף בשם הלקוח. שני השמות מופיעים על אותו מסמך, לעיתים קרובות בגדלים דומים, ומי שלא מבדיל ביניהם יכול לרשום את העסק שלכם כספק.
- מספר עוסק — מתחלף במספר החשבונית, במספר טלפון או במספר הזיהוי של הלקוח. כל אלה רצפים בני 8–9 ספרות באותו אזור בדף.
- סכום — הבלבול הקלאסי הוא בין הסכום לפני מע״מ, סכום ביניים, והסכום לתשלום. קבלה שמפרטת שורות מכילה עוד עשרות מספרים שכולם מועמדים לגיטימיים.
- מע״מ — שני מצבי כשל הפוכים: מסמך שיש בו מע״מ אבל הוא לא מודפס כשורה נפרדת (נפוץ בקבלות דלק ובקבלות קופה שכתוב עליהן רק "כולל מע״מ"), ומסמך של עוסק פטור שאין בו מע״מ כלל ובכל זאת מיוחס לו סכום.
- מטבע — סימן המטבע נחתך או מתעלמים ממנו, וסכום בדולרים נרשם כשקלים. זו טעות שקשה לתפוס בדיעבד כי המספר עצמו נראה סביר.
- תאריך — הבלבול בין DD/MM ל‑MM/DD, ובין תאריך ההנפקה לבין תאריך הדפסה או תאריך תשלום שמופיעים על אותו מסמך.
למה עדיין צריך עין אנושית
אף מערכת סריקה לא מגיעה ל‑100%, ומי שמבטיח אחרת מוכר לכם משהו. אבל הנקודה החשובה אינה שיעור הדיוק אלא סוג הכשל: הבעיה בקריאה אוטומטית היא שהיא נכשלת "בשקט". מספר שגוי נראה בדיוק כמו מספר נכון.
לכן מה שמפריד מערכת שאפשר לסמוך עליה מאחת שאי אפשר הוא לא כמה היא טועה, אלא האם היא יודעת להגיד שהיא לא בטוחה. מערכת שמסמנת מסמך לבדיקה כשלא הצליחה לזהות ממנו ספק מצמצמת את העבודה שלכם לכמה מסמכים במקום לכולם.
בדיקה עצמית פשוטה שכדאי לצפות לה: שהסכום לפני מע״מ, המע״מ והסכום הכולל מסתדרים זה עם זה. אי‑התאמה חשבונית היא הסימן הזול ביותר לזהות ששדה נקרא לא נכון.
ומעבר לכך — כדאי לעבור ידנית על מסמכים בסכומים גבוהים ועל מסמכים במטבע זר, כי שם עלות הטעות הגדולה ביותר. הסריקה חוסכת את ההקלדה; היא לא מחליפה בדיקה לפני דיווח, ובוודאי לא את רואה החשבון.
איך לבדוק מערכת סריקה לפני שסומכים עליה
אחוזי דיוק שמופיעים בשיווק אינם מדידה — הם מספר בלי מבחן מאחוריו. במקום להשוות מספרים כאלה, אפשר לבדוק שבע שאלות שהתשובה עליהן ניתנת לאימות תוך כמה דקות עם קבלות אמיתיות שלכם.
הבדיקה הכי טובה היא לא הקבלה הכי נוחה אלא הכי קשה: קבלת קופה תרמית מקומטת, מסמך במטבע זר, חשבונית של כמה עמודים, ומסמך שאינו הוצאה בכלל — כמו חשבונית זיכוי. מערכת שמתמודדת עם הארבעה האלה תתמודד גם עם השאר.
- האם היא מחזירה שדות נפרדים — ספק, תאריך, סכום, מע״מ — או רק טקסט?
- האם היא מבחינה בין המנפיק לבין הלקוח, ובין מספר עוסק למספר חשבונית?
- מה קורה במסמך שאין בו שורת מע״מ נפרדת, ומה במסמך של עוסק פטור?
- האם היא מסווגת את סוג המסמך — ובפרט, האם חשבונית זיכוי נכנסת כערך שלילי?
- האם היא מסמנת מסמך שהיא לא בטוחה לגביו, או בולעת אותו בשקט?
- האם המסמך המקורי נשמר לצד הנתונים, וניתן לייצוא בכל רגע?
- האם היא מזהה שאותו מסמך כבר נקלט פעם אחת, כדי שלא ייספר פעמיים?
מה לגבי הקבלות שכבר דיגיטליות
לפני שמשקיעים בסריקה, שווה לשאול כמה מהקבלות בכלל צריכות אותה. קבלה שהגיעה כ‑PDF במייל או בוואטסאפ היא כבר קובץ — להדפיס ולסרוק אותה מחדש רק מוסיף שלב ומוריד איכות, כי הופכים מסמך דיגיטלי לתמונה של מסמך.
הכלל הפשוט: סריקה וצילום נשמרים לנייר הפיזי בלבד — קבלת קופה, חניון, קבלה מפנקס. כל השאר עדיף שיישאר בפורמט שבו הגיע, ושייאסף מהמקור שבו הוא כבר נמצא.
ובקבלת נייר תרמי, העיתוי חשוב יותר מהציוד: לצלם באותו יום, לפני שהנייר נחשף לחום ולאור. מסמך שדהה הוא מסמך שאבד — לא בגלל ה‑OCR.
איך זה עובד
למי זה מתאים
אפקס מחלצת ספק, ח.פ., תאריך, מספר מסמך, סכום ומע״מ — ומסווגת את סוג המסמך לפני שהיא מכניסה אותו.
לעמוד סריקת החשבוניות עם AI ←שאלות נפוצות
קשור לנושא
מקורות רשמיים
- Tesseract OCR — Improving the quality of the output — tesseract-ocr.github.io — שלבי עיבוד התמונה והמלצת ה‑300 dpi
- Tesseract OCR — התיעוד הרשמי — tesseract-ocr.github.io
- רשות המסים בישראל — gov.il — המקור הרשמי למע״מ ולמס הכנסה
המדריך טכני ואינו ייעוץ מס. תיאורי שלבי העיבוד וההמלצה על 300 dpi מבוססים על התיעוד הרשמי של Tesseract; אין כאן מדידת דיוק שלנו ואין אחוזים — מספר כזה מחייב מבחן מתועד. הכרה בהוצאה, קיזוז מע״מ ושמירת מסמכים כפופים לדין ולנסיבות האישיות — היוועצו ברואה חשבון.