חילוץ נתונים מחשבוניות באמצעות בינה מלאכותית: LayoutLMv3 ו-Donut

מדוע חילוץ נתונים מחשבוניות נשבר בזרימה

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

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

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

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

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

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

השפעת ההטמעה: מהירות עיבוד ושיעור שגיאות

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

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

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

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

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

דרכי פירוק טפסים: תבניות, כללים ומודלים

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

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

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

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

שלבי ההטמעה: מאודיט הארכיון ועד מסירה לעבודה

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

1. אודיט הארכיון. מייצאים כמה מאות חשבוניות מהתקופה, מסמנים את סוגי הטפסים, סופרים את שיעור הסריקות בלי שכבת טקסט, הסיבובים והתיקונים בכתב יד. בפלט — מפת סוגי מסמכים והערכה כנה של השיעור שהחילוץ יסגור בלי מפעיל.
2. תרשים זרימת המסמכים. מתארים מאיפה מגיע הקובץ, היכן נשמר המקור, לאן נשלחת התוצאה ומה קורה לשדה אם ודאות המודל נמוכה מהסף. את התרשים מאשרים לפני הכיול.
3. כיול החילוץ. מאמנים מודל סימון על הטפסים של הלקוח, ומסמנים את הפרטים: מספר, תאריך, ספק, סכומים, מס, שורות. חלק מהשדות סוגרים בכללים ובהצלבה מול ספרי עזר — זה יציב יותר מאשר לסמוך הכול על המודל.
4. בדיקה על מדגם מבחן. מריצים על חשבוניות שהמודל לא ראה, וסופרים דיוק לכל שדה בנפרד. נקודות התורפה — שורות, פרטים בכתב יד — מפרקים ידנית, כדי שהמספר הממוצע לא יסתיר אותן.
5. קריטריוני קבלה. קובעים לפני ההרצה הסופית: דיוק לפי שדות, שיעור החשבוניות לבדיקה ידנית, זמן עיבוד של אצווה, פורמט הייצוא. לא התאים — מאמנים שוב, ולא מקבלים כמו שזה.
6. מסירה לתפעול. פורסים בקונטור של הלקוח או בענן סגור, מפעילים רישום יומן והתראות על ירידת דיוק, מאמנים את המפעילים, מוסרים תיעוד. כעבור חודש מצליבים את המדדים בפועל עם מדדי הקבלה ומאמנים שוב על טפסים חדשים.

מה הלקוח מקבל לידיים: קונפיגורציות ותקנונים

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

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

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

מקרה בוחן: זרימת מסמכים נכנסים בלי הצלבה ידנית

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

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

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

מדדים לפני ואחרי

דיוק הפירוק של שדות המפתח עלה מ-88% ל-98%, ושיעור המסמכים שעוברים בלי מעורבות אדם — מ-37% ל-91%. 9% הנותרים לא הולכים לאיבוד: הם מגיעים לתור בדיקה שבו השדות השנויים במחלוקת מודגשים, והמפעיל מתקן פרט אחד-שניים במקום להקליד את כל המסמך.

סגירת התקופה התקצרה מ-11 ל-3 ימי עבודה, והזרימה גדלה ל-6,500 מסמכים בחודש בלי הרחבת מצבת העובדים. אחרי הפיילוט הפיתרון נפרס על שאר החברות ונוספו סוגי טפסים חדשים, והמודל מאומן מחדש על תיקוני המפעילים — שיעור הקליטה האוטומטית ממשיך לעלות.

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

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

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

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

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

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

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

ספקות טכניים: דיוק, פורמטים, אינטגרציות

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

עיקרון המפתח אחד: המודל לא "רואה" את הטופס, הוא מחלץ שדות לפי המשמעות וההקשר של המסמך. לכן בקרת האיכות נבנית לא על אמון בזיהוי, אלא על סף ודאות לכל שדה: מה שמתחת לסף — עובר למפעיל, מה שמעל — למערכת החשבונאות.

מה עושים עם סריקות באיכות נמוכה — עיוות, רעש, פקס?

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

הופיע סוג מסמך חדש אחרי ההרצה — צריך לעשות הכול מחדש?

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

איך בנויה האינטגרציה עם מערכת החשבונאות ומי אחראי לטעות?

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

נדון במשימה: מה צריך כדי להעריך את הזרימה

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

• היקף וקצב הזרימה: כמה חשבוניות מגיעות בחודש, מה השיעור של סריקות בלי שכבת טקסט, והאם יש שיאים בסגירת התקופה.
• ערוצי ההגעה: ניהול מסמכים אלקטרוני, דואר, סורק רשתי, ייצוא ממערכת החשבונאות — מה כבר מגיע קריא למכונה, ומה מפורק בידיים.
• פורמטים ואיכות: PDF עם שכבת טקסט ובלעדיה, תמונות, XML; באיזו תדירות מופיעים סיבובים, ניגודיות נמוכה, נספחים רבי-עמודים עם טבלאות.
• פרטים וכללי בדיקה: אילו שדות חובה, האם יש ספרי ספקים ופריטים, ואיך כיום מצליבים סכומים, מע"מ וסיכומים לפי שורות.
• נקודת הנחיתה של התוצאה: לאן לכתוב את הנתונים שחולצו והאם נדרש שלב אישור ידני לפני רישום הפקודה.
• תשתית והרשאות: האם אפשר להציב את העיבוד בקונטור שלך או באתר ייעודי, אילו דרישות לשמירת מקורות, לרישום יומן ולהפרדת הרשאות.
• בעלי התהליך: מי מצד הנהלת החשבונות, המחשוב ואבטחת המידע מאשר את כללי הפירוק ומקבל את התוצאה.

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