- 1מדוע הזמנות סיטונאיות הורסות הנהלת חשבונות קמעונאית
- 2השקר: "מכירה היא מכירה"
- 3הנהלת חשבונות בתנאי אשראי ב-QuickBooks: חשבונית, חוב פתוח, תשלום
- 4גיל הלקוחות הוא לוח המחוונים האמיתי של תזרים המזומנים שלך
- 5פיקדונות כנגד הזמנות סיטונאיות
- 6היגיינת גבייה: ההרגלים המשעממים שגורמים לך לקבל תשלום
- 7שילוב קמעונאות + סיטונאות: בעיית שני סוגי העסקאות
הנהלת חשבונות בתנאי אשראי ב-QuickBooks מסתכמת בהחלפה אחת — החשבונית מחליפה את קבלת המכירה — ודוח אחד שאתה בודק כל שבוע.
הזמנת הרכש הגיעה ביום שלישי, והיא הייתה הטובה ביותר שקיבלת אי פעם: רשת מכוני כושר עם ארבעה סניפים, 300 יחידות במחירי סיטונאות, 9,600 דולר בתנאי נטו-30. שיגרתם אותה ביום חמישי. QuickBooks רשמה מכירה של 9,600 דולר באותה צורה שבה היא רושמת כל דבר אחר בחנות שלך, והרווח וההפסד של מרץ יצאו מרהיבים.
ואז הגיע אפריל. שכירות, הזמנת מלאי מחדש, הוצאות פרסום — הכל אמיתי, הכל דרוש עכשיו. 9,600 הדולר עדיין היו מספר בדוח. הספרים שלך אמרו שמרץ היה החודש הגדול ביותר שלך אי פעם; חשבון הבנק שלך אמר שהמזומנים שלך היו מוגבלים יותר ממה שהיו כל השנה — ושום דבר ש-QuickBooks הראתה לך לא יכול היה לומר מי חייב לך מה, או מתי זה אמור להגיע.
אם הוספת סיטונאות לחנות קמעונאית — קטלוג B2B ב-Shopify, תוסף סיטונאות ב-WooCommerce — הפער הזה בין "מכירות" ל"מזומנים" הוא בעיית הנהלת החשבונות הראשונה שאתה נתקל בה. זו לא טעות חישובית; היא מבנית. הזמנות בתנאי אשראי הן סוג שונה של עסקה מהזמנות קמעונאיות, והן זקוקות לצורה שונה בספרים שלך. פוסט זה מפרט את הצורה הזו: הנהלת חשבונות בתנאי אשראי ב-QuickBooks באופן תקין, דוח גיל הלקוחות שהופך ללוח המחוונים האמיתי של תזרים המזומנים שלך, פיקדונות והרגלי הגבייה שהופכים הבטחות למזומנים.
מדוע הזמנות סיטונאיות הורסות הנהלת חשבונות קמעונאית
הזמנה קמעונאית היא שתי אירועים המתרחשים באותו רגע: הלקוח קונה, והלקוח משלם. במונחי הנהלת חשבונות, המכירה והתשלום הם רגע אחד — זו הסיבה שהצורה הטבעית של QuickBooks להזמנה קמעונאית היא קבלת מכירה (או סיכום יומי של רבות מהן): הכנסה שנרשמה ומזומנים שהתקבלו, יחד.
הזמנת סיטונאות בתנאי נטו-15, נטו-30, או נטו-60 מפרידה את שני האירועים הללו — לפעמים בשני חודשים. אתה מרוויח את ההכנסה כשאתה שולח; אתה מקבל את המזומנים כאשר תהליך החשבונות לתשלום של הקונה שלך מסתדר. בין הרגעים הללו יושב דבר שהנהלת חשבונות קמעונאית מעולם לא נזקקה לו: חשבונות לקוחות, הלוגרבוק המתמשך של כסף שהרווחת אך עדיין לא קיבלת.
הצורה של QuickBooks עבור עסקה זו היא חשבונית. כאשר אתה מוציא חשבונית להזמנה, QuickBooks מחייבת את החשבונות לקבל וזיכויים את ההכנסות (בתוספת כל חבות מס מכירה): המכירה נמצאת בדוח רווח והפסד שלך, הכסף המגיע נמצא במאזן שלך. כאשר הקונה משלם, אתה רושם תשלום כנגד חשבונית זו - המזומן עולה, החשבונות לקבל יורדים. שתי רשומות, שני תאריכים, והפער ביניהם גלוי. גלוי זה הוא כל המטרה.
קח את הזמנת רשת מכוני הכושר. הוצאה חשבונית ב-14 במרץ בתנאי נטו-30, היא יושבת בחשבונות לקבל עם תאריך יעד של 13 באפריל. הכנסות מרץ שלך כוללות את ה-9,600$, בכנות. המזומן שלך במרץ לא כולל - והספרים שלך אומרים זאת. אין הפתעה באפריל, כי הספרים מעולם לא טענו שהכסף הגיע.
בעלי חנויות נתקלים בבעיה זו באחת משלוש תנוחות: רישום הזמנות סיטונאיות בדיוק כמו הזמנות קמעונאיות וגילוי העיוות חודשים לאחר מכן; שמירה על גיליון אלקטרוני צדדי של "מי חייב לי" שמתרחק מ-QuickBooks; או הגדרת חשבונות לקבל מבוססי חשבוניות כראוי ובדיקת דוח אחד בשבוע. שאר הפוסט הזה הוא הדרך לקבוצה השלישית.
השקר: "מכירה היא מכירה"
הטעות שכמעט כולם עושים בהתחלה היא הגיונית למראה: "מכירה היא מכירה - רשום את ההזמנה כשהיא מגיעה, והכסף יסתדר מעצמו." אז הזמנת נטו-30 נכנסת ל-QuickBooks כמו כל הזמנה קמעונאית: קבלת מכירה, מכירה ותשלום שנרשמים כרגע אחד.
הנה מה שזה עושה בפועל לספרים שלך:
זה ממציא מזומנים שאין לך. קבלת מכירה אומרת ל-QuickBooks שהכסף הגיע. פיד הבנק שלך חולק על כך, כי הוא לא. עכשיו הספרים שלך נושאים הפקדות רפאים, וסילוק הבנק מפסיק לעבוד עד שהצ'ק באמת ינוקה. אם נלחמת בקרב הזה בצד הקמעונאי, שבו תשלום של Shopify לעולם לא תואם את מה שקבלות היום אומרות, הגרסה הסיטונאית היא אותה מחלה עם תקופת דגירה ארוכה יותר.
זה מוחק את החוב. ברגע שקבלת מכירה נרשמת, אף אחד לא חייב לך כלום מבחינת QuickBooks. אין חשבון לקבל, אין תאריך יעד, אין התיישנות. הרישום היחיד שהרשת של מכוני הכושר חייבת לך 9,600$ הוא הזיכרון שלך ושרשור אימיילים. הכפל ב-15 חשבונות סיטונאיים ואתה מנהל פעילות הלוואות - כי לכך מתייחסים תנאי נטו - ללא פנקס.
זה מציג הכנסה שגויה אם אתה מגיש דוחות על בסיס מזומן. בדיווח על בסיס מזומן, הכנסות מחשבוניות נספרות כאשר התשלום מתקבל; הכנסות מקבלות מכירה נספרות מיד. רישום הזמנות בתנאי נטו כקבלות והכנסותיך על בסיס מזומן נוחתות בתקופה הלא נכונה - מוערכות יתר על המידה כעת, עם השלכות המס המגיעות לפני שהמזומן מגיע.
שום דבר מזה לא קורה כי אתה רשלן. הנהלת החשבונות שלך נבנתה לקמעונאות, שבה ההנחה "מכירה = תשלום" נכונה, וסיטונאות שברה את ההנחה מבלי להודיע על כך. התיקון אינו עבודה קשה יותר בתוך מבנה הקמעונאות. זה לתת להזמנות סיטונאיות מבנה משלהן.
הנהלת חשבונות בתנאי אשראי ב-QuickBooks: חשבונית, חוב פתוח, תשלום
הנה המחזור המלא של הזמנת נטו-תנאים ב-QuickBooks Online, שנעשה כראוי:
- צור את החשבונית בעת המשלוח (או כאשר הטריגר המוסכם שלך מופעל). הגדר את תנאי התשלום בחשבונית עצמה — נטו 30, לא ברירת המחדל 'לתשלום עם קבלת החשבונית' — כך ש-QuickBooks יחשב את תאריך היעד ויסווג את החייב כראוי.
- השאר זאת ב-AR, באופן גלוי. חשבונית פתוחה אינה בעיה שיש להסתיר; זה המערכת שעובדת. מאזן הלקוחות שלך מציג כעת את חשבונות הלקוחות כנכס — כסף שנצבר, איסוף ממתין.
- רשום את התשלום כנגד החשבונית כאשר הוא מגיע: קבל תשלום → החל על החשבונית הספציפית → הפקד. לעולם אל תרשום צ'ק סיטונאי כהפקדה עצמאית — הפקדה לא מיושמת משאירה את החשבונית פתוחה וסופרת כפליים את ההכנסה.
- התאם את ההפקדה בפיד הבנק שלך. מכיוון שהתשלום הוחל על חשבונית, ההתאמה נקייה: הפקדה אחת, רישום תשלום אחד, סיימנו.
השוואה מהירה זה לצד זה, מכיוון שהניגוד הוא השיעור:
| הזמנה קמעונאית | הזמנה סיטונאית בתנאי נטו | |
|---|---|---|
| עסקת QuickBooks | קבלת מכירה / סיכום יומי | חשבונית |
| הכנסה שהוכרה | בעת הרכישה | בעת הוצאת חשבונית (בצבירה) |
| מזומן שנרשם | באותו רגע | כאשר התשלום מתקבל |
| נמצא ב-AR? | אף פעם | מתאריך החשבונית ועד התשלום |
| מה יכול להשתבש | אי-התאמות עמלות/תשלומים | התיישנות, אי-תשלום |
היכן זה משתלב בהגדרה הרחבה יותר שלך — תרשים חשבונות, חשבונות הכנסה, מס מכירה — מכוסה במדריך הנהלת חשבונות מסחר אלקטרוני שלנו; חנויות WooCommerce ימצאו את פרטי מבנה החשבונות במדריך הנהלת חשבונות WooCommerce. שכבת הסיטונאות יושבת מעל היסוד הזה, לא במקומו.
גיל הלקוחות הוא לוח המחוונים האמיתי של תזרים המזומנים שלך
ברגע שהזמנות סיטונאיות חיות ב-AR, QuickBooks מספק לך את הדוח שמפעילי הסיטונאות מנהלים את עסקיהם בפועל: סיכום התיישנות A/R — כל לקוח עם יתרה פתוחה, מקובץ לפי מידת האיחור בכסף (נוכחי, 1–30 יום באיחור, 31–60, 61–90, מעל 90).
קרא זאת ככלי לתזרים מזומנים, לא כפורמליות חשבונאית:
- עמודת ה"נוכחי" היא תחזית המזומנים הנכנסים שלך. חשבוניות במסגרת התנאים שלהן — כסף שאמור להגיע בשבועות הקרובים אם הקונים ישלמו בזמן.
- עמודת ה-1–30 באיחור היא רשימת המשימות שלך. חשבונית באיחור טרי בדרך כלל אינה משבר; זה מחלקת תשלומים שזקוקה לדחיפה. אבל היא זקוקה לדחיפה עכשיו — סיכויי הגבייה דועכים עם הזמן.
- עמודות ה-61+ הן רשימת הסיכונים שלך. כסף באיחור של חודשיים ומעלה דורש החלטה, לא תזכורת מנומסת נוספת: הסלמה, משא ומתן מחדש, הפסקת משלוחים, או (עם רואה החשבון שלך) מחיקה.
- עקוב אחר היחס, לא רק אחר הסכום הכולל. יתרת AR גדלה זה בסדר אם היא בעיקר נוכחית והכנסות הסיטונאות גדלות איתה. נתח איחור גדל פירושו שאתה מרחיב אשראי מהר יותר ממה שאתה גובה — הפכת למלווה הזול ביותר של הקונים שלך.
ההרגל פשוט באופן כמעט מביך: פתח את דוח ההזדקנות פעם בשבוע, באותו יום בכל שבוע, ופעל לגבי כל דבר שזז דלי. עשר דקות. זו כל המשמעת - אבל היא קיימת רק אם כל הזמנת תנאי נטו הפכה לחשבונית מלכתחילה. קבלות מכירה לא מזינות לדוח הזה כלום.
פיקדונות כנגד הזמנות סיטונאיות
מערכות יחסים רבות בסיטונאות - במיוחד חשבונות חדשים והזמנות מותאמות אישית גדולות - פועלות על פיקדון: 50% מראש, יתרה בתנאי נטו לאחר המסירה.
האינסטינקט החשבונאי להתנגד: פיקדון אינו הכנסה. עד שתספק, הכסף הזה הוא התחייבות - אתה חייב לקונה את הסחורה או את כספו בחזרה. הדפוס הנקי הוא לרשום פיקדונות לפני מסירה לחשבון התחייבות לקוח-פיקדון (או כזיכוי ברשומת הלקוח), ואז להחיל סכום זה כנגד החשבונית בעת המשלוח, כך שהיתרה הפתוחה של החשבונית תציג רק את מה שעדיין חייב.
רשום את הפיקדון כהכנסה במקום זאת וההכנסה נוחתת בתקופה הלא נכונה - והחשבונית הסופית או סופרת כפליים את המכירה או צריכה להיות מקוצצת ידנית. מסלול ההתחייבות עולה חשבון נוסף אחד בתרשים וחוסך את הפירוק.
היגיינת גבייה: ההרגלים המשעממים שגורמים לך לקבל תשלום
תנאי נטו הם מוצר אשראי, והמוכרים שמקבלים תשלום בזמן מנהלים אותם כמו אחד. שום דבר מזה לא דורש תוכנה; כל זה דורש עקביות.
- שים תנאים על כל חשבונית, בכתב. תאריך יעד, שיטות תשלום מקובלות, כל מדיניות תשלום מאוחר. עמימות נפתרת לטובת הקונה.
- חשבן מיד. כל יום בין המשלוח לחשבונית הוא יום שהוספת לתנאים שלך בחינם.
- הזכר לפני תאריך היעד, לא אחרי. פתק קצר "חשבונית #1042 עומדת ביום שישי" שבוע מראש תופס החלקה במחלקת הנהלת חשבונות כל עוד זה עדיין זול לתקן.
- קבע מגבלות אשראי לכל חשבון - וכובש חשיפה כוללת. החלט כמה הכי הרבה קונה בודד יכול לחייב אותך, וכמה מההכנסה החודשית שלך יכולה להיות בתנאים בבת אחת. חשבונות חדשים מתחילים בקטן (או עם פיקדון) ומרוויחים את דרכם למעלה.
- קבע כלל עצירת משלוח וכבד אותו. אין הזמנות חדשות יישלחו לחשבון עם חשבונית שעברה את תאריך היעד ב-30 יום או יותר. הוחלט מראש, זו מדיניות; הוחלט ברגע, זה משא ומתן שתפסיד.
שילוב קמעונאות + סיטונאות: בעיית שני סוגי העסקאות
כל מה שמעל מניח שאתה יכול לומר לספרים שלך "הזמנה זו היא סיטונאית". הקאץ' הוא שסיטונאות לא מחליפה קמעונאות - היא נוחתת מעליה. אותה חנות, אותו זרם תשלומים: 400 הזמנות קמעונאיות שאמורות להירשם כקבלות מכירה או סיכום יומי, ו-12 הזמנות סיטונאיות שחייבות להירשם כחשבוניות עם AR פתוח.
אם מטפלים ידנית, מישהו בודק כל הזמנה - או שהסנכרון פועל בשיטת "מידה אחת מתאימה לכולם" וטועה בצד אחד. סנכרן הכל כקבלות וה-AR הסיטונאי שלך מתאדה (השקר, אוטומטי). סנכרן הכל כחשבוניות וספרי הקמעונאות שלך מתנפחים עם מאות חשבוניות ששולמו באופן מיידי שהופכות את התאמת התשלומים למכאיבה.
בעיית הניתוב הזו היא בדיוק מה שתיוג הזמנות פותר, והמנגנון שווה להכיר, באיזה כלי שתשתמש. ב-LedgerPort — המוצר שלנו, אז שיפוט בהתאם — זה שניים מחמש שיטות סנכרון ההזמנות. שיטת החשבונית בנויה עבור מוכרים המבוססים על תנאי תשלום: היא יוצרת את חשבונית ה-QuickBooks כאשר ההזמנה מתבצעת ורושמת את התשלום כנגדה כאשר ההזמנה משולמת בפועל — יתרות פתוחות בינתיים, דוח התיישנות מוזן כראוי, שום דבר לא מסומן כתשלום לפני שהוא שולם. ניתוב מבוסס תגים מטפל בחנות המעורבת: טבלת כללים ממפה תגי הזמנה לסוגי עסקאות QuickBooks, כך שהזמנה עם תג wholesale נרשמת כחשבונית, הזמנות retail נרשמות כקבלות מכירה או נכללות בסיכום יומי, ותג do-not-sync מרחיק דוגמאות והזמנות בדיקה מהספרים שלך לחלוטין. אם תוסף הסיטונאי שלך כבר מתייג הזמנות B2B — רובם, כולל Wholesale Suite ב-WooCommerce, יכולים — הניתוב מסתמך על תגים שכבר יש לך. שתי השיטות מושווות ב-הבנת שיטות סנכרון הזמנות, וההגדרה היא תפריט נפתח ב-תצורת הסנכרון. האותיות הקטנות, נאמרות ביושר: ניתוב מבוסס תגים הוא תכונה ברמה גבוהה יותר — תמחור מראה מה נמצא היכן.
לאחר שהיא פועלת: ההזמנה בסך 9,600 דולר נרשמת כחשבונית ביום המשלוח, דוח ההתיישנות מראה אותה עדכנית עד ה-13 באפריל, הזנת הבנק מתאימה את התשלום לחשבונית כשהיא מגיעה, והצד הקמעונאי ממשיך להתקזז כרגיל. הפשרה היא עבודה ישרה מלפנים — תנאים הוחלטו, תגים הוחלו, מיפויים הוגדרו פעם אחת. לאחר מכן, סקירת ההתיישנות של יום שני היא כל העבודה.
הפער הזה שלא יכולת לראות באפריל — החודש הגדול ביותר על הנייר, החודש הצפוף ביותר בבנק — מעולם לא היה בעיית רווחיות. זה היה 9,600 דולר של כסף שנצבר ללא רישום בספרים שיצפה בו. תן לכל הזמנת תנאים נטו חשבונית והפער לא נסגר, אבל הוא הופך גלוי, מתוארך, וניתן לגבייה — וזה הכל.
אם החנות שלך מפעילה גם קופה קמעונאית וגם תנאי סיטונאי, התחל עם התג: ראה כיצד ניתוב מבוסס תגים רושם כל צד כראוי → — או חבר את החנות שלך בחינם ונתב את הזמנת הסיטונאי הבאה שלך כחשבונית במקום קבלה.
