Biblioteca de ficheiros de exemplo
Ficheiros SEPA, camt.053, UBL, MT940 e Factur-X prontos a usar — válidos para começar, propositadamente partidos para testar. Cada ficheiro é verificado pelo validador a que pertence.
Ficheiros de exemplo SEPA e faturação eletrónica
Ficheiros SEPA, camt.053, UBL, MT940 e Factur-X prontos a usar — válidos para começar, propositadamente partidos para testar. Cada ficheiro é verificado pelo validador a que pertence.
129
Ficheiros de exemplo
92
Válido
37
Inválido
Transferência SEPA (pain.001) (12)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| pain.001.001.03 — valid credit transferUma transferência SEPA válida em pain.001.001.03: três transferências no total de 1 580,00 EUR, totais de controlo coerentes, IBAN que passam no mod-97 e nomes no conjunto de caracteres SEPA básico. | Válido | |
| pain.001.001.09 — valid, hybrid addressUma transferência pain.001.001.09 válida, com BICFI e o endereço postal híbrido permitido pela EPC153-22 v2.1: TwnNm e Ctry, mais no máximo dois AdrLine de 70 caracteres ou menos. | Válido | |
| pain.001.001.03 — CtrlSum mismatchUm pain.001 cuja soma de controlo mente: CtrlSum declara 1 000,00 EUR quando as transações totalizam 1 500,00 EUR. A divergência é assinalada duas vezes, no lote de pagamentos e no cabeçalho do ficheiro. | Inválido | |
| pain.001.001.03 — invalid IBANUm pain.001 com um IBAN de credor cujos dois dígitos de controlo falham o teste mod-97 (ISO 7064). Todo o resto está correto, pelo que o validador assinala exatamente um erro. | Inválido | |
| pain.001.001.03 — NbOfTxs mismatchUm pain.001 que se conta mal: NbOfTxs declara uma transação enquanto o ficheiro contém duas. Tal como o CtrlSum, a contagem é verificada no lote de pagamentos e no cabeçalho. | Inválido | |
| pain.001.001.03 — unstructured address after 2026-11-15O caso de referência da regra EPC de endereço estruturado: os endereços têm apenas AdrLine, sem TwnNm. O que o torna um erro bloqueante é a data de execução dentro do ficheiro (ReqdExctnDt = 2026-11-20, posterior ao limite de 15/11/2026) — com uma data anterior, o mesmo ficheiro gera apenas um aviso. | Inválido | |
| pain.001.001.11 — valid, fully structured address, executed after 2026-11-15O ficheiro de referência «pronto para 2026»: uma transferência pain.001.001.11 cuja data de execução (ReqdExctnDt = 2026-11-20) é posterior ao limite EPC de endereço estruturado de 15/11/2026. Todos os endereços de ordenante e beneficiário estão totalmente estruturados — StrtNm, BldgNb, PstCd, TwnNm, Ctry e nem uma única AdrLine. Três transferências, 4 320,00 EUR, zero erros e zero avisos. | Válido | |
| pain.001.001.09 — valid, two payment batches with different execution datesUm único ficheiro pain.001, dois blocos PmtInf: o lote A é executado a 10/03/2026 com endereços híbridos (TwnNm + Ctry + uma AdrLine), o lote B a 20/11/2026 com endereços totalmente estruturados. Demonstra as duas lições do ficheiro multilote: a regra EPC de endereço é avaliada lote a lote, com a data que cada lote transporta, e cada PmtInf tem os seus próprios NbOfTxs / CtrlSum além dos totais do GrpHdr (4 transferências, 3 350,00 EUR). | Válido | |
| pain.001.001.03 — nine-character BICUm pain.001 cujo BIC do banco do beneficiário tem nove caracteres. A ISO 9362 admite 8 (instituição + país + localidade) ou 11 (mais um código de balcão de 3 caracteres) — nunca 9 nem 10. «BNPAFRPPX» é o aspeto típico de um código de balcão truncado ou preenchido à mão, e é o defeito que ambas as camadas detetam: o XSD oficial rejeita-o pelo padrão do BIC e a camada de regras pelo comprimento. | Inválido | |
| pain.001.001.03 — accent and ampersand outside the SEPA character setUm pain.001 cujo beneficiário se chama «Café Renard & Fils SARL» — uma letra acentuada e um E comercial, ambos fora do conjunto de caracteres latino básico aprovado pelo EPC (a-z A-Z 0-9 e / - ? : ( ) . , ' + espaço). O XML está bem formado e o XSD oficial aceita-o sem reservas: Max70Text aceita qualquer cadeia. Este defeito vive inteiramente na camada de regras, e é por isso que estes ficheiros chegam ao banco, que os rejeita ou translitera em silêncio. | Inválido | |
| pain.001.001.03 — 250 transfers, high-volume payroll runUm processamento salarial realista: 250 transferências SEPA num único PmtInf, repartidas por cinco países (DE, NL, BE, ES, FR), num total de 442 028,75 EUR. Cada IBAN tem dígitos de controlo mod-97 (ISO 7064) corretos e os dois totais de controlo igualam a soma exata, ao cêntimo. Serve para ver como o seu parser, o seu portal bancário ou as suas ferramentas se comportam num ficheiro que não é nem de brincar nem patológico — e para confirmar que um único cêntimo errado num lote deste tamanho continua a ser apanhado só pelo CtrlSum. | Válido | |
| pain.001.001.03 — unstructured address, executed before 2026-11-15 (warning only)O gémeo da amostra de endereço não estruturado bloqueante, com uma única diferença: a data de execução. Os mesmos endereços reduzidos a AdrLine, mas ReqdExctnDt é 30/09/2026, anterior ao limite da EPC153-22 v2.1: o mesmo defeito volta como dois avisos em vez de dois erros — hoje o pagamento ainda passa. Mostra também o que «estruturado» significa: o endereço do devedor não tem TwnNm nem Ctry, o do credor tem Ctry e continua sem TwnNm. Ctry sozinho não chega: TwnNm é o discriminante. | Válido |
Débito direto SEPA (pain.008) (8)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| pain.008.001.02 — valid CORE direct debitUm débito direto SEPA válido no esquema CORE: duas cobranças recorrentes no total de 175,00 EUR, um Identificador de Credor (ICS) que passa a verificação ISO 7064 MOD 97-10 e um mandato assinado por cada devedor. | Válido | |
| pain.008.001.08 — valid CORE direct debit, collected after 2026-11-15É este o aspeto de um débito direto SEPA conforme após o limite de 15/11/2026: a data de cobrança é 20/11/2026, pelo que todos os endereços de credor e devedor são estruturados (TwnNm + Ctry). Esquema CORE, três cobranças no total de 228,80 EUR, sem avisos. | Válido | |
| pain.008.001.02 — mandate signed after the collectionUm débito cobrado ao abrigo de um mandato que o devedor ainda não tinha assinado: DtOfSgntr é 10/04/2026 mas a cobrança é de 05/03/2026. Um defeito comum e silenciosamente fatal — o ICS, os IBAN e os totais estão todos corretos. | Inválido | |
| pain.008.001.08 — valid B2B direct debit, RCUR sequenceUm débito direto SEPA B2B válido em pain.008.001.08: LclInstrm/Cd = B2B, sequência RCUR, duas cobranças recorrentes no total de 4 650,00 EUR. O esquema B2B é a variante entre empresas — o devedor tem de ser um não consumidor e NÃO tem direito a reembolso após a liquidação, razão pela qual o seu banco verifica o mandato antes de debitar e as cobranças B2B são apresentadas mais cedo do que as CORE. | Válido | |
| pain.008.001.02 — valid CORE direct debit, FRST sequenceUm débito direto SEPA CORE válido com sequência FRST: a primeira cobrança apresentada ao abrigo de um mandato acabado de assinar (a DtOfSgntr é de há poucos dias). Tudo o que se seguir sobre o mesmo mandato tem de sair como RCUR — deixar um lote em FRST para sempre é um dos erros SDD mais comuns e a razão pela qual os bancos devolvem cobranças com um código de sequência incorreta. | Válido | |
| pain.008.001.08 — valid one-off direct debit, OOFF sequenceUm débito direto SEPA pontual válido: sequência OOFF, uma única cobrança de 349,00 EUR. O mandato autoriza exatamente um débito e esgota-se no momento em que é usado — nunca mais pode ser apresentado, nem sequer como RCUR. É a sequência da compra única, do sinal ou da taxa pontual; usar FRST em vez dela deixa aberto, em silêncio, um mandato que o devedor nunca aceitou. | Válido | |
| pain.008.001.02 — mandate identifier (MndtId) missingUm débito sem identificador de mandato: o MndtRltdInf existe e traz uma data de assinatura, mas falta o elemento MndtId (AT-01 do rulebook). O XSD oficial ISO 20022 aceita o ficheiro — o MndtId é opcional no esquema — pelo que uma verificação puramente estrutural o deixa passar e o banco o rejeita: sem referência de mandato, o banco do devedor não tem a que ligar a cobrança e o devedor não tem o que contestar. | Inválido | |
| pain.008.001.02 — NbOfTxs and CtrlSum wrong at both levelsUm débito direto SEPA que se conta e se soma mal, nos dois níveis ao mesmo tempo: o lote tem realmente 2 cobranças no valor de 300,00 EUR, mas o NbOfTxs diz 3 e o CtrlSum diz 250,00 — no PmtInf e de novo no GrpHdr. São quatro erros, não dois: os totais de controlo são verificados no lote de pagamentos E no cabeçalho, porque um ficheiro multilote pode exibir um total de cabeçalho correto assente em dois totais de lote errados. O XML está bem formado e o XSD oficial aceita-o: para um esquema, NbOfTxs e CtrlSum são apenas números. | Inválido |
Extrato bancário (camt.052 / 053 / 054) (12)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| camt.053.001.02 — valid statementUm extrato camt.053.001.02 válido: quatro lançamentos, saldos de abertura e fecho que reconciliam (OPBD ± movimentos = CLBD) e datas em formato Dt. | Válido | |
| camt.053.001.08 — valid statementUm extrato camt.053.001.08 válido: três lançamentos, marcas temporais DtTm e BICFI em vez de BIC — as diferenças em que se tropeça ao passar da versão 02 para a 08. | Válido | |
| camt.053 — unsupported namespaceUm extrato que declara camt.053.001.99, uma versão que não existe no catálogo ISO 20022. Útil para verificar se o seu parser rejeita namespaces desconhecidos em vez de adivinhar. | Inválido | |
| camt.053.001.06 — missing Stmt elementUm extrato com namespace camt.053.001.06 correto mas sem qualquer elemento <Stmt>: o envelope está certo, falta o conteúdo. É este o aspeto de uma exportação bancária truncada. | Inválido | |
| camt.053.001.11 — valid statementUm extrato camt.053.001.11 válido — a versão atual da mensagem de extrato ISO 20022. Quatro lançamentos, OPBD 25 000,00 ± movimentos = CLBD 34 659,05. Repare no que a versão 11 torna obrigatório em cada lançamento: Sts e BkTxCd, que as versões anteriores deixavam omitir. | Válido | |
| camt.053.001.08 — three accounts in one fileUma única mensagem camt.053, três blocos <Stmt>: conta à ordem, conta poupança e conta em USD. O ficheiro é válido face ao esquema; o validador diz explicitamente que analisa apenas o primeiro extrato. É esse o ponto: um leitor que pega em Stmt[0] e para perde duas contas em silêncio, e é este ficheiro multiconta que o denuncia. | Válido | |
| camt.053.001.10 — fully detailed entriesTudo o que um banco pode pendurar num lançamento camt.053, num único ficheiro válido: NtryDtls/TxDtls com EndToEndId, InstrId, TxId e MndtId; RltdPties e RltdAgts; uma referência de credor estruturada ISO 11649 (RF) e uma fatura referenciada (CINV); um lançamento agrupado cujos dois TxDtls somam exatamente o valor do lançamento; e um BkTxCd ISO (PMNT/RCDT/ESCT) acompanhado de um GVC alemão proprietário. Serve para medir quanto a sua reconciliação lê realmente. | Válido | |
| camt.053.001.08 — closing balance does not reconcileO defeito mais frequente nos camt.053 de produção: a abertura de 4 200,00 mais os lançamentos contabilizados dá 5 194,70, enquanto o CLBD declarado diz 5 194,07 — dois algarismos trocados. O ficheiro cumpre na perfeição o XSD oficial ISO 20022, porque um esquema nada tem a dizer sobre aritmética. Só uma reconciliação de saldos apanha um saldo de fecho incoerente. | Válido | |
| camt.052.001.08 — valid intraday reportUm relatório intradiário camt.052 válido — e não é um camt.053 em miniatura: a raiz é BkToCstmrAcctRpt, o contentor é <Rpt> e os saldos são INTERMÉDIOS (ITBD contabilizado, ITAV disponível) em vez do par OPBD/CLBD de um extrato de fim de dia. Traz ainda um lançamento pendente (Sts=PDNG) deliberadamente excluído do saldo intermédio: dinheiro pendente não é dinheiro contabilizado. | Válido | |
| camt.054.001.08 — valid debit/credit notificationUm aviso de débito/crédito camt.054 válido: um crédito SEPA de entrada e um débito direto de saída, cada um com TxDtls completos e referência ponta a ponta. A surpresa estrutural é o que NÃO existe: um camt.054 não tem qualquer elemento <Bal> — o esquema ISO 20022 não define nenhum. Um aviso anuncia movimentos, nunca declara um saldo: não há nada para reconciliar. | Válido | |
| camt.053.001.08 — entry with no CdtDbtIndO segundo lançamento tem um valor de 1 200,00 e nenhum <CdtDbtInd>. Em camt.053 os valores são sempre sem sinal: sem o indicador de sentido, o valor nada significa. Duas coisas quebram ao mesmo tempo — o XSD oficial rejeita o ficheiro (CdtDbtInd é obrigatório 1..1 num lançamento) e um parser que passa silenciosamente para CRDT contabiliza +1 200,00 em vez de −1 200,00, ficando a 2 400,00 da verdade, o que a reconciliação de saldos expõe. | Inválido | |
| camt.053.001.08 — 220 entries, validUm extrato empresarial de fim de mês com 220 lançamentos contabilizados, todos reconciliados: OPBD 125 000,00 ± movimentos = CLBD 209 081,69. Cada lançamento traz NtryDtls/TxDtls, um EndToEndId e uma contraparte — põe à prova um leitor camt.053 com volume realista em vez de um ficheiro de brincar com três linhas: débito de parsing, renderização da tabela e reconciliação sobre centenas de linhas. | Válido |
Fatura UBL (Peppol BIS 3.0) (12)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| UBL Invoice — valid Peppol BIS 3.0Uma fatura Peppol BIS Billing 3.0 válida: três linhas, 2 596,00 EUR com IVA, totais coerentes, número de IVA francês e IBAN de pagamento. | Válido | |
| UBL Credit Note — valid Peppol BIS 3.0Uma nota de crédito Peppol BIS Billing 3.0 válida: uma linha, 1 770,00 EUR com IVA, referenciando a fatura original que anula. A nota de crédito é um tipo de documento UBL próprio, não uma fatura com montantes negativos. | Válido | |
| UBL Invoice — BR-CO-10 violationUma fatura que viola a regra EN 16931 BR-CO-10: a soma dos montantes líquidos de linha (1 000,00) não é igual ao total do documento BT-106 (2 000,00). Uma das rejeições mais frequentes na rede Peppol. | Inválido | |
| UBL Invoice — malformed seller VAT identifierUma fatura cujo número de IVA do vendedor, «FR1234», é demasiado curto: um número francês é FR seguido de uma chave de dois caracteres e nove dígitos. Os erros de formato no BT-31 são apanhados muito antes de chegarem à autoridade fiscal. | Inválido | |
| UBL Invoice — allowances and charges, line and document levelUma fatura UBL Peppol BIS 3.0 válida com descontos e encargos nos DOIS níveis: desconto de linha (BG-27), encargo de linha (BG-28), desconto ao nível do documento (BG-20) e portes (BG-21). O essencial é o encadeamento dos totais: BT-106 = 1 520,00 é a soma dos montantes LÍQUIDOS de linha e BT-109 = 1 530,00 = BT-106 - BT-107 + BT-108 (BR-CO-13), pelo que o IVA de 19 % incide sobre 1 530,00 e não sobre 1 520,00. | Válido | |
| UBL Invoice — reverse charge (VAT category AE)Uma fatura válida com autoliquidação em UBL: um fornecedor francês fatura serviços a uma empresa alemã, o IVA é liquidado pelo cliente, pelo que a taxa é 0 % e não há IVA cobrado. A categoria AE traz quatro regras: os dois números de IVA (BR-AE-02, BR-AE-03), a taxa 0 % (BR-AE-05), um montante de imposto de 0,00 (BR-AE-09) e um motivo de isenção (BR-AE-10), aqui VATEX-EU-AE e o texto «Reverse charge». | Válido | |
| UBL Invoice — VAT exempt (category E) with exemption reasonUma fatura isenta de IVA válida (categoria E): formação profissional isenta ao abrigo do artigo 132.º, n.º 1, alínea i) da Diretiva 2006/112/CE. Uma fatura isenta tem de dizer PORQUÊ: a BR-E-10 exige um código de motivo de isenção (BT-121) ou um texto (BT-120) — e este ficheiro traz ambos: VATEX-EU-132 e a redação da lista de códigos oficial. | Válido | |
| UBL Invoice — intra-Community supply (VAT category K)Uma transmissão intracomunitária válida (categoria de IVA K): bens expedidos da Alemanha para um adquirente registado em IVA em França, isentos ao abrigo do artigo 138.º da Diretiva 2006/112/CE. A categoria K exige dois dados que se esquecem: BR-IC-11, uma data de entrega efetiva (BT-72) ou um período de faturação, e BR-IC-12, o país de entrega (BT-80). Sem eles, a fatura não prova que os bens saíram do país. | Válido | |
| UBL Invoice — two VAT rates, one breakdown per rateUma fatura válida que combina a taxa normal francesa (20 %) e a taxa reduzida (5,5 %). A regra em causa é a BR-S-08: a discriminação do IVA (BG-23) traz UM TaxSubtotal por par (categoria, taxa) e cada base tributável é a soma das linhas desse par — 1 500,00 a 20 % (IVA 300,00) e 400,00 a 5,5 % (IVA 22,00). Fundir duas taxas num único subtotal passa todos os controlos BR-CO e continua errado. | Válido | |
| UBL Invoice — BR-CO-10, line sum does not equal BT-106A rejeição mais frequente em produção, isolada: as duas linhas somam 1 500,00 mas o BT-106 (LineExtensionAmount) declara 1 400,00 — BR-CO-10. Tudo o resto é coerente com o valor ERRADO, pelo que BR-CO-13, BR-CO-14, BR-CO-15 e BR-CO-16 passam e volta exatamente um erro. É o aspeto de uma linha apagada depois de calculados os totais. | Inválido | |
| UBL Invoice — exempt VAT without an exemption reason (BR-E-10) and a wrong exempt base (BR-E-08)Uma fatura isenta errada, duas vezes. BR-E-10: a discriminação de IVA da categoria E não traz motivo de isenção (BT-120) nem código de motivo (BT-121) — uma fatura isenta tem de dizer PORQUÊ. BR-E-08: a base isenta declara 1 200,00 enquanto as linhas isentas somam 1 500,00, porque a segunda linha nunca entrou na discriminação. O erro citado é o da camada de regras de negócio; o Schematron oficial EN 16931 acrescenta a BR-E-10. | Inválido | |
| UBL Invoice — BR-CO-17, VAT amount does not equal base x rateUma discriminação de IVA que não bate certo: uma base de 2 000,00 a 19 % dá 380,00 de IVA, mas a fatura declara 395,00. A BR-CO-17 verifica que o imposto da categoria = base × taxa / 100, com a margem oficial de uma unidade monetária — um cêntimo genuíno de arredondamento é tolerado, esta diferença de 15,00 não. Todos os outros totais acompanham o valor errado: é assim que um bug de arredondamento chega à produção. | Inválido |
Fatura CII (sintaxe XRechnung / Factur-X) (4)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| CII CrossIndustryInvoice — XRechnung 3.0, validUma fatura XRechnung 3.0 válida em sintaxe CII (UN/CEFACT CrossIndustryInvoice), a fatura eletrónica do setor público alemão. Traz o que as regras BR-DE da KoSIT acrescentam à EN 16931: o Leitweg-ID como referência do comprador (BR-DE-15), um contacto do vendedor completo — nome, telefone e e-mail (BR-DE-2 a BR-DE-6), o endereço eletrónico do vendedor, condições de pagamento estruturadas e uma transferência SEPA (meio de pagamento 58). | Válido | |
| CII CrossIndustryInvoice — Factur-X 1.0 BASIC, valid (standalone XML)O payload Factur-X / ZUGFeRD sozinho: o XML CII que normalmente viaja embutido num PDF/A-3, aqui como ficheiro autónomo validável diretamente. O perfil BASIC (BT-24 = urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic) é um CIUS conforme à EN 16931 — linhas de fatura completas, discriminação de IVA integral e os seis totais do documento. Útil para testar um extrator apenas com o XML, sem o PDF pelo meio. | Válido | |
| CII CrossIndustryInvoice — BR-CO-10, line sum does not equal BT-106BR-CO-10 em sintaxe CII: as duas linhas somam 2 000,00 mas o LineTotalAmount (BT-106, dentro de SpecifiedTradeSettlementHeaderMonetarySummation) declara 1 900,00. O mesmo defeito da amostra UBL, na sintaxe em que é mais difícil de ver — os totais do documento vivem num ramo da árvore diferente das linhas que resumem. | Inválido | |
| CII CrossIndustryInvoice — BR-CO-13, the discount never reaches the tax basisUm desconto ao nível do documento que só existe a meio: a fatura concede 200,00 (BT-107), calcula o IVA sobre a base com desconto (1 800,00 × 19 % = 342,00 — correto), mas o BT-109 (TaxBasisTotalAmount) continua a declarar 2 000,00 sem desconto. A BR-CO-13 impõe BT-109 = BT-106 - BT-107 + BT-108, pelo que o comprador é faturado em 200,00 que o vendedor julgava ter oferecido. | Inválido |
Extrato SWIFT MT940 (10)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| MT940 — Rabobank / Deutsche Bank dialectO caso nominal MT940: um extrato, um crédito e um débito, com o par referência cliente / referência banco na linha :61:. Comece por aqui para ver a estrutura das tags antes dos dialetos. | Válido | |
| MT940 — ING Belgium, structured :86:O dialeto do ING Bélgica: a linha de informação :86: está estruturada em subcampos ?00 ?20 ?30 em vez de texto livre. É a maior fonte de bugs de parsing MT940. | Válido | |
| MT940 — Commerzbank, one-decimal amountO dialeto Commerzbank: um montante com uma única casa decimal (1234,5 para 1 234,50), um tipo de transação NMSC e uma conta alemã dada como BLZ + número em vez de IBAN. | Válido | |
| MT940 — two statements in one fileDois extratos dentro de um mesmo ficheiro MT940, mais a tag de saldo disponível :64:. Um ficheiro não é um extrato, e um parser que o assuma perderá o segundo em silêncio. | Válido | |
| MT940 — reversal (RC) and intermediate balancesO caso ABN AMRO: um estorno RC (um crédito revertido em débito), saldos intermédios 60M/62M em vez de F e um :86: em duas linhas. Os estornos invertem o sinal — errar aqui é ter um saldo que nunca reconcilia. | Válido | |
| MT940 — overdrawn account (debit balances)Uma conta a descoberto: os saldos de abertura e de fecho têm ambos o marcador D (devedor). Em MT940 um saldo negativo não é um número negativo, é uma marca de sinal — código que a ignora apresenta o descoberto como saldo credor. | Válido | |
| MT940 — closing balance does not reconcileUm extrato cujo saldo de fecho não decorre da abertura ± movimentos. É deliberadamente um aviso e não um erro bloqueante: o ficheiro continua legível e cabe a uma pessoa decidir se a falha é do banco ou da exportação. | Válido | |
| MT940 — 500 transactions (load test)Quinhentas transações num único extrato, certas ao cêntimo. Use-o para verificar se o seu parser se mantém exato — e rápido — a volume real, e não apenas num ficheiro de brincar de três linhas. | Válido | |
| MT940 — statement split over two pages (62M / 60M)Um extrato, um dia, duas páginas: a sequência 00147/00001 fecha num saldo INTERMÉDIO :62M: e a sequência 00147/00002 reabre em :60M: com exatamente esse valor antes de fechar no :62F: final. M não é F: tomar o saldo intermédio pelo final do dia é declarar 37 500,00 quando a conta terminou em 44 249,25. | Válido | |
| MT940 — USD account with an RD reversalUm extrato em dólares — o MT940 não é um formato euro — em que uma transferência emitida de 35 000,00 é devolvida no dia seguinte por um estorno RD: um DÉBITO ESTORNADO é dinheiro que VOLTA a entrar. As marcas RC/RD invertem o sentido económico da linha :61:, e um parser que lê apenas o D de «RD» lança o reembolso de novo como pagamento e nunca reconcilia. | Válido |
Extrato BAI2 (EUA / Canadá) (6)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| BAI2 — US bank daily statement (nominal case)O ficheiro BAI2 nominal: uma conta, um saldo de abertura 010 e de fecho 015, e dez movimentos cujo sentido vem apenas do type code — 115 depósito lockbox, 165 crédito ACH, 195 transferência recebida, 475 cheque pago, 451 débito ACH, 495 transferência emitida, 698 encargos. O BAI2 não tem indicador débito/crédito: 100–399 é entrada, 400–699 saída. | Válido | |
| BAI2 — several accounts in one groupDois registos de conta 03 dentro de um mesmo grupo 02 — uma conta operacional e uma conta de salários, cada uma fechada pelo seu próprio trailer 49. O BAI2 é hierárquico (01 ficheiro / 02 grupo / 03 conta / 16 movimento / trailers 49-98-99): quem assumir uma conta por ficheiro perde a segunda em silêncio. | Válido | |
| BAI2 — 88 continuation recordsO registo de continuação 88 nos seus dois papéis, muito diferentes: traz tuplos de saldo adicionais a um registo de conta 03 (aqui o fecho 015 e o disponível 045) e texto livre partido em várias linhas para um movimento 16 (três linhas físicas, uma só cadeia de descritivo). Juntá-los da mesma forma é ler os saldos como texto — ou o texto como saldos. | Válido | |
| BAI2 — CAD and JPY: minor units scale with the currencyOs montantes BAI2 não têm separador decimal: são unidades menores, e quantas casas decimais implicam depende da moeda. Aqui «2500000» são 25 000,00 CAD na conta CAD (2 casas) e ¥2 500 000 na conta JPY (0 casas). A conta CAD deixa ainda o campo de moeda vazio e herda-o do cabeçalho de grupo 02. Uma divisão por 100 fixa corrompe a conta em ienes em duas ordens de grandeza — e o saldo continua a reconciliar, porque os três números erram pelo mesmo fator. | Válido | |
| BAI2 — closing balance does not reconcileO saldo de fecho 015 não decorre do saldo de abertura 010 mais os movimentos 16 — 50 000,00 + 10 000,00 − 2 500,00 dão 57 500,00, mas o ficheiro declara 59 000,00. Os trailers continuam certos: só a aritmética o denuncia. Deliberadamente um aviso e não um erro bloqueante: o ficheiro é legível e cabe a uma pessoa decidir se a falha é do banco ou da exportação. | Válido | |
| BAI2 — bad trailer totals and an out-of-range type codeTrês defeitos de uma vez. O trailer de conta 49 declara um total de controlo e um número de registos que não correspondem aos registos acima — os trailers são a verificação de integridade do próprio ficheiro, e quem os ignora não vê um truncamento. E um movimento 16 traz o type code 720, na faixa de empréstimos 700–799: não é crédito (100–399) nem débito (400–699), o sentido não pode ser inferido e o registo é descartado em vez de adivinhado — daí o saldo também já não reconciliar. | Válido |
Factur-X / ZUGFeRD (PDF) (2)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| Factur-X EN 16931 — valid hybrid invoiceUma fatura Factur-X válida no perfil EN 16931: um PDF/A-3 com o XML CII incorporado. Um único documento que uma pessoa lê e uma máquina processa — é esse todo o propósito do formato híbrido. | Válido | |
| Factur-X EN 16931 — BR-CO-15 violationUma fatura Factur-X que viola a regra EN 16931 BR-CO-15: o total com IVA é 130,00 quando a base mais o IVA somam 120,00. O PDF abre e parece perfeitamente normal — só o XML incorporado o denuncia. | Inválido |
Fatura KSeF (Polónia, FA(3)) (7)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| KSeF FA(3) — valid invoice (official MF example)Uma fatura estruturada FA(3) conforme — o exemplo n.º 4 do próprio Ministério das Finanças polaco, reproduzido sem alterações. Três linhas, 64 279,92 PLN com IVA a 23%. Referência do que o KSeF aceita. | Válido | |
| KSeF — invoice still using the retired FA(2) schemaA falha de migração para o KSeF mais comum: uma fatura perfeitamente bem formada que ainda declara o namespace FA(2), retirado a 1 de fevereiro de 2026. Nada parece errado até o KSeF a rejeitar. Repare no que o FA(3) acrescentou e aqui falta: Podmiot2 exige agora JST e GV. | Inválido | |
| KSeF FA(3) — bad NIP check digit and mismatched total (warnings only)Estruturalmente perfeita face ao esquema oficial e, ainda assim, o NIP do vendedor falha o dígito de controlo mod-11 e o P_15 não corresponde à soma da repartição do IVA. O ValidateFin reporta ambos como avisos, não erros: nenhuma das regras é normativa, e o exemplo n.º 1 do Ministério está ele próprio desviado um grosz. | Válido | |
| KSeF FA(3) — correcting invoice (faktura korygująca, KOR)Uma fatura retificativa (RodzajFaktury = KOR), o caso FA(3) mais procurado e mais vezes mal construído. Os totais transportam a DIFERENÇA, não a fatura corrigida: P_13_1, P_14_1 e P_15 são negativos. Surgem ainda PrzyczynaKorekty, TypKorekty e DaneFaKorygowanej, que remetem para a fatura corrigida. As linhas vêm aos pares: a que tem StanPrzed é o estado anterior. | Válido | |
| KSeF FA(3) — prepayment invoice (faktura zaliczkowa, ZAL)Uma fatura de adiantamento (RodzajFaktury = ZAL): fatura um sinal sobre uma encomenda ainda não entregue. Por isso não tem NENHUMA linha FaWiersz — os bens estão no bloco Zamowienie (encomenda), com as suas etiquetas P_7Z / P_11NettoZ / P_11VatZ — enquanto o P_15 mostra apenas o adiantamento de 12 300,00 PLN sobre uma encomenda de 61 500,00 PLN. | Válido | |
| KSeF FA(3) — mandatory element missing (rejected by the official XSD)Uma fatura FA(3) à qual falta um elemento obrigatório: P_2, o número da fatura. Nada parece errado — XML bem formado, namespace correto, repartição de IVA plausível — e só o XSD oficial do Ministério das Finanças o apanha: «Element P_6: this element is not expected. Expected is P_2.» O KSeF rejeita liminarmente um ficheiro destes. | Inválido | |
| KSeF FA(3) — buyer NIP failing its mod-11 check digit (warning only)O NIP do comprador é 1111111112 — dez dígitos, pelo que o esquema oficial, que apenas o restringe por um padrão, o aceita sem uma palavra. O dígito de controlo mod-11 não bate certo: não pode existir tal número fiscal polaco, e a fatura não é dirigida a ninguém. O ValidateFin emite um aviso, nunca um erro — o Ministério não publica nenhuma regra de validação dessas. | Válido |
Fatura FatturaPA (Itália, SdI) (4)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| FatturaPA FPR12 — conformant invoice to a private partyUma FatturaPA que o SdI aceitaria: aritmética de IVA correta (duas linhas a 22 % que somam 1.100 €, 242 € de imposto, 1.342 € de total), identificadores fiscais com dígito de controlo válido e um CodiceDestinatario de 7 caracteres, como exige um destinatário privado. É o ponto de referência: os restantes exemplos são este ficheiro, partido de uma forma concreta. | Válido | |
| FatturaPA — signed CAdES (.p7m) envelopeA mesma fatura conforme, envolvida num envelope de assinatura CAdES (.p7m): é assim que viajam a maioria das faturas italianas reais, e é obrigatório para qualquer fatura dirigida à Administração Pública. Aberto num editor de texto, o ficheiro é só ruído binário. O validador abre o envelope e verifica o XML lá dentro; não verifica a assinatura em si, e di-lo. | Válido | |
| FatturaPA — XSD-valid, rejected by the SdI (00421, 00422, 00445)Esta fatura é VÁLIDA face ao XSD oficial e o SdI rejeitá-la-ia na mesma — é precisamente por isso que uma verificação apenas de esquema não chega. Três defeitos: a base tributável declara 1.150 € face a linhas que somam 1.100 € (controlo 00422, cuja tolerância é de um EURO, não de um cêntimo); o imposto declara 250 € onde 22 % de 1.150 € dá 253 € (00421); e o código Natura é o N3 genérico, retirado em 1 de janeiro de 2021 a favor dos seus subcódigos (00445), embora continue na enumeração do esquema. | Inválido | |
| FatturaPA FPA12 — wrong CodiceDestinatario length (00427)A forma mais comum de uma fatura dirigida a uma administração italiana ser devolvida: o CodiceDestinatario. Para uma PA (FormatoTrasmissione = FPA12) tem de ser o código de repartição IPA de SEIS caracteres — a forma de sete pertence a destinatários privados. O XSD permite 6 OU 7 para ambos, pelo que o esquema não o vê; só o controlo 00427 do SdI o vê. O número da fatura, «FATTURA», também não contém qualquer dígito (00425). | Inválido |
Fatura RO e-Factura (Roménia, ANAF) (6)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| RO e-Factura — conformant invoice (FACT1)Uma fatura que a ANAF aceita — o seu próprio validador offline responde « este valid ». É o exemplo publicado pelo Ministério, reparado nos dois pontos que fazem falhar a versão publicada: BT-24 reposto em CIUS-RO:1.0.1 e dois CUI cujo dígito de controlo é realmente correto. É o ponto de referência: cada amostra partida é este ficheiro, danificado de forma precisa. | Válido | |
| RO e-Factura — credit note in a foreign currency (FCN)Uma nota de crédito (FCN) emitida em SEK — e a ANAF aceita-a. Mostra o que a BR-RO-030 exige realmente: RON tem de aparecer como moeda da fatura (BT-5) OU como moeda de contabilização do IVA (BT-6), não necessariamente ambas. Aqui BT-5 é SEK e BT-6 é RON, o que cumpre a regra. Traz ainda o código de tipo 381, lícito numa nota de crédito e proibido numa fatura. | Válido | |
| RO e-Factura — BT-24 still declaring CIUS-RO:1.0.0 (BR-RO-001)A rejeição romena mais frequente, e o único defeito deste ficheiro: BT-24 continua a dizer CIUS-RO:1.0.0, um valor retirado em 29 de dezembro de 2022 (ordem OMF 4092/2022). A fatura é impecável no resto e passa o XSD. Os dois exemplos que o Ministério ainda publica têm este defeito — e o seu próprio validador rejeita-os. | Inválido | |
| RO e-Factura — Bucharest written “Sector 1” instead of SECTOR1 (BR-RO-100)Um vendedor em Bucareste cuja cidade (BT-37) diz «Sector 1» — a grafia exata usada pela própria ordem ministerial. O Schematron que a ANAF executa realmente exige SECTOR1: maiúsculas, sem espaço. Quando o texto da lei e a implementação divergem, é a implementação que rejeita a sua fatura. | Inválido | |
| RO e-Factura — buyer CUI with a wrong check digit (ERRIdentif)A amostra que revela o ponto cego de qualquer validador que só corre o Schematron. O CUI do comprador (RO987456123) tem um dígito de controlo errado — e NENHUMA regra do Schematron olha para ele. Este ficheiro passa o XSD, passa todo o corpo de regras CIUS-RO, e a ANAF rejeita-o na mesma, com um código próprio: ERRIdentif, « CUI cumparator incorect ». | Inválido | |
| RO e-Factura — B2C invoice with the anonymous CNP (0000000000000)Uma fatura B2C cujo comprador é um particular, identificado pelo CNP anónimo de treze zeros — em produção desde 16 de dezembro de 2024. É válida, e um validador que o tomasse por um número pessoal malformado partiria toda a faturação a consumidores na Roménia: esse número não cumpre nenhuma regra de forma do CNP (o seu primeiro dígito, 0, é recusado em todo o resto), porque é um valor reservado, não um CNP. | Válido |
Registo de faturação Verifactu (Espanha, AEAT) (3)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| Verifactu — envío conforme, dos registros encadenadosUm envio que a AEAT aceitaria: dois registos de faturação corretamente encadeados. O primeiro declara-se o primeiro da cadeia e calcula a impressão com o campo anterior vazio; o segundo encadeia a impressão do primeiro. Ambas as impressões são reais (SHA-256 sobre a cadeia exata especificada pela AEAT), não inventadas. | Válido | |
| Verifactu — cadena de huellas rota (aceptado con errores, código 2000)O segundo registo declara uma impressão que NÃO corresponde ao seu conteúdo: a cadeia está partida. O ficheiro é VÁLIDO face ao XSD oficial da AEAT — um validador que só olhe para o esquema aprova-o. Só o recálculo do SHA-256 encadeado o deteta. E atenção: a AEAT não o rejeita, marca-o como «Aceptado con errores» (código 2000) e regista-o na mesma. | Válido | |
| Verifactu — la AEAT lo rechazaría (códigos 1190 y 1142)Uma fatura simplificada (F2) que traz um bloco Destinatarios — proibido, código 1190 — e cuja CuotaRepercutida (100 €) não corresponde à base × taxa (1 000 € × 21 % = 210 €), muito além da tolerância de ±10 € do controlo 1142. O ficheiro PASSA o XSD oficial sem uma queixa: o esquema não consegue vê-lo, a AEAT rejeita-o. | Inválido |
Fatura Facturae (Espanha, FACe) (2)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| Facturae 3.2.2 — factura B2G conforme y firmadaUma fatura Facturae 3.2.2 dirigida a uma administração pública (com os seus centros administrativos DIR3, como exige o FACe) que passa o XSD oficial de facturae.gob.es sem uma queixa, com todos os totais coerentes segundo as fórmulas do próprio esquema e uma assinatura XAdES presente. É o ponto de referência: o outro exemplo é o mesmo ficheiro, partido de uma forma concreta. A assinatura é de amostra: a sua validade criptográfica não é verificada offline. | Válido | |
| Facturae 3.2.2 — totales incoherentes (válida contra el XSD)O mesmo ficheiro, com uma única alteração: InvoiceTotal declara 1200,00 € onde a fórmula do esquema dá 1210,00 € (base 1000 + IVA 210). O ficheiro é VÁLIDO face ao XSD oficial de facturae.gob.es — um validador que só olhe para o esquema aprova-o. Só a camada de coerência o deteta, e assinala ainda que o total do lote já não bate certo. Não é uma rejeição « oficial »: Facturae/FACe não publica códigos de rejeição verificáveis offline, por isso é um aviso, não um erro. | Válido |
Extrato CODA (Bélgica) (6)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| CODA — Belgian statement with a valid structured communicationUm extrato belga comum: uma transferência SEPA com uma comunicação estruturada válida (+++090/9337/55493+++), um pagamento com cartão e uma transferência recebida com a sua contraparte. Saldo inicial 1 000,00 − 250,00 − 89,90 + 1 500,00 = saldo final 2 160,10, e os totais do trailer coincidem. | Válido | |
| CODA — globalised salary run (booked total + its details)Uma globalização: um total de salários contabilizado de 3 000,00 (número de detalhe 0000) seguido dos dois salários individuais que o compõem (0001, 0002). Só o total é contabilizado — um parser que some também os detalhes duplica o ficheiro e o extrato deixa de fechar. Encerra com um saldo devedor de 2 000,00. | Válido | |
| CODA — wrong mod-97 check digits and a statement that does not balancePartido de propósito. A comunicação estruturada termina em 94 onde o mod 97 exige 93 — a causa mais frequente de um pagamento belga nunca ser reconciliado com a sua fatura — e o saldo final não decorre dos movimentos. Nenhuma outra ferramenta CODA gratuita verifica estes dígitos de controlo. | Válido | |
| CODA — Belgian OGM (+++…+++) and ISO 11649 RF reference, both checksummedUm extrato CODA com as duas referências estruturadas que o formato permite, cada uma com o seu dígito de controlo: uma transferência emitida com comunicação estruturada belga +++090/9337/55493+++ (tipo 101, mod 97 — um resto de 0 escreve-se 97, não 00) e uma transferência recebida com referência de credor ISO 11649 RF73INV20260042 (tipo 100, mod 97-10). Ambas são válidas e o extrato fecha: 1 000,00 − 250,00 + 1 500,00 = 2 250,00. | Válido | |
| CODA — separate application: balances zeroed by design (§7.2.1)Uma «separate application» CODA (posições 84-88 do cabeçalho = 00001): uma liquidação de aceitação de cartões entregue fora do extrato de conta. O §7.2.1 da Febelfin coloca a zero os saldos inicial e final por construção, pelo que a identidade saldo inicial ± movimentos = saldo final não pode verificar-se — e não deve ser testada. O ValidateFin ignora-a aqui e declara o ficheiro limpo; um validador que não a ignore assinala como partido todo o ficheiro deste tipo. | Válido | |
| CODA — old balance ± movements ≠ new balanceUm extrato belga comum — a que falta um movimento. Os registos 2.1 somam 1 000,00 − 250,00 + 1 500,00 = 2 250,00, mas o registo «8» de saldo final declara 2 200,00: 50,00 de movimento contabilizado nunca chegaram ao ficheiro. É esta a verificação que apanha um CODA truncado, um registo perdido ou um sinal débito/crédito mal lido — e a razão pela qual a amostra anterior NÃO deve ser verificada da mesma forma. | Válido |
Extrato CFONB 120 (França) (5)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| CFONB 120 — statement with its SEPA supplement recordsUm extrato francês com todos os seus dados SEPA: um débito direto com a referência do mandato e a sequência RCUR, o nome do credor, um pagamento com cartão e uma transferência recebida com o nome do pagador, a referência end-to-end, a finalidade e o descritivo — tudo em registos «05». Saldo inicial 1 000,00 − 250,00 − 89,90 + 1 500,00 = saldo final 2 160,10. | Válido | |
| CFONB 120 — amount without its overpunched signPartido de propósito, e é a forma clássica de corromper um ficheiro CFONB: o montante do débito termina num dígito simples em vez de num carácter de sinal sobreposto, pelo que o ficheiro nunca diz que é um débito. É lido como um crédito — e é a identidade contabilística exigida pelo CFONB que o apanha. | Válido | |
| CFONB 120 — the "05" supplements: RUM, IBE, NBE, REF, LIB, NPY, IPY, RCN, LCC/LC2, CPYOs dados SEPA de um extrato CFONB 120 vivem nos registos «05», e cada qualificador corta de maneira diferente a mesma zona de 70 caracteres (posições 49-118): RUM leva uma referência de mandato E o seu tipo de sequência (RCUR), REF uma referência de lote E uma de operação, RCN um identificador ponto a ponto E um propósito, enquanto NBE, NPY e LIB ocupam a zona inteira. Lida de forma plana, a zona cola o mandato ao seu tipo de sequência. Este ficheiro traz um débito direto SEPA (operação B1) e uma transferência recebida, com dez qualificadores diferentes entre os dois. | Válido | |
| CFONB 120 — two accounts (two 01…07 blocks) in one fileUm único ficheiro CFONB 120, duas contas: cada uma forma o seu próprio bloco 01 (saldo inicial) … 07 (saldo final) e fecha por si só. A segunda abre A DESCOBERTO — o saldo inicial traz um sinal sobreposto da família «}», ou seja um débito — e recupera para um saldo credor de 179,60. Um parser que mantenha um único saldo corrente para todo o ficheiro, ou que leia o carácter de sinal como um dígito, erra nas duas contas. | Válido | |
| CFONB 120 — the new balance does not equal old balance ± movementsAqui todos os montantes trazem um sinal sobreposto correto — e mesmo assim o extrato não fecha: 1 000,00 − 89,90 + 500,00 = 1 410,10, enquanto o registo «07» declara 1 310,10. A regra 2 do §1 da especificação CFONB enuncia essa identidade como a DEFINIÇÃO de um extrato conforme: não é uma heurística, faltam 100,00 de movimento no ficheiro. | Válido |
Mensagem Fedwire ISO 20022 (EUA) (6)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| Fedwire pacs.008 — conformant customer credit transferUma transferência de cliente com cabeçalho BAH e endereços postais híbridos — já cumpre o formato exigido a partir de 16 de novembro de 2026. | Válido | |
| Fedwire pacs.009 — conformant bank-to-bank transferUma transferência entre instituições financeiras: o troço interbancário, em que devedor e credor são bancos. | Válido | |
| Fedwire pacs.008 — unstructured address, settling after 16/11/2026O endereço do credor tem três linhas livres, sem cidade nem país. Válido face ao XSD, rejeitado pela regra: a partir de 16 de novembro de 2026 a Fedwire elimina o endereço totalmente não estruturado. | Inválido | |
| Fedwire pacs.008 — same unstructured address, settling before the cut-overO contraexemplo: exatamente o mesmo endereço não estruturado, mas com liquidação em 30/06/2026. É legal, pelo que apenas avisa. O gatilho é a data de liquidação do mensagem, nunca a data de hoje. | Válido | |
| Fedwire pacs.008 — routing number that cannot existO routing number do banco do credor é 021000088 — um dígito errado. Falha o dígito de controlo ABA 3-7-1, pelo que não é um número que possa existir. O XSD vê apenas nove dígitos válidos. | Inválido | |
| Fedwire — header announces a different message than it carriesO cabeçalho BAH declara <MsgDefIdr>pacs.009.001.08</MsgDefIdr> mas o documento que encabeça é um pacs.008. Cada metade é válida face ao seu próprio esquema: só a comparação o deteta. | Inválido |
Transferência SWIFT MT103 (2)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| MT103 — cross-currency customer credit transferUm MT103 completo: os cinco blocos SWIFT, um UETR, um ordenante em opção K, agentes em opção A e um beneficiário com IBAN. Liquidado em USD e instruído em EUR — o campo :36: (taxa de câmbio) é assim obrigatório, e está presente. | Válido | |
| MT103 — three defects a plain text viewer would missEstruturalmente, um MT103 perfeitamente legível — e errado três vezes: o UETR não é um UUID v4, o pagamento é multimoeda sem taxa de câmbio em :36:, e o IBAN do beneficiário falha o mod-97. | Válido |
Ficheiro de pagamentos CPA-005 / AFT (Canadá) (6)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| CPA-005 — payroll direct deposit (two credits in one record)Um ficheiro de salários canadiano comum: um único registo «C» que transporta dois depósitos diretos (tipo de operação 200) em dois dos seus seis segmentos. O trailer Z declara 2 créditos no total de 3 750,50 e nenhum débito, e concilia. Note-se que o contador de registos conta registos FÍSICOS enquanto o trailer conta TRANSAÇÕES — há três registos e duas transações. | Válido | |
| CPA-005 — a pre-authorised debit and its NSF return (code 901)Um débito autorizado «D» de 899,00 seguido do registo «J» que o devolve. A devolução leva o código 901 (fundos insuficientes) no campo TIPO DE OPERAÇÃO — onde um pagamento levaria o seu tipo — enquanto o tipo original 700 sobrevive no stored transaction type. Ambos são contabilizados como débitos, daí os 2 débitos de 1 798,00 declarados no trailer. | Válido | |
| CPA-005 — the error correction folded into the debit totalPartido de propósito, e partido como os geradores reais o partem: o ficheiro anula um crédito com um registo «E», e o trailer conta essa anulação como um débito. Não é. A norma 005 dá às correções E e F o SEU PRÓPRIO par de totais, separado dos pares de débitos e créditos — fundi-los desequilibra o ficheiro. É a causa mais frequente de rejeição de um gerador CPA-005 feito à mão. | Inválido | |
| CPA-005 — credits (C) and debits (D) in one file, four pairs of totals balancedUm ficheiro AFT de 1464 caracteres a misturar os dois sentidos: um registo «C» com dois depósitos salariais (3 750,50) e um registo «D» com dois débitos autorizados (1 349,25). C é o CRÉDITO e D o DÉBITO — vários resumos publicados trocam-nos. O trailer Z fecha sobre os quatro pares de totais que a norma 005 define (D+J, C+I, E à parte, F à parte), aqui com os contadores E e F a zero. | Válido | |
| CPA-005 — Notice of Change file (U / S / V records, 208 characters)Um Notice of Change canadiano: a instituição recetora informa o emissor de que uma conta mudou. É um FICHEIRO À PARTE — os registos têm 208 caracteres, não 1464, e a norma 005 proíbe misturar os seus registos U (cabeçalho), S (alteração) e V (trailer) com registos AFT. Cada S traz o novo número de encaminhamento e a nova conta ao lado dos originais, e o trailer V declara quantos S o ficheiro contém. | Válido | |
| CPA-005 — transit 099999999 passes: there is no check digit in CanadaUm ficheiro de salários cliente→banco que um validador treinado nas regras norte-americanas rejeitaria duas vezes sem razão. O primeiro crédito segue pelo transit 099999999, que não tem qualquer dígito de controlo aritmético — o DPRN canadiano simplesmente não tem nenhum: a norma 005 valida-o por consulta ao Financial Institutions File e a norma 006 não define qualquer fórmula. Transpor aqui a regra ABA 3-7-1 rejeita ficheiros perfeitamente válidos. Os Item Trace Numbers estão também a zero, o que é normal num ficheiro que um cliente envia ao seu banco (é o Direct Clearer que os atribui) — daí dois avisos e zero erros. | Válido |
Ficheiro ACH / NACHA (EUA) (10)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| ACH — a returned WEB debit (R01, insufficient funds)Um débito WEB de 123,54 que volta. Numa devolução mudam três coisas e mais nada: o transaction code passa a 26 (o código de devolução de um débito em conta à ordem — NÃO o 27 original), o banco recetor passa a ser o ODFI do original, e é atribuído um novo trace number. O montante não muda — a ACH não conhece devolução parcial. O addenda 99 leva R01 e aponta para o trace da entrada original. O lote continua WEB e continua TRANSFER: não existe descrição «RETURN» nem código SEC «RET», por mais que a web diga o contrário. | Válido | |
| ACH — a notification of change (C01, corrected account number)Uma notificação de alteração — e o essencial é que NÃO é uma rejeição. O pagamento passou. O banco recetor pede que o dado guardado seja corrigido antes do PRÓXIMO pagamento: reenviar este pagaria ao beneficiário duas vezes. Daí o montante ZERO da entrada e o código SEC COR do lote. O addenda 98 leva C01 com o número de conta corrigido nas posições 36-52 do registo. | Válido | |
| ACH — an international entry (IAT) with its seven mandatory addendaUm pagamento USD → MXN para o México. Um registo IAT não é o registo doméstico com outras etiquetas: o número de conta passa para as posições 40-74 (35 caracteres, para alojar uma conta estrangeira), as posições 13-16 declaram quantos addenda se seguem, e o nome do beneficiário não está no registo de todo — vive no addenda 10. Sete addenda (10 a 16) são obrigatórios em qualquer entrada internacional, porque um registo de 94 caracteres não consegue conter o nome, a morada e a identificação bancária de ambas as partes. Ler este ficheiro com os deslocamentos domésticos devolve um fragmento do número de conta como se fosse o nome de uma pessoa. | Válido | |
| ACH — PPD payroll credits, balanced with an offset debitO ficheiro de referência: o aspeto de um ficheiro NACHA correto. Quatro créditos de salários PPD (três em conta à ordem, código 22, um em conta poupança, código 32) e uma quinta entrada — o débito de compensação (offset), código 27, sobre a própria conta da empresa pelo total exato. É isso que torna o ficheiro «equilibrado», e por isso o service class code é 200 (misto) e não 220. Entry hash, totais do Batch Control, totais do File Control e block count batem certo, e cada routing number satisfaz o dígito de controlo ABA 3-7-1. | Válido | |
| ACH — CCD corporate debits with an addenda 05 remittanceUma cobrança B2B: dois débitos CCD (service class 225, só débitos), cada um com um addenda 05 que leva a fatura que liquida — segmentos RMR e REF, a remessa ASC X12 com que o recetor corporativo reconcilia. O CCD admite exatamente UM addenda por entrada: 80 caracteres de informação de pagamento, nem um a mais. Quando o pagador precisa de mais espaço, o código SEC passa a CTX. Repare no addenda record indicator na posição 79 da entrada: vale 1, e um addenda segue-se de facto. | Válido | |
| ACH — WEB debits (e-commerce, recurring and single-entry)Quatro débitos WEB — o código SEC de um pagamento autorizado online por um consumidor. Três saem de contas à ordem (código 27) e um de uma conta poupança (código 37): é o transaction code que o diz, e lê-lo como algo que não seja uma tabela é exatamente o erro que os parsers cometem. As posições 77-78 levam o payment type indicator, R para recorrente e S para pagamento único. As entradas WEB não levam addenda, logo o addenda record indicator fica a 0. | Válido | |
| ACH — CTX with seven addenda 05 carrying an EDI 820Um débito CTX de 28 750,00 que liquida três faturas de uma vez, com o aviso de remessa ASC X12 820 repartido por sete addenda 05. CTX é o código SEC que os parsers erram mais vezes, porque o registo de entrada não significa o que significa em todo o lado: as posições 55-58 NÃO são o início de um nome, são o NÚMERO de addenda que se seguem (0007 aqui), e o nome da empresa recetora só começa na 59. Lido com os deslocamentos PPD, o nome sai como «0007GLOBEX CORP» — que é exatamente o que o nosso validador mostra, por aplicar o formato doméstico. | Válido | |
| ACH — entry hash mismatch (truncated or tampered file)Um ficheiro de créditos PPD com o entry hash errado. O entry hash é a soma dos routing numbers de 8 dígitos de todas as entradas, truncada aos seus dez últimos dígitos — uma soma de controlo cuja única função é apanhar um ficheiro que perdeu, ganhou ou viu alterar uma entrada pelo caminho. Aqui o Batch Control e o File Control declaram ambos 28905251 enquanto as quatro entradas somam 27905251. Os montantes continuam a bater certo, e é esse o ponto: o hash é o controlo que dispara quando nenhum outro o faz. | Inválido | |
| ACH — batch control debit total ≠ the sum of its entriesUm lote de débitos CCD cujo Batch Control declara 18 450,00 enquanto as suas duas entradas somam 28 075,00 — o erro clássico do gerador que escreve o trailer antes de ter somado a última entrada. Todo o resto do ficheiro está certo, incluindo os totais do File Control, pelo que o validador assinala exatamente um erro e nomeia ambos os números. É a primeira causa de rejeição de um ficheiro ACH feito à mão. | Inválido | |
| ACH — invalid ABA 3-7-1 check digit on an entry routing numberUm ficheiro de débitos WEB no qual um banco recetor leva 026009594 — um routing number que falha o dígito de controlo ABA 3-7-1 (o verdadeiro é 026009593). Só a posição 12 da entrada está errada, pelo que o entry hash e todos os totais de controlo continuam a bater certo: o dígito de controlo é o único controlo que apanha um algarismo mal digitado, e este ficheiro prova-o — os totais, sozinhos, não o veem. As outras duas entradas e todos os trailers estão corretos, por isso o validador assinala exatamente um erro. | Inválido |
Código QR de pagamento (EPC / fatura QR suíça) (6)
| Ficheiros de exemplo | Resultado esperado | Descarregar o ficheiro |
|---|---|---|
| EPC QR code — version 002 with a structured creditor reference (RF)Um payload de código QR EPC (SCT QR) conforme, versão 002 — aquela em que o BIC é facultativo e aqui é omitido. A comunicação é uma referência de credor estruturada ISO 11649, RF6518539007547034, com dígitos de controlo mod-97 corretos: 94 bytes dos 331 permitidos. | Válido | |
| EPC QR code — version 001 (BIC mandatory) with a free-text messageA outra metade do EPC069-12: a versão 001, em que o BIC do beneficiário é obrigatório (é a única diferença entre 001 e 002), com uma mensagem livre em vez de uma referência. Referência estruturada e texto livre são exclusivos: um código QR leva um ou outro, nunca ambos. | Válido | |
| EPC QR code — 312 characters but 338 bytes: over the 331-byte capA armadilha que a especificação enuncia e na qual as implementações caem na mesma: o EPC069-12 limita o payload a 331 BYTES, não caracteres. Este payload polaco tem 312 caracteres — muito abaixo de qualquer contagem — mas cada letra acentuada custa dois bytes em UTF-8: pesa 338 bytes e é rejeitado. | Inválido | |
| Swiss QR-bill — QR-IBAN with a QRR reference (the pairing rule, satisfied)A fatura QR suíça canónica: um QR-IBAN (ID de instituição 31999, dentro do intervalo 30000-31999) emparelhado com a referência QRR que exige — 26 dígitos mais um dígito de controlo em módulo 10 recursivo, não o mod-97 do mundo IBAN. Repare no bloco «ultimate creditor»: sete linhas, presentes e totalmente vazias, tal como exigem as diretrizes. | Válido | |
| Swiss QR-bill — normal IBAN with an ISO 11649 (SCOR) referenceA outra metade da regra de emparelhamento: um IBAN normal (ID de instituição 00791, fora do intervalo QR-IID) PROÍBE uma referência QRR e aceita uma referência de credor ISO 11649 (SCOR) — RF6518539007547034 — ou nenhuma. Mesma fatura, outro tipo de conta, outra referência: desta distinção depende que um pagamento suíço possa ser conciliado. | Válido | |
| Swiss QR-bill — QR-IBAN carrying a SCOR reference (the pairing rule, broken)O erro de maiores consequências do formato suíço: um QR-IBAN a transportar uma referência ISO 11649 (SCOR). A referência em si é perfeitamente válida — é essa a armadilha — mas um QR-IBAN exige uma referência QRR e mais nenhuma. O banco não consegue contabilizar o pagamento, e o veredicto é o mesmo sob as diretrizes 2.3 e 2.4. | Inválido |
Como sabemos que estes resultados se mantêm
Cada ficheiro desta biblioteca passa pelo próprio validador do site em cada build. O resultado esperado indicado acima é verificado por um teste automatizado: se um ficheiro deixasse de corresponder ao que esta página afirma, o build falharia. Duas fixtures herdadas foram reparadas assim antes da publicação: três IBAN falhavam o mod-97 e vários nomes usavam caracteres fora do conjunto SEPA básico.