No setor da construção civil, o lançamento de notas fiscais é um processo crítico, de alto volume e baixa tolerância ao erro. Um único campo preenchido errado pode resultar em rejeição pela SEFAZ, pagamento indevido ou autuação fiscal. O problema é que esses erros são normalizados — as equipes aprendem a conviver com o retrabalho em vez de eliminá-lo.

A OnSAC desenvolveu o NF Check-in especificamente para a construção civil, automatizando a validação e o lançamento de notas com integração direta ao ERP. A seguir, os 8 erros mais comuns que o sistema elimina.

1. Dados cadastrais incorretos do fornecedor

CNPJ com dígito errado, razão social desatualizada, inscrição estadual incorreta — qualquer uma dessas informações leva à rejeição imediata da nota fiscal pela SEFAZ. O impacto vai além do retrabalho: o pagamento trava, o fornecedor pressiona, e a obra pode parar por falta de material liberado.

O custo real: em obras com múltiplos fornecedores ativos, uma taxa de rejeição de 3% representa dezenas de notas retrabalhadas todo mês. O NF Check-in valida os dados automaticamente contra a base da SEFAZ antes de qualquer lançamento.

2. Tipo errado de nota (NF-e vs. NFS-e)

Notas de produto (NF-e) e de serviço (NFS-e) têm regimes tributários, obrigações fiscais e tratamentos contábeis completamente diferentes. Usar o tipo errado gera bitributação, retenções indevidas e inconsistências no SPED que podem acionar fiscalização.

O sistema identifica automaticamente o tipo de nota com base na natureza da operação, eliminando o erro de classificação na origem.

3. Confusão entre data de emissão e competência fiscal

É um dos erros mais silenciosos: a nota é lançada com a data errada. O DRE fica distorcido, as provisões não refletem a realidade e as auditorias encontram divergências que ninguém consegue explicar. Em obras com apuração mensal rigorosa, esse erro invalida o relatório inteiro.

4. Classificação fiscal incorreta (CFOP, NCM, CST)

CFOP errado impacta o aproveitamento de créditos de ICMS. NCM incorreto gera diferença de alíquota e risco de autuação. CST errado compromete o cálculo de PIS e COFINS. Esses três campos são frequentemente preenchidos manualmente, com base em memorização ou planilhas desatualizadas.

O NF Check-in usa IA para validar automaticamente as classificações com base nas regras tributárias atualizadas, sem depender do conhecimento individual de cada operador.

5. Cálculo incorreto de impostos retidos

ISS, INSS sobre serviços, IRPJ retido na fonte — cada um com alíquotas, bases de cálculo e obrigações específicas. Um erro de cálculo pode gerar tanto pagamento a maior quanto sonegação não intencional. Em contratos de serviço de longa duração, o acúmulo desse erro representa valores significativos.

6. XML da nota não armazenado

Este é o erro que aparece no pior momento possível: durante uma fiscalização. O PDF da nota fiscal não tem valor jurídico. O único documento reconhecido pelo Fisco é o arquivo XML. Sem ele, a empresa não consegue comprovar a operação e está sujeita a autuação e multa.

O sistema armazena automaticamente todos os XMLs com backup em nuvem, indexados por obra, fornecedor e período — acessíveis a qualquer momento.

7. Certificado digital vencido ou mal configurado

A captura automática de notas fiscais da SEFAZ depende de um certificado digital válido e corretamente configurado. Um certificado vencido trava o processo inteiro — as notas param de ser capturadas sem que ninguém perceba, e o atraso só é descoberto quando o pagamento já deveria ter saído.

8. Processo manual sem rastreabilidade

O erro mais caro não é o de digitação — é a ausência de histórico. Quando algo dá errado (e eventualmente dará), quem tomou a decisão? Quando foi lançado? Qual versão da nota foi usada? Sem rastreabilidade, a resposta para cada uma dessas perguntas demanda horas de investigação.

Em uma obra com 30 notas por dia, são 660 notas por mês, 7.920 por ano. Com 5% de taxa de erro, são quase 400 lançamentos problemáticos por ano — cada um com custo de tempo, retrabalho e risco fiscal.

Existe uma crença difundida no setor da construção civil de que a validação de notas fiscais é um processo de suporte — algo que o financeiro ou o fiscal resolve. O ERP recebe a nota, o contador assina, e a vida segue.

Essa crença é cara. E mensurável.

Construtoras que tratam o recebimento fiscal como processo estratégico têm algo em comum: controlam com precisão o que pagam versus o que recebem. As que tratam como operacional descobrem o descasamento nas auditorias — quando já é tarde.

O que está em jogo em cada nota fiscal que entra sem validação

Cada nota fiscal que entra no ERP sem validação é um vetor de risco em quatro dimensões:

1. Risco financeiro direto

Preço faturado acima do negociado. Quantidade maior do que entregue. Unidade diferente que passa despercebida na conversão manual. Cada uma dessas situações representa dinheiro que sai da conta da construtora sem correspondência na entrega real.

2. Risco fiscal

Classificação CFOP incorreta, NCM errado, alíquota tributária divergente. Em obras de grande porte com centenas de fornecedores, a probabilidade estatística de ter inconsistências que interessam ao Fisco é alta. A Reforma Tributária (IBS/CBS) adicionou novas camadas de complexidade que o processo manual não acompanha.

3. Risco operacional

Notas lançadas erradas geram estorno. Estorno gera novo lançamento. Novo lançamento consome tempo de equipe que deveria estar em atividades analíticas. Esse ciclo de retrabalho é o principal inimigo da produtividade financeira na construção civil.

4. Risco de rastreabilidade

Quando algo dá errado em uma auditoria interna ou externa, quanto tempo sua equipe gasta reconstruindo o histórico de uma nota? Sem rastreabilidade automática, cada investigação é artesanal — e cada resposta "não sei" é um problema de governança.

Por que o ERP sozinho não resolve

O ERP foi projetado para registrar e processar informações. Ele faz isso muito bem. O que ele não faz é questionar a qualidade do dado que recebe. Se entrar errado, fica errado — com toda a credibilidade de um sistema de gestão.

A OnSAC atua como a camada de governança entre os fornecedores e o ERP. Nenhuma nota entra no sistema de gestão sem antes ser validada, auditada e confirmada. O que o ERP recebe já é verdade.

O que muda quando a validação é automatizada

Com o NF Check-in, a equipe financeira para de ser reativamente operacional e começa a ser proativamente estratégica:

• Antes: a equipe descobre problemas depois que o pagamento saiu, e trabalha para corrigir
• Depois: problemas são sinalizados antes do pagamento, e a equipe decide como tratar

Essa inversão — de reativo para proativo — é o que diferencia operações financeiras bem governadas das que vivem apagando incêndio.

Em teoria, o processo de recebimento de notas fiscais é simples: a nota chega, é conferida, é lançada no ERP e o título de pagamento é gerado. Na prática, cada uma dessas etapas envolve pessoas, decisões, digitação manual e muitas oportunidades de erro.

O NF Check-in da OnSAC foi desenhado para que o processo de fato funcione como deveria — automaticamente, rastreado e sem depender de ninguém para executar as tarefas rotineiras. O time humano aparece apenas nos três pontos em que julgamento humano é necessário.

Por que digitalizar não é o mesmo que automatizar

Muitas construtoras acreditam que "já são digitais" porque usam o ERP e recebem XMLs. Mas receber o XML por e-mail e lançá-lo manualmente no sistema não é automação — é digitação de outro formato. A diferença está em quem executa cada etapa:

• Digitalização: os dados existem em formato digital, mas alguém ainda precisa movê-los, conferí-los e lançá-los
• Automação: o sistema executa cada etapa com base em regras, sem intervenção humana

As 10 etapas do NF Check-in

Etapa 1 — Captura Automática via SEFAZ

Antes mesmo de o caminhão sair do fornecedor, o NF Check-in já capturou a nota fiscal. O sistema se conecta ao SEFAZ e à Base Nacional usando o certificado digital da obra, baixando automaticamente cada NF-e e NFS-e emitida contra o CNPJ da empresa. Zero e-mail. Zero portal de prefeitura. Zero solicitação ao fornecedor.

Etapa 2 — Pedido Reverso Inteligente

Em uma fração significativa das notas, o fornecedor não informa o número do pedido de compra. No processo tradicional, isso paralisa o lançamento até que alguém localize o pedido manualmente. No NF Check-in, a IA busca automaticamente o pedido correspondente no ERP usando os dados disponíveis: CNPJ do fornecedor, itens, valores, obra e data. O processo segue sem interrupção.

Etapa 3 — Enriquecimento de Dados

Com a nota capturada e o pedido localizado, o sistema cruza as informações dos dois documentos e monta um registro completo: obra, centro de custo, fornecedor, itens, valores, impostos. Tudo centralizado em um único lugar, pronto para a validação.

Etapa 4 — Validação com IA

A IA compara a nota fiscal com o pedido de compra campo a campo: preço unitário, quantidade, unidade de medida, CNPJ do fornecedor, obra. Cada divergência é identificada, classificada por tipo e severidade, e encaminhada para o responsável. Nada que não esteja em conformidade segue para a próxima etapa.

Etapa 5 — Separação de Arquivos

Nem todo documento que chega é uma nota de compra. Remessas, devoluções, notas complementares — o sistema identifica automaticamente o tipo de cada documento e o distribui na aba correta. Fim das notas de remessa entrando no fluxo de pagamento por engano.

Etapa 6 — Confirmação do Almoxarife

Este é o primeiro ponto de interação humana — e intencionalmente o único no canteiro. O almoxarife acessa o portal (que funciona offline) e confirma o recebimento físico: o que chegou, em qual quantidade e em qual condição. Essa confirmação é a âncora do Three-Way Match.

Etapa 7 — Avaliação do Fornecedor

No mesmo momento da confirmação, o almoxarife avalia o fornecedor: prazo de entrega, qualidade do material, conformidade com o pedido. Esse histórico alimenta o IQF (Índice de Qualidade do Fornecedor) e apoia decisões futuras de compra — sem planilhas paralelas.

Etapa 8 — Anexo de Documentos

Antes de gerar o título, o sistema exige a anexação dos documentos obrigatórios: boleto, comprovante de entrega, laudos técnicos, contratos. Cada documento é vinculado à nota e ao título, acessível de qualquer lugar a qualquer momento.

Etapa 9 — Tipo e Condição de Pagamento

O financeiro define o tipo de pagamento de cada parcela: à vista, parcelado, boleto, transferência. Essa definição acontece antes da geração do título, garantindo que o contas a pagar receba a informação correta desde o início — sem corrigir lançamentos depois.

Etapa 10 — Geração Automática do Título no ERP

Com as nove etapas anteriores concluídas, o NF Check-in gera o título automaticamente no ERP — Sienge, Mega, Senior, SAP Business One, TOTVS ou MXM. Com todos os dados corretos, todos os documentos anexados e todas as validações realizadas. O financeiro não lança: recebe.

Resultado no Grupo OAD: 98% automático

"O processo que antes consumia horas da nossa equipe passou a rodar em segundo plano. O time parou de lançar e começou a analisar." — Grupo OAD, Florianópolis · SC

Após 3 anos com o NF Check-in, o Grupo OAD atingiu 98% de lançamentos processados automaticamente. Os 2% restantes são as exceções que requerem julgamento — e é exatamente para isso que existe o time financeiro.

O Sienge é, para a grande maioria das construtoras brasileiras, o sistema central de gestão. Suprimentos, financeiro, engenharia e obras convergem nele. Mas existe uma lacuna que o Sienge — por design — não fecha: a qualidade do dado que entra no portão da obra.

O Sienge registra o que chega. Não questiona. Não valida. Não confere se o que foi faturado é o que foi entregue. Essa função de governança foi deixada para pessoas — e pessoas cometem erros, principalmente sob pressão, volume e urgência.

O que acontece sem a OnSAC no Sienge

Sem uma camada de validação antes do Sienge, o ciclo de erros se repete:

• Nota fiscal chega — por e-mail, WhatsApp ou portal — sem conferência
• Almoxarife lança com unidade diferente, preço aproximado ou pedido errado
• O Sienge registra o erro como verdade
• O financeiro gera o título com base no registro incorreto
• O pagamento sai — e o problema só aparece na próxima auditoria

O que muda com a OnSAC integrada ao Sienge

Captura automática das notas

O NF Check-in captura automaticamente todas as notas emitidas contra os CNPJs da empresa, direto do SEFAZ e da Base Nacional. O time de suprimentos e o almoxarife param de receber XMLs por e-mail e de buscar notas em portais de prefeitura.

Validação antes do lançamento

Cada nota é confrontada com o pedido de compra no Sienge: preço, quantidade, unidade, fornecedor, obra e centro de custo. Se tudo bate, o processo segue automaticamente. Se há divergência, o sistema bloqueia, notifica o responsável e registra o ocorrido para auditoria.

Conversão automática de unidades

O pedido foi em m³, a nota chegou em toneladas. O pedido foi em sacos, a nota em pallets. A OnSAC converte automaticamente, garantindo que a comparação seja feita em bases equivalentes — sem que o almoxarife precise fazer esse cálculo de cabeça.

Three-Way Match com recebimento físico

O Sienge sabe o que foi pedido e o que foi faturado. A OnSAC adiciona o terceiro elemento: o que foi efetivamente recebido na obra. Essa conferência tripla — Pedido × Nota × Recebimento — é o que garante que o título de pagamento gerado no Sienge corresponde a uma entrega real e completa.

Integração com procurement

Para construtoras que usam o Mercado Eletrônico, a OnSAC fecha o ciclo completo: o pedido aprovado no portal é transferido automaticamente para o Sienge (via Integrador de Compras), e o recebimento da nota correspondente é validado pelo NF Check-in. A LBX Construtora opera exatamente assim — do procurement ao pagamento, sem reentrada de dados.

Resultados consistentes com Sienge + OnSAC

As construtoras que operam com Sienge + OnSAC relatam três mudanças consistentes: redução expressiva do tempo de processamento por nota, eliminação dos estornos por lançamento incorreto e rastreabilidade completa de cada documento desde a emissão até o pagamento.

O Sienge registra o passado com precisão. A OnSAC garante que o presente seja governado. Juntos, entregam o controle que você comprou quando contratou o ERP.

As linhas Protheus e RM da TOTVS sustentam operações complexas no setor da construção e da infraestrutura. São sistemas com profundidade funcional, módulos robustos de suprimentos, financeiro e fiscal — e uma limitação estrutural que todo gestor experiente conhece bem: o sistema confia no que recebe.

Se o dado que entra estiver errado, o TOTVS processa o erro com toda a eficiência que lhe é característica. A nota com NCM incorreto é registrada. O pedido com unidade divergente é lançado. O título com valor equivocado é gerado. Tudo registrado, tudo auditável — e tudo errado.

Onde o erro começa: o portão da obra

Para usuários de TOTVS na construção civil, o maior risco não está na configuração do sistema — está no canteiro. O almoxarife recebe materiais, confere visualmente e lança no sistema. Em um dia com 30 entregas, nenhum ser humano consegue manter precisão absoluta em cada conversão de unidade, cada verificação de preço, cada conferência de pedido.

Com 10 obras ativas, isso significa 6.600 oportunidades mensais para o erro contaminar o custo médio, o estoque e o fluxo de caixa no TOTVS.

O que a OnSAC faz antes do dado chegar ao TOTVS

Antecipação de divergências fiscais

A OnSAC captura a nota fiscal no momento da emissão pelo fornecedor — antes do caminhão sair. Se o NCM estiver errado, se a alíquota de retenção não bater com o contrato, se o preço for diferente do pedido: a divergência é identificada e comunicada ao responsável antes que o material chegue à obra. Fim dos estornos urgentes no Protheus por nota errada que já foi entregue.

Conversão automática de unidades

Pedido em m³, nota em toneladas. Pedido em unidades, nota em caixas. Cada construtora tem sua tabela de equivalência — e cada almoxarife tem a sua versão dessa tabela na cabeça. A OnSAC aplica a tabela correta automaticamente, garantindo que o dado que chega ao módulo de suprimentos do TOTVS seja sempre equivalente ao que foi pedido.

Three-Way Match automático

O TOTVS sabe o que foi pedido. A SEFAZ sabe o que foi faturado. A OnSAC garante que o que foi fisicamente entregue no canteiro está sendo confirmado e registrado antes do título ser gerado. Se qualquer um dos três não bater, o processo para — e o responsável é notificado com o detalhe da divergência.

Governança de Notas de Serviço pós-Reforma Tributária

Com o IBS e a CBS em fase de implementação, as notas de serviço passaram a exigir controles que o processo manual do TOTVS não consegue sustentar. A OnSAC retém a NFS-e até que a Medição de Obra correspondente seja aprovada pela engenharia. Só então o título é gerado no RM ou no Protheus — com compliance garantido e créditos fiscais aproveitados corretamente.

O que não muda: o TOTVS continua sendo o centro

A OnSAC não substitui o TOTVS. Não concorre com nenhum módulo do Protheus ou do RM. Ela opera como a camada de entrada — garantindo que o ERP receba dados que já passaram por validação, auditoria e conferência física. A implantação não exige migração de dados nem alteração no TOTVS.

O TOTVS é o motor que move sua construtora. A OnSAC é o filtro que garante que esse motor nunca seja alimentado com combustível contaminado.

O ERP Mega Senior, da Senior Sistemas, é uma escolha consistente entre construtoras que precisam de profundidade funcional: módulos integrados de engenharia, suprimentos, financeiro e contabilidade. Mas toda a capacidade analítica do Mega depende de uma premissa que raramente é questionada: os dados que entram precisam ser corretos.

Na prática, essa premissa é violada todos os dias — no portão da obra, no momento em que o almoxarife recebe um caminhão, confere visualmente e lança no sistema. Com pressão, volume e complexidade, erros acontecem. E o Mega registra cada um deles como verdade.

O problema que o Mega não resolve sozinho

Notas de serviço de todo o Brasil

Para construtoras com obras em múltiplos municípios, a captura de notas fiscais de serviço é um desafio logístico. Cada prefeitura tem seu sistema de NFS-e. Dependendo do fornecedor enviar a nota por e-mail é impreciso. Acessar portais de prefeitura manualmente é inviável em escala.

A OnSAC resolve isso na origem: conecta à base nacional de NFS-e e captura automaticamente todas as notas de serviço emitidas contra os CNPJs da construtora, em qualquer município do Brasil, no momento da emissão.

Correspondência de itens com descrições diferentes

O fornecedor descreve o material de um jeito. O pedido no Mega descreve de outro. "Vergalhão CA-50 D=12,5mm" no pedido; "Aço 12,5 CA-50" na nota. São o mesmo item — mas um sistema sem inteligência não reconhece a equivalência e gera uma divergência falsa.

A IA da OnSAC identifica a equivalência semanticamente e faz a correspondência correta, sem intervenção humana. As divergências que chegam para revisão são as reais — não os falsos positivos por diferença de nomenclatura.

Conversão de unidades

Pedido em m³, nota em toneladas. Pedido em unidades, nota em pallets. O almoxarife que faz essa conversão manualmente, sob pressão, na descarga, comete erros. A OnSAC aplica a tabela de equivalência correta automaticamente, garantindo que o dado que chega ao Mega seja sempre preciso.

Como funciona a integração OnSAC + Mega

A OnSAC opera em quatro camadas antes do dado chegar ao Mega:

• Captura: notas de produto e serviço, direto das fontes oficiais, sem depender do fornecedor
• Validação: confronto automático com o pedido — preço, quantidade, unidade, fornecedor, obra
• Confirmação: recebimento físico registrado pelo almoxarife no portal (funciona offline)
• Integração: título gerado automaticamente no Mega com todos os dados corretos e documentos anexados

O resultado é que o time financeiro não lança notas no Mega. Recebe títulos prontos — com histórico completo de cada etapa percorrida desde a emissão.

Reforma Tributária: compliance desde agora

Com o IBS e a CBS em fase de implementação progressiva, construtoras com processos de validação manual enfrentarão crescente dificuldade de compliance. A OnSAC já aplica as regras da Reforma nas NFS-e: a nota de serviço só é liberada para o Mega após a aprovação da Medição de Obra pela engenharia. Zero risco de pagar por serviço não executado. Zero crédito fiscal perdido por nota processada sem o lastro correto.

NF Check-in + ERP Mega Senior: do recebimento do insumo ao pagamento correto. Sempre. Em qualquer obra. Em qualquer município do Brasil.

O ERP UAU, da Globaltec, é um dos sistemas mais completos para o mercado de incorporação e construção civil: controle de viabilidade, orçamento, cronograma, suprimentos e financeiro em uma plataforma integrada. Gestores financeiros e diretores de operações que o conhecem sabem da sua profundidade.

Mas existe uma pergunta que todos eles já fizeram ao menos uma vez: por que o custo real nunca fecha exatamente com o planejado?

Parte da resposta está no portão da obra.

A lacuna entre planejamento e execução

O UAU planeja com dados precisos. O orçamento está correto. O cronograma é realista. O pedido de compra reflete o que foi negociado. Mas no momento em que o caminhão chega ao canteiro e o almoxarife inicia o recebimento, o ciclo de distorção começa:

• A nota vem com unidade diferente do pedido — o almoxarife converte de cabeça
• O preço unitário está 4% acima do negociado — ninguém percebe na descarga
• O fornecedor faturou 100 unidades, entregou 97 — o recebimento registrou 100

Cada um desses eventos, individualmente, parece pequeno. Acumulados ao longo de uma obra com 600 notas por mês, formam uma diferença significativa entre o que o UAU mostra e o que de fato aconteceu.

A OnSAC fecha a lacuna

Antecipação: o dado correto chega antes do material

O NF Check-in captura a nota fiscal no momento da emissão pelo fornecedor, antes do material sair do depósito. O preço é confrontado com o pedido no UAU. Se houver divergência, o responsável é notificado com tempo hábil para solicitar a correção — sem pressão de caminhão esperando no portão.

Conversão automática de unidades

O UAU trabalha com uma tabela de insumos precisa. A OnSAC garante que as notas chegem ao UAU com as quantidades convertidas para a unidade correta do pedido — automaticamente, sem intervenção do almoxarife e sem risco de arredondamento errado.

Three-Way Match: o custo real é o que foi entregue

A OnSAC confirma o recebimento físico no canteiro antes de liberar o título no UAU. Se o fornecedor faturou 100 e entregou 97, o título é gerado por 97. O saldo de pedido no UAU reflete o que foi efetivamente recebido — não o que foi faturado unilateralmente.

Governança de serviços: pague pelo que foi executado

Para contratos de mão de obra e serviços, a OnSAC retém a nota de serviço até que a Medição de Obra seja aprovada pela engenharia. O UAU recebe o título somente quando há comprovação da execução. Zero pagamento por serviço não realizado. Zero pendência de estorno.

O resultado: orçamento e execução alinhados

Quando o UAU recebe dados que passaram pela OnSAC, o que ele mostra é o que de fato aconteceu. O custo real coincide com o lançado. O saldo de pedido reflete o recebido. O financeiro decide com base em informação verdadeira — não em dado lançado sob pressão no canteiro.

O UAU é o mapa do tesouro da sua obra. A OnSAC é o GPS que garante que o mapa seja atualizado com informações reais, em tempo real, desde o portão.

Three-Way Match é o processo de conferência cruzada entre três documentos: o pedido de compra (o que foi negociado e solicitado), a nota fiscal (o que o fornecedor diz que entregou e cobrou) e o recebimento físico (o que realmente chegou na obra). Quando os três são iguais, o pagamento é liberado. Quando há divergência, o processo para.

Parece simples. Na prática, é um dos processos mais negligenciados na construção civil — e um dos que mais custam dinheiro quando não é feito corretamente.

Por que o Three-Way Match existe

Sem a conferência tripla, o financeiro da construtora depende exclusivamente da nota fiscal para liberar o pagamento. E notas fiscais nem sempre refletem a realidade:

• O fornecedor faturou 100 sacos de cimento, entregou 93 — e o portão liberou sem conferência
• O preço unitário está R$ 12 acima do pedido negociado — ninguém percebeu na descarga
• A nota veio para o pedido errado — o pagamento vai sair contra um contrato diferente
• O material entregue é de especificação diferente do solicitado — mas a nota diz que está correto

Cada um desses cenários resulta em pagamento indevido, estoque incorreto ou custo lançado no lugar errado. O Three-Way Match é a única forma de fechar esse ciclo com segurança.

Como o Three-Way Match funciona na OnSAC

1. O pedido de compra (ERP)

O ponto de referência é o pedido registrado no ERP — Sienge, TOTVS, Mega, UAU, MXM ou SAP. O pedido define o que foi negociado: fornecedor, item, quantidade, unidade, preço, obra e centro de custo. Tudo o que vier na nota e no recebimento será confrontado com esses dados.

2. A nota fiscal (SEFAZ)

A OnSAC captura a nota fiscal diretamente do SEFAZ e da Base Nacional, no momento da emissão. O sistema extrai todos os dados estruturados e os confronta com o pedido: preço unitário, quantidade, unidade de medida, CNPJ, descrição dos itens. Se a nota não bater com o pedido, o processo para — e o responsável é notificado com o detalhe da divergência.

3. O recebimento físico (canteiro)

O almoxarife confirma no portal da OnSAC o que foi efetivamente recebido: quantidade, condição e conformidade com o pedido. Essa confirmação, feita no canteiro (com suporte offline), fecha o terceiro elemento da conferência. Sem ela, o título não é gerado — independentemente de a nota estar correta.

O que acontece quando os três batem

Pedido = Nota = Recebimento: o processo segue automaticamente para a geração do título de pagamento no ERP. Sem intervenção manual. Sem aprovação adicional necessária. O financeiro recebe o título pronto — com o histórico completo de cada etapa percorrida.

O que acontece quando há divergência

Qualquer divergência entre os três pontos gera um alerta específico:

• Preço diferente: financeiro é notificado com o valor da diferença e o nome do responsável pelo pedido
• Quantidade diferente: compras é notificado para tratar a divergência com o fornecedor
• Recebimento parcial: título é gerado pela quantidade efetivamente recebida; o saldo do pedido permanece em aberto

Three-Way Match manual vs. automatizado

Muitas construtoras fazem uma versão manual do Three-Way Match: alguém do financeiro compara a nota com o pedido em planilha. O problema é que esse processo é demorado, suscetível a erro humano e não escala com o volume de obras.

Com a OnSAC, o Three-Way Match é executado automaticamente para cada nota recebida, em segundos, com regras configuradas para a realidade da construtora — e rastreabilidade completa de cada decisão.

Cada título de pagamento gerado pela OnSAC representa uma convergência comprovada entre o que foi pedido, o que foi faturado e o que foi entregue. Não por acidente — por processo.

Existe um problema silencioso no processo de recebimento fiscal das construtoras que ninguém gosta de admitir: uma parcela considerável das notas fiscais recebidas não informa o número do pedido de compra correspondente.

O motivo varia. O fornecedor esqueceu de incluir. O sistema de ERP do fornecedor não preenche o campo automaticamente. O pedido foi verbal. A nota cobre mais de um pedido. O número do pedido foi digitado errado no campo da nota.

O resultado é sempre o mesmo: a nota fica parada esperando que alguém do time de suprimentos ou do financeiro localize manualmente qual pedido corresponde àquela entrega. Em obras com alto volume, esse gargalo é diário — e caro.

O que é o Pedido Reverso

Pedido Reverso é a funcionalidade da OnSAC que resolve esse problema automaticamente. Quando uma nota fiscal chega sem o número do pedido de compra (ou com o número incorreto), o sistema usa os dados disponíveis na nota para localizar o pedido correspondente no ERP — sem intervenção humana.

O processo é chamado de "reverso" porque inverte a lógica tradicional: em vez de partir do pedido para encontrar a nota, ele parte dos dados da nota para encontrar o pedido.

Como o Pedido Reverso funciona em 5 etapas

Etapa 1 — Captura e extração dos dados da nota

A nota fiscal é capturada direto do SEFAZ ou da Base Nacional. O sistema extrai todos os dados estruturados: CNPJ do fornecedor, itens, descrições, quantidades, valores totais, data de emissão, obra de destino e qualquer referência disponível ao pedido.

Etapa 2 — Busca inteligente no ERP

Com os dados extraídos, a IA consulta o ERP em busca de pedidos compatíveis. A busca considera múltiplos critérios em simultâneo: fornecedor com aquele CNPJ, pedidos em aberto, pedidos parcialmente atendidos, valor total próximo ao da nota, obras correspondentes e datas compatíveis.

Etapa 3 — Análise semântica dos itens

Um dos pontos mais críticos é a correspondência de itens quando as descrições são diferentes. A IA analisa semanticamente a descrição dos itens na nota e os compara com os itens do pedido no ERP — reconhecendo equivalências mesmo quando a nomenclatura é completamente diferente.

Etapa 4 — Associação e confirmação

Quando o pedido correto é identificado com alto índice de confiança, a associação é feita automaticamente e o processo segue. Quando há ambiguidade — por exemplo, dois pedidos igualmente compatíveis — o sistema apresenta as opções ao responsável com os dados que fundamentam cada sugestão, para que a decisão humana seja informada e rápida.

Etapa 5 — Three-Way Match com o pedido localizado

Com a associação feita, o fluxo normal do NF Check-in segue: a nota é confrontada com o pedido localizado, o almoxarife confirma o recebimento físico, e o título é gerado no ERP. O Pedido Reverso é o que garante que o processo não trave na etapa de correspondência.

Casos em que o Pedido Reverso é especialmente crítico

• Fornecedores que nunca informam o pedido na nota (acontece mais do que se imagina)
• Notas que cobrem múltiplos pedidos (entrega consolidada de vários itens)
• Pedidos criados verbalmente ou por e-mail, sem número formal no ERP
• Obras com muitos fornecedores ativos e alto volume de notas diárias
• Situações em que o comprador está ausente e ninguém sabe qual pedido foi usado

Com o Pedido Reverso, nenhuma nota fica parada esperando que alguém do suprimentos apareça para dizer qual é o pedido. O sistema localiza. O processo segue. O time foca no que importa.

Construtoras que adotam portais de procurement — como o Mercado Eletrônico — ganham muito em competitividade: mais fornecedores, processos de negociação estruturados, aprovações rastreadas e melhores preços. Mas existe um problema que a maioria descobre tarde demais: quando o pedido é aprovado no portal, alguém ainda precisa lançá-lo manualmente no ERP.

Campo por campo. Fornecedor, item, quantidade, unidade, preço, obra, centro de custo. Cada informação já existe no portal — e precisa ser redigitada no ERP. É aí que os erros acontecem, os pedidos somem e o time de suprimentos gasta horas em tarefas que não agregam valor algum.

O custo do gap entre portal e ERP

Esse gap entre o portal de cotação e o ERP tem consequências diretas e mensuráveis:

• Erros de redigitação: quantidade trocada, fornecedor errado, centro de custo incorreto — cada campo relançado manualmente é uma oportunidade de erro
• Defasagem de informação: o ERP não reflete o estado real do pipeline de compras; pedidos aprovados ontem só chegam ao financeiro amanhã, quando alguém tiver tempo de lançar
• Perda de anexos: especificações técnicas, memorandos de negociação e laudos que existem no portal nunca chegam ao ERP
• Custo de oportunidade: o time de suprimentos que deveria estar negociando melhores contratos está relançando pedidos que já foram aprovados

O que o Integrador de Compras OnSAC faz

O Integrador de Compras opera como o elo inteligente entre o portal de procurement e o ERP. Quando um pedido é aprovado no portal, a integração é disparada automaticamente — sem que ninguém precise fazer nada.

O que é transferido automaticamente

A integração não move apenas o número do pedido. Ela transfere o conjunto completo de documentos e dados que o ERP precisa para operar com precisão:

• Pedido de Compra: número, itens, quantidades, valores aprovados e fornecedor vencedor
• Pré-Pedido: intenção de compra para validação prévia no ERP antes da aprovação final
• Requisição: criada automaticamente pela OnSAC no portal e transferida ao ERP
• Dados Mestres: fornecedor, materiais, centros de custo, obras — sincronizados entre os dois sistemas
• Anexos: especificações técnicas, laudos e documentos vinculados à requisição

Sincronização em tempo real

Assim que o pedido é aprovado no portal, a integração é disparada. O ERP é atualizado em segundos — sem defasagem, sem versão conflitante, sem pedido que "sumiu no caminho". O financeiro vê o pipeline de compras em tempo real, como ele está de fato, não como estava ontem quando alguém teve tempo de lançar.

Integração bidirecional de dados mestres

Dados mestres desatualizados entre portal e ERP são uma fonte constante de divergência. A OnSAC mantém os cadastros sincronizados: fornecedores, materiais, preços de referência e condições de pagamento. O que existe no portal existe no ERP. O que muda em um lugar é refletido no outro.

Cases em produção

LBX Construtora: Mercado Eletrônico → Sienge

A LBX opera o ciclo completo de procurement integrado: cotação no Mercado Eletrônico, aprovação no portal, transferência automática para o Sienge via Integrador de Compras, e recebimento governado pelo NF Check-in. Do processo de cotação até o pagamento do fornecedor, zero digitação manual.

Otamerica: Mercado Eletrônico → MXM

A Otamerica eliminou o processo de relançamento de pedidos entre o Mercado Eletrônico e o MXM. O que antes ocupava horas da equipe de suprimentos passou a acontecer automaticamente. O time de compras passou a focar em negociação estratégica — não em digitação operacional.

Integrador de Compras + NF Check-in: governança do procurement ao pagamento

A combinação mais poderosa é usar os dois produtos juntos. O Integrador de Compras garante que o pedido chegue ao ERP corretamente desde a aprovação no portal. O NF Check-in fecha o ciclo no momento do recebimento, fazendo o Three-Way Match entre o pedido, a nota fiscal e a entrega física na obra.

O resultado é um ciclo completamente rastreado e governado: da cotação ao pagamento, sem um único campo digitado manualmente, sem uma única divergência passando sem registro.

A integração entre portal e ERP não é uma conveniência — é o que permite que o time de suprimentos seja estratégico em vez de operacional.

A LBX Construtora, com sede em Maringá (PR), é um dos casos mais completos de integração de procurement e recebimento fiscal na construção civil brasileira. Eles operam com dois produtos da OnSAC de forma integrada: o Integrador de Compras (conectando Mercado Eletrônico ao Sienge) e o NF Check-in (governando o recebimento fiscal do canteiro ao título de pagamento).

O resultado é um ciclo de suprimentos completamente rastreado, sem reentrada de dados e sem pagamento indevido.

O problema antes da integração

Como a maioria das construtoras que usa portais de procurement, a LBX enfrentava um gap crítico entre o Mercado Eletrônico e o Sienge. Quando um pedido era aprovado no portal, o processo de compra estava concluído — mas o trabalho do time de suprimentos no ERP estava apenas começando.

Alguém precisava abrir o Sienge, localizar o fornecedor, criar o pedido de compra campo por campo, inserir cada item com a quantidade correta, vincular à obra e ao centro de custo, e então aguardar a validação do setor financeiro. Com o volume de pedidos da LBX, esse processo consumia horas diárias da equipe — horas que poderiam estar sendo investidas em negociação e análise.

Como funciona o fluxo integrado

Etapa 1 — Cotação e aprovação no Mercado Eletrônico

O processo começa normalmente no Mercado Eletrônico: a necessidade é identificada, a cotação é aberta para os fornecedores habilitados, as propostas são recebidas e o fornecedor vencedor é selecionado. Nada muda nessa etapa — o time de suprimentos continua usando o portal da forma como sempre usou.

Etapa 2 — Transferência automática para o Sienge

Quando o pedido é aprovado no Mercado Eletrônico, a OnSAC recebe o evento automaticamente e inicia a transferência para o Sienge. Em segundos, o pedido de compra está no ERP — com todos os dados: fornecedor, itens, quantidades, valores, obra, centro de custo e os anexos da negociação. Sem que ninguém precise fazer nada.

Etapa 3 — Recebimento no canteiro com NF Check-in

Quando o material chega à obra, o NF Check-in já tem o pedido no Sienge como referência. A nota fiscal, capturada automaticamente do SEFAZ, é confrontada com o pedido: preço, quantidade, unidade, fornecedor e obra. O almoxarife confirma o recebimento físico no portal.

Etapa 4 — Three-Way Match e geração do título no Sienge

Com os três elementos alinhados — pedido (Sienge), nota fiscal (SEFAZ) e recebimento físico (canteiro) — o título de pagamento é gerado automaticamente no Sienge, com todos os documentos anexados e todas as validações registradas.

O que mudou para a LBX

A mudança mais significativa não foi tecnológica — foi estratégica. O time de suprimentos deixou de ser uma equipe de lançamento de dados e passou a ser uma equipe de análise e negociação. O tempo antes gasto em digitação passou a ser investido em melhorar a base de fornecedores, negociar melhores condições e antecipar necessidades de compra.

Do ponto de vista financeiro, o Sienge passou a refletir o estado real do pipeline de compras em tempo real — sem defasagem entre o portal e o ERP, sem versão conflitante dos dados, sem pedido que "sumiu no caminho".

"A OnSAC conectou o nosso processo de compras ao nosso ERP de forma que nunca imaginamos ser possível sem uma implantação complexa. Em semanas, o fluxo estava funcionando — e nunca mais voltamos ao processo manual." — LBX Construtora, Maringá · PR

A Otamerica opera no mercado latino-americano com um processo de suprimentos estruturado: o Mercado Eletrônico como plataforma de procurement e o MXM como sistema de gestão. A combinação faz sentido — cada plataforma é referência na sua função.

O problema era o que acontecia entre as duas: cada pedido aprovado no Mercado Eletrônico precisava ser manualmente relançado no MXM. Campo por campo. Fornecedor, item, quantidade, preço, unidade, obra, centro de custo. Um processo repetitivo, suscetível a erro e que consumia horas diárias da equipe de suprimentos.

O custo invisível do gap entre os sistemas

Na Otamerica, como na maioria das construtoras que operam com portal + ERP, o custo do gap era invisível no orçamento — mas visível no comportamento da equipe. O time de suprimentos chegava cedo para "atualizar o MXM". Reuniões eram adiadas porque "os pedidos ainda não estavam no sistema". Aprovações financeiras eram bloqueadas porque o ERP estava desatualizado em relação ao que havia sido negociado no portal.

Ninguém questionava esse processo — ele era visto como parte inevitável do trabalho. Até a integração com a OnSAC.

Como funciona a integração Mercado Eletrônico → MXM

Pedido aprovado no portal = pedido no MXM

Quando o fornecedor vencedor é selecionado e o pedido é aprovado no Mercado Eletrônico, a OnSAC recebe o evento em tempo real e inicia automaticamente o processo de transferência para o MXM. O pedido de compra é criado no ERP com todos os dados corretos: fornecedor, itens com as quantidades e preços aprovados, obra, centro de custo e documentos da negociação.

O tempo entre a aprovação no portal e a disponibilidade do pedido no MXM: segundos.

Dados mestres sincronizados

Um dos problemas mais comuns em integrações de portal + ERP é a divergência de dados mestres — fornecedor cadastrado com dados diferentes nos dois sistemas, material com codificação incompatível, condições de pagamento que não correspondem. A OnSAC mantém os cadastros sincronizados, garantindo que o que existe no Mercado Eletrônico exista no MXM com fidelidade.

Rastreabilidade completa

Cada transferência é registrada com timestamp, usuário responsável pela aprovação no portal e todos os dados do pedido. Se algo precisar ser auditado — um pagamento questionado, uma divergência de estoque — o histórico completo está disponível em segundos, sem precisar consultar dois sistemas separados.

O que mudou para a Otamerica

A mudança mais imediata foi o tempo: a equipe de suprimentos deixou de dedicar horas diárias ao relançamento de pedidos. Mas a mudança mais significativa foi estratégica: com o MXM sempre atualizado em tempo real, as decisões financeiras passaram a ser baseadas em dados corretos e atuais — não em um snapshot de ontem ou de dois dias atrás.

O time de compras parou de ser operacional. Passou a ser estratégico.

"A OnSAC transformou o que era uma tarefa diária de horas em algo que simplesmente acontece. A equipe de suprimentos agora existe para tomar decisões — não para executar lançamentos que o sistema poderia fazer sozinho." — Otamerica

Para a maioria das construtoras, a gestão de notas fiscais de serviço é um processo paralelo, informal e repleto de lacunas. O material tem ERP, pedido de compra, three-way match. O serviço — mão de obra, locação de equipamento, serviço técnico — ainda depende de e-mail do prestador, acesso manual a portal de prefeitura e validação humana que raramente acontece antes do pagamento.

O resultado é previsível: pagamentos por serviços não executados, notas perdidas, atrasos fiscais e ausência de rastreabilidade nas auditorias.

O problema estrutural das NFS-e no Brasil

Diferente das notas fiscais de produto (NF-e), que têm um sistema centralizado nacional (SEFAZ), as notas fiscais de serviço historicamente eram emitidas por sistemas municipais fragmentados. Cada prefeitura com seu portal, sua API (quando tinha) e suas regras.

Para uma construtora com obras em São Paulo, Manaus, Florianópolis e Goiânia, isso significava quatro portais diferentes, quatro cadastros, quatro processos manuais — ou dependência total do prestador para enviar a NFS-e por e-mail.

A Reforma Tributária e a Base Nacional de NFS-e

A Reforma Tributária criou a Base Nacional de NFS-e: um sistema centralizado onde as prefeituras registram as notas de serviço emitidas em seus municípios. A lógica é a mesma do SEFAZ para NF-e — um único ponto de consulta para qualquer nota emitida no país.

Isso foi um avanço significativo. Mas por si só não resolve o problema da construtora: ela ainda precisaria acessar a Base Nacional, autenticar com certificado digital e fazer consultas periódicas para cada CNPJ de cada obra. Manualmente, ou com uma solução que faça isso automaticamente.

Como a OnSAC resolve: integração direta com a Base Nacional

A OnSAC se integra à Base Nacional de NFS-e usando o certificado digital A1 da construtora. A partir dessa autenticação, o sistema monitora continuamente a base em busca de notas emitidas contra todos os CNPJs da empresa — obras, filiais, SPEs.

O que isso significa na prática

Quando um prestador emite uma NFS-e para a construtora — em qualquer município, de qualquer porte — a nota aparece na Base Nacional. A OnSAC captura automaticamente, extrai os dados estruturados e inicia o processo de governança. Sem e-mail. Sem acesso manual. Sem ligação para o prestador.

• Prestador de mão de obra em obra no interior de Mato Grosso emite NFS-e → OnSAC captura
• Empresa de locação de andaime emite nota em Recife → OnSAC captura
• Empresa de topografia emite nota em Curitiba → OnSAC captura

Em todos os casos: automaticamente, no momento da emissão, sem que ninguém na construtora precise fazer nada.

Governança de serviços: o Contrato Reverso

Capturar a nota de serviço é apenas o primeiro passo. A OnSAC vai além com o Contrato Reverso — o mecanismo que garante que a NFS-e capturada só seja liberada para pagamento quando existe uma medição aprovada que a ampare.

Como funciona

Diferente dos materiais, onde o Three-Way Match confere Pedido × Nota × Recebimento físico, para serviços o processo é:

• Contrato no ERP: o contrato de prestação de serviço está registrado no ERP (Sienge, TOTVS, SAP, Mega, UAU) com escopo, valor e cronograma
• NFS-e capturada: a nota do prestador chega automaticamente via Base Nacional
• Busca do contrato (Contrato Reverso): a OnSAC identifica o contrato correspondente no ERP usando CNPJ do prestador, valor e período — sem intervenção manual
• Verificação da Medição: o sistema verifica se existe Medição de Obra aprovada pela engenharia para o escopo cobrado na nota
• Decisão: com medição aprovada → nota liberada e título gerado. Sem medição → nota retida e responsável notificado

A construtora para de confiar na nota do prestador e começa a controlar o pagamento pelo que foi efetivamente medido e aprovado pela engenharia. Esse é o princípio da governança de serviços.

NFS-e, NF-e e CT-e: governança unificada

O NF Check-in da OnSAC cobre os três principais documentos fiscais que entram na construtora:

• NF-e (Nota Fiscal Eletrônica): para materiais e insumos — capturada via SEFAZ, com Pedido Reverso e Three-Way Match com recebimento físico no canteiro
• NFS-e (Nota Fiscal de Serviços Eletrônica): para mão de obra, equipamentos e serviços técnicos — capturada via Base Nacional, com Contrato Reverso e vinculação à Medição de Obra
• CT-e (Conhecimento de Transporte Eletrônico): para fretes e transportes — capturado e validado antes do pagamento ao transportador

Um único portal. Uma única equipe de validação. Um único fluxo de aprovação e geração de títulos no ERP. A construtora não precisa de processos paralelos para cada tipo de documento.

O impacto na Reforma Tributária

Com o IBS (Imposto sobre Bens e Serviços) e a CBS (Contribuição sobre Bens e Serviços) em fase de implementação progressiva, a gestão de NFS-e ficou ainda mais crítica. As regras de crédito sobre serviços são complexas — e só se aplicam quando a nota de serviço está corretamente vinculada a uma prestação comprovada.

A OnSAC aplica automaticamente as regras da Reforma Tributária em cada NFS-e validada: alíquotas de IBS e CBS verificadas, créditos fiscais identificados, compliance garantido sem esforço manual da equipe fiscal.