Padrões de UI para telas de reconciliação que ajudam equipes de operações financeiras a identificar discrepâncias, revisar evidências, aplicar correções controladas e manter uma trilha de auditoria limpa.
Uma tela de reconciliação existe para responder a uma questão prática: quando duas fontes discordam, qual é a verdade que vamos reportar e operar?
Normalmente você compara uma “fonte” (feed bancário, processador de pagamentos, POS, sub-livro-razão, sistema de estoque) com o seu “livro de registro” (frequentemente o razão geral). A tela não é apenas uma vista comparativa. É o lugar onde decisões são tomadas e registradas.
As discrepâncias acontecem por motivos simples — e isso é uma boa notícia, porque a interface pode antecipá-las. Você verá diferenças causadas por atrasos de contabilização, itens faltantes, duplicatas, problemas de mapeamento (conta errada, cliente, moeda) e correspondências parciais em que um registro de um lado equivale a vários do outro.
O trabalho do usuário em uma boa configuração de padrões de UI para tela de reconciliação é mover cada exceção de “incerto” para “resolvido” sem adivinhar. Esse trabalho normalmente se divide em algumas ações repetíveis:
O maior risco não é um casamento incorreto. É uma mudança silenciosa. Se a tela permite que as pessoas editem valores sem mostrar o que mudou, quem mudou e quais registros foram afetados, você perde confiança e ganha retrabalho em auditorias.
Projete a tela para que cada resolução produza um resultado rastreável: valores antes/depois, registros de origem vinculados, carimbo de data/hora, usuário e código de motivo. Se são necessárias aprovações, a UI deve deixar o estado “precisa de aprovação” óbvio para que o trabalho não desapareça em uma zona cinzenta.
Se você for construir isso em uma ferramenta como AppMaster, trate a trilha de auditoria como um modelo de dados de primeira classe, não como um apêndice. Seu fechamento de mês futuro vai agradecer.
Uma tela de reconciliação funciona melhor quando parece um checklist calmo, mesmo com dados bagunçados. A maneira mais simples de chegar lá é um layout claro em três partes: Resumo no topo, uma fila de trabalho à esquerda (ou centro) e Detalhes à direita.
O Resumo é sua resposta para “estamos perto?”. Mostre totais de cada lado (quantidade e valor), depois o delta em ambas as unidades. As pessoas devem ver de relance se estão com 3 itens, $124,18 ou ambos. Se puder, inclua uma pequena tendência como “delta melhorou desde o último salvamento” para que os revisores saibam que o trabalho está fazendo diferença.
A fila de trabalho é onde mora a escala. Mantenha busca e filtros sempre visíveis para que os usuários não precisem abrir painéis extras para tarefas básicas. Uma lista simples em linhas com um chip de status (Novo, Em revisão, Corrigido, Precisa de aprovação) costuma ser suficiente.
Aqui está uma estrutura limpa usada em muitos padrões de UI para telas de reconciliação:
Padronize para a menor janela de tempo útil. Por exemplo, comece com os últimos 7 dias para que a fila seja curta e rápida, depois deixe os usuários expandirem com um clique quando precisarem do mês completo. Isso reduz ruído e ajuda revisores novos a ganhar confiança.
Se estiver construindo isso em uma ferramenta como AppMaster, mantenha o layout consistente entre web e mobile: as mesmas três zonas, apenas empilhadas em telas menores, para que treinamento e memória muscular se transfiram.
Uma boa vista de discrepância responde três perguntas em segundos: o que está errado, quão grave é e o que devo fazer em seguida. Se a tela fizer as pessoas abrirem três modais só para entender uma diferença, elas hesitarão, adivinharão ou deixarão notas para depois.
Comece usando um conjunto pequeno e consistente de tipos de discrepância em todo o produto. Essa consistência importa mais que a palavra perfeita, porque os revisores criam memória muscular. A maioria das equipes cobre 90% dos casos com quatro rótulos: item faltante, item extra, valor difere e data difere. Coloque o tipo no início da linha para que as pessoas não precisem procurar.
A severidade deve ser óbvia, mas comedida. Prefira rótulos simples como “Alta”, “Média”, “Baixa” (ou “Bloqueia fechamento”, “Precisa revisão”, “Para informação”) com cor contida. Use cor como pista, não como a mensagem. Reserve vermelho forte para casos que realmente impedem o fechamento do período e mantenha o restante neutro.
Os revisores também precisam do “porquê”, mas não em jargão interno. Mostre uma linha curta de motivo que referencia o que o sistema encontrou, como “Casado por referência, valor difere” ou “Nenhuma entrada no razão encontrada para a transação bancária”. Se regras estão envolvidas, mostre o nome da regra só se ajudar, e inclua as diferenças-chave dos campos em termos humanos.
Mantenha valores brutos e normalizados visíveis juntos. Normalização (arredondamento, conversão de moeda, remoção de espaços, mudanças de fuso) é comum, e escondê-la gera desconfiança. Um layout prático é uma comparação em duas colunas dentro de cada linha de discrepância:
Se estiver construindo isso com uma ferramenta como AppMaster, modele o tipo de discrepância e a severidade como enums na camada de dados, para que listas, filtros e painéis de detalhe se mantenham consistentes no fluxo de revisão.
Quando o volume é alto, uma fila de reconciliação precisa se comportar mais como uma caixa de entrada do que um relatório. As pessoas devem entender cada linha em um segundo, decidir o próximo passo e continuar sem perder contexto.
Comece com colunas que respondam “o que é” antes de “o que significa”. Se possível, mantenha a primeira tela com o essencial e empurre detalhes para um painel lateral.
A ordenação deve corresponder ao pensamento dos revisores. Um bom padrão é “maior delta primeiro”, porque traz o maior risco rapidamente. Adicione toggles rápidos para mais recentes, pendentes mais antigos e “tocados recentemente” para facilitar handoffs.
Visualizações salvas são o que fazem uma fila escalar entre papéis. Um analista pode querer “aberto + auto-match falhou”, um aprovador pode querer “aguardando aprovação apenas” e um auditor pode querer “resolvido neste período com edições manuais”. Mantenha as views óbvias e com nomes em linguagem simples para que as pessoas não criem suas próprias planilhas.
Seleção em massa pode economizar muito tempo, mas só se tiver guardrails. Deixe os limites claros (por exemplo, máximo 50 itens), mostre quais campos vão mudar e avise quando ações são irreversíveis. Uma etapa de pré-visualização simples evita erros em massa.
Indicadores de progresso mantêm a equipe alinhada. Mostre contagens por estado no topo e torne-as filtros clicáveis. Melhor ainda, mostre propriedade (não atribuído vs atribuído a mim) para que o trabalho não seja duplicado.
Esses padrões são diretos de construir com uma ferramenta visual como AppMaster: uma tabela de fila, filtros salvos por função e chips de status dão velocidade às equipes financeiras sem sacrificar controle.
Um bom fluxo de reconciliação trata menos de visuais chamativos e mais de evitar que as pessoas fiquem pulando pela tela. O objetivo é simples: guiar o revisor de “O que mudou?” para “O que fizemos sobre isso?” sem perder contexto.
Comece tornando o Passo 1 inevitável: escolher um período de reconciliação e as fontes de dados exatas. Coloque esses controles no topo da página e mantenha-os visíveis após a seleção (período, fonte A, fonte B, última atualização). A maioria do retrabalho ocorre quando alguém revisa discrepâncias contra um pull errado.
O Passo 2 é a varredura de 30 segundos. Mostre o delta total, a contagem de itens não reconciliados e as principais categorias de discrepância (transação faltante, diferença de valor, deslocamento de data, duplicata). Cada categoria deve ser clicável para filtrar a lista de trabalho.
O Passo 3 é onde a velocidade importa: abra um item e compare campos lado a lado. Mantenha os campos-chave alinhados (valor, data, referência, contraparte, moeda, conta) e mostre evidências ali mesmo: linha de importação bruta, lançamento no razão e quaisquer documentos anexados. Evite esconder evidências atrás de abas extras.
O Passo 4 é o ponto de decisão. A UI deve apresentar um pequeno conjunto de ações com resultados claros:
O Passo 5 é responsabilidade. Exija uma nota curta para qualquer coisa além de um casamento limpo, e dispare aprovação apenas quando as regras demandarem (por exemplo, baixas acima de um limite ou qualquer ajuste em um sub-livro fechado). Mostre quem aprovará antes do revisor submeter, para que não haja suposições.
O Passo 6 fecha o ciclo. Após o envio, confirme o que mudou (“Casado ao Lançamento #48321”, “Ajuste rascunhado”) e exiba imediatamente a entrada de auditoria: carimbo de data/hora, usuário, ação, campos antes/depois e status de aprovação. Um revisor nunca deve duvidar se o clique foi aplicado.
Correções são onde aparecem erros e riscos de fraude, então a UI deve tornar as ações mais seguras as mais fáceis. Uma boa regra: deixe as pessoas avançarem sem alterar saldos primeiro, e exija mais confirmação quando elas forem alterar valores.
Comece com ações “seguras” que não alteram saldos. Elas reduzem idas e vindas e mantêm decisões visíveis:
Quando for necessário criar um ajuste, use um formulário guiado em vez de um campo livre. O formulário deve dificultar esquecer o básico e facilitar revisão posterior. Aqui também é onde você evita “correções rápidas” que geram problemas maiores no fechamento.
Mantenha ações destrutivas protegidas por permissões e confirmação clara. Por exemplo, “Excluir ajuste” deve ser raro, baseado em função e exigir motivo. Prefira ações que criem um novo registro ao invés de editar o histórico.
A validação deve ocorrer antes de salvar, e a mensagem deve explicar como corrigir. Uma checklist simples funciona bem:
Deixe o comportamento de desfazer explícito. Os usuários devem saber se podem reabrir o item, reverter o ajuste ou criar um contralançamento. Exemplo: um revisor vincula a linha bancária errada e percebe que o match pertence a outro pagamento. Um claro “Desvincular” (com nota) é mais seguro do que editar a transação original, preservando a história do que aconteceu e por quê.
Uma trilha de auditoria só ajuda se responder rápido: quem mexeu no item, o que mudou e por quê. O truque é torná-la visível quando necessário, mas sem bloquear o fluxo normal de revisão.
Adicione uma linha do tempo compacta no painel de detalhes do item. Cada entrada deve mostrar o ator, carimbo de data/hora, ação e um resumo curto da mudança. Mantenha legível e consistente para que revisores identifiquem o último evento relevante (como “valor corrigido” ou “aprovado”) de relance.
Quando um campo é corrigido, armazene e exiba tanto o valor antes quanto o depois. Mostre-os inline na entrada da linha do tempo (por exemplo: “Valor bancário: 1.250,00 -> 1.205,00”), e também no histórico do campo se alguém abrir “Detalhes da alteração”. Isso evita o erro comum de guardar apenas o valor final.
Para ações de maior risco (dar baixa, override manual, force match), exija um motivo. Use um dropdown curto mais uma nota opcional, assim o revisor avança rápido mas deixa uma explicação clara.
Maker-checker funciona melhor quando é baseado em estados, não em mensagens. Use estados simples como Rascunho, Enviado, Precisa de info, Aprovado, Rejeitado, Escalado, e mostre o estado atual perto do título do item. Mantenha a UI de aprovações enxuta:
Por fim, mantenha evidências anexadas ao próprio item de reconciliação: uploads de arquivos, referências de e-mail ou chat, IDs externos e notas. Um revisor não deve caçar em outros sistemas para justificar uma decisão. Em ferramentas como AppMaster, isso mapeia bem para um registro “Reconciliation Item” com “Evidences” e “Approval Events” relacionados, mantendo a UI simples e os dados completos.
A maioria das telas de reconciliação funciona até que os dados reais apareçam. Os pontos de ruptura são previsíveis, então vale a pena projetar para eles cedo.
Correspondências parciais são a primeira armadilha. Uma tabela limpa um-para-um desmorona quando uma transferência bancária paga três faturas, ou cinco liquidações de cartão se consolidam em um lançamento no razão. Trate esses casos como cidadãos de primeira classe: deixe revisores criar um agrupamento com total visível, um indicador de “valor não alocado” e um rótulo claro (por exemplo, “3 itens -> 1 lançamento”). Permita expandir o grupo para confirmar as partes sem perder o resumo.
Duplicatas são a segunda armadilha. As pessoas muitas vezes “consertam” duplicatas casando itens errados. Adicione dicas suaves como “possível duplicata” com base em valor, janela de datas e contraparte, mas mantenha seguro: o revisor deve abrir uma vista comparativa, escolher o registro correto e marcar o outro como duplicata com um motivo. Se oferecer mesclagem, torne-a reversível e sempre preserve os IDs originais.
Diferenças de moeda e arredondamento são comuns e não devem parecer erros. Mostre o cálculo exato (cotação, taxa, arredondamento) e permita limites configuráveis (por moeda, conta ou tipo de transação). A UI deve indicar “dentro da tolerância” vs “precisa ação”, não apenas “casado/não casado”.
Lançamentos tardios confundem o fechamento de período. Quando um item se resolve após o fechamento, não reescreva a história. Mostre como “resolvido após fechamento” com a data de resolução e exija nota ou aprovação se alterar o número de um período fechado.
Por fim, quedas e feeds faltantes acontecem. Adicione status que facilitem revisitar:
Se construir isso em AppMaster, modele esses estados no Data Designer e force transições permitidas no Business Process Editor, assim o tratamento de edge cases permanece consistente e auditável.
É fim de mês. Seu extrato bancário mostra R$248.930,12 em atividade para abril, mas seu razão interno totaliza R$249.105,12. A tela de reconciliação abre com um Resumo que responde três perguntas rapidamente: quantos itens batem, quantos estão em discrepância e quanto ainda está sem resolver.
No painel de Resumo, o usuário vê: 1.284 itens casados, 3 discrepâncias e uma diferença não resolvida de R$175,00. Um pequeno aviso mostra “2 itens precisam de ação” porque uma discrepância é apenas informativa.
A tabela de discrepâncias agrupa problemas por tipo e deixa o próximo passo óbvio:
Quando o usuário clica em uma linha, os Detalhes do Item abrem à direita. Para a tarifa de R$25,00, os Detalhes mostram a linha bancária (data, descrição, valor) ao lado do lado do razão (nenhuma entrada correspondente encontrada) mais uma correção sugerida: “Criar lançamento de despesa: Tarifas bancárias.” O usuário seleciona o motivo de correção, adiciona uma nota e anexa a linha do extrato como evidência.
Para os R$150,00 do pagamento duplicado, os Detalhes mostram dois lançamentos do razão casados a um pagamento bancário. O usuário marca um lançamento como duplicado, escolhe “Estornar lançamento” e a tela cria um lançamento de estorno proposto. Como isso altera os livros, vai para aprovação: o status vira “Aguardando aprovação” e a discrepância deixa de contar como “Não revisada”.
O atraso de liquidação é diferente. O banco mostra um pagamento iniciado em 30 de abril, mas que liquida em 1º de maio. O usuário define o estado de resolução como “Diferença de timing”, escolhe a data esperada de liquidação e o item vai para “Carryover aberto” para o período seguinte.
Mais tarde, um auditor deve poder confirmar, sem adivinhar:
Fechar um período é onde pequenas falhas na UI viram grandes dores depois. Uma boa checklist de fechamento deve ser visível na tela, fácil de verificar e difícil de pular por acidente.
Comece pelos totais. Mostre tanto contagem quanto valor por fonte para o período e deixe óbvio qual número está impulsionando a discrepância (por exemplo, “3 itens, R$1.240,00” de cada lado). Se os totais batem mas as contagens não, destaque isso claramente para que os revisores não assumam que terminaram.
Antes do fechamento, toda exceção deve ter um status final e um motivo que alguém entenda semanas depois. “Resolvido” não é suficiente sem uma nota como “cobrança duplicada estornada” ou “diferença de timing, será limpa no próximo período”. Esse é um dos padrões que previne retrabalho repetido.
Use uma checklist pré-fechamento curta e bloqueie o fechamento se algum item falhar:
A checagem pontual é simples, mas poderosa. Abra cinco itens resolvidos aleatoriamente e verifique três coisas: a evidência (linha de extrato, recibo, log do sistema), a ação de correção (o que mudou) e a nota (por que foi válido). Se faltar algo, sua UI está ensinando um hábito errado.
Por fim, torne o período reproduzível. Ofereça um “snapshot” que congele totais-chave, status de exceções, notas e aprovações. No AppMaster, isso pode ser um registro “Period Close” gerado por um Business Process, para que a vista de auditoria corresponda ao que os revisores viram no fechamento.
Comece pelos dados, não pelo layout. Uma tela de reconciliação vira bagunça quando o sistema não consegue explicar claramente o que é um registro e como ele se relaciona a outros. Defina um pequeno modelo que você pode expandir: seus arquivos/feeds de origem, as transações individuais, os grupos de correspondência que conectam itens entre fontes e os ajustes que você cria para corrigir diferenças. Adicione campos necessários para revisão (valor, moeda, datas, texto de referência) além dos entediantes mas críticos (status, responsável, carimbos de data/hora).
Em seguida, trave permissões cedo. A maioria das equipes precisa de pelo menos três papéis: um analista que proponha matches e correções, um aprovador que valide ajustes e um auditor que veja tudo sem alterar. Se esperar demais com permissões, você acabará reconstruindo ações críticas (editar, desfazer, reabrir) quando a primeira revisão de controle aparecer.
Depois, prototipe as três superfícies que geram trabalho real:
Defina transições de status como regras, não hábitos. Por exemplo, um grupo não deve ir para “Reconciliado” a menos que a diferença restante seja zero (ou dentro de tolerância), todos os campos obrigatórios estejam presentes e as aprovações concluídas. Ainda permita exceções, mas force código de motivo e comentário para manter a trilha de auditoria limpa.
Para construir rápido, use uma plataforma sem código como AppMaster: modele o banco de dados em PostgreSQL no Data Designer, monte a fila e os painéis com o construtor de UI web e implemente regras de fluxo no editor visual Business Process. Mantenha a primeira versão estreita (um par de fontes, poucos status), teste com casos reais de fechamento e itere com base nas discrepâncias que sua equipe realmente encontra.
21 de jan. de 2026
8 min
20 de jan. de 20268 min
20 de jan. de 20268 minExperimente o AppMaster com plano gratuito.
Quando estiver pronto, você poderá escolher a assinatura adequada.
