Campi riconosciuti

Quali campi l'IDR riconosce su una fattura PDF: standard, Professional e riferimenti configurabili.

L'IDR (Intelligent Document Recogniser) riconosce automaticamente i dati principali di una fattura PDF e li converte in campi strutturati nell'e-fattura. I campi riconosciuti dipendono dall'abbonamento e dalla configurazione.

Campi riconosciuti in modo standard

Per ogni conversione PDF vengono riconosciuti automaticamente i seguenti campi:

CampoSpiegazioneFornitoreNome, indirizzo, numero di registrazione al registro delle imprese, partita IVA. Il fornitore viene identificato tramite il database delle parti eConnect (Purple Pages), non in base a quanto compare sul PDF.AcquirenteNome e indirizzo come indicati sulla fattura. Inclusi in un'estensione XML, non come identificazione principale.Numero fatturaNumero univoco della fatturaData fatturaData della fatturaData di scadenzaTermine di pagamento (se indicato)ImportiSubtotale, importo IVA e importo totaleAliquota IVAPercentuale e categoria (standard, inversione contabile, esente)IBANConto bancario del fornitoreRiferimento di pagamentoRiferimento strutturato (se presente)ValutaValuta della fattura
Numero fattura riconosciuto in modo errato per formato fornitore

Con alcuni formati fornitore, l’IDR può acquisire un campo diverso dal numero di fattura, ad esempio un ID transazione invece del numero di fattura effettivo. Un esempio noto sono le fatture Meta (Facebook), dove il numero di fattura compare in fondo a una pagina successiva del PDF e l’ID transazione viene riconosciuto in modo più prominente. Altri casi: il numero di registrazione impresa del fornitore, un numero d'ordine/PO o un riferimento bancario/di pagamento (ad esempio un riferimento bancario, l'IBAN o una parte dell'IBAN/numero di conto) al posto del numero di fattura reale, con conseguente numero di fattura errato a valle verso Coda o il sistema ERP. Quest'ultima variante può anche bloccare una nota di credito come duplicato (vedi Fattura duplicata). Si tratta di un errore di selezione del campo nel riconoscimento, distinto dal riconoscimento corretto di un riferimento di pagamento come campo PaymentID separato (vedi Addebito diretto e conto G): lì il riferimento di pagamento non sovrascrive il numero di fattura, qui viene riconosciuto per errore al suo posto.

Questo può essere migliorato per il formato fornitore in questione. Il riconoscimento del numero di fattura non è configurabile dal cliente, ma viene ottimizzato internamente da un membro del team di supporto tramite rilevamento degli outlier, regex e suggerimenti per fornitore o formato. Non è necessario alcun cambiamento nella roadmap; si tratta di un’ottimizzazione mirata della funzionalità esistente. Segnala questo caso all’assistenza — sulla base della segnalazione, il team aggiunge un suggerimento specifico per il fornitore in modo che le future fatture di quel formato ricevano il numero di fattura corretto.

Come funziona il riconoscimento in background (SampleStore)? L'IDR utilizza a tale scopo il SampleStore: un database di pattern di riconoscimento per fornitore. Il processo si svolge in tre fasi: (1) ricerca di numeri corrispondenti a un pattern RegEx nel SampleStore, (2) confronto con esempi precedenti dello stesso fornitore (lunghezza, struttura, trattini, punti, underscore, coerenza), (3) adattamento auto-apprendente basato su nuove fatture. Il supporto integra il SampleStore con esempi e facoltativamente un RegEx dopo una segnalazione.

Numero breve o diverso invece di un pattern con prefisso più lungo. Quando le fatture di un fornitore hanno normalmente un prefisso fisso e una lunghezza fissa, l'IDR a volte riconosce un numero più breve o diverso senza quel prefisso. Se il pattern (prefisso, lunghezza, struttura) è già chiaro dalla segnalazione, il primo passo è adattare direttamente il SampleStore o il RegEx per quel fornitore; un esempio PDF o XML funge quindi da prova, non da primo passo obbligatorio. Se il riconoscimento funzionava correttamente in precedenza ed è tornato ad essere errato nel tempo, si applica lo stesso approccio: verificare e adattare il SampleStore per quel fornitore, il che non indica un difetto del prodotto.

Per l'analisi, il XML della piattaforma dalla posta in arrivo è il file utile: contiene la traccia di riconoscimento IDR. Un XML che esportate voi stessi dal vostro sistema ERP (ad esempio AFAS) una volta che il numero di fattura è già stato corretto manualmente di solito manca di quel blocco IDR e mostra solo il numero già corretto — quel file non è adatto per analizzare l'errore di riconoscimento.

Testo nascosto o trasparente nel PDF (riutilizzo di modello). Alcuni fornitori riutilizzano un vecchio PDF di fattura come modello per nuove fatture. Date o numeri di fattura precedenti possono rimanere come testo residuo invisibile o trasparente nel livello di testo del PDF. L'IDR utilizza OCR ibrido: oltre all'immagine visibile, viene letto anche il livello di testo del PDF. In uno screenshot o sullo schermo si vedono solo le righe visibili, ma il riconoscimento vede il livello di testo completo incluso il testo residuo nascosto. Questo può essere la causa quando un vecchio e un nuovo numero di fattura o data si mescolano nel riconoscimento. Se sospettate questo pattern, richiedete sempre il PDF originale: uno screenshot non è sufficiente perché manca del livello di testo. Poi copiate il testo dal file in un editor di testo semplice per verificare la discrepanza rispetto alla visualizzazione visibile.

Sintomo secondario: fattura contrassegnata erroneamente come duplicato. Una fattura successiva può essere erroneamente contrassegnata come duplicato perché l'IDR riutilizza o abbina un numero di fattura errato (nascosto). Si tratta di una conseguenza dell'errore di riconoscimento sottostante, non di un problema separato: correggete prima il riconoscimento del livello di testo come descritto sopra, anziéché affrontare la rilevazione dei duplicati in modo isolato (vedere Fattura duplicata).

Numero di registrazione impresa/ID parte del fornitore nell'XML differisce dal PDF

Varianti di ricerca: «numero di registrazione impresa diverso nell'XML», «numero di registrazione impresa fattura vs XML», «numero di registrazione impresa mittente diverso», «fornitore numero di registrazione errato in XML», «numero di registrazione impresa fornitore XML diverso dalla fattura», «ID parte mittente XML PDF», «AccountingSupplierParty numero di registrazione impresa».

A volte il numero di registrazione impresa del fornitore (o un altro ID parte, come un numero di partita IVA) nel blocco mittente dell'XML differisce da quanto riportato sul PDF originale, oppure il riconoscimento abbina la fattura al fornitore sbagliato. Si tratta di un errore di riconoscimento di campo sull'identificativo del fornitore, come per importi, valuta o numero di fattura.

Attenzione — non è la stessa cosa di "numero di registrazione impresa letto come numero di fattura". In quell'altro caso (vedi sopra), il numero di registrazione impresa viene riconosciuto per errore nel campo del numero di fattura. Qui si tratta dell'ID parte nel blocco mittente stesso, che non corrisponde al PDF. Sono due problemi di riconoscimento distinti.

Cosa potete fare? Non esiste un'opzione self-service per modificare l'XML. Raccogliete il PDF originale e l'XML associato (scaricabile dal documento nella posta in arrivo) e/o l'ID documento dell'attività di conversione, e segnalatelo al supporto. Su questa base, il team adegua il riconoscimento o la corrispondenza del fornitore. Come per altri errori di riconoscimento, qui non si applica alcuna garanzia di tempo di risoluzione.

Valuta riconosciuta erroneamente sul PDF (IDR)

Varianti di ricerca: «valuta non riconosciuta correttamente», «valuta riconosciuta erroneamente», «valuta errata IDR», «SEK invece di NOK», «currency wrong PDF», «riconoscimento valuta fattura», «PDF valuta errata», «valuta letta erroneamente».

La valuta è un campo riconosciuto in modo standard (vedere la tabella sopra) e rientra negli stessi errori generici di riconoscimento PDF→XML come il numero di fattura o l'importo: l'IDR può riconoscere erroneamente il codice valuta ISO rispetto al PDF (ad esempio SEK invece di NOK). Non si tratta di una funzionalità separata né di un problema autonomo, ma della stessa questione di riconoscimento degli altri campi.

Cosa potete fare? Segnalate la discrepanza al supporto e fornite il PDF originale insieme all'XML associato (dalla posta in arrivo), o l'ID del documento dell'attività di conversione. Su questa base, il team ottimizza il riconoscimento per il formato fornitore in questione. Come con altri errori di riconoscimento, qui non si applica alcuna garanzia di tempo di risoluzione.

Campi Professional

Con l’abbonamento Professional vengono riconosciuti campi aggiuntivi:

CampoSpiegazioneNumero ordine d'acquistoIl riferimento più usato. L'IDR riconosce questo campo automaticamente.Numero contrattoRiferimento del contratto sottostanteNumero progettoRiferimento del progettoBuyer referenceCampo di riferimento del destinatario, configurabile per numero di registro, OIN o partita IVAIBAN conto GRiconoscimento dei numeri di conto G (identificabili dalla serie «099»)Riferimenti di pagamento strutturatiOGM belga, numero KID norvegese, codice QR svizzero
Riconoscimento date per paese

Varianti di ricerca: "data americana", "data fattura americana", "data fornitore USA", "data fattura USA", "data fattura MDY", "MDY invece di DMY", "formato data Stati Uniti", "data fattura non riconosciuta correttamente fornitore americano", "American date format invoice date", "US supplier date format MDY".

L'IDR riconosce le date sulle fatture PDF e le converte nel formato data UBL standard (YYYY-MM-DD). Poiché le notazioni delle date variano per paese, l'IDR determina, in base al paese del fornitore, come interpretare le date ambigue:

  • Stati Uniti: MDY (mese-giorno-anno). La data 03/11 viene interpretata come 11 marzo.
  • Tutti gli altri paesi: DMY (giorno-mese-anno). La data 03/11 viene interpretata come 3 novembre.

Vedi, per un fornitore degli Stati Uniti, una data fattura che ritieni riconosciuta in modo errato? Verifica prima questa regola per paese prima di segnalarla come errore di riconoscimento del campo: per un fornitore americano, 03/11 è ad esempio l'11 marzo, non il 3 novembre. Se la notazione della data non è la spiegazione, si tratta di un'altra questione di riconoscimento (vedi sopra).

Se il rilevamento automatico del paese non basta, si può aggiungere per fornitore un'indicazione specifica sul formato della data tramite il meccanismo di hints.

Tip: date interpretate in modo errato (ad esempio 03/11 come 11 marzo invece di 3 novembre) sono quasi sempre una questione di riconoscimento, non della piattaforma. La piattaforma mostra sempre la data come compare nell'UBL.

Validazione IBAN

Con l'abbonamento Professional, l'IBAN riconosciuto viene confrontato con il verification store: un database di IBAN convalidati manualmente in precedenza per fornitore. Se l'IBAN sulla fattura differisce da quanto verificato in precedenza, viene segnalato. Questo aiuta a individuare fatture fantasma o dati bancari modificati.

Attenzione: secondo la norma europea EN16931, l'IBAN su una fattura serve principalmente a identificare il fornitore, non come istruzione di pagamento. Un IBAN modificato va sempre convalidato prima nei dati anagrafici del proprio sistema finanziario prima di effettuare il pagamento.

Riferimenti configurabili (su misura)

Oltre ai riferimenti standard (numero ordine, numero contratto, numero progetto), altri riferimenti possono essere configurati in modo specifico per fornitore, ad esempio codici di budget, codici del responsabile di budget o riferimenti interni. Si tratta di lavoro su misura impostato su base a strisce.

Il riconoscimento dei riferimenti configurabili utilizza un meccanismo a tre livelli:

  1. Regex: validazione di formato per garantire che il riferimento estratto corrisponda esattamente al formato atteso
  2. Outlier detection: rilevamento statistico delle deviazioni per valori improbabili
  3. Hints: dati di training generati automaticamente in base alle correzioni del team QC

Tip: il numero ordine d'acquisto è il riferimento più usato e la maggior parte dei fornitori lo indica sulla fattura. Se un fornitore non può compilare un certo campo di riferimento nel proprio software, ha poco senso richiederlo. In quel caso usate il numero ordine d'acquisto come riferimento principale.

Nota: numero ordine d'acquisto, numero contratto e numero progetto sono campi standard Professional, ma il riconoscimento si attiva solo dopo una configurazione unica del supporto per cliente/fornitore (basata su almeno 5 fatture di esempio, eventualmente integrata da una regex). Contattate il supporto e fornite preferibilmente una fattura di esempio.

Messaggio: «Order/Contract Reference detection skipped as Sample store is empty»

Ricevete tramite l'API la risposta informativa Order Reference detection skipped as Sample store is empty o Contract Reference detection skipped as Sample store is empty? Non è un errore di elaborazione. L'IDR compila questi riferimenti solo quando il Customer Sample Store del vostro endpoint contiene riferimenti di esempio con cui confrontarsi. Se lo store è vuoto, viene saltato solo quel rilevamento di riferimento; tutti gli altri campi e funzionalità vengono riconosciuti normalmente.

Per risolvere: fornite alcuni numeri ordine o riferimenti contratto di esempio (almeno 3 caratteri per esempio) esattamente come compaiono sulle fatture, in modo che il supporto possa configurarli nel Customer Sample Store. Successivamente si applica prima una corrispondenza per etichetta (ad esempio «Your order number»), con regex come fallback. È disponibile anche un Remote Starter tramite il team vendite per l'impostazione del riconoscimento del numero PO.

Posso migliorare io stesso il riconoscimento del mio numero ordine d'acquisto?

No, non direttamente nella piattaforma. Non gestite voi stessi il Customer Sample Store, le regole di formattazione o la RegEx per il riconoscimento del numero ordine; questo viene impostato dal supporto eConnect.

Indirettamente, tuttavia, potete:

  • far fatturare i fornitori con un formato di riferimento ordine chiaro e uniforme (vedi buona pratica sotto);
  • condividere la conoscenza del formato (prefisso, lunghezza fissa, struttura) con il supporto;
  • fornire, dopo un riconoscimento fallito, il PDF originale o l'ID documento insieme al numero ordine corretto, affinché il supporto possa aggiornare il Sample Store.

Buona pratica per il formato del riferimento ordine sul PDF:

  • indicate il riferimento ordine preferibilmente una sola volta sulla fattura, senza ripeterlo in più punti;
  • usate un'etichetta comune, ad esempio Numero ordine, Numero PO, Numero ordine d'acquisto o Your order number;
  • separate etichetta e numero con uno spazio o un segno di punteggiatura, ad esempio Numero ordine: 420000007 invece di PO420000007;
  • mantenete una struttura fissa e preferibilmente una posizione fissa sulla fattura.

Vedi anche Errori di invio in caso di fattura bloccata o rifiutata per un numero ordine riconosciuto in modo errato.

Più numeri PO su un unico PDF (intestazione vs riga)

Varianti di ricerca: "più numeri PO", "più numeri ordine acquisto una fattura", "più riferimenti ordine PDF", "OrderReference intestazione", "PO su riga fattura", "riconoscimento righe PO", "riconoscimento più numeri PO".

  • Livello intestazione: massimo un numero d'ordine (OrderReference) sull'intestazione della fattura. Più numeri PO su un unico PDF non popolano automaticamente più riferimenti ordine di intestazione.
  • Livello riga come testo: numeri PO aggiuntivi sul PDF possono finire nella descrizione della riga (frammento di testo) tramite il riconoscimento righe — questo non è di per sé un riferimento di riga d'ordine strutturato.
  • Riferimento ordine reale a livello di riga: solo se il destinatario ha una configurazione a livello di riga; non è standard "più PO → più riferimenti ordine".

Non aspettarsi un collegamento automatico tra più numeri PO e più riferimenti ordine di intestazione. Per un layout multi-PO, verificare prima la configurazione Professional e Sample Store per l'unico PO di intestazione; i numeri PO aggiuntivi finiscono come testo di riga, non come riferimento di riga d'ordine separato, a meno che il destinatario non l'abbia configurato autonomamente. Vedi anche Riconoscimento righe per i campi di riferimento per riga.

Obbligo di riferimento e rifiuto (EN16931)

Secondo la norma europea EN16931, un riferimento (buyer reference) è obbligatorio su una fattura elettronica; si tratta spesso di un numero d'ordine o di un altro riferimento del destinatario. Un mittente può inserire un valore errato in questo campo.

eConnect non rifiuta una fattura sul riferimento per impostazione predefinita. Una fattura non soddisfa le regole di base della norma europea solo se non è presente alcun riferimento. Che una fattura venga rifiutata a causa di un riferimento sconosciuto o errato dipende dalla configurazione del destinatario: in una configurazione specifica del destinatario, una fattura può essere rifiutata se il riferimento è sconosciuto. Questo è quindi una proprietà della configurazione ricevente, non dell'elaborazione standard di eConnect.

Suggerimento: se vuoi rifiutare fatture per riferimenti mancanti o sconosciuti, configura questo tramite RBE (Rule Based Enrichment) sull'endpoint ricevente.

Numero fattura mancante: numero sostitutivo (-NOTFOUND)

Il numero fattura (campo UBL cbc:ID, BT-1) è obbligatorio in EN 16931, UBL BIS Billing 3.0 e NLCIUS per le fatture regolari. Tuttavia, l'IDR elabora un flusso di documenti misto: fatture regolari, note di credito, note spese e ricevute. Le ricevute rientrano nel regime di fatturazione semplificata (transazioni fino a circa 100 € IVA inclusa), per cui l'amministrazione fiscale non impone il numero fattura come requisito legale. Il rifiuto per un numero fattura mancante escluderebbe tutte le ricevute e le note spese dall'elaborazione.

Per questo motivo, la pipeline IDR genera automaticamente un numero sostitutivo quando non è possibile estrarre alcun numero fattura dal documento durante il riconoscimento. Il campo cbc:ID (BT-1) viene quindi compilato con la struttura:

YYYYMMDDHHmmss-NOTFOUND

Il timestamp è il momento dell'elaborazione da parte della pipeline IDR, non la data sul documento. Esempio: 20240315143022-NOTFOUND.

Intercettare il numero sostitutivo

Il filtraggio è possibile a due livelli:

  1. RBE (Rule Based Enrichment): configura una regola che verifica se BT-1 (cbc:ID) termina con -NOTFOUND. In base a questo, il documento può essere trattenuto per la revisione manuale, reindirizzato a una casella separata o rifiutato automaticamente.
  2. Sistemi propri (ERP/software contabile): una ricerca diretta di stringhe o un'espressione regolare su -NOTFOUND nel campo cbc:ID è sufficiente.
Righe fattura (riconoscimento righe)

Con il riconoscimento righe vengono riconosciute anche le singole righe della fattura: descrizione, prezzo unitario, quantità, importo riga e campi di riferimento per riga. È una funzione separata che potete attivare voi stessi tramite Il mio ambiente.


Volete sapere come funziona il riconoscimento dal punto di vista tecnico? Leggete Come funziona Scan & Riconoscimento (IDR/OCR)?.

Vedere le attività di conversione