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

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

שירותי פיתוח בלוקצ'יין

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1375
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1349
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    794
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1087
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1032
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1129

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

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

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

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

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

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

אפקט מדיד: זמני סגירת התקופה ופעולות ידניות

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

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

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

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

דרכים לחבר שכר בקריפטו עם הנהלת חשבונות

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

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

אפשרויות חיבור עם מעגל החשבונאות

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

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

שלבי הטמעה: מביקורת תשלומים ועד מסירת נוהל

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

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

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

מה נשאר במעגל: רישומים, רשומות יומן, הרשאות גישה

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

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

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

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

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

לקוח — צוות מבוזר של יותר מ-40 קבלנים בחמישה תחומי שיפוט: חלק קיבלו תשלום בסטייבלקוינים, חלק — בהעברה רגילה. לפני האינטגרציה הרישום נאסף ידנית: ייצוא היסטוריית ארנקים, הצבת שער "בעין" לפי חתך יומי, הקצאת סכומים לפרויקטים ורק אחר כך רשומות יומן. סגירת התקופה ארכה 3–4 ימים, ובכל פעם צצו 2–4% פערים — לרוב בגלל עמלת הרשת שלא נלקחה בחשבון בתשלום.

איך זה היה: הרישום כמשימה נפרדת

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

מה שינו

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

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

מה התוצאה

פעולות ידניות לתשלום אחד — מ-12–15 לבדיקה אחת. סגירת התקופה התקצרה מ-3–4 ימים ליום אחד, והתאמת הנתונים — מלאה: הסכומים בחשבונאות תואמים לבלוקצ'יין עד הספרה האחרונה. רואה החשבון כבר לא אוסף את הרישום, אלא מטפל בחריגים — ברבעון הצטברו בודדים.

במה שונה תשלום בטוקנים מהמרה לפיאט?

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

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

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

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

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

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

ספקות טכניים נפוצים לגבי אינטגרציה של תשלומים

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

איזה שער נכנס לרשומת היומן?

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

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

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

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

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

כיצד מופרדות ההרשאות ומי אחראי לרשומות היומן?

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

נדון בסכמת התשלומים והחשבונאות: ממה מתחילים

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

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

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

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