עמותה ישראלית שמפעילה כמה מרכזי מגורים הזינה כל חשבונית ספק ל־ERP באופן ידני. בניתי פלטפורמה שקוראת חשבוניות סרוקות בעזרת Azure AI Document Intelligence, מריצה 14 בדיקות אוטומטיות על כל חשבונית, ומעבירה לטיפול אנושי רק את החשבוניות שבאמת צריכות החלטה של אדם.
ספקים שולחים חשבוניות מס, חשבוניות מרכזות, תעודות משלוח וחשבוניות זיכוי, הרבה פעמים כסריקה מהטלפון או כ־PDF במייל, ולפעמים בכתב יד. לפני שאפשר היה להזין משהו ל־ERP, מישהו היה צריך לקרוא כל מסמך, לוודא שהוא מיועד לעמותה, להבין לאיזה מרכז הוא שייך, לבדוק את החשבון, לחפש חותמת וחתימה, ולוודא שהמסמך לא הוזן כבר. זו עבודה איטית וחוזרת על עצמה, וקל לפספס בה טעויות.
התרשים רחב מהמסך: החליקו הצידה לצפייה בכולו →
הגישה ל־ERP עוברת רק דרך ספק אחד (Anti-Corruption Layer). בשלב 1 הוא חושף שאילתות קריאה בלבד, וכל ספק בלי קונפיגורציה נכשל בצורה בטוחה, כך ששום דבר לא מעמיד פנים שאינטגרציה ענתה. התור יושב מאחורי ממשק: כרגע מבוסס SQL, ובהמשך Azure Service Bus דרך DI, בלי לשנות את הקוד העסקי.
מודל ה־OCR טוב, אבל אי אפשר לסמוך עליו לבד. כל תיקון שהמערכת עושה, למשל שורות שהיא בונה מחדש מהטבלה או שורות הפניה שהיא משמיטה, נשמר רק אם התוצאה מסתכמת בדיוק לסכום המודפס. המחיר: בהתחלה יותר חשבוניות מגיעות לאדם, אבל שום נתון לא מאומת לא נכנס למערכת.
מרכז, מק״ט או קוד תקציב נקבעים רק כשיש בדיוק מועמד אחד. אפס מועמדים פירושו ”לא נמצא”, ויותר מאחד פירושו ”דו־משמעי”, ובשני המקרים החשבונית עוברת לסקירה. המערכת אף פעם לא דורסת ערך שסוקר הזין. המחיר: פחות אוטומציה עד שנתוני המיפוי האמיתיים ייטענו.
סביבת Azure עוד לא הוגדרה, ולכן התור רץ על SQL Server עם תפיסה אטומית, ניסיונות חוזרים, backoff ו־dead-letter, מאחורי IProcessingQueue. ה־handlers אידמפוטנטיים. המחיר: polling כל 5 שניות, וזה מספיק בנפח הנוכחי.
הלקוח דחה את חיבור Entra ID. במקום להשאיר API פתוח, המערכת מנפיקה JWT קצר־מועד מהתחברות מדומה, עם אותם claims, אותן הגנות ואותה זהות בלוג הביקורת. המחיר: המעבר ל־Entra ID מחליף רק את מנפיק הטוקן.
בדיקות עם מסמכים אמיתיים של הלקוח התחילו מוקדם ונמשכו לאורך כל הפרויקט. כל בעיה כאן הגיעה מחשבונית אמיתית.
תפיסה בשיטת ”קרא ואז עדכן” אפשרה לשני צרכנים לקחת את אותו מסמך מהתור.
הודעות נתפסות בפקודת SQL אחת שמעדכנת שורה אחת ומחזירה אותה, כך שאין חלון שבו יכול להיווצר מרוץ. הודעה שתקועה בעיבוד יותר מ־10 דקות משוחזרת, ואחרי 3 ניסיונות היא עוברת לרשימת dead-letter שאפשר להחזיר ממנה לתור.
בחשבונית בכתב יד השירות קרא 28,500 כ־2,800 ו־5,130 כ־130, עם ודאות שדה 0.98 וודאות מסמך 1.0.
רמת הוודאות המדווחת היא עכשיו המינימום מבין כל השדות הקריטיים בכותרת ובשורות. בדיקות החשבון המצולבות (שורות ← סכום ביניים ← מע״מ ← סה״כ, בלי שום טולרנס) הפכו לרשת הביטחון העיקרית, והן אלה שתפסו את החשבונית הזאת.
בטבלאות מודפסות צפופות המודל איחד שורות, או הזיז כמויות ומחירים בין שורות.
כשהשורות של המודל לא מסתכמות, המערכת בונה אותן מחדש מגריד הטבלה שזוהה. השחזור נשמר רק אם הסכום מדויק. סוקרים יכולים גם להוסיף, למחוק ולפצל שורות, והקריאה המקורית נשמרת כמו שהיא.
מספר ח.פ בהדפסה קטנה נקרא נכון, אבל בוודאות 0.54, מתחת לסף של 95%. בלי פתרון, רוב המסמכים הסרוקים היו נכשלים על השדה הזה בלבד.
לח.פ ולת.ז יש ספרת ביקורת. מספר שעובר את בדיקת ספרת הביקורת נחשב מאומת ולא נכנס לחישוב המינימום. הלקוח אישר את זה כחריגה מתועדת ממדיניות הסף.
שכבת הפיתוח מנתחת 2 עמודים בכל קריאה. באחד הקבצים תעודת המשלוח בעמודים 1–2 הכילה את השורות, וחשבונית המס הגיעה רק אחריהם.
עכשיו גם העמודים הבאים מנותחים, ומהם נלקחים רק שדות הזיהוי החסרים. הסכומים נשארים מהתוצאה הראשית, ואם העמוד הנוסף נקרא בוודאות נמוכה יותר, זו הוודאות שמדווחת.
המודל לקח את המספר שליד הכותרת ”תעודת משלוח” כמספר החשבונית.
המספר הזה עובר עכשיו לשדות ייעודיים של תעודת משלוח, ומספר החשבונית נשאר ריק. חוק השדות החובה מבקש אז מהסוקר להזין את המספר האמיתי. חשבוניות זיכוי מטופלות באותה דרך.
לפעמים העלאה אחת הכילה יותר מחשבונית אחת.
הקובץ מפוצל למסמכים נפרדים באותו תהליך, אבל רק כשלכל חלק יש מספר חשבונית וסכום לתשלום משלו. חלקים שלא עומדים בזה נשארים צמודים לחשבונית הראשית.
חלק מהסריקות היו שרשורי מייל מודפסים, שבהם מנהל המרכז ענה ”מאושרת”.
מזהה שמרני ודטרמיניסטי מחפש סימנים של שרשור מייל וגם מילת אישור שעומדת בשורה משלה (”לא מאושרת” לעולם לא נחשב). הוא מוצג לסוקר כרמז, ואף פעם לא מאשר שום דבר אוטומטית.
הדגמה עם חשבונית סינתטית: הספק, המרכז והסכומים בדויים. בחרו שלב כדי לראות מה המערכת עושה ואיזה מנגנון הגנה פועל בו.
| תחום | לפני | אחרי |
|---|---|---|
| הזנת נתונים | כל שדה מוקלד ידנית | חילוץ אוטומטי, ואנשים סוקרים רק חשבוניות שסומנו (בערך 6 ← 1 דקות לחשבונית, הערכה) |
| בדיקות | בעין, ושונות מאדם לאדם | 14 חוקים על כל חשבונית, עם 12 סיבות חריגה מוגדרות |
| ודאות | ציון אחד למסמך (1.0 גם על קריאה שגויה) | הציון הנמוך מבין כל השדות הקריטיים, ובנוסף בדיקות חשבון מדויקות |
| אישורים | מסמך אחד בכל פעם | אישור מרוכז בבחירה מרובה, עם תיעוד של זהות המאשר והשעה |
| קבצים עם כמה חשבוניות | הפרדה ידנית | פיצול אוטומטי למסמכים נפרדים, וכל אחד עובר ולידציה בנפרד |
| כשלים | שקטים | 3 ניסיונות עם backoff, רשימת dead-letter עם החזרה לתור, ודוח יומי |
| הקמת מסד נתונים | שלבי מיגרציה ידניים | התקנה בפקודה אחת, וגם סקריפטים לגיבוי ושחזור |
שלב 1 כולל קליטה, חילוץ, התאמה, ולידציה, סקירה ואישור, ונבדק על מסמכים אמיתיים של הלקוח. שאילתות הקריאה מה־ERP (אבן דרך M7) ממתינות לפרטי ה־API מספק ה־ERP. רישום ל־ERP וקליטה מתיבת דואר מתוכננים לשלבים הבאים.
שיחת אבחון חינם · 30 דקות · ללא התחייבות
כתבו בכמה שורות: איזה תהליך או מערכת, מה כואב היום (זמן, טעויות, עלויות או פיילוט AI שנתקע) ומי עובד עם זה. אחרי שיחה קצרה מקבלים תוך כ־3 ימים תוכנית כתובה והצעת מחיר סגורה.
נפתח מייל מוכן מראש · מענה תוך יום עסקים
ה־AI קורא. הקוד סופר.
כל הפרויקטים