- 1Il Piano dei Conti che Sembra Corretto Fino alla Chiusura di Fine Mese
- 2Perché la Struttura di Pagamento Netto di Shopify è il Problema Architettonico
- 3Decisioni 1 e 2: Conti dei Ricavi Lordi e Conto di Compensazione
- 4Decisioni 3 e 4: Separazione delle Commissioni e Gestione dei Rimborsi
- 5Decisione 5: Imposta sulle Vendite come Passività Finanziaria Fin dal Primo Giorno
- 6Il Piano dei Conti che si Chiude in un Giorno
- 7One more decision: the sync method that will post into these accounts
Prendi in carico un nuovo cliente Shopify. Costruisci il suo piano dei conti in QuickBooks Online: cinque categorie, sottoconti sensati, numerazione dei conti che segue la convenzione standard. Colleghi l'integrazione Shopify. Tutto sembra corretto sulla carta.
Poi arriva il primo pagamento Shopify.
Shopify ha depositato 14.200 $ in banca. QuickBooks mostra 15.800 $ di ricavi Shopify. La dashboard di Shopify riporta 16.100 $ di vendite lorde. Tre numeri diversi, attività dello stesso mese, nessuno dei quali concorda. Passi quattro ore a inseguire la discrepanza. Alla fine la trovi: commissioni registrate come trasferimenti bancari, rimborsi che non sono stati registrati sui conti giusti, un importo di riscossione delle imposte che si trova nei ricavi invece che in una passività. Al piano dei conti non mancava nulla. Semplicemente non era stato creato per come Shopify muove effettivamente il denaro.
Ecco la falsa supposizione su cui si basano la maggior parte delle guide sul Piano dei Conti: se hai i conti giusti nelle categorie giuste, la riconciliazione funzionerà, è solo una questione di fare il lavoro ogni mese. Non è vero per Shopify. I nomi e la numerazione dei conti sono requisiti di base. Ciò che determina se i tuoi libri contabili Shopify si riconciliano è se il piano dei conti è architettonicamente compatibile con il modo in cui Shopify eroga i fondi, ovvero come pagamento netto, non come ricavi lordi. Cinque specifiche decisioni di mappatura determinano se la chiusura di fine mese richiede 30 minuti o gran parte del pomeriggio.
DIFFERENZA DI TEMPO
4 ore
vs. 30 minuti — stessa chiusura di fine mese
La differenza non è la quantità di lavoro che fai. È se il piano dei conti è stato progettato per ricevere correttamente il pagamento netto di Shopify in primo luogo.
Il Piano dei Conti che Sembra Corretto Fino alla Chiusura di Fine Mese
La maggior parte dei modelli standard di piano dei conti, anche quelli specifici per l'e-commerce, si basa sull'assunto che il reddito arrivi come ricavi lordi. Una vendita di 100 $ viene registrata come 100 $ di reddito. Le commissioni vengono registrate quando le paghi. È così che funziona la maggior parte delle attività.
Shopify non funziona in questo modo.
Shopify non ti invia 100 $ quando un cliente paga 100 $. Ti invia un pagamento netto: vendite lorde meno commissioni di elaborazione dei pagamenti, meno rimborsi, meno commissioni di transazione Shopify, a volte meno imposte sulle vendite riscosse per tuo conto, il tutto raggruppato in un unico bonifico bancario che copre da uno a quattordici giorni di ordini. Quando quel pagamento arriva sul conto bancario del tuo cliente, rappresenta almeno cinque distinti eventi finanziari. Il tuo piano dei conti deve ricevere e disaggregare tutti e cinque, altrimenti la riconciliazione fallirà ogni mese.
I conti non sono sbagliati. L'architettura lo è.
Perché la Struttura di Pagamento Netto di Shopify è il Problema Architettonico
Ecco cosa contiene effettivamente un tipico pagamento Shopify, suddiviso per voci:
- Vendite lorde — fatturato totale da tutti gli ordini nel periodo di pagamento
- Commissioni di elaborazione pagamenti — tipicamente 2,9% + 0,30$ per transazione online per Shopify Payments (piano Basic); detratte prima del versamento
- Commissioni di transazione Shopify — un ulteriore 2% per transazione se il negozio non utilizza Shopify Payments; comuni nei piani più vecchi
- Rimborsi emessi — rimborsi lordi per ordini restituiti nel periodo di pagamento
- Imposta sulle vendite facilitata dal marketplace — importi che Shopify ha riscosso e che verserà direttamente alle autorità statali per conto del commerciante (nella maggior parte degli stati USA, Shopify è il facilitatore del marketplace)
Quando la tua integrazione mappa il deposito direttamente su un conto di ricavo "Vendite Shopify", stai comprimendo tutti e cinque gli eventi in un unico numero. Il reddito è sottostimato perché le commissioni sono già state detratte. Le spese per commissioni sono invisibili. Il bilancio presenta una passività fiscale fantasma perché hai registrato la riscossione delle imposte come ricavo.
La soluzione non è ripulire dopo il fatto mese dopo mese. È costruire il piano dei conti in modo che ogni componente venga instradato automaticamente al conto corretto — e un conto di transito li riconduca al deposito bancario. Ciò richiede cinque decisioni specifiche. Il costo a valle di sbagliare queste decisioni è il tempo che la tua azienda scarica sugli incarichi di e-commerce.
Decisioni 1 e 2: Conti dei Ricavi Lordi e Conto di Compensazione
Decisione 1: Registrare le vendite lorde come ricavo, non come importo del deposito.
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.
Una sezione ricavi pulita per un cliente solo Shopify appare così:
- 4100 — Vendite Shopify (lorde, prima delle detrazioni)
- 4110 — Ricavi spedizioni Shopify (se le spedizioni vengono addebitate ai clienti)
- 4200 — Resi e abbuoni (contro-ricavo)
I conti di ricavo registrano ciò che è stato venduto. Il deposito bancario riflette ciò che è stato pagato dopo le detrazioni. Questi due numeri sono strutturalmente diversi e il tuo piano dei conti necessita di un conto che li colleghi.
Decisione 2: Utilizzare un conto di transito come collegamento.
Il conto di transito è la soluzione architetturale al problema del versamento netto: credito vendite lorde in entrata, addebiti commissioni/resi/imposte in uscita, il deposito bancario netto corrisponde esattamente. Il conto di transito si azzera ogni ciclo di pagamento. La riconciliazione diventa meccanica, non investigativa.
Quando viene registrata una vendita, l'importo lordo viene accreditato sul conto di ricavo Vendite Shopify e al conto di transito come attività. Quando Shopify eroga il versamento netto, il conto di transito riceve le detrazioni (commissioni, resi, imposte) e si azzera. Il deposito bancario corrisponde esattamente al versamento netto. Ogni componente atterra nel conto corretto.
Senza il conto di transito, stai cercando di riconciliare un deposito bancario che non corrisponde a nessun singolo conto QBO, perché non è destinato a corrispondere a nessun singolo conto. È un netto di cinque eventi finanziari. Ogni commercialista che ha passato una serata su una riconciliazione Shopify senza uno sa esattamente come ci si sente.
Crea un conto di transito per ogni processore di pagamento. Se il tuo cliente utilizza Shopify Payments e PayPal, si tratta di due conti di transito. Mescolarli ricrea lo stesso problema di discrepanza a livello di transito che stai cercando di risolvere a livello di ricavi.
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.
Decisioni 3 e 4: Separazione delle Commissioni e Gestione dei Rimborsi
Decisione 3: Le commissioni Shopify non sono una singola voce.
Three distinct fee types appear in Shopify payouts. Collapsing them into one “Shopify Fees” account loses meaningful visibility into where margin is going:
COMMISSIONE DI ABBONAMENTO
Fissa
Commissione piattaforma di $29–$399/mese; non correlata al volume delle transazioni
COMMISSIONE DI TRANSAZIONE
0,5–2%
Addebitata solo se NON si utilizzano Shopify Payments; scompare quando si passa a un altro metodo
COMMISSIONE DI ELABORAZIONE
2.9% + $0.30
Per transazione; la categoria di commissione più grande; riduce direttamente il margine lordo
Una struttura di commissioni pulita in QBO:
- 6100 — Abbonamento Shopify
- 6110 — Commissioni di transazione Shopify
- 6120 — Commissioni di elaborazione pagamenti
Raggruppare tutte e tre in un unico conto è il motivo per cui i commercialisti ereditano libri contabili in cui un'erosione del margine del 3% dovuta all'elaborazione dei pagamenti è invisibile, fino a quando qualcuno non chiede perché il margine lordo è inferiore a quanto previsto dal modello di prezzo. Separarli non costa nulla in fase di configurazione e fa risparmiare tempo in ogni revisione successiva.
Decisione 4: I rimborsi vengono registrati a fronte del pagamento, non dell'ordine originale.
Quando un cliente restituisce un ordine, Shopify deduce il rimborso dal prossimo pagamento disponibile. Non crea una transazione bancaria separata, ma riduce l'importo netto del versamento. Il conto contropartita per Resi e Abbuoni dovrebbe ricevere la voce del rimborso al momento del pagamento che lo contiene, non al momento in cui è stata elaborata la restituzione.
Se un reso è stato elaborato a marzo ma il rimborso è apparso nel pagamento di aprile, la voce contropartita appartiene ad aprile. Registrarla a marzo crea una discrepanza di periodo: le entrate di marzo diminuiscono, ma la riconciliazione bancaria di marzo continua a non quadrare perché l'effetto di cassa non si è verificato a marzo. Le discrepanze di periodo si accumulano mese dopo mese finché i libri contabili non richiedono una pulizia completa per essere districati.
Decisione 5: Imposta sulle Vendite come Passività Finanziaria Fin dal Primo Giorno
Nella maggior parte degli stati degli Stati Uniti, Shopify è un facilitatore di marketplace, il che significa che Shopify riscuote l'imposta sulle vendite dai clienti e la versa direttamente alle autorità fiscali statali. Il commerciante non tocca mai quei soldi. Il commerciante non deve l'imposta; Shopify l'ha già pagata.
L'imposta sulle vendite che Shopify riscuote appare nei totali lordi degli ordini sulla dashboard di Shopify, ma non fluisce mai sul conto bancario del commerciante e non costituisce ricavo per il commerciante. Se il tuo conto entrate registra i totali lordi degli ordini, inclusa l'imposta, stai sovrastimando le entrate e creando una passività fantasma nel bilancio.
La configurazione corretta richiede due conti di passività:
- Imposta sulle vendite dovuta — per le imposte che il commerciante riscuote e versa direttamente (canali non di marketplace come il commercio all'ingrosso o stati in cui non si applicano le regole dei facilitatori di marketplace)
- Imposta sul marketplace trattenuta (o “Imposta Shopify riscossa”) — per le imposte che Shopify riscuote e versa per conto del commerciante; si azzera dopo il ciclo di pagamento perché la passività è estinta dal versamento di Shopify, non da quello del commerciante
Se il tuo cliente vende su più canali — Shopify, sito web diretto, commercio all'ingrosso — il trattamento fiscale differisce per canale. Un singolo conto “Imposta sulle vendite dovuta” non può distinguere tra l'imposta gestita da Shopify e l'imposta gestita dal commerciante, e questa distinzione è importante al momento della dichiarazione dei redditi.
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.
Il Piano dei Conti che si Chiude in un Giorno
Quando tutte e cinque le decisioni sono in atto, le chiusure di fine mese avvengono così: ogni pagamento Shopify transita attraverso il conto di transito. Credito vendite lorde in entrata. Commissioni di elaborazione dei pagamenti, rimborsi e imposte sul marketplace in uscita. Il deposito bancario netto viene registrato. Il conto di transito si chiude a zero. La riconciliazione bancaria è bilanciata — per costruzione, non per indagine.
Questo è un processo di 20 minuti. La differenza non è il volume di lavoro, ma se il piano dei conti è stato progettato per ricevere correttamente i dati.
L'investimento iniziale è reale. Costruire questa architettura correttamente per un nuovo cliente richiede da due a tre ore la prima volta — più tempo che copiare un modello generico. Ma l'alternativa è impiegare quelle ore, o più, ogni singolo mese, indefinitamente.
Per i commercialisti che gestiscono cinque o dieci clienti Shopify, questa architettura è la base di un modello ripetibile. Le stesse cinque decisioni si applicano a ogni negozio Shopify in QBO. Costruiscila correttamente una volta, e la applicherai in tutta la tua attività — non dovrai reimparare il problema con ogni nuovo incarico.
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 gestisce la mappatura automaticamente — la sincronizzazione registra le vendite lorde, le voci di commissione, i rimborsi e le imposte riscosse dal marketplace nei conti corretti per ogni ciclo di pagamento, in modo che il conto di transito si chiuda senza intervento manuale. Il piano dei conti deve comunque essere strutturato correttamente per ricevere tali dati, ma le cinque decisioni sopra riportate ti forniscono esattamente tale struttura.
Se stai configurando un nuovo cliente Shopify in QBO — o stai ereditando libri contabili che non si riconciliano — questi sono i cinque punti da controllare per primi. Se una qualsiasi delle decisioni sopra riportate non è stata presa, è da lì che deriva la riconciliazione di quattro ore. Ottenere il piano dei conti corretto è anche la base per avere libri contabili pronti per le tasse quando il tuo commercialista li richiede — le stesse cinque decisioni che rendono pulita la chiusura di fine mese rendono semplice la chiusura di fine anno. Scopri come LedgerPort gestisce la mappatura in una pratica multi-cliente su ledgerport.com/cpas, o inizia gratuitamente.
