Mobile money y ERP: integrar los pagos móviles en el núcleo de gestión.

El escenario se repite. Una empresa de distribución cobra una parte creciente de sus ventas mediante pago móvil. Cada semana, una persona de contabilidad descarga los extractos de cada monedero, los concilia a mano con las facturas abiertas y luego registra un asiento por el total. Las desviaciones quedan en suspenso. Las comisiones del operador se estiman. El saldo del monedero no aparece en ninguna parte del balance intermedio. En el cierre, esas cuentas transitorias se convierten en el primer tema de conversación con el auditor de cuentas.

Una realidad del mercado, no un proyecto innovador

Hay que cambiar primero la mirada. El pago móvil no es un canal experimental que tratar en un proyecto aparte. Es un medio de pago, igual que la transferencia, el cheque o el efectivo, y debe tratarse en el núcleo de gestión con el mismo rigor: una cuenta de tesorería por monedero, un diario, documentos justificativos, una conciliación periódica. Mientras el ERP no lo vea, la empresa dirige su tesorería sobre una imagen parcial.

Los flujos que integrar

Cobros de clientes. El cliente paga una factura, un anticipo o una compra al contado desde su teléfono. El ERP debe recibir la transacción con su referencia, asociarla a la factura o al cliente, casar la cuenta y registrar las comisiones. El punto delicado es la identificación: un pago móvil llega con un número de teléfono y un importe, rara vez con un número de factura. El proyecto debe, por tanto, diseñar la referencia de pago, comunicarla al cliente y leerla en la recepción. Sin eso, el casado seguirá siendo manual.

Pagos a proveedores y a empleados. En el otro sentido, la empresa paga a proveedores, transportistas, jornaleros o empleados mediante pago móvil, a menudo de forma masiva. El ERP debe generar la orden de pago a partir de las facturas validadas o de la nómina, transmitirla, recibir la confirmación o el rechazo, y contabilizarlo todo línea por línea. Aquí el asunto ya no es la identificación, sino el control: quién valida la lista, quién la transmite y cómo se trata un rechazo.

Conciliación y contabilización SYSCOHADA

Un monedero de pago móvil es una cuenta de tesorería. Se sigue y se concilia como una cuenta bancaria. La conciliación confronta el extracto del operador con los asientos del ERP, transacción por transacción, y aísla las desviaciones: pagos recibidos no identificados, pagos emitidos no confirmados, comisiones, anulaciones. En el SYSCOHADA revisado, esas operaciones encuentran su lugar en las cuentas de tesorería y de gastos adecuadas, con un documento por transacción y no un asiento global. Lo que cambia con una integración real: el extracto deja de ser un fichero descargado y pasa a ser un flujo recibido por el sistema, y la conciliación se convierte en una excepción que tratar en lugar de una tarea semanal.

Esa disciplina tiene una consecuencia directa en el cierre. Cuando cada pago móvil se contabiliza por transacción, se casa y se concilia, las cuentas transitorias se vacían y la tesorería del balance refleja el dinero realmente disponible, monederos incluidos. Hablamos de ello en nuestro punto de vista sobre el cierre SYSCOHADA: una cuenta transitoria que engorda cada mes es un flujo que el sistema no sabe tratar.

Un monedero móvil es una cuenta de tesorería. Mientras el ERP no lo vea, la empresa dirige su dinero sobre una imagen parcial.

Integrar por API, no por fichero

Los operadores de pago móvil exponen interfaces que permiten iniciar un pago, recibir su notificación y consultar un saldo o un histórico. Sobre esas interfaces se construye una integración duradera, no sobre exportaciones descargadas. La arquitectura depende del núcleo de gestión. Con SAP S/4HANA, la integración pasa por SAP BTP, que soporta los conectores, la transformación de los mensajes y la supervisión, manteniendo el núcleo libre de todo desarrollo específico. Cuando la empresa tiene además Salesforce, MuleSoft desempeña ese papel de capa de integración común entre el CRM, el ERP y los operadores. Con Odoo existen conectores para los principales operadores de la subregión; deben evaluarse por su mantenimiento y su cobertura antes de adoptarlos.

Sea cual sea la plataforma, tres reglas. Una capa de integración separada del núcleo, para absorber los cambios de interfaz de los operadores sin tocar el ERP. Una supervisión de los flujos, para ver un pago bloqueado antes de que el cliente reclame. Y una gestión de los casos de error concebida desde el principio: tiempo de espera agotado, rechazo, duplicado, reembolso.

Control interno y fraude

El pago móvil es rápido e irreversible. Esa es su fuerza comercial y su riesgo de control. Los esquemas de fraude que vemos son sencillos: un número de teléfono beneficiario modificado en una ficha de proveedor, un pago de salario duplicado, un cobro desviado hacia un monedero personal, un reembolso ficticio. Ninguno exige competencia técnica. Todos aprovechan una ausencia de separación de funciones o de trazabilidad.

La integración en el ERP es justamente lo que permite responder a ello. Los números de los beneficiarios pasan a ser datos maestros, con una validación a cuatro ojos en cada modificación. Los pagos masivos siguen un circuito de validación, con límites por persona y por día. Cada transacción lleva su autor, su fecha y su documento. Los monederos los concilia una persona que no los manipula. Y las alertas, importe inhabitual, beneficiario nuevo, pago fuera de horario, salen del sistema en lugar de depender de una vigilancia individual. Nuestra oferta seguridad y riesgos IT aborda esos controles como una parte del proyecto de integración, no como una auditoría posterior.

Datos personales

Un número de teléfono asociado a un pago es un dato de carácter personal. Los flujos de pago móvil, entrantes y salientes, constituyen un tratamiento en el sentido de la ley n.º 2008-12, que debe declararse ante la CDP según las formalidades aplicables, con una finalidad, un plazo de conservación y reglas de acceso. Los registros de transacciones, útiles para el control, deben protegerse igual que la nómina. Desarrollamos esta cuestión en nuestro punto de vista sobre el cumplimiento CDP desde el encuadre.

Lo que recomendamos

• Tratar el pago móvil como un medio de pago del núcleo de gestión, con una cuenta de tesorería por monedero y un documento por transacción.
• Diseñar la referencia de pago antes de la integración: es la que hace automático el casado.
• Integrar por API, a través de una capa dedicada: SAP BTP, MuleSoft o conectores de Odoo, nunca mediante desarrollo directo en el núcleo.
• Conciliar cada día, por excepción, y no dejar que ninguna cuenta transitoria viva más allá del mes.
• Implantar la separación de funciones sobre los beneficiarios, las validaciones y las conciliaciones, con alertas soportadas por el sistema.
• Declarar el tratamiento y proteger los datos de pago como datos sensibles.

El pago móvil ya está en su cifra de negocio. La única cuestión es saber si está también en su sistema, o si vive en una hoja de cálculo, entre la tesorería real y la tesorería contable. Es un proyecto corto, en el cruce de nuestra especialidad finanzas y de nuestros trabajos de integración y API, y uno de aquellos cuyo efecto se ve ya en el siguiente cierre.