L’esportazione contabile: il file che si chiede solo in caso di verifica, ma che va prodotto in giornata
In Italia, dal 2019 la fatturazione elettronica via SdI (Sistema di Interscambio) è obbligatoria per la quasi totalità delle operazioni B2B, B2C e B2G. Aggiunta ai libri contabili obbligatori (libro giornale, libro inventari, registri IVA) e ai documenti giustificativi, costituisce l’insieme delle prove richieste dall’Agenzia delle Entrate in caso di verifica fiscale. Il problema non è la fatturazione — il SdI la impone — ma la riconciliazione contabile tra le fatture emesse, gli incassi reali, i resi, i rimborsi processore e le scritture contabili che il commercialista deve registrare nel libro giornale.
Sui negozi che auditiamo, 7 su 10 non sanno produrre un’esportazione contabile coerente senza un intervento manuale di diversi giorni. Eppure il calcolo è semplice: contabilità non riconciliata = scritture rifiutate dal commercialista = rischio di rilievi durante una verifica e tassazione su basi stimate, generalmente sfavorevoli all’impresa. Per un negozio WooCommerce o PrestaShop da 500 K€ di fatturato, lo scarto tra una contabilità pulita e un avviso di accertamento può raggiungere decine di migliaia di euro — senza contare le sanzioni del D.Lgs. 471/1997.
Cosa serve esattamente per la conformità contabile e-commerce italiana
Tre obblighi normativi si articolano:
1. La fatturazione elettronica via SdI
Ogni vendita deve generare una fattura elettronica in formato XML FatturaPA, trasmessa al SdI entro 12 giorni dalla data dell’operazione (art. 21 DPR 633/72 e D.Lgs. 127/2015). Il SdI valida la sintassi, la coerenza fiscale (partita IVA emittente, partita IVA destinatario o codice fiscale per i privati) e instrada al destinatario. Le ricevute SdI sono le prove primarie del fatto generatore IVA.
2. I libri contabili obbligatori
Secondo il Codice Civile e il DPR 600/1973:
- Libro giornale: registra cronologicamente tutte le operazioni che incidono sul patrimonio dell’impresa.
- Libro inventari: redatto annualmente, contiene attivo, passivo, conto economico.
- Registri IVA: vendite, acquisti, corrispettivi (per il commercio al dettaglio se applicabile).
Dal 2019, la tenuta può essere tutta digitale a condizione che i libri siano stampabili su richiesta e conservati a norma (art. 7 D.M. 17/06/2014 e art. 39 DPR 633/72).
3. La conservazione digitale a norma
Le fatture elettroniche e i libri contabili devono essere conservati per 10 anni in modalità digitale a norma, con marca temporale e firma digitale, secondo il CAD (Codice dell’Amministrazione Digitale). Conservare semplicemente i PDF su disco è insufficiente: serve un servizio di conservazione sostitutiva accreditato AgID, oppure il servizio gratuito dell’Agenzia delle Entrate (Fatture e Corrispettivi).
L’anatomia di un’esportazione contabile corretta
Per il commercialista, ogni operazione e-commerce si traduce in scritture in partita doppia. Una vendita B2C in Italia tipica mobilita:
15.10.001— Crediti verso clienti (conto generico per B2C ad alto volume)40.10.001— Ricavi vendite merci (o servizi se applicabile)22.05.001 / 002 / 003— IVA a debito per aliquota (22% / 10% / 5% / 4%)40.10.005— Ricavi spese di spedizione (con propria IVA)15.10.100o simile — Conto transitorio incassi (prima del bonifico effettivo)11.10.001— Banca conto corrente (al momento dell’incasso)50.20.005— Commissioni bancarie/processore (Stripe, PayPal, Satispay)
L’esportazione contabile dal negozio deve produrre queste scritture in modo strutturato. Tre regole immutabili:
- Una scrittura validata non può più essere modificata (catena di irreversibilità). Una correzione passa per una controscrittura, mai per modifica dell’originale.
- Il totale dare = totale avere su ogni scrittura (equilibrio contabile).
- I numeri di registrazione sono strettamente sequenziali e continui nel tempo per registro IVA.
È questo ultimo punto che manca sull’80% dei negozi e-commerce: gli ordini sono creati in un ordine, pagati in un altro, rimborsati più tardi. Il mapping verso una contabilità sequenziale esige una normalizzazione rigorosa.
Perché e-commerce e contabilità non vanno d’accordo naturalmente
WooCommerce e PrestaShop tengono una base commerciale: ordini, pagamenti, rimborsi, note di credito, spese di spedizione. Un commercialista ha bisogno di una base contabile: scritture in dare e avere equilibrate, codificate per conto del piano dei conti.
La traduzione dei due modelli passa per sei concetti:
1. Il piano dei conti
I conti sono organizzati secondo i principi contabili OIC e le specificità del piano dei conti aziendale (basato sui codici Civile-fiscali). Esistono modelli standard ma ogni azienda li personalizza con il proprio commercialista.
2. I registri contabili
Al minimo tre flussi distinti:
- Registro IVA vendite: registra la vendita e l’IVA a debito al momento dell’emissione della fattura
- Libro giornale conto banca: registra l’incasso reale sul conto bancario
- Scritture di rettifica: registra le note di credito, resi, commissioni processore, scarti di cambio
3. La data di registrazione vs la data di pagamento
Un ordine pagato il 31 marzo alle 23:59 e incassato da Stripe il 2 aprile deve contabilizzare la vendita su marzo (data del fatto generatore IVA: la consegna o la vendita definitiva) e l’incasso su aprile (data di accredito bancario effettivo). Questo scarto è la causa principale di errori sugli export e-commerce naïf.
4. La gestione dell’IVA
Tre casi pratici:
- Vendita Italia: IVA a debito all’aliquota italiana applicabile (22%, 10%, 5%, 4%)
- Vendita intracomunitaria B2B con n° di partita IVA valido (VIES): IVA a 0% con menzione “inversione contabile/reverse charge”, dichiarazione in modello INTRASTAT
- Vendita intracomunitaria B2C (OSS-IOSS dal 2021): IVA all’aliquota del paese di destinazione se è superata la soglia di 10.000 €/anno UE, dichiarazione tramite lo sportello unico OSS
L’OSS-IOSS è la trappola che fa cadere in non-conformità il 60% dei negozi multi-paese. Non è un export contabile standard: serve un registro separato per paese di destinazione, o conti IVA distinti per aliquota applicabile.
5. Resi e note di credito
Un reso cliente genera una nota di credito (fattura negativa, tipo documento TD04 nel SdI) E una scrittura di rimborso. Le due devono apparire separatamente, con la tracciabilità che punta sull’ordine d’origine. Contabilizzare un reso come “annullamento” della scrittura iniziale non è conforme: rompe la catena di irreversibilità.
6. Le commissioni processore
Un ordine da 100 € pagato tramite Stripe incassa realmente circa 97,10 € sul conto bancario (commissioni Stripe: 1,4% + 0,25 € per una carta UE). I 2,90 € di differenza vanno sul conto “commissioni bancarie” (gruppo 50.20). Senza questa ventilazione, la riconciliazione bancaria è impossibile.
Perché gli export e-commerce nativi non bastano
WooCommerce e PrestaShop dispongono di export CSV nativi degli ordini. Questi export non sono un export contabile per cinque ragioni:
- Nessuna nozione di registro contabile — Una riga = un ordine, non una scrittura dare/avere.
- Nessuna ventilazione per conto del piano dei conti — Gli importi imponibili, IVA, spedizione non sono mappati sui conti ricavi, IVA a debito, costi.
- Nessuna gestione della sequenzialità di scrittura — Niente numerazione continua coerente con il registro IVA.
- Nessuna separazione vendita/incasso — La data di pagamento e la data di emissione fattura sono confuse.
- Nessun trattamento di resi, note di credito e commissioni processore — Queste operazioni sono ignorate o incoerenti.
Risultato pratico: il commercialista riceve un export Excel e impiega 8-12 ore per esercizio a ricostruire le scritture manualmente. Su un negozio con 2.000 ordini/anno, sono tra 1.200 e 1.800 € di prestazione contabile aggiuntiva. Su un negozio con 20.000 ordini/anno, è il commercialista che rifiuta la pratica o fattura 4.000-6.000 € di reintegrazione.
L’architettura di un’esportazione contabile pulita
Un modulo di export contabile serio per WooCommerce o PrestaShop implementa cinque strati:
Strato 1 — Mapping dei conti
L’admin configura il mapping tra le entità e-commerce e i conti del piano dei conti:
- Categoria di prodotto → conto ricavi (merci vs servizi)
- Metodo di consegna → conto ricavi spedizione
- Aliquota IVA → conto IVA a debito per aliquota (22%, 10%, 5%, 4%)
- Metodo di pagamento → conto transitorio incassi, poi banca o sotto-conto per processore
- Commissioni processore → conto costo bancario (con sotto-conti Stripe, PayPal, Mollie, Satispay)
Strato 2 — Generazione delle scritture
Per ogni ordine nel periodo, il modulo genera 3-8 scritture distinte:
- Ricavo imponibile (dare crediti verso clienti, avere ricavi vendite)
- IVA a debito per aliquota (avere IVA a debito 22%/10%/5%/4%)
- Spedizione (avere ricavi spedizione)
- Incasso (dare banca, avere crediti verso clienti) con sfasamento di data
- Commissioni processore (dare commissioni bancarie, avere banca) in scrittura separata
Per una nota di credito, si generano le controscritture, mai una modifica delle originali.
Strato 3 — Numerazione sequenziale stabile
Il numero di registrazione è attribuito secondo un contatore globale persistente, riavviato a ogni esercizio. Una volta esportata, una scrittura conserva il suo numero a vita. Il modulo deve memorizzare questo stato per non rinumerare mai alla rigenerazione.
Strato 4 — Validazione e controlli
Prima dell’export, il modulo verifica:
- Equilibrio dare/avere per scrittura (differenza ≤ 0,01 €)
- Continuità della numerazione (niente buchi né duplicati)
- Conformità del formato (codifica, separatore, date)
- Presenza di tutte le colonne obbligatorie
- Coerenza contabile (i conti usati esistono nel piano dei conti configurato)
Strato 5 — Export e integrazione
Il file finale è prodotto nel formato atteso dal software contabile del commercialista (CSV per TeamSystem, Zucchetti, Fatture in Cloud, Aruba Fatture, o XML proprietari secondo il software). Alcuni moduli calcolano in più un hash SHA-256 per tracciabilità interna.
Le insidie giuridiche da non trascurare
1. Il termine di conservazione
I libri contabili e tutti i documenti giustificativi (fatture, note di credito, giustificativi bancari) devono essere conservati per 10 anni dalla chiusura dell’esercizio (art. 2220 c.c. e art. 22 DPR 600/73). Per un negozio e-commerce, questo include gli export SQL del database, le fatture elettroniche XML, e i log di pagamento del processore. La strategia di backup deve coprire questa retention lunga: vedi il nostro articolo sul backup PrestaShop regola 3-2-1.
2. La tenuta della contabilità deve essere cronologica
Art. 2219 c.c.: “Tutte le scritture devono essere tenute secondo le norme di un’ordinata contabilità, senza spazi in bianco, senza interlinee e senza trasporti in margine”. Un modulo che permette di “rigenerare” un esercizio chiuso non è conforme. Una volta che l’esercizio è chiuso dal commercialista, le scritture sono congelate.
3. Le sanzioni in caso di non conformità
Se i libri contabili non sono prodotti correttamente durante una verifica, l’Agenzia delle Entrate può procedere a un accertamento induttivo basato su parametri stimati (art. 39 DPR 600/73). Le sanzioni del D.Lgs. 471/1997 possono raggiungere dal 90% al 180% dell’imposta dovuta, più gli interessi.
4. GDPR e dati contabili — la tensione con il diritto all’oblio
L’art. 17 del GDPR permette a un cliente di chiedere la cancellazione dei suoi dati. Ma l’obbligo contabile impone 10 anni di conservazione. La risoluzione giuridica: si conservano i dati necessari all’obbligo legale (nome, indirizzo di fatturazione, importi, codice fiscale o partita IVA per le fatture) e si cancella il resto (preferenze, storico di navigazione, marketing). È il tema preciso che trattiamo nell’articolo di domani sul diritto all’oblio GDPR senza rompere la traccia fiscale.
WooCommerce e PrestaShop: due logiche di implementazione
WooCommerce — la specificità italiana
WooCommerce è concepito per il mercato US, dove il SdI e i libri contabili italiani non esistono. L’export contabile italiano esige quindi un plugin di terze parti che sappia leggere gli ordini WC, i loro item, le loro tasse (tramite il sistema wc_tax_rate) e che sappia mappare i payment gateway sui conti bancari. Il modulo per WooCommerce implementa questa logica con un mapping configurabile, la gestione HPOS (High-Performance Order Storage) e il supporto dei rimborsi WC nativamente. Per la fatturazione elettronica SdI specifica, plugin come “WooCommerce Fatture Elettroniche” (di terze parti italiane) o integrazioni con Fatture in Cloud / Aruba Fatture sono complementari.
PrestaShop — supporto multilingue e multidevise nativo
PrestaShop, sebbene originalmente concepito in Francia, gestisce nativamente le aliquote IVA, i conti ausiliari clienti, le fatture e note di credito sequenziali (ps_order_invoice, ps_order_slip). Il lavoro del modulo di export contabile è quindi più semplice: trasformare le invoice e slip in scritture contabili, senza dover ricalcolare le IVA. Il modulo DataFirefly Accounting Export implementa questa logica con il supporto multi-shop, multilingue, multivaluta. Per la fatturazione elettronica SdI, moduli italiani specializzati (es. moduli per il SdI dell’addons marketplace PrestaShop) sono complementari.
Casi particolari da trattare nell’export
Gli ordini B2B con IVA intracomunitaria
Quando un cliente tedesco con un numero di partita IVA UE valido (VIES) acquista, l’IVA italiana è allo 0% con reverse charge. La scrittura deve riflettere questo esplicitamente, con menzione “inversione contabile – art. 41 DL 331/93”, e l’importo deve alimentare la dichiarazione INTRASTAT. Un modulo che tratta queste vendite come B2C italiano non è conforme.
L’OSS-IOSS per il B2C UE
Da luglio 2021, le vendite B2C UE oltre i 10.000 €/anno cumulati esigono l’IVA del paese di destinazione. L’export contabile deve far apparire un conto IVA per paese/aliquota (es. IVA-DE-19 per IVA Germania 19%, IVA-FR-20 per Francia 20%). Senza questa ventilazione, la dichiarazione OSS trimestrale è impossibile.
Gli abbonamenti e l’IVA temporale
Per un negozio con abbonamenti, l’IVA è dovuta in proporzione alla prestazione. Un abbonamento annuale a 120 € sottoscritto il 15 ottobre genera: 24 € di ricavo e 5,28 € di IVA sull’esercizio corrente (ott-nov-dic), poi 96 € di ricavo e 21,12 € di IVA ripartiti sull’esercizio successivo. Il modulo deve poter generare queste scritture di risconti passivi.
I buoni regalo e gift card
Vendere un buono regalo da 50 € non è una vendita — è un impegno futuro. La scrittura iniziale è debito verso il cliente (conto debiti diversi), non ricavo. Al momento dell’utilizzo del buono, si chiude il debito e si registra il ricavo. È sottile e il 90% degli export automatici sbaglia.
Workflow consigliato: il passaggio allo studio di commercialista
La buona pratica osservata dai negozi che hanno passato senza problemi la loro ultima verifica fiscale:
- Mapping iniziale con lo studio — Una sessione di 2h con il commercialista per validare i conti utilizzati, i registri e il trattamento dei casi particolari (note di credito, commissioni processore, OSS).
- Export mensile — Generazione dell’export contabile mensile, trasmesso allo studio per riconciliazione bancaria e integrazione nella contabilità. Un mese dimenticato è un mese da ricostruire.
- Lettering dei conti ausiliari — Letterare cliente per cliente (o in aggregato per i grandi volumi) per identificare i resi e le note di credito non contabilizzate.
- Chiusura annuale — Export completo dell’esercizio, validazione finale dal commercialista, archiviazione criptata per 10 anni.
- Test di produzione — Una volta all’anno, simulare una richiesta di verifica: generare i libri contabili, verificare che si aprano nel software di controllo del commercialista e che superino le validazioni.
Costo e ROI
Per un negozio con 2.000 ordini/anno, l’equazione economica:
- Modulo di export contabile: 49 € licenza WooCommerce o 99 € licenza PrestaShop
- Setup con lo studio: 200-400 € (mapping iniziale, configurazione dei conti)
- Risparmio su prestazione contabile: 800-1.500 €/anno (reintegrazione manuale evitata)
- Risparmio sul rischio fiscale: non quantificabile ma critico in caso di verifica
Payback di 3-6 mesi sul solo risparmio contabile, senza contare la copertura del rischio.
FAQ
Il mio commercialista usa già un software che importa i miei ordini WooCommerce. Ho bisogno di un modulo di export contabile?
Il software contabile produce le sue proprie scritture a partire da ciò che importa. Ma l’export dal tuo negozio deve essere pulito a monte perché le scritture siano corrette. Un connettore diretto WooCommerce → software contabile (tipo Fatture in Cloud, Aruba Fatture, TeamSystem) può sostituire un modulo di export, ma ha il suo costo (tipicamente mensile) e i suoi limiti di mapping.
Posso tenere la contabilità in Excel e generare un export da Excel?
Legalmente sì, se Excel rispetta i principi della contabilità (irreversibilità in particolare). In pratica, è l’insidia principale: Excel permette di modificare scritture passate, il che rende la contabilità non conforme. L’Agenzia non rifiuta Excel per principio ma chiede garanzie (export PDF marcato temporalmente di ogni chiusura mensile, per esempio). Oltre i 100 ordini/mese, è ingestibile.
Qual è il giusto registro per le commissioni Stripe/PayPal/Satispay?
Il conto “commissioni bancarie e di incasso” (gruppo 50.20) con un sotto-conto per processore (Stripe, PayPal, Mollie, Satispay). La scrittura passa al momento del versamento netto del processore sul conto bancario. Alcuni commercialisti preferiscono passare al libro giornale banca con una riga di commissione — entrambi sono accettati purché coerenti nell’esercizio.
Come gestire le vendite Amazon o eBay che transitano dal mio negozio?
Se l’ordine è creato in WooCommerce/PrestaShop (tramite un connettore marketplace), l’export contabile lo tratta come una vendita normale, con il conto ausiliario = Amazon/eBay (non il cliente finale). Le commissioni marketplace vanno in conto distinto. Se l’ordine non è mai in WC/PS (Amazon FBA puro), rientra nella contabilità Amazon in parallelo — il tuo studio deve allora gestire due flussi.
L’export contabile include l’IRES e l’IVA detraibile sugli acquisti?
No. L’export prodotto da un modulo e-commerce copre solo le scritture risultanti dall’e-commerce (vendite, incassi clienti, commissioni processore). Gli acquisti fornitori, stipendi, contributi, IRES — tutto questo passa per il software contabile dello studio e si fonde con l’export e-commerce nel libro giornale annuale.
In sintesi
La conformità contabile e-commerce in Italia non è un export di più. È un obbligo legale la cui non conformità apre direttamente la porta all’accertamento fiscale. Un modulo di export contabile serio sostituisce 10-30 ore di rielaborazione contabile manuale per esercizio, mette al sicuro i termini di produzione in caso di verifica e dà allo studio del commercialista un file direttamente integrabile nel suo software.
Per WooCommerce, il modulo DfWoo-FEC gestisce il mapping, l’export e i casi particolari (HPOS, OSS, refund). Per PrestaShop, il modulo DataFirefly Accounting Export copre il multi-shop, il multilingue, la multivaluta e le vendite B2B intracomunitarie.
Il giusto riflesso nel 2026: validare con il proprio commercialista il mapping contabile fin dall’installazione del modulo, esportare mensilmente e fare un test annuale di produzione dei libri contabili. Un’ora di disciplina mensile che evita settimane di stress in caso di verifica.