אוטומציית חשבוניות בישראל: לחבר אתר ל-Green Invoice ב-API

למי זה מתאים: לבעלי עסקים, מפתחים ואנשי אוטומציה שגובים תשלומים אונליין ועדיין מוציאים חשבונית או קבלה ביד אחרי כל עסקה. אם אתם רוצים אוטומציית חשבוניות שמפיקה חשבונית מס/קבלה אוטומטית ברגע שהכסף נכנס, בין אם דרך Green Invoice (מורנינג), iCount, בקוד או ב-no-code, זה המקום. נסביר את הצד החוקי בקצרה, את חיבור ה-API צעד אחר צעד, את הסיפור של מספר הקצאה ב-2026, ואיפה Make או n8n מספיקים ואיפה צריך קוד.

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

1. מה בעצם הולכים לאטמט, ולמה זה משתלם

התרחיש הקלאסי: לקוח משלם באתר (כרטיס אשראי, Bit, PayPal, או העברה בנקאית), הכסף נכנס לחשבון הסליקה, ואז מישהו צריך לזכור להיכנס למערכת החשבוניות, להקליד את הפרטים, ולשלוח מסמך ללקוח. ברוב העסקים הקטנים ה״מישהו״ הזה הוא הבעלים, בשעה 23:00, אחרי יום עבודה.

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

מה מרוויחים בפועל:

• זמן. עסק שמוציא 50 מסמכים בחודש חוסך בקלות 3-5 שעות חודשיות.
• דיוק. אין הקלדה ידנית של סכומים ות״ז/ח״פ, פחות טעויות, פחות תיקוני מסמכים.
• חוויית לקוח. הלקוח מקבל מסמך מיד, לא אחרי יומיים. זה נראה מקצועי.
• תזרים שקט. אתם לא רודפים אחרי עצמכם בסוף החודש להשלים מסמכים שנשכחו.

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

2. רקע חוקי קצר: מה הם המסמכים ומתי מפיקים אותם

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

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

עוסק פטור: שימו לב

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

תשלומים, מנויים ועסקאות חוזרות

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

3. השחקנים בישראל: Green Invoice (מורנינג) מול iCount

שתי המערכות הדומיננטיות לעסקים קטנים בישראל עם API שמתועד טוב הן Green Invoice (שמשווקת היום תחת השם מורנינג) ו-iCount. שתיהן בענן, שתיהן עובדות מול מודל חשבוניות ישראל של רשות המסים, ולשתיהן API שמאפשר להפיק מסמכים מקוד או מאוטומציה. יש כמובן עוד שחקנים (Invoice4U, חשבשבת ועוד), אבל אלה השתיים שאני נתקל בהן הכי הרבה אצל עסקים שמוכרים אונליין.

מה אני בוחר בפועל? לרוב Green Invoice/מורנינג: ה-API שלהם נקי, התיעוד ב-Apiary ברור, וזרימת ה-JWT סטנדרטית. iCount מצוין אם הלקוח כבר עובד איתם או צריך מודול הנהלת חשבונות עשיר יותר, ובזכות ה-node הקהילתי ב-n8n קל לבנות מולה אוטומציה בלי לכתוב את כל קריאות ה-HTTP ידנית. שתיהן עובדות; אל תחליפו ספק רק בשביל ה-API.

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

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

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

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

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

• מ-1 בינואר 2026: חשבוניות מעל 10,000 ש״ח (לפני מע״מ).
• מ-1 ביוני 2026: הסף יורד ל-5,000 ש״ח (לפני מע״מ).

המטרה של המודל היא לצמצם חשבוניות פיקטיביות. המשמעות הטכנית בשבילכם: כשהמערכת מפיקה חשבונית מעל הסף, היא צריכה לפנות לרשות המסים, לקבל מספר הקצאה, ולהטביע אותו על המסמך. החדשות הטובות: Green Invoice ו-iCount עושות את זה בתוך תהליך הפקת המסמך, כך שגם דרך ה-API זה קורה אוטומטית ברוב המקרים. החדשות שדורשות תשומת לב: לפעמים רשות המסים לא מחזירה מספר מיד (תקלה, עומס, אימות), והמסמך נשאר ״ממתין למספר הקצאה״. האוטומציה שלכם חייבת לטפל במצב הזה, לא להניח שכל מסמך מעל הסף יוצא מושלם בקריאה הראשונה.

מה זה אומר לקוד שלכם

• אל תתייחסו לתשובת ה-API כ״הצלחה״ רק כי קיבלתם 200. בדקו את סטטוס המסמך ואת קיום מספר ההקצאה כשהסכום מעל הסף.
• בנו התראה (מייל/Slack/וואטסאפ) למצב ״מסמך הופק אך ללא מספר הקצאה״, שמישהו יטפל ידנית.
• שמרו את ה-document id שחזר, כדי שתוכלו לבדוק סטטוס מאוחר יותר ולהשלים את המספר כשהוא יוקצה.

שימו לב לדקות: הסף הוא לפי סכום העסקה לפני מע״מ, לא הסכום שהלקוח שילם בפועל. עסקה של 5,100 ש״ח לפני מע״מ (כ-5,967 ש״ח כולל מע״מ ב-18%) חוצה את סף יוני 2026, אז אל תבדקו את הסף מול הסכום הסופי בכרטיס האשראי. בנו את הבדיקה על שדה הסכום-לפני-מע״מ.

5. חיבור Green Invoice / מורנינג ב-API: צעד אחר צעד

נעבור על הזרימה המלאה. ההיגיון זהה בכל שפה; הדוגמאות ב-JavaScript/Node כי זה מה שרוב אתרי הלקוחות שלי רצים עליו. הכתובת והמבנה כאן תואמים לתיעוד הרשמי ב-Apiary, אבל לפני שאתם עולים לאוויר תמיד פתחו את התיעוד ותוודאו שאתם מול הגרסה והקודים העדכניים, ספקים מעדכנים שדות מדי פעם.

שלב א׳: מפתחות API

בתוך מורנינג, היכנסו להגדרות ← כלי פיתוח (Development tool). שם תייצרו זוג מפתחות: API key ID ו-API key Secret. את ה-secret רואים פעם אחת, שמרו אותו במשתנה סביבה, לא בקוד ולא ב-git.

# .env  — לא נכנס ל-git
GREENINVOICE_ID=your_api_key_id
GREENINVOICE_SECRET=your_api_key_secret

שלב ב׳: לקבל JWT

ה-API עובד עם טוקן JWT שתקף לשעה בלבד. כל קריאה אמיתית דורשת אותו ב-header בפורמט Authorization: Bearer {JWT}. כשהטוקן פג, קריאה לנתיב מוגן תחזיר 401 Unauthorized ותצטרכו לבקש טוקן חדש.

const BASE = "https://api.greeninvoice.co.il/api/v1";

async function getToken() {
  const res = await fetch(`${BASE}/account/token`, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      id: process.env.GREENINVOICE_ID,
      secret: process.env.GREENINVOICE_SECRET,
    }),
  });
  if (!res.ok) throw new Error(`token failed: ${res.status}`);
  const data = await res.json();
  return data.token; // תקף לשעה
}

טיפ מהשטח: אל תבקשו טוקן חדש בכל קריאה. שמרו אותו במטמון (משתנה/Redis) עם תוקף של ~55 דקות, ורעננו רק כשפג. זה חוסך קריאות מיותרות ומונע rate limiting.

שלב ג׳: להפיק חשבונית מס-קבלה

הפקת מסמך היא קריאת POST /documents. סוג המסמך נקבע בשדה type (קוד מספרי). לפי התיעוד והוובהוקים של מורנינג, חשבונית מס-קבלה היא type: 320. הנה שלד ריאלי:

async function issueInvoiceReceipt(token, order) {
  const body = {
    type: 320,            // 320 = חשבונית מס-קבלה (מאומת מול התיעוד)
    lang: "he",
    currency: "ILS",
    vatType: 0,           // מע"מ רגיל
    client: {
      name: order.customerName,
      emails: [order.customerEmail],
      taxId: order.customerTaxId || undefined, // ת"ז/ח"פ אם יש
      add: true,          // לשמור את הלקוח בכרטיסייה
    },
    income: [{
      description: order.productName,
      quantity: 1,
      price: order.amount,   // מחיר כולל מע"מ או לפני — לפי הגדרת החשבון
      currency: "ILS",
      vatType: 0,
    }],
    payment: [{
      type: 3,            // אמצעי תשלום (אשראי וכו') — אמתו קוד בתיעוד
      price: order.amount,
      currency: "ILS",
    }],
    // הפצה אוטומטית במייל ללקוח
    sendEmail: true,
    emailContent: "תודה על הרכישה! מצורפת החשבונית.",
  };

  const res = await fetch(`${BASE}/documents`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${token}`,
    },
    body: JSON.stringify(body),
  });

  if (!res.ok) {
    const txt = await res.text();
    throw new Error(`document failed: ${res.status} ${txt}`);
  }
  return res.json(); // כולל id, מספר מסמך, קישור PDF, וסטטוס הקצאה
}

הקודים המספריים (סוג מסמך, סוג תשלום, vatType) הם הנקודה היחידה שבה אנשים נופלים. אל תנחשו את הקודים שאתם לא בטוחים בהם, פתחו את התיעוד הרשמי ב-Apiary, מצאו את הטבלה, והעתיקו את הקוד המדויק. שגיאה כאן מפיקה מסמך מהסוג הלא נכון, וזה כאב ראש לתקן אחרי שהמסמך כבר חוקי. עבור iCount הזרימה דומה: שולחים create_doc עם פרמטר doctype (למשל invrec לחשבונית מס-קבלה), אבל שם האימות הוא token/cid במקום JWT.

שלב ד׳: לטפל בתשובה כמו שצריך

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

6. הטריגר: webhook מהסליקה במקום polling

עכשיו השאלה החשובה: מתי מריצים את הקוד מסעיף 5? התשובה הנכונה כמעט תמיד היא webhook, לא בדיקה מחזורית (polling).

הזרימה הנכונה:

1. הלקוח משלם דרך ספק הסליקה (Stripe, מערכת ישראלית, או סליקת מורנינג עצמה).
2. ספק הסליקה שולח webhook לשרת שלכם ברגע שהתשלום אושר.
3. ה-endpoint שלכם מאמת את ה-webhook (חתימה!), שולף את פרטי ההזמנה, ומפיק את המסמך.

// Express endpoint שמקבל webhook מהסליקה
app.post("/webhooks/payment", async (req, res) => {
  // 1. לאמת חתימה — קריטי, אחרת כל אחד יכול לזייף תשלום
  if (!verifySignature(req)) return res.status(401).end();

  const event = req.body;
  if (event.type !== "payment.succeeded") return res.status(200).end();

  // 2. אידמפוטנטיות — לא להפיק מסמך פעמיים לאותו תשלום
  if (await alreadyIssued(event.id)) return res.status(200).end();

  // 3. להפיק
  const token = await getToken();
  const doc = await issueInvoiceReceipt(token, mapOrder(event));
  await saveDocument(event.id, doc);

  res.status(200).end();
});

שלוש נקודות שמפילות כמעט כל אינטגרציה ראשונה:

• אימות חתימה. webhook לא מאומת = מישהו יכול לשלוח לכם ״תשלום הצליח״ מזויף ולקבל חשבונית. כל ספק רציני נותן secret לחתימה, השתמשו בו.
• אידמפוטנטיות. ספקי תשלום שולחים את אותו webhook יותר מפעם אחת (זה תקין ומכוון). בלי בדיקה אם כבר הפקתם, תוציאו חשבונית כפולה. שמרו את ה-event.id ובדקו לפני הפקה.
• להחזיר 200 מהר. אם ה-endpoint איטי או נופל, הספק ינסה שוב ושוב. עדיף לאשר קבלה מהר ולעבד ברקע (תור) אם ההפקה ארוכה.

על בניית webhooks אמינים ואוטומציות בכלל, נכנסתי לעומק בn8n מול Make מול Zapier 2026.

7. הדרך ה-no-code: Make או n8n

לא לכל לקוח יש שרת או מפתח זמין. במקרים רבים אפשר לבנות את אותה אוטומציה בלי קוד, ב-Make (לשעבר Integromat) או ב-n8n. זו דרך לגיטימית לחלוטין ואני בונה ככה הרבה.

הזרימה ב-Make/n8n נראית כך:

1. Trigger — webhook שמקבל את אירוע התשלום (מ-Stripe, מטופס, או מחנות).
2. Filter — להמשיך רק אם הסטטוס ״שולם״.
3. HTTP / מודול ייעודי — לקבל JWT ממורנינג, ואז קריאת POST /documents.
4. Error handler — אם ההפקה נכשלה, לשלוח התראה.

ב-n8n יש יתרון: חבילה קהילתית n8n-nodes-icount נותנת node מוכן ל-iCount עם פעולות כמו יצירת מסמך, עדכון לקוח וביטול, ולמורנינג משתמשים ב-HTTP Request node גנרי או ב-node קהילתי. ל-Make יש מודול ייעודי למורנינג (Morning by Green Invoice), כך שלא תמיד צריך לבנות עם HTTP גולמי. ההבדל המהותי בין הפלטפורמות: n8n אפשר לארח בעצמכם (זול וגמיש), Make הוא SaaS מנוהל (קל יותר להתחיל).

מתי no-code ומתי קוד? הנה איך אני מחליט:

האמת? הרבה פעמים מתחילים ב-no-code כדי לאמת שהזרימה נכונה, ואם הנפח גדל או הלוגיקה מסתבכת, מעבירים לקוד. אין בושה להתחיל פשוט. אם אתם שוקלים בין הכלים השונים, יש לי השוואה מלאה בn8n מול Make מול Zapier שתחסוך לכם התלבטות.

8. טיפול בשגיאות, החזרים, ומקרי קצה

זה ההבדל בין אוטומציה שעובדת בהדגמה לבין אוטומציה שעובדת שנה בלי שתיגעו בה.

החזרים וזיכויים

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

כשל בהפקה

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

• אל תיכשל בשקט. כל כשל הפקה חייב התראה, מייל או הודעה לערוץ ייעודי.
• נסו שוב בחוכמה. שגיאות זמניות (timeout, 5xx) — retry עם השהיה. שגיאות תוכן (4xx, נתון חסר) — אל תנסו שוב, הן לא יסתדרו לבד.
• תור עיבוד. אם הנפח גבוה, אל תפיקו ישירות מה-webhook. דחפו לתור (queue) ועבדו משם, כך כשל בודד לא מפיל את הכל.

לקוח בלי ת״ז/ח״פ

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

עסקאות במטבע זר

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

מצב בדיקות (sandbox)

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

9. בנייה לסביבת ייצור: checklist

לפני שמשחררים לאוויר, אני עובר על הרשימה הזו בכל אינטגרציה:

• [ ] מפתחות ב-environment variables, לא בקוד, לא ב-git.
• [ ] טוקן JWT נשמר במטמון ומתחדש לפני שפג (לא בקשה בכל קריאה).
• [ ] webhook מאומת בחתימה.
• [ ] אידמפוטנטיות, אין הפקה כפולה לאותו תשלום.
• [ ] טיפול במצב ״ממתין למספר הקצאה״ (מעל הסף ל-2026).
• [ ] הבדיקה של סף מספר הקצאה נעשית על הסכום לפני מע״מ.
• [ ] התראה על כל כשל הפקה.
• [ ] retry חכם (זמני כן, תוכן לא).
• [ ] שמירת document id + קישור PDF מקושרים להזמנה.
• [ ] זרימת זיכוי להחזרים (כולל החזר חלקי).
• [ ] טיפול במנוי חוזר: מסמך לכל חיוב חודשי, לא רק הראשון.
• [ ] נבדק ב-sandbox לפני production.

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

שאלות נפוצות

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

כן. גם Make וגם n8n מאפשרים לבנות את כל הזרימה, מקבלת webhook של תשלום ועד קריאת ה-API של מורנינג או iCount, בלי שורת קוד אחת. ל-iCount יש אפילו node קהילתי מוכן ב-n8n, ולמורנינג יש מודול ייעודי ב-Make. זה מתאים מצוין לנפח קטן-בינוני; בנפח גבוה או לוגיקה מורכבת, קוד יוצא משתלם יותר.

מה ההבדל בין Green Invoice ל-iCount מבחינת ה-API?

שתי המערכות מספקות REST API מתועד שמאפשר להפיק כל סוג מסמך. Green Invoice (מורנינג) עובדת עם טוקן JWT שתקף לשעה ותיעוד נקי ב-Apiary; iCount עובדת עם מפתח API/token והיא בעלת מודול הנהלת חשבונות עשיר יותר. שתיהן עובדות מצוין, והבחירה לרוב נקבעת לפי איפה רואה החשבון של העסק כבר עובד.

האם האוטומציה מטפלת לבד במספר הקצאה של רשות המסים?

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

מאיזה סכום חייבים מספר הקצאה ב-2026?

מ-1 בינואר 2026 כל חשבונית מס שסכומה מעל 10,000 ש״ח לפני מע״מ חייבת מספר הקצאה, ומ-1 ביוני 2026 הסף יורד ל-5,000 ש״ח לפני מע״מ. הבדיקה היא תמיד על הסכום לפני מע״מ, לא על מה שהלקוח חייב בכרטיס. בלי מספר הקצאה על חשבונית מעל הסף, הלקוח-העוסק לא יוכל לנכות בגינה מס תשומות.

מה קורה אם הלקוח מקבל החזר כספי?

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

למה צריך לאמת את ה-webhook מהסליקה?

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

האם זה ייעוץ חשבונאי?

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

לסיכום

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

1. תסגרו עם רואה החשבון אילו מסמכים נכונים לעסק שלכם (חשבונית מס-קבלה? קבלה? עוסק פטור?).
2. בחרו מערכת — Green Invoice/מורנינג או iCount, רצוי זו שכבר בשימוש.
3. התחילו פשוט — אם אין מפתח, בנו ב-Make או n8n. אם יש backend, כתבו את הזרימה בקוד.
4. חברו לטריגר נכון — webhook מהסליקה, מאומת ואידמפוטנטי, לא polling.
5. טפלו במקרי קצה — מספר הקצאה ממתין, החזרים, מנויים, כשלי הפקה, לפני שמשחררים לייצור.

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