- 1שתי הדרכים שבהן רישום מכירות Shopify בדרך כלל משתבש
- 2מדוע סנכרון הזמנות בודדות נכשל (ונכשל שוב ושוב)
- 3כיצד לרשום מכירות Shopify ב-QuickBooks Online: שיטת סיכום יומי
- 4שלב 1 — הגדר את חמשת החשבונות
- 5שלב 2 — משוך את הנתונים של יום אחד מ-Shopify
- 6שלב 3 — בנה את רשומת היומן (דוגמה עובדת)
- 7שלב 4 — התאם את התשלום
- 8שלב 5 — חזור על הפעולה מדי יום, אמת מדי חודש
- 9האם כדאי לעשות זאת ידנית או להפוך את התהליך לאוטומטי?
- 10מה LedgerPort עושה עם המבנה הזה
- 11מתי רישום מכירות מפסיק להיות משימה
הבעיה אינה הזנת הנתונים שלך. זו שיטת הרישום — ויש סיבה לכך שמקצוענים משתמשים באותה שיטה.
אתה פותח את דוח רווח והפסד שלך ב-QuickBooks Online, ומספר ההכנסות כמעט כפול ממה שאתה יודע שמכרת. אתה בוהה בו. עשית הכל לפי מדריך ההגדרה. ו-QuickBooks אומר לך כעת, בביטחון מוחלט, שהחנות שלך הרוויחה פי שניים כסף ממה שהרוויחה בפועל.
אם הגעת לרגע הזה, כנראה שהגעת אליו באחת משתי דרכים. או שהתחברת ל-QuickBooks Connector הרשמי (או לאפליקציה דומה) ועקבת אחר מסכי ההגדרה — וכעת גם הפקדות בנקאיות וגם קבלות מכירה מסונכרנות נספרות כהכנסה. או שהסנכרון עבד בדיוק כמתוכנן ודחף כל הזמנה בודדת ל-QuickBooks כעסקה נפרדת, והקובץ שלך מכיל כעת 1,800 קבלות מכירה לחודש האחרון בלבד, שאף אחת מהן לא תואמת דבר בהפקדות הבנקאיות שלך.
שני המסלולים מתחילים מאותה אמונה סבירה: "אני רק צריך למצוא את המדריך הנכון ולהזין הכל בזהירות." זה השקר שהפוסט הזה כאן כדי להפריך. הזנה זהירה לא פותרת אף אחת מהבעיות, מכיוון שאף אחת מהבעיות אינה שגיאת הזנה.
שיטת הרישום קובעת הכל. יש מבנה ספציפי — רשומת יומן מסוכמת יומית, הזורמת דרך חשבון מעבר להתאמה לתשלום — שרואי חשבון מקצועיים בתחום המסחר האלקטרוני משתמשים בו כדי לרשום מכירות Shopify ב-QuickBooks Online. זהו גם המבנה שעליו בנויה כל כלי אוטומציה רציני. פוסט זה מפרט בדיוק כיצד הוא פועל, עם דוגמה עובדת שתוכל להעתיק.
שתי הדרכים שבהן רישום מכירות Shopify בדרך כלל משתבש
לפני התיקון, כדאי לדייק לגבי מצבי הכשל, מכיוון שהם נראים שונה אך חולקים גורם שורש.
מצב כשל ראשון: הכנסה כפולה. ההפקדות הבנקאיות שלך מושכות את הפקדות התשלומים של Shopify — נניח, 1,922$ נוחתים ביום שלישי. בינתיים, אפליקציית הסנכרון שלך כבר רשמה את ההזמנות הבסיסיות כקבלות מכירה בסכום כולל של כ-2,000$. אם ההפקדה מסווגת כהכנסה (וזו האינסטינקט הבסיסי של הפיד הבנקאי), QuickBooks מציג כעת כ-3,900$ הכנסה מ-2,000$ מכירות. הכפל זאת בכל הפקדה, בכל שבוע, ודוח הרווח והפסד שלך מתנפח בשקט עד עונת המס, כאשר רואה החשבון שלך מוצא אותו ומחייב אותך על הארכיאולוגיה.
מצב כשל שני: הצפת העסקאות. הסנכרון נכון מבחינה טכנית — כל הזמנה הופכת לקבלה מכירה עם פריטים, פרטי לקוח, הכל. ב-50 הזמנות בחודש, זה בסדר. ב-1,500 הזמנות בחודש, קובץ ה-QuickBooks שלך הופך למחסן של עסקאות בודדות שמאטות דוחות, הופכות התאמה למשחק התאמה סיוטי, ויכולות לדחוף אותך לקצה גבול השימוש של QBO. יש לך פירוט מושלם ואפס בהירות.
תסמינים שונים, אותה סיבת שורש: שתי הגישות מתייחסות להזמנות כיחידת החשבונאות. הן לא. מבחינת הספרים שלך, היחידה שחשובה היא היום — והכסף שבאמת עובר הוא התשלום.
מדוע סנכרון הזמנות בודדות נכשל (ונכשל שוב ושוב)
הנה המנגנון, כי ברגע שתראו אותו, התיקון הופך ברור.
הזמנות הן ברוטו. תשלומים הם נטו. כשלקוח משלם לך 50$, Shopify רושמת הזמנה של 50$. אבל Shopify Payments מורידה את עמלת העיבוד שלה לפני שהכסף בכלל מגיע אליך, מאגדת את העסקאות שלך יחד, מחזיקה אותן לכמה ימים, ואז מפקידה סכום אחד כולל. ההפקדה שמגיעה לבנק שלך היא מכירות ברוטו, פחות החזרים, פחות עמלות, פלוס או מינוס התאמות — שלעיתים קרובות מכסה חלקים משתי הזמנות של ימים שונים. כתבנו פירוט מלא של חוסר התאמה זה בלמה התשלום שלך מ-Shopify לעולם לא תואם למה ש-QuickBooks מציג.
אז כשאתה מסנכרן הזמנות בודדות, אתה יוצר רשומות הכנסה שלעולם לא יתאימו ישירות לשום הפקדה בנקאית. QuickBooks רואה 2,000$ של קבלות מכירה בצד אחד והפקדה של 1,922$ בצד השני, ואין לו מושג שהם קשורים. יש לך שלוש אפשרויות באותו שלב: לקטלג את ההפקדה כהכנסה נוספת (כפילות), להשאיר אותה ללא התאמה לנצח (חשבון בנק שאינו ניתן להתאמה), או לעקוב ידנית אילו הזמנות שייכות לאיזה תשלום, בכל פעם (עבודת יום ראשון בערב שאתה מנסה לברוח ממנה).
כדי להיות הוגנים עם הכלים המעורבים: מחבר ה-QuickBooks הרשמי טוב באמת במה שהוא נועד לו — חנויות בנפח נמוך שרוצות פירוט ברמת ההזמנה ומוכנות לנהל הפקדות באופן ידני. הבעיה היא לא שהוא עשוי בצורה גרועה. הבעיה היא שסנכרון ברמת ההזמנה הוא השיטה הלא נכונה ברגע שהנפח הופך אמיתי.
ניסית את הפתרון הנכון לבעיה כפי שהבנת אותה. הבעיה פשוט הייתה גדולה יותר ממה שהמדריכים הראו.
כיצד לרשום מכירות Shopify ב-QuickBooks Online: שיטת סיכום יומי
השיטה המקצועית נקראת סיכום יומי (תשמעו גם "כניסת יומן מסוכמת יומית" או גישת "סיכום יומי של Shopify ל-QuickBooks"). הרעיון במשפט אחד: רשום את הפעילות של Shopify בכל יום ככניסת יומן אחת שמפקידה את הסכום נטו בחשבון מעבר, ואז התאם את התשלום בפועל מול חשבון המעבר הזה כשהוא מגיע לבנק.
יום אחד של מכירות, כניסה אחת. תשלום אחד, התאמה אחת. שום דבר לא נספר פעמיים, שום דבר לא מציף את הקובץ.
הנה איך לבנות את זה.
שלב 1 — הגדר את חמשת החשבונות
תרשים החשבונות שלך צריך חמישה חשבונות ספציפיים כדי שזה יעבוד. צור אותם ב-QuickBooks תחת הגדרות → תרשים חשבונות → חדש:
| חשבון | סוג | מה הוא מחזיק |
|---|---|---|
| מכירות Shopify | הכנסה | Gross product sales, before anything is deducted |
| החזרים וביטולים | Income (contra) | Refunds, recorded as a negative against sales |
| Shopify Clearing | Bank (or Other Current Asset) | Money Shopify has collected but not yet paid out |
| Shopify Fees | Expense | Payment processing and transaction fees |
| מס מכירה לתשלום | Other Current Liability | Tax you collected and owe to the state — not your money |
The clearing account is the one most people are missing, and it's the hinge of the whole method. It represents the gap between "a customer paid" and "the money reached your bank." If you want the full account structure for an e-commerce business — COGS, shipping income, gateway-specific clearing accounts — our chart of accounts template for e-commerce covers it.
שלב 2 — משוך את הנתונים של יום אחד מ-Shopify
In Shopify admin, go to Analytics → Reports → Finances summary, set the date range to a single day, and pull five numbers: gross sales, refunds, sales tax collected, and (from Finances → Payouts, or the transactions export) the fees Shopify Payments charged on that day's transactions.
[IMAGE: Shopify Finances summary report with a single-day date range, with gross sales, refunds, and taxes highlighted]
שלב 3 — בנה את רשומת היומן (דוגמה עובדת)
Let's use a fictional day with round numbers. On June 3, your store did:
- Gross sales: $2,000
- Refunds issued: $150
- Sales tax collected: $130
- Shopify Payments fees: $58
In QuickBooks: + New → Journal Entry, dated June 3. The Shopify sales journal entry in QuickBooks looks like this:
| חשבון | חובה | זכות |
|---|---|---|
| Shopify Clearing | $1,922 | |
| Shopify Fees | $58 | |
| החזרים וביטולים | $150 | |
| מכירות Shopify | $2,000 | |
| מס מכירה לתשלום | $130 | |
| Totals | $2,130 | $2,130 |
[IMAGE: The completed journal entry in QuickBooks Online, debits and credits balanced at $2,130]
Read what this entry just did. Your P&L now shows $2,000 of sales, $150 of refunds against it, and $58 of fees as an expense — true gross revenue and true costs, not the netted-out mush a deposit gives you. The $130 of tax sits in a liability account, because it was never your money. And $1,922 — exactly what Shopify owes you for the day — is parked in the clearing account, waiting.
שלב 4 — התאם את התשלום
Two days later, a Shopify payout of $1,922 appears in your bank feed. Instead of categorizing it as income, categorize it as a transfer from Shopify Clearing (or record it against the clearing account directly).
The clearing account drops back to zero. The deposit is explained. Nothing was double-counted, and your bank account reconciles to the penny.
If the payout doesn't zero out the clearing account, that's not a flaw in the method — that's the method working. A lingering balance means a fee changed, a refund crossed a payout boundary, or an adjustment happened, and the clearing account just told you exactly how much to go find. Payout matching at scale is its own discipline; we cover it end to end in how to reconcile Shopify payouts in QuickBooks.
שלב 5 — חזור על הפעולה מדי יום, אמת מדי חודש
רשומה אחת ליום, תשלום אחד לכל עסקה. בסוף החודש, שתי המחאות: יתרת חשבון הפיקדון צריכה להיות שווה לכל מה ש-Shopify עדיין לא שילמה (השוו מול תשלומים ממתינים בממשק הניהול של Shopify), וחשבון "חבות מס מכירות" צריך להתאים לדוחות המס שלכם ב-Shopify לפני ההגשה.
זו כל השיטה. בערך 30 שורות בחודש במקום אלפי עסקאות — וכל שורה ניתנת למעקב לדוח ש-Shopify סיפקה לכם.
האם כדאי לעשות זאת ידנית או להפוך את התהליך לאוטומטי?
תשובה כנה: זה תלוי כמעט לחלוטין בנפח ההזמנות, והסף נמוך ממה שרוב האנשים מצפים.
מתחת לכ-100 הזמנות בחודש, סיכומים יומיים ידניים ניתנים לביצוע אמיתי. אפילו אפשר לעשות אותם באופן שבועי. צפו ל-15–20 דקות ביום, או כשעה בשבוע. אם זה המצב שלכם, כל מה שמעל הוא כל מה שאתם צריכים — שמרו את הפוסט הזה במועדפים ולכו על זה.
בין 100 ל-500 הזמנות בחודש, השיטה עדיין עובדת, אבל הקצוות מתחילים להיפרם. החזרים שמגיעים בימים שונים מההזמנות המקוריות שלהם, תשלומים המכסים יומיים של עסקאות, מחלוקת או התאמה מדי פעם — כל אחד מהם הוא פרויקט מחקר קטן. הנהלת החשבונות כבר לא קשה, אבל היא בלתי פוסקת, ושבוע אחד שדילגתם עליו יוצר עומס שקשה להתיר.
מעל 500 הזמנות בחודש, סיכומים יומיים ידניים הופכים למשרה חלקית עם מועד הגשה. זהו הנפח שבו כמעט כולם או מעבירים את זה לרואה חשבון (שיגבה עבור השעות הללו מדי חודש, לנצח) או מבצעים אוטומציה ליצירת הרשומות. אף בחירה אינה שגויה — אבל "אני פשוט אהיה ממושמע לגבי זה" מפסיק להיות תוכנית אמיתית כאן.
עוד דבר אחד, מכיוון שהבינארי שלמעלה שקרי במקצת: בין "הקלדת רשומות יומן ידנית" לבין "סנכרון אוטומטי מלא" יש דרגה אמצעית — ידנית אך מסייעת. דף הסנכרון הידני של LedgerPort מפרט כל הזמנה שטרם סונכרנה, עם טווח תאריכים, סטטוס ומסנני חיפוש. סמנו את ההזמנות שאתם רוצים (או בחרו הכל), לחצו על סנכרן נבחרים, וכל אחת מהן תירשם ב-QuickBooks כעסקה במבנה נכון, עם תוצאת "סונכרן" או "שגיאה" לכל הזמנה כך ששום דבר לא ייכשל בשקט. אפס הזנת נתונים — אבל אתם לוחצים על ההדק.

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

במילים אחרות: דוגמת יוני 3 למעלה, נעשית לכל יום, מבלי שתפתח את דוח הכספים.
ישנה חתיכה עדינה יותר של השיטה הידנית שאוטומציה צריכה לעשות נכון: מתי מכירה נספרת. שלב 2 אמר לך למשוך רק הזמנות ששולמו — החלטת הכרה בהכנסות המסתתרת בתוך מסנן דוח. LedgerPort מקודד את אותה משמעת כמו טריגרים של סנכרון, שנקבעו ב-Sync Config » Orders: הזמנה נרשמת ל-QuickBooks רק כאשר היא עומדת בתנאי סטטוס תשלום וגם בתנאי סטטוס ביצוע. ההגדרה המומלצת לרוב החנויות היא שולם בתוספת (לא בוצע ובוצע) — הכנסה נוחתת ב-QuickBooks ברגע שהכסף באמת זז, ללא קשר למצב המשלוח. הזמנות ממתינות ומורשות אך לא נגבות לא נרשמות, והזמנות מבוטלות נכללות כברירת מחדל, כך שביטולים לעולם לא יופיעו כהכנסה.

דרישת קדם אחת יושבת בין "חמישה חשבונות" ל"ללא ידיים", וזה שווה להזכיר: מיפוי מוצרים. כל מוצר שופיפיי מצביע על פריט QuickBooks, שהוא מה שמנתב הכנסות לחשבון ההכנסה הנכון — וזה חל על כל שיטות הסנכרון, כולל סיכומי יום, לא רק סנכרון פר הזמנה. זה מעבר חד פעמי, לא פרויקט: Auto-Map מתאים את הקטלוג שלך לפריטי QBO לפי SKU או שם מוצר בלחיצה אחת, וכל מה שהוא לא מצליח להתאים נשאר מסומן באופן גלוי כלא ממופה לניקוי ידני במקום לפרסם בשקט במקום הלא נכון. יחד, זו כל סיפור התצורה: הטריגר מחליט מתי מכירה נספרת, המיפוי מחליט היכן היא מפורסמת — ושניהם מוגדרים פעם אחת.
והחודשים שכבר הקלטתם לא נכון? אתם לא מזינים אותם מחדש. דף הסנכרון הידני של LedgerPort דוחף נתונים היסטוריים ל-QuickBooks לפי דרישה — בחרו את הרשומות שאתם משנים (או דחפו את כולן), וחלון התקדמות מציג כל אחת מהן נוחתת. כל שורה נושאת סטטוס סנכרון, וכל מה שכבר סומן כסונכרן מדולג אוטומטית, כך שדחיפה מחדש לאחר תיקון מיפוי לא תיצור כפילויות.

פרטים מעשיים, נאמרים בכנות. ההגדרה לוקחת כ-15 דקות — חברו את החנות, חברו את QuickBooks, אשר את מיפוי החשבון. יש תוכנית חינמית (עד 30 הזמנות בחודש, חנות אחת, סנכרון ידני לפי דרישה), שהיא מספיקה כדי לראות את השיטה פועלת על הנתונים האמיתיים שלכם. תוכנית ה-Growth מתחילה ב-25$ לחודש עבור עד 1,000 הזמנות עם סנכרון יומי אוטומטי; יומני תשלומים וטיפול מלא בעמלות מגיעים בתוכנית ה-Scale מ-67$ לחודש, המכסה עד 5,000 הזמנות ושלוש חנויות עם סנכרון בזמן אמת. פרטים נמצאים בדף התמחור, וכל תוכנית בתשלום נושאת אחריות להחזר כספי של 14 יום — החזר מלא של 100%, ללא שאלות.
פשרה כנה אחת: אם אתם רוצים פירוט ברמת ההזמנה בתוך QuickBooks — כל שם לקוח, כל שורת פריט — כלי מבוסס סיכום בכוונה אינו כזה. כלי סיכום קיימים מכיוון, שעבור ספרים בנפח, הפירוט שייך ל-Shopify והחשבונאות שייכת ל-QuickBooks.
מתי רישום מכירות מפסיק להיות משימה
הנה הגרסה של הסיפור הזה שמסתיימת טוב.
זה השלישי לחודש. דוח רווח והפסד שלכם מציג בדיוק מה מכרתם ביוני — מכירות ברוטו בראש, החזרים ועמלות גלויים כשלהם, מס יושב בחשבון התחייבות היכן שהוא שייך. כל תשלום בפיד הבנקאי שלכם תואם. חשבון הפירוק קורא אפס. רואה החשבון שלכם שולח אימייל בשורה אחת: "הספרים נראים נקיים. לא נדרש ממך דבר."
והחלק המוזר ביותר הוא מה שלא עשיתם. לא הזנתם שום דבר בזהירות. לא מצאתם הדרכה טובה יותר. הפסקתם להקליט מכירות כמו שאתם מפסיקים לשים לב לדלת שכבר לא חורקת — המבנה היה נכון, ולכן המשימה פסקה בשקט מלהתקיים.
אותה רשומה של 2,130$ מ-3 ביוני היא כל הטריק. אתם יכולים לבנות אותה ידנית כל בוקר, או שאתם יכולים לגרום לה להיבנות עבורכם בזמן שאתם ישנים. התחילו בחינם עם LedgerPort — הוא יוצר את הרשומה המדויקת הזו מנתוני החנות האמיתיים שלכם, והראשונה לוקחת כ-15 דקות לראות →
