CRM de cobrança integrado ao SAP S/4HANA: o que sai do ERP, o que volta e o que dá errado

Um CRM de cobrança integrado ao SAP S/4HANA funciona assim: o SAP continua sendo o livro do contas a receber, e o CRM é onde a cobrança acontece. Todo dia, as partidas em aberto saem do SAP, por arquivo ou pela API do S/4HANA. No CRM, a régua, o discador, o WhatsApp, o negociador e a IA trabalham a carteira com a política do credor. A cada nova carga, a baixa e o status voltam, inclusive quando o SAP estorna um pagamento. No revo360, é assim que a Prime Energy, uma empresa do Grupo Shell, cobra a carteira que vem do SAP.

Este texto mostra o desenho, a escolha entre arquivo e API e as oito lições que a integração da Prime Energy deixou, para quem vai fazer a sua.

Por que não cobrar dentro do próprio SAP

O S/4HANA tem recursos de cobrança no financeiro: o programa de advertência (as cartas de cobrança) e o gerenciamento de cobranças, com lista de trabalho do analista, promessa de pagamento e disputa. Eles foram pensados para o contas a receber entre empresas, em que um analista acompanha algumas centenas de clientes.

Uma operação de cobrança em volume pede outra coisa: régua multicanal com WhatsApp, SMS e e-mail, discador, negociador com teto de desconto por fase e alçada, acordo parcelado com boleto, assessorias terceirizadas medidas na mesma régua, prestação de contas e, cada vez mais, agentes de IA. Construir isso dentro do ERP é projeto longo e de muita customização. O caminho que funciona é separar os papéis: o SAP registra, o CRM de cobrança cobra.

O desenho: três movimentos

1. Sai do SAP. As partidas em aberto do contas a receber: o parceiro de negócios (com CPF ou CNPJ), o documento, o vencimento, o valor, o saldo, a empresa ou filial e, quando houver, a linha digitável do boleto que o SAP já emitiu.
2. Roda no CRM. A carteira vira título e parcela, com o credor certo. A régua decide quem acionar, por qual canal e quando; o negociador trabalha a ficha no Omni Studio; a Sarah negocia no WhatsApp dentro da política; o acordo e o boleto saem da mesma base.
3. Volta a cada carga. O documento que o SAP fechou baixa a parcela no CRM, o cancelado vira devolução, e o estorno reabre o que tinha sido baixado. A cada carga, o CRM volta a bater com o financeiro.

Veja também Integrações e API e cobrança para energia e utilities.

Arquivo ou API

Os dois caminhos levam ao mesmo lugar, e começar por arquivo não impede passar para a API depois. O que decide a escolha é a urgência da baixa: se o cliente que pagou de manhã não pode ser cobrado à tarde, a API compensa.

Oito lições da integração da Prime Energy

A carga da Prime Energy roda todo dia. Antes dela houve uma foto completa da carteira; depois, um arquivo diário. Cada lição abaixo virou regra da carga, e todas valem para qualquer integração com SAP.

1. Um arquivo só, e o status do documento decide a ação. No começo eram três processos: carga, pagamentos e status. Viraram um arquivo só, em que a coluna “Status do Documento” manda: aberto mantém ou cria a parcela, fechado baixa, cancelado devolve. Menos arquivos, menos chance de um chegar e o outro não.

2. O status anda para trás. O mesmo documento pode estar fechado hoje e aberto amanhã, quando o SAP desfaz uma baixa ou um cancelamento. Toda ação da carga precisa ser reversível: se o pagamento foi estornado no SAP, a parcela volta a ser cobrada no CRM. Uma integração que só sabe ir para a frente cobra errado no dia seguinte ao estorno.

3. A mesma empresa chega com grafias diferentes. O SAP exportava a mesma filial como “EIRELI”, “LTDA”, “Ltda.” e “Ltda(Matriz)”. Sem uma tabela que traduza cada grafia para o credor certo, cada variante vira um credor novo, e a política, a prestação de contas e os painéis se partem. Filial fora da tabela é descartada com aviso, nunca criada às cegas.

4. O CPF ou CNPJ é a chave, e o Excel estraga a chave. Quando o arquivo passa pelo Excel, o CNPJ pode virar notação científica (8.47E+13), e há linhas com números de enchimento, como 999999999999. A carga só aceita a chave com os dígitos certos e rejeita a linha que não tem: um CNPJ errado junta a dívida de um cliente com a de outro.

5. Valor da nota não é saldo da nota. Com pagamento parcial, o saldo muda a cada carga e o valor original não. E, nas linhas de documento fechado, o valor da nota vem vazio. A carga atualiza o saldo sempre e só troca o valor da nota quando ele vem preenchido; sem essa regra, a baixa zeraria o valor de origem.

6. O layout muda sem aviso. Numa das entregas, uma coluna de datas virou duas e empurrou todas as seguintes uma posição para a frente. O layout ficou fixo e documentado, coluna por coluna, e a carga confere o arquivo antes de gravar.

7. O acento depende de quem exportou. O mesmo arquivo chega ora em UTF-8, ora em ANSI, conforme saiu do SAP ou passou pelo Excel. A carga tenta um e, se falhar, lê o outro. Sem isso, um dia o arquivo simplesmente não entra.

8. Status em texto livre pede uma tabela, não uma regra no código. O status de cobrança vem do SAP como texto livre e precisa casar com as ocorrências do CRM, que o cliente edita pela tela. Com uma tabela de correspondência, uma grafia nova é uma linha a mais; com a regra escrita no código, a carga para de casar sem dar erro.

O que o CRM acrescenta ao SAP

• A régua de cobrança por fase do credor, com canal, horário e teto de contatos. Veja régua de cobrança.
• Discador e WhatsApp na mesma ficha: o ekovox ou um dos 14 discadores integrados, e oito provedores de WhatsApp, inclusive a API oficial da Meta.
• Acordo e boleto com a política do credor. A linha digitável que o SAP já emitiu entra na carga e fica na ficha, à mão do negociador.
• Segmentação que vem do próprio SAP. Campos como projeto, varejo ou atacado entram na carga e viram critério da régua.
• Assessorias, jurídico e prestação de contas na mesma base, para quem terceiriza parte da carteira.
• IA dentro da política. A Sarah negocia, o jAcob prioriza a fila com aceite humano e a Simmone sugere a tabulação. Veja o futuro da cobrança com IA.

Checklist para a reunião com o time SAP

1. Chave: o que identifica uma parcela? (empresa, número e série do documento, parcela)
2. Frequência e corte: a que horas o arquivo sai, e o que entra nele?
3. Foto inicial: quem gera a primeira carga completa da carteira?
4. Status: quais valores o campo pode ter, e como aparece um estorno?
5. Empresas e filiais: qual é a lista oficial, e quem mantém a correspondência?
6. Contatos: telefones e e-mails vêm no mesmo arquivo ou em outro?
7. Boleto: o SAP emite a linha digitável, ou o CRM gera o boleto?
8. Conferência: quem confere, todo dia, que a soma do arquivo bate com a soma do CRM?

Perguntas frequentes

Existe CRM de cobrança integrado ao SAP S/4HANA?

Sim. O revo360 recebe o contas a receber do SAP por arquivo ou pela API do S/4HANA, cobra com régua, canais, negociador e IA, e recebe de volta a baixa e o status a cada carga. A Prime Energy, uma empresa do Grupo Shell, cobra assim a carteira que vem do SAP.

Preciso mexer no SAP?

Por arquivo, não: o SAP só precisa exportar o relatório do contas a receber todo dia, no layout combinado. Pela API, o time SAP libera o acesso e o usuário técnico. A cobrança roda no CRM, sem customização no núcleo do ERP.

A baixa feita no SAP aparece no CRM?

Sim, a cada carga. O documento fechado baixa a parcela, o cancelado vira devolução e o estorno reabre a parcela, para ninguém ser cobrado do que já pagou nem deixar de ser cobrado do que foi estornado.

Funciona com SAP ECC ou SAP Business One?

O desenho por arquivo vale para qualquer versão do SAP que exporte o contas a receber: o que muda é o layout, combinado na implantação.

Quanto tempo leva a integração?

O molde padrão de implantação do revo360 leva cerca de 36 dias úteis do kickoff à virada, para carteira que entra pela planilha padrão. A carga com o layout do SAP e a integração por API têm prazo próprio, dimensionado no levantamento. O diagnóstico operacional é o primeiro passo.