01 — Por qué importa
El único error que el banco no va a detener por usted
Casi todos los errores de un fichero de pagos los detiene alguien. Un fichero mal formado se rechaza al subirlo. Una suma de control que no cuadra se rechaza antes de que se mueva nada. Son molestos, y son inofensivos.
Pagar dos veces la misma factura no es ninguna de las dos cosas. En el fichero el segundo pago es idéntico al primero: IBAN válido, importe válido, estructura válida. El banco no tiene motivo para rechazarlo — así que no lo rechaza. Se enterará cuando el proveedor lo mencione, o al conciliar la cuenta. Que el dinero vuelva dependerá entonces de la buena voluntad del otro lado.
Pasa de la forma más corriente: una remesa exportada dos veces, un pago añadido a mano mientras el original seguía en curso, un circuito de aprobación que produjo dos ficheros. Nada llamativo — y justo por eso nadie lo busca.
02 — Y la errata cara
Un IBAN lleva consigo su dígito de control
Los caracteres tres y cuatro de un IBAN son una suma de control sobre todo lo demás (ISO 13616, módulo 97-10). Una cifra equivocada en cualquier punto y la cuenta deja de salir — así que una errata se puede detener aquí, sin conexión, sin preguntar a nadie.
Si el número está mal y aun así es válido, el dinero llega a una cuenta real que no es la de su proveedor. Si está mal y no es válido, el pago vuelve días después y la factura ha quedado silenciosamente vencida. Ambas cosas merecen dos segundos de aritmética.
Suelte también las facturas
Todo lo anterior es el fichero comprobado contra sí mismo: si la cabecera cuadra con el contenido, si los dígitos de control salen, si hay algo repetido. Queda una pregunta que el fichero por sí solo no puede responder — ¿es este el importe que pide la factura?
Un cero de más tecleado en un ERP produce un pago perfectamente válido. 12.000 y 1.200 son dos importes bien formados, los dos superan cualquier comprobación de formato, y el banco ejecuta el que está en el fichero. Aflora al conciliar — cuando el dinero ya está en la cuenta de otro.
Suelte entonces las facturas junto al fichero de pagos. El emparejamiento se hace por
el número de factura escrito en el concepto — así es como concilia también la otra
parte — y después se contrastan los importes. Los separadores dan igual:
RE-2026/0417 y RE20260417 son el mismo número.
Mejor no emparejar que emparejar mal: los números de factura de menos de cinco caracteres quedan fuera (aparecerían dentro de cualquier texto), y un concepto que cita dos facturas se salta. Las divisas distintas se avisan en lugar de convertirse — adivinar un tipo de cambio para atribuir a alguien un error no compensa.
Adeudos directos
Una remesa de adeudos (pain.008) pasa por las mismas comprobaciones, porque dentro se tuercen las mismas cosas — solo cambia a quién le toca. Un IBAN equivocado significa que ese adeudo vuelve días después mientras la factura salió hace tiempo. Y cargar dos veces al mismo cliente no es simplemente un importe de más: es una reclamación, una devolución, y en la zona SEPA el cliente puede reclamar el reembolso durante ocho semanas sin dar explicaciones. El dinero vuelve. Las comisiones no.
Dos cosas no se juzgan aquí a propósito: los datos del mandato y si la secuencia (FRST / RCUR / FNAL) es la correcta. Las dos dependen de si a este cliente ya se le ha cargado antes, y eso no está en el fichero. No decir nada es mejor que adivinar.
No se sube nada
Una remesa de pagos contiene a todos sus proveedores, lo que les paga y su número de cuenta. No es un fichero para dárselo a un formulario web. Se lee en el navegador: abra las herramientas de desarrollo, pestaña Red, y suelte un fichero — no sale ninguna petición. O bien: cargue la página, desconecte la red y suéltelo igualmente. Sigue funcionando.
Lo mismo vale para el resto del sitio: facturas en una tabla, una factura contrastada con EN 16931 y la lista completa de reglas.