Libreria di file di esempio
File SEPA, camt.053, UBL, MT940 e Factur-X pronti all’uso: validi da cui partire, rotti di proposito per fare test. Ogni file è verificato dal validatore a cui appartiene.
File di esempio SEPA e fatturazione elettronica
File SEPA, camt.053, UBL, MT940 e Factur-X pronti all’uso: validi da cui partire, rotti di proposito per fare test. Ogni file è verificato dal validatore a cui appartiene.
129
File di esempio
92
Valido
37
Non valido
Bonifico SEPA (pain.001) (12)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| pain.001.001.03 — valid credit transferUn bonifico SEPA valido in pain.001.001.03: tre bonifici per 1.580,00 EUR, totali di controllo coerenti, IBAN che superano il mod-97 e nomi nel set di caratteri SEPA di base. | Valido | |
| pain.001.001.09 — valid, hybrid addressUn bonifico pain.001.001.09 valido, con BICFI e l’indirizzo postale ibrido consentito da EPC153-22 v2.1: TwnNm e Ctry, più al massimo due AdrLine di 70 caratteri o meno. | Valido | |
| pain.001.001.03 — CtrlSum mismatchUn pain.001 con somma di controllo errata: CtrlSum dichiara 1.000,00 EUR mentre le transazioni ammontano a 1.500,00 EUR. Lo scarto viene segnalato due volte, sul lotto di pagamento e sull’intestazione del file. | Non valido | |
| pain.001.001.03 — invalid IBANUn pain.001 con un IBAN del creditore le cui due cifre di controllo non superano il test mod-97 (ISO 7064). Tutto il resto è corretto, quindi il validatore segnala esattamente un errore. | Non valido | |
| pain.001.001.03 — NbOfTxs mismatchUn pain.001 che si conta male: NbOfTxs dichiara una transazione mentre il file ne contiene due. Come per CtrlSum, il conteggio è verificato sul lotto di pagamento e sull’intestazione. | Non valido | |
| pain.001.001.03 — unstructured address after 2026-11-15Il caso di riferimento della regola EPC sull’indirizzo strutturato: gli indirizzi contengono solo AdrLine, senza TwnNm. A renderlo un errore bloccante è la data di esecuzione nel file (ReqdExctnDt = 2026-11-20, successiva alla soglia del 15/11/2026): con una data anteriore lo stesso file produce solo un avviso. | Non valido | |
| pain.001.001.11 — valid, fully structured address, executed after 2026-11-15Il file di riferimento «pronto per il 2026»: un bonifico pain.001.001.11 la cui data di esecuzione (ReqdExctnDt = 2026-11-20) cade dopo la soglia EPC per l’indirizzo strutturato del 15/11/2026. Ogni indirizzo di ordinante e beneficiario è completamente strutturato — StrtNm, BldgNb, PstCd, TwnNm, Ctry e nemmeno una AdrLine. Tre bonifici, 4.320,00 EUR, zero errori e zero avvisi. | Valido | |
| pain.001.001.09 — valid, two payment batches with different execution datesUn solo file pain.001, due blocchi PmtInf: il lotto A viene eseguito il 10/03/2026 con indirizzi ibridi (TwnNm + Ctry + una AdrLine), il lotto B il 20/11/2026 con indirizzi completamente strutturati. Mostra le due lezioni del file multi-lotto: la regola EPC sull’indirizzo si valuta lotto per lotto, sulla data che il lotto stesso porta, e ogni PmtInf ha i propri NbOfTxs / CtrlSum oltre ai totali del GrpHdr (4 bonifici, 3.350,00 EUR). | Valido | |
| pain.001.001.03 — nine-character BICUn pain.001 il cui BIC della banca del beneficiario è lungo nove caratteri. La ISO 9362 ne ammette 8 (istituto + paese + località) o 11 (più un codice filiale di 3 caratteri): mai 9 né 10. «BNPAFRPPX» è l’aspetto tipico di un codice filiale troncato o completato a mano, ed è l’unico difetto del file che entrambi i livelli intercettano: l’XSD ufficiale lo rifiuta per il pattern del BIC, il livello delle regole per la lunghezza. | Non valido | |
| pain.001.001.03 — accent and ampersand outside the SEPA character setUn pain.001 il cui beneficiario si chiama «Café Renard & Fils SARL»: una lettera accentata e una e commerciale, entrambe fuori dal set di caratteri latino di base approvato dall’EPC (a-z A-Z 0-9 e / - ? : ( ) . , ' + spazio). L’XML è ben formato e l’XSD ufficiale lo accetta senza obiezioni: Max70Text prende qualunque stringa. Il difetto vive interamente nel livello delle regole, ed è per questo che file simili arrivano in banca, che li rifiuta o li traslittera in silenzio. | Non valido | |
| pain.001.001.03 — 250 transfers, high-volume payroll runUn ciclo stipendi realistico: 250 bonifici SEPA in un unico PmtInf, distribuiti su cinque paesi (DE, NL, BE, ES, FR), per 442.028,75 EUR. Ogni IBAN ha cifre di controllo mod-97 (ISO 7064) corrette e i due totali di controllo coincidono con la somma esatta, al centesimo. Serve a vedere come si comportano il proprio parser, il portale bancario o i propri strumenti su un file né giocattolo né patologico — e a verificare che un solo centesimo sbagliato in un lotto di queste dimensioni venga comunque intercettato dal solo CtrlSum. | Valido | |
| pain.001.001.03 — unstructured address, executed before 2026-11-15 (warning only)Il gemello del campione con indirizzo non strutturato bloccante, con una sola differenza: la data di esecuzione. Gli stessi indirizzi ridotti a sole AdrLine, ma ReqdExctnDt è il 30/09/2026, prima della soglia EPC153-22 v2.1: lo stesso difetto torna come due avvisi anziché due errori — oggi il pagamento passa ancora. Mostra anche cosa significhi davvero «strutturato»: l’indirizzo del debitore non ha né TwnNm né Ctry, quello del creditore ha un Ctry ma ancora nessun TwnNm. Ctry da solo non basta: TwnNm è il discriminante. | Valido |
Addebito diretto SEPA (pain.008) (8)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| pain.008.001.02 — valid CORE direct debitUn addebito diretto SEPA valido nello schema CORE: due incassi ricorrenti per 175,00 EUR, un Identificativo Creditore (ICS) che supera il controllo ISO 7064 MOD 97-10 e un mandato firmato per ogni debitore. | Valido | |
| pain.008.001.08 — valid CORE direct debit, collected after 2026-11-15Ecco come si presenta un addebito diretto SEPA conforme dopo la soglia del 15/11/2026: la data di incasso è il 20/11/2026, quindi ogni indirizzo di creditore e debitore è strutturato (TwnNm + Ctry). Schema CORE, tre incassi per 228,80 EUR, nessun avviso. | Valido | |
| pain.008.001.02 — mandate signed after the collectionUn addebito incassato con un mandato che il debitore non aveva ancora firmato: DtOfSgntr è il 10/04/2026 mentre l’incasso è del 05/03/2026. Un difetto comune e silenziosamente fatale: ICS, IBAN e totali sono tutti corretti. | Non valido | |
| pain.008.001.08 — valid B2B direct debit, RCUR sequenceUn addebito diretto SEPA B2B valido in pain.008.001.08: LclInstrm/Cd = B2B, sequenza RCUR, due incassi ricorrenti per 4.650,00 EUR. Lo schema B2B è la variante tra imprese: il debitore deve essere un non consumatore e NON ha diritto al rimborso dopo il regolamento, per questo la sua banca verifica il mandato prima dell’addebito e gli incassi B2B si presentano prima di quelli CORE. | Valido | |
| pain.008.001.02 — valid CORE direct debit, FRST sequenceUn addebito diretto SEPA CORE valido con sequenza FRST: il primo incasso presentato su un mandato appena firmato (DtOfSgntr risale a pochi giorni). Tutto ciò che segue sullo stesso mandato deve partire come RCUR — lasciare un lotto su FRST per sempre è uno degli errori SDD più diffusi, e il motivo per cui le banche restituiscono incassi con un codice di sequenza errata. | Valido | |
| pain.008.001.08 — valid one-off direct debit, OOFF sequenceUn addebito diretto SEPA una tantum valido: sequenza OOFF, un unico incasso di 349,00 EUR. Il mandato autorizza esattamente un addebito e si esaurisce nel momento in cui viene usato: non potrà mai più essere presentato, nemmeno come RCUR. È la sequenza dell’acquisto singolo, della caparra o della spesa una tantum; usare FRST al suo posto lascia aperto, in silenzio, un mandato che il debitore non ha mai accettato. | Valido | |
| pain.008.001.02 — mandate identifier (MndtId) missingUn addebito senza identificativo del mandato: MndtRltdInf è presente e porta una data di firma, ma manca l’elemento MndtId (AT-01 del rulebook). L’XSD ufficiale ISO 20022 accetta il file — MndtId è opzionale nello schema — quindi un controllo puramente strutturale lo lascia passare e la banca lo rifiuta: senza riferimento del mandato, la banca del debitore non ha nulla a cui agganciare l’incasso e il debitore non ha nulla da contestare. | Non valido | |
| pain.008.001.02 — NbOfTxs and CtrlSum wrong at both levelsUn addebito diretto SEPA che si conta e si somma male, su entrambi i livelli insieme: il lotto contiene davvero 2 incassi per 300,00 EUR, ma NbOfTxs dichiara 3 e CtrlSum 250,00 — nel PmtInf e di nuovo nel GrpHdr. Sono quattro errori, non due: i totali di controllo si verificano sul lotto di pagamento E sull’intestazione, perché un file multi-lotto può esibire un totale d’intestazione corretto poggiato su due totali di lotto sbagliati. L’XML è ben formato e l’XSD ufficiale lo accetta: per uno schema, NbOfTxs e CtrlSum sono solo numeri. | Non valido |
Estratto conto (camt.052 / 053 / 054) (12)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| camt.053.001.02 — valid statementUn estratto conto camt.053.001.02 valido: quattro movimenti, saldi di apertura e chiusura che quadrano (OPBD ± movimenti = CLBD) e date in formato Dt. | Valido | |
| camt.053.001.08 — valid statementUn estratto conto camt.053.001.08 valido: tre movimenti, timestamp DtTm e BICFI al posto di BIC — le differenze su cui si inciampa passando dalla versione 02 alla 08. | Valido | |
| camt.053 — unsupported namespaceUn estratto che dichiara camt.053.001.99, una versione inesistente nel catalogo ISO 20022. Utile per verificare che il proprio parser rifiuti i namespace sconosciuti invece di tirare a indovinare. | Non valido | |
| camt.053.001.06 — missing Stmt elementUn estratto con namespace camt.053.001.06 corretto ma senza alcun elemento <Stmt>: la busta è giusta, manca il contenuto. È l’aspetto tipico di un export bancario troncato. | Non valido | |
| camt.053.001.11 — valid statementUn estratto conto camt.053.001.11 valido — la versione corrente del messaggio di rendiconto ISO 20022. Quattro movimenti, OPBD 25 000,00 ± movimenti = CLBD 34 659,05. Da notare ciò che la versione 11 rende obbligatorio su ogni movimento: Sts e BkTxCd, che le versioni precedenti lasciavano omettere. | Valido | |
| camt.053.001.08 — three accounts in one fileUn solo messaggio camt.053, tre blocchi <Stmt>: conto corrente, conto di risparmio e conto in USD. Il file è conforme allo schema; il validatore dichiara esplicitamente di analizzare solo il primo rendiconto. È proprio questo il punto: un lettore che prende Stmt[0] e si ferma perde due conti in silenzio, e questo file multi-conto lo smaschera. | Valido | |
| camt.053.001.10 — fully detailed entriesTutto ciò che una banca può agganciare a un movimento camt.053, in un unico file valido: NtryDtls/TxDtls con EndToEndId, InstrId, TxId e MndtId; RltdPties e RltdAgts; un riferimento creditore strutturato ISO 11649 (RF) e una fattura referenziata (CINV); un movimento raggruppato i cui due TxDtls sommano esattamente all’importo; e un BkTxCd ISO (PMNT/RCDT/ESCT) affiancato da un GVC tedesco proprietario. Utile per misurare quanto la vostra riconciliazione legge davvero. | Valido | |
| camt.053.001.08 — closing balance does not reconcileIl difetto più frequente nei camt.053 di produzione: l’apertura di 4 200,00 più i movimenti contabilizzati dà 5 194,70, mentre il CLBD dichiarato indica 5 194,07 — due cifre invertite. Il file soddisfa perfettamente l’XSD ufficiale ISO 20022, perché uno schema non ha nulla da dire sull’aritmetica. Solo una quadratura dei saldi intercetta un saldo di chiusura incoerente. | Valido | |
| camt.052.001.08 — valid intraday reportUn report infragiornaliero camt.052 valido — e non è un camt.053 in miniatura: la radice è BkToCstmrAcctRpt, il contenitore è <Rpt> e i saldi sono INTERMEDI (ITBD contabilizzato, ITAV disponibile) invece della coppia OPBD/CLBD di un estratto di fine giornata. Porta anche un movimento in sospeso (Sts=PDNG) volutamente escluso dal saldo intermedio: il denaro in sospeso non è denaro contabilizzato. | Valido | |
| camt.054.001.08 — valid debit/credit notificationUn avviso di addebito/accredito camt.054 valido: un accredito SEPA in entrata e un addebito diretto in uscita, ciascuno con TxDtls completi e riferimento end-to-end. La sorpresa strutturale è ciò che NON c’è: un camt.054 non ha alcun elemento <Bal> — lo schema ISO 20022 non ne definisce. Un avviso annuncia movimenti, non dichiara mai un saldo: non c’è nulla da quadrare. | Valido | |
| camt.053.001.08 — entry with no CdtDbtIndIl secondo movimento porta un importo di 1 200,00 e nessun <CdtDbtInd>. In camt.053 gli importi sono sempre senza segno: senza l’indicatore di direzione l’importo non significa nulla. Si rompono due cose insieme — l’XSD ufficiale rifiuta il file (CdtDbtInd è obbligatorio 1..1 su un movimento) e un parser che ripiega in silenzio su CRDT contabilizza +1 200,00 invece di −1 200,00, finendo a 2 400,00 dalla verità, cosa che la quadratura dei saldi svela. | Non valido | |
| camt.053.001.08 — 220 entries, validUn estratto conto aziendale di fine mese con 220 movimenti contabilizzati, tutti quadrati: OPBD 125 000,00 ± movimenti = CLBD 209 081,69. Ogni movimento porta NtryDtls/TxDtls, un EndToEndId e una controparte: mette alla prova un lettore camt.053 su volumi realistici anziché su un file giocattolo di tre righe — throughput di parsing, rendering della tabella e riconciliazione su centinaia di righe. | Valido |
Fattura UBL (Peppol BIS 3.0) (12)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| UBL Invoice — valid Peppol BIS 3.0Una fattura Peppol BIS Billing 3.0 valida: tre righe, 2.596,00 EUR IVA inclusa, totali coerenti, partita IVA francese e IBAN per il pagamento. | Valido | |
| UBL Credit Note — valid Peppol BIS 3.0Una nota di credito Peppol BIS Billing 3.0 valida: una riga, 1.770,00 EUR IVA inclusa, con riferimento alla fattura originale che annulla. La nota di credito è un tipo di documento UBL a sé, non una fattura con importi negativi. | Valido | |
| UBL Invoice — BR-CO-10 violationUna fattura che viola la regola EN 16931 BR-CO-10: la somma degli importi netti di riga (1.000,00) non corrisponde al totale documento BT-106 (2.000,00). Uno dei rifiuti più frequenti sulla rete Peppol. | Non valido | |
| UBL Invoice — malformed seller VAT identifierUna fattura la cui partita IVA del venditore, «FR1234», è troppo corta: un numero francese è FR seguito da una chiave di due caratteri e nove cifre. Gli errori di formato su BT-31 vengono intercettati ben prima del fisco. | Non valido | |
| UBL Invoice — allowances and charges, line and document levelUna fattura UBL Peppol BIS 3.0 valida con sconti e maggiorazioni su ENTRAMBI i livelli: sconto di riga (BG-27), maggiorazione di riga (BG-28), sconto a livello documento (BG-20) e spese di trasporto (BG-21). Il punto è la catena dei totali: BT-106 = 1.520,00 è la somma degli importi di riga NETTI, e BT-109 = 1.530,00 = BT-106 - BT-107 + BT-108 (BR-CO-13), quindi l’IVA al 19 % si applica su 1.530,00 e non su 1.520,00. | Valido | |
| UBL Invoice — reverse charge (VAT category AE)Una fattura valida in reverse charge in UBL: un fornitore francese fattura servizi a un’impresa tedesca, l’IVA è assolta dal cliente, quindi aliquota 0 % e nessuna imposta addebitata. La categoria AE porta con sé quattro regole: entrambi i numeri di partita IVA (BR-AE-02, BR-AE-03), l’aliquota 0 % (BR-AE-05), un’imposta di 0,00 (BR-AE-09) e un motivo di esenzione (BR-AE-10), qui VATEX-EU-AE e la dicitura «Reverse charge». | Valido | |
| UBL Invoice — VAT exempt (category E) with exemption reasonUna fattura esente IVA valida (categoria E): formazione professionale esente ai sensi dell’articolo 132, par. 1, lett. i) della direttiva 2006/112/CE. Una fattura esente deve dire PERCHÉ lo è: BR-E-10 impone un codice motivo di esenzione (BT-121) o un testo (BT-120), e questo file li riporta entrambi: VATEX-EU-132 e la dicitura della lista di codici ufficiale. | Valido | |
| UBL Invoice — intra-Community supply (VAT category K)Una cessione intracomunitaria valida (categoria IVA K): merci spedite dalla Germania a un acquirente con partita IVA in Francia, non imponibili ai sensi dell’articolo 138 della direttiva 2006/112/CE. La categoria K richiede due dati che si dimenticano spesso: BR-IC-11, una data di consegna effettiva (BT-72) o un periodo di fatturazione, e BR-IC-12, il paese di consegna (BT-80). Senza di essi la fattura non prova che i beni hanno lasciato il paese. | Valido | |
| UBL Invoice — two VAT rates, one breakdown per rateUna fattura valida che combina l’aliquota ordinaria francese (20 %) e quella ridotta (5,5 %). La regola illustrata è BR-S-08: il riepilogo IVA (BG-23) contiene UN TaxSubtotal per coppia (categoria, aliquota) e ogni imponibile è la somma delle righe di quella coppia — 1.500,00 al 20 % (IVA 300,00) e 400,00 al 5,5 % (IVA 22,00). Fondere due aliquote in un unico subtotale supera tutti i controlli BR-CO ed è comunque sbagliato. | Valido | |
| UBL Invoice — BR-CO-10, line sum does not equal BT-106Il rifiuto più frequente in produzione, isolato: le due righe sommano 1.500,00 mentre BT-106 (LineExtensionAmount) dichiara 1.400,00 — BR-CO-10. Tutto il resto è coerente con la cifra SBAGLIATA, quindi BR-CO-13, BR-CO-14, BR-CO-15 e BR-CO-16 passano e torna un solo errore. È esattamente l’aspetto di una riga cancellata dopo il calcolo dei totali. | Non valido | |
| UBL Invoice — exempt VAT without an exemption reason (BR-E-10) and a wrong exempt base (BR-E-08)Una fattura esente sbagliata due volte. BR-E-10: il riepilogo IVA della categoria E non riporta né un motivo di esenzione (BT-120) né un codice (BT-121) — una fattura esente deve dire PERCHÉ. BR-E-08: l’imponibile esente dichiara 1.200,00 mentre le righe esenti sommano 1.500,00, perché la seconda riga non è mai entrata nel riepilogo. L’errore citato è quello del livello business; lo Schematron ufficiale EN 16931 aggiunge BR-E-10. | Non valido | |
| UBL Invoice — BR-CO-17, VAT amount does not equal base x rateUn riepilogo IVA che non torna: una base di 2.000,00 al 19 % fa 380,00 di IVA, ma la fattura dichiara 395,00. BR-CO-17 verifica che l’imposta della categoria = imponibile × aliquota / 100, con il margine ufficiale di una unità monetaria: un centesimo di arrotondamento è tollerato, questo scarto di 15,00 no. Tutti gli altri totali seguono la cifra sbagliata: è così che un bug di arrotondamento arriva in produzione. | Non valido |
Fattura CII (sintassi XRechnung / Factur-X) (4)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| CII CrossIndustryInvoice — XRechnung 3.0, validUna fattura XRechnung 3.0 valida in sintassi CII (UN/CEFACT CrossIndustryInvoice), la fattura elettronica del settore pubblico tedesco. Contiene ciò che le regole BR-DE di KoSIT aggiungono a EN 16931: il Leitweg-ID come riferimento acquirente (BR-DE-15), un contatto venditore completo — nome, telefono ed e-mail (da BR-DE-2 a BR-DE-6), l’indirizzo elettronico del venditore, termini di pagamento strutturati e un bonifico SEPA (mezzo di pagamento 58). | Valido | |
| CII CrossIndustryInvoice — Factur-X 1.0 BASIC, valid (standalone XML)Il payload Factur-X / ZUGFeRD da solo: l’XML CII che di norma viaggia incorporato in un PDF/A-3, qui come file autonomo validabile direttamente. Il profilo BASIC (BT-24 = urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic) è un CIUS conforme a EN 16931 — righe di fattura complete, riepilogo IVA integrale e i sei totali del documento. Utile per testare un estrattore sul solo XML, senza il PDF di mezzo. | Valido | |
| CII CrossIndustryInvoice — BR-CO-10, line sum does not equal BT-106BR-CO-10 in sintassi CII: le due righe sommano 2.000,00 ma LineTotalAmount (BT-106, dentro SpecifiedTradeSettlementHeaderMonetarySummation) dichiara 1.900,00. Lo stesso difetto del campione UBL, nella sintassi in cui si nota meno: i totali del documento stanno in un ramo dell’albero diverso dalle righe che dovrebbero riassumere. | Non valido | |
| CII CrossIndustryInvoice — BR-CO-13, the discount never reaches the tax basisUno sconto a livello documento che esiste solo a metà: la fattura concede 200,00 (BT-107), calcola l’IVA sulla base scontata (1.800,00 × 19 % = 342,00 — corretto), ma BT-109 (TaxBasisTotalAmount) dichiara ancora 2.000,00 senza sconto. BR-CO-13 impone BT-109 = BT-106 - BT-107 + BT-108: all’acquirente vengono così fatturati 200,00 che il venditore credeva di aver abbuonato. | Non valido |
Estratto SWIFT MT940 (10)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| MT940 — Rabobank / Deutsche Bank dialectIl caso nominale MT940: un estratto, un accredito e un addebito, con la coppia riferimento cliente / riferimento banca nella riga :61:. Da qui si parte per capire la struttura dei tag prima dei dialetti. | Valido | |
| MT940 — ING Belgium, structured :86:Il dialetto ING Belgio: la riga informativa :86: è strutturata in sottocampi ?00 ?20 ?30 anziché in testo libero. È la prima causa di bug nel parsing MT940. | Valido | |
| MT940 — Commerzbank, one-decimal amountIl dialetto Commerzbank: un importo con un solo decimale (1234,5 per 1.234,50), un tipo di transazione NMSC e un conto tedesco espresso come BLZ + numero anziché IBAN. | Valido | |
| MT940 — two statements in one fileDue estratti in un unico file MT940, più il tag di saldo disponibile :64:. Un file non è un estratto: un parser che lo dà per scontato perde il secondo in silenzio. | Valido | |
| MT940 — reversal (RC) and intermediate balancesIl caso ABN AMRO: uno storno RC (un accredito ribaltato in addebito), saldi intermedi 60M/62M anziché F e un :86: su due righe. Gli storni invertono il segno: sbagliare qui significa un saldo che non quadra mai. | Valido | |
| MT940 — overdrawn account (debit balances)Un conto scoperto: i saldi di apertura e chiusura portano entrambi il marcatore D (dare). In MT940 un saldo negativo non è un numero negativo ma un flag di segno, e il codice che lo ignora presenta lo scoperto come credito. | Valido | |
| MT940 — closing balance does not reconcileUn estratto il cui saldo di chiusura non discende da apertura ± movimenti. È volutamente un avviso e non un errore bloccante: il file resta leggibile e spetta a una persona stabilire se la colpa è della banca o dell’export. | Valido | |
| MT940 — 500 transactions (load test)Cinquecento transazioni in un solo estratto, quadrate al centesimo. Serve a verificare che il parser resti esatto — e veloce — a volume reale, non solo su un file giocattolo di tre righe. | Valido | |
| MT940 — statement split over two pages (62M / 60M)Un estratto, un giorno, due pagine: la sequenza 00147/00001 chiude su un saldo INTERMEDIO :62M: e la sequenza 00147/00002 riapre su :60M: con esattamente quella cifra prima di chiudere sul :62F: finale. M non è F: scambiare il saldo intermedio per quello finale significa dichiarare 37.500,00 quando il conto ha chiuso a 44.249,25. | Valido | |
| MT940 — USD account with an RD reversalUn estratto in dollari — MT940 non è un formato euro — in cui un bonifico in uscita di 35.000,00 viene restituito il giorno dopo da uno storno RD: un ADDEBITO STORNATO è denaro che RIENTRA. I marcatori RC/RD invertono la direzione economica della riga :61:, e un parser che legge solo la D di «RD» registra il rimborso una seconda volta come pagamento e non quadra mai. | Valido |
Estratto BAI2 (USA / Canada) (6)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| BAI2 — US bank daily statement (nominal case)Il file BAI2 nominale: un conto, un saldo di apertura 010 e di chiusura 015 e dieci movimenti la cui direzione deriva solo dal type code — 115 versamento lockbox, 165 accredito ACH, 195 bonifico in entrata, 475 assegno pagato, 451 addebito ACH, 495 bonifico in uscita, 698 spese. BAI2 non ha un indicatore dare/avere: 100–399 è entrata, 400–699 uscita. | Valido | |
| BAI2 — several accounts in one groupDue record di conto 03 in un unico gruppo 02 — un conto operativo e un conto stipendi, ciascuno chiuso dal proprio trailer 49. BAI2 è gerarchico (01 file / 02 gruppo / 03 conto / 16 movimento / trailer 49-98-99): chi presume un conto per file perde il secondo in silenzio. | Valido | |
| BAI2 — 88 continuation recordsIl record di continuazione 88 nei suoi due ruoli, molto diversi: porta tuple di saldo aggiuntive a un record di conto 03 (qui la chiusura 015 e il disponibile 045) e testo libero mandato a capo per un movimento 16 (tre righe fisiche, una sola causale). Unirli allo stesso modo significa leggere i saldi come testo, o il testo come saldi. | Valido | |
| BAI2 — CAD and JPY: minor units scale with the currencyGli importi BAI2 non hanno separatore decimale: sono unità minori, e quante decimali sottintendano dipende dalla valuta. Qui «2500000» vale 25.000,00 CAD sul conto CAD (2 decimali) e ¥2.500.000 sul conto JPY (0 decimali). Il conto CAD lascia inoltre vuoto il campo valuta e la eredita dall’intestazione di gruppo 02. Una divisione per 100 cablata corrompe il conto in yen di due ordini di grandezza — e il saldo quadra lo stesso, perché tutte e tre le cifre sbagliano dello stesso fattore. | Valido | |
| BAI2 — closing balance does not reconcileIl saldo di chiusura 015 non discende dal saldo di apertura 010 più i movimenti 16: 50.000,00 + 10.000,00 − 2.500,00 fanno 57.500,00, ma il file dichiara 59.000,00. I trailer quadrano ancora: solo l’aritmetica lo tradisce. Volutamente un avviso e non un errore bloccante: il file è leggibile e spetta a una persona stabilire se la colpa è della banca o dell’export. | Valido | |
| BAI2 — bad trailer totals and an out-of-range type codeTre difetti insieme. Il trailer di conto 49 dichiara un totale di controllo e un numero di record che non corrispondono ai record precedenti — i trailer sono il controllo d’integrità del file stesso, e chi li salta non vede un troncamento. E un movimento 16 porta il type code 720, nella fascia prestiti 700–799: non è un accredito (100–399) né un addebito (400–699), la direzione non è deducibile e il record viene scartato anziché indovinato — ecco perché nemmeno il saldo quadra più. | Valido |
Factur-X / ZUGFeRD (PDF) (2)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| Factur-X EN 16931 — valid hybrid invoiceUna fattura Factur-X valida nel profilo EN 16931: un PDF/A-3 con l’XML CII incorporato. Un solo documento che un umano legge e una macchina analizza: è tutto il senso del formato ibrido. | Valido | |
| Factur-X EN 16931 — BR-CO-15 violationUna fattura Factur-X che viola la regola EN 16931 BR-CO-15: il totale IVA inclusa è 130,00 mentre imponibile più IVA fanno 120,00. Il PDF si apre e sembra del tutto normale: solo l’XML incorporato lo tradisce. | Non valido |
Fattura KSeF (Polonia, FA(3)) (7)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| KSeF FA(3) — valid invoice (official MF example)Una fattura strutturata FA(3) conforme: l’esempio n. 4 del Ministero delle Finanze polacco, riprodotto invariato. Tre righe, 64.279,92 PLN IVA inclusa al 23%. Riferimento di ciò che KSeF accetta. | Valido | |
| KSeF — invoice still using the retired FA(2) schemaIl più comune errore di migrazione a KSeF: una fattura formalmente ineccepibile che dichiara ancora il namespace FA(2), ritirato il 1° febbraio 2026. Nulla sembra sbagliato finché KSeF non la rifiuta. Si noti ciò che FA(3) ha aggiunto e qui manca: Podmiot2 richiede ora JST e GV. | Non valido | |
| KSeF FA(3) — bad NIP check digit and mismatched total (warnings only)Strutturalmente perfetta rispetto allo schema ufficiale, eppure il NIP del venditore non supera la cifra di controllo mod-11 e P_15 non corrisponde alla somma della ripartizione IVA. ValidateFin segnala entrambi come avvisi, non errori: nessuna delle due regole è normativa e l’esempio n. 1 del Ministero è esso stesso sfasato di un grosz. | Valido | |
| KSeF FA(3) — correcting invoice (faktura korygująca, KOR)Una fattura di rettifica (RodzajFaktury = KOR), il caso FA(3) più cercato e più spesso sbagliato. I totali portano la DIFFERENZA, non la fattura rettificata: P_13_1, P_14_1 e P_15 sono negativi. Compaiono inoltre PrzyczynaKorekty, TypKorekty e DaneFaKorygowanej, che rinviano alla fattura corretta. Le righe vanno a coppie: quella con StanPrzed è lo stato precedente. | Valido | |
| KSeF FA(3) — prepayment invoice (faktura zaliczkowa, ZAL)Una fattura di acconto (RodzajFaktury = ZAL): fattura un anticipo su un ordine non ancora consegnato. Non porta quindi ALCUNA riga FaWiersz — i beni stanno nel blocco Zamowienie (ordine), con i suoi tag P_7Z / P_11NettoZ / P_11VatZ — mentre P_15 espone solo l’acconto di 12.300,00 PLN su un ordine da 61.500,00 PLN. | Valido | |
| KSeF FA(3) — mandatory element missing (rejected by the official XSD)Una fattura FA(3) priva di un elemento obbligatorio: P_2, il numero della fattura. A prima vista nulla stona — XML ben formato, namespace corretto, ripartizione IVA plausibile — e solo l’XSD ufficiale del Ministero delle Finanze lo intercetta: «Element P_6: this element is not expected. Expected is P_2.» KSeF rifiuta senz’altro un file simile. | Non valido | |
| KSeF FA(3) — buyer NIP failing its mod-11 check digit (warning only)Il NIP dell’acquirente è 1111111112: dieci cifre, quindi lo schema ufficiale, che lo vincola solo con un pattern, lo accetta senza obiezioni. La cifra di controllo mod-11 non torna: un simile codice fiscale polacco non può esistere e la fattura non è indirizzata a nessuno. ValidateFin segnala un avviso, mai un errore — il Ministero non pubblica una regola di validazione del genere. | Valido |
Fattura elettronica (Italia, SdI) (4)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| FatturaPA FPR12 — conformant invoice to a private partyUna FatturaPA che il SdI accetterebbe: aritmetica IVA corretta (due righe al 22 % per 1.100 €, 242 € di imposta, 1.342 € di totale), identificativi fiscali con cifra di controllo valida e un CodiceDestinatario di 7 caratteri, come richiede un destinatario privato. È il punto di riferimento: tutti gli altri esempi sono questo file, rotto in un modo preciso. | Valido | |
| FatturaPA — signed CAdES (.p7m) envelopeLa stessa fattura conforme, racchiusa in una busta di firma CAdES (.p7m): è così che viaggiano la maggior parte delle fatture italiane reali, ed è obbligatorio per ogni fattura verso la Pubblica Amministrazione. Aperto in un editor di testo, il file è solo rumore binario. Il validatore apre la busta e controlla l’XML contenuto; non verifica la firma in sé, e lo dichiara. | Valido | |
| FatturaPA — XSD-valid, rejected by the SdI (00421, 00422, 00445)Questa fattura è VALIDA rispetto all’XSD ufficiale e il SdI la scarterebbe comunque: è esattamente per questo che il solo controllo di schema non basta. Tre difetti: l’imponibile dichiara 1.150 € a fronte di righe che sommano 1.100 € (controllo 00422, la cui tolleranza è di un EURO, non di un centesimo); l’imposta dichiara 250 € dove il 22 % di 1.150 € fa 253 € (00421); e il codice Natura è il N3 generico, ritirato il 1° gennaio 2021 a favore dei suoi sotto-codici (00445) — pur restando nell’enumerazione dello schema. | Non valido | |
| FatturaPA FPA12 — wrong CodiceDestinatario length (00427)Il modo più frequente in cui una fattura verso una Pubblica Amministrazione viene respinta: il CodiceDestinatario. Per una PA (FormatoTrasmissione = FPA12) deve essere il codice ufficio IPA di SEI caratteri — la forma a sette caratteri spetta ai destinatari privati. L’XSD ammette 6 O 7 per entrambi, quindi lo schema non se ne accorge; solo il controllo SdI 00427 lo fa. Il numero della fattura, «FATTURA», per giunta non contiene alcuna cifra (00425). | Non valido |
Fattura RO e-Factura (Romania, ANAF) (6)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| RO e-Factura — conformant invoice (FACT1)Una fattura che l’ANAF accetta — il suo validatore ufficiale offline risponde « este valid ». È l’esempio pubblicato dal Ministero, riparato nei due punti che fanno fallire la versione pubblicata: BT-24 portato a CIUS-RO:1.0.1 e due CUI con cifra di controllo davvero corretta. È il punto di riferimento: ogni campione rotto è questo file, danneggiato in un modo preciso. | Valido | |
| RO e-Factura — credit note in a foreign currency (FCN)Una nota di credito (FCN) in SEK — e l’ANAF la accetta. Mostra che cosa richiede davvero BR-RO-030: RON deve comparire come valuta della fattura (BT-5) OPPURE come valuta di contabilizzazione dell’IVA (BT-6), non necessariamente entrambe. Qui BT-5 è SEK e BT-6 è RON, e la regola è soddisfatta. Porta inoltre il codice tipo 381, lecito su una nota di credito e vietato su una fattura. | Valido | |
| RO e-Factura — BT-24 still declaring CIUS-RO:1.0.0 (BR-RO-001)Lo scarto rumeno più frequente, e l’unico difetto di questo file: BT-24 dichiara ancora CIUS-RO:1.0.0, valore ritirato il 29 dicembre 2022 (ordine OMF 4092/2022). La fattura è per il resto impeccabile e supera l’XSD. Entrambi gli esempi che il Ministero pubblica ancora portano questo difetto — e il suo stesso validatore li respinge. | Non valido | |
| RO e-Factura — Bucharest written “Sector 1” instead of SECTOR1 (BR-RO-100)Un venditore a Bucarest la cui città (BT-37) è scritta «Sector 1» — la grafia esatta usata dall’ordine ministeriale stesso. Lo Schematron che l’ANAF esegue davvero pretende SECTOR1: maiuscole, senza spazio. Quando il testo di legge e l’implementazione divergono, è l’implementazione a scartare la fattura. | Non valido | |
| RO e-Factura — buyer CUI with a wrong check digit (ERRIdentif)Il campione che rivela l’angolo cieco di ogni validatore che esegue solo lo Schematron. Il CUI dell’acquirente (RO987456123) ha una cifra di controllo sbagliata — e NESSUNA regola dello Schematron la guarda. Questo file supera l’XSD, supera l’intero corpus CIUS-RO, e l’ANAF lo respinge lo stesso, con un codice tutto suo: ERRIdentif, « CUI cumparator incorect ». | Non valido | |
| RO e-Factura — B2C invoice with the anonymous CNP (0000000000000)Una fattura B2C il cui acquirente è un privato, identificato dal CNP anonimo di tredici zeri — in produzione dal 16 dicembre 2024. È valida, e un validatore che lo scambiasse per un numero personale malformato romperebbe tutta la fatturazione ai consumatori in Romania: quel numero non supera nessuna regola di forma del CNP (la sua prima cifra, 0, è rifiutata ovunque altrove), perché è un valore riservato, non un CNP. | Valido |
Registro di fatturazione Verifactu (Spagna, AEAT) (3)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| Verifactu — envío conforme, dos registros encadenadosUn invio che l’AEAT accetterebbe: due registri di fatturazione correttamente concatenati. Il primo dichiara di essere il primo della catena e calcola l’impronta con il campo precedente vuoto; il secondo concatena l’impronta del primo. Entrambe le impronte sono reali (SHA-256 sulla stringa esatta specificata dall’AEAT), non inventate. | Valido | |
| Verifactu — cadena de huellas rota (aceptado con errores, código 2000)Il secondo registro dichiara un’impronta che NON corrisponde al suo contenuto: la catena è rotta. Il file è VALIDO rispetto all’XSD ufficiale dell’AEAT — un validatore che guardi solo lo schema lo promuove. Solo ricalcolando lo SHA-256 concatenato lo si scopre. E attenzione: l’AEAT non lo respinge, lo marca «Aceptado con errores» (codice 2000) e lo registra comunque. | Valido | |
| Verifactu — la AEAT lo rechazaría (códigos 1190 y 1142)Una fattura semplificata (F2) che porta un blocco Destinatarios — vietato, codice 1190 — e la cui CuotaRepercutida (100 €) non corrisponde a base × aliquota (1.000 € × 21 % = 210 €), ben oltre la tolleranza di ±10 € del controllo 1142. Il file SUPERA l’XSD ufficiale senza un reclamo: lo schema non può vederlo, l’AEAT lo respinge. | Non valido |
Fattura Facturae (Spagna, FACe) (2)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| Facturae 3.2.2 — factura B2G conforme y firmadaUna fattura Facturae 3.2.2 indirizzata a una pubblica amministrazione (con i suoi centri amministrativi DIR3, come richiede FACe) che supera l’XSD ufficiale di facturae.gob.es senza un reclamo, con tutti i totali coerenti secondo le formule dello schema stesso e una firma XAdES presente. È il punto di riferimento: l’altro esempio è lo stesso file, rotto in un modo preciso. La firma è di esempio: la sua validità crittografica non è verificata offline. | Valido | |
| Facturae 3.2.2 — totales incoherentes (válida contra el XSD)Lo stesso file, con una sola modifica: InvoiceTotal dichiara 1.200,00 € dove la formula dello schema dà 1.210,00 € (base 1.000 + IVA 210). Il file è VALIDO rispetto all’XSD ufficiale di facturae.gob.es — un validatore che guardi solo lo schema lo promuove. Solo il livello di coerenza lo scopre, e segnala anche che il totale del lotto non torna più. Non è uno scarto « ufficiale »: Facturae/FACe non pubblica codici di scarto verificabili offline, quindi è un avviso, non un errore. | Valido |
Estratto CODA (Belgio) (6)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| CODA — Belgian statement with a valid structured communicationUn estratto belga ordinario: un bonifico SEPA con una comunicazione strutturata valida (+++090/9337/55493+++), un pagamento con carta e un bonifico ricevuto con la sua controparte. Saldo iniziale 1.000,00 − 250,00 − 89,90 + 1.500,00 = saldo finale 2.160,10, e i totali del trailer concordano. | Valido | |
| CODA — globalised salary run (booked total + its details)Una globalizzazione: un totale stipendi contabilizzato di 3.000,00 (numero di dettaglio 0000) seguito dai due stipendi individuali che lo compongono (0001, 0002). Solo il totale è contabilizzato — un parser che somma anche i dettagli conta due volte il file e l’estratto non quadra più. Chiude con un saldo a debito di 2.000,00. | Valido | |
| CODA — wrong mod-97 check digits and a statement that does not balanceRotto di proposito. La comunicazione strutturata finisce con 94 dove il mod 97 richiede 93 — la causa più frequente per cui un pagamento belga non viene mai riconciliato con la sua fattura — e il saldo finale non discende dai movimenti. Nessun altro strumento CODA gratuito verifica queste cifre di controllo. | Valido | |
| CODA — Belgian OGM (+++…+++) and ISO 11649 RF reference, both checksummedUn estratto CODA che porta i due riferimenti strutturati previsti dal formato, ciascuno con la propria cifra di controllo: un bonifico emesso con comunicazione strutturata belga +++090/9337/55493+++ (tipo 101, mod 97 — un resto pari a 0 si scrive 97, non 00) e un bonifico ricevuto con riferimento creditore ISO 11649 RF73INV20260042 (tipo 100, mod 97-10). Entrambi risultano validi e l’estratto quadra: 1.000,00 − 250,00 + 1.500,00 = 2.250,00. | Valido | |
| CODA — separate application: balances zeroed by design (§7.2.1)Una «separate application» CODA (posizioni 84-88 dell’intestazione = 00001): una liquidazione di acquiring carte consegnata fuori dall’estratto conto. Il §7.2.1 di Febelfin azzera per costruzione i saldi iniziale e finale, quindi l’identità saldo iniziale ± movimenti = saldo finale non può reggere — e non va verificata. ValidateFin la salta e dichiara il file pulito; un validatore che non la salta segnala come rotto ogni file di questo tipo. | Valido | |
| CODA — old balance ± movements ≠ new balanceUn estratto belga ordinario — cui manca un movimento. I record 2.1 danno 1.000,00 − 250,00 + 1.500,00 = 2.250,00, ma il record «8» del nuovo saldo dichiara 2.200,00: 50,00 di movimento contabilizzato non sono mai finiti nel file. È questo il controllo che smaschera un CODA troncato, un record perso o un segno dare/avere letto male — ed è il motivo per cui il campione precedente NON va controllato allo stesso modo. | Valido |
Estratto CFONB 120 (Francia) (5)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| CFONB 120 — statement with its SEPA supplement recordsUn estratto francese con tutti i suoi dati SEPA: un addebito diretto con riferimento del mandato e sequenza RCUR, il nome del creditore, un pagamento con carta e un bonifico ricevuto con il nome del pagatore, il riferimento end-to-end, la causale e la descrizione — il tutto in record «05». Saldo iniziale 1.000,00 − 250,00 − 89,90 + 1.500,00 = saldo finale 2.160,10. | Valido | |
| CFONB 120 — amount without its overpunched signRotto di proposito, ed è il modo classico di corrompere un file CFONB: l’importo dell’addebito finisce con una cifra semplice invece che con un carattere di segno sovrimpresso, quindi il file non dice mai che è un addebito. Viene letto come un accredito — e a scoprirlo è l’identità contabile richiesta dal CFONB. | Valido | |
| CFONB 120 — the "05" supplements: RUM, IBE, NBE, REF, LIB, NPY, IPY, RCN, LCC/LC2, CPYI dati SEPA di un estratto CFONB 120 stanno nei record «05», e ogni qualificatore taglia in modo diverso la stessa zona di 70 caratteri (posizioni 49-118): RUM porta un riferimento di mandato E il suo tipo di sequenza (RCUR), REF un riferimento di lotto E uno di operazione, RCN un identificativo end-to-end E una causale, mentre NBE, NPY e LIB occupano tutta la zona. Letta piatta, la zona incolla il mandato al suo tipo di sequenza. Il file contiene un addebito SEPA (operazione B1) e un bonifico ricevuto, con dieci qualificatori diversi in tutto. | Valido | |
| CFONB 120 — two accounts (two 01…07 blocks) in one fileUn solo file CFONB 120, due conti: ciascuno forma il proprio blocco 01 (saldo iniziale) … 07 (saldo finale) e quadra da sé. Il secondo apre SCOPERTO — il saldo iniziale porta un segno sovrimpresso della famiglia «}», quindi un addebito — e risale a un saldo a credito di 179,60. Un parser che tenga un unico saldo progressivo per tutto il file, o che legga il carattere di segno come una cifra, sbaglia entrambi i conti. | Valido | |
| CFONB 120 — the new balance does not equal old balance ± movementsQui ogni importo porta un segno sovrimpresso corretto — eppure l’estratto non quadra: 1.000,00 − 89,90 + 500,00 = 1.410,10, mentre il record «07» dichiara 1.310,10. La regola 2 del §1 della specifica CFONB pone questa identità come la DEFINIZIONE di un estratto conforme: non è un’euristica, nel file mancano 100,00 di movimento. | Valido |
Messaggio Fedwire ISO 20022 (USA) (6)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| Fedwire pacs.008 — conformant customer credit transferUn bonifico cliente con intestazione BAH e indirizzi postali ibridi: rispetta già il formato richiesto dal 16 novembre 2026. | Valido | |
| Fedwire pacs.009 — conformant bank-to-bank transferUn bonifico tra istituzioni finanziarie: la tratta interbancaria, in cui debitore e creditore sono banche. | Valido | |
| Fedwire pacs.008 — unstructured address, settling after 16/11/2026L’indirizzo del creditore è su tre righe libere, senza città né paese. Valido rispetto all’XSD, respinto dalla regola: dal 16 novembre 2026 Fedwire elimina l’indirizzo completamente non strutturato. | Non valido | |
| Fedwire pacs.008 — same unstructured address, settling before the cut-overIl controesempio: lo stesso indirizzo non strutturato, ma con regolamento il 30/06/2026. È lecito, quindi produce solo un avviso. L’innesco è la data di regolamento del messaggio, mai la data odierna. | Valido | |
| Fedwire pacs.008 — routing number that cannot existIl routing number della banca del creditore è 021000088: una cifra sbagliata. Non supera la cifra di controllo ABA 3-7-1, quindi non può esistere. L’XSD vede solo nove cifre ineccepibili. | Non valido | |
| Fedwire — header announces a different message than it carriesL’intestazione BAH dichiara <MsgDefIdr>pacs.009.001.08</MsgDefIdr> mentre il documento che accompagna è un pacs.008. Ogni metà è valida rispetto al proprio schema: solo il confronto lo rivela. | Non valido |
Bonifico SWIFT MT103 (2)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| MT103 — cross-currency customer credit transferUn MT103 completo: i cinque blocchi SWIFT, un UETR, un ordinante in opzione K, agenti in opzione A e un beneficiario con IBAN. Regolato in USD e disposto in EUR: il campo :36: (tasso di cambio) è quindi obbligatorio ed è presente. | Valido | |
| MT103 — three defects a plain text viewer would missStrutturalmente un MT103 perfettamente leggibile — e sbagliato tre volte: l’UETR non è un UUID v4, il pagamento è multivaluta senza tasso di cambio in :36:, e l’IBAN del beneficiario non supera il mod-97. | Valido |
File di pagamenti CPA-005 / AFT (Canada) (6)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| CPA-005 — payroll direct deposit (two credits in one record)Un normale file di stipendi canadese: un unico record «C» che porta due accrediti diretti (tipo operazione 200) in due dei suoi sei segmenti. Il trailer Z dichiara 2 accrediti per 3.750,50 e nessun addebito, e quadra. Da notare: il contatore dei record conta i record FISICI, mentre il trailer conta le TRANSAZIONI — tre record e due transazioni. | Valido | |
| CPA-005 — a pre-authorised debit and its NSF return (code 901)Un addebito preautorizzato «D» di 899,00 seguito dal record «J» che lo restituisce. Il ritorno porta il codice 901 (fondi insufficienti) nel campo TIPO OPERAZIONE — dove un pagamento porterebbe il proprio tipo — mentre il tipo originale 700 sopravvive nello stored transaction type. Entrambi sono contabilizzati come addebiti, da cui i 2 addebiti per 1.798,00 nel trailer. | Valido | |
| CPA-005 — the error correction folded into the debit totalRotto di proposito, e rotto come lo rompono i generatori reali: il file storna un accredito con un record «E», e il trailer conta quello storno come un addebito. Non lo è. Lo standard 005 assegna alle correzioni E ed F una PROPRIA coppia di totali, distinta dalle coppie di addebiti e accrediti — fonderle fa perdere il quadro al file. È la causa più frequente di rifiuto di un generatore CPA-005 scritto a mano. | Non valido | |
| CPA-005 — credits (C) and debits (D) in one file, four pairs of totals balancedUn file AFT da 1464 caratteri che mescola le due direzioni: un record «C» con due accrediti di stipendio (3.750,50) e un record «D» con due addebiti preautorizzati (1.349,25). C è l’ACCREDITO e D l’ADDEBITO — diversi riassunti pubblicati li invertono. Il trailer Z quadra sulle quattro coppie di totali definite dallo standard 005 (D+J, C+I, E a sé, F a sé), qui con i contatori E e F a zero. | Valido | |
| CPA-005 — Notice of Change file (U / S / V records, 208 characters)Un Notice of Change canadese: l’istituto ricevente comunica all’emittente che un conto è cambiato. È un FILE A SÉ — i record sono di 208 caratteri, non 1464, e lo standard 005 vieta di mescolare i suoi record U (intestazione), S (modifica) e V (trailer) con i record AFT. Ogni S porta il nuovo numero di routing e il nuovo conto accanto a quelli originali, e il trailer V dichiara quanti S contiene il file. | Valido | |
| CPA-005 — transit 099999999 passes: there is no check digit in CanadaUn file di stipendi cliente→banca che un validatore addestrato sulle regole statunitensi respingerebbe due volte a torto. Il primo accredito passa dal transit 099999999, che non porta alcuna cifra di controllo aritmetica: il DPRN canadese semplicemente non ne ha — lo standard 005 lo valida consultando il Financial Institutions File e lo standard 006 non definisce alcuna formula. Trasporre qui la regola ABA 3-7-1 respinge file perfettamente validi. Gli Item Trace Number sono inoltre lasciati a zero, il che è normale in un file che un cliente invia alla propria banca (li assegna il Direct Clearer): da qui due avvisi e zero errori. | Valido |
File ACH / NACHA (USA) (10)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| ACH — a returned WEB debit (R01, insufficient funds)Un addebito WEB di 123,54 che torna indietro. In un ritorno cambiano tre cose e nient’altro: il transaction code diventa 26 (il codice di ritorno di un addebito su conto corrente — NON il 27 originale), la banca ricevente diventa l’ODFI dell’originale, e viene assegnato un nuovo trace number. L’importo è invariato — l’ACH non conosce il ritorno parziale. L’addenda 99 porta R01 e punta al trace della transazione originale. Il batch resta WEB e resta TRANSFER: non esistono né una descrizione «RETURN» né un codice SEC «RET», per quanto il web sostenga il contrario. | Valido | |
| ACH — a notification of change (C01, corrected account number)Una notifica di modifica — e il punto è che NON è un rifiuto. Il pagamento è andato a buon fine. La banca ricevente chiede di correggere il dato memorizzato prima del PROSSIMO pagamento: rinviare questo pagherebbe il beneficiario due volte. Ecco perché la transazione porta importo ZERO e il batch ha codice SEC COR. L’addenda 98 porta C01 con il numero di conto corretto nelle posizioni 36-52 del record. | Valido | |
| ACH — an international entry (IAT) with its seven mandatory addendaUn pagamento USD → MXN verso il Messico. Un record IAT non è quello domestico con etichette diverse: il numero di conto si sposta alle posizioni 40-74 (35 caratteri, per contenere un conto estero), le posizioni 13-16 dichiarano quanti addenda seguono, e il nome del beneficiario non è affatto nel record — vive nell’addenda 10. Sette addenda (dal 10 al 16) sono obbligatori su ogni transazione internazionale, perché un record di 94 caratteri non può contenere nome, indirizzo e identificazione bancaria di entrambe le parti. Leggere questo file con gli offset domestici restituisce un frammento del numero di conto come se fosse il nome di una persona. | Valido | |
| ACH — PPD payroll credits, balanced with an offset debitIl file di riferimento: com'è fatto un file NACHA corretto. Quattro accrediti stipendio PPD (tre su conto corrente, codice 22, uno su conto di risparmio, codice 32) e una quinta transazione — l'addebito di pareggio (offset), codice 27, sul conto dell'azienda stessa per il totale esatto: è ciò che rende il file «bilanciato», ed è per questo che il service class code è 200 (misto) e non 220. Entry hash, totali del Batch Control, totali del File Control e block count tornano tutti, e ogni routing number soddisfa il check digit ABA 3-7-1. | Valido | |
| ACH — CCD corporate debits with an addenda 05 remittanceUn incasso B2B: due addebiti CCD (service class 225, soli addebiti), ciascuno con un addenda 05 che porta la fattura saldata — segmenti RMR e REF, la remittance ASC X12 con cui il cliente corporate riconcilia. Il CCD ammette esattamente UN addenda per transazione: 80 caratteri di informazione di pagamento, non uno di più. Quando il pagatore ha bisogno di più spazio, il codice SEC diventa CTX. Si noti l'addenda record indicator in posizione 79 della transazione: vale 1, e un addenda segue davvero. | Valido | |
| ACH — WEB debits (e-commerce, recurring and single-entry)Quattro addebiti WEB — il codice SEC di un pagamento autorizzato online da un consumatore. Tre escono da conti correnti (codice 27) e uno da un conto di risparmio (codice 37): lo dice il transaction code, e leggerlo come qualcosa di diverso da una tabella è esattamente l'errore che fanno i parser. Le posizioni 77-78 portano il payment type indicator, R per ricorrente e S per pagamento singolo. Le transazioni WEB non portano addenda: l'addenda record indicator resta a 0. | Valido | |
| ACH — CTX with seven addenda 05 carrying an EDI 820Un addebito CTX di 28.750,00 che salda tre fatture in una volta, con l'avviso di remittance ASC X12 820 distribuito su sette addenda 05. CTX è il codice SEC che i parser sbagliano più spesso, perché il record di entrata non significa ciò che significa ovunque altrove: le posizioni 55-58 NON sono l'inizio di un nome, sono il NUMERO di addenda che seguono (qui 0007), e il nome dell'azienda ricevente comincia solo alla 59. Letto con gli offset PPD, il nome esce come «0007GLOBEX CORP» — che è esattamente ciò che mostra il nostro validatore, il quale applica il layout domestico. | Valido | |
| ACH — entry hash mismatch (truncated or tampered file)Un file di accrediti PPD con l'entry hash sbagliato. L'entry hash è la somma dei routing number a 8 cifre di tutte le transazioni, troncata alle ultime dieci cifre — un checksum il cui unico compito è intercettare un file che ha perso, guadagnato o visto alterare una transazione lungo il percorso. Qui il Batch Control e il File Control dichiarano entrambi 28905251 mentre le quattro transazioni sommano 27905251. Gli importi, invece, tornano ancora: ed è proprio il punto, il hash è il controllo che scatta quando nessun altro lo fa. | Non valido | |
| ACH — batch control debit total ≠ the sum of its entriesUn batch di addebiti CCD il cui Batch Control dichiara 18.450,00 mentre le sue due transazioni sommano 28.075,00 — il classico bug del generatore che scrive il trailer prima di aver aggiunto l'ultima transazione. Tutto il resto del file è corretto, compresi i totali del File Control: il validatore segnala quindi esattamente un errore, nominando entrambe le cifre. È la prima causa di rifiuto di un file ACH scritto a mano. | Non valido | |
| ACH — invalid ABA 3-7-1 check digit on an entry routing numberUn file di addebiti WEB in cui una banca ricevente porta 026009594 — un routing number che fallisce il check digit ABA 3-7-1 (quello vero è 026009593). È sbagliata solo la posizione 12 della transazione, quindi l'entry hash e tutti i totali di controllo tornano ancora: il check digit è l'unico controllo che intercetta una cifra digitata male, e questo file lo dimostra — i totali, da soli, non la vedranno. Le altre due transazioni e tutti i trailer sono corretti: il validatore segnala esattamente un errore. | Non valido |
QR code di pagamento (EPC / QR-fattura svizzera) (6)
| File di esempio | Risultato atteso | Scarica il file |
|---|---|---|
| EPC QR code — version 002 with a structured creditor reference (RF)Un payload di QR code EPC (SCT QR) conforme, versione 002 — quella in cui il BIC è facoltativo, e qui è omesso. La causale è un riferimento creditore strutturato ISO 11649, RF6518539007547034, con cifre di controllo mod-97 corrette: 94 byte sui 331 ammessi. | Valido | |
| EPC QR code — version 001 (BIC mandatory) with a free-text messageL’altra metà di EPC069-12: la versione 001, in cui il BIC del beneficiario è obbligatorio (è l’unica differenza tra 001 e 002), con una causale libera al posto di un riferimento. Riferimento strutturato e testo libero si escludono a vicenda: un QR code porta l’uno o l’altro, mai entrambi. | Valido | |
| EPC QR code — 312 characters but 338 bytes: over the 331-byte capLa trappola che la specifica enuncia e in cui le implementazioni cadono lo stesso: EPC069-12 limita il payload a 331 BYTE, non caratteri. Questo payload polacco ha 312 caratteri — ampiamente sotto qualsiasi conteggio — ma ogni lettera accentata costa due byte in UTF-8: pesa 338 byte e viene respinto. | Non valido | |
| Swiss QR-bill — QR-IBAN with a QRR reference (the pairing rule, satisfied)La QR-fattura svizzera canonica: un QR-IBAN (ID istituto 31999, dentro l’intervallo 30000-31999) abbinato al riferimento QRR che esige — 26 cifre più una cifra di controllo in modulo 10 ricorsivo, non il mod-97 del mondo IBAN. Si noti il blocco «ultimate creditor»: sette righe, presenti e del tutto vuote, come impongono le linee guida. | Valido | |
| Swiss QR-bill — normal IBAN with an ISO 11649 (SCOR) referenceL’altra metà della regola di abbinamento: un IBAN normale (ID istituto 00791, fuori dall’intervallo QR-IID) VIETA un riferimento QRR e accetta un riferimento creditore ISO 11649 (SCOR) — RF6518539007547034 — o nessuno. Stessa fattura, altro tipo di conto, altro riferimento: da questa distinzione dipende se un pagamento svizzero può essere contabilizzato. | Valido | |
| Swiss QR-bill — QR-IBAN carrying a SCOR reference (the pairing rule, broken)L’errore dalle conseguenze più pesanti del formato svizzero: un QR-IBAN che porta un riferimento ISO 11649 (SCOR). Il riferimento in sé è perfettamente valido — ecco la trappola — ma un QR-IBAN esige un riferimento QRR e nient’altro. La banca non può contabilizzare il pagamento, e il verdetto è identico sotto le linee guida 2.3 e 2.4. | Non valido |
Come sappiamo che questi risultati reggono
Ogni file di questa libreria passa nel validatore del sito a ogni build. Il risultato atteso indicato sopra è verificato da un test automatico: se un file smettesse di corrispondere a quanto afferma questa pagina, la build fallirebbe. Due fixture ereditate sono state riparate così prima della pubblicazione: tre IBAN non superavano il mod-97 e diversi nomi usavano caratteri fuori dal set SEPA di base.