Construir a própria automação
ou contratar
Escrever um agente que lê a nota e lança no ERP é a parte fácil — um time competente faz isso em semanas, e em 2026 faz com ajuda de IA. Esta página é o inventário do que vem depois: os casos em que a nota não é simples. Cada um deles é trabalho que alguém vai ter que fazer, por dentro ou por fora.
O caso simples é mesmo simples
Nota com o número do pedido, item que bate com o cadastro, unidade igual à comprada, preço dentro do combinado, material entregue. Para esse documento, um agente resolve: lê o XML, acha o pedido, confere, lança. Não é aí que o projeto trava.
Ele trava porque essa nota é a minoria, e porque o que decide o resultado não é o acerto nos documentos fáceis — é o que o sistema faz com os difíceis.
O inventário
Os casos abaixo não são hipóteses. São situações que aparecem na entrada de nota de obra, todas com tratamento próprio rodando em produção:
O fornecedor não é obrigado a informar o número do pedido de compra. Sem ele, não há contra o que conferir — e a amarração precisa ser descoberta a partir de fornecedor, item, valor e data.
Ele fatura em saco, você comprou em quilo. Nenhuma norma o obriga a usar a sua unidade. Sem o fator de conversão por insumo, a quantidade certa vira número errado — e quantidade é base de cálculo.
O que está no seu cadastro e o que vem descrito na nota raramente coincidem como texto. E há o caso do kit: você compra um conjunto, a nota vem desmembrada em peças.
Tem contrato e medição. O lastro é outro, a lógica de saldo é outra, e a conferência não pode ser a mesma que a de material.
O que é devido depende da classificação tributária do prestador, do tipo de serviço e do município da prestação. E o recolhimento é obrigação de quem contratou, não de quem emitiu.
A LC 214/2025 identifica os bens pela classificação NCM nos próprios anexos. Item classificado errado entra na regra errada — e o resultado não aparece como erro, aparece como número plausível.
Nem toda diferença é erro: existe tolerância, e ela varia por insumo e por contrato. Decidir o que passa e o que retém é regra de negócio, não comparação.
É a única etapa que nenhum sistema substitui: alguém no canteiro confirma que o material chegou. O desafio é fazer isso caber no dia de quem está recebendo caminhão.
A parte que quase todo projeto subestima
Some os oito e ainda falta o principal: o que acontece com o que não passou.
Um motor de validação é fácil de medir pelo que ele aprova. O que define se o processo funciona é o outro lado — a nota retida precisa de motivo escrito, dono, prazo e um caminho de volta. Se a divergência vira e-mail, ela se perde e a nota fica parada. Se vira exceção registrada, alguém termina aquilo.
Esse é o trecho que não aparece no protótipo, que não se resolve com modelo melhor, e que consome a maior parte do tempo de quem constrói — porque ele não é um problema de leitura de documento. É um problema de processo.
E a integração com o ERP
Ler a nota é um problema resolvido. Escrever no ERP é outro. O lançamento precisa nascer com o pedido amarrado, os impostos apropriados, o tipo de pagamento certo por parcela e o rateio pela obra — e precisa ser idempotente, porque reprocessar não pode duplicar título.
O NF Check-in roda em produção sobre Sienge e MXM; para os demais ERPs a camada é agnóstica e se integra ao que a construtora já usa. Dos clientes que operam o NF Check-in hoje, onze estão em Sienge — e é esse volume de casos reais, não o desenho inicial, que produziu o tratamento de cada situação da lista acima.
O que isso quer dizer na prática
Nada aqui é impossível de construir. A pergunta honesta não é "dá para fazer" — dá. É: esses oito casos, mais o tratamento de exceção, mais a escrita no ERP, são onde o seu time deve passar os próximos trimestres? Para uma construtora, isso raramente é o produto. Para a OnSAC, é o produto.
Construir ou contratar
Dá, e a primeira versão sai rápido: ler o XML, localizar o pedido, comparar e lançar é trabalho de semanas para um time competente. A dificuldade não está nessa versão — está nos documentos que não seguem o caso simples, e no que o sistema faz com eles. É aí que o prazo do projeto deixa de ser previsível.
Ela ajuda muito na leitura e na correspondência — reconhecer que um item descrito de um jeito na nota é o mesmo que está cadastrado de outro, por exemplo, é exatamente o tipo de problema em que ela ajuda. O que ela não substitui é a regra de negócio: qual tolerância de preço vale para qual insumo, o que retém e o que passa, quem decide a exceção. Isso não é um problema de modelo, é uma decisão da empresa que precisa estar escrita em algum lugar.
Depende do que se chama de integrar. Ler dados e gravar um lançamento é a parte curta. O que leva tempo é fazer o título nascer correto — com o pedido amarrado, os impostos apropriados, o tipo de pagamento por parcela e o rateio da obra — e garantir que reprocessar um documento não gere título duplicado.
O agente executa uma tarefa: lê o documento e propõe o lançamento. A camada de validação é o processo inteiro em volta disso — de onde a nota é capturada, contra o que ela é conferida, o que acontece com o que não fecha, quem é avisado, o que fica retido e com qual motivo. O agente é um componente dentro da camada, não o substituto dela.
A conta que costuma faltar não é a do desenvolvimento inicial, é a da manutenção: regra fiscal muda, ERP atualiza, aparece um caso que não estava previsto. Um sistema de entrada de nota não é um projeto que termina — é um software que precisa de dono enquanto a operação existir.