Biblioteca de ficheros de ejemplo
Ficheros SEPA, camt.053, UBL, MT940 y Factur-X listos para usar: válidos para empezar, rotos a propósito para probar. Cada fichero lo comprueba el validador al que corresponde.
Ficheros de ejemplo SEPA y facturación electrónica
Ficheros SEPA, camt.053, UBL, MT940 y Factur-X listos para usar: válidos para empezar, rotos a propósito para probar. Cada fichero lo comprueba el validador al que corresponde.
129
Ficheros de ejemplo
92
Válido
37
Inválido
Transferencia SEPA (pain.001) (12)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| pain.001.001.03 — valid credit transferUna transferencia SEPA válida en pain.001.001.03: tres transferencias por 1.580,00 EUR, totales de control coherentes, IBAN que superan el mod-97 y nombres dentro del juego de caracteres SEPA básico. | Válido | |
| pain.001.001.09 — valid, hybrid addressUna transferencia pain.001.001.09 válida, con BICFI y la dirección postal híbrida que permite EPC153-22 v2.1: TwnNm y Ctry, más un máximo de dos AdrLine de 70 caracteres o menos. | Válido | |
| pain.001.001.03 — CtrlSum mismatchUn pain.001 cuya suma de control miente: CtrlSum declara 1.000,00 EUR mientras que las transacciones suman 1.500,00 EUR. La discrepancia se señala dos veces, en el lote de pagos y en la cabecera del fichero. | Inválido | |
| pain.001.001.03 — invalid IBANUn pain.001 con un IBAN de acreedor cuyos dos dígitos de control no superan la prueba mod-97 (ISO 7064). Todo lo demás es correcto, por lo que el validador señala exactamente un error. | Inválido | |
| pain.001.001.03 — NbOfTxs mismatchUn pain.001 que se cuenta mal: NbOfTxs declara una transacción mientras que el fichero contiene dos. Como con CtrlSum, el recuento se comprueba en el lote de pagos y en la cabecera. | Inválido | |
| pain.001.001.03 — unstructured address after 2026-11-15El caso de referencia de la regla EPC de dirección estructurada: las direcciones solo llevan AdrLine, sin TwnNm. Lo que lo convierte en error bloqueante es la fecha de ejecución del fichero (ReqdExctnDt = 2026-11-20, posterior al corte del 15/11/2026); con una fecha anterior, el mismo fichero solo genera un aviso. | Inválido | |
| pain.001.001.11 — valid, fully structured address, executed after 2026-11-15El fichero de referencia «listo para 2026»: una transferencia pain.001.001.11 cuya fecha de ejecución (ReqdExctnDt = 2026-11-20) cae después del corte EPC de dirección estructurada del 15/11/2026. Cada dirección de ordenante y beneficiario está totalmente estructurada — StrtNm, BldgNb, PstCd, TwnNm, Ctry y ni una sola AdrLine. Tres transferencias, 4.320,00 EUR, cero errores y cero avisos. | Válido | |
| pain.001.001.09 — valid, two payment batches with different execution datesUn único fichero pain.001, dos bloques PmtInf: el lote A se ejecuta el 10/03/2026 con direcciones híbridas (TwnNm + Ctry + una AdrLine), el lote B el 20/11/2026 con direcciones totalmente estructuradas. Enseña las dos lecciones del fichero multilote: la regla EPC de dirección se evalúa lote a lote, con la fecha que lleva cada uno, y cada PmtInf tiene sus propios NbOfTxs / CtrlSum además de los totales del GrpHdr (4 transferencias, 3.350,00 EUR). | Válido | |
| pain.001.001.03 — nine-character BICUn pain.001 cuyo BIC del banco del beneficiario tiene nueve caracteres. La norma ISO 9362 admite 8 (entidad + país + localidad) u 11 (más un código de sucursal de 3 caracteres), nunca 9 ni 10. «BNPAFRPPX» es el aspecto típico de un código de sucursal truncado o rellenado a mano, y es el defecto que ambas capas detectan: el XSD oficial lo rechaza por su patrón de BIC y la capa de reglas por su longitud. | Inválido | |
| pain.001.001.03 — accent and ampersand outside the SEPA character setUn pain.001 cuyo beneficiario se llama «Café Renard & Fils SARL»: una letra acentuada y un ampersand, ambos fuera del juego de caracteres latino básico aprobado por el EPC (a-z A-Z 0-9 y / - ? : ( ) . , ' + espacio). El XML está bien formado y el XSD oficial lo acepta sin problema: Max70Text admite cualquier cadena. Este defecto vive por completo en la capa de reglas, y por eso estos ficheros llegan al banco, que los rechaza o los translitera en silencio. | Inválido | |
| pain.001.001.03 — 250 transfers, high-volume payroll runUna nómina realista: 250 transferencias SEPA en un único PmtInf, repartidas entre cinco países (DE, NL, BE, ES, FR), por un total de 442.028,75 EUR. Cada IBAN lleva dígitos de control mod-97 (ISO 7064) correctos y ambos totales de control coinciden con la suma exacta, al céntimo. Sirve para ver cómo se comporta tu parser, tu portal bancario o tus propias herramientas ante un fichero que no es ni de juguete ni patológico, y para comprobar que un solo céntimo erróneo en un lote de este tamaño lo detecta el CtrlSum por sí solo. | Válido | |
| pain.001.001.03 — unstructured address, executed before 2026-11-15 (warning only)El gemelo de la muestra de dirección no estructurada bloqueante, con una sola diferencia: la fecha de ejecución. Las mismas direcciones reducidas a AdrLine, pero ReqdExctnDt es el 30/09/2026, anterior al corte de EPC153-22 v2.1: el mismo defecto reaparece como dos avisos en vez de dos errores — hoy el pago aún se ejecuta. Además muestra qué significa «estructurada»: la dirección del ordenante no tiene ni TwnNm ni Ctry, la del beneficiario tiene Ctry pero sigue sin TwnNm. Ctry por sí solo no basta: TwnNm es el discriminante. | Válido |
Adeudo directo SEPA (pain.008) (8)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| pain.008.001.02 — valid CORE direct debitUn adeudo directo SEPA válido en el esquema CORE: dos cobros recurrentes por 175,00 EUR, un Identificador de Acreedor (ICS) que supera la comprobación ISO 7064 MOD 97-10 y un mandato firmado tras cada deudor. | Válido | |
| pain.008.001.08 — valid CORE direct debit, collected after 2026-11-15Así es un adeudo directo SEPA conforme tras el corte del 15/11/2026: la fecha de cobro es el 20/11/2026, por lo que cada dirección de acreedor y deudor está estructurada (TwnNm + Ctry). Esquema CORE, tres cobros por 228,80 EUR, sin avisos. | Válido | |
| pain.008.001.02 — mandate signed after the collectionUn adeudo cobrado con un mandato que el deudor aún no había firmado: DtOfSgntr es el 10/04/2026 mientras que el cobro es del 05/03/2026. Un defecto frecuente y silenciosamente fatal: el ICS, los IBAN y los totales son correctos. | Inválido | |
| pain.008.001.08 — valid B2B direct debit, RCUR sequenceUn adeudo directo SEPA B2B válido en pain.008.001.08: LclInstrm/Cd = B2B, secuencia RCUR, dos cobros recurrentes por 4.650,00 EUR. El esquema B2B es la variante entre empresas: el deudor debe ser un no consumidor y NO tiene derecho a devolución tras la liquidación, por lo que su banco verifica el mandato antes de adeudar y los cobros B2B se presentan antes que los CORE. | Válido | |
| pain.008.001.02 — valid CORE direct debit, FRST sequenceUn adeudo directo SEPA CORE válido con secuencia FRST: el primer cobro presentado bajo un mandato recién firmado (DtOfSgntr es de hace unos días). Todo lo que siga sobre el mismo mandato debe enviarse como RCUR; dejar un lote en FRST para siempre es uno de los errores SDD más comunes y el motivo por el que los bancos devuelven cobros con un código de secuencia incorrecta. | Válido | |
| pain.008.001.08 — valid one-off direct debit, OOFF sequenceUn adeudo directo SEPA puntual válido: secuencia OOFF, un único cobro de 349,00 EUR. El mandato autoriza exactamente un adeudo y se agota en cuanto se usa: no puede volver a presentarse, ni siquiera como RCUR. Es la secuencia de la compra única, la señal o la tarifa puntual; usar FRST en su lugar deja abierto, en silencio, un mandato que el deudor nunca aceptó. | Válido | |
| pain.008.001.02 — mandate identifier (MndtId) missingUn adeudo sin identificador de mandato: MndtRltdInf está presente y lleva fecha de firma, pero falta el elemento MndtId (AT-01 del rulebook). El XSD oficial ISO 20022 acepta el fichero —MndtId es opcional en el esquema—, de modo que una comprobación puramente estructural lo deja pasar y el banco lo rechaza: sin referencia de mandato, el banco del deudor no tiene con qué casar el cobro y el deudor no tiene nada que reclamar. | Inválido | |
| pain.008.001.02 — NbOfTxs and CtrlSum wrong at both levelsUn adeudo directo SEPA que se cuenta y se suma mal, en los dos niveles a la vez: el lote contiene realmente 2 cobros por 300,00 EUR, pero NbOfTxs dice 3 y CtrlSum dice 250,00 — en el PmtInf y otra vez en el GrpHdr. Son cuatro errores, no dos: los totales de control se comprueban en el lote de pagos Y en la cabecera, porque un fichero multilote puede lucir un total de cabecera correcto sobre dos totales de lote equivocados. El XML está bien formado y el XSD oficial lo acepta: para un esquema, NbOfTxs y CtrlSum son solo números. | Inválido |
Extracto bancario (camt.052 / 053 / 054) (12)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| camt.053.001.02 — valid statementUn extracto camt.053.001.02 válido: cuatro apuntes, saldos de apertura y cierre que cuadran (OPBD ± movimientos = CLBD) y fechas en formato Dt. | Válido | |
| camt.053.001.08 — valid statementUn extracto camt.053.001.08 válido: tres apuntes, marcas de tiempo DtTm y BICFI en lugar de BIC — las diferencias con las que se tropieza al pasar de la versión 02 a la 08. | Válido | |
| camt.053 — unsupported namespaceUn extracto que declara camt.053.001.99, una versión que no existe en el catálogo ISO 20022. Útil para comprobar que tu parser rechaza namespaces desconocidos en lugar de adivinar. | Inválido | |
| camt.053.001.06 — missing Stmt elementUn extracto con namespace camt.053.001.06 correcto pero sin ningún elemento <Stmt>: el sobre está bien, falta el contenido. Así se ve una exportación bancaria truncada. | Inválido | |
| camt.053.001.11 — valid statementUn extracto camt.053.001.11 válido — la versión actual del mensaje de extracto ISO 20022. Cuatro apuntes, OPBD 25 000,00 ± movimientos = CLBD 34 659,05. Ojo con lo que la versión 11 vuelve obligatorio en cada apunte: Sts y BkTxCd, que las versiones anteriores permitían omitir. | Válido | |
| camt.053.001.08 — three accounts in one fileUn solo mensaje camt.053, tres bloques <Stmt>: cuenta corriente, cuenta de ahorro y cuenta en USD. El fichero es válido según el esquema; el validador avisa explícitamente de que solo analiza el primer extracto. Ahí está la clave: un lector que coge Stmt[0] y se detiene pierde dos cuentas en silencio, y este fichero multicuenta lo pone en evidencia. | Válido | |
| camt.053.001.10 — fully detailed entriesTodo lo que un banco puede colgar de un apunte camt.053, en un único fichero válido: NtryDtls/TxDtls con EndToEndId, InstrId, TxId y MndtId; RltdPties y RltdAgts; una referencia de acreedor estructurada ISO 11649 (RF) y una factura referenciada (CINV); un apunte agrupado cuyos dos TxDtls suman exactamente el importe del apunte; y un BkTxCd ISO (PMNT/RCDT/ESCT) junto a un GVC alemán propietario. Sirve para medir cuánto lee de verdad su conciliación. | Válido | |
| camt.053.001.08 — closing balance does not reconcileEl defecto más frecuente en los camt.053 de producción: la apertura de 4 200,00 más los apuntes contabilizados da 5 194,70, mientras que el CLBD declarado dice 5 194,07 — dos cifras transpuestas. El fichero cumple a la perfección el XSD oficial ISO 20022, porque un esquema no tiene nada que decir sobre aritmética. Solo un cuadre de saldos detecta un saldo de cierre incoherente. | Válido | |
| camt.052.001.08 — valid intraday reportUn informe intradía camt.052 válido — y no es un camt.053 en pequeño: la raíz es BkToCstmrAcctRpt, el contenedor es <Rpt> y los saldos son INTERMEDIOS (ITBD contabilizado, ITAV disponible) en lugar del par OPBD/CLBD de un extracto de cierre. Incluye además un apunte pendiente (Sts=PDNG) deliberadamente excluido del saldo intermedio: el dinero pendiente no es dinero contabilizado. | Válido | |
| camt.054.001.08 — valid debit/credit notificationUn aviso de adeudo/abono camt.054 válido: un abono SEPA entrante y un adeudo directo saliente, cada uno con TxDtls completos y referencia de extremo a extremo. La sorpresa estructural es lo que NO está: un camt.054 no tiene ningún elemento <Bal> — el esquema ISO 20022 no define ninguno. Un aviso anuncia movimientos, nunca declara un saldo: no hay nada que cuadrar. | Válido | |
| camt.053.001.08 — entry with no CdtDbtIndEl segundo apunte lleva un importe de 1 200,00 y ningún <CdtDbtInd>. En camt.053 los importes van siempre sin signo: sin el indicador de sentido, el importe no significa nada. Se rompen dos cosas a la vez — el XSD oficial rechaza el fichero (CdtDbtInd es obligatorio 1..1 en un apunte) y un parser que se pasa en silencio a CRDT contabiliza +1 200,00 en lugar de −1 200,00 y se queda a 2 400,00 de la verdad, algo que el cuadre de saldos deja al descubierto. | Inválido | |
| camt.053.001.08 — 220 entries, validUn extracto empresarial de cierre de mes con 220 apuntes contabilizados, todos cuadrados: OPBD 125 000,00 ± movimientos = CLBD 209 081,69. Cada apunte lleva NtryDtls/TxDtls, un EndToEndId y una contraparte, de modo que exige a un lector camt.053 un volumen realista y no un fichero de juguete de tres líneas: rendimiento de parseo, renderizado de la tabla y conciliación sobre cientos de líneas. | Válido |
Factura UBL (Peppol BIS 3.0) (12)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| UBL Invoice — valid Peppol BIS 3.0Una factura Peppol BIS Billing 3.0 válida: tres líneas, 2.596,00 EUR con IVA, totales coherentes, NIF-IVA francés e IBAN de pago. | Válido | |
| UBL Credit Note — valid Peppol BIS 3.0Un abono Peppol BIS Billing 3.0 válido: una línea, 1.770,00 EUR con IVA, referenciando la factura original que anula. El abono es un tipo de documento UBL propio, no una factura con importes negativos. | Válido | |
| UBL Invoice — BR-CO-10 violationUna factura que incumple la regla EN 16931 BR-CO-10: la suma de los importes netos de línea (1.000,00) no coincide con el total del documento BT-106 (2.000,00). Uno de los rechazos más frecuentes en la red Peppol. | Inválido | |
| UBL Invoice — malformed seller VAT identifierUna factura cuyo NIF-IVA del vendedor, «FR1234», es demasiado corto: un número francés es FR seguido de una clave de dos caracteres y nueve dígitos. Los errores de formato en BT-31 se detectan mucho antes de llegar a Hacienda. | Inválido | |
| UBL Invoice — allowances and charges, line and document levelUna factura UBL Peppol BIS 3.0 válida con descuentos y cargos en AMBOS niveles: descuento de línea (BG-27), cargo de línea (BG-28), descuento a nivel de documento (BG-20) y portes (BG-21). Lo importante es el encadenamiento de los totales: BT-106 = 1.520,00 es la suma de los importes NETOS de línea, y BT-109 = 1.530,00 = BT-106 - BT-107 + BT-108 (BR-CO-13), de modo que el 19 % de IVA se aplica sobre 1.530,00 y no sobre 1.520,00. | Válido | |
| UBL Invoice — reverse charge (VAT category AE)Una factura válida con inversión del sujeto pasivo en UBL: un proveedor francés factura servicios a una empresa alemana, el IVA lo liquida el cliente, por lo que el tipo es 0 % y no se repercute IVA. La categoría AE trae cuatro reglas: los dos NIF-IVA (BR-AE-02, BR-AE-03), el tipo 0 % (BR-AE-05), una cuota de 0,00 (BR-AE-09) y un motivo de exención (BR-AE-10), aquí VATEX-EU-AE y el texto «Reverse charge». | Válido | |
| UBL Invoice — VAT exempt (category E) with exemption reasonUna factura exenta de IVA válida (categoría E): formación profesional exenta al amparo del artículo 132.1.i) de la Directiva 2006/112/CE. Una factura exenta debe decir POR QUÉ lo está: BR-E-10 exige un código de motivo de exención (BT-121) o un texto (BT-120), y este fichero lleva ambos: VATEX-EU-132 y la redacción de la lista de códigos oficial. | Válido | |
| UBL Invoice — intra-Community supply (VAT category K)Una entrega intracomunitaria válida (categoría de IVA K): mercancías expedidas desde Alemania a un comprador con NIF-IVA en Francia, exentas al amparo del artículo 138 de la Directiva 2006/112/CE. La categoría K exige dos datos que suelen olvidarse: BR-IC-11, una fecha de entrega efectiva (BT-72) o un periodo de facturación, y BR-IC-12, el país de entrega (BT-80). Sin ellos, la factura no acredita que los bienes salieron del país. | Válido | |
| UBL Invoice — two VAT rates, one breakdown per rateUna factura válida que combina el tipo general francés (20 %) y el reducido (5,5 %). La regla que ilustra es BR-S-08: el desglose de IVA (BG-23) lleva UN TaxSubtotal por par (categoría, tipo), y cada base imponible es la suma de las líneas de ese par: 1.500,00 al 20 % (IVA 300,00) y 400,00 al 5,5 % (IVA 22,00). Fundir dos tipos en un solo subtotal supera todas las comprobaciones BR-CO y sigue estando mal. | Válido | |
| UBL Invoice — BR-CO-10, line sum does not equal BT-106El rechazo más frecuente en producción, aislado: las dos líneas suman 1.500,00 pero BT-106 (LineExtensionAmount) declara 1.400,00 — BR-CO-10. Todo lo demás es coherente con la cifra ERRÓNEA, así que BR-CO-13, BR-CO-14, BR-CO-15 y BR-CO-16 pasan y solo aparece un error. Así se ve una línea borrada después de calcular los totales. | Inválido | |
| UBL Invoice — exempt VAT without an exemption reason (BR-E-10) and a wrong exempt base (BR-E-08)Una factura exenta mal hecha, por partida doble. BR-E-10: el desglose de IVA de la categoría E no lleva ni motivo de exención (BT-120) ni código de motivo (BT-121); una factura exenta debe decir POR QUÉ. BR-E-08: la base exenta declara 1.200,00 mientras que las líneas exentas suman 1.500,00, porque la segunda línea nunca llegó al desglose. El error citado es el de la capa de reglas de negocio; el Schematron oficial EN 16931 añade además BR-E-10. | Inválido | |
| UBL Invoice — BR-CO-17, VAT amount does not equal base x rateUn desglose de IVA que no cuadra: una base de 2.000,00 al 19 % son 380,00 de IVA, pero la factura declara 395,00. BR-CO-17 comprueba que la cuota de la categoría = base × tipo / 100, con el margen oficial de una unidad monetaria: un céntimo real de redondeo se tolera, esta diferencia de 15,00 no. Los demás totales cuadran con la cifra errónea, que es justo cómo un bug de redondeo llega a producción. | Inválido |
Factura CII (sintaxis XRechnung / Factur-X) (4)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| CII CrossIndustryInvoice — XRechnung 3.0, validUna factura XRechnung 3.0 válida en sintaxis CII (UN/CEFACT CrossIndustryInvoice), la factura electrónica del sector público alemán. Incluye lo que las reglas BR-DE de KoSIT añaden a EN 16931: el Leitweg-ID como referencia del comprador (BR-DE-15), un punto de contacto del vendedor completo —nombre, teléfono y correo (BR-DE-2 a BR-DE-6)—, la dirección electrónica del vendedor, condiciones de pago estructuradas y una transferencia SEPA (medio de pago 58). | Válido | |
| CII CrossIndustryInvoice — Factur-X 1.0 BASIC, valid (standalone XML)La carga útil de Factur-X / ZUGFeRD por sí sola: el XML CII que normalmente viaja incrustado en un PDF/A-3, aquí como fichero independiente validable directamente. El perfil BASIC (BT-24 = urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic) es un CIUS conforme a EN 16931: líneas de factura completas, desglose de IVA íntegro y los seis totales del documento. Útil para probar un extractor solo con el XML, sin el PDF de por medio. | Válido | |
| CII CrossIndustryInvoice — BR-CO-10, line sum does not equal BT-106BR-CO-10 en sintaxis CII: las dos líneas suman 2.000,00 pero LineTotalAmount (BT-106, dentro de SpecifiedTradeSettlementHeaderMonetarySummation) declara 1.900,00. El mismo defecto que en la muestra UBL, en la sintaxis donde menos se ve: los totales del documento viven en una rama del árbol distinta de las líneas que resumen. | Inválido | |
| CII CrossIndustryInvoice — BR-CO-13, the discount never reaches the tax basisUn descuento a nivel de documento que solo existe a medias: la factura concede 200,00 (BT-107), calcula el IVA sobre la base descontada (1.800,00 × 19 % = 342,00, correcto), pero BT-109 (TaxBasisTotalAmount) sigue declarando 2.000,00 sin descuento. BR-CO-13 exige BT-109 = BT-106 - BT-107 + BT-108, así que se le facturan al comprador 200,00 que el vendedor creía haber regalado. | Inválido |
Extracto SWIFT MT940 (10)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| MT940 — Rabobank / Deutsche Bank dialectEl caso nominal MT940: un extracto, un abono y un cargo, con el par referencia cliente / referencia banco en la línea :61:. Empiece por aquí para ver la estructura de etiquetas antes de los dialectos. | Válido | |
| MT940 — ING Belgium, structured :86:El dialecto de ING Bélgica: la línea de información :86: está estructurada en subcampos ?00 ?20 ?30 en lugar de texto libre. Es la principal fuente de errores de parsing MT940. | Válido | |
| MT940 — Commerzbank, one-decimal amountEl dialecto Commerzbank: un importe con un solo decimal (1234,5 por 1.234,50), un tipo de transacción NMSC y una cuenta alemana dada como BLZ + número en vez de IBAN. | Válido | |
| MT940 — two statements in one fileDos extractos dentro de un mismo fichero MT940, más la etiqueta de saldo disponible :64:. Un fichero no es un extracto, y un parser que lo suponga perderá el segundo en silencio. | Válido | |
| MT940 — reversal (RC) and intermediate balancesEl caso ABN AMRO: una contrapartida RC (un abono convertido en cargo), saldos intermedios 60M/62M en lugar de F y un :86: repartido en dos líneas. Las contrapartidas invierten el signo: si se equivoca aquí, el saldo nunca cuadra. | Válido | |
| MT940 — overdrawn account (debit balances)Una cuenta en descubierto: los saldos de apertura y cierre llevan ambos el marcador D (deudor). En MT940 un saldo negativo no es un número negativo, sino una marca de signo; el código que la ignora presenta el descubierto como saldo a favor. | Válido | |
| MT940 — closing balance does not reconcileUn extracto cuyo saldo de cierre no se deriva de la apertura ± los movimientos. Es deliberadamente un aviso y no un error bloqueante: el fichero sigue siendo legible y corresponde a una persona decidir si falla el banco o la exportación. | Válido | |
| MT940 — 500 transactions (load test)Quinientas transacciones en un solo extracto, cuadradas al céntimo. Sirve para comprobar que su parser sigue siendo exacto —y rápido— a volumen real, y no solo con un fichero de juguete de tres líneas. | Válido | |
| MT940 — statement split over two pages (62M / 60M)Un extracto, un día, dos páginas: la secuencia 00147/00001 cierra con un saldo INTERMEDIO :62M: y la secuencia 00147/00002 reabre en :60M: con esa misma cifra antes de cerrar con el :62F: final. M no es F: tomar el saldo intermedio por el final del día es declarar 37.500,00 cuando la cuenta terminó en 44.249,25. | Válido | |
| MT940 — USD account with an RD reversalUn extracto en dólares —MT940 no es un formato euro— en el que una transferencia emitida de 35.000,00 se devuelve al día siguiente mediante una contrapartida RD: un CARGO REVERTIDO es dinero que VUELVE a entrar. Las marcas RC/RD invierten el sentido económico de la línea :61:, y un parser que solo lee la D de «RD» contabiliza el reembolso otra vez como pago y nunca cuadra. | Válido |
Extracto BAI2 (EE. UU. / Canadá) (6)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| BAI2 — US bank daily statement (nominal case)El fichero BAI2 nominal: una cuenta, un saldo de apertura 010 y de cierre 015, y diez movimientos cuyo sentido procede únicamente del type code — 115 depósito lockbox, 165 abono ACH, 195 transferencia recibida, 475 cheque pagado, 451 cargo ACH, 495 transferencia emitida, 698 comisiones. BAI2 no tiene indicador debe/haber: 100–399 es entrada, 400–699 salida. | Válido | |
| BAI2 — several accounts in one groupDos registros de cuenta 03 dentro de un mismo grupo 02 —una cuenta operativa y una de nóminas—, cada una cerrada por su propio trailer 49. BAI2 es jerárquico (01 fichero / 02 grupo / 03 cuenta / 16 movimiento / trailers 49-98-99): quien asuma una cuenta por fichero perderá la segunda en silencio. | Válido | |
| BAI2 — 88 continuation recordsEl registro de continuación 88 en sus dos papeles, muy distintos: aporta tuplas de saldo adicionales a un registro de cuenta 03 (aquí el cierre 015 y el disponible 045) y texto libre plegado a un movimiento 16 (tres líneas físicas, una sola cadena de concepto). Fusionarlos igual significa leer los saldos como texto, o el texto como saldos. | Válido | |
| BAI2 — CAD and JPY: minor units scale with the currencyLos importes BAI2 no llevan separador decimal: son unidades menores, y cuántos decimales implican depende de la divisa. Aquí «2500000» son 25.000,00 CAD en la cuenta CAD (2 decimales) y 2.500.000 ¥ en la cuenta JPY (0 decimales). La cuenta CAD deja además vacío su campo de divisa y la hereda de la cabecera de grupo 02. Una división entre 100 fija corrompe la cuenta en yenes en dos órdenes de magnitud, y el saldo sigue cuadrando porque las tres cifras están mal por el mismo factor. | Válido | |
| BAI2 — closing balance does not reconcileEl saldo de cierre 015 no se deriva del saldo de apertura 010 más los movimientos 16: 50.000,00 + 10.000,00 − 2.500,00 son 57.500,00, pero el fichero declara 59.000,00. Los trailers sí cuadran; solo la aritmética lo delata. Deliberadamente un aviso y no un error bloqueante: el fichero es legible y corresponde a una persona decidir si falla el banco o la exportación. | Válido | |
| BAI2 — bad trailer totals and an out-of-range type codeTres defectos a la vez. El trailer de cuenta 49 declara un total de control y un número de registros que no coinciden con los registros anteriores: los trailers son la verificación de integridad del propio fichero, y quien los ignora no ve un truncamiento. Y un movimiento 16 lleva el type code 720, dentro del rango de préstamos 700–799: no es abono (100–399) ni cargo (400–699), su sentido no puede inferirse y se descarta en vez de adivinarse, por lo que el saldo tampoco cuadra ya. | Válido |
Factur-X / ZUGFeRD (PDF) (2)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| Factur-X EN 16931 — valid hybrid invoiceUna factura Factur-X válida en el perfil EN 16931: un PDF/A-3 con el XML CII incrustado dentro. Un único documento que una persona lee y una máquina procesa: ese es todo el sentido del formato híbrido. | Válido | |
| Factur-X EN 16931 — BR-CO-15 violationUna factura Factur-X que incumple la regla EN 16931 BR-CO-15: el total con IVA es 130,00 mientras que la base más el IVA suman 120,00. El PDF se abre y parece perfectamente normal; solo el XML incrustado lo delata. | Inválido |
Factura KSeF (Polonia, FA(3)) (7)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| KSeF FA(3) — valid invoice (official MF example)Una factura estructurada FA(3) conforme: el ejemplo n.º 4 del propio Ministerio de Hacienda polaco, reproducido sin cambios. Tres líneas, 64.279,92 PLN con IVA al 23 %. Referencia de lo que KSeF acepta. | Válido | |
| KSeF — invoice still using the retired FA(2) schemaEl fallo de migración a KSeF más habitual: una factura perfectamente bien formada que sigue declarando el espacio de nombres FA(2), retirado el 1 de febrero de 2026. Nada parece incorrecto hasta que KSeF la rechaza. Observe lo que FA(3) añadió y aquí falta: Podmiot2 ahora exige JST y GV. | Inválido | |
| KSeF FA(3) — bad NIP check digit and mismatched total (warnings only)Estructuralmente perfecta frente al esquema oficial y, aun así, el NIP del vendedor no supera su dígito de control mod-11 y P_15 no coincide con la suma del desglose de IVA. ValidateFin informa de ambos como advertencias, no errores: ninguna regla es normativa, y el ejemplo n.º 1 del Ministerio se desvía él mismo un grosz. | Válido | |
| KSeF FA(3) — correcting invoice (faktura korygująca, KOR)Una factura rectificativa (RodzajFaktury = KOR), el caso FA(3) más buscado y peor construido. Sus totales llevan la DIFERENCIA, no la factura corregida: P_13_1, P_14_1 y P_15 son negativos. Aparecen además PrzyczynaKorekty, TypKorekty y DaneFaKorygowanej, que remiten a la factura corregida. Las líneas van por pares: la que lleva StanPrzed es el estado anterior. | Válido | |
| KSeF FA(3) — prepayment invoice (faktura zaliczkowa, ZAL)Una factura de anticipo (RodzajFaktury = ZAL): factura un depósito sobre un pedido aún no entregado. Por eso no lleva NINGUNA línea FaWiersz: los bienes están en el bloque Zamowienie (pedido), con sus propias etiquetas P_7Z / P_11NettoZ / P_11VatZ, mientras que P_15 solo muestra el anticipo de 12.300,00 PLN sobre un pedido de 61.500,00 PLN. | Válido | |
| KSeF FA(3) — mandatory element missing (rejected by the official XSD)Una factura FA(3) a la que le falta un elemento obligatorio: P_2, el número de factura. A la vista nada falla — XML bien formado, espacio de nombres correcto, desglose de IVA verosímil — y solo el XSD oficial del Ministerio de Hacienda lo detecta: «Element P_6: this element is not expected. Expected is P_2.» KSeF rechaza el archivo sin más. | Inválido | |
| KSeF FA(3) — buyer NIP failing its mod-11 check digit (warning only)El NIP del comprador es 1111111112: diez dígitos, así que el esquema oficial, que solo lo restringe con un patrón, lo acepta sin rechistar. Su dígito de control mod-11 no cuadra: no puede existir semejante número fiscal polaco, y la factura no va dirigida a nadie. ValidateFin lanza una advertencia, nunca un error — el Ministerio no publica ninguna regla de validación así. | Válido |
Factura FatturaPA (Italia, SdI) (4)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| FatturaPA FPR12 — conformant invoice to a private partyUna FatturaPA que el SdI aceptaría: aritmética del IVA correcta (dos líneas al 22 % que suman 1.100 €, 242 € de impuesto, 1.342 € en total), identificadores fiscales cuyo dígito de control es válido, y un CodiceDestinatario de 7 caracteres, como exige un destinatario privado. Es el punto de referencia: los demás ejemplos son este archivo, roto de una manera concreta. | Válido | |
| FatturaPA — signed CAdES (.p7m) envelopeLa misma factura conforme, envuelta en un sobre de firma CAdES (.p7m): así viajan la mayoría de las facturas italianas reales, y así DEBE viajar toda factura dirigida a una administración pública. Abierta en un editor de texto es solo ruido binario. El validador abre el sobre y comprueba el XML que contiene; no verifica la firma en sí, y lo dice. | Válido | |
| FatturaPA — XSD-valid, rejected by the SdI (00421, 00422, 00445)Esta factura es VÁLIDA frente al XSD oficial y el SdI la rechazaría igualmente: por eso una comprobación de esquema no basta. Tres defectos: la base imponible declara 1.150 € frente a líneas que suman 1.100 € (control 00422, cuya tolerancia es un EURO, no un céntimo); el impuesto declara 250 € donde el 22 % de 1.150 € son 253 € (00421); y el código Natura es el N3 escueto, retirado el 1 de enero de 2021 en favor de sus subcódigos (00445), aunque siga figurando en la enumeración del esquema. | Inválido | |
| FatturaPA FPA12 — wrong CodiceDestinatario length (00427)La forma más frecuente de que rebote una factura dirigida a una administración italiana: el CodiceDestinatario. Para una PA (FormatoTrasmissione = FPA12) debe ser el código de oficina IPA de SEIS caracteres; la forma de siete corresponde a destinatarios privados. El XSD permite 6 O 7 para ambos, así que el esquema no lo ve; solo lo ve el control 00427 del SdI. El número de factura, «FATTURA», tampoco contiene ningún dígito (00425). | Inválido |
Factura RO e-Factura (Rumanía, ANAF) (6)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| RO e-Factura — conformant invoice (FACT1)Una factura que ANAF acepta — su propio validador sin conexión responde « este valid ». Es el ejemplo publicado por el Ministerio, reparado en los dos puntos que hacen fallar la versión publicada: BT-24 con CIUS-RO:1.0.1 y dos CUI cuyo dígito de control es realmente correcto. Es el punto de referencia: cada muestra rota es este archivo, dañado de una forma precisa. | Válido | |
| RO e-Factura — credit note in a foreign currency (FCN)Una nota de crédito (FCN) emitida en SEK — y ANAF la acepta. Muestra lo que BR-RO-030 exige realmente: RON debe aparecer como moneda de la factura (BT-5) O como moneda de contabilización del IVA (BT-6), no necesariamente ambas. Aquí BT-5 es SEK y BT-6 es RON, lo que cumple la regla. Lleva además el código de tipo 381, lícito en una nota de crédito e ilícito en una factura. | Válido | |
| RO e-Factura — BT-24 still declaring CIUS-RO:1.0.0 (BR-RO-001)El rechazo rumano más frecuente, y el único defecto de este archivo: BT-24 sigue diciendo CIUS-RO:1.0.0, un valor retirado el 29 de diciembre de 2022 (orden OMF 4092/2022). La factura es impecable por lo demás y supera el XSD. Los dos ejemplos que el Ministerio aún publica llevan este defecto — y su propio validador los rechaza. | Inválido | |
| RO e-Factura — Bucharest written “Sector 1” instead of SECTOR1 (BR-RO-100)Un vendedor en Bucarest cuya ciudad (BT-37) dice «Sector 1» — la grafía exacta que emplea la propia orden ministerial. El Schematron que ANAF ejecuta realmente exige SECTOR1: mayúsculas, sin espacio. Cuando el texto de la ley y la implementación discrepan, es la implementación la que rechaza su factura. | Inválido | |
| RO e-Factura — buyer CUI with a wrong check digit (ERRIdentif)La muestra que revela el punto ciego de todo validador que solo ejecuta el Schematron. El CUI del comprador (RO987456123) tiene un dígito de control erróneo — y NINGUNA regla del Schematron lo mira. Este archivo supera el XSD, supera todo el corpus CIUS-RO, y aun así ANAF lo rechaza, con un código propio: ERRIdentif, « CUI cumparator incorect ». | Inválido | |
| RO e-Factura — B2C invoice with the anonymous CNP (0000000000000)Una factura B2C cuyo comprador es un particular, identificado por el CNP anónimo de trece ceros — en producción desde el 16 de diciembre de 2024. Es válida, y un validador que lo tomara por un número personal mal formado rompería toda la facturación a consumidores en Rumanía: ese número no supera ninguna regla de forma del CNP (su primer dígito, 0, se rechaza en cualquier otro caso), porque es un valor reservado, no un CNP. | Válido |
Registro de facturación Verifactu (España, AEAT) (3)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| Verifactu — envío conforme, dos registros encadenadosUn envío que la AEAT aceptaría: dos registros de alta correctamente encadenados. El primero declara PrimerRegistro=S y su huella se calcula con el campo Huella vacío; el segundo encadena la huella del primero. Ambas huellas son reales (SHA-256 sobre la cadena exacta que especifica la AEAT), no inventadas. Es el punto de referencia: los demás ejemplos son este fichero, roto de una manera concreta. | Válido | |
| Verifactu — cadena de huellas rota (aceptado con errores, código 2000)El segundo registro declara una huella que NO corresponde a su contenido: la cadena está rota. El fichero es VÁLIDO contra el XSD oficial de la AEAT — un validador que solo mire el esquema lo da por bueno. Solo recalcular el SHA-256 encadenado lo detecta. Y ojo: la AEAT NO lo rechaza, lo marca « Aceptado con errores » (código 2000) y lo registra igualmente, a subsanar. | Válido | |
| Verifactu — la AEAT lo rechazaría (códigos 1190 y 1142)Una factura simplificada (F2) que lleva un bloque Destinatarios — prohibido, código 1190 — y cuya CuotaRepercutida (100 €) no cuadra con la base por el tipo (1 000 € × 21 % = 210 €), muy por encima de la tolerancia de ±10 € del control 1142. El fichero PASA el XSD oficial sin una sola queja: es el esquema quien no puede verlo, y la AEAT quien lo rechaza. | Inválido |
Factura Facturae (España, FACe) (2)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| Facturae 3.2.2 — factura B2G conforme y firmadaUna factura Facturae 3.2.2 dirigida a una administración pública (con sus centros administrativos DIR3 — oficina contable, órgano gestor, unidad tramitadora — como exige FACe) que pasa el XSD oficial de facturae.gob.es sin una sola queja, con todos los totales cuadrados según las fórmulas del propio esquema y una firma XAdES presente. Es el punto de referencia: el otro ejemplo es este mismo fichero, roto de una manera concreta. La firma es de muestra: su validez criptográfica no se comprueba sin conexión. | Válido | |
| Facturae 3.2.2 — totales incoherentes (válida contra el XSD)El mismo fichero, con un solo cambio: InvoiceTotal declara 1200,00 € donde la fórmula oficial del esquema da 1210,00 € (base 1000 + IVA 210). El fichero es VÁLIDO contra el XSD oficial de facturae.gob.es — un validador que solo mire el esquema lo da por bueno. Solo la capa de coherencia lo detecta, y además señala que el total del lote ya no cuadra. No es un rechazo « oficial »: Facturae/FACe no publica códigos de rechazo verificables sin conexión, así que es un aviso, no un error. | Válido |
Extracto CODA (Bélgica) (6)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| CODA — Belgian statement with a valid structured communicationUn extracto belga ordinario: una transferencia SEPA con una comunicación estructurada válida (+++090/9337/55493+++), un pago con tarjeta y una transferencia recibida con su contraparte. Saldo inicial 1.000,00 − 250,00 − 89,90 + 1.500,00 = saldo final 2.160,10, y los totales del trailer concuerdan. | Válido | |
| CODA — globalised salary run (booked total + its details)Una globalización: un total de nóminas contabilizado de 3.000,00 (número de detalle 0000) seguido de las dos nóminas individuales que lo componen (0001, 0002). Solo el total se contabiliza: un parser que sume también los detalles duplica el fichero y el extracto deja de cuadrar. Cierra con un saldo deudor de 2.000,00. | Válido | |
| CODA — wrong mod-97 check digits and a statement that does not balanceRoto a propósito. La comunicación estructurada termina en 94 donde el mod 97 exige 93 — la causa más frecuente de que un pago belga nunca se concilie con su factura — y el saldo final no se deduce de los movimientos. Ninguna otra herramienta CODA gratuita comprueba estos dígitos de control. | Válido | |
| CODA — Belgian OGM (+++…+++) and ISO 11649 RF reference, both checksummedUn extracto CODA con las dos referencias estructuradas que admite el formato, cada una con su dígito de control: una transferencia emitida con comunicación estructurada belga +++090/9337/55493+++ (tipo 101, mod 97 — un resto de 0 se escribe 97, no 00) y una transferencia recibida con referencia de acreedor ISO 11649 RF73INV20260042 (tipo 100, mod 97-10). Ambas son correctas y el extracto cuadra: 1.000,00 − 250,00 + 1.500,00 = 2.250,00. | Válido | |
| CODA — separate application: balances zeroed by design (§7.2.1)Una «separate application» CODA (posiciones 84-88 de la cabecera = 00001): una liquidación de aceptación de tarjetas entregada fuera del extracto de cuenta. El §7.2.1 de Febelfin pone a cero sus saldos inicial y final por construcción, de modo que la identidad saldo inicial ± movimientos = saldo final no puede cumplirse, y no debe comprobarse. ValidateFin la omite aquí y declara limpio el fichero; un validador que no la omita marcará como roto todo fichero de este tipo. | Válido | |
| CODA — old balance ± movements ≠ new balanceUn extracto belga corriente — al que le falta un movimiento. Los registros 2.1 suman 1.000,00 − 250,00 + 1.500,00 = 2.250,00, pero el registro «8» de saldo final declara 2.200,00: 50,00 de movimiento contabilizado nunca llegaron al fichero. Esta es la comprobación que detecta un CODA truncado, un registro perdido o un signo deudor/acreedor mal leído, y la razón por la que la muestra anterior NO debe comprobarse igual. | Válido |
Extracto CFONB 120 (Francia) (5)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| CFONB 120 — statement with its SEPA supplement recordsUn extracto francés con todos sus datos SEPA: un adeudo directo con su referencia de mandato y secuencia RCUR, el nombre del acreedor, un pago con tarjeta y una transferencia recibida con el nombre del pagador, la referencia end-to-end, el propósito y el concepto — todo en registros «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 signRoto a propósito, y es la forma clásica de corromper un fichero CFONB: el importe del adeudo termina en un dígito simple en lugar de un carácter de signo sobreimpreso, de modo que el fichero nunca dice que es un adeudo. Se lee como un abono — y la identidad contable que exige el CFONB es lo que lo detecta. | Válido | |
| CFONB 120 — the "05" supplements: RUM, IBE, NBE, REF, LIB, NPY, IPY, RCN, LCC/LC2, CPYLos datos SEPA de un extracto CFONB 120 viven en los registros «05», y cada uno corta de forma distinta la misma zona de 70 caracteres (posiciones 49-118): RUM lleva una referencia de mandato Y su tipo de secuencia (RCUR), REF una referencia de lote Y una de operación, RCN un identificador extremo a extremo Y un propósito, mientras que NBE, NPY y LIB ocupan toda la zona. Leída en plano, la zona pega el mandato a su tipo de secuencia. Este fichero lleva un adeudo SEPA (operación B1) y una transferencia recibida, con diez calificadores distintos entre ambos. | Válido | |
| CFONB 120 — two accounts (two 01…07 blocks) in one fileUn único fichero CFONB 120, dos cuentas: cada una forma su propio bloque 01 (saldo inicial) … 07 (saldo final) y cuadra por separado. La segunda abre EN DESCUBIERTO —el saldo inicial lleva un signo sobreimpreso de la familia «}», es decir un adeudo— y remonta hasta un saldo acreedor de 179,60. Un parser que mantenga un único saldo acumulado para todo el fichero, o que lea el carácter de signo como un dígito, se equivoca en las dos cuentas. | Válido | |
| CFONB 120 — the new balance does not equal old balance ± movementsTodos los importes llevan aquí un signo sobreimpreso correcto — y aun así el extracto no cuadra: 1.000,00 − 89,90 + 500,00 = 1.410,10, mientras que el registro «07» declara 1.310,10. La regla 2 del §1 de la especificación CFONB enuncia esa identidad como la DEFINICIÓN de un extracto conforme: no es una heurística, faltan 100,00 de movimiento en el fichero. | Válido |
Mensaje Fedwire ISO 20022 (EE. UU.) (6)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| Fedwire pacs.008 — conformant customer credit transferUna transferencia de cliente con cabecera BAH y direcciones postales híbridas: ya cumple el formato exigido desde el 16 de noviembre de 2026. | Válido | |
| Fedwire pacs.009 — conformant bank-to-bank transferUna transferencia entre instituciones financieras: el tramo interbancario, donde deudor y acreedor son bancos, no clientes. | Válido | |
| Fedwire pacs.008 — unstructured address, settling after 16/11/2026La dirección del acreedor son tres líneas libres sin ciudad ni país. Válida frente al XSD, rechazada por la regla: desde el 16 de noviembre de 2026 Fedwire elimina la dirección totalmente no estructurada. | Inválido | |
| Fedwire pacs.008 — same unstructured address, settling before the cut-overEl contraejemplo: exactamente la misma dirección no estructurada, pero con liquidación el 30/06/2026. Es legal, así que solo advierte. El desencadenante es la fecha de liquidación del mensaje, nunca la fecha de hoy. | Válido | |
| Fedwire pacs.008 — routing number that cannot existEl routing number del banco del beneficiario es 021000088: un dígito equivocado. Falla el dígito de control ABA 3-7-1, así que no es un número que pueda existir. El XSD solo ve nueve dígitos correctos. | Inválido | |
| Fedwire — header announces a different message than it carriesLa cabecera BAH declara <MsgDefIdr>pacs.009.001.08</MsgDefIdr> mientras que el documento que encabeza es un pacs.008. Cada mitad es válida frente a su propio esquema: solo compararlas lo detecta. | Inválido |
Transferencia SWIFT MT103 (2)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| MT103 — cross-currency customer credit transferUn MT103 completo: los cinco bloques SWIFT, un UETR, un ordenante en opción K, agentes en opción A y un beneficiario con IBAN. Liquidado en USD e instruido en EUR, por lo que el campo :36: (tipo de cambio) es obligatorio y está presente. | Válido | |
| MT103 — three defects a plain text viewer would missEstructuralmente, un MT103 perfectamente legible… y equivocado tres veces: el UETR no es un UUID v4, el pago es multidivisa sin tipo de cambio en :36:, y el IBAN del beneficiario falla el dígito de control mod-97. | Válido |
Archivo de pagos CPA-005 / AFT (Canadá) (6)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| CPA-005 — payroll direct deposit (two credits in one record)Un archivo de nóminas canadiense corriente: un único registro «C» que lleva dos depósitos directos (tipo de operación 200) en dos de sus seis segmentos. El trailer Z declara 2 abonos por 3.750,50 y ningún adeudo, y cuadra. Obsérvese que el contador de registros cuenta registros FÍSICOS mientras que el trailer cuenta TRANSACCIONES: hay tres registros y dos transacciones. | Válido | |
| CPA-005 — a pre-authorised debit and its NSF return (code 901)Un adeudo preautorizado «D» de 899,00 seguido del registro «J» que lo devuelve. La devolución lleva el código 901 (fondos insuficientes) en el campo TIPO DE OPERACIÓN — donde el pago llevaría su tipo — mientras que el tipo original 700 sobrevive en el stored transaction type. Ambos se contabilizan como adeudos, de ahí los 2 adeudos por 1.798,00 del trailer. | Válido | |
| CPA-005 — the error correction folded into the debit totalRoto a propósito, y roto como lo rompen los generadores reales: el fichero anula un abono con un registro «E», y el trailer cuenta esa anulación como un adeudo. No lo es. La norma 005 da a las correcciones E y F su PROPIO par de totales, separado de los pares de adeudos y abonos: fundirlos descuadra el fichero. Es la causa más frecuente de rechazo de un generador CPA-005 hecho a mano. | Inválido | |
| CPA-005 — credits (C) and debits (D) in one file, four pairs of totals balancedUn archivo AFT de 1464 caracteres que mezcla ambos sentidos: un registro «C» con dos depósitos de nómina (3.750,50) y un registro «D» con dos adeudos preautorizados (1.349,25). C es el ABONO y D el ADEUDO — varios resúmenes publicados los invierten. El trailer Z cuadra sobre los cuatro pares de totales que define la norma 005 (D+J, C+I, E aparte, F aparte), aquí con los contadores E y F a cero. | Válido | |
| CPA-005 — Notice of Change file (U / S / V records, 208 characters)Un Notice of Change canadiense: la entidad receptora avisa al emisor de que una cuenta ha cambiado. Es un FICHERO APARTE — los registros son de 208 caracteres, no de 1464, y la norma 005 prohíbe mezclar sus registros U (cabecera), S (cambio) y V (trailer) con registros AFT. Cada S lleva el nuevo número de ruta y la nueva cuenta junto a los anteriores, y el trailer V declara cuántos S contiene el fichero. | Válido | |
| CPA-005 — transit 099999999 passes: there is no check digit in CanadaUn fichero de nóminas cliente→banco que un validador formado en reglas estadounidenses rechazaría dos veces por error. Su primer abono va al tránsito 099999999, que no lleva ningún dígito de control aritmético: el DPRN canadiense sencillamente no tiene ninguno — la norma 005 lo valida consultando el Financial Institutions File y la norma 006 no define ninguna fórmula. Trasladar aquí la regla ABA 3-7-1 rechaza ficheros perfectamente válidos. Además, sus Item Trace Numbers están a cero, lo normal en un fichero que un cliente envía a su banco (los asigna el Direct Clearer): de ahí dos advertencias y cero errores. | Válido |
Archivo ACH / NACHA (EE. UU.) (10)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| ACH — a returned WEB debit (R01, insufficient funds)Un adeudo WEB de 123,54 que vuelve. En una devolución cambian tres cosas y nada más: el transaction code pasa a 26 (el código de devolución de un adeudo en cuenta corriente, NO el 27 original), el banco receptor pasa a ser el ODFI del original, y se asigna un nuevo trace number. El importe no cambia: la ACH no conoce la devolución parcial. El addenda 99 lleva R01 y apunta al trace de la entrada original. El lote sigue siendo WEB y sigue diciendo TRANSFER: no existe una descripción «RETURN» ni un código SEC «RET», por mucho que la web diga lo contrario. | Válido | |
| ACH — a notification of change (C01, corrected account number)Una notificación de cambio — y lo esencial es que NO es un rechazo. El pago se realizó. El banco receptor pide que se corrija el dato almacenado antes del PRÓXIMO pago: reenviar este pagaría al beneficiario dos veces. De ahí el importe CERO de la entrada y el código SEC COR del lote. El addenda 98 lleva C01 con el número de cuenta corregido en las posiciones 36-52 del registro. | Válido | |
| ACH — an international entry (IAT) with its seven mandatory addendaUn pago USD → MXN a México. Un registro IAT no es el registro nacional con otras etiquetas: el número de cuenta pasa a las posiciones 40-74 (35 caracteres, para alojar una cuenta extranjera), las posiciones 13-16 declaran cuántos addenda siguen, y el nombre del beneficiario no está en el registro en absoluto: vive en el addenda 10. Siete addenda (del 10 al 16) son obligatorios en toda entrada internacional, porque un registro de 94 caracteres no puede contener el nombre, la dirección y la identificación bancaria de ambas partes. Leer este fichero con los desplazamientos nacionales devuelve un fragmento del número de cuenta como si fuera un nombre de persona. | Válido | |
| ACH — PPD payroll credits, balanced with an offset debitEl fichero de referencia: el aspecto de un fichero NACHA correcto. Cuatro abonos de nómina PPD (tres a cuenta corriente, código 22, uno a cuenta de ahorro, código 32) y una quinta entrada: el adeudo de compensación (offset), código 27, sobre la propia cuenta de la empresa por el total exacto. Eso es lo que hace que el fichero esté «balanceado», y por eso el service class code es 200 (mixto) y no 220. Entry hash, totales del Batch Control, totales del File Control y block count cuadran todos, y cada routing number satisface el dígito de control ABA 3-7-1. | Válido | |
| ACH — CCD corporate debits with an addenda 05 remittanceUn cobro B2B: dos adeudos CCD (service class 225, solo adeudos), cada uno con un addenda 05 que lleva la factura que salda — segmentos RMR y REF, la remesa ASC X12 con la que el receptor corporativo concilia. El CCD admite exactamente UN addenda por entrada: 80 caracteres de información de pago, ni uno más. Cuando el pagador necesita más espacio, el código SEC pasa a ser CTX. Fíjese en el addenda record indicator de la posición 79 de la entrada: vale 1, y efectivamente le sigue un addenda. | Válido | |
| ACH — WEB debits (e-commerce, recurring and single-entry)Cuatro adeudos WEB: el código SEC de un pago que un consumidor autorizó en línea. Tres salen de cuentas corrientes (código 27) y uno de una cuenta de ahorro (código 37): lo dice el transaction code, y leerlo como otra cosa que una tabla es justo el error que cometen los parsers. Las posiciones 77-78 llevan el payment type indicator, R para recurrente y S para pago único. Las entradas WEB no llevan addenda, así que el addenda record indicator queda en 0. | Válido | |
| ACH — CTX with seven addenda 05 carrying an EDI 820Un adeudo CTX de 28 750,00 que salda tres facturas a la vez, con el aviso de remesa ASC X12 820 repartido en siete addenda 05. CTX es el código SEC que más a menudo interpretan mal los parsers, porque el registro de entrada no significa lo que significa en todos los demás sitios: las posiciones 55-58 NO son el principio de un nombre, son el NÚMERO de addenda que siguen (0007 aquí), y el nombre de la empresa receptora solo empieza en 59. Leído con los desplazamientos PPD, el nombre sale como «0007GLOBEX CORP», que es precisamente lo que muestra nuestro propio validador, que aplica el formato nacional. | Válido | |
| ACH — entry hash mismatch (truncated or tampered file)Un fichero de abonos PPD con el entry hash incorrecto. El entry hash es la suma de los routing numbers de 8 dígitos de todas las entradas, truncada a sus diez últimos dígitos: una suma de control cuyo único cometido es atrapar un fichero que ha perdido, ganado o visto alterar una entrada por el camino. Aquí el Batch Control y el File Control declaran ambos 28905251 mientras que las cuatro entradas suman 27905251. Los importes siguen cuadrando, y esa es la gracia: el hash es el control que salta cuando ningún otro lo hace. | Inválido | |
| ACH — batch control debit total ≠ the sum of its entriesUn lote de adeudos CCD cuyo Batch Control declara 18 450,00 mientras que sus dos entradas suman 28 075,00: el error clásico del generador que escribe el trailer antes de haber añadido la última entrada. Todo lo demás del fichero es correcto, incluidos los totales del File Control, así que el validador señala exactamente un error y nombra ambas cifras. Es la primera causa de rechazo de un fichero ACH hecho a mano. | Inválido | |
| ACH — invalid ABA 3-7-1 check digit on an entry routing numberUn fichero de adeudos WEB en el que un banco receptor lleva 026009594: un routing number que falla el dígito de control ABA 3-7-1 (el verdadero es 026009593). Solo la posición 12 de la entrada es incorrecta, así que el entry hash y todos los totales de control siguen cuadrando: el dígito de control es el único control que atrapa una cifra mal tecleada, y este fichero lo demuestra — los totales, por sí solos, no lo verán. Las otras dos entradas y todos los trailers son correctos, de modo que el validador señala exactamente un error. | Inválido |
Código QR de pago (EPC / factura QR suiza) (6)
| Ficheros de ejemplo | Resultado esperado | Descargar el fichero |
|---|---|---|
| EPC QR code — version 002 with a structured creditor reference (RF)Una carga útil de código QR EPC (SCT QR) conforme, versión 002: aquella en la que el BIC es opcional, y aquí se omite. El concepto es una referencia de acreedor estructurada ISO 11649, RF6518539007547034, con dígitos de control mod-97 correctos: 94 bytes de los 331 permitidos. | Válido | |
| EPC QR code — version 001 (BIC mandatory) with a free-text messageLa otra mitad de EPC069-12: la versión 001, en la que el BIC del beneficiario es obligatorio (es la única diferencia entre 001 y 002), con un texto libre en lugar de una referencia. Referencia estructurada y texto libre son excluyentes: un código QR lleva uno u otro, nunca ambos. | Válido | |
| EPC QR code — 312 characters but 338 bytes: over the 331-byte capLa trampa que la norma deletrea y en la que aun así caen las implementaciones: EPC069-12 limita la carga útil a 331 BYTES, no caracteres. Esta carga en polaco tiene 312 caracteres — holgadamente por debajo de cualquier recuento — pero cada letra acentuada cuesta dos bytes en UTF-8: pesa 338 bytes y es rechazada. | Inválido | |
| Swiss QR-bill — QR-IBAN with a QRR reference (the pairing rule, satisfied)La factura QR suiza canónica: un QR-IBAN (ID de institución 31999, dentro del rango 30000-31999) emparejado con la referencia QRR que exige — 26 dígitos más un dígito de control en módulo 10 recursivo, no el mod-97 del mundo IBAN. Fíjese en el bloque «ultimate creditor»: siete líneas, presentes y completamente vacías, tal como piden las directrices. | Válido | |
| Swiss QR-bill — normal IBAN with an ISO 11649 (SCOR) referenceLa otra mitad de la regla de emparejamiento: un IBAN normal (ID de institución 00791, fuera del rango QR-IID) PROHÍBE una referencia QRR y admite una referencia de acreedor ISO 11649 (SCOR) — RF6518539007547034 — o ninguna. Misma factura, otro tipo de cuenta, otra referencia: de esta distinción depende que un pago suizo pueda conciliarse. | Válido | |
| Swiss QR-bill — QR-IBAN carrying a SCOR reference (the pairing rule, broken)El error de mayores consecuencias del formato suizo: un QR-IBAN que lleva una referencia ISO 11649 (SCOR). La referencia en sí es perfectamente válida — ahí está la trampa —, pero un QR-IBAN exige una referencia QRR y ninguna otra. El banco no puede contabilizar el pago, y el veredicto es el mismo bajo las directrices 2.3 y 2.4. | Inválido |
Cómo sabemos que estos resultados se sostienen
Cada fichero de esta biblioteca pasa por el propio validador del sitio en cada build. El resultado esperado indicado arriba lo verifica un test automatizado: si un fichero dejara de coincidir con lo que afirma esta página, el build fallaría. Dos fixtures heredadas se repararon así antes de publicarse: tres IBAN no superaban el mod-97 y varios nombres usaban caracteres fuera del juego SEPA básico.