Três automações contábeis: como construir, onde a IA entra, onde ela não pode entrar

Este material é para você construir. Ele pega três processos contábeis que saíram da planilha e viraram sistema e abre o como: a regra escrita até o fim, os prompts completos, o código do cálculo, os testes que travam o deploy, e os erros reais — com a correção de cada um.

Não é relato de resultado. É roteiro.

O que você não vai encontrar aqui, de propósito. Nenhum dado ou valor de cliente, nenhum número da operação do escritório, nenhuma regra interna de equipe ou de permissão. Isso é informação confidencial e não entra em material de aula. O que está aberto é o que você pode copiar e adaptar: as regras fiscais, que são públicas, os prompts, o código, os testes e as armadilhas.

Os três casos foram escolhidos porque usam IA de três formas diferentes — e é a diferença entre eles que vira método.

Os termos técnicos, traduzidos

As seções mais adiante usam alguns nomes de tecnologia. Nenhum deles precisa ser decorado — mas todos ficam mais úteis quando você sabe o que a coisa faz neste processo específico. Esta tabela serve de referência enquanto você lê.

Um esclarecimento que ajuda a ler o resto: o IRRF sobre dividendos nasceu em 2026. A retenção veio com a reforma. Antes não havia cálculo a fazer; agora passou a existir uma apuração por sócio × empresa × mês, com limiar, abatimento retroativo e saldo isento — que é justamente o que a planilha não sustenta.

Automação 1 — Distribuição de lucros com IRRF

Como era feito antes. Controle em planilha de Excel: o cliente distribuía, avisava o escritório, alguém buscava a informação, conferia o saldo disponível, lançava na planilha, validava — e só depois isso virava registro contábil, REINF e informe de rendimentos. Fila de gente, prazo apertado, retificação depois.

O problema de verdade. A retenção criada em 2026 trouxe um limiar mensal por sócio × empresa. Parece simples e não é: a regra depende do histórico do mês inteiro daquele par e muda a cada novo lançamento — toda vez que entra uma distribuição, o imposto das anteriores daquele mês pode mudar de situação.

É o tipo de conta que planilha não sustenta, porque não existe "linha isolada": existe acumulado. Reconhecer isso é o que decide a arquitetura.

O que é IA aqui. A construção do software e a tradução da regra fiscal em código funcionando. Nenhum modelo roda em produção: a IA construiu o software; quem calcula o imposto é regra determinística, em código testado. Existe agente? Não.

Como os dados entram. Lançamento manual num assistente de tela: valor bruto. Duas portas para o mesmo dado — a tela interna do escritório e o portal do cliente. O cliente lança, o escritório enxerga no mesmo instante.

Integrações. Sem ferramenta de automação no meio. Três bancos de dados conversando por webhook e funções de borda, com autenticação por chave, trava contra laço infinito e regra de conflito definida. A propagação de exclusão vive num serviço separado, para não apagar dado por acidente.

Onde o humano entra. Vê a prévia do IRRF antes de gravar — o sistema calcula sem salvar e mostra os avisos; decide consumir ou não o saldo isento; marca exceção quando cabe, com uma trava no servidor que impede classificar Lucro como fora da base, porque isso zeraria imposto devido.

A lição de arquitetura: quando a interface permite uma exceção, a trava não pode morar na interface. Ela mora no servidor, por onde toda porta passa — a tela interna, o portal do cliente e qualquer integração futura.

Como ficou. IRRF calculado no ato do lançamento, recibo em PDF com protocolo, histórico com bruto, IRRF e líquido, painel de saldo por empresa e exportação em Excel. A retenção é uma obrigação que em 2025 não existia, e foi absorvida sem dia de trabalho novo.

Uma decisão de implantação que vale copiar: comece pelas empresas de maior movimento. São as que mais doem na planilha, as que produzem caso de teste rápido e as que justificam o projeto antes de você ter migrado tudo.

O erro que você vai cometer: split-brain

O que aconteceu. A tela de novo lançamento gravava e calculava num banco de dados enquanto o sistema lia de outro. Lançamentos sumiam da tela e, pior, o cálculo do mês usava um histórico incompleto: com menos distribuições no acumulado, o total não atingia o limiar de R$ 50 mil e o sistema deixava de reter imposto devido. Duas semanas depois o mesmo defeito reapareceu escondido na opção de consumir o saldo isento.

Por que aconteceu. O módulo nasceu num banco e migrou para outro. A leitura migrou; a escrita ficou para trás.

O que foi alterado. Escrita e leitura passaram a acontecer no mesmo banco, com tradução explícita das chaves de empresa e sócio. O motor de cálculo não foi tocado — o erro nunca esteve na regra, e sim em qual dado a regra recebia.

A lição que vale para tudo: automação não erra alto e escandaloso. Erra baixo, plausível e em silêncio. Quando for diagnosticar, pergunte primeiro "qual dado a regra recebeu?" antes de suspeitar da regra.

Um segundo erro, da mesma família. O painel de visão geral somava apenas as primeiras 1.000 distribuições, porque a camada de acesso ao banco cortava nesse número sem erro e sem aviso. O total exibido era menor que a realidade e parecia plausível. Ninguém desconfia de um número plausível.

A regra que ficou: toda leitura de lista é paginada por obrigação. Camada de acesso que corta em silêncio é pior que erro — erro você vê.

Uma terceira armadilha, mais barata mas igualmente cara em tempo: uma divergência entre dois bancos foi investigada como falha de sincronismo. Era valor bruto contra valor líquido. Todo indicador precisa declarar sua unidade.

O prompt da Gestão de Lucros, para copiar e adaptar

A regra abaixo é onde o prompt chegou depois de passar por três ferramentas. Não é a primeira versão — a primeira tinha poucas linhas e pedia "monte um controle de distribuição de lucros com cálculo de IRRF". A diferença entre as duas é a história inteira de amadurecer uma automação.

CONTEXTO
Você é um assistente fiscal brasileiro. Vai calcular o IRRF sobre distribuição
de lucros a sócio de pessoa jurídica, segundo a regra vigente a partir de 2026.

DADOS QUE VOCÊ RECEBE
· valor bruto do evento
· categoria: Lucro | Pró-labore | Empréstimo | Devolução de empréstimo |
  Plano de saúde | Outros
· total bruto já distribuído no mês para o MESMO sócio na MESMA empresa
· IRRF já retido no mês para esse mesmo par sócio × empresa
· saldo de lucros isentos de 2025 ainda disponível na empresa
· se o operador autorizou consumir esse saldo neste evento

TAREFA
Devolver: o IRRF deste evento, o valor líquido a pagar, quanto consumiu do
saldo isento, e o motivo quando o IRRF for zero.

REGRAS
1. Entram na base: Lucro, Plano de saúde e Outros. Ficam fora: Pró-labore,
   Empréstimo e Devolução de empréstimo (têm tributação própria).
2. Limiar mensal: se o total bruto do mês para esse sócio × empresa NÃO passar
   de R$ 50.000, o IRRF é zero.
3. Se passar, o IRRF é 10% sobre o TOTAL do mês — não sobre o excedente.
4. Do total devido, abata o que já foi retido no mês para esse par.
5. O saldo isento de 2025, quando autorizado, reduz a base e só pode ser
   consumido em Lucro ou Outros.
6. Se o IRRF a reter ficar maior que o valor bruto do evento, não calcule:
   recuse e explique. Líquido negativo é erro de lançamento.

O QUE NÃO FAZER
· Não arredonde por conveniência: duas casas decimais, sempre.
· Não trate "Lucro" como fora da base em hipótese alguma.
· Não invente saldo isento que não foi informado.

SAÍDA
JSON: { irrf_evento, valor_liquido, consumo_saldo_2025, total_bruto_mes,
        total_irrf_mes, avisos[], motivo_isencao }

Os testes de aceite — o que transforma prompt em processo

Um prompt bom ainda não é um processo. O que fecha a conta são cenários de aceite: casos com resposta conhecida, escritos antes, que a ferramenta precisa acertar toda vez. Eles viram trava automática — se o motor deixar de acertar qualquer um, o código não sobe.

São casos de teste inventados para o exercício, não lançamentos reais.

O cenário 1 é o que mais confunde: a leitura intuitiva sugere 10% sobre o excedente de R$ 5.000. São 10% sobre os R$ 55.000 inteiros. Vale usar esses três

Teste de ferramenta pronta: jogue esses três casos em qualquer sistema que prometa fazer esse cálculo, inclusive os comprados. Você descobre em cinco minutos se a regra está certa lá dentro.

Como o prompt mudou em cada ferramenta

O mesmo processo passou por três ferramentas, e o prompt amadureceu em cada uma. A sequência vale mais que qualquer uma delas:

Abrindo o motor fiscal

"Motor determinístico em código" é fácil de dizer e fácil de virar caixa-preta. Este é o código real que calcula o IRRF, com os comentários apontando o que cada pedaço faz. Não é preciso saber programar para acompanhar — a regra que você já conhece está escrita ali.

// [1] AQUI ESTÁ O LIMITE, escrito uma vez só
const LIMIAR_MENSAL_IRRF = 50_000;
const ALIQUOTA_IRRF_DIVIDENDOS = 0.10;

// [2] AQUI DECIDIMOS O QUE ENTRA NA BASE
switch (categoria) {
  case 'PROFIT':         return true;   // lucro entra
  case 'HEALTH_PLAN':    return true;   // plano de saúde entra
  case 'OTHER':          return true;   // outros entram
  case 'PRO_LABORE':     return false;  // pró-labore tem tributação própria
  case 'LOAN':           return false;  // empréstimo não é lucro
  case 'LOAN_REPAYMENT': return false;  // devolução também não
}

// [3] AQUI CONSIDERAMOS O SALDO ISENTO DE 2025
const consumidoDoSaldo = podeUsarSaldo && operadorAutorizou
  ? Math.min(saldoDisponivel, valorBruto) : 0;
const valorQueEntraNaBase = valorBruto - consumidoDoSaldo;

// [4] AQUI SOMAMOS O MÊS DESTE SÓCIO NESTA EMPRESA
const totalDoMes = historicoDoMes + valorQueEntraNaBase;

// [5] AQUI VERIFICAMOS O LIMITE
if (totalDoMes <= LIMIAR_MENSAL_IRRF) {
  return { irrf: 0, motivo: 'total do mês abaixo do limiar' };
}

// [6] AQUI APLICAMOS A ALÍQUOTA sobre o TOTAL, não sobre o excedente
const irrfDevidoNoMes = totalDoMes * ALIQUOTA_IRRF_DIVIDENDOS;

// [7] AQUI ABATEMOS O QUE JÁ FOI RETIDO NESTE MÊS
const irrfDesteEvento = irrfDevidoNoMes - jaRetidoNoMes;

// [8] AQUI BLOQUEAMOS: se o imposto passar do valor do evento,
//     o sistema recusa em vez de gerar líquido negativo
if (irrfDesteEvento > valorBruto) {
  throw new Error('IRRF a reter excede o valor bruto do evento');
}

Bloco a bloco:

1. O limite mora numa linha só. Se a lei mudar, muda ali e muda para todos os clientes no mesmo instante.
2. É a tabela que todo contador tem na cabeça, escrita de um jeito que o computador também entende.
3. O saldo isento da ATA reduz a base, não o imposto. A diferença importa.
4. O mês é daquele sócio naquela empresa. Essa conta muda a cada novo lançamento — é o que torna a planilha inviável.
5. O teste do limite.
6. Dez por cento sobre o total, não sobre o excedente.
7. Desconta o que já foi retido antes, no mesmo mês.
8. O sistema se recusa a fazer a conta. Melhor travar do que entregar um líquido negativo.

O bloco [8] é o mais importante de todos: automação boa não é a que sempre responde — é a que sabe quando não responder.

Automação 2 — Conciliação de fornecedores

O problema. Casar a nota provisionada com o pagamento, somando as retenções (IRRF, INSS, ISS, PIS, COFINS), e dizer o que não fechou. No Excel isso é conferência linha a linha, e tem um defeito pior que o tempo gasto: não fica registro de por que aquela linha foi considerada conciliada. A pendência que passa batido vira diferença no balanço, descoberta só no fechamento.

A decisão de projeto que importa — e é a mais contraintuitiva deste material: aqui não entra IA nenhuma. Não por limitação, por adequação. Conciliar é regra objetiva e repetitiva: mesma entrada, mesmo resultado. É exatamente onde se quer previsibilidade, não interpretação.

Aprenda isto antes de qualquer prompt: se a tarefa não tem dúvida, você não quer inteligência — quer repetição. Vai gastar menos e dormir melhor.

Ferramentas. Python (pandas e openpyxl) como primeiro motor, rodando numa máquina local. Depois portado integralmente para dentro do sistema, onde a equipe usa sozinha. IA: nenhuma. Agente: não.

O que é regra tradicional. Tudo — com um detalhe que vale copiar: a aritmética roda em centavos inteiros, nunca em número decimal, porque conciliação feita com número quebrado erra no centavo e derruba a confiança no relatório inteiro.

Onde o humano entra. O contador concilia, rejeita ou pareia manualmente a linha que o motor não resolveu. Essa decisão é gravada com uma assinatura estável (documento + valor da nota + valor pago) e volta aplicada sozinha na rodada seguinte.

Como fica. Sobe o arquivo e o motor roda em segundos, devolvendo as linhas conciliadas, as repescadas e as pendências agrupadas por fornecedor, cada uma com o motivo escrito em português. O ganho não é só o tempo: o que sobra chega agrupado e explicado, não linha solta.

A regra, que aqui faz o papel do prompt

1ª camada — por número da nota: soma de TODOS os créditos da referência (vários acumuladores) contra a soma de TODOS os débitos (pagamento + retenções IRRF/INSS/ISS/PIS/COFINS).

2ª camada — repescagem: débito e crédito que zeram no mês; resíduo de arredondamento de até um centavo.

3ª camada — decisão do humano, que fica valendo.

O que não fechar vira pendência, com o motivo dito em português: nota sem pagamento no período · crédito e pagamento divergentes · sem referência · pagamento sem nota provisionada.

Aprendizado sem modelo

A terceira camada é a parte mais interessante deste processo. Quando o contador resolve manualmente uma linha, a decisão não fica só naquele lote: ela é gravada com uma chave que identifica a linha independentemente do arquivo, e reaparece aplicada na rodada seguinte.

É memória de processo, não aprendizado de máquina — e resolve o mesmo problema por uma fração do custo, com total previsibilidade.

Princípio geral: guarde a decisão do humano. Sem isso, a mesma exceção volta todo mês e a automação nunca melhora.

O erro real: a repescagem roubava as conciliações boas

O que aconteceu. A segunda camada — a tolerante, que casa por valor — estava rodando antes da camada oficial, que casa por número de nota. Casamentos frouxos pegavam linhas que teriam fechado corretamente pela nota. A taxa de conciliação aparecia inflada, com pareamento errado por baixo.

Por que aconteceu. As camadas foram escritas em ordem de dificuldade de implementação, não em ordem de confiança no resultado.

O que foi alterado. A ordem virou regra explícita: a repescagem só roda depois que a camada oficial terminou, sobre as sobras. E as camadas ficaram visíveis na tela — "por nota", "por valor", "repescado", "resíduo", "conciliado manual". O contador vê como cada linha fechou, não apenas que fechou.

A lição: ordene as etapas por confiança, da mais segura para a mais tolerante. E mostre na tela por qual caminho cada item passou — senão você tem um número bom escondendo um casamento ruim.

Outros três defeitos corrigidos no caminho: resíduo de R$ 0,01 virava pendência de verdade e poluía o relatório; retenção lançada como crédito — que é estorno — estava sendo somada como se fosse pagamento, e fechava nota que não tinha fechado; e o leitor do arquivo da Domínio rejeitava o razão sem dar erro claro.

Como a regra se afina. Reprocessando o mesmo arquivo várias vezes seguidas, ajustando a regra entre uma passada e outra e vendo a quantidade de pendências cair. Vale dizer porque desfaz uma ilusão comum: automação de regra não nasce pronta. Ela nasce de rodar contra dado real, olhar o que sobrou, e perguntar por quê.

Um detalhe que ninguém antecipa: o arquivo exportado do ERP vem com a extensão mentindo — é .xls mas por dentro pode ser outro formato. O leitor precisa de quatro tentativas em cascata até conseguir abrir. É o tipo de trabalho invisível que separa uma demonstração de um sistema em produção.

Automação 3 — Aplicações Financeiras (Informes de Rendimentos)

Extração dos informes de rendimentos de aplicações financeiras e preenchimento do controle de Receitas Financeiras e IRRF. É aqui que a IA entra de verdade — e é aqui que ela é impedida de concluir sozinha.

O problema. Abrir o PDF do informe do banco, achar as seções certas e digitar rendimento e IRRF mês a mês, conta a conta, na planilha que alimenta a apuração trimestral. Cada banco tem um layout próprio — e é isso que inviabiliza um leitor rígido, daqueles que procuram o valor numa posição fixa da página.

E o risco não é o tempo: é digitação de número financeiro, o tipo de erro que ninguém pega na conferência e que se propaga direto para a apuração do trimestre.

Qual IA. Gemini 2.5 Flash, lendo o PDF nativo por visão (sem OCR prévio). Temperatura 0, saída obrigatoriamente em JSON, 3 tentativas com espera crescente, 4 arquivos em paralelo com barra de progresso. A função é sem estado: ela lê e devolve, não grava no banco.

Existe agente? Não — é uma chamada única por documento, sem memória e sem autonomia. Não é um agente: é uma função que lê um papel e devolve uma tabela. Era só isso que o processo precisava.

O que é regra tradicional. Conversão de número pelo último separador decimal (resolve o padrão americano contra o brasileiro); CNPJ com zero à esquerda; identificação do banco por tabela própria; deduplicação de competência; e recálculo de todos os totais no servidor — nunca se confia no total que o modelo devolveu.

Onde o humano fica. A extração volta para a tela e a pessoa confere e edita linha a linha antes de salvar. Os arquivos descartados aparecem listados com o motivo. Os avisos da própria IA aparecem ao lado do valor. Ao fechar o período, a obrigação fica no painel como aguardando validação humana — e só fica entregue depois que alguém valida.

A ordem que vale copiar: aqui a IA entrou depois, não antes. Primeiro veio a planilha histórica do ano anterior, já digitada e conferida — que virou gabarito. Só então a IA foi posta para ler os PDFs, e o que ela devolvia pôde ser comparado com o que já se sabia estar certo. Sem gabarito você não tem como saber se está certo; tem só a impressão de que está.

O prompt — este está em produção hoje

CONTEXTO
"Você é um assistente contábil brasileiro especializado em rendimentos de
aplicações financeiras e IRRF."

TAREFA
Classificar se o documento é um Informe de Rendimentos (extrato, fatura,
contrato e proposta NÃO são) e extrair, por conta, o Rendimento e o IRRF de
cada mês.

REGRAS
· "empresa_cnpj" = a PJ BENEFICIÁRIA. NUNCA o CNPJ da fonte pagadora, do
  banco, nem do administrador do fundo.
· Alguns bancos usam padrão americano ("5,058.06" = cinco mil) e outros o
  brasileiro ("4.283,83"). Converta corretamente.
· IGNORE linhas de "Total"/"Total Trimestre" e seções que mostram apenas SALDO.
· Se os MESMOS valores aparecerem em duas seções do documento, conte a conta
  uma única vez.
· exercicio = o ano-calendário IMPRESSO (pode não ser o atual).
· Não invente: campo ausente = null ou "0.00".

SAÍDA
JSON exato: { eh_informe_rendimentos, empresa, empresa_cnpj, exercicio,
contas[{ banco, conta, tipo, darf, meses[{ mes, rendimento, irrf }] }],
avisos[] }

Repare no bloco de REGRAS: nenhuma daquelas linhas estava na primeira versão, que tinha quatro linhas. Cada uma foi acrescentada depois que um documento real quebrou a anterior.

Um prompt maduro é um registro de erros. Não tente escrever o prompt perfeito de partida — escreva o suficiente, rode contra documento real, e transforme cada falha em uma linha nova.

O erro real: o banco repete meses, e a correção quebrou outra coisa

O que aconteceu. Alguns bancos emitem o informe do trimestre repetindo meses que já tinham sido importados. O robô contava a receita duas vezes.

A correção trouxe um defeito próprio. Para deduplicar, a chave usava os últimos seis dígitos da conta — só que esses dígitos incluíam o código do DARF impresso no fim. Duas contas diferentes acabavam com a mesma cauda, e o sistema passou a pular meses de contas distintas. De contar a mais, passou a contar a menos.

O que foi alterado. A chave de deduplicação passou a ser o número da conta, ignorando o código do DARF — e conta sem número claro nunca deduplica: na dúvida, não pula.

A lição mais traiçoeira deste material: o erro mais caro não foi a IA ler errado. Foi a correção que consertou uma coisa e quebrou outra. Correção de automação merece a mesma desconfiança — e o mesmo teste — que o erro original.

Dois outros defeitos, mais simples e igualmente instrutivos: o modelo pegava o CNPJ do banco ou do administrador do fundo em vez do beneficiário; e "5,058.06" lido no padrão brasileiro virava cinco reais em vez de cinco mil.

Medir a falha faz parte

Parte dos arquivos que sobem não gera lançamento nenhum — arquivo que não era informe, ou documento que não rendeu extração. Esses descartes são mantidos de propósito, listados com o motivo, em vez de desaparecerem.

Por que isso importa: uma taxa de aproveitamento visível é o que permite melhorar o prompt em vez de adivinhar. Automação que esconde a própria falha não tem como melhorar — e passa a impressão de estar perfeita.

Do PDF à tela

A IA podia ter respondido em texto: "o rendimento de janeiro foi mil duzentos e cinquenta reais e quarenta centavos". Só que aí alguém teria que ler e digitar de novo — e o problema seria o mesmo de antes. Então pedimos que ela responda numa ficha com campos nomeados. Isso é o JSON. O sistema lê a ficha e preenche a tela sozinho.

Estrutura, com valores inventados só para ilustrar:

{
  "eh_informe_rendimentos": true,
  "empresa": "<razão social do titular>",
  "empresa_cnpj": "00000000000000",
  "exercicio": 2026,
  "contas": [
    { "banco": "Banco X", "conta": "00012-3", "tipo": "CP", "darf": "3426",
      "meses": [ { "mes": 1, "rendimento": "1250.40", "irrf": "250.08" },
                 { "mes": 2, "rendimento": "1310.15", "irrf": "262.03" } ] }
  ],
  "avisos": ["valor de março parcialmente legível"]
}

Dois campos merecem atenção especial, e os dois são baratos de copiar:

avisos — pedimos que a própria IA diga do que ela não teve certeza. Esse aviso vai direto para a tela de conferência, ao lado do valor. Custa uma linha no prompt e muda completamente a relação com o erro: em vez de procurar o que pode estar errado, a pessoa é levada até o ponto duvidoso.

"não invente: campo ausente = null" — também está no prompt. Um modelo que preenche buraco por conta própria é o maior risco de qualquer automação contábil, porque o resultado parece completo.

Os três desenhos

Cada caixa abaixo é um sistema com nome; cada seta diz que informação está passando. Leia as setas em voz alta e o processo se explica.

Gestão de Lucros

Cliente (portal)  ──┐
                    ├─ empresa, sócio, valor bruto ─→  MOTOR DE IRRF
Escritório (tela) ──┘                                  (regra em código)
                                                          ↑        ↑
     Banco: histórico do mês ─ quanto já foi pago ────────┘        │
     Banco: saldo isento de 2025 ─ quanto ainda há ───────────────┘

MOTOR ─ IRRF, líquido, avisos ─→ PRÉVIA NA TELA
                                     │
                                     └─ humano confirma ─→ Banco: distribuição gravada
                                                               │
                                                               ├─ webhook avisa ─→ função de borda ─→ banco do outro lado
                                                               └─→ recibo em PDF com protocolo

Lendo o desenho: o lançamento entra por duas portas — o cliente ou o escritório. O motor busca no banco o histórico daquele sócio naquele mês, calcula e mostra a prévia. Só grava depois que a pessoa confirma. Gravou, o webhook avisa o outro sistema sozinho.

Conciliação de Fornecedores

Razão de fornecedores (.xls do ERP)
   │ data, histórico, crédito, débito
   ↓
LEITOR DO ARQUIVO ─ tabela na memória ─→ 1ª CAMADA: casa por número da nota
                                              │              │
                                     conciliado              o que sobrou
                                              │              ↓
                                              │   2ª CAMADA: casa por valor e por saldo
                                              │        │            │
                                              │  repescado    o que sobrou
                                              ↓        ↓            ↓
                                           RESULTADO        PENDÊNCIA (com o motivo escrito)
                                              │                      │
                                              ↓            contador decide
                                      Excel com 8 abas               ↓
                                                        Banco: decisão gravada por linha
                                                                     │
                                                 volta aplicada na próxima rodada ─┘

Lendo o desenho: o motor tenta primeiro o casamento seguro, pelo número da nota. Só o que sobrou vai para a tentativa mais tolerante. O que ainda sobrar vira pendência com o motivo escrito em português — e a decisão do contador fica gravada para valer na próxima rodada.

Aplicações Financeiras

PDF do informe (vários bancos, vários layouts)
   ↓
FUNÇÃO DE BORDA (não grava nada)
   │  PDF + instruções                      ficha em JSON:
   └──────────────→  GEMINI  ──────────────→ banco, conta, mês,
                 (lê o PDF olhando)          rendimento, IRRF
   ↓
TELA DE CONFERÊNCIA  ←─ Regras em código: formato de número, CNPJ, duplicidade
   │
   └─ humano confere e edita ─→ Banco: lançamentos
                                   │
                                   ├─→ painel por empresa e Excel
                                   └─ robô propõe ─→ Obrigação: aguardando validação humana
                                                          │
                                                   pessoa valida ─→ ENTREGUE

Lendo o desenho: a IA só lê e devolve — ela nunca escreve no banco. Entre ela e o banco há uma camada de regra que conserta formato de número e CNPJ, e uma pessoa que confere. A obrigação só fica entregue depois que alguém assina.

Como a IA construiu o software

Esta é a parte que mais interessa a quem não programa. A sequência foi a mesma nos três casos: a regra contábil que eu já sabia virou prompt — a regra escrita até o fim; o prompt gerou código; o código foi testado contra caso real; o erro que apareceu voltou como regra nova no prompt. E assim até o software funcionar.

A parte difícil nunca foi o código. Foi escrever a regra até o fim, incluindo o que não pode acontecer. Um prompt que só diz o que fazer gera um programa que faz coisa errada com confiança.

Na Conciliação, por que Python? A resposta honesta é sequencial, não técnica: o arquivo era uma planilha, e Python é a linguagem que melhor lida com planilha; não havia tela nenhuma ainda e não precisava — dava para rodar na própria máquina e olhar o resultado; e só depois que a regra provou que funcionava é que virou tela dentro do sistema. A regra, em todo caso, é do contador — não da IA.

Como sabemos que está certo

Cada um dos três foi validado de um jeito diferente — e os três jeitos podem ser copiados.

O teste da Conciliação é o mais instrutivo, porque foi humano e metódico — e porque achou coisa. Cada apontamento virou uma causa-raiz no código:

Não foi a IA que descobriu nada disso. Foi um contador com o razão aberto do lado. É assim que automação contábil melhora — e por isso o passo de validação humana não é burocracia, é a fonte das próximas regras.

O que os três ensinam juntos

Três princípios atravessam os três:

1. Separe interpretação de cálculo. Interpretar documento, classificar, resumir e identificar são tarefas boas para IA. Cálculo, limiar, validação objetiva e campo obrigatório são regra determinística e devem continuar sendo, porque precisam dar o mesmo resultado toda vez e ser auditáveis depois.

2. A entrega só existe depois que uma pessoa assina. Nos três casos a máquina propõe e um humano confirma. Isso não é desconfiança da tecnologia: é o que permite usar a tecnologia numa atividade com responsabilidade técnica.

3. Guarde a decisão do humano. Quando o contador resolve uma exceção, essa decisão tem que ficar em algum lugar e voltar aplicada. Sem isso, a mesma exceção volta todo mês e a automação nunca melhora.

Sobre as horas que sobraram

Um esclarecimento que importa mais que qualquer número: as pessoas continuam. As cinco do time contábil que faziam a conferência e a digitação seguem no processo. O que mudou não foi o tamanho da equipe — foi o que ela faz com o tempo.

As horas poupadas não viraram redução de quadro. Viraram tempo para conversar com cliente, olhar exceção de verdade e cuidar do que exige julgamento contábil. Automação que devolve tempo para relacionamento rende mais que automação que corta gente — e, no caso destes três processos, a parte que sobrou para o humano é justamente a mais difícil de contratar.

Como começar no seu escritório

O caminho que funcionou aqui não começou pela ferramenta.

1. Escolha uma tarefa repetitiva, cara ou cansativa. Não a mais estratégica — a que dói toda semana.
2. Desenhe como ela funciona hoje, com as pessoas e as etapas reais, inclusive as que ninguém registra.
3. Separe o que é regra, o que é interpretação e o que precisa continuar humano. Essa separação é o projeto inteiro. Se tudo for regra, você talvez não precise de IA nenhuma — e vai gastar menos e dormir melhor.
4. Automatize uma parte pequena e rode contra dado real. Dado real quebra suposição mais rápido que qualquer planejamento.
5. Escreva os cenários de aceite antes de confiar: três ou quatro casos com resposta conhecida, que a ferramenta precisa acertar sempre.
6. Mantenha a validação humana e guarde as decisões dela.

E uma última observação, que talvez seja a mais útil: automação não erra alto e escandaloso. Erra baixo, plausível e em silêncio. Um total que parece razoável, um mês que ficou de fora, um imposto que deixou de ser retido. Por isso vale mais investir em conferência e em número com fonte do que em tela bonita.