Agente de reconciliação bancária: extratos em escala com IA

A reconciliação bancária é o processo mais automatizável da área financeira e um dos que com mais frequência continua a ser feito à mão. A razão não é a inexistência de software de correspondência — existe há décadas. A razão é que a maioria das implementações automatiza a maioria fácil, despeja o restante numa folha de cálculo e deixa uma pessoa a fazer os vinte por cento mais difíceis sem nenhum do contexto que tornava fáceis os outros oitenta por cento.

O resultado é um processo nominalmente automatizado e na prática ainda manual, porque é no resíduo que o tempo sempre se gastou. Uma equipa que reconcilia vários milhares de transações por mês pode fazer a correspondência automática da grande maioria e continuar a gastar dias no resto: pagamentos de um para muitos, liquidações parciais, transações com uma referência que não corresponde a nada no livro-razão, recebimentos em moeda estrangeira que chegaram líquidos de uma comissão que ninguém previu.

O trabalho de design com valor num agente de reconciliação não é, portanto, o motor de correspondência. É o tratamento das exceções: classificá-las, resolver as que são mecanicamente resolúveis e apresentar o restante, o genuinamente ambíguo, a uma pessoa com tudo o que é necessário para decidir em segundos e não em minutos.

Por que razão isto importa

A reconciliação bancária está no caminho crítico do fecho. Uma conta bancária não reconciliada significa que a tesouraria não pode ser confirmada, o que significa que o balanço não pode ser assinado, o que significa que nada a jusante pode ser concluído. Qualquer atraso aqui propaga-se por inteiro.

É também o controlo que deteta uma classe de problemas específica e séria. As saídas de tesouraria sem correspondência são a forma de descobrir apropriações indevidas. As entradas de tesouraria sem correspondência são a forma de descobrir recebimentos de clientes não aplicados — e os recebimentos não aplicados são a razão pela qual as equipas de cobranças perseguem faturas que, de facto, já estão pagas, o que prejudica a relação com o cliente e desperdiça tempo do controller. Uma reconciliação feita mensalmente encontra estas coisas com até trinta dias de atraso. Feita diariamente, encontra-as na manhã seguinte.

E é a condição que viabiliza a mudança mais ampla de um fecho periódico para um fecho contínuo. A reconciliação contínua só é sustentável se uma pessoa não estiver a rever cada correspondência — que é precisamente o que um agente torna possível.

Numa vista rápida: tipos de exceção e como devem ser tratados

Nos nossos projetos, o resíduo que exige genuinamente uma decisão humana estabiliza tipicamente abaixo dos dez por cento do volume de transações depois de o agente estar afinado durante alguns meses. Esse número é uma observação de quem está no terreno, resultante de implementações mid-market, e não um benchmark, e varia consideravelmente com a combinação de meios de pagamento: um negócio com tráfego intenso de liquidações transfronteiriças e de marketplace ficará acima disso.

O que funciona e sobre o que é preciso ser honesto

O que funciona:

Limiares de confiança em vez de regras binárias. Uma correspondência com 99% de confiança e uma correspondência com 70% devem ser tratadas de forma diferente: a primeira é registada, a segunda é apresentada a uma pessoa como sugestão, com o raciocínio à vista. Os sistemas que tratam a correspondência como aprovada ou reprovada ou registam erros automaticamente ou encaminham demasiado.

Aprender com as resoluções humanas. Quando um controller resolve uma exceção, essa resolução é dados de treino. Uma contraparte que paga sempre líquido de uma comissão fixa, ou que referencia ordens de compra em vez de faturas, devia precisar de explicação uma única vez. Os agentes que não incorporam o histórico de resoluções recriam a mesma exceção todos os meses para sempre.

Exceções apresentadas com contexto, não como uma lista. O ganho de produtividade no resíduo vem quase inteiramente da apresentação: a linha do banco, os candidatos a correspondência ordenados com o respetivo raciocínio, o histórico de pagamentos da contraparte, as partidas abertas relacionadas e a resolução com um clique. A mesma exceção leva quatro minutos numa folha de cálculo e vinte segundos numa fila bem concebida.

Execução diária. Um agente que reconcilia diariamente trabalha com um volume pequeno de exceções recentes, em que o contexto ainda é recuperável. A execução mensal produz um lote grande de exceções antigas. O trabalho é idêntico; a dificuldade não.

Regras determinísticas primeiro, inferência depois. Tudo o que for expressável como regra deve ser uma regra — auditável, testável, explicável. A inferência deve tratar aquilo que as regras não conseguem. Os sistemas construídos com a inferência à frente são mais difíceis de auditar e mais difíceis de merecer confiança.

Sobre o que é preciso ser honesto:

Os últimos pontos percentuais não serão automatizados, e persegui-los é um mau investimento. A partir de certo ponto, cada ponto percentual adicional de correspondência automática custa mais em configuração e acarreta mais risco do que os minutos humanos que poupa. Identifique onde essa curva se achata para a sua combinação de meios de pagamento e pare aí deliberadamente.

Os erros de correspondência automática são silenciosos. Uma correspondência errada não gera uma exceção — produz uma conta reconciliada com duas transações mal imputadas, e pode não vir à superfície durante meses. É por isso que os limiares devem ser conservadores no início e por isso que uma revisão por amostragem das partidas com correspondência automática deve manter-se em permanência, mesmo quando o agente está a funcionar bem.

A qualidade dos dados bancários varia mais do que se espera. O comprimento do campo de referência, o tratamento de caracteres, os formatos, se o nome da contraparte é ou não transmitido — isto difere de banco para banco e de esquema de pagamento para esquema de pagamento, e as diferenças determinam diretamente as taxas de correspondência alcançáveis. Um ambiente multibanco é um problema materialmente mais difícil do que um de banco único.

Vai trazer à superfície uma acumulação de recebimentos não aplicados. A maioria das empresas que faz este arranque descobre pagamentos de clientes que nunca foram aplicados a faturas, às vezes de anos atrás. Isso é um benefício, mas chega em forma de trabalho, e precisa de um responsável.

Os auditores vão perguntar como é que o agente decide. Tenha a resposta documentada antes de perguntarem: as regras, os limiares, a lógica, o rasto de auditoria, o procedimento de revisão por amostragem. Um agente cujas decisões não podem ser explicadas é uma reserva de auditoria, independentemente da exatidão.

Quadro de decisão: por onde começar

Percorra pela ordem. Pare na primeira correspondência.

1. Reconcilia mensalmente em vez de diariamente?
Passe primeiro para diário, mesmo manualmente, durante algumas semanas. Reduz de imediato a dificuldade das exceções e mostra-lhe o seu perfil real de exceções — que é o input de todas as decisões seguintes.

2. Tem ligações bancárias automáticas ou está a importar ficheiros manualmente?
Estabeleça ligações automáticas fiáveis antes de qualquer outra coisa. Um agente dependente de uma importação manual herda uma dependência manual e não funcionará sem supervisão.

3. Conhece o seu perfil de exceções por categoria?
Se não, registe um mês de exceções por tipo usando a tabela acima. A distribuição determina o que configurar e onde está o retorno. A maioria das equipas erra ao adivinhar o seu próprio perfil — as comissões transfronteiriças e as liquidações de um para muitos são sistematicamente subestimadas.

4. Tem uma acumulação de recebimentos não aplicados ou de partidas históricas não reconciliadas?
Limpe-a antes de arrancar. Um agente que trabalha contra um livro-razão com ruído histórico gera exceções para problemas que lhe são anteriores, e a fila torna-se inutilizável na primeira semana.

5. As suas regras de correspondência estão documentadas e são determinísticas onde o podem ser?
Escreva as regras de forma explícita, incluindo as tolerâncias para comissões e desvios cambiais. Isto é a substância da configuração e deve poder ser revisto pelo seu auditor.

6. Tudo o que está acima já está no lugar?
Arranque com limiares conservadores e revisão humana de todas as correspondências automáticas nas primeiras duas semanas, e depois aperte à medida que a evidência se acumula. Construa a fila de exceções com o contexto adequado desde o primeiro dia — não é uma fase dois.

7. A funcionar bem, mas a taxa de exceções continua alta?
Olhe a montante. Uma taxa de exceções persistentemente alta é habitualmente causada por algo fora da reconciliação: faturas sem referências estáveis, uma base de clientes que paga por extrato em vez de por fatura, ou uma configuração do ERP que não expõe as partidas abertas de forma útil.

Custo e esforço indicativos

Pressupõe uma a três contas bancárias em uma ou duas moedas com uma única instância de ERP. Ambientes multibanco e multimoeda com tráfego de liquidações de marketplace situam-se no topo do intervalo ou acima dele. Peça um orçamento para uma estimativa delimitada.

Perguntas frequentes

Que taxa de correspondência devemos esperar?
Depende muito mais da sua combinação de meios de pagamento e da qualidade dos dados bancários do que do agente. Um negócio B2B doméstico com referenciação disciplinada de faturas atinge uma taxa alta rapidamente. Um negócio transfronteiriço com liquidações de marketplace e muitos pagamentos parciais ficará mais abaixo e não deve tratar isso como um fracasso. Faça primeiro a perfilagem das suas exceções e defina o objetivo a partir da sua própria distribuição, e não a partir do número de um fornecedor.

O agente pode registar lançamentos contabilísticos por si próprio?
Para registos determinísticos e sujeitos a regras dentro de tolerâncias definidas — comissões bancárias, diferenças cambiais — sim, e deve fazê-lo. Para tudo o que exija juízo sobre a classificação, não. A fronteira deve estar escrita na política e ser mostrada ao seu auditor, não deixada à configuração.

Como evitamos que o agente esconda um problema fazendo-lhe correspondência automática?
Limiares conservadores, revisão por amostragem permanente das partidas com correspondência automática e um alerta para qualquer alteração invulgar de padrão nas taxas de correspondência. Uma melhoria súbita na correspondência automática merece tanta investigação como uma deterioração súbita.

Isto substitui o nosso controller?
Não, e as empresas que o implementam à espera disso ficam desapontadas duas vezes. Muda o que o controller faz: menos correspondência, mais investigação de exceções genuínas, mais tempo nos problemas de qualidade de contas a receber e contas a pagar que a reconciliação traz à superfície. Em equipas mid-market, o resultado habitual são os mesmos efetivos a tratar consideravelmente mais volume com um fecho mais curto.

Onde é que isto se situa em relação a encurtar o nosso fecho?
É tipicamente a intervenção técnica de maior retorno disponível, porque a reconciliação bancária está no caminho crítico e a sua automatização é bem compreendida. Não é suficiente por si só — a correspondência intercompanhias, a política de data de corte de contas a pagar e a propriedade dos dados fora da área financeira também têm de ser tratadas.

Fecho — Próximos passos

A medida de um agente de reconciliação não é a sua taxa de correspondência. É a rapidez com que uma pessoa consegue resolver o que o agente não conseguiu, e se o agente aprende com essa resolução. Duas implementações com desempenho de correspondência idêntico podem diferir num fator de várias vezes no tempo total consumido, inteiramente por causa do desenho das exceções.

Se quiser saber com o que está a lidar antes de se comprometer: registe um mês de exceções de reconciliação por categoria, com o tempo que cada uma levou a resolver. A distribuição dir-lhe-á o que automatizar, e a coluna do tempo dir-lhe-á se o seu problema é a taxa de correspondência ou o tratamento de exceções. Na maioria das empresas mid-market é o segundo.

Sobre o autor

Bruno Galo é o fundador da Atypical Tech, uma consultora NetSuite que serve clientes mid-market em toda a Ibéria. Especializa-se em ligar sistemas CRM e ERP para fluxos order-to-cash sem atritos, construindo pipelines automatizados de gestão de encomendas que eliminam a introdução manual de dados entre as equipas comerciais e financeiras. Como parceiro oficial de implementação Stacksync, Bruno concebe e implementa agentes de IA em plataformas de integração para tratar o encaminhamento de exceções, o processamento de documentos e a reconciliação — transformando fluxos de encomendas fragmentados em sistemas fiáveis e com automonitorização.

LinkedIn: https://www.linkedin.com/in/brunogd

Fontes

Os URL são a nível de editor e devem ser verificados antes da publicação.

• Oracle NetSuite, documentação de reconciliação bancária e de ligações bancárias — https://docs.oracle.com/en/cloud/saas/netsuite/
• European Payments Council, SEPA scheme rulebooks — informação de remessa e especificações dos campos de dados — https://www.europeanpaymentscouncil.eu
• ISO 20022, documentação da norma de mensagens de pagamento — dados de remessa estruturados — https://www.iso20022.org
• APQC, Open Standards Benchmarking — tempos de ciclo de contabilidade geral e de reporte — https://www.apqc.org
• Experiência de projetos da Atypical Tech, automatização financeira mid-market na Ibéria