DEV Community: S-Data

Web scraping legale per aziende: GDPR, robots.txt e banche dati

S-Data — Thu, 29 Oct 2026 19:28:56 +0000

Raccogliere dati dal web in modo automatico può essere molto utile a un'azienda: monitorare i listini dei concorrenti, tenere aggiornato un catalogo, seguire bandi e pubblicazioni, alimentare un report. Ma "è pubblico, quindi posso prenderlo" non è un criterio sufficiente. In Italia e nell'Unione Europea entrano in gioco almeno quattro piani diversi: la protezione dei dati personali, le condizioni d'uso del sito, i diritti sulle banche dati e il comportamento tecnico verso il server che si interroga.

Questa guida mette in fila le domande da porsi prima di partire, con una checklist finale.

Nota: questo articolo è informativo e non costituisce consulenza legale. Per un progetto concreto, soprattutto se coinvolge dati personali, fate valutare il caso a un legale o al vostro DPO.

1. Prima domanda: che dati raccogliete?

La distinzione più importante è tra dati che riguardano persone e dati che non le riguardano.

Dati non personali: prezzi, disponibilità, caratteristiche tecniche dei prodotti, orari, testi di bandi. Qui il GDPR in genere non entra in gioco, mentre restano gli altri piani (condizioni d'uso, banche dati, carico sul server).
Dati personali: nomi, email, numeri di telefono, profili, recensioni firmate, foto. Qui si applica il Regolamento (UE) 2016/679 (GDPR), anche se i dati sono liberamente visibili online.

Il punto che si dimentica più spesso è proprio questo: un dato personale pubblicato su un sito resta un dato personale. Il fatto che sia accessibile non dà automaticamente il diritto di raccoglierlo, copiarlo in un database e usarlo per altri scopi.

2. Se ci sono dati personali: GDPR

Se il progetto tocca dati personali, servono risposte chiare ad alcune domande che derivano direttamente dal GDPR:

Base giuridica (art. 6): su cosa si fonda il trattamento? Nei progetti aziendali si valuta spesso il legittimo interesse, che però richiede un bilanciamento documentato con i diritti delle persone interessate e non è una formula valida per tutto.
Finalità e minimizzazione (art. 5): raccogliete solo i campi che servono davvero allo scopo dichiarato. Se vi serve sapere quante recensioni negative ha un prodotto, probabilmente non vi servono i nomi di chi le ha scritte.
Informativa (art. 14): quando i dati non vengono raccolti presso l'interessato, il GDPR prevede comunque obblighi di informazione, con alcune eccezioni da valutare caso per caso.
Conservazione e sicurezza: per quanto tempo tenete i dati, dove, chi vi accede.

Il Garante per la protezione dei dati personali ha pubblicato nel 2024 una nota informativa dedicata al web scraping, rivolta soprattutto ai gestori di siti che vogliono difendersi dalla raccolta massiva di dati personali, ma utile anche a chi lo scraping lo fa.

Una regola prudente: se un obiettivo si può raggiungere senza dati personali, progettate il sistema per non raccoglierli affatto, invece di raccoglierli e filtrarli dopo.

3. Le condizioni d'uso del sito

Molti siti hanno termini di servizio che vietano o limitano l'estrazione automatica dei contenuti. Il loro peso dipende da diversi fattori, per esempio se l'utente li ha accettati (con una registrazione o un login) e da come sono formulati. Due indicazioni pratiche:

Leggeteli prima, non dopo. Se il sito vieta esplicitamente lo scraping, è un elemento da valutare seriamente insieme a chi segue gli aspetti legali.
Attenzione alle aree riservate: estrarre dati da sezioni accessibili solo dopo login, con un account che ha accettato condizioni contrarie, è una situazione molto diversa dal leggere pagine pubbliche.

4. Banche dati: il diritto sui generis

La Direttiva 96/9/CE sulla tutela giuridica delle banche dati, recepita in Italia nella legge sul diritto d'autore (L. 633/1941), prevede oltre al diritto d'autore un diritto sui generis a favore di chi ha fatto un investimento rilevante per costituire, verificare o presentare una banca dati.

In sintesi, questo diritto consente al costitutore di vietare:

l'estrazione o il reimpiego della totalità o di una parte sostanziale del contenuto;
l'estrazione ripetuta e sistematica di parti non sostanziali, quando questo contrasta con il normale sfruttamento della banca dati o arreca un pregiudizio ingiustificato al costitutore.

Il secondo punto è rilevante per lo scraping: anche prelevare poco alla volta, se fatto in modo sistematico fino a ricostruire una parte importante dell'archivio, può ricadere nel divieto.

Va considerata anche la Direttiva (UE) 2019/790, che disciplina il text and data mining: tra le altre cose prevede che i titolari dei diritti possano riservarsi l'uso dei contenuti con strumenti leggibili da una macchina. Se il sito esprime questa riserva, è un'informazione da tenere in conto.

5. robots.txt: non è una legge, ma è un segnale

Il file robots.txt (oggi descritto nello standard RFC 9309) indica quali percorsi del sito il gestore non vuole che vengano visitati dai programmi automatici. Non è di per sé una norma di legge, ma ignorarlo significa ignorare una volontà espressa chiaramente dal gestore, e questo pesa nella valutazione complessiva del progetto.

In pratica: leggete il robots.txt del sito, rispettate i percorsi esclusi e le eventuali indicazioni sul ritmo delle richieste. Se i dati che vi servono stanno in una sezione esclusa, è il momento di chiedersi se esiste un'altra strada.

6. Carico sul server e rate limit

Uno scraper scritto male può mandare in difficoltà un sito, soprattutto se piccolo, e finire bloccato. Le buone pratiche tecniche sono semplici:

limitare la frequenza delle richieste, con pause tra una pagina e l'altra e poche connessioni in parallelo;
rispettare i segnali del server: se arriva un errore HTTP 429 (troppe richieste) o un'intestazione Retry-After, rallentare o fermarsi;
lavorare negli orari di minor traffico quando possibile;
scaricare solo ciò che è cambiato, usando cache e richieste condizionali invece di riscaricare tutto ogni volta;
identificarsi in modo onesto e non aggirare le misure di protezione del sito, come captcha o blocchi di accesso.

7. L'alternativa da valutare per prima: le API ufficiali

Prima di scrivere uno scraper conviene sempre verificare se la fonte offre un canale ufficiale:

API pubbliche o a pagamento, con condizioni d'uso chiare;
feed (RSS, XML, CSV) o file di esportazione;
open data pubblicati dalle pubbliche amministrazioni;
accordi diretti con il gestore, per esempio con un fornitore che può mandarvi il listino in un formato strutturato.

Un'API ufficiale è quasi sempre più stabile di uno scraper, che si rompe ogni volta che il sito cambia grafica, e chiarisce in partenza cosa si può fare con i dati. Lo scraping ha senso quando un canale ufficiale non esiste o non copre quello che serve.

Checklist prima di avviare un progetto

Obiettivo: quale decisione o processo deve alimentare il dato? Scrivetelo in una frase.
Campi: elencate i campi necessari ed eliminate quelli superflui, in particolare quelli personali.
Fonti: per ogni sito, esiste un'API, un feed o un open data alternativo?
Condizioni d'uso: le avete lette? Contengono divieti o limiti sull'estrazione automatica?
robots.txt e riserve TDM: i percorsi che vi servono sono consentiti?
Banca dati: state prelevando una parte sostanziale di un archivio costruito da altri, anche a piccoli pezzi?
Dati personali: se ci sono, base giuridica, informativa, conservazione e sicurezza sono documentate?
Frequenza e carico: ogni quanto serve aggiornare? Avete previsto pause, limiti e gestione degli errori 429?
Uso finale: i dati restano interni o verranno ripubblicati? Il reimpiego verso terzi richiede una valutazione più attenta.
Manutenzione: chi si accorge se il sito cambia struttura e lo scraper smette di funzionare?

Se a qualcuna di queste domande non sapete rispondere, è meglio fermarsi e chiarire prima di scrivere codice.

Per approfondire

Se state valutando un progetto di raccolta dati, potete vedere come impostiamo fonti, frequenze e limiti tecnici nella pagina del nostro servizio di web scraping. Quando la fonte mette a disposizione un canale ufficiale, la strada più solida resta l'integrazione tramite sviluppo e integrazione API.

Checklist per il brief di un gestionale su misura: cosa preparare

S-Data — Thu, 29 Oct 2026 18:37:44 +0000

Prima di chiedere un preventivo per un gestionale su misura conviene mettere per iscritto cosa deve fare. Non serve un capitolato di cento pagine. Bastano poche pagine chiare, che rispondano alle domande che qualsiasi sviluppatore farà comunque. Un brief fatto bene rende i preventivi confrontabili, riduce le sorprese durante lo sviluppo e ti permette di capire se chi hai davanti ha capito il tuo lavoro.

Questa è la checklist che consigliamo di preparare, sezione per sezione.

1. I processi, descritti come succedono davvero

Parti da come lavorate oggi, non da come vorreste lavorare in teoria. Per ogni processo che il gestionale deve coprire (preventivi, ordini, commesse, magazzino, interventi, fatturazione) scrivi:

chi lo avvia e da cosa parte (una telefonata, un'email, un ordine dal sito);
i passaggi, in ordine, con chi fa cosa;
dove si blocca oggi: doppi inserimenti, fogli Excel passati di mano, informazioni che si perdono;
le eccezioni: il cliente che paga in modo diverso, l'ordine urgente, il reso.

Le eccezioni sono la parte che si dimentica più spesso, ed è quella che fa lievitare tempi e costi se emerge a metà progetto. Se avete moduli cartacei, file Excel o email tipo, allegali come esempio: valgono più di molte descrizioni.

Un consiglio pratico: distingui i processi in indispensabili per partire e utili in un secondo momento. Ti servirà per decidere cosa mettere nel primo rilascio.

2. Ruoli e permessi

Elenca chi userà il gestionale e cosa deve poter fare. Una tabella semplice basta:

Ruolo	Vede	Modifica	Approva
Amministrazione	tutto	anagrafiche, fatture	pagamenti
Commerciale	i propri clienti	preventivi	—
Tecnico	i propri interventi	rapportini	—
Titolare	tutto	tutto	tutto

Indica anche quante persone, più o meno, useranno ogni ruolo, se qualcuno lavora da mobile o fuori sede e se servono accessi per soggetti esterni (agenti, clienti, fornitori). Tutto questo incide sull'architettura e sulla sicurezza, e va saputo subito.

3. I dati da migrare

Il recupero dei dati esistenti è spesso sottovalutato. Prepara un elenco di:

cosa va portato nel nuovo sistema: anagrafiche clienti e fornitori, articoli, listini, storico documenti, commesse aperte;
da dove arriva: il vecchio gestionale, file Excel, Access, un database, un software in cloud;
quanto storico serve davvero: tutto, gli ultimi anni o solo i dati aperti;
in che stato sono i dati: doppioni, campi usati in modo diverso da persone diverse, codici non coerenti.

Se possibile, estrai un campione reale (anche anonimizzato) e allegalo. Chi deve stimare la migrazione capisce molto di più da un file vero che da una descrizione. Chiarisci anche chi si occupa della pulizia dei dati: se la fa il fornitore è lavoro da mettere in preventivo, se la fate voi va pianificata prima.

4. Le integrazioni con altri sistemi

Un gestionale raramente vive da solo. Elenca ogni sistema con cui deve scambiare dati e, per ciascuno, in che direzione e con che frequenza:

Fatturazione elettronica e SdI: il gestionale genera l'XML e lo invia tramite un intermediario, oppure passa i dati a un software di fatturazione che già usate? Serve ricevere le fatture passive?
ERP o contabilità esistente: cosa resta lì e cosa passa al nuovo sistema, e chi è il "padrone" di ogni dato (per esempio, le anagrafiche si modificano solo in un posto).
E-commerce: ordini, giacenze, prezzi, stati di spedizione. In tempo reale o a intervalli?
Altro: banca, corrieri, CRM, posta elettronica, firma digitale, macchinari o sensori in produzione.

Per ogni integrazione indica se il sistema dall'altra parte ha delle API documentate, se esporta file o se oggi i dati si copiano a mano. È una delle voci che pesa di più sulla stima, e saperlo in anticipo evita preventivi "al buio".

5. Report e numeri che vi servono

Scrivi quali informazioni volete ottenere dal gestionale, non solo quali inserire. Per esempio:

margine per commessa o per cliente;
ordini aperti e in ritardo;
scadenziario incassi e pagamenti;
carico di lavoro per tecnico o reparto.

Per ogni report indica chi lo guarda, ogni quanto e in che formato (a schermo, PDF, export Excel). Se oggi avete già un file Excel che fa questo lavoro, allegalo: è la specifica migliore possibile.

6. Criteri di accettazione

Questa è la sezione che distingue un brief da una lista di desideri. Per ogni funzione importante scrivi come capirete che funziona. Qualche esempio:

"Un commerciale crea un preventivo da un cliente esistente, lo trasforma in ordine e l'amministrazione lo vede senza reinserirlo."
"Una fattura generata dal gestionale viene accettata dallo SdI senza scarti per i casi standard che usiamo (cliente italiano, split payment, reverse charge)."
"Il tecnico compila il rapportino da telefono anche con connessione scarsa e i dati arrivano in ufficio appena torna la rete."

Criteri così sono verificabili da entrambe le parti, chiudono le discussioni del tipo "pensavo facesse anche…" e diventano la base per il collaudo di ogni rilascio.

7. Proprietà del codice e dei dati

Va chiarito per iscritto prima di firmare, non dopo:

di chi è il codice sorgente e se ne riceverete una copia;
di chi sono i dati e in che formato potrete esportarli in qualsiasi momento;
dove gira il sistema: server vostro, cloud a vostro nome o infrastruttura del fornitore;
cosa succede se cambiate fornitore: documentazione, credenziali, accessi.

Non esiste una risposta giusta per tutti, ma deve esistere una risposta scritta. Un gestionale su misura è un investimento pluriennale, e la libertà di cambiare chi lo mantiene è parte del suo valore.

8. Manutenzione ed evoluzione

Il giorno del rilascio non è la fine del progetto. Nel brief chiedi esplicitamente:

come si gestiscono bug e segnalazioni, e in quanto tempo;
chi si occupa di aggiornamenti di sicurezza, backup e hosting;
come si stimano e si pagano le modifiche future;
cosa succede quando cambiano le regole esterne, per esempio le specifiche tecniche della fattura elettronica.

Così potete confrontare i preventivi sul costo complessivo negli anni, non solo sul prezzo iniziale.

9. Vincoli, tempi e budget

Chiudi il brief con i paletti: entro quando vi serve il primo rilascio, periodi in cui non potete fermarvi (chiusure di bilancio, alta stagione), persone interne che seguiranno il progetto e quanto tempo possono dedicarci.

Indicare una fascia di budget, anche ampia, non è una debolezza: permette al fornitore di proporre la soluzione giusta per quella cifra invece di un progetto ideale fuori portata. Per avere un ordine di grandezza, nella nostra esperienza un'automazione mirata o un primo modulo su un solo processo si collocano in genere tra 3.000 e 7.500 €, un gestionale con più moduli collegati tra 7.500 e 18.000 € e un gestionale completo che copre più reparti tra 18.000 e 40.000 € (IVA esclusa). Il numero vero dipende proprio dalle voci di questa checklist: processi, integrazioni e dati da recuperare.

Una pagina di riepilogo

Se il brief è lungo, aggiungi in testa una pagina di sintesi:

cosa fa l'azienda, in tre righe;
i 3-5 problemi che il gestionale deve risolvere;
i processi indispensabili per il primo rilascio;
le integrazioni obbligatorie;
tempi e fascia di budget.

È la pagina che chiunque leggerà per prima, e spesso basta per capire se ha senso approfondire.

Per approfondire

Se state valutando un gestionale su misura, portare questa checklist già compilata al primo incontro con il fornitore accorcia molto i tempi di analisi. Per capire come ogni voce del brief incide sul prezzo finale trovate le fasce e i fattori di costo nella guida quanto costa un software gestionale su misura.

Fattura elettronica XML: gli errori più comuni che fanno scartare il file dallo SdI (e come evitarli)

S-Data — Tue, 27 Oct 2026 22:16:37 +0000

Chi genera fatture elettroniche da PDF o da Excel scopre presto che «produrre un XML» e «produrre un XML che lo SdI accetta» sono due lavori diversi. Qui metto in ordine i motivi di scarto che un convertitore può provocare, con codici e significati presi dai documenti ufficiali.

Fonti usate: Allegato A – Specifiche tecniche versione 1.9.1 (Agenzia delle Entrate), Elenco dei controlli versione 2.0 (fatturapa.gov.it) e lo schema Schema_VFPR12 versione 1.2.3. I link sono in fondo.

Due livelli di controllo, non uno

Validazione dello schema (XSD). Controlla struttura, ordine degli elementi, tipi e formati. Un file che non la supera è, in pratica, «non conforme al formato»: 00200, e nel messaggio lo SdI indica il punto preciso. Se gli errori di formato sono più di 50, lo SdI si ferma con il 00201.
Controlli di contenuto. Coerenza dei numeri, identificativi fiscali, codice destinatario, unicità. Qui lo schema non ti aiuta: un file può essere valido sull'XSD e venire scartato lo stesso.

Per questo conviene validare in locale sull'XSD, ma non fermarsi lì.

Codici di scarto da conoscere

Significati come da Elenco controlli v2.0 e Allegato A 1.9.1:

Codice	Significato
00200	File non conforme al formato (il messaggio indica la non conformità puntuale)
00300 / 00301 / 00305	Identificativo fiscale non valido: `IdCodice` del trasmittente (00300), del cedente/prestatore (00301), del cessionario/committente (00305). Il controllo verifica la presenza in anagrafe tributaria; non si applica agli identificativi assegnati da autorità estere
00311	`CodiceDestinatario` non valido
00400	`Natura` assente con `AliquotaIVA` pari a zero
00401	`Natura` presente con `AliquotaIVA` diversa da zero (con l'eccezione del TipoDocumento TD16)
00404	Fattura duplicata: stesso cedente, stesso anno della data, stesso numero di una fattura già trasmessa e non scartata
00421 / 00422 / 00423	`Imposta`, `ImponibileImporto` e `PrezzoTotale` non calcolati secondo le regole delle specifiche
00424	`AliquotaIVA` non espressa in termini percentuali
00427	`CodiceDestinatario` di lunghezza non ammessa per il `FormatoTrasmissione` (7 caratteri con FPA12, 6 con FPR12)

Altri due: 00417 (del cessionario/committente deve esserci almeno uno tra partita IVA e codice fiscale) e 00425 (il Numero documento deve contenere almeno un carattere numerico).

Dove sbaglia un convertitore PDF/Excel → XML

Date. Nello schema Data è un xs:date: formato 2026-10-27. Una data letta dal PDF come 27/10/2026 non passa l'XSD (l'ho provato). La data non può nemmeno essere successiva alla ricezione da parte dello SdI (00403).

Decimali e arrotondamenti. Qui nascono molti scarti 00421–00423. Le regole:

PrezzoTotale deve essere uguale a (PrezzoUnitario ± ScontoMaggiorazione) × Quantita, con tolleranza di ±1 centesimo (00423);
Imposta è AliquotaIVA × ImponibileImporto / 100, arrotondata alla seconda cifra decimale (per difetto se la terza è inferiore a 5, per eccesso se uguale o maggiore), tolleranza ±1 centesimo (00421);
ImponibileImporto per ogni aliquota è la somma dei PrezzoTotale delle righe con quell'aliquota (più contributo cassa e arrotondamento, se presenti), con tolleranza di ±1 euro (00422).

Nello schema Imposta e ImportoTotaleDocumento ammettono esattamente due decimali: 8.250 è respinto, 8.25 passa. PrezzoUnitario ne accetta da 2 a 8, la Percentuale di sconto solo 2. L'Agenzia stessa segnala nelle sue FAQ che il 00423 compare spesso con gli sconti quando il sistema di origine lavora con più decimali di quelli previsti dal tracciato. In un convertitore: calcola con tipi decimali (mai float), arrotonda come da specifica e confronta i totali ricostruiti con quelli del documento sorgente.

Aliquote e Natura. AliquotaIVA va scritta come 22.00, non 22 e non 0.22. Attenzione: 0.22 è valido per l'XSD, perché ha due decimali, ma non è «in termini percentuali» e lo SdI risponde 00424. Con aliquota 0.00 serve la Natura (00400), con aliquota diversa da zero non va messa (00401). I codici generici N2, N3 e N6 non sono più ammessi come natura dell'operazione (controllo 00445), ma l'XSD li accetta ancora: serve il sottocodice (per esempio N2.2).

Codice destinatario e PEC. Il CodiceDestinatario ha 7 caratteri per i privati (FPR12) e 6 per la PA. 0000000 si usa quando il destinatario riceve via PEC indicata in PECDestinatario o quando non si conosce il canale. XXXXXXX è solo per soggetti non residenti: con un IdPaese italiano del cessionario viene scartato con 00313. Un codice a 6 caratteri in una fattura FPR12 supera l'XSD (che accetta 6–7 caratteri) ma fa scattare il 00427.

Partita IVA e codice fiscale. L'esistenza la verifica lo SdI (00300, 00301, 00305), non lo schema. Dal PDF possono arrivare spazi, prefissi «IT» ripetuti o zeri persi: normalizza prima di scrivere IdCodice.

Ordine degli elementi. Lo schema è una sequenza: mettere PrezzoUnitario prima di Quantita produce un errore (Element 'Quantita': This element is not expected). Se generi l'XML da un dizionario, non dare per scontato l'ordine delle chiavi.

Encoding e caratteri. Le descrizioni ammettono solo caratteri Basic Latin e Latin-1 Supplement: è, à passano, mentre il trattino lungo – e il simbolo €, comunissimi nel testo copiato da un PDF, vengono respinti dall'XSD. Sostituiscili prima di scrivere. Anche Numero è limitato a 20 caratteri Basic Latin.

Numero e duplicati. Il numero deve avere almeno una cifra (00425). Ritrasmettere lo stesso numero è un problema solo se la fattura precedente non è stata scartata (00404): dopo uno scarto, la stessa fattura corretta può essere inviata di nuovo con lo stesso numero.

Dimensioni e nome file. Il singolo file fattura non può superare 5 MB. Il nome segue IdPaese + codice trasmittente, underscore, progressivo alfanumerico di massimo 5 caratteri, ad esempio IT01234567890_00001.xml.

Un frammento corretto

Il blocco righe e riepilogo di una fattura TD01 con due aliquote (22% e operazione con natura N2.2). Ho validato il file completo da cui è estratto sull'XSD 1.2.3 con libxml2: l'esito riguarda solo lo schema. I controlli di contenuto dello SdI (anagrafe, destinatario) non si possono riprodurre in locale, e i dati sono inventati.

<DatiBeniServizi>
  <DettaglioLinee>
    <NumeroLinea>1</NumeroLinea>
    <Descrizione>Consulenza tecnica</Descrizione>
    <Quantita>3.00</Quantita>
    <UnitaMisura>ore</UnitaMisura>
    <PrezzoUnitario>12.50</PrezzoUnitario>
    <PrezzoTotale>37.50</PrezzoTotale>
    <AliquotaIVA>22.00</AliquotaIVA>
  </DettaglioLinee>
  <DettaglioLinee>
    <NumeroLinea>2</NumeroLinea>
    <Descrizione>Rimborso spese documentate</Descrizione>
    <PrezzoUnitario>100.00</PrezzoUnitario>
    <PrezzoTotale>100.00</PrezzoTotale>
    <AliquotaIVA>0.00</AliquotaIVA>
    <Natura>N2.2</Natura>
  </DettaglioLinee>
  <DatiRiepilogo>
    <AliquotaIVA>22.00</AliquotaIVA>
    <ImponibileImporto>37.50</ImponibileImporto>
    <Imposta>8.25</Imposta>
    <EsigibilitaIVA>I</EsigibilitaIVA>
  </DatiRiepilogo>
  <DatiRiepilogo>
    <AliquotaIVA>0.00</AliquotaIVA>
    <Natura>N2.2</Natura>
    <ImponibileImporto>100.00</ImponibileImporto>
    <Imposta>0.00</Imposta>
    <RiferimentoNormativo>Esempio di riferimento normativo</RiferimentoNormativo>
  </DatiRiepilogo>
</DatiBeniServizi>

Per validare in locale basta qualche riga (serve lo schema scaricato dal sito dell'Agenzia):

from lxml import etree

schema = etree.XMLSchema(etree.parse("Schema_VFPR12_v1.2.3.xsd"))
doc = etree.parse("fattura.xml")
if not schema.validate(doc):
    for e in schema.error_log:
        print(e.line, e.message)

Nota: lo schema importa lo schema xmldsig del W3C; se la rete non è disponibile, scaricane una copia e sostituisci il percorso nell'import.

Checklist finale

Date in formato AAAA-MM-GG, non successive all'invio.
Importi con punto decimale, due decimali dove richiesto; calcoli con tipi decimali.
Ricalcola PrezzoTotale, Imposta e ImponibileImporto e verifica le tolleranze prima di scrivere.
AliquotaIVA in percentuale (22.00); Natura solo con aliquota zero, e mai N2, N3 o N6 generici.
CodiceDestinatario di 7 caratteri per FPR12; 0000000 con PECDestinatario; XXXXXXX solo per non residenti.
Partita IVA e codice fiscale normalizzati; almeno uno dei due per il cessionario.
Elementi nell'ordine dello schema.
Testo ripulito dai caratteri fuori da Basic Latin e Latin-1 (trattini lunghi, €).
Numero con almeno una cifra, massimo 20 caratteri; file sotto 5 MB; nome file corretto.
Validazione sull'XSD ufficiale aggiornato alla versione in vigore, a ogni cambio di specifiche.

Per approfondire

Se ti serve generare questi file da documenti esistenti, qui trovi come funziona un convertitore da PDF a XML per la fattura elettronica; il quadro generale è nella pagina sulla fatturazione elettronica. S-Data sviluppa convertitori su misura: se il tuo caso non rientra negli strumenti già pronti, se ne può parlare.

Fonti ufficiali

Allegato A – Specifiche tecniche 1.9.1 (Agenzia delle Entrate)
Elenco dei controlli, versione 2.0 (fatturapa.gov.it)
Schema VFPR12 1.2.3 (Agenzia delle Entrate)
Controlli SdI / motivi di errore (FAQ)

Software su misura o pacchetto: come decidere (e come fare il conto su 3-5 anni)

S-Data — Tue, 27 Oct 2026 12:56:38 +0000

La domanda «meglio su misura o a pacchetto?» ha una risposta onesta in due righe, e va detto subito: se il pacchetto ti basta, è la scelta giusta.

Il pacchetto basta quando siete in pochi e il vostro modo di lavorare è standard. Il primo anno costa quasi sempre meno.
Il su misura conviene quando il vostro processo è diverso da quello che il pacchetto prevede, o quando oggi lavorate tra Excel, email e doppie digitazioni.

Il resto di questo articolo serve a capire in quale dei due casi sei.

Cinque domande da farsi prima di decidere

Quante persone useranno il software e per quanti anni? Più sono, e più a lungo lo usate, più pesa il costo ricorrente.
Il mio processo entra nel pacchetto senza trucchi, o devo adattarmi io? Se serve un foglio Excel accanto al gestionale per fare la parte che il gestionale non fa, la risposta è già un'altra.
Quanto tempo a settimana si perde tra Excel, email e doppie digitazioni? Moltiplicalo per le persone coinvolte: è il costo nascosto del «ci arrangiamo».
Quali sistemi deve collegare? Contabilità, ERP, CRM, e-commerce, banca, corrieri. Un pacchetto collega quello che il produttore ha previsto.
Cosa succede ai dati e al software se smetto di pagare o cambio fornitore? Con un abbonamento, se smetti di pagare smetti di usarlo: controlla le condizioni di esportazione dei dati.

Il confronto, punto per punto

Criterio	Pacchetto in abbonamento	Su misura
Come si lavora	ti adatti tu al programma	il programma segue le tue fasi, documenti e ruoli
Costo iniziale	più basso	più alto: si paga lo sviluppo, meglio se per fasi
Costo nel tempo	canone mensile, di solito per utente	hosting ed eventuale assistenza
Se aumentano le persone	il costo cresce a ogni utente	dipende dal contratto: chiedi se ci sono licenze per utente
Moduli	paghi anche quelli che non usi	solo quelli che servono, aggiunti quando servono
Integrazioni	quelle previste dal produttore	API, database o file verso i sistemi che già usi
Dati e proprietà	legati alla piattaforma	sotto il tuo controllo; codice su repository se previsto

Il confronto è generale: ogni prodotto ha le sue condizioni, quindi controlla quelle del pacchetto che stai valutando.

Una terza strada: tenere il pacchetto e aggiungere il pezzo che manca

Non è una scelta tutto o niente. La contabilità, l'ERP o l'e-commerce che usi oggi possono restare al loro posto: un modulo su misura si collega a loro via API, database o file e copre solo la parte che il pacchetto non copre. Si parte dal processo che oggi ti fa perdere più tempo, lo metti in uso e decidi cosa aggiungere guardando come funziona.

Il conto su 3-5 anni (con un po' di codice)

Il confronto onesto non si fa sul primo anno. Per ogni opzione somma tutto quello che pagherai nell'orizzonte che ti interessa:

def costo_pacchetto(canone_mensile_utente, utenti, anni, extra_a_pagamento=0.0):
    """Canone per utente x utenti x 12 mesi x anni, più moduli/personalizzazioni a pagamento."""
    return canone_mensile_utente * utenti * 12 * anni + extra_a_pagamento


def costo_su_misura(sviluppo, anni, hosting_annuo=0.0, manutenzione_pct=0.0, licenze_terzi_annue=0.0):
    """Sviluppo una tantum più costi ricorrenti. manutenzione_pct è una frazione (0.15 = 15%)."""
    ricorrenti = hosting_annuo + sviluppo * manutenzione_pct + licenze_terzi_annue
    return sviluppo + ricorrenti * anni

Come input usa numeri tuoi o preventivi veri: il canone per utente del pacchetto che stai valutando, il numero di persone, le cifre scritte nei preventivi. Per la manutenzione, le software house che la dichiarano pubblicamente indicano tra il 12% e il 20% annuo del valore sviluppato; molte la rendono facoltativa, quindi chiedilo esplicitamente. Poi confronta costo_pacchetto(...) e costo_su_misura(...) a 3 e a 5 anni, e guarda in quale anno le due curve si incrociano (se si incrociano).

Una regola pratica che ne discende: più sono gli utenti e più a lungo userai il programma, prima il su misura va in pari. Con pochi utenti e un processo standard, il pacchetto resta spesso più conveniente.

Come tenere il costo sotto controllo, se scegli il su misura

Perimetro scritto prima di iniziare: cosa fa il software e cosa resta fuori.
Parti da un modulo, quello che oggi ti costa più tempo.
Paga a fasi, man mano che il software entra in uso.
Chiedi per iscritto cosa è compreso e cosa no: hosting, licenze di terzi, funzioni dopo l'avvio, assistenza.

Quanto costa il su misura

Per le fasce di prezzo pubblicate dal mercato e per le voci che muovono il costo c'è la guida Quanto costa un software gestionale su misura. Il confronto qui sopra è pensato per decidere, non per vendere: se dopo le cinque domande il pacchetto ti basta, prendi il pacchetto.

S-Data è una software house che sviluppa gestionali su misura dal 2007, quindi ha un interesse nella scelta: ho provato a scrivere il confronto in modo che regga anche per chi sceglie l'altra strada.

Cosa pesa davvero sul costo di un gestionale su misura (dati 2026)

S-Data — Tue, 27 Oct 2026 12:56:10 +0000

Chi deve far costruire un gestionale per la propria azienda si scontra quasi sempre con la stessa risposta: «dipende». È vero, ma si può dire qualcosa di più preciso. Ho messo insieme i prezzi che dodici software house e professionisti italiani pubblicano sui loro siti (rilevazione del 22 ottobre 2026) e li ho tenuti separati da qualsiasi stima mia. Qui sotto trovi cosa dicono, cosa non dicono e quali sono le voci che spostano davvero il costo.

Cosa dicono i prezzi pubblicati

Nove delle dodici fonti pubblicano cifre per almeno due fasce di progetto e sono entrate nel calcolo. Mediane dei prezzi dichiarati, IVA esclusa:

Fascia	Mediana dei minimi	Mediana dei massimi
Piccolo progetto o primo modulo	5.000 €	13.500 €
Gestionale con più moduli collegati	15.000 €	22.000 €
Gestionale completo / ERP	37.500 €	40.000 € (molte fonti scrivono «oltre»)

Se si guardano solo le cinque software house che si rivolgono esplicitamente alle PMI (classificazione mia, per come si presentano sui loro siti) le fasce scendono: 3.100–8.000 € per il piccolo, 8.000–20.000 € per il medio, 18.000–40.000 € per il grande. Le agenzie orientate a clienti più grandi pubblicano cifre molto più alte in tutte le fasce.

Tre cose da non dimenticare quando leggi quella tabella

Sono prezzi pubblicati, non preventivi chiusi. Un preventivo reale può essere più alto o più basso.
Il campione è piccolo e non è casuale. Sono le pagine che una ricerca sul web mostra, scritte da chi vende il servizio.
«Piccolo», «medio» e «grande» non significano la stessa cosa per tutti. Alcune cifre sono per modulo, altre per reparto, altre per un verticale. Dove una fonte scrive «oltre X» ho usato X come minimo e nessun massimo, quindi le mediane dei massimi per i progetti grandi si basano su meno fonti.

Un conflitto di interessi va detto: scrivo per una software house che sviluppa gestionali su misura. Per questo le nostre fasce non sono nei dati e non entrano in nessun calcolo.

Cosa muove davvero il costo

Due gestionali che sulla carta sembrano uguali possono costare uno il doppio dell'altro. Nella nostra esperienza la differenza sta quasi sempre in cinque voci, e nessuna è «il numero di schermate»:

Quanti processi copre. Un'attività sola (per esempio i preventivi) oppure più reparti che si passano il lavoro. Ogni processo in più porta regole, schermate e test.
Quanti sistemi deve collegare. Contabilità, ERP, CRM, e-commerce, banca, corrieri. Spesso è la voce che pesa di più, soprattutto se il programma da collegare è vecchio o chiuso, senza API.
Ruoli e permessi. Chi vede cosa, chi modifica, chi approva. Cinque persone con compiti molto diversi possono costare più lavoro di cinquanta che fanno la stessa cosa.
Dati da recuperare. Partire da zero è semplice. Portare anni di anagrafiche e storico da Excel o dal vecchio gestionale richiede pulizia, regole di deduplica e controlli con chi quei dati li conosce.
Regole del lavoro. Listini per cliente, calcoli, scadenze, passaggi di approvazione. È la parte che si vede meno ed è quella che fa la differenza tra un programma generico e uno utile.

Da dove nascono le cifre: le tariffe a giornata

Un preventivo è, in buona parte, giornate di lavoro moltiplicate per una tariffa. Le fonti pubbliche che ho trovato:

Assintel Report 2025, riportato da Buspa (indagine su 346 PMI ICT, dati 2024): programmatore 347 €/giorno, analista circa 420, capoprogetto circa 480, consulente 540.
Zornade: freelance e piccole strutture 250–400 €/giorno; software house strutturate 400–700 €.

A titolo di sola aritmetica: a 347 €/giorno, 5.000 € corrispondono a circa 14 giornate di un programmatore. Non è un preventivo, serve per capire cosa può starci dentro un «piccolo progetto».

La manutenzione: quanto chiedono

Tra le fonti che la indicano, la manutenzione annua è dichiarata tra il 12% e il 20% del valore sviluppato (LEMIO 12–18%, SicDev 15–20%, Sydus 15–20%). Altre fonti non la indicano o parlano di supporto incluso per alcuni mesi.

Come confrontare due preventivi

Prima di confrontare due cifre, confronta cosa c'è dentro:

c'è un perimetro scritto (cosa fa il software e cosa resta fuori)?
si paga a milestone o tutto all'inizio?
hosting, server e licenze di terzi sono nel prezzo o a parte?
l'import dei dati è compreso, e quali dati?
cosa costano le funzioni chieste dopo l'avvio?
la manutenzione è obbligatoria o facoltativa, e in che percentuale?
chi ha il controllo di codice e dati se cambi fornitore?

Il rischio vero non è il prezzo iniziale, ma un progetto che cresce senza controllo. Un perimetro scritto e un primo modulo da mettere in uso subito sono le due difese più semplici.

Dati e fonti

Tabella completa, fonti una per una (con link alle pagine lette), metodo e limiti sono nell'Osservatorio prezzi del gestionale su misura 2026. Il CSV è anche su GitHub, con uno script che ricalcola le mediane: S-Data-IT/osservatorio-prezzi-gestionale-italia. Licenza CC BY 4.0: puoi riusarli citando la fonte.

Se sei una delle aziende citate e una cifra non è corretta, scrivi a info@s-data.it e la correggiamo.