"É só um aplicativo web com alguns campos a mais"
Ouvimos alguma variação disso em quase toda primeira ligação sobre um sistema financeiro ou de compliance — uma rede de varejo que quer um livro contábil de verdade em vez de uma planilha, uma construtora que precisa de faturamento por etapas, uma clínica que precisa de sinistros e folha de pagamento em um só lugar, uma escola que precisa de contabilidade de verbas e mensalidades que resista a uma auditoria. O instinto é dimensionar o projeto como o último app CRUD: algumas tabelas, alguns formulários, um dashboard, pronto em algumas sprints.
Não é a mesma construção. Não porque a interface seja mais difícil — a maioria dos softwares financeiros tem telas mais simples e em menor número do que um app de consumo. É diferente porque cinco coisas são inegociáveis em software financeiro que são opcionais em qualquer outro lugar. Pule qualquer uma delas e o sistema não falha de forma barulhenta. Ele falha silenciosamente, meses depois, na frente de um auditor ou de um cliente muito insatisfeito.
1. Dinheiro não é um float
Um app comum pode arredondar um número na tela e seguir em frente. Um livro contábil não pode. Armazene valores monetários como ponto flutuante e pequenos erros de arredondamento se acumulam ao longo de milhares de transações até que o balanço não feche — e "o balanço não fecha" não é um chamado de bug, é uma emergência do negócio.
A correção é chata e obrigatória: centavos como inteiros ou um tipo decimal adequado, nunca floats de JavaScript, e todo cálculo — impostos, descontos, divisões, retenções contratuais — passa pela mesma regra de arredondamento em todo o código-base. Tratamos isso como uma regra de linting, não como um detalhe de code review.
2. Nada é excluído
Apps comuns fazem soft-delete ou hard-delete de registros o tempo todo. Sistemas financeiros não excluem — eles corrigem, e mantêm o original. Um livro contábil somente-de-inserção (append-only) significa que todo lançamento é imutável depois de contabilizado; um erro é revertido com um novo lançamento vinculado, não editado ou removido. É isso que deixa um sistema pronto para auditoria: um auditor consegue percorrer o histórico completo de qualquer valor, não apenas o estado atual.
Essa única decisão remodela todo o seu modelo de dados. As tabelas precisam de posted_at, reversed_by e created_by em cada linha financeira desde o primeiro dia — adaptar imutabilidade a um schema que foi construído para permitir edições é uma reconstrução, não uma migração.
3. Toda ação de alto risco precisa de um segundo par de olhos
O modelo de permissões de um app comum costuma ser "essa função pode ver essa página". Software financeiro precisa de permissão no nível da ação individual, e para tudo que envolva dinheiro real ou risco real — cancelar uma nota fiscal, aprovar uma transferência, reverter a negativa de um sinistro, dispensar uma multa por atraso — uma segunda pessoa precisa aprovar antes de a ação ser executada. Isso é maker-checker: uma pessoa propõe a ação, outra pessoa com a função certa confirma, e o sistema registra as duas.
Adaptar isso depois é doloroso porque não é só uma tabela de permissões — isso muda o formato da sua API. As ações passam a ter duas etapas (propose e depois approve) em vez de uma só, e esse padrão precisa ser projetado desde o início, não encaixado à força em um fluxo existente de "um clique para enviar".
4. Retentativas criam dinheiro duplicado se você deixar
Gateways de pagamento, arquivos bancários e câmaras de compensação de seguros fazem retentativas o tempo todo. Um app comum tenta novamente uma requisição que falhou e nada de ruim acontece. Um sistema financeiro que tenta novamente uma chamada de pagamento sem uma chave de idempotência pode cobrar um cliente duas vezes, lançar uma transação duas vezes, ou duplicar o pagamento a um subcontratado. Toda escrita externa precisa de uma chave de idempotência única, e todo job noturno precisa de uma etapa de reconciliação que confere o que realmente aconteceu contra o que o seu livro contábil acha que aconteceu, sinalizando a diferença em vez de presumir sucesso.
Essa é uma lacuna comum em sistemas que não foram construídos pensando em idempotência: a integração funciona bem em testes, e meses depois, já em produção, um acerto de contas com um fornecedor não reconcilia e ninguém sabe dizer por quê — porque nada sinalizou a retentativa que causou o problema.
5. Regras de retenção e disponibilidade não são suas para definir
Um app comum pode escolher sua própria política de backup. Software financeiro e de compliance herda regras de fora: cerca de sete anos de retenção de registros contábeis exigidos pela maioria das autoridades fiscais, a própria regra da HIPAA de seis anos de retenção para documentação de compliance como políticas e autorizações (a retenção real de prontuários médicos é definida pela legislação estadual, que varia e não é sobreposta pela HIPAA), e as regras de escopo do PCI DSS no momento em que dados de cartão tocam o seu sistema, mesmo em trânsito. Ignore isso e o custo não é uma correção de bug — é um apontamento na auditoria do ano seguinte, ou uma multa.
As expectativas de disponibilidade também mudam. Um site institucional fora do ar por uma hora é constrangedor. A folha de pagamento não rodar no dia certo, ou o sistema de faturamento de um hospital ficar inacessível durante a admissão de pacientes, é uma categoria de problema completamente diferente — e isso muda o que você precisa orçar para monitoramento, failover e cobertura de plantão.
Como isso se manifesta em cada setor
Varejo — o ponto de dor costuma ser a reconciliação: vendas do PDV, acertos da processadora de cartões e pagamentos a fornecedores precisam bater entre dezenas de unidades, todos os dias, automaticamente.
Construção civil — faturamento por etapas no estilo AIA e controle de retenção significam que a "nota fiscal" só é definitiva depois que um marco do projeto é verificado; o livro contábil precisa modelar pagamento parcial e condicional, não apenas pago/não pago. Construímos exatamente isso para uma construtora de empreendimentos multifamiliares e comerciais — veja o estudo de caso.
Saúde — fluxos de sinistros, análise de cobertura pelo convênio e folha de pagamento clínica envolvem informações de saúde protegidas, então o tratamento com consciência da HIPAA (registro de acessos, acesso mínimo necessário, criptografia em repouso) é uma restrição de design, não um item marcado no fim do projeto.
Instituições — livros de verbas, restrições de doadores e orçamentos departamentais precisam de contabilidade por fundo: dinheiro marcado para um propósito não pode silenciosamente cobrir outro, e cada valor precisa de um rastro reportável até sua origem.
O que isso realmente custa
Nada disso é engenharia exótica — são padrões disciplinados e bem compreendidos aplicados de forma consistente. Mas isso significa que um módulo financeiro leva mais tempo do que uma funcionalidade CRUD comparável e custa mais por tela. Na nossa experiência, um módulo único e focado — custeio de obra, entrada de sinistros, um dashboard de reconciliação — leva de 10 a 16 semanas. Uma suíte financeira multimódulo que toca em vários dos pontos acima ao mesmo tempo costuma levar de 5 a 9 meses, com uma primeira fatia utilizável no ar dentro das primeiras 12 semanas.
Se um fornecedor cotar software financeiro ou de compliance pelo mesmo valor do seu site institucional, pergunte diretamente como eles lidam com trilhas de auditoria imutáveis, aprovação dupla e reconciliação. Se a resposta for vaga, o número é que está errado — não o esforço que você esperava pagar.
Resumo
Software financeiro não é mais difícil porque as telas são complicadas. É mais difícil porque as restrições são externas — regras contábeis, HIPAA, PCI, seus próprios auditores — e nenhuma delas perdoa atalhos tomados para bater um prazo. Construa a disciplina do livro contábil desde o primeiro schema, não depois da primeira auditoria. Nosso time de software financeiro e corporativo dimensiona exatamente esse tipo de projeto — varejo, construção civil, saúde e instituições — e consegue dizer em uma semana quais dos padrões acima o seu sistema específico realmente precisa.
