Ultima revisione giugno 2026. Regole OSS aggiornate al regime UE post-2021; percorsi del back office verificati su PrestaShop 1.7, 8.x e 9.x. Conferma sempre il trattamento fiscale con il tuo commercialista.
Ecco la distinzione che decide quanto sarà dolorosa la chiusura di fine mese: PrestaShop è il sistema che incassa il denaro, mentre il tuo software contabile è il sistema che deve spiegare quel denaro all'autorità fiscale. Non sono lo stesso lavoro. Il tuo negozio registra un ordine con un cliente, un corriere, un metodo di pagamento e un carrello di prodotti. Il tuo commercialista ha bisogno di una fattura numerata in sequenza, di un conto ricavi, di un codice IVA e di una nota di credito per ogni rimborso, in un formato che si riconcili al centesimo. Collegare i due sistemi significa tradurre un modello nell'altro. Se la traduzione è corretta, la contabilità si chiude da sola; se è sbagliata, ti ritrovi a riconciliare l'IVA a mano alle 23:00 dell'ultimo giorno del trimestre.
Questa guida riguarda nello specifico il collegamento di PrestaShop a un software contabile, Xero, QuickBooks e gli altri, affinché gli ordini diventino fatture corrette e verificabili senza reinserire i dati. Non riguarda il collegamento di PrestaShop a un ERP completo per magazzino e acquisti (è un problema diverso, con una struttura diversa: vedi collegare PrestaShop al tuo ERP e, per la domanda "quando mi serve?", quando il tuo negozio supera il lavoro manuale). Qui il perimetro è il registro contabile: fatture, imposte, rimborsi, commissioni e i numeri che il tuo commercialista deve approvare.
Cosa deve davvero passare da PrestaShop alla contabilità
Prima di scegliere uno strumento, chiarisci quali dati deve trasportare il collegamento. PrestaShop ne genera già la maggior parte: il compito dell'integrazione è mappare ogni elemento nel punto giusto del tuo piano dei conti, non ricrearlo. Gli oggetti importanti vivono in tabelle PrestaShop ben definite, e conoscerne i nomi ti dice esattamente che cosa sta leggendo un'integrazione:
- La fattura, non l'ordine. Un ordine PrestaShop (ps_orders) non è ancora un documento contabile. La fattura è un oggetto separato (OrderInvoice / ps_order_invoice) generato quando l'ordine raggiunge uno stato di fatturazione, e ha un proprio numero. La contabilità considera la fattura. Sincronizza ordini senza fattura e creerai ricavi che, legalmente, non esistono ancora.
- Imposte suddivise per aliquota. PrestaShop memorizza le imposte per riga e per fattura (ps_order_detail_tax, ps_order_invoice_tax). Un singolo ordine può avere due o tre aliquote IVA diverse: beni ad aliquota ordinaria, beni ad aliquota ridotta, spedizione a zero. L'integrazione deve preservare questa suddivisione, non limitarsi a un unico totale.
- Rimborsi e annullamenti come note di credito. Un rimborso in PrestaShop è una nota di credito (OrderSlip / ps_order_slip), con un proprio numero sequenziale. Nel tuo software contabile deve arrivare come nota di credito collegata alla fattura originale, non come vendita negativa e mai come eliminazione silenziosa.
- Pagamento rispetto a fattura. Ciò che il cliente ha pagato (ps_order_payment) e ciò che hai fatturato sono due eventi diversi. Contrassegnare una fattura come "pagata" in contabilità dovrebbe dipendere dal record di pagamento, così cassa e ricavi si riconciliano separatamente.
- Commissioni del gateway e spedizione. Stripe e PayPal trattengono una quota prima che il denaro arrivi; l'incasso della spedizione (ciò che ha pagato il cliente) e il costo della spedizione (ciò che hai pagato al corriere) sono due righe diverse. Nulla di tutto questo è visibile in una sincronizzazione ingenua "totale ordine → ricavi".
Quindi? Se sai nominare questi cinque flussi, puoi valutare qualsiasi connettore in cinque minuti: ti basta chiedere quali gestisce e quali lascia cadere in silenzio.
La decisione prima dello strumento: chi controlla il numero di fattura?
Questa è la singola scelta che plasma ogni integrazione contabile, e la maggior parte delle guide la salta. In quasi ogni giurisdizione, fatture di vendita e note di credito devono essere sequenziali e univoche; in alcune giurisdizioni la sequenza deve essere senza salti, oppure ogni salto deve essere spiegabile e verificabile. La domanda è quale sistema sia la fonte ufficiale per quella sequenza.
| Modello | Chi numera la fattura | Ideale quando | Attenzione a |
|---|---|---|---|
| PrestaShop è il registro ufficiale | PrestaShop assegna il numero di fattura; il software contabile lo riceve come riferimento | Emetti fatture ai clienti al momento dell'ordine e il negozio è il tuo registro vendite principale | Devi controllare con precisione la numerazione di PrestaShop (prefisso, reimpostazione, assenza di salti) perché regga a una verifica fiscale |
| Il software contabile è il registro ufficiale | La piattaforma contabile numera la fattura; l'ID ordine PrestaShop è solo un metadato | Il tuo commercialista pretende che tutti i documenti legali siano emessi dal suo sistema | Il PDF visibile al cliente da PrestaShop e la fattura legale ora differiscono: potresti doverne sopprimere uno |
Se PrestaShop controlla la numerazione, la sequenza nativa è configurabile ma rigida, e un salto inspiegato (una fattura annullata o mancante, una modifica manuale al database, una migrazione fallita o una reimpostazione di sequenza configurata male) è esattamente il tipo di cosa che un revisore segnala. Due dei nostri moduli esistono proprio per questo punto di controllo: Invoice Number e Order Number ti permettono di impostare prefisso, valore iniziale e formato, così i documenti PrestaShop seguono la sequenza annuale senza salti che il tuo commercialista si aspetta, invece di combattere con i valori predefiniti del core. Il vantaggio è specifico ma concreto: il documento che il cliente scarica e quello che il commercialista registra hanno lo stesso numero legalmente valido, quindi la riconciliazione diventa una ricerca, non un'indagine.
Xero
Xero è una scelta frequente per i negozi del Regno Unito e dell'Europa, e se lo merita: API ben documentata, multivaluta nativa e gestione dell'IVA che regge anche oltre confine. Per PrestaShop il collegamento è quasi sempre indiretto: un servizio middleware o un modulo dedicato legge gli ordini fatturati e crea le fatture corrispondenti in Xero, perché Xero non dispone di un'estensione nativa per PrestaShop.
Le quattro cose che determinano davvero se un collegamento a Xero è corretto:
- Mappatura del piano dei conti. Le categorie (o i prodotti) PrestaShop devono essere mappate sui conti ricavi di Xero. Un negozio che vende beni fisici e prodotti digitali scaricabili di solito li vuole in conti separati: decidi la mappatura prima della prima sincronizzazione, perché rimappare dopo migliaia di fatture è pesante.
- Mappatura delle aliquote fiscali. Una regola fiscale di PrestaShop (Back Office → Internazionale → Imposte → Regole fiscali) non è lo stesso oggetto di un'aliquota fiscale Xero. Devi mappare esplicitamente ciascuna: PrestaShop "FR Standard 20%" all'aliquota corrispondente in Xero, e così via per ogni paese in cui vendi. Saltane una e le vendite di quel paese verranno registrate con l'imposta sbagliata, o senza imposta.
- Stato del pagamento. Una fattura dovrebbe essere contrassegnata come pagata in Xero solo quando PrestaShop conferma il pagamento. Basati sullo stato pagato dell'ordine, non sulla creazione della fattura, altrimenti la tua posizione di cassa risulterà gonfiata.
- Multivaluta. Se vendi in GBP, EUR e USD, lascia che sia Xero a gestire i tassi di cambio e registra le fatture nella valuta della vendita. Non preconvertire nell'integrazione: perderesti la traccia verificabile dell'importo nella valuta originale.
L'errore più comune con Xero è sincronizzare troppo. Parti solo da ordini fatturati e pagati. Ordini in bozza, carrelli abbandonati e pagamenti in sospeso non hanno posto nella contabilità finché il denaro non è passato di mano.
QuickBooks Online
QuickBooks Online è comune tra i commercianti statunitensi ed è utilizzabile anche in alcune configurazioni europee, con un ecosistema di connettori maturo: la maggior parte delle piattaforme middleware lo supporta subito. Che sia davvero adatto a un negozio europeo dipende dai requisiti fiscali e di fatturazione elettronica locali, quindi verificali prima di impegnarti. La complicazione per chi vende oltre confine è che QuickBooks modella l'imposta sulle vendite (USA, basata sulla destinazione, per stato/contea) in modo molto diverso dall'IVA (UE). Se vendi in entrambi i contesti, l'integrazione deve creare la voce fiscale corretta in base alla posizione del cliente: un ordine USA ottiene una riga di imposta sulle vendite, un ordine UE ottiene una riga IVA, e quella logica vive nel connettore, non in QuickBooks.
Configurazioni pratiche che ripagano:
- Usa classi o sedi. Se gestisci più di un negozio PrestaShop (per esempio un negozio separato per paese), le classi di QuickBooks ti permettono di mantenere separabili i ricavi di ogni negozio nel P&L senza un secondo file QuickBooks.
- Lavora per lotti, non in flusso continuo. La sincronizzazione in tempo reale sembra interessante; un lotto giornaliero o orario è più affidabile e molto più facile da diagnosticare quando una fattura fallisce. Vuoi trovare un problema in un lotto da 40, non inseguirlo dentro un flusso in tempo reale.
- Decidi la granularità dei prodotti. Ogni prodotto PrestaShop diventa un articolo QuickBooks, oppure aggreghi i ricavi per categoria? Per prodotto ottieni reportistica a livello prodotto e una lista articoli molto più grande da mantenere; per categoria mantieni QuickBooks più leggero. La maggior parte dei negozi è più soddisfatta aggregando.
- Trasforma le note di credito PrestaShop in note di credito QuickBooks. Una nota di credito PrestaShop dovrebbe creare un credit memo QuickBooks collegato alla fattura originale: stesso importo, stesso trattamento fiscale.
Le altre piattaforme, e perché decide il tuo paese
Xero e QuickBooks dominano la conversazione in lingua inglese, ma lo strumento giusto di solito è quello che il tuo commercialista locale e l'autorità fiscale si aspettano. L'approccio di integrazione cambia di conseguenza:
- Sage, presente da tempo nel Regno Unito e in Francia, comune nelle aziende più grandi; l'approccio di integrazione dipende dal prodotto Sage, con opzioni che vanno dai connettori API (Sage Business Cloud, Intacct) al middleware e alle esportazioni pianificate.
- Datev, lo standard di fatto in Germania, perché la maggior parte dei consulenti fiscali tedeschi (Steuerberater) ci lavora. Raramente vogliono un'API; vogliono un'esportazione compatibile con Datev da importare. Per questi commercialisti, un flusso CSV pulito batte qualsiasi connettore in tempo reale.
- Fakturownia / inFakt / wFirma, piattaforme polacche per fatturazione e imposte. Le regole polacche su numerazione e dichiarazioni JPK sono rigide, il che rende particolarmente importante la decisione sopra su "chi controlla il numero di fattura".
- Fattura24 / Aruba, l'Italia richiede la fatturazione elettronica (fatturazione elettronica) tramite il sistema di interscambio SDI. Queste piattaforme gestiscono l'invio allo SDI; il compito dell'integrazione PrestaShop è fornire loro una fattura strutturata correttamente, non dialogare direttamente con SDI.
- FreshBooks / strumenti in stile Debitoor, fatturazione più semplice per microimprese e freelance, di solito alimentata da esportazioni invece che da integrazioni profonde.
Per qualsiasi piattaforma senza un connettore pronto all'uso, l'integrazione quasi sempre si riduce a un'esportazione strutturata che il software contabile (o il tuo commercialista) importa a calendario. Non è un passo indietro: per un flusso Datev o Fattura24 è esattamente ciò che il sistema ricevente vuole.
Cosa contiene davvero un file di esportazione contabile

Se la tua strada è l'esportazione (Datev, JPK, "mandami solo un CSV"), è utile sapere quali colonne si aspetta il destinatario, perché un'intestazione pulita è gran parte del lavoro. L'importazione del commercialista non vuole la vista ordine del tuo negozio: vuole righe a livello di fattura, con le imposte suddivise per aliquota. Un'intestazione CSV utilizzabile per esportare fatture di vendita assomiglia a questa:
invoice_number,invoice_date,order_reference,customer_name,customer_vat_number,country,currency,net_amount,tax_rate,tax_amount,gross_amount,payment_method,document_type
INV-2026-000412,2026-06-18,XKBKTSXPM,"ACME GmbH",DE811234567,DE,EUR,200.00,0.00,0.00,200.00,bankwire,invoice
INV-2026-000412,2026-06-18,XKBKTSXPM,"ACME GmbH",DE811234567,DE,EUR,50.00,19.00,9.50,59.50,bankwire,invoice
CN-2026-000031,2026-06-20,XKBKTSXPM,"ACME GmbH",DE811234567,DE,EUR,-50.00,19.00,-9.50,-59.50,bankwire,credit_note
Due cose da notare: ogni aliquota fiscale ha la propria riga (quindi una fattura con più aliquote occupa più righe che sommano al totale del documento), e un rimborso appare come credit_note con importi negativi rispetto all'order_reference originale, mai come una riga di fattura eliminata o modificata. Conferma i nomi esatti delle colonne e il formato della data con il tuo commercialista prima del primo avvio; Datev e JPK hanno ciascuno il proprio layout richiesto, ma la struttura, una riga per aliquota, note di credito come negativi, resta costante.
Due strade verso la contabilità: modulo nativo o middleware
Una volta chiarito cosa deve passare e chi controlla la numerazione, ci sono due modi realistici per spostare davvero i dati. Non si escludono a vicenda: molti negozi usano un modulo per le fatture e un connettore middleware per una piattaforma specifica, ma è utile vedere il compromesso in modo chiaro.
| Modulo PrestaShop / esportazione | Middleware (Synder, A2X, Make, Zapier) | |
|---|---|---|
| Dove vive la logica | Dentro PrestaShop, eseguita sul tuo server | Un servizio di terze parti tra i due sistemi |
| Costo continuativo | Licenza una tantum (tipica dei nostri moduli) | Abbonamento mensile, spesso con fasce per transazione |
| Residenza dei dati | I dati ordine restano sul tuo hosting | I dati ordine/finanziari passano attraverso una terza parte |
| Copertura | Ampia quanto consentono formato di esportazione / modulo | Connettori preconfigurati per molte piattaforme contabili |
| Ideale per | Commercialisti orientati all'esportazione (Datev), controllo fatture, nessun canone ricorrente | Sincronizzazione API in tempo reale verso Xero/QuickBooks con nuovi tentativi/log gestiti per te |
Sul lato modulo, il nostro modulo Financial Revolution gestisce generazione, numerazione ed esportazione delle fatture in formati che la tua piattaforma contabile può usare. Quando il risultato richiesto è un file pulito a calendario, il caso Datev o JPK, Invoice CSV List Exporter estrae i dati fattura e le imposte per aliquota che il commercialista importa, mentre Orders CSV List Exporter copre il lato ordine grezzo quando è ciò che il sistema ricevente richiede. Il risultato pratico: puoi mettere in piedi un flusso contabile accurato dal back office, senza un canone middleware ricorrente e senza che i dati ordine lascino il tuo server: spesso è il fattore decisivo per un flusso Datev o JPK in cui il commercialista vuole solo un file pulito a calendario. (E se quel calendario deve funzionare senza interventi manuali, Cron Manager esegue e registra l'esportazione ricorrente, così un'esecuzione mancata è visibile, non silenziosa.)
Il middleware giustifica l'abbonamento quando vuoi una sincronizzazione in tempo reale e senza interventi manuali specificamente verso Xero o QuickBooks, e dai valore ai nuovi tentativi integrati, ai log e ai connettori già mappati. Se il motivo per cui guardi a Zapier o Make è l'automazione più ampia del negozio, non il registro contabile in sé, quello è un argomento diverso: la meccanica di costruzione di quei flussi è trattata in Zapier e Make per PrestaShop e l'approccio senza codice in automatizzare i flussi senza scrivere codice.
IVA transfrontaliera: la parte che trasforma un compito contabile in un obbligo legale
Se vendi oltre i confini dell'UE, l'IVA è il punto in cui un'integrazione contabile smette di essere una comodità e diventa conformità normativa. PrestaShop acquisisce i fatti grezzi; la tua contabilità deve riportarli correttamente.
- OSS (One-Stop Shop). Da luglio 2021, un negozio UE può dichiarare l'IVA per tutti gli Stati membri tramite un'unica dichiarazione OSS, ma solo se i tuoi registri sanno quale aliquota del paese si è applicata a ogni vendita. PrestaShop memorizza già la destinazione e la regola fiscale applicata per fattura; l'integrazione deve portare quella dimensione paese fino alla contabilità, altrimenti la dichiarazione OSS diventa un'ipotesi.
- Reverse charge B2B. Vendi a un'azienda con un numero IVA UE valido e non addebiti l'IVA: è l'acquirente ad assolverla. Questo significa che l'integrazione deve registrare la vendita come operazione in reverse charge, non come vendita a IVA zero, perché per l'autorità fiscale sono cose diverse. La verifica del numero al momento dell'ordine è il prerequisito; il nostro Automatic EU VAT Checker verifica i numeri IVA su VIES in tempo reale, così l'ordine viene etichettato correttamente prima ancora di arrivare in contabilità.
- Esportazioni extra UE. Le vendite fuori dall'UE sono in genere ad aliquota zero, ma devono comunque apparire in contabilità come esportazioni: presenti, non invisibili.
La regola pratica: sistema l'IVA transfrontaliera prima di aumentare i volumi. Una mappatura fiscale sbagliata è un piccolo fastidio a 30 ordini al mese e una correzione a cinque cifre a 3.000.
Insidie che colpiscono ogni integrazione contabile
Indipendentemente dallo strumento scelto, ricorrono sempre gli stessi bug. Progettarli in anticipo costa meno che scoprirli a fine anno:
- Fatture duplicate. Il classico. Una sincronizzazione che gira due volte, o riprova dopo un timeout, può registrare la stessa fattura due volte. La soluzione è una chiave di idempotenza, quasi sempre l'ID ordine o fattura PrestaShop, così il lato contabile riconosce e salta una ripetizione.
- Scostamenti di arrotondamento. PrestaShop e il tuo software contabile possono arrotondare l'imposta per riga oppure sul totale in modo diverso. Una differenza di un centesimo su un ordine è rumore; su migliaia di ordini diventa una riconciliazione che non torna mai del tutto. Decidi una volta la regola di arrotondamento e fai in modo che entrambi i sistemi concordino (modalità e tipo di arrotondamento di PrestaShop si trovano in Parametri negozio → Generale).
- Valuta non coerente. Un cliente paga in GBP, la tua contabilità è in EUR: la registrazione deve contenere sia l'importo nella valuta originale sia l'importo convertito al tasso corretto, altrimenti la rendicontazione in valuta estera è finzione.
- Commissioni gateway dimenticate. La percentuale del processore di pagamento non è uno sconto sui ricavi: è un costo. Registra separatamente la vendita lorda e la commissione, altrimenti i margini sembrano migliori di quanto siano e il saldo bancario non quadrerà.
- Rimborsi che spariscono. Il punto più comune in cui un processo manuale si rompe sono i rimborsi. Se le note di credito PrestaShop non passano automaticamente in note di credito contabili, i ricavi risultano sistematicamente sovrastimati. Automatizza questo percorso per primo, non per ultimo.
Un rollout sensato, in base alla dimensione del negozio
Non ti serve il flusso più sofisticato: te ne serve uno accurato, affidabile e capace di farti risparmiare più tempo di quanto costi gestirlo. Adegua lo sforzo al volume:
- Sotto circa 50 fatture/mese: un'esportazione settimanale (CSV/in stile Datev) che il commercialista importa è davvero sufficiente. Non sovraingegnerizzare.
- Circa 50–500/mese: una sincronizzazione automatica giornaliera o un'esportazione pianificata, con rimborsi automatizzati e un avviso di errore, così trovi un'esecuzione rotta lo stesso giorno e non a fine mese.
- 500+/mese: integrazione quasi in tempo reale con idempotenza, log e monitoraggio: è il volume in cui un duplicato silenzioso o una nota di credito mancata costa abbastanza da giustificare l'ingegneria.
E qualunque sia la dimensione: parla con il tuo commercialista prima di costruire. Chiedi quale piano dei conti usare, quali codici fiscali si aspetta, quale formato di esportazione importa davvero e se vuole che sia PrestaShop o il suo sistema a controllare la numerazione delle fatture. Poi esegui il nuovo flusso in parallelo al processo esistente per un mese intero e riconcilia i due risultati prima di spegnere la procedura manuale di riserva. L'obiettivo non è un'integrazione intelligente: è un fine trimestre in cui la contabilità è già chiusa perché ogni ordine, rimborso e riga IVA si è tradotto correttamente al primo tentativo.
Domande frequenti
Il numero di fattura deve provenire da PrestaShop o dal mio software contabile?
Scegline uno come registro ufficiale e mantieni quella scelta. Se emetti fatture visibili al cliente al momento dell'ordine e il negozio è il tuo registro vendite principale, PrestaShop dovrebbe controllare la numerazione; in quel caso però devi controllare strettamente prefisso, formato e sequenza, in modo che non ci siano salti e che regga a una verifica fiscale (è a questo che servono Invoice Number e Order Number). Se il tuo commercialista insiste perché tutti i documenti legali siano emessi dal suo sistema, lascia che li numeri lui e tratta l'ID ordine PrestaShop come metadato, sopprimendo il PDF per il cliente così i due documenti non entrano in conflitto.
Come dovrebbero arrivare i rimborsi al mio software contabile?
Come note di credito, mai come fatture eliminate o modificate. Una nota di credito PrestaShop (OrderSlip / ps_order_slip) si mappa a una nota di credito in Xero o a un credit memo in QuickBooks collegato alla fattura originale: stesso importo, stesso trattamento fiscale, valori negativi. Automatizza questo percorso per primo, perché un processo di rimborso manuale è la causa più comune di contabilità con ricavi sovrastimati.
Mi serve un abbonamento middleware a pagamento o posso semplicemente esportare un file?
Per un commercialista orientato all'esportazione, Datev in Germania, JPK in Polonia o chiunque dica "mandami solo un CSV". Un'esportazione pianificata è esattamente ciò che vuole, e un modulo come Invoice CSV List Exporter lo fa senza canoni ricorrenti e senza che i dati ordine lascino il tuo server. Il middleware (Synder, A2X) giustifica l'abbonamento quando vuoi specificamente una sincronizzazione API in tempo reale e senza interventi manuali verso Xero o QuickBooks, con nuovi tentativi e log gestiti per te.
Come evito di registrare due volte le fatture quando una sincronizzazione riprova?
Usa una chiave di idempotenza, quasi sempre l'ID ordine o fattura PrestaShop, così il lato contabile riconosce e salta una ripetizione. Senza di essa, qualsiasi sincronizzazione che gira due volte o riprova dopo un timeout può registrare di nuovo la stessa fattura, e lo scopri in riconciliazione. È una decisione di progettazione da una riga che previene il bug più comune delle integrazioni contabili.
L'IVA transfrontaliera sembra sbagliata in contabilità: dove si rompe il flusso?
Quasi sempre nella mappatura delle aliquote fiscali o nella dimensione paese mancante. PrestaShop memorizza la destinazione e la regola fiscale applicata per fattura, ma l'integrazione deve portare quel paese fino alla contabilità per la dichiarazione OSS, registrare le vendite B2B a numeri IVA UE validi come reverse charge (non IVA zero) e trattare le vendite extra UE come esportazioni a zero invece di farle sparire. Verifica i numeri IVA al momento dell'ordine (Automatic EU VAT Checker controlla su VIES), così ogni ordine è etichettato correttamente prima di raggiungere il registro contabile.
Letture correlate
- Quando il tuo negozio supera il lavoro manuale. Decidere se l'integrazione contabile è il primo passo di cui hai bisogno
- Collegare PrestaShop al tuo ERP, la metà relativa a magazzino e acquisti, diversa dal registro contabile
- Zapier e Make per PrestaShop, quando il motivo per integrare è l'automazione più ampia del negozio, non il registro contabile
Commenti
Lascia un commento
Condividi una domanda, un dettaglio di installazione o un feedback utile per un altro lettore.