O que é um IBAN virtual?

Um IBAN virtual (vIBAN) é um International Bank Account Number real e endereçável, emitido a partir de uma faixa dedicada e roteado para uma única conta master. Ele recebe pagamentos como qualquer outro IBAN — o pagador envia uma transferência SEPA comum a partir do próprio banco —, mas não mantém saldo próprio. Sua função é identificar: como cada IBAN virtual é atribuído a exatamente um pagador ou finalidade, o pagamento que chega por ele já informa quem o enviou e para que serve. O dinheiro se concentra na conta master automaticamente; o IBAN virtual é a etiqueta do pagamento, não um segundo lugar onde o dinheiro fica.

Essa única propriedade — um IBAN por pagador — é a ideia inteira. Para entender por que ela merece um artigo, comece pelo problema que ela elimina.

O problema real: associar o dinheiro ao pagador

Imagine uma empresa que recebe por transferência bancária em uma única conta: aluguéis, assinaturas, faturas. Todo crédito cai no mesmo IBAN, e a única pista de quem pagou é o que o pagador digitou no campo de referência. Referências são digitadas errado, truncadas em algum ponto da cadeia ou deixadas em branco. Uma transferência de €49.00 com referência ilegível ainda não é €49.00 de receita reconhecida — é um chamado. Alguém precisa descobrir a que cliente e a que fatura ela pertence antes do fechamento contábil.

Em volume baixo, isso é um incômodo. Em volume de plataforma, vira um departamento. Os motores de conciliação pontuam faturas candidatas por valor, data e texto aproximado da referência; o que não conseguem encaixar vai para uma fila humana. E a falha é estrutural: quando dois assinantes pagam o mesmo valor no mesmo dia sem referência, nenhum motor consegue separá-los — a informação que os distinguiria nunca esteve no pagamento.

Um IBAN por pagador: identidade por construção

Um programa de IBAN virtual inverte o desenho. Em vez de pedir que cada pagador identifique corretamente o pagamento, você dá a cada um o seu próprio endereço. Cada inquilino, assinante ou vendedor de marketplace paga em um IBAN que é só dele. O campo de referência pode estar errado, vazio ou em outro alfabeto — o crédito continua se identificando, porque a identidade viaja no número da conta.

O número da conta é um portador muito melhor que a referência. Um IBAN inclui seus próprios dígitos verificadores, então um IBAN digitado errado falha na validação no banco do pagador antes mesmo de a transferência ser enviada. Uma referência errada passa sem problema e vira problema seu. Tirar a identidade do campo de texto livre e levá-la para o endereço desloca a checagem de erros do seu back office para o banco remetente.

Para o pagador, nada muda: ele paga um IBAN pelo app do banco, como sempre. Toda a novidade está no lado de quem recebe — o pagamento chega já etiquetado, e o campo de referência volta a ser o que sempre deveria ter sido: uma anotação, não um sistema de identificação.

Quando cada pagador paga no próprio IBAN, um pagamento recebido só pode significar uma coisa. O problema de conciliação não é resolvido — ele deixa de existir.

Onde o dinheiro realmente fica

Por baixo, há exatamente uma conta master por moeda. Os IBANs virtuais são emitidos a partir de faixas dedicadas ao programa, e todo crédito enviado a qualquer um deles é liquidado na master. Não há saldos por pagador para gerenciar nem rotinas de varredura no fim do dia levando fundos de milhares de contas pequenas para uma só — a concentração acontece por roteamento, não por transferências extras que você teria de conciliar por conta própria.

É isso também que faz do IBAN virtual algo real, e não um truque. Ele é endereçável a partir de qualquer banco, compensa como qualquer crédito SEPA e aparece no extrato do próprio pagador como a conta que ele pagou. O que lhe falta é justamente o que uma conta completa traz de bagagem: saldo próprio e um ciclo de vida além da atribuição e da desativação.

O que um IBAN virtual não é

Não é uma subconta: a subconta mantém saldo, exige aporte e resgate e multiplica os livros-razão que você opera. Não é um número de referência virtual: esses ainda dependem do campo de referência e de pagadores que copiem textos corretamente. E não é uma carteira: nada fica armazenado no próprio vIBAN. É um endereço com roteamento por trás — a construção mais enxuta que torna um pagamento recebido autoidentificável.

Devoluções voltam com o motivo anexado

Pagamentos não apenas chegam. Contas são encerradas, bancos rejeitam créditos, pagadores solicitam o estorno de transferências. Num mundo de conta única de recebimento, uma devolução é uma pequena investigação: qual pagamento voltou, de quem era e se o lançamento ao qual ele foi associado precisa ser estornado.

Num programa de vIBAN, a devolução é dado. Ela traz seu código de motivo, chega como um evento payment.returned contra o mesmo IBAN virtual usado pelo crédito original e ganha sua própria contagem no extrato. Você sabe de quem era o pagamento que voltou, e por quê, antes que alguém abra um chamado. Devoluções viram linhas a tratar, não mistérios a perseguir.

Uma fila de exceções, não uma equipe de conciliação

Nenhum desenho concilia cem por cento de nada. Créditos chegam em vIBANs desativados. Duplicidades acontecem. Alguém, de algum jeito, paga direto na conta master. O objetivo não é tornar as exceções impossíveis, e sim raras e contáveis. Na demo de vIBAN da Protocore, 99.6% dos créditos são conciliados automaticamente; o restante entra numa fila de revisão com todo o histórico do pagador anexado, de modo que tratar uma exceção parte do contexto, não de um extrato bancário e uma planilha.

Essa diferença remodela a equipe. Uma operação de conciliação cresce com o volume de pagamentos: mais créditos, mais créditos sem correspondência, mais gente. Um processo de exceções cresce com o volume de exceções, que o desenho já empurrou para perto de zero. As pessoas que ficam tratam anomalias genuínas, não referências redigitadas. Na nossa stack, essa fila vive no Protocore Center (/products/center), o console de operações em que toda ação privilegiada exige uma justificativa e fica registrada em um log de auditoria.

Emissão em lote, tags de finalidade, plataformas

Um IBAN por pagador só funciona se emitir um não custar nada. Um proprietário com uma dúzia de inquilinos poderia criar vIBANs à mão; um marketplace que integra milhares de vendedores, não. Por isso a emissão é uma operação em lote. Na demo de vIBAN, um CSV com 2,400 pagadores é validado, mostra uma prévia do IBAN em cada linha e emite tudo em uma única ação — 2,400 pagadores, uma operação, uma etapa de revisão no meio.

As tags de finalidade mantêm os fluxos separados no nível do endereço: aluguel aqui, assinaturas ali, repasses do marketplace em sua própria faixa. Relatórios por finalidade viram um filtro, não um projeto, e cada vIBAN tem seu próprio extrato — CSV ou PDF —, enquanto a conta master continua sendo a fonte única da verdade por baixo. Quando um pagador sai, seu vIBAN é desativado: o histórico permanece, o endereço deixa de aceitar novos créditos.

Onde isso se encaixa em uma stack de pagamentos

IBANs virtuais são infraestrutura de recebimento. Dão às transferências bancárias recebidas o que os pagamentos com cartão sempre tiveram — identidade anexada ao próprio pagamento, não digitada ao lado dele. No ecossistema Protocore, os pedidos pay-by-transfer do Gateway carregam referências de vIBAN, e o Center trata as exceções que a conciliação deixa para trás. A página do produto em /products/viban percorre o ciclo completo — emitir, compartilhar, conciliar, tratar exceções, reportar — com os mesmos dados de demonstração usados aqui.

E um limite honesto: se você recebe um punhado de transferências por mês, uma convenção de referência e dez minutos de contabilidade resolvem. Os IBANs virtuais se pagam onde o volume transformou a conciliação em processo — carteiras de aluguel, cobranças de assinatura, marketplaces —, em qualquer lugar onde a pergunta "quem me pagou?" é feita milhares de vezes por mês.