Raggruppare le registrazioni e-commerce in scritture riepilogative

Un venditore online in crescita può generare in pochi giorni migliaia di ordini, pagamenti, rimborsi e commissioni. Se tutti questi eventi vengono esportati senza filtro come singole registrazioni in un sistema contabile, si ottengono lotti di registrazioni enormi. Il volume di dati rende più difficile il controllo, allunga le importazioni e trasforma in fretta le schede contabili in elenchi illeggibili, sia per la contabilità sia per il commercialista.

La soluzione non consiste nel cancellare gli ordini o le fatture sottostanti. Consiste nel distinguere due livelli:

Le singole transazioni operative restano conservate integralmente nel sistema a monte, con numero d'ordine, numero di fattura, aliquota IVA, marketplace, riferimento di pagamento e altri dettagli.

Le registrazioni aggregate riuniscono transazioni singole omogenee e compatibili nel merito per l'export verso il sistema contabile (TeamSystem, Zucchetti, Fatture in Cloud, Danea, DATEV o un altro).

KudTax quindi non unisce più fatture giuridicamente autonome in un nuovo documento di fattura. La descrizione corretta è questa:

KudTax raggruppa ordini, vendite e transazioni omogenei in scritture riepilogative per l'export contabile.

Questa distinzione è decisiva. La fattura resta il documento della singola operazione. La scrittura riepilogativa è una rappresentazione controllata, nel libro mastro, di più operazioni imputate allo stesso modo.

Perché nell'e-commerce le singole registrazioni diventano presto illeggibili

In una classica azienda B2B, 500 fatture di vendita al mese possono corrispondere più o meno a 500 registrazioni di ricavo. Nell'e-commerce la struttura dei dati è diversa. Un solo ordine può generare diversi eventi contabili:

• vendita e IVA,
• spese di spedizione,
• sconto,
• pagamento,
• commissione di pagamento,
• commissione del marketplace,
• rimborso parziale successivo,
• reso,
• chargeback,
• accredito tramite un fornitore di pagamento.

Se un venditore vende su Amazon Germania, Amazon Francia, Shopify ed eBay, il numero di varianti si moltiplica. A questo si aggiungono possibili aliquote IVA diverse, paesi di magazzino, valute e conti di ricavo.

Un export che registra ogni singolo ordine come scrittura a sé su un conto di contabilità generale può essere corretto nel merito. Con volumi molto alti, però, emergono svantaggi pratici:

• lotti di registrazioni DATEV molto grandi,
• schede contabili lunghe con descrizioni ripetitive,
• maggiore lavoro di importazione ed elaborazione,
• visione più difficile dei totali periodici,
• più fatica nel controllare registrazioni omogenee,
• limiti tecnici dei singoli file di importazione,
• report poco leggibili per il cliente e per lo studio.

DATEV indica per i lotti di registrazioni un massimo di 99.999 registrazioni per file. Questo non significa che ogni venditore debba per forza aggregare i propri dati. Con volumi elevati, però, il limite mostra perché un'aggregazione controllata o una suddivisione per periodi può avere un'utilità pratica.

Che cos'è una scrittura riepilogativa nell'e-commerce?

Una scrittura riepilogativa riunisce in un'unica registrazione più operazioni singole con le stesse caratteristiche contabili.

Supponiamo che 1.800 ordini Amazon Germania, nel periodo dal 1° al 15 gennaio, vengano tutti registrati con la stessa logica:

• conto dare: 1800 (piano dei conti tedesco SKR04, esempio),
• conto avere: 4400,
• marketplace: Amazon Germania,
• valuta: EUR,
• trattamento fiscale identico,
• stesso periodo di export.

Invece di produrre 1.800 righe di export, il sistema può sommare gli importi in un'unica scrittura riepilogativa. La registrazione esportata riporta allora, per esempio:

15/01 – 4400 / 1800 – Amazon DE Orders

I 1.800 ordini restano presenti singolarmente nel sistema a monte. La scrittura riepilogativa deve poter essere scomposta in un elenco delle transazioni che contiene.

Una scrittura riepilogativa non è quindi né un nuovo ordine né una nuova fattura. È una registrazione aggregata di libro mastro basata su operazioni singole documentate.

Registrazione singola o scrittura riepilogativa: qual è la differenza?

Caratteristica	Registrazione singola	Scrittura riepilogativa
Numero di righe di export	Una riga per operazione o componente contabile	Una riga per più operazioni omogenee
Livello di dettaglio nel libro mastro	Molto alto	Aggregato
Livello di dettaglio nel sistema a monte	Transazione singola presente	La transazione singola deve restare presente
Scheda contabile	Molte righe singole	Totali periodici o raggruppati
Adatta alle partite aperte	Buona per partite aperte riferite alle fatture	Non adatta a ogni logica clienti
Volume di importazione	Alto	Ridotto
Controllo	Controllo singolo direttamente nel sistema contabile	Controllo tramite scrittura riepilogativa e prospetto di scomposizione
Uso tipico	Fatture B2B, operazioni particolari, partite aperte	Transazioni B2C di massa omogenee e registrazioni di contabilità generale

I due metodi si possono combinare all'interno dello stesso cliente. Le fatture di vendita nel partitario clienti possono essere trasmesse singolarmente, mentre determinati movimenti di contabilità generale o gruppi di vendite B2C già riconciliati vengono esportati in forma aggregata.

Raggruppare le registrazioni è conforme ai GoBD?

I GoBD tedeschi (i principi del diritto tedesco sulla tenuta dei libri in formato elettronico) richiedono in linea di principio che le operazioni siano registrate in modo completo, corretto, tempestivo, ordinato e tracciabile. Di regola prevedono una registrazione singola, in modo che si possano verificare presupposti, contenuto e significato di un'operazione.

Allo stesso tempo, dal punto di vista tedesco, registrazioni riepilogative o aggregate nel libro mastro possono essere ammesse se possono essere scomposte in modo tracciabile nelle singole posizioni delle registrazioni di base o del giornale.

Per una scrittura riepilogativa verificabile questo significa in particolare:

• Ogni transazione originaria resta conservata.
• L'attribuzione a una scrittura riepilogativa è univoca.
• La formazione del totale è riproducibile.
• Criteri, periodo e filtri sono documentati.
• Le modifiche alle transazioni singole e alle scritture riepilogative sono tracciabili.
• Documenti e fatture restano accessibili.
• Le singole posizioni possono essere analizzate in modo automatizzato.
• La funzione utilizzata è descritta nella documentazione delle procedure (Verfahrensdokumentation).

Un'aggregazione non deve rendere impossibile ricostruire il contenuto originario. Il § 239 HGB (codice commerciale tedesco) richiede che le registrazioni originarie restino riconoscibili anche in caso di modifiche.

In Italia non esiste un piano dei conti nazionale obbligatorio: ogni impresa usa il proprio piano dei conti, e il bilancio segue gli artt. 2424–2425 c.c. e i principi OIC. I numeri di conto di questo articolo sono quindi solo esempi del piano dei conti tedesco; il raggruppamento in KudTax si imposta sui conti del tuo piano dei conti.

L'uso concreto va concordato con il proprio studio o commercialista. Non tutte le operazioni si prestano a una scrittura riepilogativa.

In base a quali criteri KudTax può raggruppare le registrazioni?

Al momento dell'export puoi attivare la funzione di raggruppamento e stabilire quali registrazioni confluiscono insieme in una scrittura riepilogativa. I criteri si combinano tra loro. Solo le registrazioni che soddisfano tutte le condizioni scelte finiscono nello stesso gruppo.

Periodo

Sei tu a stabilire il periodo di un gruppo. È possibile, per esempio, una suddivisione in:

• dal 1° al 15 gennaio,
• dal 16 al 31 gennaio.

Ne risultano due registrazioni separate, anche se entrambe riguardano la stessa piattaforma e la stessa imputazione.

Un raggruppamento quindicinale può essere utile quando report, liquidazioni periodiche IVA o controlli interni non devono mostrare solo un totale mensile. A seconda del processo possono avere senso anche raggruppamenti giornalieri, settimanali o mensili.

Conta quale data viene usata per la selezione: data dell'ordine, data della fattura, data della prestazione, data del pagamento o un'altra data della transazione. Questo tipo di data va fissato in modo univoco nel processo di export.

Conto dare e conto avere, ovvero accounting code

Dovrebbero essere raggruppate solo registrazioni con un'imputazione compatibile. KudTax può usare come criterio di raggruppamento gli accounting code, cioè i conti dare e avere.

Per esempio, tutte le registrazioni con:

• conto avere 4400,
• conto dare 1800

possono essere raggruppate all'interno di un periodo definito.

Le registrazioni con un altro conto di ricavo, di imposta, di commissioni o un conto transitorio diverso devono restare in un altro gruppo. Così si evita che operazioni economicamente diverse spariscano in un totale poco chiaro.

Piattaforma

La piattaforma indica il canale di vendita o il sistema di livello superiore, per esempio Amazon, Shopify, eBay o Kaufland.

Un raggruppamento per piattaforma evita che vendite Amazon e Shopify finiscano nella stessa scrittura riepilogativa, anche se magari vengono riconciliate con fonti dati, processi di pagamento e report di controllo diversi.

Marketplace

Una piattaforma può comprendere più marketplace. Su Amazon, per esempio, Germania, Francia, Italia, Spagna o altri paesi sono marketplace distinti.

Il raggruppamento per marketplace permette una separazione chiara:

• Amazon Germania,
• Amazon Francia,
• Amazon Italia.

Questo è particolarmente importante quando entrano in gioco paesi IVA, aliquote, conti di ricavo o valute diversi.

Data di registrazione della scrittura riepilogativa

Sei tu a stabilire quale data riceve la registrazione aggregata nell'export. Per il periodo dal 1° al 15 gennaio, per esempio, si può usare il 15 gennaio come data di registrazione.

La data della scrittura riepilogativa non modifica automaticamente le date originarie di fattura, prestazione o transazione. Queste restano conservate a livello delle singole operazioni. La data scelta serve alla presentazione e all'attribuzione al periodo nell'export contabile e deve essere coerente con la logica contabile del cliente.

Descrizione personalizzata

La descrizione della registrazione può essere definita in modo dinamico o personalizzato. Alcuni esempi:

• Amazon DE Orders 01-15,
• Shopify DE Sales January,
• Amazon FR 20% VAT,
• eBay Payments Week 03.

Una buona descrizione indica con precisione il gruppo senza elencare ogni singolo ordine. DATEV limita il campo descrizione nel lotto di registrazioni a 60 caratteri. I dettagli più lunghi vanno quindi nel prospetto di scomposizione, nelle informazioni aggiuntive o nel sistema a monte.

Esempio pratico: vendite Amazon Germania dal 1° al 15 gennaio

In KudTax scegli le seguenti impostazioni:

Impostazione	Scelta
Periodo	01/01–15/01
Conti	4400 / 1800
Piattaforma	Amazon UE
Marketplace	Germania
Data di registrazione	15/01
Descrizione	Amazon DE Orders

Nel periodo scelto ci sono 2.400 ordini corrispondenti. In base alle regole di registrazione approvate, insieme danno un importo di 142.800,00 €.

Per l'export KudTax genera la scrittura riepilogativa:

15/01 – 142.800,00 € – 4400 / 1800 – Amazon DE Orders

Nel sistema restano conservati, tra l'altro:

• tutti i 2.400 numeri d'ordine,
• i numeri di fattura,
• i singoli importi,
• le date originarie,
• le informazioni su articoli e imposte,
• l'attribuzione al marketplace,
• i riferimenti di pagamento,
• l'attribuzione alla specifica scrittura riepilogativa.

Dal 16 al 31 gennaio si può generare una seconda scrittura riepilogativa con propria data, importo e descrizione.

Esempio esteso con più gruppi

Periodo	Marketplace	Gruppo imposta/conti	Registrazione esportata
01/01–15/01	Amazon DE	DE 19 % / 4400 / 1800	Amazon DE 19% 01-15
01/01–15/01	Amazon DE	DE 7 % / altro conto di ricavo	Amazon DE 7% 01-15
01/01–15/01	Amazon FR	FR aliquota ordinaria / conto proprio	Amazon FR STD 01-15
16/01–31/01	Amazon DE	DE 19 % / 4400 / 1800	Amazon DE 19% 16-31
16/01–31/01	Amazon FR	FR aliquota ordinaria / conto proprio	Amazon FR STD 16-31

L'aggregazione riduce il numero di registrazioni esportate senza mescolare indebitamente aliquote, paesi e conti.

Quali operazioni non si possono semplicemente raggruppare insieme?

Una scrittura riepilogativa non va formata solo perché più importi sono positivi o negativi. Le operazioni sottostanti devono essere compatibili nel merito.

Di regola vanno trattati separatamente:

• conti dare o avere diversi,
• aliquote IVA diverse,
• paesi di imposizione diversi,
• valute diverse,
• operazioni imponibili ed esenti,
• casi B2B e B2C con trattamento diverso,
• vendite e rimborsi, se la logica di controllo richiede una presentazione separata,
• ricavi e commissioni del marketplace,
• pagamenti dei clienti e accrediti bancari,
• chargeback aperti e rettifiche definitive dei ricavi,
• periodi di prestazione o di registrazione diversi,
• vendite nazionali e vendite OSS,
• vendite su marketplace con diverso status di fornitore presunto (deemed supplier),
• singoli clienti da chiudere tramite partite aperte.

Più criteri coincidono all'interno di un gruppo, più la scrittura riepilogativa è solida.

Differenza tra ordini, fatture, transazioni e registrazioni

Ordine

L'ordine documenta che cosa il cliente ha ordinato nel negozio online o sul marketplace. In seguito può essere annullato, suddiviso o modificato.

Fattura

La fattura è il documento giuridico e fiscale di addebito. La funzione di raggruppamento non fonde più fatture autonome in una nuova fattura riepilogativa.

Transazione

Una transazione descrive un evento finanziario od operativo, per esempio pagamento, rimborso, commissione, riserva o accredito. A un ordine possono corrispondere più transazioni.

Registrazione

La registrazione trasferisce l'effetto economico nella contabilità generale. Una registrazione singola può riferirsi a una transazione. Una registrazione aggregata può riunire più transazioni trattate allo stesso modo.

La funzione di KudTax aggrega il livello delle registrazioni dell'export. Non sostituisce né gli ordini né i documenti di fattura.

Quali vantaggi offre l'aggregazione?

Meno registrazioni nel libro mastro

Migliaia di ordini omogenei possono essere riuniti in poche registrazioni controllate per periodo, conto e marketplace.

Schede contabili più leggibili

Invece di righe singole ripetitive, il conto mostra totali periodici chiaramente descritti. I dettagli si possono aprire all'occorrenza nel sistema a monte.

Elaborazione più rapida di grandi volumi di dati

Lotti di registrazioni più piccoli si trasmettono, importano e controllano più facilmente. È particolarmente rilevante quando volumi elevati si avvicinano ai limiti tecnici dei file.

Separazione chiara per marketplace e imputazione

I criteri di raggruppamento evitano che marketplace o gruppi di conti diversi vengano mescolati senza controllo.

Logica di periodo personalizzata

Puoi formare per esempio gruppi quindicinali, settimanali o mensili e fissare la data di registrazione di conseguenza.

Meno lavoro manuale

Lo studio non deve scorrere migliaia di righe di registrazione identiche una per una. Controlla i totali, i criteri e i prospetti di scomposizione.

Processo di export ripetibile

Le impostazioni definite una volta possono essere usate in modo coerente per gli export ricorrenti, purché la logica di imputazione e quella fiscale restino invariate.

Quali svantaggi e rischi hanno le scritture riepilogative?

L'aggregazione non è fine a sé stessa. Un'aggregazione troppo spinta può nascondere informazioni importanti.

Possibili rischi:

• assenza della transazione singola diretta nel libro mastro,
• abbinamento delle partite aperte più difficile,
• commistione di casi fiscali diversi,
• formazione del totale non spiegata,
• attribuzione errata al periodo,
• doppia registrazione dopo un nuovo export,
• differenze tra sistema a monte e DATEV,
• documentazione delle procedure insufficiente,
• perdita dei riferimenti a ordini e documenti,
• verifica fiscale laboriosa se manca un prospetto di scomposizione.

La soluzione è un raggruppamento controllato con regole fisse, versione, ID di export e piena tracciabilità.

Come KudTax raggruppa in modo intelligente le registrazioni e-commerce

L'export di KudTax separa selezione dei dati, logica di registrazione e raggruppamento.

1. Selezionare i dati: scegli il periodo di export e le fonti dati.
2. Applicare le regole di registrazione: ogni ordine o transazione riceve conti, trattamento fiscale e altre caratteristiche.
3. Attivare il raggruppamento: raggruppamento per periodo, accounting code, piattaforma e marketplace.
4. Fissare data e descrizione: ogni gruppo riceve una data di export e una descrizione.
5. Sommare gli importi compatibili: vengono aggregate solo le transazioni che soddisfano tutti i criteri.
6. Generare l'export: KudTax crea le scritture riepilogative secondo il tuo piano dei conti per TeamSystem, Zucchetti, Fatture in Cloud o Danea, oppure per DATEV o altri sistemi supportati.
7. Salvare l'attribuzione: ogni operazione singola resta collegata alla propria scrittura riepilogativa.

Un report di controllo per ogni scrittura riepilogativa

Un prospetto di scomposizione e controllo utile dovrebbe contenere, per ogni gruppo, almeno:

• ID univoco del gruppo o dell'export,
• data di creazione,
• periodo,
• tipo di data utilizzato,
• piattaforma,
• marketplace,
• conto dare,
• conto avere,
• codice IVA o codice di registrazione,
• valuta,
• numero di operazioni singole,
• totali imponibile, IVA e lordo, se rilevanti,
• data di registrazione,
• descrizione,
• elenco o file esportabile delle transazioni incluse,
• versione delle regole,
• utente o stato di approvazione,
• rettifiche o storni successivi.

Così lo studio può risalire dalla scrittura riepilogativa alle singole posizioni e, al contrario, verificare in quale scrittura riepilogativa è confluito un determinato ordine.

Come si gestiscono resi e modifiche successive?

I dati e-commerce possono cambiare dopo un export. Un cliente restituisce a febbraio un ordine che a gennaio era incluso in una scrittura riepilogativa. L'export di gennaio non deve essere modificato in silenzio.

Un processo tracciabile tratta il reso successivo come nuova operazione di rettifica. La nota di credito o la rettifica del ricavo viene registrata nel periodo corretto e mantiene il riferimento all'ordine e alla fattura originari.

Se i dati di origine vengono corretti in seguito, il sistema dovrebbe riconoscere:

• se la transazione originaria è già stata esportata,
• in quale gruppo era inclusa,
• quale registrazione di rettifica è necessaria,
• se nasce un nuovo gruppo per le rettifiche,
• se un export può essere stornato e generato di nuovo.

Le registrazioni già bloccate non devono essere sovrascritte senza che nessuno se ne accorga.

Una scrittura riepilogativa può sostituire le partite aperte?

Non sempre. La gestione delle partite aperte richiede spesso un abbinamento per fattura, cliente o ID ordine. Se più fatture clienti vengono aggregate in un'unica registrazione di contabilità generale, in DATEV l'abbinamento singolo può andare perso.

Modelli possibili:

Registrazioni clienti singole, registrazioni di contabilità generale aggregate: fatture e pagamenti restano singoli nel partitario. Determinate componenti del libro mastro vengono aggregate.

Cliente piattaforma o cliente cumulativo: i grandi volumi B2C passano attraverso un processo cumulativo riconciliato. Le transazioni singole restano nel sistema a monte.

Registrazione interamente singola: per fatture B2B particolari, crediti aperti o casi singoli rilevanti per le verifiche, ogni registrazione resta separata.

Il metodo adatto dipende dal processo di fatturazione, dalla riconciliazione dei pagamenti, dal piano dei conti e dall'impostazione dello studio.

Export verso DATEV e altri sistemi contabili

Il formato DATEV è un'interfaccia basata su CSV per dati contabili strutturati. DATEV raccomanda di creare un file separato per ogni periodo contabile. Un export aggregato può sostenere questo concetto di periodo, generando per esempio scritture riepilogative chiaramente delimitate per mese o per quindicina.

Un lotto di registrazioni DATEV può contenere, tra gli altri, i seguenti campi:

• importo e indicatore dare/avere,
• conto e contropartita,
• codice BU (BU-Schlüssel),
• data del documento,
• campi documento,
• descrizione,
• numero d'ordine,
• data della prestazione,
• valuta,
• informazioni aggiuntive,
• GUID della registrazione.

L'aggregazione deve avvenire prima dell'export. DATEV riceve quindi la scrittura riepilogativa già pronta. Le transazioni singole e il prospetto di scomposizione restano nel sistema a monte o nell'archivio documentato.

KudTax può esportare i dati anche per altri sistemi contabili, in Italia secondo il tuo piano dei conti per TeamSystem, Zucchetti, Fatture in Cloud o Danea. Struttura dei campi, logica dei conti e aggregazione ammessa possono variare a seconda del sistema di destinazione.

Esempio di export DATEV aggregato

Data	Importo	Conto	Contropartita	Descrizione
15/01	142.800,00 €	4400	1800	Amazon DE Orders 01-15
31/01	151.420,00 €	4400	1800	Amazon DE Orders 16-31
15/01	48.900,00 €	4125	1800	Amazon FR Sales 01-15
31/01	52.760,00 €	4125	1800	Amazon FR Sales 16-31

Dietro la prima riga possono esserci 2.400 ordini singoli, dietro la seconda 2.610 e dietro i gruppi francesi altre transazioni. Il lotto DATEV resta leggibile, mentre il prospetto di scomposizione contiene i dettagli.

Quali controlli dovrebbe fare lo studio?

Prima di approvare un export aggregato andrebbe verificato:

1. Sono incluse tutte le piattaforme e tutti i marketplace attesi?
2. Il periodo è completo e senza sovrapposizioni?
3. Le transazioni già esportate sono state escluse?
4. Conti e codici IVA corrispondono alla logica approvata?
5. Paesi, aliquote e valute diversi sono stati separati?
6. Ogni scrittura riepilogativa è scomponibile in transazioni singole?
7. I totali del gruppo, del report di controllo e del file DATEV coincidono?
8. Fatture e documenti sono ancora disponibili?
9. La data di registrazione è ammissibile nel merito?
10. Rettifiche e resi sono trattati in modo tracciabile?
11. La versione delle regole è stata documentata?
12. I tipi di transazione insoliti o nuovi sono stati esclusi o verificati?

Errori tipici nel raggruppare le registrazioni e-commerce

Errore 1: parlare di fatture "unite"

La funzione aggrega registrazioni. Non crea una nuova fattura riepilogativa a partire da fatture giuridicamente autonome.

Errore 2: mescolare più aliquote in un unico totale

Le vendite con aliquote diverse richiedono di regola gruppi di conti o di imposta separati.

Errore 3: registrare insieme Amazon Germania e Amazon Francia

Marketplace, paese di imposizione ed eventualmente valuta devono restare separati.

Errore 4: compensare vendite e commissioni

La logica dell'accredito netto o del settlement non deve portare a mescolare ricavi e costi.

Errore 5: cancellare le transazioni singole dopo l'export

L'aggregazione è verificabile solo se le registrazioni di base e i documenti restano conservati.

Errore 6: la data della scrittura riepilogativa sostituisce la data della prestazione

La data di export non deve sovrascrivere le date originarie rilevanti ai fini fiscali.

Errore 7: resi successivi modificano vecchi gruppi senza che nessuno se ne accorga

Le rettifiche richiedono una nuova operazione documentata oppure uno storno e una riemissione controllati.

Errore 8: lo studio non riceve un prospetto di scomposizione

Senza elenco delle transazioni il totale non si può controllare in modo efficiente.

Errore 9: ignorare i requisiti delle partite aperte

Le registrazioni clienti e gli abbinamenti dei pagamenti non si possono aggregare in modo sensato in ogni modello.

Errore 10: modificare le regole di raggruppamento senza storico delle versioni

Altrimenti lo stesso file di origine può portare a risultati diversi senza che la causa sia ricostruibile.

Quando conviene in particolare una scrittura riepilogativa?

L'aggregazione è particolarmente adatta quando:

• si generano moltissimi ordini B2C omogenei,
• la logica di imputazione è stabile,
• nel libro mastro non serve seguire singolarmente le partite aperte,
• le transazioni singole restano integralmente conservate nel sistema a monte,
• piattaforma, marketplace, valuta e logica fiscale sono chiaramente separati,
• viene prodotto un report di controllo,
• lo studio ha approvato il processo.

È meno adatta per poche fatture singole di importo rilevante, clienti B2B individuali, crediti aperti o contestati, nuovi tipi di transazione, casi IVA poco chiari od operazioni senza documenti completi.

Domande frequenti

Che cosa significa "raggruppare le registrazioni e-commerce"?

Più ordini o transazioni imputati allo stesso modo vengono sommati in un'unica registrazione aggregata per l'export contabile. Le transazioni singole restano conservate nel sistema a monte.

Con la funzione di KudTax più fatture diventano una sola fattura?

No. Le fatture restano documenti autonomi. KudTax raggruppa per l'export le registrazioni che ne derivano, se compatibili nel merito.

In base a quali criteri KudTax può raggruppare le registrazioni?

Il raggruppamento può avvenire per periodo, accounting code ovvero conti dare e avere, piattaforma e marketplace. In più si possono fissare la data di registrazione e la descrizione della scrittura riepilogativa.

Posso raggruppare separatamente dal 1° al 15 e dal 16 a fine mese?

Sì. I due periodi possono essere definiti come gruppi separati e ricevono date di registrazione, descrizioni e totali propri.

Si possono raggruppare Amazon Germania e Amazon Francia?

Dovrebbero restare separati se la logica di paese, di imposta o di imputazione è diversa. Nel commercio transfrontaliero di regola è così.

Posso raggruppare vendite con aliquota 7 % e 19 %?

Non in una registrazione fiscalmente identica. Aliquote diverse e i relativi conti di ricavo o codici IVA dovrebbero formare gruppi separati. Lo stesso vale per le aliquote IVA italiane (22 %, 10 %, 5 %, 4 %).

I singoli ordini Amazon restano tracciabili?

Sì. Gli ordini originari e i dettagli delle transazioni restano conservati in KudTax e vengono collegati alla rispettiva scrittura riepilogativa.

Una scrittura riepilogativa è conforme ai GoBD?

Secondo il diritto tedesco, registrazioni aggregate nel libro mastro possono essere ammesse se si possono scomporre integralmente nelle singole posizioni delle registrazioni di base e se sono garantiti tracciabilità, immodificabilità, accesso ai documenti e documentazione delle procedure. Il processo concreto va concordato con lo studio o il commercialista.

Una scrittura riepilogativa riduce il numero di fatture?

No. Riduce solo il numero di righe di registrazione nell'export. Fatture e documenti restano invariati.

Posso raggruppare anche gli ordini Shopify per DATEV?

Sì, a condizione che le transazioni scelte abbiano le stesse caratteristiche di conto, imposta, valuta e periodo e che il processo contabile scelto preveda un'aggregazione.

Che cosa succede in caso di reso successivo?

Il reso viene elaborato come operazione di rettifica nel periodo corretto e collegato all'ordine originario. Un gruppo già esportato non deve essere modificato senza che nessuno se ne accorga.

Mi serve un report per ogni scrittura riepilogativa?

Un prospetto di scomposizione e controllo è vivamente consigliato. Spiega periodo, criteri, conti, numero di transazioni e composizione dell'importo totale.

Conclusione: migliaia di ordini possono diventare poche registrazioni, ma verificabili

Un gran numero di ordini e-commerce non deve per forza portare a un libro mastro illeggibile. Le operazioni omogenee possono essere aggregate in modo controllato in scritture riepilogative per periodo, conti, piattaforma e marketplace.

La qualità della funzione, però, non dipende solo dalla riduzione delle righe. Decisivo è il legame tra registrazione aggregata e transazione operativa singola. Ogni totale deve essere riproducibile. Ogni ordine deve restare reperibile. Tipi di imposta, paesi, valute e conti non devono essere mescolati senza controllo.

KudTax ti permette di configurare tu stesso il raggruppamento al momento dell'export. Periodi, accounting code, piattaforma, marketplace, data e descrizione della registrazione si possono fissare in base al processo del cliente. Ne risultano export chiari per TeamSystem, Zucchetti, Fatture in Cloud, Danea, DATEV o altri sistemi contabili, mentre gli ordini originari e i dettagli delle transazioni restano tracciabili.

Aggregare in modo controllato i grandi volumi di dati e-commerce per l'export contabile — inizia ora.

Fonti ufficiali e approfondimenti

• DATEV Developer Portal: formato DATEV e lotti di registrazioni
• DATEV Developer Portal: descrizione del formato dei lotti di registrazioni
• DATEV Developer Portal: introduzione al formato DATEV
• DATEV Developer Portal: requisiti di interfaccia per dati di movimento strutturati
• BMF: GoBD – principi sulle registrazioni singole e sulle registrazioni aggregate nel libro mastro
• BMF: GoBD, seconda modifica del 14/07/2025
• Gesetze im Internet: § 238 HGB – obbligo di tenuta della contabilità
• Gesetze im Internet: § 239 HGB – tenuta dei libri commerciali
• KudTax: integrazione DATEV

Nota: questo articolo ha scopo puramente informativo e non sostituisce una consulenza fiscale, legale o relativa ai GoBD. Se e in quale misura le scritture riepilogative siano adatte a un'impresa concreta va valutato con il proprio studio o commercialista, alla luce dei processi di fatturazione, partite aperte, IVA e controllo.