Em TI PJ, você não perde dinheiro porque “não emitiu nota”. Você perde porque emitiu mal descrita, sem evidência, e o cliente glosou ou travou pagamento.
📌 Em resumo
-
Padronize modelo de cobrança (sprint, hora, projeto).
-
Descrição clara reduz glosa e discussão comercial.
-
Evidência de entrega + competência bem definida = pagamento previsível.
Cliente fora do DF, serviço remoto, contrato por sprint… isso não é problema.
Problema é quando você emite uma NFS-e que o cliente não consegue validar internamente. Aí começa a novela: “ajusta a descrição”, “manda relatório”, “refaz a nota”.
✅ Checklist antes de emitir (TI PJ)
-
Escopo fechado (contrato/OS/ordem interna)
-
Evidência de entrega (aceite, e-mail, relatório, backlog)
-
Modelo de cobrança definido (sprint/hora/projeto)
-
Competência e período explícitos na nota
-
Cadastro do tomador revisado (dados corretos)
-
Arquivo do mês organizado (nota + evidências + comprovantes)
📎 3 modelos de descrição prontos (TI PJ)
-
Sprint: “Desenvolvimento de software — sprint X — entregas conforme backlog aprovado — competência MM/AAAA.”
-
Projeto: “Implementação de [módulo] — etapa Y — conforme contrato/OS nº ____ — período //__ a //__.”
-
Hora técnica: “Serviços técnicos de TI — alocação de horas — relatório de horas referente ao período //__ a //__.”
⚠️ Erros comuns que geram glosa
-
“Serviços de TI” (genérico demais)
-
sem período/competência
-
sem evidência anexável
-
divergência entre proposta/contrato e descrição da nota
Perguntas rápidas
Vale a pena emitir por sprint?
Sim, se você tem evidência de entrega e aceite por sprint.
O que cliente mais questiona?
Descrição + período + comprovação de entrega.
Como a Carmelitas ajuda
A Carmelitas padroniza seu faturamento de TI PJ (modelos de descrição, dossiê por cliente e rotina de conferência) para você emitir e receber sem ruído.
