E-ticaret için Hesap Planı: Kötü Eşleştirme Kararları Vermemek İçin Nasıl Bir Yol İzlenir

Yeni bir Shopify müşterisi alırsınız. QuickBooks Online'da hesap planını oluşturursunuz — beş kategori, mantıklı alt hesaplar, standart konvansiyona uyan hesap numaralandırması. Shopify entegrasyonunu bağlarsınız. Kağıt üzerinde her şey doğru görünüyor.

Sonra ilk Shopify ödemesi gelir.

Shopify bankaya 14.200 $ yatırdı. QuickBooks 15.800 $ Shopify geliri gösteriyor. Shopify panosu 16.100 $ brüt satış bildiriyor. Aynı ayın faaliyetine ait üç farklı rakam, hiçbiri uyuşmuyor. Boşluğu kovalamak için dört saat harcarsınız. Sonunda bulursunuz: banka transferleri olarak kaydedilen ücretler, doğru hesaplara göre gönderilmeyen iadeler, gelirde duran bir vergi toplama tutarı yerine bir yükümlülük. Hesap planında hiçbir şey eksik değildi. Sadece Shopify'ın parayı nasıl hareket ettirdiği için tasarlanmamıştı.

Çoğu Hesap Planı rehberinin dayandığı yanlış varsayım şudur: doğru hesaplar doğru kategorilerde olduğu sürece, mutabakat işe yarayacaktır — bu sadece her ay işi yapma meselesidir. Shopify için bu doğru değil. Hesap adları ve numaralandırma temel gereksinimlerdir. Shopify kitaplarınızın mutabakatını neyin belirlediği, hesap planının Shopify'ın fonları nasıl dağıttığıyla mimari olarak uyumlu olup olmadığıdır — brüt gelir olarak değil, net ödeme olarak. Beş özel eşleştirme kararı, ay sonu kapanışının 30 dakika mı yoksa öğleden sonranın çoğu mu süreceğini belirler.

Ay Sonu Kapanışına Kadar Doğru Görünen Hesap Planı

Çoğu standart hesap planı şablonu — e-ticarete özel olanlar bile — gelirin brüt gelir olarak geldiği varsayımına dayanır. 100 dolarlık bir satış, 100 dolarlık gelir olarak kaydedilir. Ücretler ödendiğinde kaydedilir. Çoğu işletme bu şekilde çalışır.

Shopify bu şekilde çalışmaz.

Shopify, bir müşteri 100 $ ödediğinde size 100 $ göndermez. Size net bir ödeme gönderir — brüt satışlar eksi ödeme işlem ücretleri, eksi iadeler, eksi Shopify işlem ücretleri, bazen sizin adınıza tahsil edilen satış vergisi eksi, hepsi bir ila on dört günlük siparişleri kapsayan tek bir banka transferinde toplanır. Bu ödeme müşterinizin banka hesabına ulaştığında, en az beş farklı finansal olayı temsil eder. Hesap planınızın bu beşini de alıp ayırması gerekir, aksi takdirde her ay mutabakat başarısız olur.

Hesaplar yanlış değil. Mimari yanlış.

Shopify'ın Net Ödeme Yapısı Neden Mimari Bir Sorun

Tipik bir Shopify ödemesinin aslında neleri içerdiğini, kalemler halinde dökümü aşağıdadır:

• Brüt satışlar — ödeme dönemindeki tüm siparişlerden elde edilen ana gelir
• Ödeme işlem ücretleri — Shopify Payments (Temel plan) için çevrimiçi işlem başına tipik olarak %2,9 + 0,30 ABD doları; ödeme öncesinde düşülür
• Shopify işlem ücretleri — mağaza Shopify Payments kullanmıyorsa işlem başına ek %2; eski planlarda yaygındır
• İade edilen tutarlar — ödeme dönemindeki iade edilen siparişler için brüt iadeler
• Pazar yeri aracılı satış vergisi — Shopify'ın topladığı ve satıcı adına doğrudan eyalet yetkililerine ödeyeceği tutarlar (ABD eyaletlerinin çoğunda Shopify pazar yeri aracısıdır)

Entegrasyonunuz, doğrudan yatırılan tutarı “Shopify Satışları” gelir hesabına eşlediğinde, beş olayın tamamını tek bir sayıya indirgemiş olursunuz. Ücretler zaten düşüldüğü için gelir eksik beyan edilir. Ücret giderleri görünmezdir. Vergi tahsilatını gelir olarak kaydettiğiniz için bilanço hayali bir vergi yükümlülüğü taşır.

Çözüm, ay sonunda geçmişi temizlemek değildir. Her bileşenin otomatik olarak doğru hesaba yönlendirilmesi için hesap planını oluşturmak ve bir takas hesabı aracılığıyla banka mevduatına geri bağlamaktır. Bu, beş özel karar gerektirir. Bunları yanlış yapmanın sonraki maliyeti, firmanızın e-ticaret taahhütlerinde boşa harcadığı zamandır.

Kararlar 1 ve 2: Brüt Gelir Hesapları ve Mahsup Hesabı

Karar 1: Mevduat tutarını değil, brüt satışları gelir olarak kaydedin.

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.

Sadece Shopify müşterisi olan bir işletme için temiz bir gelir bölümü şu şekildedir:

• 4100 — Shopify Satışları (brüt, kesintiler öncesi)
• 4110 — Shopify Nakliye Geliri (nakliye müşterilere ücretlendiriliyorsa)
• 4200 — İadeler ve İndirimler (gelir karşıtı)

Gelir hesapları ne satıldığını kaydeder. Banka mevduatı, kesintiler sonrası ne kadar ödendiğini yansıtır. Bu iki sayı yapısal olarak farklıdır ve hesap planınızın bunları birbirine bağlayan bir hesaba ihtiyacı vardır.

Karar 2: Köprü olarak bir takas hesabı kullanın.

Bir satış kaydedildiğinde, brüt tutar Shopify Satış gelir hesabına ve bir varlık olarak takas hesabına işlenir. Shopify net ödemeyi yaptığında, takas hesabı kesintileri (ücretler, iadeler, vergi) alır ve sıfıra iner. Banka mevduatı net ödemeyle tam olarak eşleşir. Her bileşen doğru hesaba yerleşir.

Takas hesabı olmadan, tek bir QBO hesabıyla eşleşmeyen bir banka mevduatını mutabık kılmaya çalışırsınız - çünkü tek bir hesapla eşleşmesi gerekmez. Beş finansal olayın netidir. Teki olmadan bir Shopify mutabakatı üzerinde bir akşam geçiren her mali müşavir, bunun nasıl bir his olduğunu tam olarak bilir.

Her ödeme işlemcisi için bir takas hesabı oluşturun. Müşteriniz Shopify Payments ve PayPal kullanıyorsa, bu iki takas hesabı demektir. Bunları karıştırmak, gelir düzeyinde çözmeye çalıştığınız aynı eşleşmeme sorununu takas düzeyinde yeniden oluşturur.

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.

Kararlar 3 ve 4: Ücret Ayrımı ve İade İşlemleri

Karar 3: Shopify ücretleri tek bir satır kalemi değildir.

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

QBO'da temiz bir ücret yapısı:

• 6100 — Shopify Aboneliği
• 6110 — Shopify İşlem Ücretleri
• 6120 — Ödeme İşleme Ücretleri

Üçünü tek bir hesaba toplamak, mali müşavirlerin %3'lük marj erozyonunun ödeme işlemeden görünmez olduğu defterleri devralmasının yoludur - ta ki biri brüt marjın fiyatlandırma modelinin öngördüğünden neden daha düşük olduğunu sorana kadar. Bunları ayırmak kurulumda hiçbir maliyet getirmez ve sonrasında her incelemede zaman kazandırır.

Karar 4: İadeler orijinal sipariş yerine ödemeye işlenir.

Bir müşteri bir siparişi iade ettiğinde, Shopify iade tutarını bir sonraki mevcut ödemeden düşer. Ayrı bir banka işlemi oluşturmaz - ödemenin net tutarını azaltır. İade ve İndirimler için karşı hesap, iadenin işlendiği zamanda değil, onu içeren ödeme zamanında iade girişini almalıdır.

Mart ayında bir iade işlenmiş ancak iade Nisan ödemesinde görünmüşse, karşı gelir kaydı Nisan ayına aittir. Bunu Mart ayına kaydetmek bir dönem eşleşmemesi yaratır: Mart geliri düşer, ancak Mart banka mutabakatı nakit etkisi Mart ayında gerçekleşmediği için hala dengelenmez. Dönem eşleşmemeleri, defterlerin çözülmesi için tam bir temizlik gerektirene kadar aydan aya birikir.

Karar 5: Satış Vergisi Başlangıçtan İtibaren Bir Yükümlülük Olarak

ABD'deki çoğu eyalette Shopify bir pazar yeri kolaylaştırıcısıdır - yani Shopify müşterilerden satış vergisini toplar ve doğrudan eyalet vergi dairelerine iletir. Satıcı bu paraya asla dokunmaz. Satıcının vergi borcu yoktur; Shopify zaten ödemiştir.

Shopify'nin topladığı satış vergisi, Shopify kontrol panelindeki brüt sipariş toplamlarında görünür, ancak hiçbir zaman satıcının banka hesabına akmaz ve satıcının geliri değildir. Gelir hesabınız vergi dahil brüt sipariş toplamlarını kaydediyorsa, geliri fazla gösteriyor ve bilanço üzerinde hayali bir yükümlülük oluşturuyorsunuz.

Doğru kurulum iki yükümlülük hesabı gerektirir:

• Ödenecek Satış Vergisi — satıcının doğrudan topladığı ve ödediği vergiler için (toptan satış gibi pazar yeri olmayan kanallar veya pazar yeri kolaylaştırıcısı kurallarının geçerli olmadığı eyaletler)
• Pazar Yeri Vergi Kesintisi (veya “Toplanan Shopify Vergisi”) — Shopify'nin satıcı adına topladığı ve ödediği vergiler için; Shopify'nin ödemesiyle yükümlülük ortadan kalktığı için ödeme döngüsünden sonra sıfıra netleşir, satıcının değil

Müşteriniz birden fazla kanalda satış yapıyorsa — Shopify, doğrudan web sitesi, toptan satış — vergi uygulaması kanala göre farklılık gösterir. Tek bir “Ödenecek Satış Vergisi” hesabı, Shopify tarafından işlenen vergi ile satıcı tarafından işlenen vergi arasındaki ayrımı yapamaz ve vergi zamanında bu ayrım önemlidir.

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.

Bir Günde Kapanan Hesap Planı

Beş karar da yerindeyken, ay sonu işlemleri şu şekilde ilerler: her Shopify ödemesi takas hesabından geçer. Brüt satışlar kredisi girer. Ödeme işlem ücretleri, iadeler ve pazar yeri vergi borcu çıkar. Net banka mevduatı kaydedilir. Takas hesabı sıfıra kapanır. Banka mutabakatı, araştırma yoluyla değil, yapı gereği dengelenir.

Bu 20 dakikalık bir işlemdir. Fark, işin hacmi değil — hesap tablosunun veriyi doğru alacak şekilde tasarlanıp tasarlanmadığıdır.

Ön yatırım gerçektir. Bu mimariyi yeni bir müşteri için doğru bir şekilde oluşturmak ilk seferde iki ila üç saat sürer — genel bir şablonu kopyalamaktan daha uzun sürer. Ancak alternatif, bu saatleri veya daha fazlasını her ay, süresiz olarak harcamaktır.

Beş veya on Shopify müşterisi yöneten CPA'lar için bu mimari, tekrarlanabilir bir şablonun temelini oluşturur. Aynı beş karar, QBO'daki her Shopify mağazası için geçerlidir. Bir kez doğru bir şekilde oluşturun ve uygulamayı, her yeni görevle problemi yeniden öğrenmek yerine, uygulama genelinde uygulayın.

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 eşlemeyi otomatik olarak halleder — senkronizasyon, her ödeme döngüsünde brüt satışları, ücret satır öğelerini, iadeleri ve pazar yeri tarafından toplanan vergiyi doğru hesaplarına gönderir, böylece takas hesabı manuel müdahale olmadan kapanır. Hesap tablosunun bu veriyi alacak şekilde doğru yapılandırılması hala gereklidir, ancak yukarıdaki beş karar size tam olarak bu yapıyı verir.

Yeni bir Shopify müşterisi kuruyorsanız veya mutabakatı yapılmayan bir defter devralıyorsanız, ilk bakmanız gereken beş yer burasıdır. Yukarıdaki kararlardan herhangi biri verilmediyse, dört saatlik mutabakatın nedeni budur. Hesap planını doğru ayarlamak, mali müşaviriniz istediğinde vergiye hazır defterlere sahip olmanın da temelini oluşturur — ay sonunu temiz yapan aynı beş karar, yıl sonunu da basit hale getirir. LedgerPort'un çoklu müşteri uygulaması genelindeki eşleştirmeyi nasıl yönettiğini ledgerport.com/cpas adresinde görün veya ücretsiz başlayın.