האם AI יכול לחלץ נתונים מחוזים ל-ERP? כך זה עובד

AI יכול לקרוא חוזים, לחלץ שדות כמו צדדים, תאריכים ותנאי תשלום, ולכתוב אותם ל-ERP כטיוטה שאדם מאשר. המדריך מסביר את השלבים ומביא דוגמה מ-Priority ERP.

Contracts scanned by AI and extracted into structured ERP fields on a dashboard

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

האם AI יכול לחלץ נתונים מחוזים ל-ERP?

כן, AI יכול לחלץ נתונים מחוזים ל-ERP. התהליך המקובל קורא את המסמך, מחלץ את השדות שהגדרתם, מאמת אותם, וכותב ל-ERP רשומת טיוטה שאדם מאשר.

לזה קוראים בדרך כלל עיבוד מסמכים חכם (Intelligent Document Processing): תוכנה שמשלבת זיהוי תווים אופטי (OCR) עם AI, ויותר ויותר עם מודלי שפה גדולים, כדי להפוך מסמכים לנתונים מובנים. קובץ PDF סרוק או קובץ Word הופכים לשדות שמערכת יכולה להשתמש בהם, במקום טקסט שמישהו מקליד מחדש. זה מתמודד עם חוזים בפריסות, בטבלאות ובשפות שונות, אבל הדיוק משתנה לפי איכות המסמך והפריסה שלו, ואת השדות שאתם צריכים יש להגדיר מראש.

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

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

בהמשך המדריך: איך השלבים עובדים, אילו נתונים אפשר לחלץ, למה שלב אישור אנושי חשוב, דוגמה אמיתית על Priority ERP, ומה להכין לפני שמתחילים.

איך עובד חילוץ מחוזים ל-ERP

התהליך כולל חמישה שלבים: קליטת המסמך, חילוץ השדות, אימות, מיפוי לשדות ה-ERP וכתיבת טיוטה ל-ERP. אדם מאשר את הטיוטה לפני שהיא הופכת לרשומה.

  1. קליטה: קובצי PDF, סריקות וקובצי Word מגיעים במייל או בהעלאה.
  2. חילוץ: מודל שפה מזהה שדות, סעיפים וטבלאות (אחרי OCR בסריקות).
  3. אימות: בדיקת שדות חובה, פורמטים וסכומים, וסימון חוסרים.
  4. מיפוי: התאמת הערכים שחולצו לשדות ה-ERP.
  5. כתיבה: שליחת טיוטה ל-ERP דרך ה-API שלו, ואז אדם מאשר אותה.

שלב 1: קליטה

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

שלב 2: חילוץ

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

שלב 3: אימות

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

שלב 4: מיפוי וכתיבה

כל ערך שחולץ מותאם לשדה ב-ERP, ואז נשלח דרך ה-API של ה-ERP. המבנה הבטוח ביותר כותב טיוטה ולא רשומה סופית, ובודק מאשר אותה.

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

אילו נתונים AI יכול לחלץ מחוזה

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

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

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

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

למה שלב אישור אנושי חשוב

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

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

איפה החילוץ טועה

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

מה הבודק צריך

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

אחרי שלבי האפיון והתשתית, קדמון סיסטמס בונה גרסה מקצה לקצה עם אדם בלולאה (human in the loop), ואז סוקרת אותה עם הצד העסקי לפני הפריסה.

Extracted contract fields mapped to a draft ERP form awaiting human approval

דוגמה אמיתית: קליטת חוזים ל-Priority ERP אצל ספק רכב גלובלי

עבור ספק רכב גלובלי עם חמש סביבות Priority ERP בינלאומיות, קדמון סיסטמס בנתה קליטת חוזים מבוססת AI על Make.com (לשעבר Integromat), שכותבת טיוטות ל-Priority ERP לאישור אנושי.

הקליטה מנתחת 25 עד 30 תבניות חוזה בכמה שפות, כולל מסמכים של 20+ עמודים. במבנה הזה DocuPipe ושכבת LLM מבצעים את החילוץ, Make.com כותב טיוטה ל-Priority ERP, ואדם מאשר אותה לפני שהיא הופכת לרשומה.

מה להכין לפני שמתחילים

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

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

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

איך קדמון סיסטמס בונה קליטת חוזים

קדמון סיסטמס, חברת ייעוץ ישראלית לאוטומציה ולאינטגרציית AI ו-Make.com Gold Partner, בונה קליטת חוזים מבוססת AI שכותבת טיוטות ל-Priority ERP לאישור אנושי. סוכני AI וחילוץ מסמכים הם אחד מחמשת תחומי השירות שלה, לצד ארכיטקטורת Make.com ואינטגרציה ל-Priority ERP.

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

  1. מסמך אפיון
  2. תשתית
  3. MVP מקצה לקצה עם אדם בלולאה
  4. סקירה עסקית
  5. פריסה
  6. שכפול לסביבות נוספות
  7. QA ומסירה

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

שאלות נפוצות

האם AI קורא חוזים סרוקים וקובצי PDF?

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

האם ה-AI כותב ישירות ל-ERP?

הוא יכול, דרך ה-API של ה-ERP, אבל מבנה בטוח יותר כותב טיוטה שאדם מאשר קודם. כך יש בודק אחד שאחראי על הרשומה, בין החילוץ לבין ה-ERP.

האם זה עובד עם חוזים בכמה שפות?

כן. קליטת החוזים שקדמון סיסטמס בנתה לספק רכב גלובלי מנתחת 25 עד 30 תבניות חוזה בכמה שפות, כולל מסמכים של 20+ עמודים.

עם אילו מערכות ERP זה עובד?

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

מה זה עיבוד מסמכים חכם (IDP)?

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

רוצים לראות איך זה עובד אצלכם?

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