Por que somar dinheiro apaga sua origem

Todo saldo bancário é, por definição jurídica, fungível, e é exatamente essa propriedade, não uma falha de implementação, que impede qualquer sistema de contas de preservar a origem de um valor depois que ele foi somado a outro.

A afirmação parece técnica demais para importar, até se traduzir em consequência prática: nenhuma equipe de conciliação, nenhum sistema de auditoria e nenhuma quantidade de investimento em tecnologia consegue recuperar, depois do fato, uma informação que a própria definição legal do que é dinheiro já determinou que não precisava ser guardada. Vale entender por quê, com precisão, antes de assumir que é só uma questão de melhorar o processo.

O que a fungibilidade determina

O Código Civil resolve isso em uma linha: são fungíveis os bens móveis que podem substituir-se por outros da mesma espécie, qualidade e quantidade ([1]). Dinheiro é o exemplo canônico. Quem empresta cem reais não tem direito a receber de volta as mesmas cédulas, tem direito a receber cem reais, quaisquer que sejam as notas usadas para compor esse valor. A identidade da unidade específica é juridicamente irrelevante. O que importa é a quantidade.

Essa é uma escolha de design do sistema jurídico e econômico, feita muito antes de qualquer sistema de contabilidade digital existir, e ela existe por uma boa razão: fungibilidade é o que permite que dinheiro circule sem que cada transação precise verificar a procedência específica de cada unidade envolvida. Sem fungibilidade, comércio em qualquer escala seria impraticável.

Por que a soma apaga o que a soma não precisa saber

Um saldo bancário é a representação numérica de uma obrigação fungível. Quando dois créditos, de dez reais e de vinte reais, chegam à mesma conta, o sistema não precisa saber, e portanto não guarda, qual parte dos trinta reais resultantes veio de qual origem. Essa não é uma limitação da implementação. É a consequência direta e esperada de representar uma obrigação fungível como um número: uma vez que a_1 + a_2 = S, não existe operação inversa que recupere a_1 e a_2 a partir de S sozinho, porque S nunca carregou essa informação. Ela ficou, desde o início, em outro lugar, num registro secundário que a aritmética do saldo não obriga a existir.

É por isso que a reconciliação, a conta de passagem e o motor de split existem como categorias de produto inteiras: elas são a tentativa de reconstruir, num sistema paralelo, algo que o modelo de dados principal decidiu, corretamente segundo a própria lógica da fungibilidade, que não precisava reter.

A ressalva necessária

Vale registrar o limite deste argumento antes que alguém precise apontá-lo. Preservar a procedência de uma unidade de valor não exige abandonar a fungibilidade econômica desse valor, e um sistema não precisa escolher entre as duas coisas. Um objeto de valor pode manter identidade própria, com origem e histórico registrados, e ainda ser inteiramente fungível na hora de ser gasto, exatamente como uma nota de banco específica é rastreável pelo número de série e, ainda assim, equivalente a qualquer outra nota de mesmo valor na hora da troca. Fungibilidade é uma propriedade da obrigação. Procedência é uma propriedade do objeto que carrega a obrigação. As duas operam em camadas diferentes, e um sistema que trata cada movimento como um objeto discreto, em vez de uma alteração num número agregado, pode preservar a segunda sem sacrificar a primeira.

O que não é possível é obter esse resultado depois do fato, a partir de um saldo que já absorveu a soma. A procedência, se existir, precisa ser uma decisão tomada no momento em que o valor entra no sistema, não uma reconstrução tentada no momento em que alguém pergunta por ela.