התאמת חשבוניות של צד שלישי (3PL): ביקורת על חשבון המשלוח שלך

החשבונית של ה-3PL שלך מורכבת על ידי תוכנה, מוזנת על ידי בני אדם, ולא נבדקת על ידי אף אחד - עד שאתה בודק אותה.

---

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

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

פוסט זה הוא מערכת עבודה להתאמת חשבוניות 3PL: חמש בדיקות שאתה מריץ כל חודש בכ-30 דקות, דוגמה מעשית לחשבונית שהגיעה ב-23% יותר מהמודל, ו - מכיוון שהתרגיל משתלם פעמיים - היכן כל חלק מהחשבונית הזו שייך בספרים שלך. אם עדיין לא הפנמת מה כל סוג תשלום הוא, קרא קודם איך תמחור 3PL באמת עובד. הפוסט ההוא הוא האנטומיה. זהו הבדיקה הפיזית.

השקר: "זה נוצר על ידי המערכת, אז זה נכון"

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

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

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

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

ה-3PL Invoice Reconciliation Runsheet: חמש בדיקות חודשיות

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

בדיקה 1: התאמת ספירת הזמנות

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

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

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

בדיקה 2: אחסון מחויב לעומת תפוסה בפועל

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

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

בדיקה 3: בדיקות מדגמיות של חיובים נוספים

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

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

בדיקה 4: בדיקת גרסת תעריפים

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

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

בדיקה 5: מעקב אחר זיכויים

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

לזיכויים שהובטחו יש נטייה לא להתממש עד לבקשה השנייה או השלישית. זה נדיר שזה זדון — תעודת הזיכוי שלך היא כרטיס בעדיפות נמוכה בתור של מישהו אחר. היומן הופך "אני חושב שהם חייבים לנו משהו" ל"זיכוי עבור חשבונית 4417, 364$, הובטח ב-12 ביוני, לא התקבל" — מה שמשולם.

דוגמה מעשית: החשבונית שהגיעה ב-23% יותר

הנה ה-runsheet מיושם. כל המספרים הם מספרים עגולים פיקטיביים — חנות שמבצעת כאלף הזמנות בחודש, עם מודל עלויות שנבנה מכרטיס התעריפים החוזי שלה (תרגיל המידול מפוסט אנטומיית התמחור). המודל הצביע על כ-9,800$. החשבונית הצביעה על 12,054$ — 23% יותר. "סקאם-אנד-פיי" היה אוכל את כל העודף. ה-runsheet פיצל אותו:

ממצא	בדיקה שזיהתה זאת	סכום
83 איסופים ראשונים יותר שחוייבו מאשר הזמנות שנשלחו (איסופים בהזמנות שבוטלו ומשלוחים חוזרים שחוייבו פעמיים)	ספירת הזמנות תואמת	249$ זיכוי
52 עמדות משטחים שחוייבו; הפורטל מראה 41 תפוסות	אחסון לעומת תפוסה	220$ זיכוי
חיוב עונת שיא הופעל מחוץ לחלון השיא החוזי	בדיקת חיוב עונת שיא	364$ זיכוי
איסופים נוספים שחוייבו ב-0.95$ לעומת 0.75$ חוזיים (כרטיס תעריפים חדש, ללא הודעה מוקדמת)	בדיקת גרסת כרטיס תעריפים	80$ זיכוי
פרויקט תיוג מחדש (נ requested וצוטט)	לגיטימי	$450
תמהיל חבילות כבד יותר ופיזור אזורי לא נוח במשלוח	לגיטימי	$891
שארית שונות לעומת המודל (תמהיל, עיגול)	לגיטימי	0$ נטו

913$ מתוך 2,254$ העודף היו שגיאת חיוב — כ-7.6% מהחשבונית. השאר היו עלויות אמיתיות שהמודל לא חזה: פרויקט שהחנות ביקשה, ותמהיל משלוחים שהשתנה. ההבחנה הזו היא הנקודה של התרגיל. הביקורת אינה "להילחם בכל עלייה" — היא "לדעת אילו עליות אמיתיות", כדי שתצוד את 913$ ותבצע מידול מחדש עבור 1,341$, כי תמהיל משלוחים כבד באופן קבוע הוא בעיית שולי רווח, לא בעיית חיוב. (אם הממצאים הם עלות אמיתית ולא שגיאת חיוב, זה תיקון אחר: השוואת ספקים לפי פרופיל ההזמנה בפועל שלך.)

צד הספרים: חשבונית אחת, ארבעה יעדים

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

• איסוף ואריזה, דמי חשבון, קבלה — הוצאות תפעוליות של fulfillment. זוהי עלות העבודה של הוצאת הזמנות מהדלת. היא גדלה עם נפח ההזמנות, ואתם רוצים לעקוב אחריה כמדד לכל הזמנה.
• חומרי אריזה — סמוך ל-COGS. קופסאות, מעטפות ומילוי הם חלק מעלות אספקת המוצר; חנויות רבות כוללות אותם בעלות המכר כדי שהרווחים ליחידה ישקפו את העלות האמיתית של יחידה שנשלחה. עקביות חשובה יותר מהחשבון המדויק — בחרו טיפול והיצמדו אליו, אחרת מגמת הרווח שלכם לא אומרת כלום. כיצד COGS אמור לזרום מ-Shopify ל-QuickBooks מכסה היכן גבול זה נמצא.
• אחסון — הוצאה תפעולית, נקודה. היא גדלה עם המלאי המוחזק, לא עם יחידות שנמכרו, וזו בדיוק הסיבה שאתם לא רוצים שהיא תסתתר בתוך COGS — רבעון עם מלאי כבד ייראה כמו קריסת רווח.
• משלוח — וכאן הכיוון חשוב. משלוח יוצא (חבילות ללקוחות) הוא הוצאה תפעולית של מכירה. משלוח נכנס (משלוח נכנס למחסן) הוא חלק מעלות המלאי שלכם ושייך ל-COGS כאשר המלאי הזה נמכר. חשבון 3PL יכול להכיל את שניהם, והזמנת משלוח מכולה נכנסת כהוצאת מכירה מקטינה את עלות המוצר שלכם בכל יחידה.

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

מחלוקות וזיכויים בספרים שלך

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

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

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

החשבון הוא טיוטה עד שתקרא אותו

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

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