Rivoluzione finanziaria: reportistica avanzata per i proprietari di negozi PrestaShop

Ultima revisione: giugno 2026, i percorsi dei campi nel back office e i nomi delle tabelle indicati di seguito si applicano a PrestaShop 1.7, 8 e 9; le etichette dei menu cambiano leggermente tra le versioni, quindi la dicitura esatta nella tua amministrazione può essere diversa.

PrestaShop ti dirà senza problemi quanto hai venduto. Apri Statistiche (il controller AdminStats, sotto il menu Dashboard / Statistiche a seconda della versione) e trovi le vendite nel tempo, i prodotti più venduti, la suddivisione per corriere, un cruscotto vendite-e-ordini e un elenco ordinabile dei prodotti più venduti. Quello che nessuna di queste schermate ti dirà è l'unico numero che decide se il tuo negozio è davvero un'attività: quanto denaro ti è rimasto. Il fatturato è ciò che PrestaShop misura per impostazione predefinita. Il profitto è ciò che porti a casa, e i due valori divergono molto più di quanto la maggior parte dei commercianti immagini. Questo articolo parla di come colmare quel divario: la reportistica finanziaria di cui un negozio PrestaShop ha bisogno per gestire in base al margine invece che al giro d'affari, che cosa offre il back office, dove si ferma e come arrivare al profitto reale per prodotto, per ordine, per cliente.

Prima una precisazione, così questo articolo resta nel suo perimetro. Questa è reportistica finanziaria. Denaro in entrata, denaro in uscita, ciò che resta. Non è analisi web. Da dove arrivano i visitatori, come si comportano sulla pagina, quale fonte di traffico converte. È una disciplina separata, che affrontiamo in che cosa monitorare e che cosa ignorare e nelle metriche GA4 che contano davvero. Qui restiamo sul conto economico.

Perché le statistiche native di PrestaShop non possono dirti se sei redditizio

Il motore Statistiche nativo è costruito intorno a fatturato e volume, perché sono i dati che vivono in modo pulito nelle tabelle degli ordini. Quando PrestaShop registra una vendita, memorizza il prezzo pagato dal cliente, l'imposta, la spedizione addebitata e lo stato dell'ordine. Non memorizza, in una forma di reportistica davvero utilizzabile, quanto quell'ordine ti è costato. Quel costo è sparso in punti che le schermate Statistiche non collegano mai tra loro:

• Costo all'ingrosso. PrestaShop ha effettivamente un campo per questo, wholesale_price sul prodotto, impostato in Catalogo → Prodotti → [prodotto] → Prezzi → Prezzo di costo, salvato in ps_product e copiato in ps_order_detail.original_wholesale_price al momento della vendita. Il problema: quasi nessuno lo compila e, anche quando viene compilato, i punti nativi in cui compare, il valore di margine di profitto in Statistiche → Statistiche catalogo e la colonna del profitto per prodotto in Statistiche → Prodotti più venduti / Dettagli prodotto. Sono viste aggregate o medie per prodotto, mai una vista per ordine o per cliente.
• Commissioni di elaborazione dei pagamenti. L'1,4-3% trattenuto da Stripe, PayPal o dal gestore della carta non entra mai in PrestaShop. Un ordine da 100 € viene registrato come 100 € di fatturato anche se sul tuo conto arrivano 97,10 €.
• Costo reale di spedizione. L'ordine memorizza ciò che il cliente ha pagato per la spedizione, mai ciò che il corriere ha addebitato a te. Offri la spedizione gratuita e il totale nativo mostra ricavi di spedizione pari a zero e costo pari a zero, quando in realtà hai pagato il corriere 6 €.
• Rimborsi e resi. Un ordine rimborsato può comunque restare in uno stato che conta come fatturato "valido", a seconda della configurazione degli stati ordine, gonfiando silenziosamente il totale dei ricavi.

Quindi il numero nativo del "Profit margin" va bene come indicazione generale per un controllo di buon senso, ma è inutile per prendere decisioni. Non può dirti quale tra due prodotti dovresti promuovere, perché non vede che uno porta con sé 2 € di commissioni carta e un tasso di reso del 30%, mentre l'altro viene spedito senza questi freni.

Il fatturato è il numero più fuorviante del tuo negozio

Considera due negozi PrestaShop affiancati. Il negozio A fattura 50.000 € al mese; il negozio B ne fattura 20.000 €. Il cruscotto nativo fa sembrare A il vincitore netto. Ora aggiungi i costi che PrestaShop non traccia: A vende elettronica a basso margine con un tasso di reso del 12%, paga l'1,9% di commissioni sulle carte e sovvenziona la spedizione; B vende prodotti a marchio proprio con un margine del 60% e quasi nessun reso. Fai i conti veri e B trattiene più euro ogni mese. Il commerciante che guarda la schermata Statistiche nativa ottimizzerebbe esattamente per il negozio sbagliato.

Questo esempio riassume l'intero motivo per cui serve la reportistica finanziaria. Le metriche che spostano davvero un negozio sono di secondo livello, esistono solo dopo aver sottratto i costi dal fatturato:

• Margine lordo per prodotto, prezzo di vendita meno costo all'ingrosso, meno la commissione di pagamento, il sussidio di spedizione e la quota proporzionale di costi generali attribuibile a quella riga. Il prodotto che sembra il tuo campione nell'elenco dei più venduti a volte è quello che perde denaro in silenzio quando entrano in gioco commissioni e resi.
• Contributo per ordine, ciò che un singolo ordine lascia dopo i propri costi variabili. Due ordini da 80 € non sono uguali se uno è stato spedito gratuitamente dall'altra parte del paese e l'altro era un ritiro in negozio.
• Profitto per segmento di clientela, collegare il valore nel tempo all'acquisizione. Il rapporto tra quanto vale un cliente e quanto costa acquisirlo è un tema a sé; non lo ricalcoliamo qui, i dati sul valore cliente rispetto al costo di acquisizione sono in che cosa monitorare e che cosa ignorare.
• Tasso di reso reale per prodotto e categoria, un tasso di reso del 30% non identifica un prodotto di successo, è un difetto o una descrizione fuorviante che mangia il margine due volte (paghi la spedizione in uscita, assorbi il rientro, potresti non riuscire a rivendere l'articolo).

Che cosa puoi ottenere oggi da PrestaShop, e il muro dell'esportazione

Prima di cercare qualcosa in più, vale la pena sapere esattamente fin dove ti porta la soluzione standard, perché per un catalogo piccolo potrebbe bastare.

Quell'ultima riga è dove finisce la maggior parte dei commercianti, esportare gli ordini in un foglio di calcolo, aggiungere a mano le tabelle delle commissioni e le fatture dei corrieri, ricostruire ogni mese la stessa tabella pivot. Funziona una volta. Non funziona come abitudine settimanale, e un report che esegui solo quando sei preoccupato è un report che intercetta i problemi con un mese di ritardo. Il limite nativo, in tutta onestà, è questo: PrestaShop può mostrarti il fatturato in un cruscotto e i costi solo se vai a scavare nel Gestore SQL con query tue. Unire i due in una vista stabile, pianificata e navigabile del profitto è il muro che il back office non ti fa superare.

Se ti trovi a tuo agio nel Gestore SQL, puoi davvero arrivare lontano, una query che unisce ps_orders, ps_order_detail e original_wholesale_price ti darà un margine lordo reale per ordine. Quello che non puoi fare facilmente lì è integrare dati di costo esterni (il tariffario Stripe, le fatture dei corrieri), pianificarla o consegnarla a un collega non tecnico. È questa la linea tra una query intelligente e un sistema di reportistica.

La query del Gestore SQL che ti dà il margine lordo reale per ordine

Ecco una query di partenza che puoi incollare in Parametri avanzati → Database → Gestore SQL. Somma il fatturato di ogni ordine rispetto al costo all'ingrosso acquisito al momento della vendita, così ottieni il margine lordo per ordine, ciò che le schermate native non ti mostrano. Adatta il prefisso delle tabelle (ps_) se il tuo è diverso, e il filtro sugli ordini validi in base ai tuoi stati ordine:

SELECT
    o.id_order,
    o.reference,
    o.total_paid_tax_excl                              AS revenue_excl_tax,
    SUM(od.product_quantity * od.original_wholesale_price) AS cost_of_goods,
    o.total_paid_tax_excl
        - SUM(od.product_quantity * od.original_wholesale_price) AS gross_margin,
    ROUND(
        100 * (o.total_paid_tax_excl
            - SUM(od.product_quantity * od.original_wholesale_price))
        / NULLIF(o.total_paid_tax_excl, 0)
    , 1)                                               AS margin_pct
FROM ps_orders o
JOIN ps_order_detail od ON od.id_order = o.id_order
WHERE o.valid = 1
GROUP BY o.id_order
ORDER BY gross_margin ASC;

Due avvertenze oneste. Questo è solo margine lordo, sottrae il costo della merce, ma non le commissioni di pagamento, il costo reale di spedizione o i resi, perché PrestaShop non li memorizza (ed è proprio il punto di questo articolo). Ed è veritiero solo quanto lo sono i tuoi dati original_wholesale_price: gli ordini inseriti quando il campo costo era vuoto mostreranno un margine del 100% e falsificheranno l'elenco. L'ordinamento crescente (gross_margin ASC) mette in cima i tuoi ordini peggiori, che di solito sono quelli da guardare per primi.

Dai dati alle decisioni: che cosa cambia quando puoi vedere il profitto

E quindi? Il punto di tutto questo non è avere un cruscotto più bello. È che quattro decisioni quotidiane smettono di essere scommesse:

• Prezzi. Un aumento del 5% su un prodotto con buon margine e domanda stabile è una mossa sicura quando puoi vedere il margine reale attuale accanto alla tendenza delle vendite. Senza visibilità sui costi, la stessa decisione è un testa o croce.
• Che cosa promuovere. La reportistica sul profitto riordina regolarmente l'elenco dei prodotti più venduti. Il campione per volume unitario e il campione per profitto sono spesso prodotti diversi, e tu vuoi che lo spazio in home page, la spesa pubblicitaria e le offerte a pacchetto puntino al secondo.
• Magazzino. Che cosa riassortire, interrompere o liquidare dovrebbe seguire il margine, non il volume. Un prodotto lento con un margine del 65% può meritare più visibilità; un prodotto veloce al 4% può richiedere un aumento di prezzo o un'uscita silenziosa dal catalogo.
• Strategia degli sconti. Una vendita flash che registra 10.000 € di fatturato ma 500 € di profitto dopo lo sconto, le commissioni e la spedizione non è il successo che suggerisce il grafico dei ricavi. La reportistica sensibile al margine te lo dice la mattina dopo, non a fine trimestre.

Colmare il divario con il modulo Financial Revolution

Questo è il lavoro specifico per cui esiste il nostro modulo Financial Revolution: prendere il fatturato che PrestaShop registra già, permetterti di acquisire i costi e le spese che non traccia affatto, e trasformare il risultato in una vista stabile di profitti e perdite dentro il back office, niente foglio di calcolo mensile, niente SQL manuale. Che cosa ti dà, concretamente?

• Una vera vista profitti e perdite, non solo un cruscotto del fatturato, fatturato, costi acquisiti e spese operative, imposte/IVA e profitto risultante, suddivisi per categoria, così il risultato finale che leggi è quello che trattieni davvero invece di un dato di giro d'affari.
• Monitoraggio di costi e spese che PrestaShop non sa dove mettere, registra i costi e le spese generali che la piattaforma non memorizza mai (commissioni dei gestori di pagamento, spedizione reale, spese operative) e sottrai automaticamente tutto dal fatturato invece di aggiungerlo a mano in un foglio di calcolo.
• Reportistica su flusso di cassa, imposte e IVA in un unico punto, movimenti di cassa, report fiscali e IVA, fatture e rettifiche gestiti dentro il back office invece di essere riconciliati a mano a posteriori.
• Vive nella tua amministrazione, consultalo dal back office con la stessa cadenza settimanale con cui controlli già gli ordini, invece di esportare e ricostruire, con esportazione CSV quando devi consegnare i numeri al commercialista.

Limite onesto: un modulo di reportistica fa reportistica, non imposta i prezzi al posto tuo e non ti rimborsa le commissioni carta. Il suo compito è rendere impossibile ignorare il numero vero, così tu puoi agire. Ed è accurato solo quanto lo sono i dati di costo che lo alimentano, che è il punto successivo.

Rendilo affidabile: compila prima i dati di costo

La reportistica finanziaria segue la regola dei dati errati in ingresso e risultati errati in uscita, e il motivo più comune per cui un report di profitto sembra sbagliato sono i campi costo vuoti. Prima di fidarti di qualunque valore di margine, nativo o di un modulo, fai il lavoro di base, poco appariscente ma indispensabile:

• Compila il prezzo all'ingrosso / prezzo di costo su ogni prodotto (Catalogo → Prodotti → Prezzi → Prezzo di costo). Modificalo in blocco o importalo tramite l'importazione Catalogo se hai centinaia di SKU; un report sui margini basato su campi costo mezzi vuoti è peggio di nessun report, perché sembra autorevole e non lo è.
• Conosci il tuo tariffario reale delle commissioni, la percentuale effettiva e la commissione per transazione applicate dal tuo fornitore di pagamento, leggibili da un estratto conto Stripe o PayPal, non il tasso pubblicizzato.
• Recupera i costi reali dei corrieri, non il prezzo di spedizione mostrato al cliente, dalle fatture dei tuoi corrieri, soprattutto se offri spedizione gratuita o a tariffa fissa, dove l'importo pagato dal cliente non ti dice nulla.
• Sistema gli stati ordine in modo che gli ordini rimborsati e annullati non vengano conteggiati in silenzio come fatturato valido. Controlla quali stati sono contrassegnati come logable/pagati in Parametri negozio → Impostazioni ordini → Stati.

Costruisci l'abitudine alla reportistica

Il report più accurato del mondo non vale nulla se nessuno lo apre. I negozi che migliorano nel tempo sono quelli in cui è un numero, non un'intuizione, a chiudere la discussione, e questo accade solo con un ritmo:

• Ogni settimana: profitto totale (non fatturato), i migliori e peggiori prodotti per margine e qualunque oscillazione che meriti un secondo sguardo. Cinque minuti dal back office.
• Ogni mese: tendenze e stagionalità, e se una specifica iniziativa, una modifica di prezzo, un nuovo fornitore, una promozione, ha davvero mosso il profitto invece del solo fatturato.
• Ogni trimestre: l'intera strategia confrontata con i dati. Quali categorie meritano spazio a scaffale, quali clienti vale la pena mantenere, dove si trova il peso morto del catalogo.

PrestaShop misura il fatturato di serie perché il fatturato è il numero facile da memorizzare. Il profitto è il numero che fa funzionare l'attività, e arrivarci significa sottrarre i costi che la piattaforma disperde o ignora, acquisto all'ingrosso, commissioni, spedizione reale, resi. Che tu ci arrivi con una query accurata nel Gestore SQL, con un foglio di calcolo disciplinato o con un modulo che fa le unioni per te, la disciplina è la stessa: gestisci in base a ciò che trattieni, non a ciò che incassi, e leggilo abbastanza spesso da intercettare la discesa prima che abbia già un trimestre di età.

Domande frequenti

Perché il margine di profitto nativo di PrestaShop sembra sbagliato o vuoto?

Quasi sempre perché il campo del prezzo di costo è vuoto. Il margine di Statistiche → Statistiche catalogo di PrestaShop viene calcolato da wholesale_price, e se non lo hai mai compilato sui prodotti, il dato è privo di significato. Anche quando è compilato, il numero nativo è una sola percentuale globale media che ignora commissioni di pagamento, costo reale di spedizione e resi, quindi va bene come controllo approssimativo di buon senso ed è inutile per decidere quale prodotto promuovere. Compila prima i prezzi di costo; poi decidi se la vista nativa basta o se ti serve il dettaglio per ordine.

Posso calcolare il profitto reale per ordine senza un modulo?

Sì, per il margine lordo, la query del Gestore SQL qui sopra unisce ps_orders e ps_order_detail su original_wholesale_price e ti dà il margine per ordine. Quello che non puoi fare nel Gestore SQL senza un lavoro notevole è integrare costi esterni (il tariffario Stripe, le fatture dei corrieri), pianificare il report o consegnarlo a un collega non tecnico. Quel divario, unire dati di costo esterni in un conto economico stabile e navigabile. È la linea tra una query intelligente e un sistema di reportistica come Financial Revolution.

Dove salva PrestaShop il prezzo di costo e come posso compilarlo in blocco?

Il prezzo di costo vive in wholesale_price su ps_product (e per combinazione, dove lo imposti), modificato in Catalogo → Prodotti → Prezzi → Prezzo di costo. Al momento della vendita PrestaShop lo copia in ps_order_detail.original_wholesale_price, motivo per cui gli ordini storici conservano il costo valido quando sono stati effettuati. Per centinaia di SKU, compilalo tramite l'importazione CSV del Catalogo invece che a mano, e ricorda che gli ordini effettuati prima della compilazione non mostreranno alcun costo, quindi non fidarti del margine sugli ordini vecchi.

Financial Revolution traccia automaticamente commissioni di pagamento e costi di spedizione?

Ti offre il posto in cui registrarli e li sottrae automaticamente dal fatturato una volta inseriti, ma non può leggere per te l'estratto conto Stripe o la fattura del corriere. Il compito del modulo è acquisire i costi che PrestaShop non ha dove memorizzare (commissioni dei gestori, spedizione reale, spese operative) e integrarli in un conto economico nel back office, così smetti di ricostruire un foglio di calcolo. L'accuratezza dipende comunque dall'inserimento del tariffario reale delle commissioni e dei costi dei corrieri; dati errati in ingresso, risultati errati in uscita vale qui come altrove.

È la stessa cosa dei miei dati GA4 o di analisi?

No, e confonderli è un errore comune. Questa è reportistica finanziaria: denaro in entrata, denaro in uscita, ciò che resta. GA4 e strumenti simili sono analisi web: da dove arrivano i visitatori, come si comportano, quale canale converte. Rispondono a domande diverse e nessuno dei due sostituisce l'altro. Per la parte di analisi, parti da che cosa monitorare e che cosa ignorare e dalle metriche GA4 che contano davvero.