Layout bancario para pago a proveedores: qué es, cómo se arma y por qué no debería salir de un Excel

¿Qué es un layout bancario de pago a proveedores?

Un layout bancario es un archivo plano que el portal de banca empresarial acepta para ejecutar muchas transferencias de una sola vez. Cada renglón es un pago. Cada columna es un dato del pago, en la posición y el formato que la institución espera. El nombre cambia según el banco —archivo de dispersión, pagos masivos, transferencias por lote—, pero la mecánica es la misma.

Los campos habituales son pocos. La cuenta destino, que puede ser una CLABE de 18 dígitos para transferencias interbancarias, una cuenta de la misma institución o una tarjeta. El importe, con los decimales que el formato exija. El nombre del beneficiario. Una referencia numérica y un concepto de pago, que es lo que el proveedor ve en su estado de cuenta. Según el banco se agregan la clave de la institución destino, la fecha de aplicación o un correo de aviso.

El formato también varía. Algunos bancos leen un CSV con un separador definido, con o sin renglón de encabezado. Otros exigen texto de ancho fijo, donde cada campo ocupa posiciones exactas y se rellena con ceros o espacios. Un importe que debe ir en centavos sin punto decimal es un detalle que el banco rechaza si no se respeta. Una CLABE que debe ir con ceros a la izquierda, también. Y el rechazo no siempre dice cuál fue el problema.

Qué alimenta el layout: la propuesta de pago

El layout no nace en Tesorería. Nace en Cuentas por pagar, en la propuesta de pago. La propuesta es la lista de facturas que ya pasaron la recepción, el cruce con la orden de compra y la cadena de autorización, agrupadas por moneda y por fecha de pago. De esa lista sale un renglón por factura o un renglón por proveedor, según la política de la empresa.

Lo que separa una propuesta seria de una lista de facturas es lo que se verificó antes de llegar a ella. Que la factura está vigente ante el SAT. Que el proveedor está en regla. Que el monto cierra con la orden de compra dentro de la tolerancia. Que alguien con facultad la autorizó, y que no fue la misma persona que la recibió. Sobre ese último punto trata el artículo de segregación de funciones en cuentas por pagar.

Si la propuesta se arma bien, el layout es una exportación. Si la propuesta se arma a mano, el layout hereda cada error de la propuesta y le agrega los suyos.

Dónde se rompe cuando se arma en un Excel

Una hoja de cálculo es un editor de renglones sin memoria de lo que cada renglón representa. Los errores que produce se repiten en cualquier empresa que la use para esto.

La CLABE mal tecleada. Dieciocho dígitos copiados de un correo o de una carátula escaneada. Un dígito transpuesto produce, en la mayoría de los casos, una CLABE que no pasa la validación del banco, y el pago rebota. En los casos en que sí pasa, el dinero llega a otra cuenta.

El importe que no descontó la nota de crédito. La factura decía 100, el proveedor emitió una nota de crédito por 10 y el renglón dice 100. La nota llegó por otro correo y nadie la ligó a la factura. Cómo ligarla por UUID se explica en nota de crédito con UUID relacionado.

La factura que no estaba autorizada. Entró a la lista porque estaba en la carpeta del mes, no porque alguien la firmara. El banco no distingue una factura autorizada de una que no lo está. Solo ve un renglón.

El archivo de la semana pasada. Se abre el layout anterior como plantilla, se cambian tres importes y se olvida un renglón. Ese proveedor cobra dos veces. Recuperar un pago duplicado depende de la buena voluntad del proveedor y de semanas de correos.

La celda que Excel reformateó. Una CLABE que empieza con cero pierde el cero al abrir el archivo. Un importe con separador de miles se lee como texto. Un CSV guardado con el separador equivocado corre todas las columnas un lugar.

Ninguno de estos errores es de la persona que arma el archivo. Son del método.

Qué validar antes de exportar

Cada renglón del layout debería pasar cinco comprobaciones antes de salir. Las cinco son mecánicas y un sistema las corre sin criterio humano.

La CLABE: 18 dígitos y dígito verificador

La CLABE (Clave Bancaria Estandarizada) tiene 18 dígitos. Los primeros tres identifican a la institución, los siguientes tres a la plaza, los once siguientes a la cuenta y el último es un dígito verificador. El algoritmo del verificador es público. Cada uno de los 17 primeros dígitos se multiplica por un peso que se repite en ciclo (3, 7, 1) y de cada producto se toma la última cifra. Esas cifras se suman, y el verificador es lo que le falta a la suma para llegar a la siguiente decena; si ya termina en cero, es cero.

Correr ese cálculo sobre cada CLABE descarta la mayoría de los errores de captura antes de que el banco los vea. Un sistema serio lo hace al momento de guardar la CLABE, no al momento de pagar.

El banco, reconocido por el prefijo

Los tres primeros dígitos se cruzan contra el catálogo público de instituciones. Una CLABE con un prefijo que no existe puede pasar el dígito verificador y aun así no llegar a ningún lado. Reconocer el banco sirve además para separar, si el layout lo pide, las transferencias a la misma institución de las interbancarias.

El beneficiario es la razón social del proveedor

El nombre del renglón debe coincidir con la razón social del proveedor que emitió la factura, tomada del padrón y no del correo donde pidió el pago. Una CLABE válida a nombre de otra persona es la forma más simple de desviar un pago. Por eso quien carga la CLABE y quien la revela tienen permisos distintos, y ninguno de los dos es quien arma el archivo.

El importe es el monto a pagar, no el total de la factura

El importe sale de la factura menos las notas de crédito ligadas por UUID, en la moneda de la factura. Si la propuesta se agrupa por proveedor, la suma debe ser trazable renglón por renglón a las facturas que la componen. Un importe que no se puede reconstruir desde las facturas no debería ir al banco.

La entrada de mercancía, si la política lo exige

Muchas empresas no pagan sin una entrada registrada en el ERP, sea una entrada de mercancía (MIGO) o una hoja de entrada de servicios (HES). Es la evidencia de que lo facturado se recibió. Esa comprobación pertenece al cruce con la orden de compra y se detalla en conciliación de factura contra orden de compra. En la propuesta de pago solo se confirma que existe.

Campo por campo: de dónde sale y qué se valida

Campo del layout	De dónde sale	Qué se valida
Cuenta destino (CLABE)	Padrón de proveedores, cargada por el proveedor	18 dígitos, dígito verificador, prefijo en el catálogo
Nombre del beneficiario	Razón social del padrón	Coincide con el emisor del CFDI
Importe	Factura menos notas de crédito ligadas	Trazable a las facturas autorizadas de la propuesta
Moneda	Factura y propuesta	Una sola moneda por propuesta
Referencia	Folio de la factura o de la propuesta	Única por renglón; permite ligar el comprobante
Concepto	Folio y proveedor	Largo y caracteres que el formato admite
Fecha de aplicación	Propuesta de pago	Día hábil bancario
Entrada (MIGO/HES)	ERP, por orden de compra	Registrada, si la política lo exige

Quién carga la CLABE y cómo se guarda

La CLABE la carga el proveedor, no el área de pagos. Lo hace en su portal, una vez, con su propio usuario. Desde ese momento su dato bancario viaja con la factura y no por correo. Cambiar la CLABE exige entrar al portal con las credenciales del proveedor, y el cambio queda registrado con fecha y usuario. Un correo que pide «actualizar la cuenta de depósito» deja de tener efecto sobre los pagos, y ese correo es un vector de fraude conocido en cualquier área de pagos.

Cómo se guarda importa tanto como quién la carga. La CLABE es un dato sensible y se trata como tal. Cifrada en reposo. Enmascarada en pantalla, con los últimos cuatro dígitos visibles para que quien arma la propuesta la reconozca sin verla entera. Revelada solo con un permiso específico, y con bitácora de quién la consultó y cuándo. Es el mismo tratamiento que reciben CURP, RFC y NSS en un expediente de proveedores serio.

Qué queda como evidencia

El pago no termina cuando el banco acepta el archivo. Termina cuando cada factura tiene su comprobante ligado y el proveedor sabe que cobró.

Tres piezas cierran el ciclo. El comprobante que emite el banco, guardado junto a la factura que pagó y no en una carpeta de Tesorería que nadie relaciona con el CFDI. El cambio de etapa de la factura a pagada, con fecha, actor y comprobante. Y el aviso al proveedor, que le ahorra al área los correos preguntando si ya se pagó.

Con esas tres piezas, una auditoría reconstruye cada pago desde la orden de compra hasta el estado de cuenta sin pedirle nada a nadie. Y una factura PPD pagada con evidencia es la base para exigirle al proveedor su complemento de pago en plazo.

Cómo lo hace Vigía Legal

En Vigía Legal, la propuesta de pago se arma con las facturas autorizadas de una misma moneda. Cada partida muestra su conciliación de entrada (MIGO/HES) y la CLABE del proveedor enmascarada, cargada por él desde su portal y validada al guardarla —18 dígitos, dígito verificador, banco por prefijo—. Las notas de crédito ligadas por UUID ya bajaron el monto a pagar antes de que la factura llegue a la propuesta.

La exportación usa un layout configurable. Columnas, orden, formato de importes y fechas, separador o ancho fijo, con o sin encabezado, se mapean sin código. Durante la implementación el mapeo se configura con el archivo real que su banco lee y se prueba contra él antes de la primera propuesta. Vigía Legal no ejecuta el pago ni contabiliza; produce el archivo y registra lo que pasa después.

Cuando el banco aplica la dispersión, se sube el comprobante a la propuesta. Cada factura pasa a pagada con ese comprobante y el proveedor recibe el aviso en su portal. La CLABE queda cifrada, con la bitácora de cada consulta. Quien arma la propuesta ve la cuenta enmascarada; revelarla es un permiso aparte.