
Codici di errore del validatore KoSIT: regole BR-DE, BR-CO e PEPPOL
Riferimenti ufficiali
Usa queste fonti per verificare date, formati e modifiche ufficiali delle regole.
Wiki tecnica correlata
Esplora la documentazione approfondita per sviluppatori e le linee guida normative corrispondenti a questo articolo.
Errori di validazione BR-DE per XRechnung, con la regola di business interessata e una soluzione pratica.
Come XRechnung applica EN 16931 in Germania: sintassi XML, validazione, riferimento acquirente e canale di invio.
Formato, cifra di controllo e uso della Leitweg-ID per le fatture XRechnung destinate agli enti pubblici tedeschi.
Un report KoSIT elenca ogni regola non superata con il suo ID, un breve messaggio e una posizione XML. Questa pagina spiega le regole che compaiono più spesso nei report del nostro validatore XRechnung gratuito, con la causa tipica e la correzione. Ogni ID di regola porta a una pagina con esempi XML.
Parti dal primo errore del report. Correggi il campo indicato nei dati di origine, genera di nuovo il file e controllalo con la stessa configurazione del validatore.
Che cos’è KoSIT?
KoSIT, la Koordinierungsstelle für IT-Standards, è l’ufficio pubblico tedesco di coordinamento che pubblica lo standard XRechnung. Pubblica anche il validatore open source e la configurazione XRechnung, che controllano un file rispetto allo schema XML, alle regole della EN 16931 e alle regole tedesche BR-DE.
Pipeline interattiva
Come viene validata una fattura elettronica
Fai clic su una fase per vedere cosa controlla, oppure digita l’ID di una regola per trovare la fase che la segnala.
Fase 1 · Cosa controlla
Schema XML
- Il file è XML ben formato. Se non si può leggere, nessuna regola può essere eseguita.
- Elemento radice, namespace, ordine degli elementi e tipi di dato seguono lo schema UBL 2.1 o CII D16B.
Codici di esempio
Correzione tipica
Correggi il generatore: un elemento fuori posto, un namespace errato o un valore nel tipo di dato sbagliato.
Le regole KoSIT che falliscono più spesso
La tabella è ordinata in base a quante volte ogni regola compare nei controlli falliti dei nostri validatori gratuiti. La gravità è il livello nella configurazione del validatore indicata nella sezione successiva.
| Regola | Gravità | Significato | Causa tipica | Correzione |
|---|---|---|---|---|
PEPPOL-EN16931-R008 | Errore | L’XML contiene un elemento senza testo e senza elementi figli. | Un modello di esportazione scrive ogni campo anche senza valore nell’origine, per esempio <cbc:Note/>. | Rimuovi l’elemento, e il gruppo padre se resta vuoto. Non riempirlo con "-" o "n/a". |
BR-DE-19 | Avviso | Con il codice 58 (bonifico SEPA) in BT-81, l’identificativo del conto BT-84 deve essere un IBAN valido. | Un errore di battitura nell’IBAN, un’etichetta come "IBAN:" nel campo o un numero di conto nazionale. | Correggi l’IBAN nei dati anagrafici. Le cifre di controllo devono superare il test modulo 97; gli spazi vengono ignorati. |
BR-CO-09 | Errore | Le partite IVA in BT-31, BT-48 e BT-63 devono iniziare con un codice paese ISO 3166-1 (Grecia: EL). | Il numero è stato esportato senza prefisso, oppure un codice fiscale nazionale è finito nel campo della partita IVA. | Scrivi la partita IVA con il prefisso, per esempio DE123456789. Il numero fiscale tedesco (Steuernummer) va in BT-32. |
BR-CO-13 | Errore | Il totale imponibile (BT-109) deve essere pari agli importi netti delle righe, meno gli sconti (BT-107) e più le maggiorazioni (BT-108) a livello di documento. | Uno sconto o una maggiorazione è nel totale stampato, ma manca nell’XML come sconto o maggiorazione a livello di documento. | Ricalcola i totali dalle righe, dagli sconti e dalle maggiorazioni esportati invece di copiare il totale stampato. |
BR-S-08 | Errore | Per ogni aliquota della categoria S, l’imponibile (BT-116) deve essere pari agli importi netti delle righe, più maggiorazioni e meno sconti a quell’aliquota. | Uno sconto o una maggiorazione a livello di documento ha l’aliquota sbagliata, oppure uno sconto su più aliquote è stato esportato con una sola. | Raggruppa righe, sconti e maggiorazioni per aliquota e ricostruisci ogni riepilogo IVA (BG-23) da questi gruppi. |
BR-CO-11 | Errore | La somma degli sconti a livello di documento (BT-107) deve essere pari alla somma di tutti gli importi di sconto (BT-92). | Uno sconto è detratto in BT-107, ma non è esportato come sconto a sé (BG-20). | Esporta ogni sconto come BG-20 e calcola BT-107 da questi importi. |
BR-DE-27 | Avviso | Il numero di telefono del contatto venditore (BT-42) deve contenere almeno tre cifre. | Un segnaposto come "--" o "N/A", oppure un nome nel campo del telefono. | Inserisci il numero aziendale reale nei dati del venditore, per esempio +49 30 1234567. |
BR-DE-15 | Errore | Il riferimento dell’acquirente (BT-10) deve essere presente. KoSIT verifica solo che ci sia, non il formato della Leitweg-ID. | L’ordine non indicava un riferimento, oppure l’esportazione lascia vuoto BT-10 per i clienti aziendali. | Chiedi all’acquirente quale riferimento si aspetta; un ente pubblico indica di solito una Leitweg-ID. Non inventarla. |
PEPPOL-EN16931-R010 | Errore | L’indirizzo elettronico dell’acquirente (BT-49) deve essere presente. | L’anagrafica cliente non contiene un indirizzo di fatturazione elettronica dell’acquirente. | Chiedi all’acquirente l’indirizzo e il relativo schema, per esempio 0204 per una Leitweg-ID o EM per un indirizzo e-mail. |
BR-DE-21 | Avviso | L’identificativo della specifica (BT-24) deve essere quello di XRechnung. | Il file dichiara ZUGFeRD, Peppol BIS, la sola EN 16931 o una versione precedente di XRechnung. | Imposta BT-24 sull’identificativo di XRechnung 3.0, oppure controlla il file con un validatore per il profilo dichiarato. |
CII-SR-465 / CII-SR-466 | Errore (XRechnung CII) | In CII un punto di contatto (BT-41 venditore, BT-56 acquirente) è un nome di persona o di reparto, non entrambi. | L’esportazione scrive ram:PersonName e ram:DepartmentName uno accanto all’altro. L’attuale configurazione KoSIT porta l’avviso del CEN a errore. | Mantieni solo uno dei due elementi. L’UBL non è interessato. |
BR-FX-EN-04 | Avviso (Factur-X) | Factur-X / ZUGFeRD: una fattura tra parti tedesche richiede una data di consegna (BT-72), un periodo di fatturazione (BG-14) o un periodo su ogni riga (BG-26). | L’origine non indica una data di consegna o di prestazione, oppure solo un periodo senza paese di consegna (BT-80). | Aggiungi la data o il periodo dai documenti di origine; con il solo periodo, aggiungi anche BT-80. Questa regola la controlla il validatore ZUGFeRD, non KoSIT. |
PEPPOL-EN16931-R020 | Errore | L’indirizzo elettronico del venditore (BT-34) deve essere presente. | I dati del venditore non contengono un indirizzo di fatturazione elettronica. La regola ha un nome Peppol, ma KoSIT la applica a ogni XRechnung. | Inserisci l’indirizzo elettronico del venditore con il relativo schema (BR-62), per esempio un indirizzo e-mail con schema EM. |
BR-CO-10 | Errore | La somma degli importi netti di riga (BT-106) deve essere pari al totale di tutti gli importi netti di riga (BT-131). | Una riga, come la spedizione, è stampata ma non esportata, oppure le righe sono state arrotondate dopo il calcolo della somma. | Calcola BT-106 dalle righe esportate, con lo stesso arrotondamento delle righe. |
BR-CO-15 | Errore | Il totale con IVA (BT-112) deve essere pari a BT-109 più l’importo totale dell’IVA (BT-110). | Il totale lordo è stato copiato dal PDF mentre netto o IVA sono stati ricalcolati, quindi differisce di un centesimo di arrotondamento. | Calcola BT-112 come BT-109 + BT-110 dai valori esportati. |
BR-DE-1 | Errore | La fattura deve contenere le istruzioni di pagamento (BG-16). | Le coordinate bancarie sono stampate nel PDF, per esempio a piè di pagina, ma non vengono esportate. | Aggiungi BG-16 con il codice del mezzo di pagamento (BT-81) e i relativi dati di conto o di mandato. |
BR-DE-2 | Errore | Il gruppo contatto del venditore (BG-6) deve essere presente; BR-DE-5, BR-DE-6 e BR-DE-7 richiedono poi BT-41, BT-42 e BT-43. | L’esportazione scrive l’indirizzo dell’azienda, ma nessun nome di contatto, numero di telefono o indirizzo e-mail. | Registra nei dati del venditore un nome di contatto presidiato, un numero di telefono e un indirizzo e-mail. |
KoSIT verifica solo che BT-10 sia presente (BR-DE-15). Per XRechnung, Invoice-Converter.com avvisa nella fase di revisione se una Leitweg-ID in BT-10 ha una cifra di controllo errata; non blocca il file per questo. Tutte le altre regole sono nel riferimento degli errori KoSIT.
Da quale versione del validatore vengono le regole
Invoice-Converter.com controlla i file XRechnung con il validatore KoSIT 1.6.3 e la configurazione XRechnung v2026-08-31: XRechnung 3.0.2 con gli artefatti di validazione EN 16931 1.3.16. Un’altra configurazione può segnalare altre regole o altri livelli; confronta quindi solo report della stessa configurazione.
Per XRechnung 3.0, BT-24 deve identificare il profilo come urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0. Un identificativo abbreviato o un identificativo ZUGFeRD seleziona un altro insieme di regole.
Con gli artefatti EN 16931 1.3.16 la regola BR-CO-25 è stata eliminata. Un report che la mostra ancora proviene da una configurazione precedente: un importo dovuto positivo non richiede più una data di scadenza (BT-9) né condizioni di pagamento (BT-20).
La configurazione XRechnung controlla un XML UBL o CII rispetto allo schema XML, alle regole EN 16931 e alle regole tedesche XRechnung. Non controlla il contenitore PDF/A-3 di un file ZUGFeRD o Factur-X. Per questa verifica distinta usa un validatore per fatture ibride.
Un avviso non è un rifiuto
Un report KoSIT distingue qui due livelli. Un errore (segnato come “fatal” nello Schematron) rende il file non valido. Un avviso è una raccomandazione: se il report non contiene errori, KoSIT raccomanda comunque di accettare il file.
Nella tabella, BR-DE-19, BR-DE-27, BR-DE-21, BR-FX-EN-04 sono avvisi. Correggili se i dati alla base sono errati, per esempio un IBAN digitato male. Non bloccare un file altrimenti valido solo per un avviso e non nascondere un avviso con un segnaposto.
Sequenza sicura per la correzione
Spesso segue BR-DE-16: se la fattura usa la categoria IVA S, Z, E, AE, K, G, L o M, servono la partita IVA del venditore (BT-31), il suo codice di registrazione fiscale (BT-32) o un rappresentante fiscale (BG-11 con BT-63); per K o G, BR-IC-02 e BR-G-02 accettano solo BT-31 o BT-63. La guida ai campi obbligatori XRechnung descrive gli altri gruppi BR-DE.
Invoice-Converter.com crea e controlla file di fattura elettronica. Non invia fatture e non è un access point Peppol.
- Conferma la versione XRechnung in BT-24 e la configurazione del validatore.
- Apri il primo errore del report e annota l’ID della regola e la posizione XML.
- Correggi il BT o il BG indicato nei dati di origine o nell’anagrafica, non solo nell’XML generato.
- Genera di nuovo la fattura e controllala con la stessa configurazione del validatore.
- Valuta gli avvisi a parte. Un avviso non equivale a una fattura rifiutata.
Domande frequenti
Che cos’è il validatore KoSIT?
Il validatore KoSIT è lo strumento di validazione open source della Koordinierungsstelle für IT-Standards tedesca. Con la configurazione XRechnung controlla un file XRechnung rispetto allo schema XML, alle regole della EN 16931 e alle regole tedesche BR-DE, ed elenca in un report ogni regola non superata.
Che cosa significa "Document MUST not contain empty elements"?
È la regola PEPPOL-EN16931-R008: il documento non deve contenere elementi vuoti. Il file contiene un elemento XML senza testo e senza elementi figli. Rimuovi l’elemento invece di riempirlo con un segnaposto.
Un avviso KoSIT è un rifiuto?
No. Solo gli errori rendono il file non valido. Avvisi come BR-DE-19, BR-DE-27 o BR-DE-21 sono raccomandazioni; correggili se i dati alla base sono errati.
Perché il mio file CII ora non supera CII-SR-465?
Dalla configurazione KoSIT del 31 agosto 2026, CII-SR-465 e CII-SR-466 sono errori per XRechnung in sintassi CII. Un contatto con sia un nome di persona sia un nome di reparto non è valido; mantieni solo uno dei due.
KoSIT convalida il PDF/A-3 ZUGFeRD?
No. La configurazione XRechnung convalida l’XML UBL o CII. Un file ZUGFeRD o Factur-X richiede anche controlli del contenitore PDF/A-3, dell’XML incorporato, dei metadati e della corrispondenza semantica tra PDF e XML.
Verifica la tua fattura elettronica
Carica il file XML XRechnung e scopri quali regole KoSIT non sono rispettate prima dell’invio. Il validatore è gratuito e funziona senza account.
