Finance reporting automatizzato: Stripe, WeTravel, QuickBooks in un'unica fonte di verità

Nei progetti ecommerce e service-led che seguo, la stessa scena si ripete spesso: il team finance apre la mattina con tre o quattro tab — Stripe, una piattaforma di prenotazione o checkout secondaria, il gestionale contabile, un foglio Google riempito a mano la sera prima. Da quei tab nasce un report che dovrebbe essere “la fonte di verità”, ma che in realtà nasce già obsoleto e contiene un paio di duplicati che nessuno ha tempo di scovare. Il risultato non è solo perdita di tempo: è una marginalità che non si riesce a leggere con la precisione necessaria per prendere decisioni di pricing o di mix di prodotto.

Questo articolo descrive un pattern che ho applicato più volte per consolidare entrate da più revenue stream in un’unica fonte di verità — Stripe, una piattaforma di prenotazione tipo WeTravel, e l’export contabile da QuickBooks o Xero — usando Make.com come collante. L’obiettivo non è “automatizzare il report finale”: è eliminare il lavoro manuale di riconciliazione e produrre dati che il team contabile possa firmare senza riaprire le sorgenti.

Il problema vero non è l’export, è la deduplica

Chi ha provato ad aggregare Stripe con un altro processore o con una piattaforma di booking sa che il punto critico non è scaricare i dati. Entrambi gli ecosistemi offrono API o export CSV. Il punto critico è che lo stesso pagamento spesso compare due volte: una transazione Stripe che corrisponde a una prenotazione gestita altrove, oppure un pagamento che parte da una piattaforma terza e poi atterra come settlement nel conto bancario tracciato dalla contabilità.

Senza una chiave di deduplica robusta, il report di fine mese gonfia il revenue del 15-25%. Con una chiave sbagliata, lo gonfia comunque ma in modo non rilevabile a occhio. Il primo lavoro vero, prima di scrivere un singolo scenario Make, è definire la chiave composta giusta.

In un progetto education / travel su cui ho lavorato la chiave è risultata Program + Email: il nome del programma a cui il cliente si è iscritto, più la sua email normalizzata in lowercase. Né Stripe da solo, né WeTravel da solo, contenevano abbastanza informazione per fare la deduplica — andavano incrociati. La logica:

1. Recupero giornaliero dei pagamenti Stripe via export CSV (in casi più puliti, via API).
2. Recupero giornaliero delle prenotazioni WeTravel via API.
3. Normalizzazione: trim, lowercase email, matching del nome programma su una tabella di alias.
4. Costruzione della chiave slug(program) + "|" + lower(email).
5. Upsert in un Google Sheet “master finance” con quella chiave come identificatore unico.

Il risultato pratico è che lo stesso pagamento, anche se compare in entrambe le sorgenti, finisce in una sola riga nel master. Da quella riga si possono poi separare i revenue stream (programmi, retreat, prodotti, eccetera) e produrre dashboard per categoria senza più sommare due volte la stessa cifra.

Il workaround QuickBooks “no custom reports”

QuickBooks Online è un buon gestionale ma ha un limite noto: la sua API non espone i custom report che si costruiscono nell’interfaccia. Si possono però estrarre i report standard — P&L, Balance Sheet, Aged Receivables, Aged Payables — via /reports endpoint, e da lì costruirsi tutto il resto a valle.

Il pattern che uso è semplice: uno scenario Make schedulato (giornaliero per P&L sintetico, settimanale per balance sheet completo) che chiama l’endpoint QBO, parsa la risposta JSON gerarchica e scrive le righe in un foglio strutturato. Da lì le pivot table e i grafici diventano un problema di Sheets, non di QuickBooks. È un workaround, non una soluzione elegante, ma elimina la rilavorazione manuale che il team finance fa ogni lunedì.

Per chi usa Xero invece di QuickBooks il pattern cambia ma il principio resta. In un progetto luxury furniture resale ho gestito tutto il flusso con un “Xero Daily Journal Sweep”: un cron notturno (in quel caso pg_cron su Supabase, ma il pattern è identico in Make) che alle 02:00 raccoglie le transazioni della giornata, costruisce le journal entries e le posta su Xero tramite un dispatcher dedicato. Sul dispatcher centralizzato passano tutte le scritture — invoice, journal, edit di invoice già emesse, gestione delle gift card che richiedono carve-out contabili specifici. La logica di business sta in un posto solo; Xero diventa il sink, non il sistema che dirige.

L’architettura in pratica

L’architettura tipica per un setup multi-source con Make.com è a tre livelli:

Ingestion layer. Uno scenario per sorgente, ciascuno con la propria cadenza. Stripe ogni 4 ore, WeTravel ogni 4 ore, QuickBooks una volta al giorno post-chiusura. Ogni scenario scrive in una “staging sheet” non normalizzata, mantenendo i campi originali.

Normalization layer. Uno scenario che gira di notte, legge le staging sheet, applica le regole di normalizzazione (mappa alias programmi, email lowercase, conversione valute con tasso del giorno) e costruisce le chiavi di deduplica.

Master layer. Una sola sheet “verità”, con upsert per chiave. Da qui partono le pivot, i Looker Studio, gli eventuali export per il commercialista.

Il vantaggio di separare i tre livelli è che quando una sorgente cambia formato — Stripe rinomina un campo, WeTravel introduce una nuova tipologia di booking — si tocca solo l’ingestion. Le regole di normalizzazione restano centralizzate, e il master non sa nulla delle sorgenti.

La metrica realistica

Su un progetto con due revenue stream principali e volumi medi (qualche centinaio di transazioni al mese), il tempo manuale di consolidamento e riconciliazione era circa due ore al giorno: scaricare CSV, pulire duplicati a mano, costruire pivot in Excel, controllare quadrature. Dopo aver messo in produzione il pattern descritto, il lavoro residuo è circa cinque minuti al giorno: aprire il master, controllare l’indicatore “righe in attenzione” (transazioni che hanno fallito la normalizzazione e sono finite in una sheet di quarantena), decidere caso per caso.

Da due ore a cinque minuti è un fattore 24x, ma non è il numero che conta di più. Il numero che conta è che il team contabile firma il report di fine mese il primo giorno utile, non il quinto. La chiusura mensile passa da settimana a giornata. Questo a sua volta abilita decisioni di pricing e di mix più veloci, perché i dati che servono al management non arrivano più con tre settimane di ritardo.

Quando non farlo

Questo pattern non ha senso se i volumi sono bassissimi (sotto le venti transazioni al mese, fai prima a mano) o se c’è un’unica sorgente che il gestionale gestisce già bene. Non ha senso nemmeno se la priorità è la conformità fiscale in giurisdizioni complesse: lì serve un commercialista con strumenti dedicati, non un consolidamento in Sheets. Make.com brilla nella fascia intermedia — qualche centinaio o migliaio di transazioni al mese, due o tre revenue stream da incrociare, un team finance piccolo che vuole tempo per pensare ai numeri invece che per copiarli.

Il consolidamento finance automatizzato non è glamour. Non è il caso d’uso che fa scintillare le slide. Ma è probabilmente quello con il ROI più diretto e più facile da difendere davanti a un CFO: tempo recuperato, errori eliminati, chiusura mensile più veloce. Tre numeri che parlano la lingua giusta.