Cómo acertar con los detalles de pago en las transferencias empresariales

La mayoría de las transferencias empresariales que fallan o se retrasan no se deben a fondos insuficientes, sino a instrucciones de pago incorrectas. Una vez que una transferencia se libera en los rails bancarios, es difícil recuperarla, y los pagos wire que se enrutan a través de bancos corresponsales son, en la práctica, irreversibles. Los errores en los datos del beneficiario pueden provocar devoluciones, deducciones de intermediarios, comisiones de investigación y trabajo de conciliación que cuesta más que el pago original. Tratar los detalles de pago como datos estructurados que deben capturarse, validarse y verificarse, en lugar de texto libre copiado de una factura, es la base de unos pagos salientes fiables.

Campos esenciales de los que depende toda transferencia

Cada transferencia se apoya en un pequeño conjunto de campos que deben coincidir con los registros del banco receptor: el nombre del beneficiario exactamente como está registrado, el número de cuenta en el formato que espera el rail de destino, el identificador bancario (SWIFT/BIC a nivel internacional, códigos routing o sort a nivel nacional), el nombre y la dirección del banco receptor, la moneda y el importe. Los campos de referencia y de propósito merecen la misma atención, ya que el equipo de conciliación del destinatario los utiliza para asociar el pago a una factura. Varios rails realizan hoy en día comprobaciones del nombre en el destino, como el Confirmation of Payee en el Reino Unido, de modo que un nombre comercial o una abreviatura puede desencadenar una advertencia o un rechazo incluso cuando el número de cuenta es correcto. Los formatos con checksum, incluidos el IBAN y la CLABE de 18 dígitos de México, permiten una validación mecánica antes de enviar el pago.

Rails locales y sus propias reglas de direccionamiento

Los pagos empresariales transfronterizos se liquidan cada vez más a través de rails instantáneos locales en lugar de los corredores SWIFT tradicionales, y cada rail tiene requisitos de direccionamiento propios. Los abonos SEPA se direccionan mediante el IBAN dentro de la zona; ACH en Estados Unidos utiliza un número de routing de nueve dígitos más un número de cuenta; PIX en Brasil puede direccionarse mediante claves registradas como el CPF, el CNPJ, un número de teléfono, un correo electrónico o un código aleatorio; SPEI en México se enruta mediante la CLABE; el IMPS y el NEFT de la India utilizan un número de cuenta más un IFSC. Como algunos identificadores incorporan el código del banco de destino, un valor mal escrito puede desviar los fondos a una institución completamente distinta. La asignación de comisiones también debe acordarse de antemano, ya que las cadenas de bancos corresponsales pueden hacer deducciones sobre el importe recibido (los códigos de cargos SWIFT OUR, BEN y SHA existen precisamente por este motivo). Las plataformas que conectan las tesorerías de stablecoins con los rails bancarios, incluida Oobit, que liquida pagos empresariales en cuentas bancarias locales a través de SEPA, ACH, PIX, SPEI y sistemas similares, presentan una vista previa de liquidación que muestra el tipo de conversión, las comisiones y el importe final del abono antes de autorizar una transferencia, lo que ofrece a los equipos de finanzas un punto de control fijo para confirmar los detalles.

Verificación y cumplimiento antes de mover los fondos

Antes de que los fondos salgan de la tesorería, el banco y la jurisdicción del destinatario deben contrastarse con bases de datos de sanciones y de cumplimiento, y el propósito del pago debe documentarse en los casos en que las normas de reporte transfronterizo lo exijan. Los datos bancarios de los proveedores deben verificarse de forma independiente en el momento del alta, y toda solicitud posterior de cambio debe confirmarse a través de un contacto conocido o mediante un procedimiento de devolución de llamada, ya que el business email compromise, en el que los atacantes sustituyen sus propios datos en una factura de aspecto legítimo, es una causa bien documentada de pagos corporativos desviados. En el caso de transferencias de alto valor o de beneficiarios nuevos, enviar un pequeño pago de prueba y confirmar su recepción antes del importe principal sigue siendo una precaución estándar.

Controles internos que detectan errores

Los datos recurrentes de los proveedores deben guardarse en plantillas de pago almacenadas, en lugar de volver a escribirse en cada ciclo de pagos, con una doble revisión de cualquier registro nuevo o modificado. Los validadores automáticos pueden comprobar la aritmética mod-97 del IBAN, los dígitos de control de la CLABE y la estructura del IFSC antes del envío. Un responsable designado para las excepciones de pago, un proceso documentado de recuperación con el banco emisor y la conservación de los registros de transferencia acortan el tiempo de recuperación cuando algo sale mal. El propósito de esta disciplina es sencillo: un pago debe hacerse bien una sola vez, en el momento de su captura, en lugar de tener que recuperarlo laboriosamente después.