Mobile money e ERP: integrar os pagamentos móveis no núcleo de gestão.

O cenário repete-se. Uma empresa de distribuição recebe uma parte crescente das suas vendas por pagamento móvel. Todas as semanas, alguém da contabilidade descarrega os extratos de cada carteira, reconcilia-os manualmente com as faturas em aberto e lança um movimento pelo total. As diferenças ficam em suspenso. As comissões do operador são estimadas. O saldo da carteira não aparece em lado nenhum no balancete intercalar. No fecho, estas contas transitórias tornam-se o primeiro tema de discussão com o revisor oficial de contas.

Uma realidade do mercado, não um projeto inovador

É preciso, antes de mais, mudar de olhar. O pagamento móvel não é um canal experimental a tratar num projeto à parte. É um meio de pagamento, tal como a transferência bancária, o cheque ou o numerário, e deve ser tratado no núcleo de gestão com o mesmo rigor: uma conta de tesouraria por carteira, um diário, documentos de suporte, uma reconciliação periódica. Enquanto o ERP não o vir, a empresa gere a sua tesouraria a partir de uma imagem parcial.

Os fluxos a integrar

Recebimentos de clientes. O cliente paga uma fatura, um adiantamento ou uma compra a pronto a partir do telemóvel. O ERP tem de receber a transação com a respetiva referência, associá-la à fatura ou ao cliente, regularizar a conta e registar as comissões. O ponto delicado é a identificação: um pagamento móvel chega com um número de telemóvel e um montante, raramente com um número de fatura. O projeto tem, portanto, de conceber a referência de pagamento, comunicá-la ao cliente e lê-la na receção. Sem isso, a regularização continuará a ser manual.

Pagamentos a fornecedores e a trabalhadores. No sentido inverso, a empresa paga a fornecedores, transportadores, trabalhadores eventuais ou colaboradores por pagamento móvel, muitas vezes em massa. O ERP tem de gerar a ordem de pagamento a partir das faturas validadas ou do processamento salarial, transmiti-la, receber a confirmação ou a rejeição e contabilizar tudo linha a linha. Aqui, a questão já não é a identificação mas o controlo: quem valida a lista, quem a transmite e como é tratada uma rejeição.

Reconciliação e contabilização SYSCOHADA

Uma carteira de pagamento móvel é uma conta de tesouraria. Acompanha-se e reconcilia-se como uma conta bancária. A reconciliação confronta o extrato do operador com os lançamentos do ERP, transação a transação, e isola as diferenças: pagamentos recebidos não identificados, pagamentos emitidos não confirmados, comissões, anulações. No SYSCOHADA revisto, estas operações têm o seu lugar nas contas de tesouraria e de gastos adequadas, com um documento por transação e não um lançamento global. O que muda com uma integração real: o extrato deixa de ser um ficheiro descarregado, passa a ser um fluxo recebido pelo sistema, e a reconciliação torna-se uma exceção a tratar em vez de uma tarefa semanal.

Esta disciplina tem uma consequência direta no fecho. Quando cada pagamento móvel é contabilizado à transação, regularizado e reconciliado, as contas transitórias esvaziam-se e a tesouraria do balanço reflete o dinheiro realmente disponível, carteiras incluídas. Falamos disso no nosso ponto de vista sobre o fecho SYSCOHADA: uma conta transitória que engorda todos os meses é um fluxo que o sistema não sabe tratar.

Uma carteira móvel é uma conta de tesouraria. Enquanto o ERP não a vir, a empresa gere o seu dinheiro a partir de uma imagem parcial.

Integrar por API, não por ficheiro

Os operadores de pagamento móvel disponibilizam interfaces que permitem iniciar um pagamento, receber a respetiva notificação e consultar um saldo ou um histórico. É sobre estas interfaces que se constrói uma integração duradoura, não sobre exportações descarregadas. A arquitetura depende do núcleo de gestão. Com o SAP S/4HANA, a integração passa pelo SAP BTP, que suporta os conectores, a transformação das mensagens e a supervisão, mantendo o núcleo livre de qualquer desenvolvimento específico. Quando a empresa tem também Salesforce, o MuleSoft desempenha esse papel de camada de integração comum entre o CRM, o ERP e os operadores. Com o Odoo, existem conectores para os principais operadores da sub-região; devem ser avaliados quanto à sua manutenção e à sua cobertura antes de serem escolhidos.

Seja qual for a plataforma, três regras. Uma camada de integração separada do núcleo, para absorver as alterações de interface dos operadores sem tocar no ERP. Uma supervisão dos fluxos, para ver um pagamento bloqueado antes de o cliente reclamar. E uma gestão dos casos de erro pensada desde o início: tempo de espera esgotado, rejeição, duplicado, reembolso.

Controlo interno e fraude

O pagamento móvel é rápido e irreversível. É a sua força comercial e o seu risco de controlo. Os esquemas de fraude que vemos são simples: um número de telemóvel de beneficiário alterado numa ficha de fornecedor, um pagamento de salário duplicado, um recebimento desviado para uma carteira pessoal, um reembolso fictício. Nenhum exige competência técnica. Todos exploram uma ausência de segregação de funções ou de rastreabilidade.

A integração no ERP é justamente o que permite responder-lhes. Os números dos beneficiários passam a ser dados de referência, com uma validação a quatro olhos em cada alteração. Os pagamentos em massa seguem um circuito de validação, com limites por pessoa e por dia. Cada transação regista o seu autor, a sua data e o seu documento. As carteiras são reconciliadas por alguém que não as manipula. E os alertas, montante invulgar, beneficiário novo, pagamento fora de horas, saem do sistema em vez de dependerem de uma vigilância individual. A nossa oferta de segurança e riscos de TI aborda estes controlos como parte do projeto de integração, não como uma auditoria a posteriori.

Dados pessoais

Um número de telemóvel associado a um pagamento é um dado de caráter pessoal. Os fluxos de pagamento móvel, de entrada como de saída, constituem um tratamento na aceção da lei n.º 2008-12, a declarar junto da CDP segundo as formalidades aplicáveis, com uma finalidade, um prazo de conservação e regras de acesso. Os registos de transações, úteis ao controlo, devem ser protegidos ao mesmo título que o processamento salarial. Desenvolvemos esta questão no nosso ponto de vista sobre a conformidade CDP desde o enquadramento.

O que recomendamos

• Tratar o pagamento móvel como um meio de pagamento do núcleo de gestão, com uma conta de tesouraria por carteira e um documento por transação.
• Conceber a referência de pagamento antes da integração: é ela que torna a regularização automática.
• Integrar por API, através de uma camada dedicada: SAP BTP, MuleSoft ou conectores Odoo, nunca em desenvolvimento direto no núcleo.
• Reconciliar todos os dias, por exceção, e não deixar nenhuma conta transitória viver para além do mês.
• Instituir a segregação de funções sobre os beneficiários, as validações e as reconciliações, com alertas suportados pelo sistema.
• Declarar o tratamento e proteger os dados de pagamento como dados sensíveis.

O pagamento móvel já está no seu volume de negócios. A única questão é saber se está também no seu sistema, ou se vive numa folha de cálculo, entre a tesouraria real e a tesouraria contabilística. É um projeto curto, no cruzamento da nossa competência em finanças e dos nossos trabalhos de integração e de API, e um daqueles cujo efeito se vê logo no fecho seguinte.