Fatture Amazon ed eBay Che Non Tornano: l'Architettura n8n che Riconcilia Commissioni, Incassi e IVA su Ogni Marketplace

18 ottobre 2026 — Cosmio Team

I venditori multi-marketplace non fatturano ad Amazon o eBay: devono riconciliare manualmente commissioni, incassi e IVA su ogni canale. Ecco l'architettura n8n che automatizza il processo.

Il thread "Amazon e il casino con le fatture" su forum.fibra.click raccoglie decine di risposte di venditori italiani che si scontrano con lo stesso equivoco: Amazon non vuole una fattura dal venditore, ma è il venditore a dover scaricare mensilmente le fatture-commissioni emesse da Amazon EU S.à r.l. in Lussemburgo — o dalla branch italiana, a seconda del setup contrattuale — e a registrarle correttamente, spesso in autofattura con reverse charge. Lo stesso schema, con variazioni, si ripete su eBay e su buona parte del settore e-commerce italiano che vende su più canali contemporaneamente. Il problema non è capire la norma una volta: è rifarlo ogni mese, per ogni marketplace, incrociando righe di commissioni, spedizioni, pubblicità e rimborsi con l'estratto conto bancario, senza un margine di errore accettabile quando si parla di liquidazione IVA.

TL;DR — Executive Summary - I venditori multi-marketplace non fatturano ad Amazon/eBay: scaricano le fatture-commissioni e riconciliano gli incassi tramite il Report Pagamenti/Settlement Report di ciascun canale. - Il trattamento IVA delle commissioni (autofattura TD18 in reverse charge vs IVA italiana già esposta) dipende dall'entità che emette la fattura e va verificato canale per canale, non assunto una volta per tutte. - Un'architettura n8n che orchestra Amazon SP-API ed eBay API scarica, normalizza e riconcilia i settlement report automaticamente, segnalando solo le righe anomale per la revisione umana. - Un LLM (Claude, ChatGPT o Gemini) può riclassificare in output strutturato un report grezzo di centinaia di righe, riducendo da giorni a minuti il lavoro di categorizzazione fiscale.

Il tuo processo di riconciliazione marketplace ha questo problema?

• Dedichi più di 4 ore al mese a incrociare manualmente i report Amazon/eBay con l'estratto conto bancario?
• Hai mai scoperto commissioni, costi pubblicitari o storni addebitati che non corrispondevano ai tuoi calcoli interni?
• Vendi su più di un marketplace e gestisci ogni canale con un foglio Excel separato, senza una vista unificata?
• Il tuo commercialista riceve i report settlement già a fine mese, senza tempo per verificare le anomalie prima della liquidazione IVA?

Se hai risposto Sì a 3 o più domande, il collo di bottiglia descritto in questo articolo sta probabilmente impattando la tua operatività — le sezioni seguenti mostrano come quantificarlo e affrontarlo. Se hai risposto Sì a meno di 2 domande, il tuo processo è più maturo della media: le sezioni seguenti possono comunque rivelare ottimizzazioni incrementali, soprattutto se stai per aggiungere un nuovo marketplace.

Diagnosi del collo di bottiglia: perché la riconciliazione multi-marketplace costa così tanto

Il costo reale non è il tempo di download dei report: è la combinazione di tre fattori che si aggravano a vicenda man mano che crescono i canali di vendita.

Formati non uniformi. Il Report Pagamenti di Amazon Seller Central (disponibile anche via SP-API come GET_V2_SETTLEMENT_REPORT_DATA_FLAT_FILE) e il report Payouts di eBay (estraibile tramite le Finances API) usano strutture, nomi di colonna e granularità diverse per le stesse voci economiche — commissione di vendita, fee di spedizione, costi pubblicitari, storni cliente. Riconciliarli manualmente significa ricostruire ogni mese una mappatura che nessun gestionale italiano conosce nativamente.

Trattamento IVA non uniforme tra canali. Dal 2024 Amazon ha progressivamente spostato parte della fatturazione delle commissioni sulla propria branch italiana per alcuni venditori, applicando direttamente l'IVA italiana in fattura; in altri casi — setup contrattuali precedenti, vendite anche su siti Amazon di altri paesi UE — le fatture arrivano ancora da Amazon EU S.à r.l. in Lussemburgo senza IVA, da integrare con autofattura TD18 in reverse charge. eBay segue logiche proprie legate all'entità contraente. Il risultato è che lo stesso venditore può dover applicare due trattamenti IVA diversi per due marketplace nello stesso mese, e l'errore si scopre spesso solo in sede di controllo.

Volume che scala più velocemente del team contabile. Un venditore con 200 ordini al mese può sostenere la riconciliazione manuale. Con 1.200 ordini su due canali, il numero di righe da controllare cresce in modo non lineare rispetto alle ore disponibili del commercialista o dell'ufficio contabilità interno. La stessa dinamica — volume che supera la capacità del team prima che ce ne si accorga — si osserva nel servizio clienti e-commerce, dove i ticket ripetitivi seguono una curva simile a quella delle righe di riconciliazione da verificare.

Stime di settore riportate da fornitori di contabilità e-commerce indicano che la riconciliazione bancaria mensile in aziende con alto volume di transazioni può richiedere 2-3 giorni; con processi automatizzati l'intervento umano si riduce tipicamente a poche ore dedicate alle sole eccezioni. Il costo di un servizio di contabilità esterna per un e-commerce multi-marketplace con gestione fatture e dichiarazioni periodiche si colloca spesso tra 2.500€ e 3.400€ annui, a seconda del volume documentale — una cifra che non comprende il tempo interno speso a preparare i dati prima che arrivino al commercialista.

Se questi numeri assomigliano alla tua situazione, il questionario di Analisi IA incrocia volume ordini e numero di canali attivi per stimare dove l'automazione produce il ritorno più rapido.

Soluzione implementativa: l'architettura n8n per la riconciliazione multi-marketplace

L'obiettivo non è sostituire il commercialista, ma eliminare il lavoro di preparazione manuale dei dati che oggi precede ogni liquidazione IVA. Come descritto nella guida 2026 all'automazione IA per l'e-commerce italiano, il principio architetturale è sempre lo stesso: orchestrare le fonti dati con n8n, delegare la classificazione semantica a un LLM, mantenere un gestionale certificato come sistema di registrazione fiscale finale. Lo stesso pattern n8n + LLM, applicato alla gestione simultanea di migliaia di SKU pubblicitari invece che di righe di settlement, è illustrato nell'architettura n8n e Claude per Performance Max e Advantage+.

Esempio pratico: dal settlement report grezzo alla discrepanza segnalata

Input: un workflow n8n programmato (Schedule Trigger settimanale) interroga l'Amazon SP-API con una chiamata createReport sul tipo GET_V2_SETTLEMENT_REPORT_DATA_FLAT_FILE, attende la disponibilità con un nodo di polling su getReport, scarica il documento tramite getReportDocument e lo decomprime. In parallelo, un secondo branch richiama le eBay Finances API per ottenere i payout dello stesso periodo. Entrambi i file arrivano come CSV con centinaia di righe: ordine, tipo di transazione (commissione, spedizione, pubblicità, storno), importo, data di liquidazione.

Processo: un nodo Code in n8n normalizza le due strutture in uno schema comune (order_id, canale, categoria, importo, data). I dati normalizzati vengono passati a un nodo HTTP Request che chiama l'API di un LLM con questo prompt strutturato:

Ricevi una tabella di transazioni marketplace (colonne: order_id, canale,
categoria_raw, importo, data). Riclassifica categoria_raw in una delle
categorie fiscali: COMMISSIONE_VENDITA, SPEDIZIONE, PUBBLICITA, STORNO,
ALTRO. Per ogni riga, calcola la differenza tra l'importo atteso (ordine
originale x aliquota commissione nota) e l'importo effettivo. Segnala
come ANOMALIA le righe con differenza superiore a 5 EUR. Restituisci
JSON con i campi: order_id, canale, categoria_fiscale, importo,
differenza, flag_anomalia.

Output (estratto su un lotto di 1.200 ordini mensili Amazon + eBay):

Su un volume di 1.200 ordini mensili, un flusso di questo tipo isola tipicamente tra 10 e 20 righe con differenza superiore alla soglia impostata — anomalie che un commercialista o un controller può verificare in 20-30 minuti invece di ricostruire l'intero mese a mano.

Come usare l'IA Generativa per automatizzare la riclassificazione fiscale

Il software di settore resta al centro del processo: n8n orchestra le chiamate API, un tool dedicato come A2X o Settle — benchmark di mercato nati per la contabilità e-commerce multi-canale — può gestire la conversione dei settlement report in voci contabili standard per Shopify, Amazon ed eBay, mentre un gestionale italiano come TeamSystem o Zucchetti resta il sistema che registra l'autofattura TD18 in reverse charge e genera la liquidazione IVA. L'LLM si inserisce nel gap che nessuno di questi tre coprirebbe da solo: la riclassificazione semantica di voci con etichette non standard e la segnalazione delle anomalie prima che diventino un problema di liquidazione.

Per questo caso d'uso, Claude è preferibile quando il volume mensile di righe supera le migliaia e serve mantenere nel contesto l'intero settlement report per confronti incrociati tra periodi; ChatGPT è una scelta solida se il workflow deve anche generare in output testi esplicativi per il commercialista insieme ai dati strutturati; Gemini conviene se l'azienda opera già su Google Workspace e vuole che l'output JSON alimenti direttamente un Google Sheet condiviso con il team contabile.

Azioni immediate (questa settimana, senza cambiare software)

1. Scarica il Report Pagamenti/Transazioni di Amazon Seller Central dell'ultimo mese e confronta i primi 20 ordini con l'incasso effettivo registrato in banca: conta quante righe non coincidono al centesimo.
2. Verifica con il commercialista se le fatture-commissioni ricevute da Amazon nell'ultimo trimestre provengono dalla branch italiana (IVA già esposta) o da Amazon EU S.à r.l. in Lussemburgo (da integrare in autofattura TD18): molti venditori scoprono di avere entrambi i casi senza saperlo.
3. Se vendi anche su eBay, estrai il report Payouts dello stesso periodo ed etichetta manualmente le prime 50 righe per categoria fiscale: questo campione diventa la base per validare qualsiasi classificazione automatica futura, anche non IA.

Hai ora un numero concreto di discrepanze e una mappa del trattamento IVA reale sui tuoi canali. Per tradurre questa mappa in un piano di automazione con stime di effort realistiche, il questionario di Analisi IA incrocia questi dati con benchmark tecnici di settore.

Quale approccio per la tua realtà

Chi gestisce più canali con volumi crescenti troverà utile anche l'approccio descritto per digitalizzare il flusso ordini multi-canale, che affronta lo stesso problema di fondo — dati sparsi su fonti diverse — applicato al processo ordini invece che alla riconciliazione fiscale.

Dubbi frequenti

La condivisione di dati transazionali con un LLM è compatibile con il GDPR? I settlement report contengono dati fiscali e transazionali aziendali; alcuni export includono anche IBAN o nominativi cliente in caso di rimborsi. Per questo va usata esclusivamente la versione business del fornitore — Claude for Work, ChatGPT Enterprise o Gemini for Google Workspace — che garantisce contrattualmente che i dati non vengano usati per l'addestramento dei modelli. I dati sensibili non vanno mai caricati su versioni consumer gratuite. L'azienda resta titolare del trattamento anche usando strumenti IA terzi: verificare il DPA (Data Processing Agreement) del fornitore prima dell'adozione è un passaggio da considerare non negoziabile.

Un LLM può sbagliare la classificazione di una riga? Sì, ed è per questo che l'architettura descritta non invia nulla direttamente al gestionale senza revisione: il flag_anomalia serve esattamente a isolare i casi dubbi per l'arbitrato umano. Il modello riduce il volume di lavoro manuale, non elimina la supervisione del commercialista sulla liquidazione finale.

Dove questo approccio ha dei limiti. L'automazione descritta funziona bene quando i settlement report hanno una struttura relativamente stabile nel tempo e il volume mensile giustifica l'investimento di configurazione iniziale — sotto i 200-300 ordini al mese un foglio Excel ben organizzato resta spesso più efficiente di un'architettura n8n dedicata. L'integrazione con l'Amazon SP-API richiede inoltre competenze tecniche per la gestione dell'autenticazione e del polling asincrono dei report: senza uno sviluppatore interno o un system integrator, la configurazione iniziale va affidata a un fornitore esterno. Infine, il trattamento IVA delle commissioni resta una decisione che spetta al commercialista: l'architettura automatizza la raccolta e la classificazione dei dati, non sostituisce la competenza fiscale necessaria a decidere se una fattura va integrata in reverse charge.

In sintesi

L'esempio dei 1.200 ordini mensili riconciliati in 20-30 minuti invece di due giornate lavorative non descrive un caso teorico: descrive la differenza tra un processo che si ripete manualmente ogni mese e uno che isola automaticamente solo le eccezioni che meritano attenzione umana. Il thread di forum.fibra.click che ha ispirato questo articolo si chiude, come molti simili, con un venditore che chiede "ma quindi come fate voi?" — la risposta pratica non è un software miracoloso, ma un'architettura che mette ogni componente (API dei marketplace, LLM per la classificazione, gestionale per la registrazione fiscale) a fare esattamente ciò per cui è più adatto. Chi vuole capire quanto di questo processo è già automatizzabile con lo stack che usa oggi può partire da un percorso di analisi IA personalizzato, il primo passo per mappare queste integrazioni prima di scegliere da dove cominciare.