Documenti e data entry

In molti uffici esiste una persona — spesso più d'una — il cui lavoro quotidiano è guardare un documento e ricopiarne i dati da un'altra parte: fatture nel gestionale, ordini nel magazzino, moduli nel CRM, note spese nel foglio del mese. È il lavoro che oggi si automatizza meglio, ed è quello dove l'errore di ricopiatura costa di più.

Che cosa fa il sistema

Legge il documento in arrivo — PDF, scansione, fotografia, allegato di posta — ed estrae i dati che vi servono in forma strutturata: intestazioni, righe, importi, date, riferimenti. Poi li verifica e li inserisce dove devono andare, nel formato che il vostro sistema si aspetta. Tre proprietà lo distinguono da un OCR tradizionale:

• Tollera i formati che variano. Un modello linguistico non ha bisogno che la fattura di ogni fornitore sia impaginata allo stesso modo: capisce dove sta il dato anche quando il documento cambia disposizione, cosa su cui i sistemi a maschere fisse si rompono di continuo.
• Controlla prima di scrivere. Ogni estrazione passa verifiche di coerenza: i totali devono quadrare con le righe, i codici devono esistere, le date devono essere plausibili. Un dato che non supera i controlli non entra nel gestionale: va a una persona, con il documento originale a fianco.
• Lascia traccia. Per ogni documento resta registrato che cosa è stato letto, che cosa è stato scritto e chi ha approvato i casi dubbi. Se fra sei mesi un dato risulta strano, si risale al documento in un minuto.

I casi tipici

• Ciclo passivo: fatture fornitori e bolle di consegna registrate nel gestionale, con riconciliazione contro gli ordini.
• Ordini in ingresso: ordini che arrivano via email o PDF in formati diversi, trasformati in righe pronte per il sistema di magazzino.
• Moduli e pratiche: richieste di clienti o utenti — iscrizioni, domande, reclami — trasformate da carta o PDF in record lavorabili.
• Note spese e giustificativi: scontrini e ricevute abbinati alle trasferte e caricati con le voci giuste.

Che cosa si presta bene, e che cosa no

Si prestano bene i flussi con volume ricorrente e dati verificabili: se un totale deve quadrare, se un codice deve esistere in anagrafica, il sistema può controllarsi da solo e il tasso di revisione umana scende con le settimane. Si prestano male i documenti dove il dato va interpretato più che letto — un contratto atipico, una perizia, una lettera — e i flussi così piccoli che il progetto non si ripaga: entrambe le cose si dicono in fase di analisi, non dopo.

Domande frequenti

Funziona anche con documenti scansionati o fotografati?

Nella maggior parte dei casi sì: i modelli attuali leggono bene scansioni e fotografie di qualità normale, timbri e annotazioni comprese. La calligrafia corsiva e le scansioni degradate restano il terreno più incerto: si misurano sul vostro campione reale durante il prototipo, non si promettono a scatola chiusa.

Il nostro gestionale non ha API: si può fare lo stesso?

Quasi sempre. Se manca un'interfaccia di integrazione si passa dai tracciati di importazione che il gestionale già accetta, dal suo database dove il fornitore lo consente, o in ultima istanza da un'automazione dell'interfaccia utente. Sono strade con robustezza diversa, e la scelta va fatta a ragion veduta in fase di analisi.

Quanti documenti servono per partire?

Per il prototipo basta un campione rappresentativo: qualche decina di documenti che copra i fornitori o i moduli più frequenti e i casi anomali che vi ricordate. Non serve preparare nulla di speciale — servono i documenti come arrivano davvero, brutti compresi.

Chi si accorge degli errori?

Il sistema per primo: ogni documento estratto passa controlli di coerenza — totali che devono quadrare, partite IVA valide, date plausibili, confronto con lo storico — e ciò che non li supera finisce in una coda di revisione con il documento originale a fianco. L'obiettivo non è l'infallibilità: è che gli errori emergano prima di entrare nel gestionale, invece che a bilancio.