Seu ERP está preparado para o Open Finance? Fazer o quiz gratuito

TecnologiaOpen Finance

Agregar conta PJ: o que muda em relação a pessoa física

Quem autoriza quando o titular é uma empresa, o que vem a mais no dado PJ, onde o fluxo dá mais trabalho que PF e a comparação lado a lado.

Equipe PluggyNov 2026

Se você já integrou agregação bancária para pessoa física e agora precisa atender empresa, a primeira impressão é que vai ser igual com outro documento no formulário.

É a mesma API, são os mesmos endpoints, são os mesmos objetos. E ainda assim o projeto demora mais do que a estimativa.

O que muda não é o código. É quem autoriza, e o que acontece quando essa pessoa não é uma pessoa só.

O que muda, em resumo

Tecnicamente, agregar conta PJ usa a mesma integração de PF. Os objetos de conta, transação e identidade são os mesmos, com campos a mais.

Na prática, três coisas mudam: o conector costuma ser outro, a autorização segue as regras de representação da empresa no banco, e o dado que volta é mais rico e mais irregular.

Quem autoriza quando o titular é uma empresa

Esse é o ponto que mais atrapalha quem vem de PF.

Em pessoa física, quem autoriza é o titular. Uma pessoa, uma decisão, um fluxo.

Em empresa, quem autoriza é quem tem poderes para agir pela empresa naquele banco. E essa regra não é sua nem da camada de agregação: é a mesma regra que o banco já aplica para qualquer operação daquela conta.

Isso tem duas consequências práticas no seu produto.

A pessoa que usa o seu sistema pode não ser a que pode autorizar. O analista financeiro opera o seu software todo dia, mas quem tem poderes no banco é o sócio. Se o seu fluxo assume que quem clica é quem autoriza, ele trava.

Quando a empresa exige assinatura conjunta, a autorização também é conjunta. Se o contrato social e o cadastro no banco exigem dois representantes, o consentimento segue a mesma exigência, do jeito que aquela instituição implementa. O seu fluxo precisa suportar uma conexão que fica pendente esperando a segunda pessoa, em vez de tratar isso como erro.

O desenho que funciona é separar quem pede da conexão de quem autoriza: o seu usuário inicia e envia o convite para quem tem poderes, em vez de você assumir que são a mesma pessoa.

O que vem a mais no dado PJ

A boa notícia é que o dado de empresa é bem mais rico, principalmente pelos conectores de Open Finance.

Na identidade: data de constituição, sócios e administradores com documento e percentual de participação, CNPJs relacionados, atividades econômicas por CNAE e o faturamento informado à instituição. Procuradores também aparecem, com nome e documento.

No relacionamento: desde quando a empresa é cliente daquela instituição, quais produtos ela consome e quais contas estão no consentimento, com agência, número e tipo.

Na transação: a contraparte com CNPJ é bem mais útil em PJ do que em PF, porque é ela que permite casar um recebimento com um cliente e um pagamento com um fornecedor. Em conciliação, esse campo é metade do trabalho.

Esse conjunto só existe assim nos conectores de Open Finance. Vale conferir a diferença entre conector regulado e acesso direto antes de prometer um campo ao seu time de produto.

Onde PJ dá mais trabalho

Quatro coisas que aparecem em todo projeto e surpreendem quem só fez PF.

O conector costuma ser separado. A maioria das instituições tem entradas distintas para pessoa física e jurídica. Se o seu produto é só para empresa, vale filtrar a lista para mostrar só os conectores de empresa, senão o usuário escolhe o errado e recebe um erro que não explica nada.

Uma empresa tem mais contas. Conta movimento, conta de recebimento, conta de uma filial, conta de outro CNPJ do grupo. O seu modelo de dados precisa aguentar várias conexões por cliente desde o primeiro dia, não depois.

O volume de transações é outro. Uma conta PJ ativa gera num dia o que uma conta pessoal gera numa semana. Paginação, carga inicial e janela de sincronização precisam ser pensadas, não herdadas.

Reautorizar é muito mais caro. O padrão é consentimento sem prazo, mas ele cai quando alguém revoga ou quando o conector trabalha com validade definida. Em PF, pedir para reautorizar é um incômodo. Em PJ, significa caçar de novo a pessoa com poderes, que não é quem usa o sistema. Trate isso como fluxo de produto, não como alerta técnico.

PF e PJ lado a lado

AspectoPessoa físicaPessoa jurídica
Quem autorizaO próprio titularQuem tem poderes pela empresa no banco
Autorização conjuntaNão se aplicaPode ser exigida, conforme o cadastro no banco
ConectorEntrada de pessoa físicaCostuma ser entrada separada
DocumentoCPFCNPJ, normalmente com o CPF do representante
Contas por clientePoucasVárias, inclusive de CNPJs diferentes
Volume de transaçãoMenorBem maior, e concentrado em dias de fechamento
Dado de identidadeDados pessoais e endereçoAcrescenta sócios, participação, CNAE e faturamento informado
Uso da contraparteÚtilEssencial, é o que casa cliente e fornecedor
Custo de reautorizarBaixoAlto, depende de achar quem tem poderes

E a Pluggy nisso tudo?

PF e PJ chegam pela mesma API, com os mesmos objetos. Você não integra duas vezes.

No fluxo de conexão dá para filtrar os conectores por tipo, então um produto feito para empresa pode mostrar só as entradas de empresa e evitar o erro mais comum de todos. E dá para pré-preencher CPF e CNPJ nos conectores de Open Finance, o que tira dois campos de digitação do caminho de quem está autorizando.

O enriquecimento vale a pena mencionar aqui porque é em PJ que ele mais rende: contraparte com CNPJ é o que transforma uma lista de lançamentos em conciliação.

Os recortes de produto são agregar dados PJ e agregar dados PF. Para o estado do Open Finance empresarial, o texto é Open Finance PJ: avanços.

Perguntas frequentes

É a mesma integração para PF e PJ?

É. Mesma API, mesmos objetos. O que muda é o conector, o fluxo de autorização e a riqueza do dado.

Quem precisa autorizar numa empresa?

Quem tem poderes para agir pela empresa naquela instituição. A regra é do banco, e é a mesma que vale para qualquer operação da conta.

E se a empresa exigir dois representantes?

A autorização segue essa exigência, do jeito que a instituição implementa. O seu fluxo precisa suportar uma conexão pendente de segunda autorização em vez de tratar como falha.

A cobertura de instituições é a mesma?

Não necessariamente. Nem toda instituição oferece as duas entradas, e isso vale verificar para os bancos que os seus clientes usam.

O dado cadastral da empresa vem completo?

Varia por instituição e por tipo de conector. Campos opcionais podem vir vazios, e o seu produto precisa funcionar sem travar quando isso acontece.

Dá para conectar vários CNPJs do mesmo grupo?

Dá. Cada conexão é independente, e vale modelar isso desde o começo em vez de assumir um CNPJ por cliente.

Conclusão

Agregar conta de empresa não é um projeto técnico maior. É um projeto de produto maior, porque a pessoa que usa o seu sistema e a pessoa que pode autorizar costumam ser duas.

Se você está desenhando esse fluxo agora, dá para testar com os conectores de empresa antes de decidir como o seu produto pede a autorização.

Voltar para o blog

Pronto para integrar Open Finance na sua plataforma?

Teste grátis