# Codici errore del validatore KOSIT: guida completa ai 21 errori BR-DE XRechnung [2026]

- Date: 2026-01-15
- Reading time: 18 min di lettura

Guida completa a tutti i 21 codici errore BR-DE del validatore KOSIT. Scopri cosa significano BR-DE-1…BR-DE-21, UBL-CR-646 e altri errori di validazione

## Panoramica dell’articolo

        Questo articolo spiega Codici errore del validatore KOSIT: guida completa ai 21 errori BR-DE XRechnung [2026] come riferimento pratico per la fatturazione elettronica europea. Definisce il tema in modo chiaro, lo colloca nel contesto di conformità e collega la spiegazione ai formati XRechnung, ZUGFeRD/Factur-X, UBL e CII.

Usa l’articolo come punto di partenza prima di modificare un workflow finance o ERP: identifica la regola nazionale o lo standard applicabile, scegli il formato strutturato richiesto, valida l’XML generato e mantieni un processo di eccezione documentato per le fatture che richiedono revisione manuale.

      **Stai ricevendo errori di validazione quando invii una fattura XRechnung o ZUGFeRD?** Qui trovi una panoramica completa dei 21 codici BR-DE del validatore KoSIT, con spiegazioni e soluzioni rapide.

Il validatore KoSIT (Koordinierungsstelle für IT-Standards) è lo strumento ufficiale in Germania per verificare la conformità di e‑fatture nei formati XRechnung e ZUGFeRD. Se una fattura fallisce la validazione, i messaggi possono sembrare “criptici”: questa guida ti aiuta a capirli e risolverli rapidamente.

        ### Soluzione veloce

        Se ti serve solo validare e correggere velocemente, usa il nostro flusso di validazione e‑fatture.

[Valida la tua e‑fattura ora →](/it/convert)
      

      ## Elenco completo dei codici errore BR-DE (KoSIT)

Per Elenco completo dei codici errore BR-DE (KoSIT), verifica questi punti prima di procedere.

        - [BR-DE-1: Una fattura tedesca deve includere l’indirizzo dell’acquirente](/it/resources/kosit-validator-errors/br-de-1-german-invoice-must-have-buyers-address)

- [BR-DE-2: Il contatto del venditore deve essere indicato](/it/resources/kosit-validator-errors/br-de-2-seller-contact-must-be-provided)

- [BR-DE-3: La città del venditore deve essere indicata](/it/resources/kosit-validator-errors/br-de-3-seller-city-must-be-provided)

- [BR-DE-4: Il CAP del venditore deve essere indicato](/it/resources/kosit-validator-errors/br-de-4-seller-postal-code-must-be-provided)

- [BR-DE-5: Il paese del venditore deve essere indicato](/it/resources/kosit-validator-errors/br-de-5-seller-country-must-be-provided)

- [BR-DE-6: Il nome del venditore deve essere indicato](/it/resources/kosit-validator-errors/br-de-6-seller-name-must-be-provided)

- [BR-DE-7: Il nome dell’acquirente deve essere indicato](/it/resources/kosit-validator-errors/br-de-7-buyer-name-must-be-provided)

- [BR-DE-8: Deve essere indicato il codice data del momento di esigibilità IVA](/it/resources/kosit-validator-errors/br-de-8-value-added-tax-point-date-code-must-be-provided)

- [BR-DE-9: Il codice valuta della fattura deve essere EUR](/it/resources/kosit-validator-errors/br-de-9-invoice-currency-code-must-be-eur)

- [BR-DE-10: Nessuna riga fattura per abbuoni o addebiti](/it/resources/kosit-validator-errors/br-de-10-no-invoice-lines-for-allowances-or-charges)

- [BR-DE-11: Devono essere indicate le condizioni di pagamento](/it/resources/kosit-validator-errors/br-de-11-payment-terms-must-be-provided)

- [BR-DE-12: La fattura deve avere almeno una riga](/it/resources/kosit-validator-errors/br-de-12-invoice-must-have-at-least-one-invoice-line)

- [BR-DE-13: Il riferimento dell’acquirente deve essere indicato](/it/resources/kosit-validator-errors/br-de-13-buyer-reference-must-be-provided)

- [BR-DE-14: Deve essere indicata la parte rappresentante fiscale del venditore](/it/resources/kosit-validator-errors/br-de-14-seller-tax-representative-party-must-be-provided)

- [BR-DE-15: Deve essere indicata la Leitweg-ID](/it/resources/kosit-validator-errors/br-de-15-leitweg-id-must-be-provided)

- [BR-DE-16: Deve essere indicato il tipo di processo aziendale](/it/resources/kosit-validator-errors/br-de-16-business-process-type-must-be-provided)

- [BR-DE-17: Deve essere indicato l’identificatore dell’oggetto](/it/resources/kosit-validator-errors/br-de-17-object-identifier-must-be-provided)

- [BR-DE-18: Devono essere indicati gli identificativi del venditore](/it/resources/kosit-validator-errors/br-de-18-seller-features-must-be-provided)

- [BR-DE-19: Il conto SEPA deve contenere un IBAN valido](/it/resources/kosit-validator-errors/br-de-19-sepa-payment-account-must-be-valid-iban)

- [BR-DE-20: Deve essere indicato il riferimento contratto](/it/resources/kosit-validator-errors/br-de-20-contract-reference-must-be-provided)

- [BR-DE-21: Deve essere indicato l’identificatore della specifica](/it/resources/kosit-validator-errors/br-de-21-specification-identifier-must-be-provided)

- [BR-CO-3: Data di esigibilità IVA e codice data di esigibilità si escludono a vicenda](/it/resources/kosit-validator-errors/br-co-3-vat-point-date-and-code-mutually-exclusive)

- [BR-CO-4: Ogni riga di fattura deve avere un codice categoria IVA](/it/resources/kosit-validator-errors/br-co-4-each-invoice-line-must-have-vat-category-code)

- [BR-CO-9: Le partite IVA devono avere un prefisso paese ISO 3166-1 alpha-2](/it/resources/kosit-validator-errors/br-co-9-vat-identifier-must-have-iso-country-prefix)

- [BR-CO-10: La somma degli importi netti di riga deve coincidere con il totale dei netti di riga](/it/resources/kosit-validator-errors/br-co-10-sum-of-line-net-amounts-must-equal-line-total)

- [BR-CO-11: La somma degli sconti a livello documento deve coincidere con il totale di tutti gli sconti](/it/resources/kosit-validator-errors/br-co-11-sum-of-document-allowances-must-match)

- [BR-CO-13: Il totale fattura IVA esclusa deve essere uguale al totale righe meno gli sconti più gli oneri](/it/resources/kosit-validator-errors/br-co-13-invoice-total-without-vat-must-match-totals-chain)

- [BR-CO-14: Il totale IVA della fattura deve essere uguale alla somma degli importi IVA per categoria](/it/resources/kosit-validator-errors/br-co-14-invoice-total-vat-must-equal-sum-of-vat-categories)

- [BR-CO-15: Il totale fattura IVA inclusa deve essere uguale al totale IVA esclusa più l’imposta totale](/it/resources/kosit-validator-errors/br-co-15-invoice-total-with-vat-must-match)

- [BR-CO-16: L’importo da pagare deve essere uguale al totale IVA inclusa meno gli acconti più l’arrotondamento](/it/resources/kosit-validator-errors/br-co-16-amount-due-for-payment-must-match)

- [BR-CO-17: L’importo IVA per categoria deve essere uguale alla base imponibile per l’aliquota diviso 100](/it/resources/kosit-validator-errors/br-co-17-vat-category-tax-amount-must-match-base-times-rate)

- [BR-CO-25: Se l’importo da pagare è positivo serve la data di scadenza o le condizioni di pagamento](/it/resources/kosit-validator-errors/br-co-25-positive-amount-due-needs-payment-due-date-or-terms)

- [BR-CO-26: Il venditore deve essere identificabile tramite un identificativo, un codice di registrazione o la partita IVA](/it/resources/kosit-validator-errors/br-co-26-seller-must-be-identifiable)

- [BR-S-1: Le righe ad aliquota standard richiedono una corrispondente riga nella ripartizione IVA](/it/resources/kosit-validator-errors/br-s-1-standard-rated-line-requires-standard-rated-vat-breakdown)

- [BR-S-5: L’aliquota IVA in una ripartizione ad aliquota standard deve essere maggiore di zero](/it/resources/kosit-validator-errors/br-s-5-standard-rated-vat-breakdown-rate-must-be-positive)

- [BR-S-8: La base imponibile ad aliquota standard deve essere uguale ai netti di riga più gli oneri meno gli sconti alla stessa aliquota](/it/resources/kosit-validator-errors/br-s-8-standard-rated-taxable-amount-must-match-line-and-allowance-sum)

- [BR-61: Identificativo conto richiesto per bonifico](/it/resources/kosit-validator-errors/br-61-credit-transfer-account-required)

- [BR-AE-02: Reverse charge richiede ID IVA venditore](/it/resources/kosit-validator-errors/br-ae-02-reverse-charge-seller-vat-id-required)

- [BR-AE-10: Ripartizione reverse charge richiede motivo esenzione](/it/resources/kosit-validator-errors/br-ae-10-reverse-charge-exemption-reason-required)

- [BR-E-01: Righe esenti richiedono ripartizione IVA esente](/it/resources/kosit-validator-errors/br-e-01-exempt-vat-breakdown-required)

- [BR-E-05: Aliquota IVA esente deve essere zero](/it/resources/kosit-validator-errors/br-e-05-exempt-vat-rate-must-be-zero)

- [BR-05: Il codice valuta della fattura deve essere presente](/it/resources/kosit-validator-errors/br-05-invoice-currency-code-must-be-present)

- [BR-22: Ogni riga deve contenere la quantità fatturata](/it/resources/kosit-validator-errors/br-22-invoice-line-quantity-must-be-present)

- [BR-23: Ogni quantità di riga deve avere un codice unità](/it/resources/kosit-validator-errors/br-23-invoice-line-unit-code-must-be-present)

- [BR-24: Ogni riga deve avere un importo netto](/it/resources/kosit-validator-errors/br-24-invoice-line-net-amount-must-be-present)

- [BR-25: Ogni riga deve contenere il nome articolo](/it/resources/kosit-validator-errors/br-25-invoice-line-item-name-must-be-present)

- [BR-26: Ogni riga deve contenere il prezzo netto dell’articolo](/it/resources/kosit-validator-errors/br-26-invoice-line-item-net-price-must-be-present)

- [BR-47: Ogni ripartizione IVA deve avere un codice categoria IVA](/it/resources/kosit-validator-errors/br-47-vat-breakdown-category-code-must-be-present)

- [BR-57: L’indirizzo di consegna deve includere il codice paese](/it/resources/kosit-validator-errors/br-57-delivery-country-code-must-be-present)

- [BR-DE-22: I nomi file degli allegati incorporati devono essere univoci](/it/resources/kosit-validator-errors/br-de-22-embedded-attachment-filenames-must-be-unique)

- [BR-DE-26: Le fatture rettificate dovrebbero riferirsi alla fattura precedente](/it/resources/kosit-validator-errors/br-de-26-corrected-invoice-should-reference-preceding-invoice)

- [BR-DE-27: Il telefono del venditore dovrebbe contenere almeno tre cifre](/it/resources/kosit-validator-errors/br-de-27-seller-phone-should-contain-three-digits)

- [BR-DE-28: L’e-mail del venditore dovrebbe avere forma di indirizzo e-mail](/it/resources/kosit-validator-errors/br-de-28-seller-email-should-be-shaped-like-email)

- [BR-DE-30: L’addebito diretto richiede l’identificativo creditore](/it/resources/kosit-validator-errors/br-de-30-direct-debit-requires-creditor-identifier)

- [BR-DE-31: L’addebito diretto richiede l’identificativo del conto addebitato](/it/resources/kosit-validator-errors/br-de-31-direct-debit-requires-debited-account)

- [PEPPOL-EN16931-R001: Il processo di business deve essere indicato](/it/resources/kosit-validator-errors/peppol-en16931-r001-business-process-must-be-present)

- [PEPPOL-EN16931-R010: L’indirizzo elettronico dell’acquirente deve essere indicato](/it/resources/kosit-validator-errors/peppol-en16931-r010-buyer-electronic-address-must-be-present)

- [PEPPOL-EN16931-R020: L’indirizzo elettronico del venditore deve essere indicato](/it/resources/kosit-validator-errors/peppol-en16931-r020-seller-electronic-address-must-be-present)

- [PEPPOL-EN16931-R046: Il prezzo netto deve essere prezzo lordo meno sconto](/it/resources/kosit-validator-errors/peppol-en16931-r046-net-price-must-match-gross-minus-allowance)

- [PEPPOL-EN16931-R120: Il netto riga deve rispettare la formula Peppol](/it/resources/kosit-validator-errors/peppol-en16931-r120-line-net-amount-formula)

- [PEPPOL-EN16931-R130: Il codice unità della base prezzo deve corrispondere all’unità fatturata](/it/resources/kosit-validator-errors/peppol-en16931-r130-price-base-unit-code-must-match-quantity-unit)

      

      ## Dettagli e soluzioni per ogni errore

      
        ### BR-DE-1: Una fattura tedesca deve includere l’indirizzo dell’acquirente

        In Germania è obbligatorio indicare l’indirizzo dell’acquirente in fattura secondo GoBD e normativa fiscale.

**Contesto:** Questa regola consente all’amministrazione fiscale di identificare il destinatario della fattura e verificare la transazione. La mancanza dell’indirizzo dell’acquirente può portare al rifiuto della fattura durante controlli fiscali.

**Come risolvere:** Aggiungi alla fattura l’indirizzo completo dell’acquirente (via, CAP, città e paese).

              Esempi validi

- Musterverkäufer GmbH, Musterstraße 123, 12345 Musterstadt, Germania
- ABC Corp., Hauptstr. 45, 80331 München, Germania

              Esempi non validi

- Indirizzo dell’acquirente completamente assente
- Solo il nome dell’acquirente senza dettagli dell’indirizzo

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-1-german-invoice-must-have-buyers-address)

### BR-DE-2: Il contatto del venditore deve essere indicato

        Le informazioni di contatto del venditore devono essere presenti in fattura.

**Contesto:** I destinatari (soprattutto la PA) usano i contatti del venditore per chiarire dubbi, risolvere incongruenze e accelerare i pagamenti. In pratica, la mancanza dei contatti provoca spesso rifiuti manuali o ritardi di elaborazione.

**Come risolvere:** Aggiungi in fattura le informazioni di contatto del venditore.

              Esempi validi

- Contatto: Max Mustermann, +49 30 1234567, invoice@company.example
- Email di contatto presente nel blocco contatto della parte venditrice

              Esempi non validi

- Nessun elemento Contact per la parte venditrice
- Solo un nome azienda generico senza un contatto email/telefono

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-2-seller-contact-must-be-provided)

### BR-DE-3: La città del venditore deve essere indicata

        La città del venditore deve essere presente in fattura.

**Contesto:** Un indirizzo postale completo è necessario per identificare in modo affidabile il venditore e garantire la tracciabilità/auditabilità. La città è una parte obbligatoria dell’indirizzo postale del venditore nei profili di validazione tedeschi.

**Come risolvere:** Aggiungi la città del venditore alla fattura.

              Esempi validi

- Berlin
- München
- Hamburg

              Esempi non validi

- Città assente
- Elemento  vuoto

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-3-seller-city-must-be-provided)

### BR-DE-4: Il CAP del venditore deve essere indicato

        Il codice postale (CAP) del venditore deve essere presente in fattura.

**Contesto:** La validazione tedesca richiede un indirizzo postale completo del venditore. Il CAP viene usato per la validazione dell’indirizzo e aiuta a evitare ambiguità tra nomi di città e località.

**Come risolvere:** Aggiungi il CAP del venditore alla fattura.

              Esempi validi

- 10115
- 80331
- 20095

              Esempi non validi

- CAP assente
- Elemento  vuoto

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-4-seller-postal-code-must-be-provided)

### BR-DE-5: Il paese del venditore deve essere indicato

        Il paese del venditore deve essere presente in fattura.

**Contesto:** Il codice paese del venditore deve essere presente e valido (di norma ISO 3166-1 alpha-2). È necessario per la gestione IVA transfrontaliera e per una validazione coerente degli indirizzi delle parti.

**Come risolvere:** Aggiungi il paese del venditore alla fattura.

              Esempi validi

- DE
- AT
- FR

              Esempi non validi

- Germania
- D
- DEU
- Codice paese vuoto

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-5-seller-country-must-be-provided)

### BR-DE-6: Il nome del venditore deve essere indicato

        Il nome del venditore deve essere presente in fattura.

**Contesto:** Il nome del venditore è necessario per identificare chiaramente l’emittente della fattura. Usa la denominazione legale registrata (incluse forme giuridiche come GmbH/AG) per evitare discrepanze con registri o dati contrattuali.

**Come risolvere:** Aggiungi il nome del venditore alla fattura.

              Esempi validi

- Mustermann GmbH
- ABC Technologies AG

              Esempi non validi

- Nome venditore assente
- Solo spazi

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-6-seller-name-must-be-provided)

### BR-DE-7: Il nome dell’acquirente deve essere indicato

        Il nome dell’acquirente deve essere presente in fattura.

**Contesto:** Il nome dell’acquirente è richiesto per identificare il destinatario della fattura. Per i destinatari della PA, usa la denominazione ufficiale dell’organizzazione registrata dall’ente/portale per evitare problemi di instradamento e approvazione.

**Come risolvere:** Aggiungi il nome dell’acquirente alla fattura.

              Esempi validi

- Bundesministerium XYZ
- Stadtverwaltung Musterstadt

              Esempi non validi

- Nome acquirente assente
- Solo un codice interno

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-7-buyer-name-must-be-provided)

### BR-DE-8: Deve essere indicato il codice data del momento di esigibilità IVA

        In fattura deve essere indicato il codice data del momento di esigibilità IVA.

**Contesto:** Se non puoi indicare una data IVA esplicita, alcuni profili consentono un codice che indica come viene determinata la data IVA (ad esempio in base alla data di emissione). Usa un valore valido per il profilo XRechnung/EN 16931 e mantienilo coerente con gli altri campi data.

**Come risolvere:** Aggiungi alla fattura il codice data del momento di esigibilità IVA.

              Esempi validi

- Un codice TaxPointDateCode valido definito dal tuo profilo

              Esempi non validi

- Codice data IVA mancante
- Codice non consentito dal profilo

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-8-value-added-tax-point-date-code-must-be-provided)

### BR-DE-9: Il codice valuta della fattura deve essere EUR

        Le fatture tedesche devono usare EUR come codice valuta per tutti gli importi monetari.

**Contesto:** Questa regola assicura la conformità alle norme fiscali tedesche e semplifica i controlli per l’amministrazione fiscale. Tutti i calcoli, le imposte e i totali devono essere in EUR.

**Come risolvere:** Converti tutti gli importi in EUR e imposta il codice valuta su EUR.

              Esempi validi

- Codice valuta: EUR
- Tutti gli importi in euro (€)

              Esempi non validi

- Codice valuta: USD
- Codice valuta: GBP
- Valute miste nella stessa fattura

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-9-invoice-currency-code-must-be-eur)

### BR-DE-10: Nessuna riga fattura per abbuoni o addebiti

        Le righe fattura non devono essere usate per abbuoni o addebiti.

**Contesto:** Gli abbuoni (sconti) e gli addebiti (maggiorazioni) devono essere rappresentati tramite le strutture dedicate AllowanceCharge. Codificare uno sconto come riga negativa (o un addebito come riga aggiuntiva) spesso altera i totali e viola le regole del profilo.

**Come risolvere:** Rimuovi le righe fattura usate per abbuoni o addebiti.

              Esempi validi

- AllowanceCharge a livello documento con ChargeIndicator=false e un importo
- AllowanceCharge a livello riga all’interno di InvoiceLine, dove consentito

              Esempi non validi

- InvoiceLine con quantità/importo negativo usata per rappresentare uno sconto
- Riga separata chiamata "Sconto" invece di AllowanceCharge

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-10-no-invoice-lines-for-allowances-or-charges)

### BR-DE-11: Devono essere indicate le condizioni di pagamento

        Le condizioni di pagamento devono essere presenti in fattura.

**Contesto:** Le condizioni di pagamento definiscono quando e come una fattura è pagabile (ad esempio scadenza a 14 giorni, condizioni di sconto o istruzioni di regolamento). La loro assenza può portare a chiarimenti manuali e pagamenti in ritardo.

**Come risolvere:** Aggiungi le condizioni di pagamento alla fattura.

              Esempi validi

- Pagabile entro 14 giorni netti
- 2% di sconto se pagato entro 10 giorni; altrimenti 30 giorni netti

              Esempi non validi

- Nessuna condizione di pagamento indicata
- Nota condizioni di pagamento vuota

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-11-payment-terms-must-be-provided)

### BR-DE-12: La fattura deve avere almeno una riga

        Una fattura deve contenere almeno una riga fattura.

**Contesto:** Una fattura senza righe non può essere validata in modo coerente e non rappresenta beni/servizi fatturabili. Anche se fatturi un solo totale, inserisci almeno una riga con il bene o servizio fatturato.

**Come risolvere:** Aggiungi almeno una riga fattura alla fattura.

              Esempi validi

- Una InvoiceLine che rappresenta un costo di servizio
- Più righe con articoli/servizi

              Esempi non validi

- Nessun elemento  presente

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-12-invoice-must-have-at-least-one-invoice-line)

### BR-DE-13: Il riferimento dell’acquirente deve essere indicato

        Il riferimento dell’acquirente deve essere presente in fattura.

**Contesto:** Molti destinatari della PA usano il riferimento dell’acquirente per instradare internamente la fattura (ufficio, centro di costo, riferimento ordine) e abbinarla al processo di acquisto. Se non hai un riferimento d’ordine, usa l’identificatore fornito dall’acquirente/portale.

**Come risolvere:** Aggiungi il riferimento dell’acquirente alla fattura.

              Esempi validi

- DEPT-4711
- PO-2025-000123
- Riferimento di instradamento fornito dall’acquirente

              Esempi non validi

- Riferimento acquirente mancante
- Uso di un riferimento interno del venditore al posto

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-13-buyer-reference-must-be-provided)

### BR-DE-14: Deve essere indicata la parte rappresentante fiscale del venditore

        In fattura deve essere indicata la parte rappresentante fiscale del venditore.

**Contesto:** In alcuni scenari IVA transfrontalieri, un venditore può nominare un rappresentante fiscale. Quando richiesto dal profilo o dalla transazione, la parte rappresentante fiscale deve essere inclusa affinché il destinatario possa validare responsabilità IVA e identificativi.

**Come risolvere:** Aggiungi alla fattura la parte rappresentante fiscale del venditore.

              Esempi validi

- Parte rappresentante fiscale con nome, indirizzo e, se applicabile, ID IVA/fiscale

              Esempi non validi

- Rappresentante fiscale richiesto ma completamente assente

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-14-seller-tax-representative-party-must-be-provided)

### BR-DE-15: Deve essere indicata la Leitweg-ID

        La Leitweg-ID (ID di instradamento) deve essere presente per identificare il percorso di trasmissione delle e‑fatture tedesche.

**Contesto:** La Leitweg-ID è richiesta dalle autorità tedesche per tracciare il percorso di trasmissione delle fatture elettroniche. Aiuta a garantire autenticità e integrità della fattura durante l’invio attraverso diversi sistemi.

**Come risolvere:** Aggiungi una Leitweg-ID valida nel formato "Leitweg-ID: [identificatore]" nell’intestazione della fattura.

              Esempi validi

- Leitweg-ID: 123456789012345678901234567890123456789012345678
- Leitweg-ID: DE123456789

              Esempi non validi

- Leitweg-ID completamente assente
- Leitweg-ID: (vuota)
- Formato o caratteri non validi

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-15-leitweg-id-must-be-provided)

### BR-DE-16: Deve essere indicato il tipo di processo aziendale

        In fattura deve essere indicato il tipo di processo aziendale.

**Contesto:** Il tipo di processo identifica quale processo/profilo segue la fattura. I destinatari lo usano per applicare le regole di validazione corrette. Usa il valore richiesto dal canale di consegna (portale/rete) e dal profilo XRechnung di destinazione.

**Come risolvere:** Aggiungi il tipo di processo aziendale alla fattura.

              Esempi validi

- Un ProfileID/identificatore di processo valido (di solito un URN) richiesto dal destinatario

              Esempi non validi

- Tipo di processo (ProfileID) mancante
- Uso di un valore di testo libero arbitrario

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-16-business-process-type-must-be-provided)

### BR-DE-17: Deve essere indicato l’identificatore dell’oggetto

        In fattura deve essere indicato l’identificatore dell’oggetto.

**Contesto:** Alcuni processi di acquisto richiedono un identificatore dell’oggetto fatturato (ad esempio un bene, un contatore o una pratica) per permettere al destinatario di abbinare la fattura all’oggetto corretto nei suoi sistemi.

**Come risolvere:** Aggiungi l’identificatore dell’oggetto alla fattura.

              Esempi validi

- OBJECT-12345
- METER-00001234
- ASSET-4711

              Esempi non validi

- Identificatore dell’oggetto mancante
- Uso di una descrizione al posto di un identificatore

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-17-object-identifier-must-be-provided)

### BR-DE-18: Devono essere indicati gli identificativi del venditore

        In fattura devono essere indicati gli identificativi del venditore.

**Contesto:** Questa regola indica in genere che il profilo di destinazione richiede attributi aggiuntivi di identificazione del venditore (ad esempio identificativi legali o di instradamento a seconda del canale di consegna). Assicurati che la parte venditrice includa tutti gli identificativi richiesti per il tuo scenario.

**Come risolvere:** Aggiungi gli identificativi del venditore alla fattura.

              Esempi validi

- Identificativi del venditore presenti come richiesto dal profilo (es. Partita IVA, ID registro imprese, endpoint ID)

              Esempi non validi

- Identificativi del venditore mancanti quando richiesti dal destinatario/profilo

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-18-seller-features-must-be-provided)

### BR-DE-19: Il conto SEPA deve contenere un IBAN valido

        Per bonifico SEPA, l’identificativo conto pagamento deve essere un IBAN sintatticamente valido.

**Contesto:** Molti export includono dati bancari come testo. I validatori attendono solo l’identificativo instradabile.

**Come risolvere:** Normalizza spazi, rimuovi etichette come IBAN: e salva solo il valore IBAN in BT-84.

              Esempi validi

- DE89370400440532013000

              Esempi non validi

- IBAN: DE89 3704 0044 0532 0130 00
- Conto corrente Example Bank

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-19-sepa-payment-account-must-be-valid-iban)

### BR-DE-20: Deve essere indicato il riferimento contratto

        In fattura deve essere indicato il riferimento al contratto.

**Contesto:** Nei processi di appalto pubblico, i riferimenti contrattuali sono spesso richiesti per abbinare le fatture ad accordi quadro o contratti. Usa l’identificatore esatto del contratto fornito dall’acquirente/ente.

**Come risolvere:** Aggiungi il riferimento contratto alla fattura.

              Esempi validi

- CON-2024-00077
- Riferimento all’accordo quadro

              Esempi non validi

- Riferimento contratto mancante

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-20-contract-reference-must-be-provided)

### BR-DE-21: Deve essere indicato l’identificatore della specifica

        In fattura deve essere indicato l’identificatore della specifica.

**Contesto:** L’identificatore della specifica (spesso CustomizationID) indica al destinatario quale insieme di regole applicare (ad esempio una specifica versione/profilo XRechnung). Senza di esso, i validatori non possono selezionare in modo affidabile le regole schematron corrette.

**Come risolvere:** Aggiungi l’identificatore della specifica alla fattura.

              Esempi validi

- Un CustomizationID/identificatore di specifica valido richiesto dal destinatario e dalla versione XRechnung

              Esempi non validi

- Identificatore di specifica (CustomizationID) mancante

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-21-specification-identifier-must-be-provided)

### BR-CO-3: Data di esigibilità IVA e codice data di esigibilità si escludono a vicenda

        La data di esigibilità IVA (BT-7) e il codice della data di esigibilità IVA (BT-8) non possono coesistere nella stessa fattura. Utilizzane esattamente uno.

**Contesto:** EN 16931 consente di indicare il momento di esigibilità IVA come data esplicita o come riferimento codificato (ad esempio la data di consegna). Indicare entrambi renderebbe la rendicontazione fiscale ambigua e comprometterebbe la riconciliazione contabile.

**Come risolvere:** Rimuovi BT-7 oppure BT-8 in modo che resti un solo indicatore del momento di esigibilità IVA.

              Esempi validi

- BT-7 = 2026-03-31, BT-8 assente
- BT-8 = 3 (data fattura), BT-7 assente

              Esempi non validi

- BT-7 = 2026-03-31 e BT-8 = 35 valorizzati insieme
- Sia data sia codice di esigibilità IVA presenti nella stessa ripartizione IVA

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-co-3-vat-point-date-and-code-mutually-exclusive)

### BR-CO-4: Ogni riga di fattura deve avere un codice categoria IVA

        Ogni riga di fattura (BG-25) deve riportare un codice categoria IVA dell’articolo fatturato (BT-151), in modo da poter essere assegnata a una ripartizione IVA.

**Contesto:** Senza un codice categoria per riga, il validatore non può riconciliare gli importi imponibili di riga con la ripartizione IVA a livello documento (BG-23). È il presupposto di tutti i controlli BR-S, BR-Z, BR-E e BR-AE.

**Come risolvere:** Aggiungi BT-151 (ad esempio "S" per aliquota standard, "Z" per aliquota zero, "AE" per inversione contabile) a ogni riga.

              Esempi validi

- Riga 1 BT-151 = "S" con BT-152 = 19
- Riga 2 BT-151 = "Z" (aliquota zero) con BT-152 = 0

              Esempi non validi

- Riga di fattura senza elemento ClassifiedTaxCategory
- Riga di fattura con BT-151 vuoto

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-co-4-each-invoice-line-must-have-vat-category-code)

### BR-CO-9: Le partite IVA devono avere un prefisso paese ISO 3166-1 alpha-2

        Le partite IVA del venditore (BT-31), del rappresentante fiscale del venditore (BT-63) e dell’acquirente (BT-48) devono iniziare con un codice paese ISO 3166-1 alpha-2 (ad esempio "DE", "FR", "IT").

**Contesto:** Gli access point Peppol e il controllo VIES dell’UE si basano sul prefisso paese per instradare la fattura e validare la partita IVA presso il registro nazionale corretto. Senza prefisso, la consegna Peppol e l’interrogazione VIES falliscono prima che l’acquirente veda la fattura.

**Come risolvere:** Anteponi a ogni partita IVA il codice paese a due lettere corretto, ad esempio "DE123456789" invece di "123456789".

              Esempi validi

- BT-31 = "DE123456789"
- BT-48 = "FR12345678901"
- BT-63 = "IT12345678901"

              Esempi non validi

- BT-31 = "123456789" (manca il prefisso DE)
- BT-48 = "GERMANY-123" (prefisso non ISO)
- BT-63 = "EU123456789" (EU non è un codice ISO 3166-1 alpha-2)

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-co-9-vat-identifier-must-have-iso-country-prefix)

### BR-CO-10: La somma degli importi netti di riga deve coincidere con il totale dei netti di riga

        Il totale dei netti di riga a livello documento (BT-106) deve essere uguale alla somma aritmetica di tutti gli importi netti di riga (BT-131).

**Contesto:** Discrepanze nei totali di riga sono una delle cause di rifiuto più frequenti quando un ERP esporta XML senza allineare gli arrotondamenti. I portali della PA rifiutano il file prima di ogni revisione manuale.

**Come risolvere:** Ricalcola BT-106 partendo dai netti di riga effettivi e riporta il nuovo valore nell’intestazione della fattura.

              Esempi validi

- Righe 100,00 + 50,00 + 25,00 producono BT-106 = 175,00
- Riga unica da 99,99 produce BT-106 = 99,99

              Esempi non validi

- Righe somma 175,00 ma BT-106 = 174,99 (deriva di arrotondamento)
- BT-106 lasciato a 0,00 con righe presenti

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-co-10-sum-of-line-net-amounts-must-equal-line-total)

### BR-CO-11: La somma degli sconti a livello documento deve coincidere con il totale di tutti gli sconti

        La somma degli sconti a livello documento (BT-107) deve coincidere con la somma aritmetica di tutti gli importi di sconto a livello documento (BT-92).

**Contesto:** Gli sconti a livello documento devono conciliarsi affinché BR-CO-13 (catena dei totali) regga. Un solo sconto dimenticato fa rifiutare l’intero blocco dei totali.

**Come risolvere:** Ricalcola BT-107 sommando ogni BT-92 nel gruppo degli sconti a livello documento.

              Esempi validi

- Due sconti BT-92 da 5,00 e 10,00 producono BT-107 = 15,00
- Nessuno sconto a livello documento e BT-107 = 0,00 (o assente)

              Esempi non validi

- BT-107 = 10,00 ma l’unico BT-92 nel documento è 15,00
- BT-107 assente con BT-92 presenti

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-co-11-sum-of-document-allowances-must-match)

### BR-CO-13: Il totale fattura IVA esclusa deve essere uguale al totale righe meno gli sconti più gli oneri

        Il totale fattura IVA esclusa (BT-109) deve essere uguale al totale dei netti di riga (BT-106) meno gli sconti a livello documento (BT-107) più gli oneri a livello documento (BT-108).

**Contesto:** BR-CO-13 è la regola centrale della catena dei totali. Se fallisce, falliscono anche tutte le regole successive (BR-CO-15, BR-CO-16). I rifiuti reali derivano spesso da arrotondamenti diversi tra motore riga e motore totali.

**Come risolvere:** Ricalcola BT-109 = BT-106 − BT-107 + BT-108 e riporta il risultato nel blocco dei totali.

              Esempi validi

- BT-106 = 200,00, BT-107 = 10,00, BT-108 = 5,00 → BT-109 = 195,00
- BT-106 = 100,00, nessuno sconto o onere → BT-109 = 100,00

              Esempi non validi

- BT-106 = 200,00, BT-107 = 10,00, BT-108 = 5,00 ma BT-109 = 200,00
- BT-109 lasciato pari a BT-106 nonostante BT-107 > 0

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-co-13-invoice-total-without-vat-must-match-totals-chain)

### BR-CO-14: Il totale IVA della fattura deve essere uguale alla somma degli importi IVA per categoria

        L’importo totale IVA (BT-110) deve essere uguale alla somma aritmetica di tutti gli importi IVA per categoria (BT-117) presenti nella ripartizione IVA.

**Contesto:** Le autorità fiscali riconciliano l’importo IVA di testata con la ripartizione per categoria. Una differenza indica una riga mancante o un errore di arrotondamento ed è considerata errore bloccante.

**Come risolvere:** Ricalcola BT-110 sommando ogni BT-117 (uno per ogni combinazione categoria/aliquota) prima dell’esportazione.

              Esempi validi

- Due importi BT-117 da 19,00 e 7,00 producono BT-110 = 26,00
- BT-117 unico = 38,00 produce BT-110 = 38,00

              Esempi non validi

- BT-110 = 26,00 ma la ripartizione somma 25,99
- BT-110 = 19,00 con due righe BT-117 da 19,00 e 7,00

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-co-14-invoice-total-vat-must-equal-sum-of-vat-categories)

### BR-CO-15: Il totale fattura IVA inclusa deve essere uguale al totale IVA esclusa più l’imposta totale

        Il totale fattura IVA inclusa (BT-112) deve essere uguale al totale fattura IVA esclusa (BT-109) più l’imposta totale (BT-110). Importi non quadrati sono la causa di rifiuto più frequente.

**Contesto:** I destinatari della PA (ZRE, OZG-RE) rifiutano automaticamente le fatture con totali di testata non quadrati, perché di solito indicano un errore di trasferimento dati tra ERP e convertitore.

**Come risolvere:** Ricalcola BT-112 = BT-109 + BT-110 utilizzando la stessa regola di arrotondamento del blocco totali.

              Esempi validi

- BT-109 = 100,00, BT-110 = 19,00 → BT-112 = 119,00
- BT-109 = 84,03, BT-110 = 15,97 → BT-112 = 100,00

              Esempi non validi

- BT-109 = 100,00, BT-110 = 19,00 ma BT-112 = 118,99
- BT-112 = BT-109 (IVA dimenticata nel totale lordo)

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-co-15-invoice-total-with-vat-must-match)

### BR-CO-16: L’importo da pagare deve essere uguale al totale IVA inclusa meno gli acconti più l’arrotondamento

        L’importo da pagare (BT-115) deve essere uguale al totale fattura IVA inclusa (BT-112) meno l’importo già pagato (BT-113) più l’importo di arrotondamento (BT-114).

**Contesto:** Acconti e aggiustamenti di arrotondamento sono la fonte tipica di errori. Gli ERP spesso non riportano l’importo già pagato nell’export e-fattura.

**Come risolvere:** Ricalcola BT-115 = BT-112 − BT-113 + BT-114 considerando come zero BT-113 e BT-114 quando assenti.

              Esempi validi

- BT-112 = 119,00, BT-113 = 50,00, BT-114 = 0,00 → BT-115 = 69,00
- BT-112 = 100,00, BT-113 assente, BT-114 = 0,01 → BT-115 = 100,01

              Esempi non validi

- BT-115 = BT-112 nonostante BT-113 = 50,00 di acconto
- BT-115 ignora l’arrotondamento BT-114 = 0,02

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-co-16-amount-due-for-payment-must-match)

### BR-CO-17: L’importo IVA per categoria deve essere uguale alla base imponibile per l’aliquota diviso 100

        L’importo IVA per categoria (BT-117) deve essere uguale alla base imponibile (BT-116) moltiplicata per l’aliquota IVA (BT-119) divisa per 100, arrotondata a due decimali.

**Contesto:** La regola viene verificata per ogni riga della ripartizione. La causa tipica di errore è la divergenza tra arrotondamento commerciale e bancario fra ERP e convertitore.

**Come risolvere:** Ricalcola ogni BT-117 come round(BT-116 × BT-119 / 100, 2) con la modalità di arrotondamento attesa dal destinatario (arrotondamento commerciale per la PA tedesca).

              Esempi validi

- BT-116 = 100,00, BT-119 = 19 → BT-117 = 19,00
- BT-116 = 84,03, BT-119 = 19 → BT-117 = 15,97

              Esempi non validi

- BT-116 = 100,00, BT-119 = 19 ma BT-117 = 19,01
- BT-117 lasciato a 0,00 con BT-116 e BT-119 non nulli

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-co-17-vat-category-tax-amount-must-match-base-times-rate)

### BR-CO-25: Se l’importo da pagare è positivo serve la data di scadenza o le condizioni di pagamento

        Se l’importo da pagare (BT-115) è maggiore di zero, deve essere presente la data di scadenza (BT-9) oppure le condizioni di pagamento (BT-20).

**Contesto:** Senza data di scadenza o termini scritti la contabilità fornitori dell’acquirente non può pianificare il pagamento, con conseguenti scadenze mancate e contestazioni su mora.

**Come risolvere:** Aggiungi BT-9 (data di scadenza) oppure BT-20 (termini testuali come "30 giorni") quando esiste un saldo positivo da incassare.

              Esempi validi

- BT-115 = 119,00, BT-9 = 2026-05-30
- BT-115 = 119,00, BT-20 = "Pagabile entro 14 giorni netti"

              Esempi non validi

- BT-115 = 119,00 senza BT-9 né BT-20
- BT-115 > 0 con BT-9 vuoto e BT-20 anch’esso vuoto

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-co-25-positive-amount-due-needs-payment-due-date-or-terms)

### BR-CO-26: Il venditore deve essere identificabile tramite un identificativo, un codice di registrazione o la partita IVA

        Per permettere all’acquirente di identificare automaticamente il fornitore, deve essere presente almeno uno tra identificativo del venditore (BT-29), codice di registrazione legale (BT-30) o partita IVA (BT-31).

**Contesto:** Gli ERP degli acquirenti abbinano i fornitori in automatico tramite questi identificativi. In assenza, la fattura finisce in coda manuale e il pagamento viene ritardato.

**Come risolvere:** Compila almeno uno tra BT-29, BT-30 o BT-31 nel blocco della parte venditrice.

              Esempi validi

- BT-31 = "DE123456789"
- BT-30 = "HRB 12345"
- BT-29 = "GLN 4012345000094"

              Esempi non validi

- Parte venditrice con solo nome e indirizzo, BT-29/BT-30/BT-31 tutti assenti
- BT-31 rimosso perché venditore non soggetto IVA, ma anche BT-30 mancante

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-co-26-seller-must-be-identifiable)

### BR-S-1: Le righe ad aliquota standard richiedono una corrispondente riga nella ripartizione IVA

        Se una riga, uno sconto o un onere a livello documento è ad aliquota standard (codice categoria IVA "S"), la ripartizione IVA (BG-23) deve contenere almeno una riga con codice "S".

**Contesto:** Una riga ad aliquota standard senza ripartizione corrispondente lascia la base imponibile non dichiarata; destinatari e fisco lo considerano dato mancante.

**Come risolvere:** Aggiungi una riga di ripartizione IVA con BT-118 = "S" e l’aliquota corretta prima dell’esportazione.

              Esempi validi

- Riga BT-151 = "S" più riga di ripartizione BT-118 = "S", BT-119 = 19
- Sconto documento BT-95 = "S" più riga di ripartizione corrispondente

              Esempi non validi

- Riga BT-151 = "S" ma la ripartizione contiene solo righe "Z"
- Onere documento BT-102 = "S" senza riga "S" nella ripartizione

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-s-1-standard-rated-line-requires-standard-rated-vat-breakdown)

### BR-S-5: L’aliquota IVA in una ripartizione ad aliquota standard deve essere maggiore di zero

        In ogni riga di ripartizione IVA (BG-23) con codice categoria (BT-118) "S" (aliquota standard), l’aliquota IVA (BT-119) deve essere maggiore di zero.

**Contesto:** Aliquota zero con codice "S" è contraddittoria. Se la fornitura è effettivamente esente o ad aliquota zero, va usato il codice "Z" o "E" per classificare correttamente la ripartizione.

**Come risolvere:** Imposta BT-119 sull’aliquota positiva applicabile (ad esempio 19 in Germania, 22 in Italia) quando BT-118 vale "S".

              Esempi validi

- BT-118 = "S", BT-119 = 22
- BT-118 = "S", BT-119 = 10

              Esempi non validi

- BT-118 = "S", BT-119 = 0
- BT-118 = "S", BT-119 assente

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-s-5-standard-rated-vat-breakdown-rate-must-be-positive)

### BR-S-8: La base imponibile ad aliquota standard deve essere uguale ai netti di riga più gli oneri meno gli sconti alla stessa aliquota

        Per ogni aliquota standard distinta (BT-119), la base imponibile (BT-116) nella ripartizione IVA deve essere uguale alla somma dei netti di riga (BT-131) più gli oneri a livello documento (BT-99) meno gli sconti a livello documento (BT-92) con codice IVA "S" e aliquota coincidente.

**Contesto:** Su fatture con aliquote miste (ad esempio 4%, 10% e 22% in Italia), le basi imponibili per aliquota devono coincidere con le righe sottostanti. Sono il presupposto del calcolo IVA in BR-CO-17.

**Come risolvere:** Raggruppa tutte le righe, gli sconti e gli oneri "S" per aliquota e ricalcola BT-116 per gruppo come Σ BT-131 + Σ BT-99 − Σ BT-92.

              Esempi validi

- Due righe al 22% (60,00 + 40,00) e uno sconto al 22% (10,00) producono BT-116 = 90,00 per la riga 22%
- Riga unica al 10% con netto 50,00 produce BT-116 = 50,00 per la riga 10%

              Esempi non validi

- BT-116 della riga 22% riporta 100,00 ma le righe al netto degli sconti fanno 90,00
- BT-116 della riga 10% mancante con righe al 10% presenti

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-s-8-standard-rated-taxable-amount-must-match-line-and-allowance-sum)

### BR-61: Identificativo conto richiesto per bonifico

        Quando il mezzo di pagamento indica bonifico, deve essere presente l’identificativo del conto beneficiario (BT-84).

**Contesto:** I validatori non possono gestire un bonifico senza conto, anche se i termini di pagamento sono completi.

**Come risolvere:** Aggiungi cac:PayeeFinancialAccount/cbc:ID in UBL o il campo CII equivalente, di solito un IBAN per bonifico SEPA.

              Esempi validi

- PaymentMeansCode 58 con PayeeFinancialAccount ID DE89370400440532013000

              Esempi non validi

- PaymentMeansCode 58 senza conto beneficiario

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-61-credit-transfer-account-required)

### BR-AE-02: Reverse charge richiede ID IVA venditore

        Categorie IVA reverse charge su righe o totali richiedono l’ID IVA del venditore.

**Contesto:** Il reverse charge sposta l’obbligo fiscale; i sistemi riceventi devono verificare l’identità fiscale del venditore.

**Come risolvere:** Aggiungi la registrazione IVA venditore e mantieni il codice reverse charge su righe e ripartizione IVA.

              Esempi validi

- PartyTaxScheme venditore CompanyID DE123456789 con categoria IVA AE

              Esempi non validi

- Categoria IVA AE senza registrazione IVA venditore

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-ae-02-reverse-charge-seller-vat-id-required)

### BR-AE-10: Ripartizione reverse charge richiede motivo esenzione

        Una ripartizione IVA reverse charge deve includere codice o testo del motivo di esenzione.

**Contesto:** L’acquirente necessita di un motivo leggibile o codificato per capire perché l’IVA non è addebitata.

**Come risolvere:** Aggiungi cbc:TaxExemptionReasonCode con codice VATEX valido o testo cbc:TaxExemptionReason sulla categoria AE.

              Esempi validi

- Categoria IVA AE con codice VATEX VATEX-EU-AE

              Esempi non validi

- Categoria IVA AE senza codice o testo motivo esenzione

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-ae-10-reverse-charge-exemption-reason-required)

### BR-E-01: Righe esenti richiedono ripartizione IVA esente

        Se una riga usa categoria IVA E, la ripartizione IVA documento deve contenere un subtotale E.

**Contesto:** Categorie IVA di riga e ripartizione documento devono riconciliarsi per verificare le basi imponibili.

**Come risolvere:** Aggiungi subtotale IVA categoria E con imponibile, imposta zero, percentuale zero e motivo esenzione.

              Esempi validi

- Categoria IVA riga E più TaxSubtotal documento con TaxCategory ID E

              Esempi non validi

- Riga categoria IVA E ma presente solo ripartizione standard

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-e-01-exempt-vat-breakdown-required)

### BR-E-05: Aliquota IVA esente deve essere zero

        La categoria IVA E deve usare aliquota zero su righe e ripartizioni.

**Contesto:** Una categoria esente con aliquota non zero è contraddittoria e crea totali incoerenti.

**Come risolvere:** Imposta Percent a 0 per categoria E e mantieni la base nella ripartizione esente.

              Esempi validi

- Categoria IVA E con Percent 0

              Esempi non validi

- Categoria IVA E con Percent 19

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-e-05-exempt-vat-rate-must-be-zero)

### BR-05: Il codice valuta della fattura deve essere presente

        La fattura deve contenere il codice valuta (BT-5), ad esempio EUR, così ogni importo viene interpretato in modo coerente.

**Contesto:** BT-5 è un campo base EN 16931. Senza valuta falliscono i controlli su IVA, pagamento e righe prima delle regole di profilo.

**Come risolvere:** Imposta BT-5 sul codice ISO 4217 usato per totali e righe.

              Esempi validi

- BT-5 = EUR
- DocumentCurrencyCode = USD per una fattura in USD

              Esempi non validi

- BT-5 assente
- Valuta scritta come testo libero fuori dal campo XML

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-05-invoice-currency-code-must-be-present)

### BR-22: Ogni riga deve contenere la quantità fatturata

        Ogni riga fattura (BG-25) deve includere la quantità fatturata (BT-129).

**Contesto:** La quantità serve per BT-131 e per regole Peppol come PEPPOL-EN16931-R120.

**Come risolvere:** Aggiungi BT-129 a ogni riga e mantienilo coerente con il calcolo del netto riga.

              Esempi validi

- BT-129 = 2
- BT-129 = 1,5 per ore di servizio

              Esempi non validi

- Riga presente ma quantità vuota
- Quantità nel PDF non trasferita in XML

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-22-invoice-line-quantity-must-be-present)

### BR-23: Ogni quantità di riga deve avere un codice unità

        Una riga fattura (BG-25) deve contenere il codice unità della quantità fatturata (BT-130).

**Contesto:** I codici unità sono valori controllati. Testo libero come “pezzi” o “ore” fallisce anche se la quantità è presente.

**Come risolvere:** Imposta BT-130 su un codice valido, ad esempio C62 per pezzo, HUR per ora o DAY per giorno.

              Esempi validi

- BT-130 = C62
- BT-130 = HUR

              Esempi non validi

- BT-130 assente
- Unità scritta “pezzo” invece di C62

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-23-invoice-line-unit-code-must-be-present)

### BR-24: Ogni riga deve avere un importo netto

        Ogni riga fattura (BG-25) deve contenere l’importo netto di riga (BT-131).

**Contesto:** BT-131 alimenta BR-CO-10 e la riconciliazione IVA. Netti riga mancanti generano spesso più errori di totale.

**Come risolvere:** Calcola BT-131 da quantità, prezzo unitario e sconti/addebiti di riga, poi arrotonda secondo il profilo.

              Esempi validi

- BT-131 = 200,00 per 2 x 100,00

              Esempi non validi

- Importo riga assente
- Netto riga 0,00 con quantità e prezzo presenti

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-24-invoice-line-net-amount-must-be-present)

### BR-25: Ogni riga deve contenere il nome articolo

        Ogni riga fattura (BG-25) deve contenere il nome articolo (BT-153).

**Contesto:** BT-153 è richiesto anche con codici articolo. I soli codici non bastano per EN 16931.

**Come risolvere:** Mappa la descrizione prodotto o servizio della fattura sorgente in BT-153 per ogni riga.

              Esempi validi

- BT-153 = Servizi di consulenza marzo 2026

              Esempi non validi

- Nome articolo vuoto
- Solo SKU 4711 senza nome

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-25-invoice-line-item-name-must-be-present)

### BR-26: Ogni riga deve contenere il prezzo netto dell’articolo

        Ogni riga fattura (BG-25) deve contenere il prezzo netto dell’articolo (BT-146).

**Contesto:** Fonti con solo prezzo lordo richiedono derivazione deterministica del netto. BT-146 mancante blocca le validazioni di riga e Peppol.

**Come risolvere:** Indica il prezzo unitario netto prima IVA in BT-146 e allinealo a quantità e netto riga.

              Esempi validi

- BT-146 = 100,00 prima IVA

              Esempi non validi

- BT-146 assente
- Prezzo lordo copiato in BT-146 senza scorporare IVA

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-26-invoice-line-item-net-price-must-be-present)

### BR-47: Ogni ripartizione IVA deve avere un codice categoria IVA

        Ogni ripartizione IVA (BG-23) deve essere definita tramite un codice categoria IVA (BT-118).

**Contesto:** BT-118 determina quale famiglia di regole IVA si applica. Un valore irrisolto può produrre XML errato; il backend blocca invece di indovinare.

**Come risolvere:** Imposta BT-118 su ogni subtotale IVA, ad esempio S, Z, E, AE o O, e allinealo alle righe.

              Esempi validi

- BT-118 = S con BT-119 = 19

              Esempi non validi

- Ripartizione IVA senza BT-118
- Categoria IVA vuota dopo OCR

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-47-vat-breakdown-category-code-must-be-present)

### BR-57: L’indirizzo di consegna deve includere il codice paese

        Ogni indirizzo di consegna (BG-15) deve contenere il codice paese di consegna (BT-80).

**Contesto:** Il paese di consegna influenza IVA e profilo. Un indirizzo parziale senza paese non è dato strutturato valido.

**Come risolvere:** Aggiungi BT-80 come codice paese ISO 3166-1 alpha-2 quando sono presenti dati di consegna.

              Esempi validi

- BT-80 = DE
- BT-80 = FR

              Esempi non validi

- Via e città di consegna presenti senza paese
- Paese scritto Germania invece di DE

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-57-delivery-country-code-must-be-present)

### BR-DE-22: I nomi file degli allegati incorporati devono essere univoci

        XRechnung richiede che ogni attributo filename dei documenti incorporati sia univoco nella fattura.

**Contesto:** Nomi allegato duplicati rendono ambiguo il trattamento e possono causare rifiuti dai portali destinatari.

**Come risolvere:** Rinomina gli allegati duplicati prima dell’export, ad esempio terms.pdf e timesheet.pdf invece di due attachment.pdf.

              Esempi validi

- condizioni-fattura.pdf e documento-consegna.pdf

              Esempi non validi

- Due file incorporati chiamati attachment.pdf

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-22-embedded-attachment-filenames-must-be-unique)

### BR-DE-26: Le fatture rettificate dovrebbero riferirsi alla fattura precedente

        Quando BT-3 è 384 per una fattura rettificata, XRechnung si aspetta almeno un riferimento alla fattura precedente (BG-3).

**Contesto:** La regola è un warning nel bundle XRechnung fissato, ma i destinatari spesso richiedono il riferimento originale.

**Come risolvere:** Aggiungi numero e data della fattura originale in BG-3 prima dell’export.

              Esempi validi

- BT-3 = 384 e BG-3 riferisce INV-2026-001

              Esempi non validi

- Fattura rettificata senza BG-3

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-26-corrected-invoice-should-reference-preceding-invoice)

### BR-DE-27: Il telefono del venditore dovrebbe contenere almeno tre cifre

        XRechnung avvisa quando il telefono venditore (BT-42) contiene meno di tre cifre.

**Contesto:** I contatti venditore aiutano i destinatari pubblici a risolvere domande senza rifiutare subito il documento.

**Come risolvere:** Fornisci un numero reale con cifre o rimuovi placeholder non validi.

              Esempi validi

- BT-42 = +49 30 123456

              Esempi non validi

- BT-42 = --
- BT-42 = x

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-27-seller-phone-should-contain-three-digits)

### BR-DE-28: L’e-mail del venditore dovrebbe avere forma di indirizzo e-mail

        XRechnung avvisa se l’e-mail venditore (BT-43) non contiene esattamente una @ con caratteri validi intorno.

**Contesto:** Un indirizzo di contatto plausibile riduce i chiarimenti manuali con destinatari pubblici.

**Come risolvere:** Usa un indirizzo raggiungibile come fatture@example.com e rimuovi spazi, punti finali o placeholder.

              Esempi validi

- BT-43 = fatture@example.com

              Esempi non validi

- BT-43 = fatture@
- BT-43 = fatture.example.com

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-28-seller-email-should-be-shaped-like-email)

### BR-DE-30: L’addebito diretto richiede l’identificativo creditore

        Quando sono presenti istruzioni di addebito diretto (BG-19), va fornito anche BT-90 identificativo creditore.

**Contesto:** I dati di addebito devono essere completi perché l’acquirente autorizza l’incasso per un creditore e mandato specifici.

**Come risolvere:** Aggiungi l’identificativo creditore SEPA in BT-90 oppure cambia mezzo di pagamento se non c’è addebito diretto.

              Esempi validi

- Mezzo addebito diretto con BT-90 = DE98ZZZ09999999999

              Esempi non validi

- Addebito diretto selezionato ma BT-90 assente

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-30-direct-debit-requires-creditor-identifier)

### BR-DE-31: L’addebito diretto richiede l’identificativo del conto addebitato

        Quando sono presenti istruzioni di addebito diretto (BG-19), va fornito anche BT-91 identificativo del conto addebitato.

**Contesto:** L’addebito diretto non può essere elaborato correttamente senza identificare il conto addebitato.

**Come risolvere:** Aggiungi in BT-91 l’identificativo conto dell’acquirente per addebito diretto, oppure usa bonifico.

              Esempi validi

- Addebito diretto con BT-91 = DE89370400440532013000

              Esempi non validi

- Addebito diretto selezionato ma BT-91 assente

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/br-de-31-direct-debit-requires-debited-account)

### PEPPOL-EN16931-R001: Il processo di business deve essere indicato

        Peppol richiede l’identificativo del processo di business (BT-23 / ProfileID).

**Contesto:** BT-23 indica agli access point Peppol quali regole applicare. Valori mancanti bloccano routing e validazione.

**Come risolvere:** Imposta BT-23 sull’identificativo processo Peppol richiesto dal profilo del destinatario.

              Esempi validi

- BT-23 / ProfileID contiene l’URN del processo Peppol billing

              Esempi non validi

- ProfileID assente
- BT-23 copiato da CustomizationID

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/peppol-en16931-r001-business-process-must-be-present)

### PEPPOL-EN16931-R010: L’indirizzo elettronico dell’acquirente deve essere indicato

        Peppol richiede l’indirizzo elettronico acquirente (BT-49) per il routing.

**Contesto:** Senza identificativo endpoint destinatario Peppol non può instradare la fattura.

**Come risolvere:** Aggiungi BT-49 con identificativo destinatario e scheme, ad esempio Peppol participant ID.

              Esempi validi

- BT-49 presente con schemeID

              Esempi non validi

- Endpoint acquirente assente
- Valore senza schemeID

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/peppol-en16931-r010-buyer-electronic-address-must-be-present)

### PEPPOL-EN16931-R020: L’indirizzo elettronico del venditore deve essere indicato

        Peppol richiede l’indirizzo elettronico venditore (BT-34).

**Contesto:** Gli indirizzi elettronici di venditore e acquirente identificano entrambi i partecipanti Peppol.

**Come risolvere:** Aggiungi BT-34 con identificativo endpoint venditore e scheme coerente.

              Esempi validi

- BT-34 presente con schemeID

              Esempi non validi

- Endpoint venditore assente
- Valore senza schemeID

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/peppol-en16931-r020-seller-electronic-address-must-be-present)

### PEPPOL-EN16931-R046: Il prezzo netto deve essere prezzo lordo meno sconto

        Quando è fornito un prezzo lordo, Peppol richiede che il netto sia lordo meno sconto.

**Contesto:** La regola intercetta scostamenti lordo-netto da conversioni PDF prima dei totali riga.

**Come risolvere:** Ricalcola BT-146 da prezzo lordo e sconto prezzo, oppure rimuovi dettagli lordi non affidabili.

              Esempi validi

- Lordo 120,00 meno sconto 20,00 dà BT-146 = 100,00

              Esempi non validi

- Lordo 120,00, sconto 20,00, BT-146 = 119,00

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/peppol-en16931-r046-net-price-must-match-gross-minus-allowance)

### PEPPOL-EN16931-R120: Il netto riga deve rispettare la formula Peppol

        Peppol richiede che BT-131 sia quantità per prezzo netto, corretto da addebiti e sconti di riga.

**Contesto:** È un rifiuto frequente quando l’estrazione PDF arrotonda troppo presto o perde sconti di riga.

**Come risolvere:** Ricalcola i netti riga da BT-129, BT-146, quantità base prezzo, addebiti e sconti, poi aggiorna BT-131.

              Esempi validi

- 2 x 100,00 meno 10,00 sconto dà BT-131 = 190,00

              Esempi non validi

- La formula dà 190,00 ma BT-131 = 189,99

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/peppol-en16931-r120-line-net-amount-formula)

### PEPPOL-EN16931-R130: Il codice unità della base prezzo deve corrispondere all’unità fatturata

        Peppol richiede che il codice unità della quantità base prezzo coincida con quello della quantità fatturata.

**Contesto:** Unità miste rendono ambiguo il calcolo prezzo e compaiono spesso in export ERP.

**Come risolvere:** Usa lo stesso codice unità per BT-130 e quantità base prezzo, oppure ricalcola il prezzo sull’unità fatturata.

              Esempi validi

- BT-130 = HUR e unità base prezzo = HUR

              Esempi non validi

- BT-130 = HUR ma unità base prezzo = C62

            
        [Apri la guida dettagliata →](/it/resources/kosit-validator-errors/peppol-en16931-r130-price-base-unit-code-must-match-quantity-unit)

*Ultimo aggiornamento: gennaio 2026 | Versione: XRechnung 3.0.2, ZUGFeRD 2.4*

        ## Come usare questa guida

        Usa l’articolo come punto di partenza prima di modificare un workflow finance o ERP: identifica la regola nazionale o lo standard applicabile, scegli il formato strutturato richiesto, valida l’XML generato e mantieni un processo di eccezione documentato per le fatture che richiedono revisione manuale.