Durante l'invio di una fattura tramite la piattaforma eConnect può capitare di ricevere un messaggio di errore. La maggior parte dei messaggi di errore è legata a dati mancanti o errati nella fattura. Di seguito si trovano i messaggi più comuni, la loro causa e come risolverli.

Questo messaggio di errore generico viene attivato dalla validazione pre-invio nell'interfaccia della piattaforma. La piattaforma verifica prima dell'invio se il valore dell'identificativo (ad es. OINO, numero Camera di Commercio) corrisponde al formato atteso. Se tale verifica fallisce, appare questo messaggio di errore.

Invio tramite AFAS / E-verbinding: alla domanda «posso reinviare da AFAS o E-verbinding?», la risposta è generalmente di reinviare tramite la piattaforma (Posta in uscita > Reinvia), non rigenerare in AFAS -- purché il documento sia già nella posta in uscita. L'errore rosso «Errore sconosciuto durante la chiamata all'evento applicativo» durante il reinvio è quasi sempre la stessa validazione schema/valore descritta sopra, non un guasto AFAS separato. Vedere anche la sezione «Reinviare una fattura con un riferimento corretto» più sotto.

Esempio comune: lo schemeID 0190 (OINO) richiede esattamente 20 cifre. Se il valore contiene un prefisso — ad esempio NL:OINO:00000001001932779000 anziché semplicemente 00000001001932779000 — la validazione fallisce.

Nota: questo errore può verificarsi anche per fatture create tramite API, non solo per le fatture create manualmente.

Soluzione: verificare i valori dell'identificativo e rimuovere eventuali prefissi o caratteri non validi. Il valore deve corrispondere esattamente al formato atteso per lo schemeID (ad es. 20 cifre per OINO, 8 cifre per numero Camera di Commercio).

Regola generale -- inserire solo il valore numerico; la piattaforma aggiunge automaticamente il prefisso schemeID. Questa regola si applica a tutti gli schemi di identificazione, non solo OINO. Se l'utente inserisce anche il prefisso manualmente (ad es. 0088:1234567890123 mentre lo schema è già impostato su GLN/0088), la validazione del formato fallisce. Esempio GLN (schemeID 0088, GS1): selezionare lo schema GLN e inserire solo le cifre GLN nel campo valore -- senza 0088: davanti.

Se un fornitore inserisce un apostrofo prima del numero OIN nell'XML (un artefatto noto di Excel), l'instradamento Peppol fallisce. Il sistema legacy riconosce la fattura e la consegna internamente — il destinatario non vede alcuna fattura nella sua casella creditori, ma riceve un'e-mail di notifica con un link.

Soluzione: chiedere al fornitore di inserire il numero OIN senza apostrofo nell'XML e di verificare le impostazioni di esportazione Excel.

In caso di errori di invio da 4PS, la causa spesso non è immediatamente chiara. Non presupporre a priori che una connessione PSB mancante (Peppol Service Bus) sia la causa.

Procedura:

1. TechSupport stabilisce la causa. Non indirizzare direttamente alle vendite sulla base di un'ipotesi.
2. La causa è una connessione PSB attiva mancante presso eConnect? Il passo successivo è allora le vendite per l'onboarding PSB. Non dare al cliente consigli di configurazione 4PS — senza una connessione PSB non c'è nulla da configurare.
3. La causa è qualcos'altro? Gestirlo tramite il messaggio di errore o la soluzione pertinente in questa pagina (o nelle pagine di integrazione 4PS).

In breve: la diagnosi da parte di TechSupport precede sempre la route commerciale. La route commerciale (onboarding PSB) si applica solo quando TechSupport ha stabilito che una connessione PSB mancante è la causa.

La piattaforma valida ogni fattura sugli standard Peppol e NLCIUS vigenti prima dell'invio. I codici di errore che iniziano con BR (Business Rule) indicano quale regola non è stata rispettata.

La propria organizzazione (il fornitore) non è selezionata correttamente nella fattura. Questo accade quando il campo fornitore è stato modificato manualmente o quando l'organizzazione non è ancora attivata.

Soluzione: cliccare sull'icona matita accanto a "Fornitore" e riselezionare la propria organizzazione. Se l'organizzazione non è ancora attivata, farlo prima tramite Aggiungere e attivare un'organizzazione.

È stato aggiunto un allegato con un tipo MIME non consentito nella validazione Peppol BIS Billing V3 attuale. I tipi di allegato consentiti sono (BT-125):

application/xml non è consentito come tipo MIME allegato nella validazione BIS Billing V3 attuale. XML come allegato appartiene a EN 16931-1:2026 e a una futura versione di Peppol (probabilmente BIS Billing 4.0) — non aggiungere un allegato XML per risolvere BR-CL-24.

Causa frequente (Business Central, Unit4 ERPx e altri ERP): l'ERP incorpora automaticamente gli allegati collegati alla fattura registrata, oppure esporta blocchi UBL incompleti. Un tipo di allegato non supportato (es. un documento Word) causa BR-CL-24; BT-122 mancante porta a BR-52; bonifico senza IBAN a BR-61; tag vuoti a PEPPOL-EN16931-R008. Più codici insieme indicano il payload/export ERP, non un'interruzione dell'ambiente eConnect. È possibile validare in anticipo con il Document Validator.

Soluzione:

1. Verificare quali allegati sono collegati alla fattura nell'ERP (Business Central: Fattura di vendita registrata > Allegati).
2. Rimuovere o sostituire gli allegati con un tipo non consentito -- es. convertire un documento Word in PDF.
3. Inviare nuovamente la fattura.

BR-52 si verifica quando il blocco documento aggiuntivo (BG-24) è presente senza Supporting document reference (BT-122). Succede soprattutto con l'export UBL dell'ERP, ad es. Unit4 ERPx in test o pilot.

Soluzione: indicare un ID (BT-122) per ogni allegato o riferimento documento, oppure omettere il blocco allegato incompleto. La correzione è nell'export UBL dell'ERP, non in eConnect.

BR-61 si verifica quando Payment means type code (BT-81) è un bonifico (es. SEPA o local/non-SEPA credit transfer, codici come 30 o 58) senza Payment account identifier (BT-84, di solito IBAN). Si tratta di EN 16931 BR-61.

Soluzione: inserire IBAN o numero di conto nei dati di pagamento, oppure non inviare un codice bonifico finché non è incluso un numero di conto.

Varianti di ricerca: "BR-CL-16", "Payment means in an invoice MUST be coded using UNCL4461 code list", "PaymentMeansCode vuoto", "UNCL4461", "BT-81 non valido".

BR-CL-16 si verifica quando Payment means type code (BT-81, cbc:PaymentMeansCode in cac:PaymentMeans) è vuoto, contiene testo libero, oppure non compare nell'elenco codici UNCL4461. Il messaggio letterale include: "Payment means in an invoice MUST be coded using UNCL4461 code list".

Soluzione: impostare PaymentMeansCode su un codice UNCL4461 valido, ad es. 30 (bonifico), 49 (addebito diretto), 58 (bonifico SEPA) o 59 (addebito diretto SEPA). È una correzione nell'UBL di origine presso il mittente -- per una fattura ricevuta e inoltrata (InvoiceReceived), PaymentMeans è un passthrough 1:1, quindi il reinvio senza correzione non risolve il problema. Convalidare in anticipo tramite il Document Validator.

PEPPOL-EN16931-R008 si verifica quando l'UBL contiene elementi XML vuoti (tag vuoti).

Soluzione: omettere completamente i campi senza valore nell'export UBL; non inviare tag vuoti. La correzione è nell'export ERP/UBL, non in eConnect.

L'unità di misura inserita per una riga fattura non è riconosciuta come codice UN/ECE valido. Questo accade quando si utilizza un'abbreviazione o una denominazione personalizzata.

Soluzione: utilizzare un'unità di misura standard dalla lista: come "Pezzi" (EA), "Ore" (HUR) o "Giorni" (DAY).

Il tipo di identificativo in "OrganisatieID" differisce dal tipo in "Invia tramite". Ad esempio: l'OrganisatieID è su OIN, ma "Invia tramite" è su Camera di Commercio.

Soluzione: assicurarsi che entrambi i campi utilizzino lo stesso tipo di identificativo. Se si fattura alla pubblica amministrazione, impostare entrambi su OIN/OINO. Se si fattura a un'azienda, utilizzare per entrambi il numero Camera di Commercio (0106).

La Partita IVA del fornitore manca nella fattura.

Soluzione: inserire la propria Partita IVA nelle impostazioni dell'organizzazione.

La sua organizzazione non ha una Partita IVA (ad esempio una fondazione, un ente pubblico o un fornitore sanitario che eroga esclusivamente servizi esenti da IVA)? Non utilizzi il valore fittizio NL000000000B01. Scelga invece la categoria IVA 'O' — fuori dall'ambito di applicazione dell'IVA al momento della compilazione della fattura. Con la categoria 'O', l'obbligo di inserire una Partita IVA viene eliminato e la fattura è conforme allo standard Peppol. Si veda anche IVA inversione contabile e categoria IVA O per una spiegazione dei codici di categoria IVA.

Le fondazioni, alcuni enti pubblici e fornitori sanitari che erogano esclusivamente servizi esenti da IVA non hanno una Partita IVA. Durante la creazione di una fattura sulla piattaforma, appare il requisito di inserire la Partita IVA del fornitore.

Soluzione: selezionare la categoria IVA 'O' — fuori dall'ambito di applicazione dell'IVA (codice UNCL5305 O, "Services outside scope of tax") nel modulo di fatturazione. Con la categoria 'O', il requisito dell'interfaccia per il campo Partita IVA viene eliminato e la fattura può essere inviata senza Partita IVA del fornitore.

Non utilizzare Partite IVA fittizie come NL000000000B01 — non è la soluzione prevista per questo scenario. La categoria 'O' è la scelta corretta per le organizzazioni senza obbligo IVA.

Differenza 'E' e 'O': La categoria IVA 'E' (Exempt from VAT) è destinata alle organizzazioni soggette a IVA che fatturano una transazione specifica esente. La categoria 'E' richiede una Partita IVA. La categoria 'O' è per le organizzazioni senza alcun obbligo IVA.

Non inserire un valore segnaposto nel campo Partita IVA per la categoria O. Valori come nvt, n/d, NA o un trattino non sono una Partita IVA valida e causano comunque un errore di validazione. L'organizzazione non ha strutturalmente una Partita IVA? Selezioni la categoria O e lasci il campo Partita IVA vuoto — non digiti nulla.

Varianti di ricerca: "È richiesto un tipo di IVA su una riga fattura", "I18N_INV.UI.VALUE_MISSING", "menu a tendina IVA vuoto riga fattura", "fattura bozza non si può salvare IVA", "SnelStart XML bozza categoria IVA".

Questo messaggio compare quando la categoria IVA (il menu a tendina IVA) è rimasta vuota su almeno una riga fattura. Il messaggio blocca sia il Salvataggio che l'Invio. Questo accade spesso con un XML consegnato tramite l'Email Ricevitore (ad esempio da SnelStart) che arriva come bozza senza una categoria IVA valida per riga.

Soluzione:

1. Andare su Fatture di vendita → Fatture in bozza e aprire la bozza in questione.
2. Selezionare la categoria IVA corretta nel menu a tendina per ogni riga fattura. Non scegliere un'aliquota per supposizione -- scegliere la categoria corrispondente alla fornitura effettiva.
3. Verificare anche gli altri campi obbligatori: data fattura, Fornitore e Cliente. Se uno di questi campi non è valido, usare l'icona matita per riselezionare la parte dall'elenco a tendina invece di digitare il nome manualmente.
4. Verificare la Partita IVA per codice paese e separatori (ad esempio BE0665904901 per il Belgio), vedere BR-CO-09 più sotto.
5. Salvare e inviare la fattura.

Strutturale nella consegna ERP/XML: un'esportazione incompleta dal software di contabilità o fatturazione porta a un invio automatico (auto-send) inaffidabile. Il fornitore del software deve fornire una categoria IVA valida per riga fattura nell'XML.

Si veda anche "Il campo Fornitore è un menu a tendina, non un campo di testo libero" e BR-CO-09 sopra, e Email Ricevitore per l'auto-send XML (solo con un XML valido).

Per la fatturazione al governo centrale olandese (Basisfactuur Rijk, tramite Digipoort) è obbligatorio un numero IBAN.

Soluzione: inserire il proprio numero IBAN nei dati di pagamento della fattura. È comunque consigliabile includere sempre un IBAN nella fattura, poiché questo diventerà obbligatorio in modo più ampio in futuro.

Questo errore si verifica quando il CompanyID (il campo PartyLegalEntity nell'UBL) contiene una Partita IVA anziché un numero della Camera di Commercio o OIN. La validazione NLCIUS richiede che le parti olandesi utilizzino sempre un numero della Camera di Commercio (schemeID 0106) o OIN (schemeID 0190) come CompanyID. NL-R-003 riguarda il fornitore, NL-R-005 il cliente.

Tecnico: EndpointID e CompanyID sono due campi separati con scopi diversi. L'EndpointID determina l'instradamento tramite Peppol e accetta qualsiasi tipo dalla lista di codici EAS (incluso 9944 per le Partite IVA). Il CompanyID identifica l'entità giuridica e per le parti olandesi deve sempre essere un numero Camera di Commercio (0106) o OIN (0190).

Soluzione: verificare l'UBL generato dal proprio sistema e assicurarsi che il CompanyID contenga un numero della Camera di Commercio o OIN, anche se l'EndpointID è una Partita IVA. Entrambi i campi devono fare riferimento alla stessa organizzazione, ma possono avere tipi di identificativo diversi.

Varianti di ricerca: "OP-T10-R008", "Party Company Identifier Scheme", "schemeID NL:KVK", "schemeID NL:VAT", "codice di lettere schemeID CompanyID", "CompanyID scheme non valido".

OP-T10-R008 (Party Company Identifier Scheme) si verifica quando l'attributo schemeID su un campo Party CompanyID (PartyLegalEntity/CompanyID o PartyIdentification) contiene un codice di lettere storico, come NL:KVK o NL:VAT, invece di un codice PEPPOL numerico. Questo non è consentito: la validazione richiede uno scheme dalla lista ufficiale di identificazione delle parti PEPPOL.

Il codice di lettere NL:KVK viene trattato dal Peppol Service Bus (PSB) come alias di instradamento dello scheme 0106, ma ciò non si applica a questo campo UBL -- sono due contesti diversi.

Soluzione: sostituire il codice di lettere con il codice EAS numerico, ad esempio schemeID="0106" per un numero della Camera di Commercio olandese:

<cbc:CompanyID schemeID="0106">12345678</cbc:CompanyID>

Un campo CompanyID vuoto rientra in un'altra regola -- vedi "NL-R-005 / NL-R-003" sopra. Maggiori informazioni su tipi di identificativo e schemeID: Party identifiers.

Varianti di ricerca: "BR-AE-10", "SOAP:CLIENTBR-AE-10", "Reverse charge shall have a VAT exemption reason", "BT-120", "BT-121", "motivo esenzione inversione contabile mancante", "fatture rifiutate reverse charge".

BR-AE-10 si verifica quando una categoria IVA AE (Reverse Charge) nel dettaglio IVA (BG-23) non contiene un motivo di esenzione: né BT-121 (codice) né BT-120 (testo, ad esempio "Reverse charge" o "IVA inversione contabile"). Si tratta di un errore nell'UBL fornito dall'ERP o dal pacchetto di fatturazione -- eConnect valida la fattura ma non modifica automaticamente i campi AE.

Soluzione:

1. Verificare che ogni riga o supplemento fattura con categoria IVA AE abbia un'aliquota IVA dello 0%.
2. Nell'export UBL del sistema di origine, compilare il campo TaxExemptionReason (BT-120) e/o il codice (BT-121) per ogni dettaglio AE.
3. Validare la fattura in anticipo tramite il Document Validator.
4. Reinviare la fattura corretta -- il reinvio dell'XML originale errato non risolve il problema.

Si veda anche IVA inversione contabile: codici K, AE e G per la spiegazione completa dei codici di inversione contabile IVA.

Queste regole di validazione EN 16931 verificano se il dettaglio IVA e i totali della fattura sono mutuamente coerenti. I valori sono calcolati dal software mittente — non sono campi che si possono correggere nell'interfaccia eConnect.

Varianti di ricerca BR-CO-12 / BR-E-01: "BR-CO-12", "BR-E-01", "ChargeTotalAmount", "BT-108", "totale maggiorazioni non torna", "spese di spedizione non in riga fattura", "Shipping costs AllowanceCharge", "dettaglio Exempt mancante".

BR-CO-12 si verifica quando il totale maggiorazioni a livello fattura non corrisponde alla somma delle singole maggiorazioni documento — ad esempio spese di spedizione incluse come AllowanceCharge documento separato (ChargeIndicator=true, motivo "Shipping costs" / codice FC). Questo è UBL valido; vedere Maggiorazioni e sconti per la struttura. BR-E-01 si verifica quando una riga fattura, maggiorazione o sconto documento con categoria IVA 'Esente IVA' (E) non ha un dettaglio Exempt corrispondente nel riepilogo IVA.

Causa frequente: arrotondare l'IVA per riga anziché per aliquota IVA, o una discrepanza tra importi di riga e sconti a livello fattura.

Soluzione: contattare il fornitore del software mittente per una correzione. eConnect non può rettificare questi valori perché il calcolo è fisso nell'XML fornito.

Varianti di ricerca: «Invalid payload BR-S-08», «Delivery Failed BR-S-08», «il riepilogo IVA non quadra», «riga fattura senza quantità», «quantità riga fattura mancante», «BT-116», «VAT category taxable amount».

Oltre agli errori di arrotondamento, BR-S-08 fallisce anche quando una riga fattura non ha quantità (o ha una quantità vuota) (Invoiced quantity / BT-129). In tal caso l'importo di riga IVA esclusa non è corretto (quantità x prezzo unitario più maggiorazioni di riga meno sconti di riga), per cui la somma delle righe si discosta dal VAT category taxable amount (BT-116) nel riepilogo IVA per Standard rated. Il messaggio di errore letterale spesso assomiglia a: Invalid payload. [BR-S-08]-For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is Standard rated, the VAT category taxable amount (BT-116)....

Differenza con gli errori xs:decimal: nella sezione «'non è un xs:decimal valido'» sopra, il campo importo stesso non è un numero decimale valido (vuoto o notazione scientifica). Con BR-S-08 il campo importo è un numero valido, ma il calcolo tra gli importi di riga e il riepilogo IVA non quadra.

Checklist di primo livello (prima di escalare al fornitore software):

1. Verificare che tutte le righe fattura abbiano quantità e importo di riga IVA esclusa compilati.
2. Importo di riga = quantità x prezzo unitario (più maggiorazioni di riga, meno sconti di riga); nessun campo importo vuoto.
3. Far ricalcolare i totali IVA nel sistema di origine.
4. Inviare una fattura corretta tramite Peppol. Reinviare lo stesso documento senza correzione non risolve BR-S-08 -- Reinviare nella Posta in uscita non modifica importi di riga o IVA (stesso ambito di reinvio di R120 sopra).
5. L'errore continua a presentarsi con quantità complete? Allora si tratta di un errore di arrotondamento o di un altro errore di calcolo nell'ERP o nell'esportazione UBL -- inoltrare al fornitore software.

Categoria IVA E vs. O: l'organizzazione non ha Partita IVA (fondazione, ente pubblico, sanità)? Utilizzare la categoria O (fuori dall'ambito di applicazione) — vedere la sezione «Organizzazioni esenti da IVA: categoria O» sopra. La categoria E richiede sempre una Partita IVA.

Varianti di ricerca: «Processing is not possible», «We were unable to process the UBL invoice in the attachment», «BR-CO-18», «BR-Z-01», «BR-Z-05», «Zero rated», «aliquota zero UBL», «riepilogo IVA BG-23 mancante», «XML + PDF inviati insieme», «UBL rifiutato PDF comunque elaborato», «sopprimere messaggio di errore XML», «ditch the XML».

Zero rated (Z, IVA 0%) non è sinonimo di esente (categoria E) o di inversione contabile IVA (categoria AE) -- righe, aliquote e totali IVA devono essere reciprocamente coerenti:

• BR-CO-18: per ogni combinazione di categoria IVA, aliquota, motivo di esenzione e codice articolo utilizzata, la fattura deve avere almeno un riepilogo IVA (BG-23). Mancante o incompleto -- rifiuto.
• BR-Z-01: se la categoria Z è usata su una riga fattura, maggiorazione o sconto documento, il riepilogo IVA deve contenere almeno una riga con categoria Z («almeno una», non «esattamente una»).
• BR-Z-05: se la categoria IVA è Z, l'aliquota IVA deve essere 0.

Combinazione XML + PDF in una stessa e-mail (dual-path): se arriva un'e-mail con sia un allegato XML che PDF, e l'XML viene rifiutato su una di queste regole, l'e-mail della piattaforma può mostrare «Processing is not possible» o «We were unable to process the UBL invoice in the attachment» -- mentre il PDF è stato elaborato e si trova nella Posta in arrivo. Non è un doppio fallimento: i due allegati vengono valutati separatamente, e il messaggio di errore relativo all'XML non può essere soppresso finché sono presenti altri allegati elaborati con successo.

Tutti questi errori si trovano nell'UBL inviato dal mittente o dal suo software. eConnect non modifica i campi IVA nell'XML inviato; reinviare lo stesso XML errato non risolve nulla -- è necessaria una nuova fattura corretta. È possibile validare in anticipo tramite il Document Validator.

Soluzione (scegliere una di queste vie strutturali):

1. Correggere l'UBL alla fonte: il fornitore o il software completa il riepilogo IVA (categoria Z con riepilogo corrispondente, aliquota 0, righe e totali coerenti).
2. Omettere l'XML: inviare solo il PDF, senza l'allegato XML nella stessa e-mail (adatto solo al percorso di invio via e-mail, non un sostituto per un invio Peppol).
3. Email Receiver solo PDF: il supporto può configurare l'Email Receiver del cliente per accettare solo fatture digitali (PDF), così l'XML non viene più validato.

Se la fattura passa via Peppol o UBL nativo, l'opzione 1 è l'unica soluzione strutturale -- un PDF non è li un sostituto per un UBL valido.

Varianti di ricerca: «Errore Peppol», «stato di consegna», «stato di consegna nel proprio software», «arrotondamento nel tempo», «due decimali software di origine», «importi esclusa IVA non corretti», «nuovo batch stesso errore».

Triage con più possibili cause («Errore Peppol» / stato di consegna ERP): lo stesso ticket puo contenere sia un errore di calcolo R120 sia un errore di schema EndpointID. Procedere in questo ordine:

1. Verificare prima il codice o il testo di errore letterale nella Posta in uscita eConnect (platform.econnect.eu) -- non solo lo stato nell'ERP o nel pacchetto contabile del cliente (ad esempio «consegna» o «errore»). Lo stato ERP non e uguale allo stato della piattaforma eConnect.
2. L'errore indica «sum invoice line», arrotondamento o due decimali nel pacchetto di origine? Allora si tratta di questo calcolo di riga R120 -- la correzione spetta al software mittente.
3. Si tratta di un EndpointID non valido con schema 0190 (OIN olandese) per un debitore belga? Utilizzare allora lo schema 0208 (numero di impresa belga, 10 cifre senza punti) o lo schema con cui il destinatario e effettivamente registrato su Peppol -- vedere la sezione sul numero di impresa belga piu sotto.
4. Un nuovo batch fallisce di nuovo? Cio accade solo se la stessa causa sottostante (calcolo R120 e/o schema EndpointID) e ancora presente nell'XML -- non per l'etichetta di tipo del batch in se.

Questo errore viene segnalato anche come errore «sum invoice line». R120 è una regola di calcolo che verifica se LineExtensionAmount = (Quantity × PriceAmount ÷ BaseQuantity) + maggiorazioni − sconti. R120 non vieta esplicitamente gli importi negativi; la validazione fallisce quando il calcolo non è bilanciato. Ciò si verifica frequentemente quando uno sconto a livello riga (AllowanceCharge a livello riga) supera il prezzo dell'articolo, ad esempio in una nota di credito con uno sconto elevato.

La correzione spetta al software di invio (il programma in cui è stata creata la fattura), non a eConnect: eConnect non modifica gli importi nell'XML inviato.

Soluzione: utilizzare l'importo netto dell'accredito direttamente come PriceAmount e omettere l'elemento AllowanceCharge sulla riga. Per dettagli e un esempio XML, consultare l'articolo su maggiorazioni e sconti. Richiedere il file XML della fattura è necessario solo come approfondimento per schemi insoliti, non come primo passo.

Il reinvio non risolve R120. Reinviare nella posta in uscita corregge i campi di instradamento e di riferimento (come EndpointID o numero d'ordine) — non gli importi di riga o gli sconti di riga. Per R120, riprovare con lo stesso documento non ha senso: correggere il calcolo nel software di invio o creare un nuovo documento.

Fattura creata direttamente nella piattaforma (nessun XML ERP esterno)? Creare una nuova fattura di vendita — il documento nella posta in uscita è di sola lettura e non può essere eliminato. Assicurarsi che quantità × prezzo unitario corrisponda all'importo di riga per ogni riga, senza sconto di riga separato che superi il prezzo dell'articolo; inserire il prezzo netto direttamente se necessario. Riselezionare il destinatario e inviare tramite Peppol. Il documento non riuscito può rimanere nella posta in uscita; contrassegnarlo come duplicato non è un problema.

Fattura di correzione da AFAS (tramite eVerbinding) non ricevuta. Quando una fattura di correzione inviata tramite AFAS e eVerbinding attiva R120, il testo dell'errore potrebbe non nominare R120 direttamente: lo stato mostra quindi «consegna non riuscita» o «document format not supported by receiver», spesso dopo una trasformazione NLCIUS-Peppol BIS fallita. Si tratta di una conseguenza dell'errore di validazione del contenuto, non di una prova che il destinatario non sia raggiungibile o rifiuti la fattura.

Ordine di diagnosi: prima i log, XML solo per approfondimento.

1. Aprire prima i log del mittente o lo stato della posta in uscita del documento e cercare il codice letterale R120, il testo «Invoice line net amount MUST equal» o un errore di trasformazione NLCIUS-BIS segnalato.
2. Solo se ciò non chiarisce il problema: aprire la fattura nella posta in uscita e utilizzare il menu a discesa Scarica XML per visualizzare l'XML inviato. Richiedere il file XML al cliente è un passo di approfondimento facoltativo, non la prima azione quando i log mostrano già l'errore.

eConnect non converte quantità o prezzi. Per una riga di credito o correzione corretta, si prevede una quantità negativa e un prezzo unitario positivo (il totale è quindi negativo). eConnect non cambia il segno delle quantità o dei prezzi da negativo a positivo o viceversa — R120 fallisce sul calcolo nell'XML inviato dal sistema di origine (ad esempio AFAS). Il fatto che l'interfaccia della piattaforma mostri solo un PDF senza vista XML separata non indica che eConnect riscriva gli importi.

Anche senza sconto di riga (puro disallineamento quantità × prezzo). R120 fallisce anche quando non c'è AllowanceCharge sulla riga, ma Quantity × (PriceAmount / BaseQuantity) non corrisponde a LineExtensionAmount. Questo indica tipicamente un errore decimale o di fattore 100 nel prezzo o nell'importo di riga nell'XML di origine, ad esempio 200 × 5,14 = 1028,00 invece di 10,28. In questo caso, verificare manualmente i campi XML -- non solo i totali mostrati nell'interfaccia.

I totali a schermo sono corretti, ma R120 fallisce comunque. Un cliente potrebbe indicare che gli importi nella schermata di bozza sono corretti; ciò non esclude R120. R120 verifica i campi nell'XML (Quantity, PriceAmount, BaseQuantity, LineExtensionAmount, AllowanceCharge), non quanto mostrato a schermo. Se una fattura in bozza o l'XML di origine fornito continua a fallire su R120, correggere nel sistema di origine e inviare un documento nuovo o corretto. Modificare manualmente l'OrganisationID o l'unità non risolve R120 -- si tratta di altre regole di validazione.

Questi tre codici di errore compaiono quando la fattura è stata tecnicamente inviata, ma il destinatario o il validatore respinge il contenuto su campi base nell'UBL/XML. La causa risiede nel file XML stesso, non nella connessione Peppol, nell'ID Peppol o nel metodo di consegna al cliente.

Soluzione: correggere i campi interessati nel software in cui viene generata la fattura -- CustomizationID e ProfileID sono valori fissi per tipo di documento, non un'impostazione nella piattaforma eConnect. Se mancano sia BuyerReference che OrderReference, aggiungere uno dei due prima di reinviare la fattura.

Attenzione con R007 e altri profili BIS: il valore predefinito nella tabella si applica a una fattura/nota di credito standard. Il self-billing e altri profili Peppol BIS (ad es. self-billing invoicing) hanno un ProfileID proprio, diverso. Non forzare il valore predefinito su fatture che utilizzano deliberatamente un altro profilo BIS -- verificare prima quale profilo si applica prima di usare questa FAQ.

Da non confondere con: una registrazione Peppol mancante presso il destinatario, un EndpointID errato, un guasto dell'Access Point, o il messaggio «nessuna regola di validazione disponibile» (vedere la sezione corrispondente più avanti) -- questi casi presentano sintomi diversi da questa combinazione di specifica, profilo e riferimento.

Varianti di ricerca: "P0112", "invoice type code 326 or 384 is only allowed when both buyer and seller are German organisations", "codice tipo 326", "partial invoice", "dove cambiare il tipo di fattura", "modificare il codice tipo fattura nel portale", "non vedo un campo tipo fattura", "384 fatture di vendita francesi", "debito e credito sulla stessa fattura Francia", "fattura correttiva non in Francia", "entrambe le parti non stabilite in Francia", "entrambe le parti non nel paese X", "InvoiceTypeCode 384 FR", "P0112 Francia", "mixed debit credit BIS 3.0", "suddividere 380 381".

Questo messaggio di errore si verifica quando cbc:InvoiceTypeCode (BT-3) ha il valore 326 (partial invoice) o 384 (corrected invoice/fattura correttiva), mentre non sono entrambi -- fornitore e destinatario -- organizzazioni tedesche. La regola Peppol BIS Billing 3.0 PEPPOL-EN16931-P0112 consente 326 e 384 solo quando entrambe le parti sono tedesche.

Nessuna regola specifica per la FR: un testo di errore o un'interpretazione personale su "entrambe le parti non stabilite in Francia" o "non nel paese X" è una parafrasi errata. P0112 verifica esclusivamente la Germania (fornitore e destinatario), non il paese della fattura né il luogo di stabilimento delle parti francesi. Un'entità francese in uscita con codice tipo 384 su BIS Billing 3.0 incontra la stessa restrizione DE→DE -- non esiste un percorso separato "fattura correttiva FR".

Interfaccia del portale: il selettore del tipo di fattura si trova a destra nella bozza di fattura. Le etichette visibili al cliente includono fattura parziale (accanto ai termini standard "fattura correttiva" e "fattura commerciale") -- facile da non notare.

Soluzione (portale, fattura IT o non-DE, incl. FR/BIS 3.0):

1. Andare a Fattura di vendita → crea fattura.
2. A destra della bozza: verificare il tipo di fattura -- prestare attenzione all'etichetta fattura parziale.
3. Scegliere Fattura commerciale (codice tipo 380) invece di Fattura correttiva, a meno che non si tratti di una correzione effettiva e sia il mittente sia il destinatario siano tedeschi.
4. Per una correzione verso un destinatario non tedesco: utilizzare una nota di credito o un 380 negativo più una nuova fattura -- vedere Varianti nota di credito. Non utilizzare il codice tipo 326/384 al di fuori di DE→DE.
5. Per una correzione con sia righe di debito che di credito sulla stessa fattura al di fuori di DE→DE: dividere in due documenti -- 380 (debito) e 381 (credito) -- oppure usare un'unica 380 con le righe di credito come quantità negativa e prezzo positivo.

Fonte: Peppol BIS Billing 3.0 -- PEPPOL-EN16931-P0112.

Questo errore si verifica su riga/righe fattura con categoria IVA Cessione intracomunitaria / Intra-community supply (K, BT-151) quando manca un dato IVA obbligatorio. Per la categoria K sono obbligatori: la partita IVA del fornitore (seller VAT, BT-31) o quella del rappresentante fiscale (seller tax representative VAT, BT-63), e la partita IVA dell'acquirente (buyer VAT, BT-48). I dati mancanti si trovano nei dati anagrafici (organizzazione o cliente), non sulla riga fattura stessa. L'errore non indica un numero di riga specifico -- la regola si attiva non appena una delle righe fattura usa la categoria K.

Soluzione:

1. Determinare quale/i riga/righe fattura usano la categoria IVA K (cessione intracomunitaria).
2. Inserire la partita IVA del fornitore (seller VAT) nelle impostazioni dell'organizzazione, oppure inserire il rappresentante fiscale (seller tax representative VAT).
3. Inserire la partita IVA del cliente (buyer VAT) nei dati del debitore.
4. Inviare nuovamente la fattura. Il documento nella posta in uscita è di sola lettura -- in caso di errore è necessario creare una nuova fattura di vendita.

Gli ID Peppol belgi possono avere due forme:

Formato Partita IVA: BE seguito da esattamente 10 cifre (aggiungere zeri iniziali se necessario). Verificare la Partita IVA tramite lo strumento di validazione VIES della Commissione europea (ec.europa.eu/taxation_customs/vies).

L'opzione Peppol non appare per il debitore belga? Verificare con quale tipo di identificativo il debitore è registrato su Peppol. Alcune organizzazioni belghe sono registrate solo tramite 0208: (KBO) e non tramite 9925: (IVA). In tal caso provare il numero KBO: la Partita IVA senza BE davanti (ad es. per BE0123456789 il numero d'impresa è 0123456789; per BE1xxxxxxxxx è 1xxxxxxxxx -- entrambi i prefissi sono validi).

AFAS: il numero d'impresa con punti fallisce in Peppol BIS V3. Quando AFAS invia inizialmente una fattura SI2.0, non viene effettuata alcuna validazione sul numero d'impresa belga -- i formati con punti (ad es. 0809.948.614) sono accettati. Passando a Peppol BIS V3, l'errore di formato emerge perché BIS V3 valida il numero d'impresa. Soluzione: il cliente aggiorna i dati anagrafici in AFAS e rimuove i punti dal numero d'impresa. Il formato corretto è esattamente 10 cifre che iniziano con 0 o 1, senza separatori.

Fattura verso il Belgio non inviata/non arrivata: numero BE:EN a 9 cifre (zero iniziale mancante). Quando una fattura verso un destinatario belga (EndpointID, schemeID 0208) non viene inviata, o il cliente segnala che non è arrivata tramite Peppol, una causa frequente è un numero d'impresa a 9 cifre invece di 10: lo 0 iniziale è stato omesso o troncato. Il numero d'impresa belga (BE:EN, schemeID 0208) ha sempre esattamente 10 cifre, che iniziano con 0 o 1, senza punti o separatori. Soluzione: aprire l'UBL/XML del documento e controllare AccountingCustomerParty > EndpointID con schemeID="0208"; se il valore non ha 10 cifre, correggere i dati anagrafici nell'ERP (aggiungere lo zero iniziale) e inviare nuovamente il documento come documento nuovo o corretto -- Rinvia nella Posta in uscita non corregge i valori degli elementi nell'XML stesso. Lo stesso controllo di lunghezza si applica quando l'EndpointID del fornitore usa 0208 nell'XML.

Altro: le righe con prezzo negativo non sono consentite nelle fatture belghe; utilizzare una quantità negativa con un prezzo positivo.

I codici errore BR-DE-* sono regole di validazione tedesche specifiche per XRechnung.

Leitweg-ID mancante (EAS 0204): comune nelle fatture alla pubblica amministrazione tedesca. Richiedere il Leitweg-ID all'ente committente e aggiungerlo come identificativo con schemeID 0204.

PDF non accettato: dal 1° gennaio 2025, la Germania ha introdotto l'obbligo di ricevere le fatture elettroniche. Un semplice PDF spesso non è più sufficiente. Inviare la fattura come XRechnung o ZUGFeRD.

Rifiuto KSeF: spesso causato da un formato XML FA_VAT non valido. Il PSB eConnect gestisce normalmente la trasformazione corretta nel formato polacco KSeF.

Errori di certificato: possono verificarsi se i certificati KSeF non sono installati correttamente o sono scaduti.

Rate limiting: KSeF applica limiti al numero di richieste. eConnect utilizza l'elaborazione in batch per evitarlo.

UWV applica proprie regole di validazione in aggiunta alla validazione Peppol/NLCIUS standard.

• UWV Grande Flusso di Denaro (reinserimento lavorativo, formazione, sussidi): OIN 00000004191771249000
• UWV Piccolo Flusso di Denaro (gestione): OIN 00000004172892677000

Soluzione per codice UWV: compilare il campo mancante nella fattura. La serie UWV001 riguarda i campi fornitore obbligatori; la serie UWV002 gli elementi di identificazione.

Varianti di ricerca: "fattura ERPx non in posta in uscita", "stato di elaborazione consegna eConnect", "consultare registro Unit4 eConnect", "fattura da ERPx non visibile eConnect", "ERPx inviato nulla in eConnect", "registri eConnect numero fattura ERPx", "Unit4 ERPx stato di elaborazione consegna", "fattura elettronica ERPx non arrivata eConnect".

Una fattura elettronica creata in Unit4 ERPx non arriva nella Posta in uscita di eConnect, mentre l'anagrafica del debitore in ERPx sembra corretta (metodo di invio fatturazione elettronica, formato Peppol, OIN/schema compilati). ERPx a volte mostra per la fattura lo stato di elaborazione "in elaborazione".

Ordine di prima linea:

1. Richiedere il numero fattura (oltre alla data fattura, l'organizzazione/amministrazione eConnect e un eventuale codice di errore o timestamp ERPx). Senza numero fattura non è possibile una ricerca affidabile nel registro o nella Posta in uscita.
2. Cercare il numero fattura nella Posta in uscita (e nelle bozze) e nei registri eConnect.
   • Non trovato nella Posta in uscita e non nei registri eConnect: il documento non è arrivato a eConnect. Rimandare il cliente al consulente ERPx/Unit4 -- la causa risiede allora sul lato invio o connettore di ERPx, non su eConnect.
   • Trovato: seguire il consueto percorso di stato della Posta in uscita su questa pagina (consegna non riuscita, bozza, duplicato o elaborato con successo).
3. Con un'anagrafica debitore completamente compilata ma senza prova di arrivo, non presumere immediatamente un problema di raggiungibilità Peppol o dell'EndpointID del debitore. Ciò che conta è la prova di arrivo a eConnect (numero fattura rintracciabile nella Posta in uscita o nel registro), non lo stato dell'anagrafica debitore.

Il significato esatto dello stato ERPx "in elaborazione" rispetto all'arrivo a eConnect non è stabilito come fatto di prodotto -- usare questo stato solo come segnale del cliente, non come prova che la fattura sia già arrivata a eConnect.

No. eConnect è l'Access Point Peppol: si occupa del trasporto della fattura sulla rete Peppol (vedi Cos'è Peppol?). eConnect non è un software di contabilità o di fatturazione.

Regola pratica per il confine dell'ambito: un errore che si verifica prima che la fattura arrivi a eConnect -- ad esempio una validazione di campo su Città, CAP o altri dati dell'anagrafica cliente nel software con cui viene creata la fattura -- non rientra nella responsabilità di eConnect.

• Verificate prima voi stessi che i campi interessati (Località, CAP, ecc.) siano compilati correttamente nell'anagrafica cliente del destinatario, nel vostro software di fatturazione/contabilità.
• Se il messaggio persiste, contattate il fornitore di quel software di fatturazione/contabilità.
• Vedi anche "Identificativo del fornitore obbligatorio" o la sezione sui numeri d'ordine sconosciuti più avanti (nota "campo specifico ERP"): eConnect può indicare un codice di errore, ma non gestisce direttamente il pacchetto ERP/contabile del cliente.

Questo messaggio appare nella Posta in uscita quando la fattura non ha potuto essere consegnata al destinatario tramite la rete Peppol. Possibili cause:

• Destinatario non registrato su Peppol: il destinatario non ha una registrazione Peppol attiva. La piattaforma offre automaticamente il fallback e-mail in questo caso.
• EndpointID errato: l'indirizzo Peppol del destinatario non è corretto. Verificare il numero della Camera di Commercio o il numero OIN inserito come debitore.
• La parte ricevente ha un problema tecnico: la fattura è stata inviata correttamente ma non ha potuto essere elaborata dal sistema del destinatario. Questo esula dal proprio controllo: contattare il destinatario.

In caso di consegna fallita è possibile reinviare la fattura e correggere l'EndpointID.

not available durante l’invio (test) a un destinatario significa: il destinatario non è attivo su Peppol per ricevere documenti sull’identificativo utilizzato. Non si tratta di un problema lato mittente.

• Il routing Peppol avviene tramite l’EndpointID del destinatario (numero di registro delle imprese / OIN), non tramite il numero di partita IVA del mittente. Un numero di partita IVA valido non rende di per sé un’organizzazione rintracciabile o raggiungibile -- è necessaria la registrazione su Peppol (vedere Qual è il mio Peppol ID? e Registrarsi su Peppol).
• In caso di not available, la piattaforma offre automaticamente il fallback via e-mail, in modo che il documento possa comunque essere consegnato al destinatario via e-mail.
• Nota lato mittente: l’invio tramite Peppol funziona automaticamente non appena la propria organizzazione è attivata. L’attivazione per la produzione è un requisito KYC; i test sono possibili tramite il programma pilota (vedere Registrarsi su Peppol).

Il campo fornitore non contiene dati. Questo accade quando l'organizzazione non è selezionata o quando non è attivata.

Soluzione: cliccare sull'icona matita accanto al campo fornitore e selezionare la propria organizzazione. L'organizzazione non è ancora attivata? Seguire prima i passaggi in Aggiungere e attivare un'organizzazione.

Il campo fornitore accetta solo un'organizzazione selezionata dal menu a tendina. Se si digita del testo in questo campo -- ad esempio il proprio nome aziendale -- invece di selezionare l'organizzazione, la sezione Fornitore della fattura non viene costruita correttamente. Il campo appare compilato, ma la fattura viene rifiutata all'invio. Questo errore appare spesso sotto un altro messaggio, come "Partita IVA mancante" o "Identificativo del fornitore obbligatorio".

Soluzione: rimuovere il testo digitato dal campo fornitore, fare clic sul campo e selezionare la propria organizzazione dal menu a tendina. Rinviare quindi la fattura.

Questa è la stessa procedura di correzione prevista per "Il campo Fornitore è vuoto" e BR-NL-1: selezionare la propria organizzazione tramite il menu a tendina. La differenza è che qui il campo appare compilato a prima vista, poiché contiene effettivamente del testo -- ma non una selezione valida.

La regola di validazione BR-CO-09 verifica se la Partita IVA ha un formato valido. La Partita IVA deve sempre essere inserita con il codice paese e senza punti, spazi o separatori.

I codici paese seguono lo standard ISO 3166-1 alpha-2. Le Partite IVA sono obbligatorie quando il fornitore o il destinatario è soggetto passivo IVA e l'aliquota non è esente.

Se l'importo inserito scompare quando si passa al passaggio successivo, il campo probabilmente contiene caratteri non ammessi. Il campo importo accetta solo cifre con la virgola come separatore decimale. Inserire gli importi come 100,00, non come € 100,00 o 100.00.

Varianti di ricerca: "icona di stop rossa invio", "cerchio rosso invio", "la fattura non può essere inviata", "l'invio fallisce", "icona stop fattura", "nota fattura obbligatoria", "IBAN conto bancario obbligatorio", "maggiori info nota fattura", "dati di pagamento IBAN vuoto", "campi obbligatori invio fattura".

Durante l'invio di una fattura di vendita manuale può comparire un'icona di stop rossa: la fattura non viene inviata. La causa è la validazione del modulo lato client -- non un errore Peppol o di rete, e non un difetto della piattaforma. Debitore/OIN, raggiungibilità Peppol e numero d'ordine possono già essere corretti mentre l'invio continua a fallire perché un altro campo obbligatorio è rimasto vuoto.

Controllare questi due campi:

1. Nota fattura (sezione Maggiori info) -- inserire una breve nota o riferimento, ad esempio il numero d'ordine o il riferimento concordato con il cliente.
2. IBAN conto bancario (sezione Dati di pagamento) -- inserire l'IBAN su cui viene ricevuto il pagamento, tramite Modifica se necessario. L'IBAN a livello di organizzazione è facoltativo, ma un IBAN vuoto sulla fattura stessa può comunque bloccare l'invio.

Distinzione da altri blocchi:

• Il pulsante di invio non risponde o mostra segnaposto: vedere "Il pulsante di invio Peppol non risponde" più sotto (traduzione automatica del browser).
• La fattura resta nelle bozze: vedere la sezione corrispondente (impostazione dell'organizzazione o "Invia tramite" mancante).

L'invio continua a fallire dopo aver compilato entrambi i campi? Richiedere uno screenshot del messaggio di errore esatto, non solo dell'icona di stop.

Varianti di ricerca: "numero di conto bancario non formattato correttamente", "conto bancario non formattato correttamente", "IBAN non formattato correttamente", "errore formato IBAN", "spazi IBAN", "formattazione IBAN dati di pagamento", "errore IBAN invio fattura manuale".

Durante l'invio di una fattura di vendita manuale può comparire il messaggio che il numero di conto bancario o l'IBAN non è formattato correttamente, anche se il numero è corretto nella sostanza. La causa è una validazione del formato pre-invio su IBAN o conto bancario nella sezione Dati di pagamento -- non un errore Peppol o di rete. Spazi, trattini o altri separatori (o un codice paese mancante) fanno fallire il controllo.

Soluzione:

1. Aprire la fattura e andare su Dati di pagamento (IBAN o conto bancario).
2. Inserire l'IBAN completo come stringa continua: codice paese seguito da cifre/lettere, senza spazi, trattini o altri separatori (forma: NL00BANK0123456789).
3. Non utilizzare un vecchio numero di conto senza codice paese -- i conti olandesi iniziano con NL.
4. Salvare e reinviare la fattura.

Distinzione da altri blocchi:

• Campo IBAN vuoto con icona di stop rossa sui campi obbligatori -- vedere "Icona di stop rossa durante l'invio" sopra.
• "ID non formattato correttamente" riguarda la formattazione dell'identificatore/schemeID, non il conto bancario -- vedere le sezioni sugli errori sconosciuti/validazione dell'identificatore sopra.

Il messaggio continua a comparire? Richiedere il contenuto esatto del campo (compresi spazi o caratteri) e il messaggio di errore letterale o uno screenshot.

Varianti di ricerca: "il pulsante di invio non risponde", "la schermata di caricamento si blocca durante l'invio", "testo strano sulla fattura", "nome fornitore strano", "unità illogica sulla fattura", "l'organizzazione mostra testo strano", "accedere più volte per salvare", "accedere di nuovo per inviare", "campi fattura tradotti", "traduzione del browser durante la creazione della fattura", "non riesco ad accedere", "testo strano nella pagina di accesso".

Se il pulsante di invio non risponde o la schermata di caricamento rimane bloccata durante l'invio di una fattura Peppol, e vengono visualizzate sintassi di template non tradotte come {{invoice.data.supplierDetails.name}} al posto dei valori inseriti, la causa probabile è la traduzione automatica del browser.

Lo stesso schema può verificarsi durante la creazione di una (nuova) fattura: etichette/valori dei campi illogici o "tradotti" per, tra gli altri, fornitore, organizzazione e unità, dove salvare o inviare riesce solo dopo aver effettuato nuovamente l'accesso più volte. Questo ha la stessa causa dei segnaposto del pulsante di invio -- non è un defetto del prodotto e non è motivo per reinstallare il software client (la piattaforma è solo browser).

Lo stesso accade sulla pagina di accesso di platform.econnect.eu e altrove nell'interfaccia: testo segnaposto o chiavi i18n grezze (ad esempio {{lang.text}} o I18N_COLLABRR_WS.*) al posto delle etichette normali. Gli utenti spesso segnalano questo come «non riesco ad accedere». Vedere anche Accesso e 2FA.

La traduzione automatica del browser (Chrome o Edge) interferisce con il DOM della piattaforma. Questo impedisce ai pulsanti di funzionare correttamente e lascia visibili segnaposto di template o i18n, oppure etichette di campo illogiche.

Soluzione (ordine prima linea):

1. Disabilitare la traduzione automatica nel browser per la piattaforma eConnect (incluso platform.econnect.eu).
2. Aggiornamento forzato (Ctrl+F5) ed effettuare nuovamente l'accesso; riaprire o ricreare la fattura se necessario.
3. Ancora senza successo? Svuotare la cache del browser e/o provare un altro browser.
4. Il problema persiste? Richiedere uno screenshot della pagina della fattura, incluso browser e versione.

Varianti di ricerca: «Errore durante l'invio», «errore del portale intermittente», «funziona dopo il riavvio», «errore di invio senza dettagli», «messaggio di errore senza contenuto».

A volte un utente segnala un errore durante l'invio tramite la piattaforma, senza il testo letterale dell'errore o uno screenshot. Senza questo contenuto non ci sono informazioni sufficienti per una diagnosi solida; non si tratta di un'interruzione diffusa nota.

Possibile primo passo (causa non confermata):

1. Svuotare la cache del browser e/o provare un altro browser.
2. Se non aiuta, richiedere più contesto: il messaggio di errore letterale o uno screenshot, l'orario e il numero di fattura.

Da non confondere con:

• Il pulsante di invio non risponde, la schermata di caricamento si blocca, o etichette/segnaposto illogici -- vedi «Il pulsante di invio Peppol non risponde» sopra (traduzione automatica del browser, con un proprio ordine first-line).
• Stato SentRetry o SentError dopo l'accettazione -- vedi la sezione sulla riconsegna automatica Peppol più avanti in questa pagina; si tratta di un meccanismo di retry lato server, non un problema di cache del browser.

Durante l’invio di una fattura può comparire il messaggio di errore «EndpointID mancante». Si tratta di un bug noto della piattaforma — non è un problema di registrazione Peppol lato cliente. Una diagnosi automatica a volte lo classifica erroneamente come problema di registrazione; tale classificazione è errata.

Soluzione (workaround): aprire il blocco della fattura → fare clic sull’icona della matita in alto a destra → riselezionare il fornitore e/o il debitore → inviare nuovamente la fattura. La piattaforma ricostruisce gli identificativi nel XML e può quindi inviare correttamente la fattura.

Si tratta dello stesso workaround con l’icona della matita come per «Il campo Fornitore è vuoto» / BR-NL-1 e «Identificativo del fornitore obbligatorio». La differenza sta nel messaggio di errore specifico «EndpointID mancante».

Varianti di ricerca: «Fornire un ID valido dell'entità fornitrice», ID valido entità fornitrice, ID entità fornitrice, ID entità fornitrice corretto.

Questo messaggio riguarda l'ID Fornitore / Party ID — il proprio identificativo di organizzazione sulla fattura (standard NL: numero Camera di Commercio, 8 cifre, schema 0106), non il debitore. La causa è solitamente una selezione Fornitore vuota o non valida, testo digitato manualmente invece del menu a tendina, o un identificativo senza l'interruttore Invio attivato.

Soluzione: fare clic sull'icona della matita accanto a Fornitore e riselezionare la propria organizzazione dal menu a tendina. Verificare quindi in Organizzazioni → la propria organizzazione → Dettagli che almeno un identificativo abbia l'interruttore Invio attivato. Vedere anche Party identifiers § Party ID.

Doppio sintomo (frequente con enti pubblici): questo messaggio compare insieme a «solo e-mail» o «Peppol non selezionabile» quando si invia a un debitore pubblico? Sono due cause separate su un unico concetto:

1. Fornitore/Party ID (organizzazione propria) — soluzione come sopra.
2. Debitore pubblico non raggiungibile via Peppol — per ente pubblico NL, Invia tramite deve essere impostato su OIN/OINO e l'ID Organizzazione deve essere l'OIN esatto di 20 cifre, senza il prefisso 0190:. Nessuna opzione Peppol significa che il destinatario ricade sulla consegna via e-mail (non un guasto), non utilizzare il numero Camera di Commercio. Vedere «not available» durante l'invio (test) a un destinatario più sotto e «Fatturare alla pubblica amministrazione olandese» nella knowledge base.

Salvare e Inviare di nuovo dopo aver corretto entrambi i punti; Peppol dovrebbe quindi apparire per un OIN raggiungibile.

Questo messaggio compare quando si carica una fattura XML sulla piattaforma. La piattaforma legge i dati dall'XML, ma l'identificativo del fornitore è assente nel file. Di conseguenza la piattaforma non può inviare la fattura.

Soluzione: fare clic sull'icona della matita accanto al campo fornitore e riselezionare la propria organizzazione. La piattaforma ricostruisce la sezione fornitore e aggiunge gli identificativi richiesti all'XML.

Si tratta della stessa soluzione di "Il campo Fornitore è vuoto" e BR-NL-1: riselezionare la propria organizzazione tramite l'icona della matita. La differenza è che qui appare il messaggio specifico "Identificativo del fornitore obbligatorio" a causa di un identificativo fornitore mancante nell'XML caricato.

Varianti di ricerca: «Nessun identificativo attivato per l'invio trovato per l'azienda fornitrice», identificativi attivati per l'invio, «verifica del fornitore non ancora effettuata», invio fattura nuova amministrazione, due organizzazioni con e senza S.r.l., identificativi non verificati.

Questo messaggio, e la frase del cliente «verifica del fornitore non ancora effettuata» su una prima fattura o nuova amministrazione, di solito non indica un passaggio KYC fornitore separato. La causa è quasi sempre uno di questi quattro punti.

Checklist (in ordine):

1. Organizzazione fornitrice corretta selezionata? Con due organizzazioni simili (ad esempio lo stesso nome con e senza “S.r.l.”), può essere stata scelta quella sbagliata. Usare l'icona della matita per selezionare l'organizzazione con identificativi verificati -- un'organizzazione senza identificativi verificati non può inviare.
2. Organizzazione attivata? Non ancora attivata: attivarla prima tramite Aggiungere e attivare un'organizzazione.
3. Interruttore «Invio» attivo? Andare su Organizzazioni → la propria organizzazione → Dettagli e verificare che almeno un identificativo (preferibilmente la Partita IVA) abbia l'interruttore Invio attivo. Per un'organizzazione attivata, questo è di solito già attivo.
4. Partita IVA corretta? Verificare sia la Partita IVA del fornitore sia quella del debitore per codice paese e separatori -- vedere BR-CO-09 sopra. Un errore di formato IVA può verificarsi contemporaneamente a questo messaggio.

Se il messaggio persiste dopo questi quattro passaggi, inviare nuovamente la fattura dopo aver corretto i dati dell'organizzazione o della fattura.

Se una fattura non può essere inviata e resta nella cartella "Bozze", verificare due cose:

1. Invio attivato: verificare nelle impostazioni dell'organizzazione se "Invio documenti" è attivato. Se non lo è, contattare il supporto.
2. "Invia tramite" impostato: nella sezione "Debitore", oltre all'OrganisatieID, deve essere selezionata anche un'opzione "Invia tramite". Senza questa impostazione la fattura non può essere inviata.

La piattaforma eConnect utilizza a volte un prefisso del namespace nelle fatture UBL generate (ad es. <urn:Invoice xmlns:urn="...">). Entrambe le forme — con e senza prefisso — sono XML tecnicamente valido.

Un destinatario che rifiuta le fatture a causa del prefisso del namespace non è conforme a Peppol. Il prefisso del namespace non è configurabile per destinatario.

Comunicazione al cliente: la fattura è tecnicamente corretta. Il destinatario deve utilizzare un parser XML corretto che gestisca sia i namespace con prefisso che quelli predefiniti. Il rifiuto basato sul prefisso del namespace non è consentito in Peppol.

I codici errore EBMS come EBMS:0003 e EBMS:0004 sono errori di trasporto AS4 nella comunicazione tra Access Point. I clienti vedono SentError o SentRetry nella piattaforma — il codice EBMS stesso non è visibile nell'interfaccia cliente.

Azione: rinviare il cliente a TechSupport. TechSupport può visualizzare i dettagli dell'errore tramite l'audit trail e Application Insights.

Il codice errore stato 40 significa che il documento non è stato elaborato correttamente. Due possibili cause:

1. Errore di elaborazione IDR: l'IDR non può elaborare il documento e restituisce lo stato 40.
2. Rifiuto da parte della piattaforma: l'IDR ha elaborato il documento, ma la piattaforma lo imposta poi su stato 40 (ad es. a causa di un errore di validazione dopo la conversione).

Diagnostica: un dipendente eConnect deve verificare in CloudWatch quali fasi di elaborazione ha attraversato il documento.

Varianti di ricerca: "correggere EndpointID reinviare", "fattura inviata all'ID Peppol errato resend", "ID Peppol modificato destinatario riconsegnare", "reinviare PeppolID", "fattura di nuovo con altro PeppolID", "Reinvia Modifica PeppolID", "ellissi verticale reinvia", "menu riga reinvia posta in uscita", "fattura Consegnata cliente non vede nulla", "returnedMessageId destinatario fattura mancante".

Tramite l'opzione Reinvia nella posta in uscita, è possibile inviare nuovamente una fattura già inviata. Prima dell'invio effettivo, è possibile modificare campi come il riferimento (numero d'ordine, OrderReference) o l'EndpointID (ID di instradamento Peppol). La fattura viene quindi reinviata con lo stesso numero di fattura ma con il valore corretto.

Invio tramite AFAS / E-verbinding: se il documento è già nella posta in uscita, reinviarlo tramite Reinvia sulla piattaforma è la strada corretta -- non rigenerarlo in AFAS o E-verbinding. Se tale azione restituisce un errore rosso di evento applicativo, verificare prima la combinazione schema/valore dell'identificatore del destinatario (vedere la sezione «Errore sconosciuto durante la chiamata all'evento applicativo» sopra). Se il documento non è ancora nella posta in uscita, la causa è nel canale di invio (ERP/E-verbinding) -- il reinvio non si applica in quel caso.

Lo stato Consegnato non conferma che il destinatario veda la fattura nella propria contabilità. Tecnicamente, Consegnato significa che il punto di accesso del debitore ha accettato il documento. Se il debitore segnala comunque di non aver ricevuto nulla, fornire al cliente il returnedMessageId come ID di riferimento per la richiesta al proprio fornitore Peppol del destinatario (vedere la sezione «Stato 'consegnato' ma il destinatario non ha ricevuto la fattura» più sotto).

EndpointID obsoleto o modificato (ad esempio dopo una modifica del numero di partita IVA presso il destinatario): se una fattura è stata inviata a un ID Peppol errato o successivamente modificato, Reinvia con la correzione dell'EndpointID è il percorso preferito, non l'accredito seguito da una nuova fatturazione. Andare alla posta in uscita, cercare la fattura inviata all'ID Peppol errato, fare clic su Reinvia, correggere l'EndpointID con l'ID corretto prima dell'invio e inviare. La fattura viene reinviata con lo stesso numero fattura all'ID Peppol corretto. Verificare l'ID corretto tramite il Peppol Directory.

Una nota di credito con rifatturazione completa non è necessaria per questo scenario. Questo percorso più pesante si applica solo quando la fattura originale è già stata consegnata (parzialmente) o deve essere corretta per motivi contabili.

Un cliente può eseguire un reinvio autonomamente solo con un account piattaforma attivato con accesso alla posta in uscita. Un partner IT senza un proprio account deve prima registrarsi.

Questo è l'approccio consigliato quando un destinatario rifiuta una fattura a causa di un numero d'ordine errato o di un altro errore di riferimento. Evita la necessità di creare una nota di credito e una nuova fattura.

Nell'attuale Peppol BIS Billing 3.0 e NLCIUS, è supportato solo 1 riferimento ordine (OrderReference) per fattura. Si tratta di una limitazione derivante dalla norma europea EN 16931. Se una fattura copre più ordini, il fornitore deve inviare fatture separate.

AdditionalDocumentReference può contenere riferimenti aggiuntivi di altri tipi (progetto, contratto o riferimento acquirente), ma non più OrderReference.

Futuro: la EN 16931-1:2026 rivista (approvata formalmente dal CEN il 13 marzo 2026) aggiunge il supporto per più ordini di acquisto per fattura. Si prevede che venga incorporata in una futura versione dello standard Peppol (possibilmente BIS Billing 4.0). Nel frattempo, si applica la limitazione attuale di 1 OrderReference per fattura in BIS Billing 3.0 e NLCIUS.

Varianti di ricerca: "OrderReferentieNummer", "KopersReferentieNummer", "OrderReferentieNummer vs KopersReferentieNummer", "ordini non collegati in ERPx", "PO solo in BuyerReference".

Se una fattura viene rifiutata a causa di un numero d'ordine mancante o sconosciuto, è necessario distinguere due livelli.

1. Un riferimento è obbligatorio ai sensi di EN 16931. Un riferimento -- numero d'ordine o altro riferimento (BuyerReference, riferimento contratto o progetto) -- è richiesto. Una fattura senza alcun riferimento non è conforme alle regole di base della norma.

2. eConnect non rifiuta di default in base al contenuto del riferimento. L'unica situazione in cui la piattaforma rifiuta su questo punto è quando non è presente alcun riferimento.

3. La configurazione specifica del cliente può essere più restrittiva. Il rifiuto effettivo dipende dalla configurazione del destinatario. In una configurazione specifica, una fattura può essere rifiutata se il riferimento è sconosciuto a quel destinatario. Ciò dipende dalla configurazione e non è un comportamento standard della piattaforma eConnect.

4. Numero d'ordine (BT-13, OrderReference/ID) non riconosciuto dal destinatario. Un numero d'ordine in XML dovrebbe normalmente essere riconosciuto dall'ERP del destinatario. In pratica, la corrispondenza a volte fallisce per uno di questi motivi:

• Il sistema ERP del destinatario non è configurato per abbinare automaticamente il valore dell'ordine.
• Il mittente trasmette il valore dell'ordine in modo non standard (ad es. in un campo di riferimento diverso da quello atteso dall'ERP).
• Il valore dell'ordine si trova in un campo di riferimento diverso da quello monitorato dall'ERP del destinatario.

Nomi dei campi della piattaforma, da non confondere. Sulla piattaforma, BT-13 (OrderReference/ID) è denominato OrderReferentieNummer e BT-10 (BuyerReference) è denominato KopersReferentieNummer. Per la corrispondenza ordini ERP (ad es. Unit4 ERPx), il numero d'ordine d'acquisto deve essere inserito in OrderReferentieNummer -- KopersReferentieNummer è il riferimento proprio dell'acquirente e non sostituisce la corrispondenza PO. Una fattura può essere valida secondo EN 16931 con solo KopersReferentieNummer compilato (la norma richiede almeno uno dei due), mentre la corrispondenza ordine nell'ERP fallisce comunque: valido secondo EN non equivale a una corrispondenza ordine riuscita. Se il valore PO è stato inserito per errore solo in KopersReferentieNummer, far spostare il fornitore il valore in OrderReferentieNummer; KopersReferentieNummer può rimanere compilato anche in aggiunta.

eConnect può risolvere questo problema a livello di prodotto per destinatario, in modo che il processo di corrispondenza funzioni correttamente. Ciò può essere configurato anche per un mittente specifico.

Azione:

• Rinviare la fattura usando l'opzione Reinvia (vedere la sezione precedente) con un riferimento valido.
• Se il numero d'ordine è sconosciuto, contattare il destinatario riguardo alla procedura desiderata.
• Se la corrispondenza fallisce sistematicamente con un destinatario specifico, contattare il supporto -- eConnect può configurare una soluzione su misura per destinatario (e opzionalmente per mittente).

Una fattura con stato finale InvoiceSentError (dopo un errore di validazione 4xx) non tenta ulteriori consegne. Solo gli errori 5xx vengono ritentati (massimo 8 tentativi, circa 35 ore). Per un errore 4xx, viene effettuato un solo tentativo; nulla viene inviato ulteriormente al destinatario.

Non esiste un endpoint DELETE per le fatture di vendita (salesInvoice). Una fattura di vendita inviata o rifiutata è un evento rilevante per l'audit e rimane disponibile nel registro di audit per 90 giorni. Se la fattura era errata, emettere una nota di credito o fattura correttiva secondo il flusso contabile standard.

La rete Peppol dispone di un meccanismo automatico di riconsegna/retry in caso di errori di consegna temporanei tra Access Point. Quando la consegna all'Access Point ricevente (C3) fallisce temporaneamente -- ad esempio a causa di un'interruzione del servizio lato destinatario -- l'Access Point mittente (C2) tenta di riconsegnare il documento in un secondo momento.

• Errore temporaneo (5xx) = retry; errore permanente (4xx) = nessun retry. A livello di invio eConnect, solo gli errori 5xx vengono ritentati (massimo 8 tentativi, circa 35 ore). Un errore di validazione 4xx è permanente e dà luogo a un unico tentativo -- vedere anche la sezione "InvoiceSentError" sopra.
• Stato nella piattaforma: durante un retry, il cliente vede lo stato SentRetry (livello di trasporto AS4). In caso di fallimento definitivo, questo diventa SentError.
• Effetto di un'interruzione di rete o Access Point: la fattura può essere consegnata solo diversi giorni dopo l'invio, ossia quando il retry ha successo. Il mittente non deve intraprendere alcuna azione -- la riconsegna avviene automaticamente all'interno della finestra di retry.
• Durata esatta della finestra: la finestra di retry esatta della rete Peppol (al di fuori del retry di invio eConnect) non è standardizzata pubblicamente e può variare a seconda dell'Access Point.

Questo meccanismo di riconsegna spiega in parte perché la data di ricezione può essere diversi giorni successiva alla data della fattura (IssueDate). Vedere anche Data fattura (IssueDate) vs. data di ricezione in eConnect per la spiegazione dal lato ricezione.

Fonte: conferma dell'esperto Johan Schaeffer (Peppol & Fatturazione elettronica), 2026-07-04, relativa al ticket #15268901 (W776).

Gli errori di validazione come TaxInclusiveAmount '-1.336061E6' non è un xs:decimal valido si verificano perché il sistema di origine serializza un importo numerico in notazione scientifica (es. -1.336061E6 per -1.336.061,00). I campi importo UBL sono di tipo xs:decimal, che non consente la notazione E.

Causa comune: il sistema di origine memorizza gli importi internamente come double/float e utilizza la conversione stringa predefinita, che passa automaticamente alla notazione esponenziale per valori molto grandi o molto piccoli.

Seconda causa distinta -- campo importo vuoto: l'errore The string '' is not a valid Decimal value su un campo PriceAmountType si verifica quando un campo importo (ad esempio cbc:PriceAmount) contiene una stringa vuota ("") su una o più righe fattura invece di un numero decimale. xs:decimal non consente una stringa vuota come valore lessicale. Questa è una causa diversa e separata dalla notazione scientifica, ma della stessa classe di pattern di errore ("non è un xs:decimal valido"/"not a valid Decimal value"): il sistema di origine lascia semplicemente il campo vuoto invece di inviare un numero formattato in modo errato.

Soluzione lato cliente (entrambe le varianti): aggiornare il sistema di origine in modo che gli importi vengano sempre scritti come stringa decimale normale (es. tramite tipi decimal/BigDecimal o un pattern decimale indipendente dalla locale, senza separatori delle migliaia e senza notazione E), e che nessun campo importo resti vuoto.

Lato eConnect: non può essere corretto automaticamente -- il valore è già errato (o vuoto) nell'XML fornito. Fare riferimento al fornitore del pacchetto software; la fattura deve essere inviata nuovamente con un importo valido su tutte le righe.

Questo scenario si applica quando il fornitore afferma di aver inviato la fattura ma il destinatario non ha ricevuto nulla, e la fattura non ha ancora raggiunto lo stato finale 'Consegnata' o lo stato è incerto.

Diagnosi in tre passaggi:

1. Verificare lo stato di invio nella piattaforma. Andare alla Casella di posta in uscita (piattaforma) o PSB Control > Eventi (PSB). Il cliente può verificarlo autonomamente (autodiagnosi). Se la fattura mostra 'Inviata' o 'Consegnata' nella Casella di posta in uscita o come evento riuscito in PSB Control, la fattura è stata inviata alla rete Peppol. Se il Participant ID del destinatario è registrato presso un altro o concorrente Access Point, la fattura è stata consegnata a quell'Access Point -- questo non è un problema di invio eConnect. Uno stato del partner software come "Inviata" (ad esempio in Simar) non significa automaticamente che il documento sia stato inviato anche a eConnect -- verificare direttamente lo stato Casella di posta in uscita/PSB. È anche comune che il cliente legga male l'ID Peppol del debitore (ad es. leggendo 0106-1234567 come un'unica stringa con trattino) o inserisca lo stesso numero sia in Invia tramite sia in ID organizzazione. Non si trova affatto nella Casella di posta in uscita o in PSB? Allora non esiste alcun percorso di reinvio -- rimandare il cliente al partner software o all'ERP mittente per scoprire perché la fattura non è mai stata inviata. La diagnosi cross-AP è rilevante solo quando è effettivamente coinvolto un altro partecipante eConnect.
2. Destinatario non attivato? Allora non instradabile. Non è possibile inviare a un'organizzazione non attivata: non è pubblicata come Participant nell'SMP/SML e il Participant ID non è instradabile tramite eConnect. Errore comune: i mittenti pensano di dover aggiungere anche il destinatario (il loro cliente) come organizzazione nella piattaforma -- non è necessario. Solo l'organizzazione mittente deve essere attivata; il destinatario non deve essere presente nell'account.
3. Il destinatario è presso un altro fornitore? Migrazione necessaria. Se il destinatario (o il fornitore stesso) desidera migrare a eConnect: prima annullare la registrazione presso il vecchio Service Provider, poi registrarsi con eConnect. Attivare prima l'organizzazione affinché la registrazione possa essere completata immediatamente, oppure richiedere un codice di migrazione (questo non è ancora automatico nella piattaforma). Vedere Registrazione e migrazione Peppol.

Per lo scenario in cui lo stato mostra già Consegnata ma il destinatario dice di non aver ricevuto nulla, vedere la sezione "Stato 'consegnato' ma il destinatario non ha ricevuto la fattura" di seguito.

Lo stato Consegnato significa che il punto di accesso ricevente (il fornitore di servizi Peppol del debitore) ha tecnicamente accettato il documento e confermato tale accettazione. eConnect riceve un returnedMessageId (formato GUID@econnect.eu): prova che la fattura è arrivata al punto di accesso del destinatario. Il punto in cui il returnedMessageId è visibile differisce tra la piattaforma e il PSB — verificare l’ambiente corretto per il cliente.

Se il debitore dichiara di non aver ricevuto la fattura mentre lo stato mostra 'Consegnato', il documento è stato consegnato al punto di accesso del debitore ma non è ancora visibile nel suo software o nella sua contabilità. Si tratta di un problema a valle sul lato del destinatario.

Passi per risolvere:

1. Confermare al cliente che la fattura è stata inviata correttamente al punto di accesso Peppol del debitore e che eConnect ha ricevuto una conferma di consegna.
2. Consigliare al cliente di chiedere al debitore di contattare il proprio fornitore di servizi Peppol. Il returnedMessageId può essere fornito: con quell'identificatore il punto di accesso ricevente può rintracciare il documento.
3. La gestione successiva spetta al punto di accesso del debitore; eConnect come parte mittente non ha visibilità oltre il punto di consegna.

Varianti di ricerca: «aggiungere organizzazione» per una fattura, portale fornitori, nome organizzazione + numero Camera di Commercio in alto a destra, impossibile modificare la riga organizzazione esistente, impossibile rinominare l'organizzazione esistente, screenshot organizzazione cliente in alto a destra, messaggio identificativo durante l'aggiunta di un'organizzazione (fornitore), aggiungere la propria organizzazione separatamente, debitore come propria organizzazione, aggiungere destinatario fattura all'ambiente, attivare organizzazione debitore pubblica amministrazione, il destinatario deve essere nell'ambiente, registrarsi con l'OIN proprio di un comune, OIN del cliente come propria organizzazione, fatturare a un comune con OIN proprio, OIN destinatario non è il proprio identificativo, schema 0190 debitore.

I nuovi utenti -- in particolare quelli che passano da altri servizi di fatturazione elettronica -- a volte cercano di aggiungere l'organizzazione ricevente come propria organizzazione sulla piattaforma durante l'invio di una fattura. Non è necessario e genera un messaggio di errore.

Per inviare una fattura a un destinatario, quella organizzazione non deve essere presente nel proprio account: al momento della creazione della fattura, si seleziona il destinatario tramite il campo di ricerca debitore. È possibile cercare per numero di registro commerciale, ragione sociale o numero OIN.

Messaggio di errore "L'identificatore è già stato verificato in un'altra organizzazione"

Questo messaggio viene visualizzato durante la presentazione della fattura (tramite Peppol) o quando si tenta di "aggiungere un'organizzazione ricevente". Il messaggio copre due scenari con cause e soluzioni diverse:

Scenario 1: il messaggio riguarda l'identificatore del CLIENTE (destinatario/debitore). Si tratta di un utilizzo scorretto della piattaforma: l'utente tenta di aggiungere un'organizzazione cliente/destinataria al proprio ambiente. Non si tratta di un problema di autorizzazione — il supporto non deve liberare l'identificatore internamente. La procedura corretta: aggiungere solo la propria organizzazione (o le proprie organizzazioni) e attivarle nel proprio ambiente. Successivamente, inviare la fattura al destinatario tramite il campo di ricerca debitore — il destinatario non deve essere presente nel proprio account.

Scenario 2: il messaggio riguarda il PROPRIO identificatore dell'utente. L'identificatore è già registrato sotto un'altra organizzazione in un altro account. Non si tratta di un utilizzo scorretto della piattaforma: l'utente vuole legittimamente creare la propria organizzazione. Cause possibili: un collega ha già creato l'organizzazione, oppure l'organizzazione esiste ancora in un vecchio account.

• Internamente: verificare chi ha creato l'organizzazione in precedenza e aggiungere il nuovo utente a quell'account o organizzazione.
• Se il creatore è sconosciuto: il supporto può cercare l'indirizzo e-mail del creatore in modo che l'utente possa contattarlo direttamente. Il supporto non scollega né trasferisce l'identificatore — ciò non fa parte della procedura di supporto standard.

Varianti di ricerca: «nessuna organizzazione trovata», «nessuna organizzazione trovata Francia», «destinatario non trovato per nome», «la ricerca debitore fallisce», «ricerca per nome debitore», «non è possibile cercare per ID Peppol», «fattura tramite GLN», «inserire debitore manualmente», «database aziendale non è Peppol», «destinatario estero non nei risultati di ricerca», «organizzazione non selezionabile», «ricerca IVA FR fattura bozza», «ricerca IVA FR vuota», «0225 SIREN Invia tramite», «OrganisationID SIREN».

Punto chiave: la ricerca per nome del debitore interroga il database aziendale (registro delle imprese, ecc.), non Peppol. Il messaggio «nessuna organizzazione trovata» sul nome dell'organizzazione o su una partita IVA francese non significa quindi che il destinatario non sia su Peppol, né che sia impossibile cercare tramite ID Peppol -- non dice nulla sullo stato online/offline del destinatario su Peppol.

Soluzione:

1. Debitore non trovato tramite il database aziendale? Inserire il debitore manualmente con i dati del destinatario (nome, indirizzo, paese, identificativo).
2. L'identificativo Peppol del destinatario è noto?
   • Spesso un GLN (scheme 0088, etichette GS1/EAN): impostare Invia tramite su GLN e inserire solo le cifre in OrganisationID, senza il prefisso 0088: (vedere la regola generale solo-cifre sopra riguardo alla formattazione degli identificativi).
   • Francia / CTC: impostare Invia tramite su 0225 (SIREN/FR CTC) e inserire solo il valore SIREN in OrganisationID, senza il prefisso 0225: (9 cifre pure, oppure il formato esteso SIREN_SUFFIX/SIREN_SIRET). Non inserire qui una partita IVA francese -- è uno scheme separato (9957). Vedere Qual è il mio Peppol ID?.
3. Non creare il destinatario tramite Aggiungi organizzazione -- questa funzione è destinata alla propria organizzazione, non al destinatario della fattura (vedere la sezione «Confusione: tentare di aggiungere l'organizzazione destinataria come propria organizzazione» sopra).
4. L'endpoint è stato fornito dal cliente ma non è raggiungibile? Confermare prima il formato scheme/valore; se risulta che il destinatario non ha ancora una registrazione di ricezione attiva, il destinatario francese deve completare la registrazione 0225 prima che una fattura di prova possa avere esito positivo.

Varianti di ricerca: "enabled for Peppol sending", "additional Peppol activation", "is sending already enabled", "attivazione invio aggiuntiva", "University of Luxembourg", "9938", "scheme destinatario estero".

Per un'organizzazione attivata, l'invio è attivo per impostazione predefinita: fa parte della connessione standard. Non esiste un passaggio separato «Peppol send enable» oltre a uno stato organizzazione attivo. Vedere Registrarsi su Peppol per la procedura di attivazione completa.

Inserire il destinatario (ad esempio una parte Peppol estera come un'università lussemburghese) solo sulla fattura, tramite il campo di ricerca debitore (ID organizzazione + Invia tramite). Non aggiungere il destinatario come propria organizzazione nell'account -- vedere anche la sezione «Confusione: tentare di aggiungere l'organizzazione destinataria come propria organizzazione» sopra.

Si continua a ricevere un messaggio di errore non descritto qui? Contattare il supporto tramite support.econnect.eu.