Conciliação bancária em rede de restaurantes com 20+ unidades

Rede de restaurantes com 22 unidades em 3 estados. Cada unidade tem 2-3 adquirentes, Pix próprio, conta bancária da casa. Controller único tenta fechar mês 5-7 dias depois. Diretoria pede 2.

Conciliação multi-unidade é problema estrutural, não apenas operacional. Como atacar.

Por que rede de restaurantes é caso difícil

3 características complicam:

1. Multiplicação de fontes por unidade.

• 22 unidades × 3 adquirentes = 66 fluxos
• 22 contas correntes
• 22 Pix de loja
• Marketplace (iFood, Rappi) por unidade

Total: 130-150 fontes de transação por mês.

2. Operação descentralizada.

• Gerente de cada unidade negocia adquirente local
• Taxa contratada varia por unidade
• Antecipação pode estar configurada diferente

3. Volume alto + ticket baixo.

• Cada unidade processa 200-800 transações/dia
• Em 22 unidades: 4.000-17.000 transações/dia
• 100k+ transações/mês

Manualmente, inviável. Mas é o que muitas redes ainda fazem.

O setup de conciliação automatizada

Hardware:

• Nenhum específico. Roda em qualquer dispositivo.

Software:

• Motor de conciliação multi-fonte com IA
• Integração com Omie / Conta Azul / ERP da rede
• Coleta automática de extrato (API ou import periódico)

Pessoas:

• 1 controller (papel muda — vira analista de exceção, não digitador)
• 1 assistente (foca em casos divergentes e atendimento de unidade)

Tempo de implementação:

• Setup: 4-8 semanas
• Piloto em 3-5 unidades: 4-6 semanas
• Rollout pro restante: 8-12 semanas

A arquitetura

Camada 1: coleta automática.

Pra cada fonte:

• API oficial (Cielo, Stone, Pag, Mercado Pago, etc.)
• Importação de extrato periódico
• Conexão com banco via Open Banking

Camada 2: padronização.

Cada fonte tem formato diferente. Sistema:

• Lê extrato
• IA classifica cada linha (venda, estorno, taxa, antecipação, ajuste)
• Padroniza em estrutura única

Camada 3: casamento.

Pra cada transação:

• Sistema tenta casamento exato (valor + data + referência)
• Se exato: marca conciliado
• Se aproximado: IA propõe casamento provável, controller revisa
• Se divergente: vai pra fila de exceção

Camada 4: análise por unidade.

Dashboard por unidade:

• Total entrado vs total esperado
• Divergência por adquirente
• Outlier (taxa de antecipação fora do contratado)
• Gerência da unidade tem acesso ao próprio dado

Camada 5: consolidação.

DRE da rede:

• Soma de todas as unidades
• Drill-down até transação específica
• Exportação pro ERP

Fluxo diário típico

Manhã:

• Sistema processou extratos da madrugada
• Controller abre dashboard
• Lista priorizada: 20-50 casos divergentes do dia
• 1h de análise resolve 80%

Tarde:

• Restante de casos vai pra investigação (assistente liga pra unidade, adquirente)
• Cadastro corrige (taxa nova, condição mudada)
• Sistema aprende padrão

Sexta:

• Fechamento semanal por unidade
• Gerentes recebem relatório

Final do mês:

• Fechamento contábil: dias 1-2 do mês seguinte
• DRE pronto pra diretoria

Compare com modelo antigo: 5-7 dias úteis depois.

ROI esperado

Rede típica de 20-30 unidades:

Cenário antes:

• Controller + assistente em fechamento 5-7 dias
• Diferenças residuais aceitas ("é pequeno")
• Decisão estratégica com dado defasado
• Risco de fraude difícil de detectar

Cenário pós:

• Fechamento em 1-2 dias
• Diferenças investigadas e ajustadas
• Decisão estratégica com dado atualizado
• Fraude detectável (padrão anômalo é flag)

ROI: 6-12 meses dependendo do tamanho da rede.

Casos especiais em restaurante

Caso 1: comanda dividida em mesa.

• 4 pessoas comem, pagam separado. 4 transações.
• Sistema precisa entender que somou pra fechar a conta.

Caso 2: gorjeta antecipada vs taxa.

• Cliente paga 10% gorjeta no cartão
• Adquirente repassa pra empresa
• Empresa paga pro garçom
• Conciliação precisa segregar.

Caso 3: iFood/Rappi com split.

• Cliente paga R$ 80 no iFood
• iFood retém comissão (20-30%)
• Restaurante recebe líquido
• Conciliação precisa lembrar do bruto.

Caso 4: estorno de pedido errado.

• Cliente pagou, cancelou
• Adquirente faz estorno
• Sistema reconhece estorno

Cada caso desses confunde controller manual. Motor dedicado resolve com IA classificando.

Compliance fiscal

Rede de restaurantes tem 2 dimensões:

1. NFe/NFCe emitida.

• Cada venda gera NFCe
• Conciliação precisa cruzar venda do cartão com NFCe

2. Receita Federal.

• Apuração de Simples Nacional ou Lucro Presumido
• Dado de venda precisa estar correto

Conciliação automatizada alimenta o fiscal — dado limpo e estruturado.

O que NÃO funciona

• Manter manual em rede de 20+ unidades. Inviável.
• Comprar ERP "all-in-one" esperando que resolva. Módulo nativo não cobre complexidade multi-fonte.
• RPA copiando planilha. Frágil, vimos no post sobre RPA vs motor.
• Cada unidade conciliando próprio. Fragmentação, sem visão da rede.

Quando vale começar

Sinais consolidados:

• Rede com 10+ unidades
• Controller único processando todas
• Fechamento mensal saindo depois do dia 5
• Diferenças residuais cumulativas
• Plano de expandir rede

Quando 2+ presentes, motor dedicado vira ROI imediato.

Próximo passo

Motor de conciliação multi-fonte com IA + integração com ERP + dashboard por unidade é o caminho honesto pra rede de restaurantes fechar mês em prazo. A FELGOR Match implementa esse fluxo. Se quiser ver aplicado no contexto da sua rede, agende um diagnóstico de 30 minutos com os fundadores.