ई-कॉमर्स के लिए खातों का चार्ट: खराब मैपिंग निर्णय न लेने के तरीके

आप एक नया शॉपिफाई क्लाइंट लेते हैं। आप क्विकबुक्स ऑनलाइन में उनका खातों का चार्ट बनाते हैं — पांच श्रेणियां, समझदार उप-खाते, मानक परंपरा का पालन करने वाली खाता संख्या। आप शॉपिफाई एकीकरण को कनेक्ट करते हैं। कागज पर सब कुछ सही लगता है।

फिर पहला शॉपिफाई भुगतान आता है।

शॉपिफाई ने बैंक में $14,200 जमा किए। क्विकबुक्स में $15,800 शॉपिफाई राजस्व दिखाता है। शॉपिफाई डैशबोर्ड $16,100 सकल बिक्री की रिपोर्ट करता है। तीन अलग-अलग संख्याएं, एक ही महीने की गतिविधि, उनमें से कोई भी सहमत नहीं है। आप अंतर का पता लगाने में चार घंटे बिताते हैं। अंततः आपको यह मिल जाता है: बैंक हस्तांतरण के रूप में दर्ज की गई फीस, गलत खातों के विरुद्ध पोस्ट न की गई वापसी, देनदारी के बजाय राजस्व में बैठी कर संग्रह राशि। खातों के चार्ट में कुछ भी गायब नहीं था। यह बस उस तरह से पैसे ले जाने के लिए नहीं बनाया गया था जिस तरह से शॉपिफाई वास्तव में पैसे ले जाता है।

यहां वह झूठी धारणा है जिस पर अधिकांश CoA गाइड आधारित हैं: यदि आपके पास सही श्रेणियों में सही खाते हैं, तो सुलह काम करेगी — यह हर महीने काम करने का मामला है। यह शॉपिफाई के लिए सच नहीं है। खाते के नाम और संख्याएं टेबल स्टेक हैं। यह निर्धारित करता है कि आपका शॉपिफाई खाता सुलह करेगा या नहीं, यह इस बात पर निर्भर करता है कि खातों का चार्ट वास्तुशिल्प रूप से शॉपिफाई द्वारा धन वितरित करने के तरीके के साथ संगत है या नहीं — सकल राजस्व के रूप में नहीं, बल्कि शुद्ध भुगतान के रूप में। पांच विशिष्ट मैपिंग निर्णय यह निर्धारित करते हैं कि महीने के अंत में क्लोज 30 मिनट लेता है या दोपहर का अधिकांश समय।

खातों का चार्ट जो महीने के अंत तक सही लगता है

अधिकांश मानक खातों के चार्ट टेम्प्लेट — ई-कॉमर्स-विशिष्ट वाले भी — इस धारणा पर बनाए जाते हैं कि आय सकल राजस्व के रूप में आती है। $100 की बिक्री $100 आय के रूप में पोस्ट की जाती है। जब आप उनका भुगतान करते हैं तो शुल्क दर्ज किए जाते हैं। अधिकांश व्यवसाय इसी तरह काम करते हैं।

शॉपिफाई उस तरह से काम नहीं करता है।

जब कोई ग्राहक $100 का भुगतान करता है तो शॉपिफाई आपको $100 नहीं भेजता है। यह आपको एक शुद्ध भुगतान भेजता है — सकल बिक्री घटा भुगतान प्रसंस्करण शुल्क, घटा वापसी, घटा शॉपिफाई लेनदेन शुल्क, कभी-कभी आपके बदले एकत्र किए गए बिक्री कर को घटाकर, सभी एक बैंक हस्तांतरण में बंडल किए जाते हैं जिसमें एक से चौदह दिनों के ऑर्डर शामिल होते हैं। जब वह भुगतान आपके क्लाइंट के बैंक खाते में आता है, तो यह कम से कम पांच अलग-अलग वित्तीय घटनाओं का प्रतिनिधित्व करता है। आपके खातों के चार्ट को सभी पांच को प्राप्त करने और अलग करने की आवश्यकता है, या हर महीने सुलह विफल हो जाएगी।

खाते गलत नहीं हैं। आर्किटेक्चर गलत है।

शॉपिफाई की नेट भुगतान संरचना वास्तुशिल्प समस्या क्यों है

एक विशिष्ट Shopify भुगतान में वास्तव में क्या शामिल होता है, यहाँ बताया गया है, जिसे लाइन आइटम के रूप में तोड़ा गया है:

• सकल बिक्री — भुगतान अवधि में सभी ऑर्डर से शीर्ष-पंक्ति राजस्व
• भुगतान प्रसंस्करण शुल्क — आम तौर पर Shopify भुगतान (बेसिक प्लान) के लिए प्रति ऑनलाइन लेनदेन 2.9% + $0.30; वितरण से पहले काटा जाता है
• Shopify लेनदेन शुल्क — यदि स्टोर Shopify भुगतान का उपयोग नहीं कर रहा है तो प्रति लेनदेन अतिरिक्त 2%; पुराने प्लान पर आम
• जारी की गई वापसी — भुगतान अवधि में लौटे ऑर्डर के लिए सकल वापसी
• मार्केटप्लेस-सुविधाजनक बिक्री कर — राशि जो Shopify ने एकत्र की है और व्यापारी की ओर से सीधे राज्य के अधिकारियों को भेजेगी (अधिकांश अमेरिकी राज्यों में, Shopify मार्केटप्लेस सुविधाकर्ता है)

जब आपका एकीकरण जमा को सीधे "Shopify बिक्री" आय खाते में मैप करता है, तो आप सभी पाँच घटनाओं को एक संख्या में समेट रहे होते हैं। आय कम करके आंकी जाती है क्योंकि शुल्क पहले ही काटे जा चुके होते हैं। शुल्क व्यय अदृश्य होते हैं। बैलेंस शीट एक काल्पनिक कर देनदारी रखती है क्योंकि आपने राजस्व के रूप में कर संग्रह दर्ज किया है।

इसका समाधान महीने दर महीने बाद में सफाई करना नहीं है। यह खातों के चार्ट का निर्माण करना है ताकि प्रत्येक घटक स्वचालित रूप से सही खाते में रूट हो जाए — और एक क्लियरिंग खाता उन्हें बैंक जमा से वापस जोड़ता है। इसके लिए पाँच विशिष्ट निर्णय लेने की आवश्यकता होती है। उन्हें गलत करने की डाउनस्ट्रीम लागत वह समय है जिसे आपकी फर्म ई-कॉमर्स एंगेजमेंट पर राइट-ऑफ करती है।

निर्णय 1 और 2: सकल राजस्व खाते और क्लियरिंग खाता

निर्णय 1: सकल बिक्री को आय के रूप में दर्ज करें, जमा राशि के रूप में नहीं।

Your income accounts should reflect what customers actually paid — before Shopify deducts anything. Create separate income accounts for each sales channel (Shopify sales, WooCommerce sales, wholesale revenue) rather than a single “e-commerce sales” bucket. Once you combine Shopify and Amazon revenue into one account, you lose per-channel margin visibility, and there’s no practical way to recover it without rebuilding the books.

केवल Shopify क्लाइंट के लिए एक स्वच्छ आय अनुभाग इस तरह दिखता है:

• 4100 — Shopify बिक्री (सकल, कटौती से पहले)
• 4110 — Shopify शिपिंग आय (यदि ग्राहकों से शिपिंग शुल्क लिया जाता है)
• 4200 — रिटर्न और छूट (विपरीत-राजस्व)

आय खाते वह दर्ज करते हैं जो बेचा गया था। बैंक जमा वह दर्शाता है जो कटौती के बाद भुगतान किया गया था। वे दो संख्याएँ संरचनात्मक रूप से भिन्न हैं, और आपके खातों के चार्ट को एक ऐसे खाते की आवश्यकता है जो उन्हें जोड़ता है।

निर्णय 2: पुल के रूप में एक क्लियरिंग खाते का उपयोग करें।

जब कोई बिक्री दर्ज की जाती है, तो सकल राशि Shopify बिक्री आय खाते और एक परिसंपत्ति के रूप में समाशोधन खाते में पोस्ट हो जाती है। जब Shopify शुद्ध भुगतान जारी करता है, तो समाशोधन खाते में कटौती (शुल्क, वापसी, कर) प्राप्त होती है और शून्य हो जाती है। बैंक जमा शुद्ध भुगतान से बिल्कुल मेल खाता है। प्रत्येक घटक सही खाते में आता है।

समाशोधन खाते के बिना, आप एक बैंक जमा का मिलान करने की कोशिश कर रहे हैं जो किसी एक QBO खाते से मेल नहीं खाता है - क्योंकि यह किसी एक खाते से मेल नहीं खाना चाहिए। यह पांच वित्तीय घटनाओं का शुद्ध है। कोई भी सीपीए जिसने एक के बिना एक शाम Shopify मिलान पर बिताई है, वह ठीक से जानता है कि यह कैसा लगता है।

प्रति भुगतान प्रोसेसर एक समाशोधन खाता बनाएं। यदि आपका ग्राहक Shopify भुगतान और PayPal का उपयोग करता है, तो वे दो समाशोधन खाते हैं। उन्हें मिलाने से आय स्तर पर वह बेमेल समस्या फिर से बन जाती है जिसे आप हल करने की कोशिश कर रहे हैं।

How these two decisions get enforced: product mappings.

Decisions 1 and 2 only hold if the software posting into QBO respects them, and mappings are where that happens. The sequencing rule comes straight from LedgerPort’s own setup docs: build the chart of accounts first, then map. LedgerPort maps to your existing QuickBooks accounts — it doesn’t create accounts behind your back — so the structure you design in this article is the structure the sync respects.

The mapping screen is also where you set revenue granularity. Every product maps to a QBO item, and every item carries an income account. Point many products at one item and you get the simple variant of this template — a single Shopify Sales account. Map products individually and you get per-SKU revenue, plus COGS posting on Inventory-type items. It’s the same decision as “one Sales account vs. per-line revenue accounts,” surfaced as a dropdown.

Two details make this workable in practice. First, the failure mode is safe: an order containing an unmapped product errors with a named status — “Product Not Mapped” — and holds instead of posting to a wrong account, so the template can’t be silently violated. Second, the setup isn’t a week of dropdown clicking: Auto-Map matches Shopify products to QBO items by SKU or name in one click, flags the results for review, and leaves only the misses for manual mapping.

निर्णय 3 और 4: शुल्क पृथक्करण और वापसी प्रबंधन

निर्णय 3: Shopify शुल्क एक एकल पंक्ति मद नहीं हैं।

Three distinct fee types appear in Shopify payouts. Collapsing them into one “Shopify Fees” account loses meaningful visibility into where margin is going:

QBO में एक स्वच्छ शुल्क संरचना:

• 6100 — Shopify सदस्यता
• 6110 — Shopify लेनदेन शुल्क
• 6120 — भुगतान प्रसंस्करण शुल्क

इन तीनों को एक खाते में डालने से सीपीए को ऐसी किताबें मिलती हैं जहाँ भुगतान प्रसंस्करण से 3% मार्जिन का क्षरण अदृश्य होता है - जब तक कि कोई यह न पूछे कि सकल मार्जिन मूल्य निर्धारण मॉडल की भविष्यवाणी से कम क्यों है। उन्हें अलग करने में सेटअप पर कुछ भी खर्च नहीं होता है और बाद में हर समीक्षा में समय बचाता है।

निर्णय 4: वापसी मूल आदेश के बजाय भुगतान के विरुद्ध पोस्ट की जाती है।

जब कोई ग्राहक किसी ऑर्डर को वापस करता है, तो Shopify अगले उपलब्ध भुगतान से वापसी की कटौती करता है। यह एक अलग बैंक लेनदेन नहीं बनाता है - यह भुगतान की शुद्ध राशि को कम करता है। वापसी और छूट के लिए प्रति-राजस्व खाते को उस भुगतान के समय वापसी प्रविष्टि प्राप्त करनी चाहिए जिसमें वह शामिल है, न कि उस समय जब वापसी संसाधित की गई थी।

यदि मार्च में कोई वापसी संसाधित की गई थी लेकिन अप्रैल के भुगतान में वापसी दिखाई दी, तो प्रति-राजस्व प्रविष्टि अप्रैल में आती है। इसे मार्च में पोस्ट करने से अवधि का बेमेल होता है: मार्च का राजस्व घट जाता है, लेकिन मार्च का बैंक मिलान अभी भी संतुलित नहीं होता है क्योंकि नकदी प्रभाव मार्च में नहीं हुआ था। अवधि के बेमेल महीने दर महीने बढ़ते जाते हैं जब तक कि किताबों को सुलझाने के लिए पूरी सफाई की आवश्यकता न हो।

निर्णय 5: बिक्री कर को पहले दिन से देनदारी के रूप में

अधिकांश अमेरिकी राज्यों में, Shopify एक बाज़ार सुविधाकर्ता है - जिसका अर्थ है कि Shopify ग्राहकों से बिक्री कर एकत्र करता है और सीधे राज्य कर अधिकारियों को भेजता है। व्यापारी उस पैसे को कभी नहीं छूता है। व्यापारी कर का बकाया नहीं है; Shopify ने पहले ही इसका भुगतान कर दिया है।

Shopify द्वारा एकत्र किया जाने वाला बिक्री कर Shopify डैशबोर्ड पर सकल ऑर्डर योग में दिखाई देता है, लेकिन यह कभी भी व्यापारी के बैंक खाते में प्रवाहित नहीं होता है और यह व्यापारी का राजस्व नहीं है। यदि आपका आय खाता कर सहित सकल ऑर्डर योग दर्ज करता है, तो आप आय को बढ़ा-चढ़ाकर बता रहे हैं और बैलेंस शीट पर एक काल्पनिक देनदारी बना रहे हैं।

सही सेटअप के लिए दो देनदारी खातों की आवश्यकता होती है:

• बिक्री कर देय — व्यापारी द्वारा सीधे एकत्र और भुगतान किए जाने वाले कर के लिए (मार्केटप्लेस चैनल जैसे थोक, या वे राज्य जहां मार्केटप्लेस सुविधाकर्ता नियम लागू नहीं होते हैं)
• मार्केटप्लेस कर रोका गया (या “Shopify कर एकत्र किया गया”) — व्यापारी की ओर से Shopify द्वारा एकत्र और भुगतान किए जाने वाले कर के लिए; भुगतान चक्र के बाद शून्य हो जाता है क्योंकि देनदारी Shopify के भुगतान द्वारा समाप्त हो जाती है, व्यापारी द्वारा नहीं

यदि आपका ग्राहक कई चैनलों पर बेचता है — Shopify, सीधी वेबसाइट, थोक — तो प्रत्येक चैनल के लिए कर उपचार अलग होता है। एक एकल “बिक्री कर देय” खाता Shopify-हैंडल किए गए कर और व्यापारी-हैंडल किए गए कर के बीच अंतर नहीं कर सकता है, और कर समय पर यह अंतर मायने रखता है।

In LedgerPort, Decision 5 ships as a setting rather than a monthly discipline. The Taxes tab of the sync configuration has a Line Item Tax option: platform-collected tax posts as its own line on the QuickBooks transaction, routed to a liability account you pick from a dropdown. “Tax is a liability, not income” stops being a rule someone has to remember and becomes the only way the sync can post.

The same tab holds the detail nobody explains: tax rounding. The platform’s tax math and QuickBooks’ tax math disagree by a cent or two on some orders, and without a home for those cents the books drift a few cents per order into an unreconcilable smear. The Tax Rounding setting adds a rounding-adjustment line item that absorbs the difference — which is why the books tie to the cent instead of “close enough.” Close enough doesn’t close.

खातों का चार्ट जो एक दिन में बंद हो जाता है

जब सभी पांच निर्णय हो जाते हैं, तो महीने के अंत में इस तरह चलता है: प्रत्येक Shopify भुगतान क्लियरिंग खाते के माध्यम से रूट होता है। सकल बिक्री क्रेडिट में। भुगतान प्रसंस्करण शुल्क, रिफंड, और मार्केटप्लेस कर डेबिट में। शुद्ध बैंक जमा पोस्ट किया जाता है। क्लियरिंग खाता शून्य पर बंद हो जाता है। बैंक समाधान शेष होता है — निर्माण द्वारा, जांच द्वारा नहीं।

यह 20 मिनट की प्रक्रिया है। अंतर काम की मात्रा नहीं है — यह इस बात पर निर्भर करता है कि डेटा को सही ढंग से प्राप्त करने के लिए खातों के चार्ट को डिज़ाइन किया गया था या नहीं।

शुरुआती निवेश वास्तविक है। किसी नए ग्राहक के लिए इस आर्किटेक्चर को ठीक से बनाने में पहली बार दो से तीन घंटे लगते हैं — एक सामान्य टेम्पलेट को कॉपी करने से अधिक समय। लेकिन विकल्प यह है कि उन घंटों, या उससे अधिक, हर महीने, अनिश्चित काल तक खर्च किए जाएं।

पांच या दस Shopify ग्राहकों का प्रबंधन करने वाले CPAs के लिए, यह आर्किटेक्चर एक दोहराने योग्य टेम्पलेट की नींव है। वही पांच निर्णय QBO में हर Shopify स्टोर पर लागू होते हैं। इसे एक बार सही ढंग से बनाएं, और आप इसे अभ्यास में लागू कर रहे हैं — प्रत्येक नए जुड़ाव के साथ समस्या को फिर से सीखने के बजाय।

One more decision: the sync method that will post into these accounts

A chart of accounts isn’t finished when the accounts exist. It’s finished when you’ve decided what kind of transaction will post into them. In a sync tool, that decision has a name: the sync method. In LedgerPort it’s one dropdown — Sync Config » Orders » Sync Method, reached from the left sidebar of the app — with five options, and each option asks something different of the chart you just built.

• Sales Receipt — one receipt per order, with line items, taxes, shipping, and discounts, posting into income and the clearing account. No receivables required.
• Invoice — two records per order: the Invoice when it’s placed, a Payment when Shopify marks it paid. Choose this and your chart needs open receivables.
• Estimate — a non-posted record; it touches nothing until converted. The docs are blunt about how rare this is: “If you are unsure whether you need it, you probably do not.”
• Daily Summary — one journal entry per day aggregating all of that day’s orders. Selecting it exposes account-mapping fields right below the dropdown.
• Tag-Based — Shopify order tags route orders to different transaction types (wholesale → Invoice, retail → Sales Receipt, do-not-sync → skipped), so a mixed retail/wholesale store may need both receivables and receipt-side accounts.

Look closely at what Daily Summary does: the moment you select it, the software asks you to name the accounts its daily journal entry will post to. Those mapping fields are this article’s five decisions, rendered as form fields — gross revenue, clearing, fees, refunds, tax. If you built the chart above, you fill them in one pass. If you didn’t, this is the screen where that becomes obvious.

The decision logic is short. Standard DTC store, paid at checkout: Sales Receipt — the docs’ own default, “the right starting point for most stores.” B2B or payment terms: Invoice. High volume — roughly 100 or more orders a day — with an accountant who works from totals: Daily Summary, which is how a 3,000-order month becomes ~30 journal entries instead of 3,000 records.

And the rule that makes this decision safe: changing the sync method never rewrites orders that have already synced. It applies going forward only. Pick a method, watch a payout cycle post through the clearing account, and revisit if the shape is wrong — the books you’ve already closed stay closed.

LedgerPort मैपिंग को स्वचालित रूप से संभालता है — सिंक प्रत्येक भुगतान चक्र पर सकल बिक्री, शुल्क लाइन आइटम, रिफंड, और मार्केटप्लेस-एकत्रित कर को उनके सही खातों में पोस्ट करता है, इसलिए क्लियरिंग खाता मैन्युअल हस्तक्षेप के बिना बंद हो जाता है। डेटा प्राप्त करने के लिए खातों के चार्ट को अभी भी सही ढंग से संरचित करने की आवश्यकता है, लेकिन उपरोक्त पांच निर्णय आपको ठीक वही संरचना देते हैं।

यदि आप क्यूबीओ में एक नया शॉपिफाई क्लाइंट सेट कर रहे हैं - या ऐसी किताबें विरासत में पा रहे हैं जो मेल नहीं खाती हैं - तो ये पांच स्थान हैं जहाँ आपको सबसे पहले देखना चाहिए। यदि उपरोक्त में से कोई भी निर्णय नहीं लिया गया था, तो यहीं से चार घंटे का मिलान आ रहा है। खातों के चार्ट को सही करना भी आपके सीपीए द्वारा मांगे जाने पर टैक्स-तैयार किताबें रखने की नींव है - वही पांच निर्णय जो महीने के अंत को साफ करते हैं, साल के अंत को सीधा बनाते हैं। देखें कि लेजरपोर्ट एक बहु-क्लाइंट अभ्यास में मैपिंग को कैसे संभालता है ledgerport.com/cpas पर, या निःशुल्क शुरुआत करें।