Split Payment e arquitetura financeira: roteiro de testes e homologação no ERP

Introdução

A Reforma Tributária do Consumo mudou a natureza do projeto fiscal: não basta trocar fórmulas; é preciso conectar regra, processo, dado, documento, contabilização e evidência. Este artigo analisa Split Payment e arquitetura financeira pelo ângulo de plano de testes. O foco é mostrar o que precisa ser conferido por tesouraria, arquitetura, fiscal e TI, quais riscos merecem controle e como levar o requisito para o ERP sem inventar regra legal ou funcionalidade de software.

Até a data desta pesquisa, 31/08/2026, a empresa precisa acompanhar legislação, atos conjuntos, notas técnicas e documentação do fornecedor de ERP como fontes distintas. Uma obrigação legal não prova que determinada rotina já existe no Protheus; da mesma forma, uma função documentada pelo fornecedor não substitui a validação da regra tributária aplicável à empresa.

O que está confirmado nas fontes oficiais

Conforme a legislação e as orientações oficiais consultadas até 31/08/2026, a Reforma Tributária do Consumo está em implementação progressiva. A LC 214/2025 instituiu IBS, CBS e Imposto Seletivo, e a LC 227/2026 complementou a estrutura do IBS e do CGIBS. As obrigações e cronogramas precisam ser lidos pela data de vigência, porque 2026 é um período de adaptação com atos e documentação técnica sendo atualizados.

No Split Payment, o CGIBS disponibiliza página técnica com Manual de Integração e OpenAPI. O fato de existir documentação técnica não autoriza presumir regras de produção além do que foi publicado; por isso, contratos de integração, versões e ambientes devem ser tratados explicitamente.

Por que split payment e arquitetura financeira merece atenção

O objetivo operacional é preparar integração e conciliação a partir de especificações oficiais, sem antecipar comportamento não publicado. O processo envolve tesouraria, arquitetura, fiscal e TI e pode produzir efeitos em documentos, cadastros, integrações, títulos, estoque, custos ou contabilidade. O risco prioritário é construir processo definitivo sobre minuta ou suposição.

Uma forma útil de analisar o tema é seguir a cadeia regra tributária → evento de negócio → dado de origem → cálculo/classificação → documento ou obrigação → financeiro → contabilidade → evidência. Nem todos os processos percorrem todas as etapas, mas a empresa deve saber exatamente quais etapas existem no seu cenário.

Plano de testes para Split Payment e arquitetura financeira

A homologação deve provar o processo, não apenas a tela. Comece com uma massa de dados conhecida e execute, no mínimo:

1. Fluxo padrão: reprocessamento após falha técnica para verificar duplicidade.
2. Vigência: operação com alto volume para avaliar desempenho e filas.
3. Variação comercial: alteração de tabela oficial ou versão técnica seguida de regressão.
4. Ajuste ou reversão: operação em data próxima à troca de vigência.
5. Falha controlada: devolução ou ajuste vinculado ao documento de origem.

Depois amplie para documento com desconto, acréscimo ou condição diferente do padrão e cadastro incompleto ou divergente para validar bloqueios e mensagens. Em cada caso, compare entrada, cálculo, documento, escrituração, financeiro e contabilidade quando esses componentes fizerem parte do fluxo.

Critério de aceite

O teste só deve ser considerado aprovado quando o resultado puder ser reproduzido e explicado. Isso inclui registrar a versão da documentação usada, ambiente, data, massa de teste e responsável pelo aceite.

Protheus e regressão

o CGIBS publica Manual de Integração e OpenAPI; ERP deve ser integrado de forma versionada. Antes de atualizar componente fiscal, mantenha uma suíte de regressão com operações de maior valor, maior volume e maior risco de rejeição.

Perguntas que a equipe deve responder

1. Qual fonte oficial sustenta a regra atual e qual é sua vigência?
2. Quem aprova a interpretação tributária aplicada a split payment e arquitetura financeira?
3. Qual sistema é a fonte dos dados que determinam o tratamento?
4. O resultado consegue ser reproduzido em homologação com a mesma versão da regra?
5. Como devoluções, cancelamentos, ajustes e falhas de integração são tratados?
6. Existe conciliação entre documento, financeiro e contabilidade quando aplicável?
7. Quais customizações podem interferir no cálculo ou no documento?
8. O que precisa ser retestado quando houver nova nota técnica ou atualização do Protheus?

Riscos e pontos de atenção

Não use flexibilização temporária de validações como justificativa para adiar a preparação. Não replique parâmetros de outra empresa sem confirmar enquadramento. Não publique em produção uma regra cuja base legal ou tabela oficial não esteja registrada. E, principalmente, não atribua ao Protheus campo, rotina, patch ou comportamento que não esteja comprovado na documentação oficial da versão utilizada.

Conclusão

A transição será longa e continuará recebendo atos, notas técnicas e versões de software. Por isso, a melhor arquitetura é aquela que aceita mudança sem perder histórico, governança e capacidade de teste. Para Split Payment e arquitetura financeira, a recomendação é manter o desenho simples: fonte oficial, requisito escrito, configuração identificável, teste reproduzível, conciliação e monitoramento. Assim, a Reforma Tributária deixa de ser uma sequência de correções emergenciais e passa a ser um programa controlado de mudança fiscal e tecnológica.

Aviso: este artigo tem caráter informativo. A aplicação concreta deve ser confirmada com a área tributária, contábil ou assessoria especializada e com a documentação oficial da TOTVS correspondente ao ambiente do cliente.