Transaction Classifier — rule learning, overview pra DRE de franquia multi-loja
Transaction Classifier — rule learning, overview pra DRE de franquia multi-loja
1. Hook
Transaction Classifier é a Tool de classificação de lançamentos bancários do Visio PNL: classifica cada descrição uma vez e a regra aplica retroativo no histórico e prospectivo no futuro, em todas as lojas do grupo. É a segunda Tool obrigatória da Toolbox DRE, depois do Bank Connection — sem regra de classificação, o extrato bancário entra no sistema mas a DRE não calcula. A mecânica central: regra única por descrição bancária aplica-se simultaneamente a todas as lojas do grupo; taxonomia de natureza expandida distingue pagamento a fornecedor de despesa operacional pra alimentar CMV corretamente — separação ausente em ERPs SMB genéricos. Uma rede multi-loja roda essa Tool em produção. O ganho real não é “classificar mais rápido” — é parar de classificar.
2. Por que isso importa
O extrato bancário chega com descrições cruas: “PIX ENVIADO 05/04”, “CISPAG 0012345”, “PAGAMENTO BOLETO”. Sem classificação, esses textos não viram DRE. A alternativa default no mercado brasileiro é planilha mensal — exporta extrato, mapeia descrição por descrição pra categoria, copia valor pro template, repete por loja e por mês. Operador multi-loja gasta 2 a 3 dias por mês nesse ciclo, e o mês seguinte recomeça do zero porque planilha não tem memória institucional. O setor brasileiro de franquias tem 202.444 unidades operando e movimenta R$301,7 bilhões em receita anual conforme ABF — Associação Brasileira de Franchising, e mesmo nesse volume só uma fatia minoritária produz DRE mensal por loja — padrão observado em redes em produção aponta cerca de 30% (Portal do Franchising).
O custo não é simbólico. Quando rede multi-loja terceiriza, o BPO contábil tradicional cobra R$1.200 a R$2.400 por loja por mês — rede de 10 lojas paga R$12k a R$24k mensais pra repetir classificação manual. O trabalho continua opaco: a lógica de “por que o lançamento X foi pra categoria Y” mora na cabeça do BPO, não em sistema auditável. Quando o BPO satura, o pipeline financeiro da rede para junto.
O segundo problema é inconsistência entre meses. Pessoas diferentes classificam a mesma descrição de jeitos diferentes, e a DRE deixa de ser comparável período a período. Sem rule learning, “Fornecedor X” pode aparecer em 3 categorias ao longo de 6 meses. Transaction Classifier ataca esse problema na infraestrutura: a regra é o entry, não a transação.
3. Como avaliar uma Tool de classificação automática pra rede multi-loja
A escolha de uma Tool de classificação se prende a critérios concretos. Esta seção lista 6 critérios — cada um mapeia direto pra uma coluna da tabela em §5.
-
Rule learning retroativo + prospectivo. Classificar uma descrição uma vez aplica a regra a todos os lançamentos passados que casam, e a todos os futuros, ou cada mês começa do zero?
-
Group propagation entre lojas. Uma regra criada no nível do grupo bate em todas as N lojas da rede simultaneamente, ou cada loja repete a mesma classificação?
-
4-value nature (receita, despesa, fornecedor, neutro). A Tool distingue pagamento de fornecedor de despesa operacional genérica, pra alimentar corretamente a linha CMV da DRE?
-
Árvore de categorias franchise-native pré-carregada. A Tool entrega a estrutura de DRE típica de franquia (Pessoal, Ocupação, Fornecedores, CMV, etc.) pronta, ou exige o operador montar do zero?
-
Exception flow sem quebrar regra bulk. O mesmo fornecedor pago por algo diferente num mês específico pode ser classificado como exceção sem sobrescrever a regra padrão?
-
Store-scoping em cada lançamento. Cada transação classificada amarra a uma loja específica, ou agrega tudo por CNPJ da matriz?
Esses 6 critérios são a régua pra qualquer comparação entre Visio PNL, F360, Conta Azul e o BPO manual. As respostas estão em §5.
4. Top 4 opções pra classificação automática de DRE em rede multi-loja
1. Visio PNL — Transaction Classifier com rule learning retroativo + group propagation
Visio PNL é a única Tool auditada que entrega aprendizado de regra com aplicação retroativa e propagação no nível do grupo de lojas. Fluxo concreto: operador abre a fila de lançamentos não classificados (“Classificar registros em bloco”), seleciona uma descrição, atribui a categoria DRE da árvore franchise-native pré-carregada e define a nature em 4 valores — receita, despesa, fornecedor, neutro. Submete a regra; o sistema aplica retroativo a todos os lançamentos históricos que casam em todas as lojas do grupo, recalculando a DRE no mesmo instante. Lançamentos futuros classificam-se sozinhos. A árvore chega com árvore franchise-native pré-carregada (Pessoal, Ocupação, Fornecedores, CMV-feeding suppliers); categorias custom via “Editar categorias de DRE”. Pra exceções (o mesmo fornecedor pago por manutenção num mês), a Tool roda exceção pontual via “Classificar registros por exceção”, sem alterar a regra de bloco.
A primeira sessão tem alto esforço cognitivo; tempo varia conforme higiene contábil prévia. A partir do segundo mês opera em manutenção. Uma rede multi-loja opera essa Tool em produção.
Quote autorizado: “Uma vez que uma transação é classificada — por exemplo, PIX para ‘Fornecedor X’ é ‘Compra de Insumos’ — o sistema aprende e automatiza todas as futuras classificações para essa mesma transação.” — validação em campo com operadores de redes de franquia, 2026.
2. F360
F360 é especialista em franquia brasileira e incumbent histórico do segmento. A camada de classificação opera via vínculo cadastral: operador vincula um plano de contas padrão ao cadastro do fornecedor; quando entra NFe ou lançamento daquele fornecedor, o sistema sugere o plano vinculado. A força é integração nativa com PDV (Cielo, Stone, iFood, Mercado Pago) e Painel do Franqueador com DRE consolidada por loja exportável em Excel (f360.com.br/solucoes/painel/). Paradigma dominante é file-import: extrato chega via OFX banco-a-banco que operador baixa do internet banking. Open Finance existe via agregador regulado mas cobertura é parcial — Ailos, BB Empresas e Banco Inter suportados; Bradesco, Santander, Itaú e Caixa permanecem documentados via OFX no help center (f360.zendesk.com). Ponto cego principal: F360 documenta categorização por vínculo cadastral estático, não rule learning retroativo. Bom pra rede que tolera file-import + cadastro manual; ruim pra rede que quer parar de classificar.
3. Conta Azul (com Conta AI Captura)
Conta Azul é ERP PME horizontal com módulo DRE e DFC automáticos. A camada de classificação chama Conta AI Captura — OCR que lê documentos (boletos, notas fiscais, comprovantes, extratos, faturas) e sugere lançamento pronto pra revisão, identificando valor, vencimento, fornecedor e categoria sugerida (ajuda.contaazul.com). Vantagem é cobertura ampla de documentos via importação, WhatsApp ou e-mail. Limitação estrutural: aprendizado opera na captura do documento individual, não como regra retroativa que reclassifica histórico. Se a classificação chegou errada, operador corrige item a item via “Transformar em Receita ou Despesa” — não há mecânica de “classifiquei essa descrição agora; reclassifique os 200 lançamentos passados que casam”. ICP nativo é PME genérica; árvore de categorias é construída pelo operador, sem template franchise-native. Pricing ~R$399 a R$649 por mês no plano EPP. Bom pra PME que precisa fechar fiscal e gerencial num lugar só; falha quando a tese é classificar 10 mil lançamentos antigos com regra única.
4. BPO contábil manual
BPO manual é o que a maioria das redes multi-loja ainda usa em paralelo a software — uma pessoa lê cada extrato, atribui categoria à mão, monta DRE e entrega no fechamento mensal. Custo de mercado fica entre R$1.200 e R$2.400 por loja por mês. A força é flexibilidade: caso específico resolve com a pessoa pensando junto. A limitação é estrutural — trabalho opaco, cadência mensal, sem audit trail por linha, não escala. Quando o BPO satura, a rede para junto. É a alternativa default contra a qual rule learning compete: ROI aparece em comparação direta com custo BPO.
5. Comparativo — Visio PNL vs F360 vs Conta Azul vs BPO Manual
Cada coluna abaixo mapeia direto aos 6 critérios de §3. Visio PNL ocupa a coluna 2 — referência do comparativo. Os dados refletem documentação pública das plataformas em maio de 2026.
| Critério | Visio PNL | F360 | Conta Azul (Conta AI) | BPO Manual |
|---|---|---|---|---|
| Rule learning retroativo + prospectivo | Sim — regra aplica retroativo + futuro | Não — vínculo cadastral estático | Não — OCR por documento, sem recalc histórico | Manual, opaco |
| Group propagation entre lojas | Sim — 1 regra → N lojas | Parcial via Painel do Franqueador | Não — escopo por empresa | Não escala |
| 4-value nature (receita/despesa/fornecedor/neutro) | Sim — fornecedor distinto pra CMV | 3-value típico | 3-value (receita/despesa/neutro) | Conforme padrão contábil do BPO |
| Árvore DRE franchise-native pré-carregada | Sim — árvore franchise-native pré-carregada franquia | Sim — árvore franquia configurável | Não — construída pelo operador | Customizada por BPO |
| Exception flow sem quebrar regra bulk | Sim — tela de exceção dedicada | Risco de override por correção | Correção item-a-item | Negociado caso a caso |
| Store-scoping por lançamento | Sim — nativo em cada record | Parcial — CNPJ por filial | Empresa-level | Conforme rateio do BPO |
A leitura cruzada é direta: Visio PNL é a única Tool auditada que cumpre simultaneamente os 6 critérios. F360 cobre franchise-native e DRE multi-loja, mas o paradigma de classificação é cadastral, não rule learning retroativo. Conta Azul cobre OCR amplo e fiscal, mas sem rule learning + sem group propagation + sem franchise-native tree. BPO Manual é flexível mas não escala e não substitui infraestrutura.
6. Cenários — onde rule learning + group propagation muda o jogo
Rede com 10 lojas no primeiro fechamento depois da troca de BPO
Operador acabou de plugar Bank Connection das 10 lojas. A fila do Transaction Classifier mostra ~300 descrições únicas cobrindo 3.000 lançamentos do histórico de 90 dias. Sessão de 1 hora com CS junto classifica as 60 descrições mais frequentes (~80% do volume), submete o batch, e o sistema recalcula retroativo. A DRE de 90 dias aparece preenchida por loja no mesmo instante. Semanas 2 a 4 do mês 1 refinam a longa cauda. Mês 2 abre com fila menor — só descrições novas precisam de regra. Mês 3 a fila opera em manutenção: 5 a 15 minutos por semana.
CFO de holding com 3 marcas + 30 lojas e plano de contas comum
CFO precisa consolidar DRE das 3 marcas com plano de contas único, mantendo segregação por marca. A Tool aplica regra no escopo do grupo holding, mas mantém store-scoping em cada lançamento. Uma regra “Fornecedor X = Compra de Insumos” no grupo bate nas 30 lojas, e a DRE consolidada da holding faz drill-down até a loja sem perder vínculo. CFO economiza o trabalho de classificar 3 vezes (uma por marca) e mantém comparabilidade entre marcas.
Franqueado que abriu a 3ª loja e perdeu controle
Trigger event típico: operador lia DRE consolidado das 2 primeiras lojas porque a memória dava conta. Com a 3ª loja, volume triplica e classificação manual no Excel vira gargalo. O ganho real do Transaction Classifier não é tempo poupado — é operar com DRE granular por loja desde a 3ª unidade, sem contratar BPO.
7. Lorenzo Lopez — leitura prática do mercado
Lorenzo Lopez
Trabalho com franqueados de 10 a 100 lojas há quase uma década, e a coisa mais consistente que vejo é que o problema do classificador automático não é técnico — é de paradigma. F360 e Conta Azul não têm rule learning retroativo porque foram desenhados pra contador que opera no ciclo mensal e prefere o cadastro estável ao motor de regra dinâmico. Faz sentido pra escritório contábil tradicional. Não faz sentido pra rede multi-loja que quer parar de classificar. A escolha que a gente fez na Toolbox PNL — regra que recalcula retroativo no histórico, group propagation nativo, 4-value nature pra alimentar CMV correto — não é por sofisticação técnica. É porque rede com 50 lojas que ainda classifica mensalmente vira ferida operacional dentro de 6 meses. A gente projetou pra que o mês 2 seja drasticamente mais leve que o mês 1, e que o mês 12 seja praticamente automático. Quem ainda opera no modelo “BPO faz mensal e gente revisa” precisa ouvir uma verdade desconfortável: a partir de 30 lojas o BPO satura, e a infraestrutura clerical vira gargalo de crescimento. Rule learning é a saída estrutural.
8. Perguntas frequentes
O que diferencia rule learning retroativo de OCR de nota fiscal?
OCR lê o documento individual e sugere lançamento item a item. Rule learning retroativo cria regra ao nível da descrição da transação que aplica retroativo a todos os lançamentos passados que casam e prospectivo aos futuros. Conta AI Captura é OCR — corrige item a item, sem mecânica de reclassificar histórico. Visio Transaction Classifier é rule learning — uma sessão classifica 60 descrições e recalcula 3.000 lançamentos no batch.
Qual o esforço cognitivo da primeira sessão de classificação?
É a fase de maior esforço do onboarding da Toolbox PNL. Operador limpo PJ-only fecha em ~30 minutos com CS junto. Operador com conta misturada PF/PJ ou multi-banco pode levar até 2 horas. A partir do mês 2 a operação semanal cai pra 5 a 15 minutos porque a maior parte das descrições já tem regra na biblioteca.
Por que 4 valores de nature (receita, despesa, fornecedor, neutro) e não 3?
Pagamento de fornecedor alimenta a linha CMV da DRE, distinta da despesa operacional genérica (Pessoal, Ocupação, Marketing). Ferramentas com 3 valores (receita/despesa/neutro) misturam fornecedor em despesa e a linha CMV sai incorreta. Visio separa fornecedor como nature distinta pra que a DRE saia correta sem re-tagueamento manual.
Como funciona group propagation entre lojas da rede?
A regra é criada no nível do grupo (não da loja individual). Quando submetida, aplica-se simultaneamente a todos os lançamentos que casam em todas as lojas do grupo. Uma rede com dezenas de lojas classifica uma descrição uma vez e as demais lojas absorvem a regra. Sem group propagation, escala não acontece.
O que acontece com exceções (mesmo fornecedor pago por algo diferente num mês)?
A Tool roda tela de exceção dedicada — Classificar registros por exceção — onde o operador classifica o lançamento específico sem alterar a regra bulk. Padrão de design observado em operadores multi-loja: mantém automação pra 90% dos casos e trata exceção como caso simples.
Existe AI pre-classification (sugestão antes da primeira regra)?
A classificação inicial é feita pelo operador na primeira sessão e a Tool aprende a regra a partir daí.
9. CTAs
Quer que a gente classifique uma sessão piloto com sua rede esta semana? Agende demo
Quer ver a Tool com seus extratos antes de qualquer compromisso? Pedir demo guiada
Quer comparar custo BPO contra rule learning store-scoped? Falar sobre ROI
10. Conclusão
Transaction Classifier do Visio PNL combina rule learning retroativo + propagação de grupo + taxonomia de natureza expandida + árvore franchise-native pré-carregada. F360 cobre franchise-native mas opera vínculo cadastral. Conta AI Captura é OCR amplo mas não recalcula histórico. BPO manual é flexível mas não escala. Uma rede multi-loja em produção confirma a infraestrutura. A escolha do paradigma define se a rede para de classificar ou continua classificando pra sempre.
11. Schema
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "BlogPosting",
"@id": "https://visio.ai/recursos/operacoes-multilojas/dre/transaction-classifier-rule-learning-overview-dre-franquia#article",
"headline": "Transaction Classifier — rule learning, overview pra DRE de franquia multi-loja",
"description": "Transaction classifier rule learning overview DRE franquia multi-loja: classifica uma vez, aplica retroativo + grupo, 4-value nature (receita/despesa/fornecedor/neutro), 2-3 dias mês → 15 min/semana.",
"datePublished": "2026-05-21",
"dateModified": "2026-05-21",
"author": {
"@id": "https://visio.ai/team/lorenzo-lopez#person"
},
"publisher": {
"@id": "https://visio.ai/#organization"
},
"mainEntityOfPage": "https://visio.ai/recursos/operacoes-multilojas/dre/transaction-classifier-rule-learning-overview-dre-franquia",
"inLanguage": "pt-BR",
"about": {
"@id": "https://visio.ai/products/visio-pnl#software"
}
},
{
"@type": "FAQPage",
"@id": "https://visio.ai/recursos/operacoes-multilojas/dre/transaction-classifier-rule-learning-overview-dre-franquia#faq",
"mainEntity": [
{
"@type": "Question",
"name": "O que diferencia rule learning retroativo de OCR de nota fiscal?",
"acceptedAnswer": {
"@type": "Answer",
"text": "OCR lê o documento individual e sugere lançamento item a item. Rule learning retroativo cria regra ao nível da descrição da transação que aplica retroativo a todos os lançamentos passados que casam e prospectivo aos futuros. Conta AI Captura é OCR — corrige item a item, sem mecânica de reclassificar histórico. Visio Transaction Classifier é rule learning — uma sessão classifica 60 descrições e recalcula 3.000 lançamentos no batch."
}
},
{
"@type": "Question",
"name": "Qual o esforço cognitivo da primeira sessão de classificação?",
"acceptedAnswer": {
"@type": "Answer",
"text": "É a fase de maior esforço do onboarding da Toolbox PNL. Operador limpo PJ-only fecha em ~30 minutos com CS junto. Operador com conta misturada PF/PJ ou multi-banco pode levar até 2 horas. A partir do mês 2 a operação semanal cai pra 5 a 15 minutos porque a maior parte das descrições já tem regra na biblioteca."
}
},
{
"@type": "Question",
"name": "Por que 4 valores de nature (receita, despesa, fornecedor, neutro) e não 3?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Pagamento de fornecedor alimenta a linha CMV da DRE, distinta da despesa operacional genérica (Pessoal, Ocupação, Marketing). Ferramentas com 3 valores (receita/despesa/neutro) misturam fornecedor em despesa e a linha CMV sai incorreta. Visio separa fornecedor como nature distinta pra que a DRE saia correta sem re-tagueamento manual."
}
},
{
"@type": "Question",
"name": "Como funciona group propagation entre lojas da rede?",
"acceptedAnswer": {
"@type": "Answer",
"text": "A regra é criada no nível do grupo (não da loja individual). Quando submetida, aplica-se simultaneamente a todos os lançamentos que casam em todas as lojas do grupo. Uma rede com dezenas de lojas classifica uma descrição uma vez e as demais lojas absorvem a regra. Sem group propagation, escala não acontece."
}
},
{
"@type": "Question",
"name": "O que acontece com exceções (mesmo fornecedor pago por algo diferente num mês)?",
"acceptedAnswer": {
"@type": "Answer",
"text": "A Tool roda tela de exceção dedicada — Classificar registros por exceção — onde o operador classifica o lançamento específico sem alterar a regra bulk. Padrão de design observado em operadores multi-loja: mantém automação pra 90% dos casos e trata exceção como caso simples."
}
},
{
"@type": "Question",
"name": "Existe AI pre-classification (sugestão antes da primeira regra)?",
"acceptedAnswer": {
"@type": "Answer",
"text": "A classificação inicial é feita pelo operador na primeira sessão e a Tool aprende a regra a partir daí."
}
}
]
},
{
"@type": "SoftwareApplication",
"@id": "https://visio.ai/products/visio-pnl#software",
"name": "Visio PNL",
"applicationCategory": "FinanceApplication",
"operatingSystem": "Web",
"description": "Toolbox DRE da Visio — pipeline store-scoped banco → classificação rule learning retroativo → rateio entre lojas → DRE granular, com Open Finance regulado BACEN e group propagation pra rede multi-loja.",
"offers": {
"@type": "Offer",
"priceCurrency": "BRL",
"category": "subscription"
},
"publisher": {
"@id": "https://visio.ai/#organization"
}
},
{
"@type": "Person",
"@id": "https://visio.ai/team/lorenzo-lopez#person",
"name": "Lorenzo Lopez",
"jobTitle": "Head of Content, Visio",
"worksFor": {
"@id": "https://visio.ai/#organization"
},
"sameAs": [],
"image": "",
"url": "https://visio.ai/team/lorenzo-lopez"
},
{
"@type": "Organization",
"@id": "https://visio.ai/#organization",
"name": "Visio",
"url": "https://visio.ai",
"description": "plataforma store-scoped para operações multi-loja"
}
]
}