Il problema non è un cliente — sono cento
Un gestionale pensato per un'unica azienda ha, in un certo senso, vita facile: le stesse banche mese dopo mese, gli stessi fornitori, uno stile di documento che diventa familiare in fretta. Il software che uno studio commercialista usa per la propria pratica non ha questo lusso. Ogni cliente porta le proprie banche, i propri fornitori abituali, il proprio modo — più o meno ordinato — di raccogliere scontrini e note spese. Moltiplicato per trenta, cinquanta, duecento clienti, la varietà di documenti che lo studio deve leggere ogni mese non assomiglia più a quella di un'azienda sola: assomiglia a quella di un intero settore compresso in un solo software.
Questa pagina descrive l'API che legge esattamente quella varietà — estratti conto, scontrini, fatture estere, DDT, note spese, di qualunque cliente e qualunque fornitore — restituendo uno schema tipizzato invece di un output OCR grezzo che il tuo team dovrebbe ancora interpretare, documento per documento, cliente per cliente.
In cosa è diverso da un gestionale per una sola azienda
Un gestionale che serve una singola azienda ha un unico piano dei conti, un'unica lista di fornitori abituali, un unico stile di documento da imparare a leggere bene. Un software per la pratica di uno studio è, per struttura, l'esatto opposto: ogni cliente ha il proprio piano dei conti, i propri fornitori, la propria banca — e lo studio deve tenerli tutti separati, corretti e aggiornati contemporaneamente.
Questo cambia cosa serve davvero da uno strato di estrazione. Non basta leggere bene un documento una volta — serve leggerlo bene la centesima volta, per un cliente mai visto prima, con un fornitore mai visto prima, senza che qualcuno nello studio debba prima "insegnare" al sistema come appare quel documento. È esattamente il problema che questa API è pensata per risolvere: nessuna configurazione per cliente, nessun modello da costruire prima di poter servire un nuovo nominativo in portafoglio.
Perché costruirlo in casa si arena, ancora di più qui
Un servizio OCR generico restituisce testo, non campi
Textract, Document AI o un motore OCR generico leggono i pixel — trasformarli in importo, data, causale resta un lavoro di analisi che il tuo team deve scrivere e mantenere da solo, per ogni formato che i clienti dello studio portano.
Le tabelle multi-riga sono la parte difficile, moltiplicata per fornitore
Ricostruire correttamente una tabella di righe su più pagine è già complesso per un fornitore solo. Farlo bene su decine di fornitori diversi, ognuno con la propria impaginazione, è dove la maggior parte dei progetti interni si ferma per mesi.
Ogni nuovo cliente porta nuovi formati mai visti
Un fornitore mai visto prima, una banca mai vista prima: senza un motore che legge dalla struttura del documento invece che da un modello fisso, ogni nuovo cliente acquisito diventa un piccolo progetto di adattamento, non solo un'operazione commerciale.
L'indice di affidabilità è facile da saltare e costoso da saltare, su più clienti insieme
Senza un segnale di affidabilità per campo, o si controlla tutto a mano su ogni cliente (lento, e non scala oltre una manciata di clienti) o ci si fida di tutto (dati sbagliati nel software di più clienti contemporaneamente).
Nessuno di questi punti significa che costruire da soli sia sempre una scelta sbagliata — un software con un parco clienti molto ristretto e competenze OCR già in squadra può farlo funzionare. Ma il costo reale del "costruire" cresce con il numero di clienti serviti, non resta fisso — è di solito un progetto di più trimestri con manutenzione continua, non un weekend passato a collegare un'API.
Cosa questa API non decide
Non legge le fatture elettroniche XML dallo SDI
Quel canale resta quello che il tuo software già usa per ogni cliente — questa API si occupa solo di ciò che arriva fuori dal flusso elettronico obbligatorio.
Non sa a quale cliente appartiene un documento
Restituisce il documento letto e strutturato. Associarlo al cliente giusto resta la logica del tuo software, informata da qualunque identificativo cliente tu già usi internamente.
Non decide la categoria contabile o il piano dei conti
Il piano dei conti cambia da cliente a cliente — assegnare una riga a una categoria resta la logica del tuo prodotto, non una decisione che l'estrazione può prendere al posto tuo.
Dove finisce lo SDI e dove inizia questa API
È una distinzione che vale la pena rendere esplicita, perché confonderla porta a integrare la cosa sbagliata. Lo SDI è un canale di trasmissione obbligatorio per le fatture elettroniche italiane — dati già strutturati, già completi, che il tuo software riceve e legge senza bisogno di estrazione, per ogni cliente allo stesso modo. Questa API si occupa di tutto il resto: documenti che nessuna norma obbliga a strutturare, che arrivano ancora come immagine di una pagina, di qualunque cliente dello studio.
In pratica, per il portafoglio clienti tipico di uno studio commercialista italiano questo significa: estratti conto di ogni banca di ogni cliente, scontrini e ricevute raccolti da titolari e dipendenti, fatture di fornitori esteri che non passano dallo SDI, DDT, note spese e polizze assicurative. Nessuno di questi ha un canale strutturato equivalente allo SDI — restano PDF o scansioni, per ogni singolo cliente, ed è esattamente il punto dove uno studio continua a dipendere da OCR o da inserimento manuale.
Le chiamate che contano
Quattro endpoint coprono l'intero flusso di estrazione. Sono documentati per intero, con ogni parametro, nella pagina della documentazione API — qui sotto la forma che userai davvero dalla pipeline di ingestione del tuo software.
curl -X POST https://flowparse.io/api/v1/extract \
-H "Authorization: Bearer pf_live_xxx" \
-H "Content-Type: application/json" \
-d '{ "file": "JVBERi0xLjcK...", "filename": "estratto-conto-agosto.pdf" }'
# → { "type":"bank_statement", "pages":3, "billedPages":3,
# "price": { "eur":0.10, "perPageEur":0.035, "complexity":"standard" },
# "data": { "type":"bank_statement", "data": { "transactions":[ ... ],
# "opening_balance":4120.50, "closing_balance":5980.15 } } }curl -X POST https://flowparse.io/api/v1/validate \
-H "Authorization: Bearer pf_live_xxx" \
-H "Content-Type: application/json" \
-d '{ "type": "invoice", "data": { "supplier_name": "Fornitore Estero SRL",
"invoice_number": "2026-114", "total": 980.00, "currency": "EUR" } }'
# → { "valid": true, "issues": [] }/validateè gratuito su ogni piano, il posto giusto per prototipare il tuo modello dati prima di spendere qualcosa sull'estrazione vera e propria. /reconcile e /merge estendono lo stesso modello per abbinare fatture a movimenti bancari e per unire più documenti dello stesso cliente in un unico export.
Cosa viene letto
| Tipo di documento | Cosa restituisce |
|---|---|
| Estratto conto | Ogni movimento con data, causale, importo firmato, saldo progressivo |
| Fattura estera (fuori SDI) | Fornitore, numero, date, valuta, righe con quantità e prezzo unitario |
| Scontrino o ricevuta | Esercente, data, totale, IVA quando presente, righe se leggibili |
| DDT e nota spese | Data, riferimenti, righe di dettaglio, totale |
Un documento con una tabella di righe su più pagine viene letto come una tabella unica e continua — le righe non vengono duplicate né perse al cambio di pagina, uno degli errori più comuni in una pipeline di estrazione costruita in casa, ed è tanto più visibile quando lo stesso errore si ripete su decine di clienti diversi invece che su uno solo.
Come funziona su più clienti insieme
Non esiste un'impostazione "modalità multi-cliente" da attivare — funziona così di default, perché l'API non ha alcun concetto di cliente incorporato. Ogni chiamata è indipendente dalle altre: puoi inviare un documento del cliente A e uno del cliente B in parallelo, senza che l'uno influenzi in alcun modo la lettura dell'altro. Sei tu, con il tuo software, ad associare ogni chiamata a un identificativo cliente prima di inviarla e a smistare il risultato al posto giusto quando torna indietro.
Questa separazione è coperta in dettaglio, con un esempio di codice per un flusso batch su più clienti, nella pagina estrazione documenti multi cliente.
Come funziona il prezzo
L'estrazione viene fatturata a una tariffa fissa per pagina — €0,035, la stessa qualunque sia il cliente o la complessità del documento, senza moltiplicatori da stimare. Nessuna licenza per postazione, nessun impegno minimo mensile per iniziare, e soprattutto nessun livello enterprise da negoziare quando il numero di clienti serviti dallo studio cresce.
curl https://flowparse.io/api/v1/usage \
-H "Authorization: Bearer pf_live_xxx"
# → { "plan":"PRO", "pricePerPageEur":0.035,
# "balance": { "pages":812, "monthlyRemaining":712, "bonusPages":100 },
# "thisMonth": { "requests":143, "pages":288, "spendEur":8.18 } }Per un fornitore di software per studi, questo si traduce direttamente nel proprio modello tariffario — il costo di leggere un documento diventa un dato noto e prevedibile da inserire nel proprio prezzo per cliente dello studio, invece di una voce di infrastruttura cloud opaca che cresce in modo imprevedibile con il portafoglio servito.
Come si inserisce nel tuo flusso
Il documento arriva nel tuo software
Caricamento manuale, casella email dedicata per cliente o cartella condivisa — dove il tuo prodotto già riceve i documenti dei clienti.
La tua pipeline chiama /extract
Una sola chiamata POST per documento; JSON strutturato con campi, righe e indice di affidabilità torna indietro.
Associ il risultato al cliente giusto
Con l'identificativo cliente che già usi internamente — l'API non lo conosce, lo aggiungi tu.
Applichi la tua soglia di affidabilità
I documenti ad alta affidabilità proseguono automaticamente; quelli incerti vanno in una coda di revisione, ordinata per cliente o per priorità.
I dati confermati entrano nel software
Direttamente come JSON, oppure esportati via /export come file pronto per la tua importazione, cliente per cliente.
Un esempio: la chiusura di fine mese su venti clienti
Uno studio con venti clienti attivi raccoglie, a fine mese, gli estratti conto di tutti — inoltrati dalla stessa casella email condivisa che già usa per raccogliere i documenti. Ogni file va a /extract, taggato con l'identificativo del cliente corrispondente prima dell'invio. Le venti chiamate corrono in parallelo: la risposta media riporta un'affidabilità di 0,97, sopra la soglia di 0,9 impostata dallo studio per l'inserimento automatico nel libro banca di ciascun cliente.
| Passaggio | Risultato |
|---|---|
| Estrazione, 20 clienti in parallelo | Circa 8 secondi in totale, 60 pagine, €2,10 |
| Controllo saldo per ogni cliente | Saldo iniziale + movimenti = saldo finale, verificato singolarmente |
| Affidabilità media | 0,97 — sopra la soglia di inserimento automatico |
| Documenti in revisione umana | 2 su 20, entrambi scansioni di qualità scarsa |
I due documenti sotto soglia vengono segnalati con il campo specifico incerto evidenziato — non l'intero estratto marcato come sospetto, e non gli altri diciotto clienti coinvolti in alcun modo dal fatto che due dei loro colleghi in portafoglio abbiano avuto un documento più difficile da leggere quel mese.
Costruire in casa contro integrare
| Costruirlo in casa | Integrare questa API |
|---|---|
| Un servizio OCR generico più la tua analisi, la ricostruzione delle righe e l'indice di affidabilità, per ogni formato che i clienti portano | Uno schema tipizzato da una sola chiamata, valido per qualunque cliente |
| Tempo di sviluppo misurato in mesi, più manutenzione continua per ogni nuovo cliente acquisito con formati mai visti | Integrazione operativa tipicamente in un giorno o due |
| Infrastruttura da ospitare, monitorare e scalare da soli man mano che il portafoglio clienti cresce | Nessuna infrastruttura — prezzo a consumo, invariato con il numero di clienti |
| Ogni regressione di precisione è del tuo team, su ogni cliente coinvolto | La qualità dell'estrazione è il prodotto principale di chi la offre |
Nessuno dei due lati di questa tabella è sempre giusto — un fornitore di software con esigenze di estrazione genuinamente particolari e competenze OCR già in squadra può ottenere un sistema più su misura costruendolo. La maggior parte dei fornitori di software per studi commercialisti, soprattutto prima di aver raggiunto il volume che ripaga un sistema proprietario, è meglio servita investendo quel tempo di sviluppo su ciò che differenzia davvero il prodotto — gestione del portafoglio clienti, flussi di lavoro dello studio, scadenzario — piuttosto che sull'OCR.
Precisione e indice di affidabilità
La precisione a livello di campo si attesta intorno al 99% sui layout standard — documenti generati digitalmente da un sistema di fatturazione o di home banking. Un documento scansionato o fotografato può variare di più, ed è esattamente per questo che ogni campo porta il proprio indice di affidabilità invece di un singolo segnale per l'intero documento.
Questa granularità per campo è ciò che permette a una coda di revisione condivisa da più clienti di restare proporzionata al rischio reale — un documento con un solo campo incerto non richiede lo stesso sforzo di revisione di uno dove l'estrazione ha genuinamente faticato ovunque, e un cliente con documenti costantemente puliti non deve mai passare dalla stessa coda di un cliente che fotografa gli scontrini con il telefono in condizioni di luce scarsa.
Formati di export
Oltre al JSON grezzo, lo stesso documento estratto può essere esportato direttamente in xlsx, csv, o file pronti per Xero, QuickBooks, Sage, DATEV, Zoho Books, NetSuite e altri target — 14 in totale.
curl -X POST https://flowparse.io/api/v1/export \
-H "Authorization: Bearer pf_live_xxx" \
-H "Content-Type: application/json" \
-d '{ "format": "xlsx", "type": "bank_statement", "data": { ... } }'
# → { "format":"xlsx", "filename":"estratto-conto.xlsx",
# "encoding":"base64", "content":"UEsDBB..." }Non esiste un formato nativo per il software di un fornitore specifico per studi commercialisti — nessun fornitore lo ha ancora integrato direttamente. Il percorso realistico oggi è JSON o Excel/CSV, che la tua routine di importazione già mappa sul tuo modello dati interno, cliente per cliente, con l'opzione di costruire in futuro un formato di export dedicato una volta che il volume lo giustifica.
I picchi di scadenza, senza dover riprogettare nulla
Uno studio commercialista vive di scadenze concentrate — la chiusura di un trimestre, una scadenza fiscale, il periodo in cui arrivano insieme i documenti di gran parte del portafoglio clienti. Perché ogni chiamata è indipendente e senza stato, l'API non ha bisogno di sapere che sta arrivando un picco: la tua pipeline invia semplicemente più chiamate in parallelo nello stesso intervallo di tempo, e la capacità di elaborazione segue il volume reale invece di essere legata a un livello di infrastruttura fisso deciso in anticipo.
Questo è particolarmente rilevante per uno studio, dove il volume mensile può oscillare sensibilmente da una settimana all'altra senza che nessuno debba prevederlo con settimane di anticipo o dimensionare un server per il caso peggiore.
Errori e limiti
| Codice | Significato |
|---|---|
| 400 | Richiesta malformata o formato non supportato |
| 401 | Chiave API mancante, non valida o revocata |
| 422 | Nessun dato estraibile nel documento fornito |
| 429 | Saldo pagine esaurito — ricarica per continuare |
| 500 | Errore imprevisto nella generazione della risposta |
Non c'è un limite di richieste al secondo da progettare — l'unico limite è il saldo pagine, che si ricarica immediatamente alla conferma del pagamento, così un picco di documenti a fine mese su tutto il portafoglio clienti non richiede una gestione speciale nella tua pipeline di ingestione.
Dal primo test al portafoglio clienti intero
Un fornitore di software per studi che integra questa API per la prima volta di solito inizia con qualche documento di prova di un solo cliente su /extract, conferma che lo schema corrisponde a ciò che la propria logica si aspetta, poi la collega alla pipeline reale una volta calibrata la soglia di affidabilità sul rischio accettabile per i propri clienti — prima con un piccolo gruppo pilota, poi sull'intero portafoglio.
Da lì, il volume cresce senza cambiare nulla nell'integrazione — la stessa chiamata gestisce i documenti di dieci clienti al giorno o di mille, dato che prezzo e capacità sono a consumo invece che legati a un livello di infrastruttura fisso da prevedere in anticipo per un numero di clienti che, in uno studio in crescita, cambia continuamente.
Per chi è pensata
Fornitori di software gestionale per studi commercialisti
Uno strato di estrazione fin dal primo giorno, senza un progetto OCR di più trimestri prima di poter servire il primo studio reale.
Team di sviluppo che valutano costruire o integrare
Un'API concreta su cui prototipare prima di impegnare la roadmap su un sistema proprietario per un portafoglio clienti che continua a crescere.
Piattaforme che migrano da un servizio OCR generico
Uno schema tipizzato per documenti che sostituisce uno strato di analisi costruito a mano sopra un servizio OCR generico, valido per qualunque cliente dello studio.
Software verticali che aggiungono un modulo per la pratica dello studio
Estrazione documenti multi-cliente integrata come funzionalità, senza diventare un team OCR dedicato.
Perché i team smettono di costruirselo da soli
Un primo prototipo di estrazione, testato su una manciata di documenti puliti di un solo cliente, sembra ingannevolmente vicino al finito. È solo quando lo studio porta clienti reali con fornitori mai visti prima, banche mai viste prima e scontrini fotografati male — moltiplicati per decine di nominativi diversi — che la distanza tra "funziona in demo" e "affidabile abbastanza da fidarsi con dati reali su tutto il portafoglio" diventa visibile — di solito dopo che la decisione di costruire è già stata presa e le risorse di sviluppo già impegnate altrove.
Quella manutenzione continua è ciò che, in pratica, è difficile da presidiare dentro un team la cui vera differenziazione dovrebbe essere il flusso di lavoro dello studio — non la ricerca OCR. Trattare l'accuratezza dell'estrazione come il prodotto principale di qualcun altro, migliorato continuamente e indipendentemente dal proprio ciclo di rilascio, è dove la maggior parte dei team arriva dopo aver gestito la versione fatta in casa per un anno o due, con il portafoglio clienti cresciuto nel frattempo.
Ottieni la tua chiave API
Prendi una chiave API gratuita e prova un documento reale di un cliente su /extract prima di impegnarti su qualsiasi cosa — nessuna carta di credito richiesta per vedere la forma della risposta sul tuo documento.
Sicurezza e privacy
Caricamento cifrato con TLS end-to-end.
Elaborazione su infrastruttura con controlli allineati a SOC 2.
Il documento originale viene eliminato subito dopo l'elaborazione.
Nulla di ciò che carichi viene mai usato per addestrare modelli di IA.
L'API non conserva alcun identificativo di cliente o di studio.
Per un fornitore di software che elabora i documenti finanziari di decine di clienti diversi, questo conta tanto per la fiducia degli studi che usano il tuo prodotto quanto per la tua — dettagli completi nella pagina sulla sicurezza.