Que riscos fiscais mais aparecem num projeto de S/4HANA que ignorou o cronograma fiscal?

Discordo de listar multa como risco do projeto, a exceção é, né. A exceção é, né, quando a obrigação de fato fica sem entrega. Multa depende da obrigação e da legislação vigente, e isso não cito aqui, porque não tenho trecho do texto para apoiar. Do ponto de vista do projeto, o risco é a obrigação não sair; a multa é a consequência. Quem decide como tratar prazo e penalidade é o tributário da empresa, não o cronograma do projeto.

e aí, a ideia é, do lado de quem escreve código: a alternativa é antecipar o fiscal na ordem das ondas. Em vez de deixar o fiscal para o fim, levamos o levantamento das extensões próprias para o início do projeto. Cada extensão entra numa de três decisões: replica, reconfigura ou descontinua. O material que temos descreve esse desenho em fases, com janela própria do fiscal no cutover e passagem planejada para a sustentação. Custa um pouco no começo e evita surpresa no final.

Completando, e aí, o teste é: o teste que a diretoria deve exigir é o primeiro fechamento real, não o teste técnico. O material que temos lista os tipos de teste: técnico pela consultoria, integrado pelo cliente com apoio, regressão, contábil, homologação do cliente e primeiro fechamento em produção. Se o cronograma do projeto só prevê os dois primeiros, o fiscal vai descobrir o problema no fechamento. Peça o plano de teste por tipo e a data de cada um.

Os riscos que mais aparecem, na ordem em que doem:

1. Nota que não emite ou não contabiliza, porque o fiscal não foi parametrizado.
2. Apuração que sai diferente da contabilidade no primeiro fechamento.
3. Obrigação rejeitada, por dado mestre que não migrou.
4. Descoberta tardia de extensões próprias do ECC que não funcionam no novo ambiente.

agora, vale registrar. O material que temos resume isso: apuração, livros e contabilização dependem de parametrização, extensões Z e dado mestre que não migram sozinhos, e isso costuma ser descoberto tarde.