Importante

11/2023 - V15 - Nova versão dos extratos eletrônicos - Documentação e arquivos de teste

Visando trazer maior transparência e fluidez na conciliação dos extratos, os nossos arquivos terão uma nova estrutura em sua demonstração.

Esta mudança está prevista para implantação em nov/23.

Abaixo segue o comunicado enviado com os detalhes das alterações, arquivos de teste e documentação complementar para apoiar com a homologação.

Material versão português

Material version english

Material versión español

Arquivos de Teste

É importante que a homologação da nova estrutura ocorra até a data indicada para não impactar a leitura dos extratos.

Importante! A versão atual dos extratos não terá mais suporte e geração a partir de jan/24.

Histórico de Alterações

Versão Produtiva

Aqui você encontra as documentações referentes a versão produtiva do Extrato EDI, atualizada em: 06/09/2023

Manual versão português

Manual versão inglês

01/09/2023 - V14 - Inclusão de novos campos Pix (CIELO16) - Documentação e arquivos de teste

Esta mudança foi implantada em 01/09/2023

CIELO_Extrato_Eletronico_-_Manual_-_Versao_14_v2(pix)

Massa_PIX_Cenarios_EDI_V2

09/12/2022 – V14 – Negociação de Recebíveis + pix

Observação: as atualizações citadas abaixo, estarão disponíveis a partir do dia 07 de junho de 2021.

Manual de Extrato Eletrônico

Electronic Statement Manual - English version

Atualização de Layout EE - Registro de Recebíveis + PIX

Arquivos de teste – Comunicado 09/12/2022

Introdução

Essa API possibilita o registro de grupos e mantém seu registro para receber arquivos EDI (Electronic Data Interchange).

Descrição do Produto

O Extrato Eletrônico é um produto disponibilizado pela Cielo aos clientes que necessitam de automatização no processo de conciliação. Nele, as informações são transmitidas de forma padronizada sem intervenção manual por meio do canal SFG (Sterling File Gateway), proporcionando agilidade e segurança no tráfego das informações. Ao lado, macrofluxo do serviço.

Benefícios

• Permite a realização da conciliação contábil e financeira de forma automatizada
• Maior agilidade e eficiência operacional
• Integração com a automação comercial de vendas
• Segurança no recebiento das informações
• Atendimento Especializado

Fluxo de Concessão

Passo 1 - Login

1 - O parceiro redireciona o cliente para {cielo-login-url}.
2 - O cliente entra com suas credenciais e clica em Entrar.
3 - A Cielo mostra os termos de autorização e o cliente aprova este acesso clicando em Permitir Acesso.
4 - A Cielo redireciona o cliente para o parceiro novamente em {partner-call-back-url}.

O que é base-login-url?

https://{base-login-url}?response_type=code &client_id={client_id} &redirect_uri={redirect_uri} &scope={scope} &state={state}

Homologação: https://digitalhml.hdevelo.com.br/oauth/?mode=redirect&client_id={client_id}&redirect_uri={redirect_uri}&state=STATE_INFO&scope=profile_read,transaction_read

Produção: https://minhaconta2.cielo.com.br/oauth/?mode=redirect&client_id={client_id}&redirect_uri={redirect_uri}&state=STATE_INFO&scope=profile_read,transaction_read

• base-login-url: URL base que muda por ambiente
• response_type: O valor deve ser fixo “code”
• client_id: Identificador do cliente, será enviado pela Cielo em tempo de projeto
• redirect_uri: URL do parceiro para a Cielo redirecionar o usuário quando o processo de login terminar, ou se der algum erro no processo
• scope: Uma lista separada por vírgula das APIs que o parceiro deseja acessar, os possiveis escopos serão enviados por API.
• state: Um valor que o cliente deseja receber no retorno para manter o estado entre a requisição e o retorno

O que é partner-callback-url?

https://{partner-callback-url}?code={code}&state={state}

• partner-callback-url: A URL do parceiro que será redirecionado quando o processo de login terminar.
• code: O authorization code gerado pela Cielo. Com esse código o parceiro vai poder trocar por um access_token para fazer chamadas em nome do cliente.
• state: O mesmo valor que o parceiro enviou na requisição.

Passo 2 – Requisitando um Access Token

• O serviço do parceiro solicita um access_token.
• A Cielo retorna um acess_token, um refresh_token e um expiration_time.

Request

POST {cielo-api-base-url}/consent/v1/oauth/access-token

Key	Value
Authorization	Basic Base64(client_id e client_secret do parceiro concatenado com “:” e codificado em base64)

curl --location --request POST 'https://{cielo-api-base-url}/consent/v1/oauth/access-token' \
--header 'Basic Basic64'
--header 'Content-Type: application/json' \
--data-raw '{
    "grant_type": "authorization_code",
    "code": "{}"
}'
--verbose

Response

{
"access_token": "{access_token}",
"refresh_token": "{refresh_token}",
"token_type": "access_token",
"expires_in": {expiration_time}
}

Observações

• O authorization_code precisa ser trocado por um access_token em menos de 10 minutos.
• Este tipo de access_token é mandatório para chamar as APIs que retornam dados sensíveis dos clientes.
• O parceiro precisa armazenar o access_token e o refresh_token em um lugar seguro.
• Quando o access_token expirar o parceiro não conseguirá mais chamas as APIs até que solicite um novo acess_token usando o fluxo de refresh_token.
• O acess_token gerado nesse fluxo será único por cliente da Cielo, pois precisa obrigatoriamente a aprovação do cliente.
• O parceiro NÃO consegue gerar um access_token sem o consentimento do cliente.
• O parceiro NÃO consegue usar o authorization code, recebido no primeiro passo, mais de uma vez.

Passo 3 - Chamando as APIs

Neste momento parceiro vai conseguir chamar as APIs da Cielo sem a necessidade da aprovação do cliente, pois esta já foi concedida.

A única exigência para chamar as APIs da Cielo é enviar o seguinte header HTTP: Authorization: Bearer {access_token} Em todas as chamadas para as APIs.

• O access_token foi obtido no Segundo passo

Passo 3.1 - Atualizando um Access Token

1. O serviço do parceiro chama o serviço de refresh_token.
2. A Cielo retorna um access_token novo, um refresh_token novo e um novo expiration_time.

O dados de resposta serão os mesmos do passo 2 quando o parceiro solicita um acess_token, porém todos os dados retornados são novos e precisam ser armazenados no lugar dos antigos.

Request

curl --location --request POST 'https://{cielo-api-base-url}/consent/v1/oauth/access-token' \
--header 'Basic Basic64'
--header 'Content-Type: application/json' \
--data-raw '{
    "grant_type": "refresh_token",
    "refresh_token": "{}"
}'
--verbose

Um ponto de atenção na requisição pois agora o parceiro precisa enviar o grant_type como refresh_token e no campo refresh_token deve ser enviado um refresh_token válido (e não mais um access_token).

Response

{
"access_token": "{access_token}",
"refresh_token": "{refresh_token}",
"token_type": "access_token",
"expires_in": {expiration_time}
}

Erros

Caso ocorra algum erro do lado Cielo o cliente será redirecionado para a URL de call-back do parceiro com o parâmetro error na URL, por exemplo https://{partner-callback-url}?error={error}.

Possíveis valores para {error}:

• lid_request: A requisição está faltando algum parâmetro obrigatório, ou esta com algum parâmetro inválido, ou qualquer outra possibilidade que faça a URL ficar incorreta.
• unauthorized_client: O parceiro não está autorizado a fazer uma requisição usando este método.
• access_denied: O dono do recurso ou o servidor de autorização negou a requisição.
• unsupported_response_type: O servidor de autorização não suporta obter um authorization code usando este método.
• invalid_scope: O escopo é invalido, desconhecido ou malformado.
• server_error: O servidor de autorização encontrou uma condição inesperada e não consegue concluir esta requisição. ( Este erro é necessário porque não é possível retornar um HTTP status code 500 Internal Server Error via redirecionamento HTTP)
• temporarily_unavailable: O servidor de autorização não consegue tratar a requisição devido a uma sobrecarga temporária ou está em manutenção. (Este erro é necessário pois não é possível retornar um HTTP Status 503 Service Unavailable para o parceiro via redirecionamento HTTP)

Opcionalmente pode ser retornado um outro parâmetros error_description com um detalhe do erro, apenas um texto simples.

Observação

• Todos os tokens (access_token e refresh_token) devem ser armazenados em um local seguro.
• O parceiro precisam iniciar um novo fluxo de concessão se perderem os tokens ou ambos expirarem (O refresh_token tem expiração de 90 dias a partir da geração).
• Caso gere um novo refresh_token este tem mais 90 dias a partir da geração para expirar.
• O parceiro precisa iniciar um novo fluxo de concessão para cada cliente da Cielo que o parceiro deseja consultar os dados.

Ambiente

Collection

Dispobilizamos as Collections utiizadas para realizar as todas operações da API. Será necessário configurar a URL e as credenciais.

Download das Collections

Operações

GET Consulta a Lista de Filiais

Executa a lista de clientes abaixo do access_token informado. O filtro pode ser usado para listar apenas aqueles disponíveis ou indisponíveis. Indisponível significa que a filial já participa de outro registro. Nos serviços de registro e edição, há validação para permitir que apenas aqueles disponíveis sejam informados.

Response

GET /merchantgroup

Headers

Key	Value
	Authorization	Bearer + access_token

{
  "legalEntityNumber": "string",
  "branches": [
    {
      "merchantID": "9999111222",
      "legalEntityNumber": "01234567890",
      "businessName": "V",
      "status": "UNAVAILABLE"
    }
  ]
}

GET Consultar configurações existentes.

Retorna configurações existentes agrupadas por mainMerchantID.

Response

GET /mainmerchants

Headers

Key	Value
Authorization	Bearer + access_token

{
  "registerID": "38724",
  "mainMerchantID": "2006907071",
  "merchants": ["2006907071"],
  "type": [
    "SELL",
    "PAYMENT",
    "ANTECIPATION_CIELO",
    "ASSIGNMENT",
    "BALANCE",
    "ANTECIPATION_ALELO",
    "NRC",
    "PIX"
  ],
  "editStatus": "AVAILABLE"
}

POST Registrar merchantID

Registre o ID do lojista(apenas um, uma lista ou todos), com base no número da entidade.

Request

POST /registers

Headers

Key	Value
Authorization	Bearer + access_token

{
  "mainMerchantId": "9999111222",
  "merchants": ["9999111111", "9999111333"],
  "merchantEMail": "customer@customer.com",
  "type": ["SELL"]
}

Response

{
  "legalEntityNumber": 1234567890,
  "mainMerchantId": 2008983,
  "registerID": 12345,
  "merchants": [823958412384701, 679809436576210],
  "type": ["SELL"],
  "status": "PROCESSING"
}

GET Consultar o Status do Registro

Recupere o status de registro do EDI.

Response

GET /registers/{registerID}

Headers

Key	Value
Authorization	Bearer + access_token
registerID	Valor usado para recuperar o status do registro.

{
  "legalEntityNumber": "01234567890",
  "registerID": 12345,
  "merchants": [9999222111, 9999222222],
  "status": "PROCESSING"
}

GET Consulta o Registro do merchantID

Consulte o MerchantID com base no registerID ou no mainMerchantID.

Response

GET /edi?registerID=&mainMerchantID=

Headers

Key	Value
Authorization	Bearer + access_token
registerID	O registerID é fornecido pela operação /edi/registers ao se registrar. Pode ser usado no lugar de mainMerchantID, se preferir (apenas um precisa ser informado).
mainMerchantID	A maneira mais comum de recuperar um registro EDI na empresa. Pode ser usado em vez de registerID, principalmente em casos de registro não realizados por /edi/registers.

{
  "legalEntityNumer": "12314314",
  "mainMerchantId": 9999111222,
  "registerID": 12345,
  "merchants": [9999111111, 9999111333],
  "type": ["SELL"],
  "acknowledge": "COMPLETED"
}

PUT Atualizar o Registro do merchantID

Atualize o merchantID com base no registerID ou mainMerchantID.

Request

PUT /edi

Headers

Key	Value
Authorization	Bearer + access_token

{
  "registerID": "string",
  "mainMerchantId": "9999222333",
  "merchants": ["9999222111", "9999222222"],
  "type": ["SELL"]
}

Response

{
  "legalEntityNumber": "01234567890",
  "mainMerchantId": 9999111222,
  "registerID": 12345,
  "merchants": [9999222333, 9999111222],
  "type": ["SELL"]
}

DELETE Excluir o Registro do merchantID

Consulte o MerchantID com base no registerID ou no mainMerchantID.

Response

DELETE /edi

Headers

Key	Value
Authorization	Bearer + access_token
registerID	O registerID é fornecido pela operação /edi/registers ao se registrar. Pode ser usado no lugar de mainMerchantID, se preferir (apenas um precisa ser informado).
mainMerchantID	A maneira mais comum de recuperar um registro EDI na empresa. Pode ser usado em vez de registerID, principalmente em casos de registro não realizados por /edi/registers.

{
  "legalEntityNumer": "12314314",
  "mainMerchantId": 9999111222,
  "registerID": 12345,
  "acknowledge": "COMPLETED"
}

Duplicação de Matriz

A duplicação de registro funciona com base no retorno do GET /merchantgroup, se retornar “unavailable” significa que esse merchant já possui vínculo com alguma conciliadora.

GET /merchantgroup

{
  "legalEntityNumber": "67625512",
  "branches": [
    {
      "merchantID": "2006907071",
      "legalEntityNumber": "67.625.512/0001-14",
      "businessName": "MERCHANTI",
      "status": "UNAVAILABLE"
    }
  ]
}

Com isso, será necessário efetuar um novo GET para saber se você pode ou não vincular essa cadeia de merchant a sua conciliadora, que nesse caso é o GET /mainmerchants, se você obter o status “available” no campo “editStatus”, significa que você poderá fazer a duplicação de matriz via API.

GET /mainmerchants

[
  {
    "registerID": "38724",
    "mainMerchantID": "2006907071",
    "merchants": ["2006907071"],
    "type": ["SELL", "ASSIGNMENT", "BALANCE"],
    "editStatus": "AVAILABLE"
  }
]

GET /mainmerchants pode retornar mais de um objeto, com isso, se o objeto estiver como “available”, será necessário efetuar uma chamada de PUT para cada objeto. Os objetos que retornarem “unavailable”, será necessário solicitar a duplicação manual através do edi@cielo.com.br (lembrando que isso representa apenas 10% dos casos, após a implementação da duplicação através do método PUT).

Com isso, deverá ser feita uma chamada de PUT /edi no qual, irá fazer a duplicação da matriz.

PUT /edi

{
  "mainMerchantID": "2006907071",
  "registerID": "38724",
  "merchants": ["2006907071"],
  "type": ["SELL", "ASSIGNMENT"]
}

O header de todas essas requisições permanecem da mesma forma, deve ser informado o Authorization, como nas demais chamadas desta API. Com base no retorno do GET /mainmerchants, será necessário informar o registerID, mainMerchantID e as filiais no array de merchants da chamada de PUT.

Tipos de Extrato Eletrônico

Tabela A - Tipos de Arquivo

É possível solicitar o recebimento dos seguintes tipos de arquivos (exclusivo transações Alelo):

Layouts dos Tipos de Registros

Tabela B - Registro 0 - Header

Identifica o cabeçalho de cada arquivo por matriz de extrato eletrônico*

• (*) cadastro que permite a inclusão de todos os estabelecimentos controlados pelo cliente, independente do tipo de pagamento (centralizado, descentralizado, individual). Todos os números de estabelecimento (número do cliente na Cielo) devem ser informados no formulário de cadastro.

Registro 1 - Detalhe do Resumo de Operações (RO)

Grupo de vendas, ajustes ou cobrança de serviços. Permite identificar a origem dos lançamentos e as ações de manutenção.

Registro 2 - Detalhe do Comprovante de Venda (CV)

Detalhe das vendas ou ajustes agrupados em um RO. Conforme regras de segurança, todos os registros que possuírem número de cartão apresentarão o número truncado.

Registro 3 - Operação de recebíveis

Permite identificar a origem das operações realizadas com os recebíveis.

Registro 5 - Detalhe da Operação de Antecipação Alelo

Apresenta a operação de antecipação Alelo realizada no dia anterior à geração do arquivo.

Registro 6 - Detalhe dos ROs Antecipados Alelo

Apresenta o detalhamento da operação de Antecipação demonstrando os ROs antecipados Alelo.

Registro 7 - Detalhe dos Débitos de ROs Antecipados

Apresenta os débitos compensados nas datas antecipadas.

Registro 8 - Detalhe Transação PIX

Apresenta as transações realizadas na modalidade PIX.

Registro A - Resumo Negociação de Recebíveis

Permite conferir as negociações que foram realizadas.

Registro B - Detalhe Negociação de Recebíveis

Permite conferir o detalhe das negociações que foram realizadas.

Registro C - Conta de Recebimento

Registro 9 - Trailer

Indica o final do arquivo.

Observação: os campos reservados para a Cielo poderão ser utilizados para a inclusão de novas informações. Também poderá ser necessário incluir novos tipos de registros. Por conta disso, sugerimos que a solução de conciliação despreze os registros não relacionados nesta especificação.

Tabelas

Tabela I - Opção de Extrato

Tabela II - Tipo de Transação

Tabela III - Status do Pagamento

Quando um valor a crédito estiver em processo de compensação com um valor a débito, ambos serão enviados no arquivo de pagamento na data da compensação, posterior a data prevista de pagamento. O status enviado para o banco poder ser novamente apresentado no extrato de pagamento, quando o banco domicílio devolver uma ordem de crédito (reenvio de pagamento)

Tabela IV - Código do Produto

Tabela V - Origem do Ajuste

Tabela VI - Bandeira

Tabela VII - Meio de Captura

Tabela VIII - Motivo da Rejeição

Tabela IX - Modo de Entrada do Cartão

Tabela X - Grupo de Cartões

Tabela XI - Tipo de Cartão

Transmissão e Reenvio de arquivo

Para receber o Extrato Eletrônico, é necessário que o cliente entre em contato com o Atendimento EDI e preencha o formulário de cadastro. Os arquivos serão disponibilizados na caixa postal diariamente, exceto o arquivo de saldo em aberto que será enviado mensalmente. Quando não houver movimento, o arquivo será enviado somente com o "Header" e o "Trailer". Caso ocorra alguma inconsistência na transmissão do(s) arquivo(s), o cliente deverá informar à Cielo, contatando o Atendimento EDI (edi@cielo.com.br

Reenvio de Arquivos

Em caso de perda do arquivo ou não recebimento, a Cielo disponibilizará na caixa postal o mesmo arquivo enviado diariamente (arquivo backup). O cliente poderá contatar o Atendimento EDI para solicitar o reenvio

Recuperação de Arquivos

• Permite a recuperação de um movimento anterior, atualizando o status dos lançamentos.
• Os arquivos são disponibilizados separadamente do arquivo diário.
• Não disponível para o Extrato de Saldo em Aberto (09).
• A solicitação deve ser encaminhada para o Atendimento EDI.

Conceitos Financeiros/Glossário

Ajuste: lançamento financeiro à crédito ou a débito realizado para regularizar uma cobrança indevida, cancelar uma venda ou repassar um chargeback para o cliente.

Alteração do Plano Parcelado: ocorre quando o portador solicita ao cliente uma alteração no plano parcelado contratado no início, como cancelamento total ou parcial da venda e alteração na quantidade ou valor de parcelas.

Antecipação de Recebíveis (ARV): serviço oferecido ao cliente afiliado à Cielo ou Alelo que deseja antecipar o recebimento de suas vendas crédito à vista e parceladas.

Cadeia de Pagamento Centralizado: é um grupo de clientes com a mesma raiz de CNPJ, regras de travas e antecipação, domicílio bancário e as mesmas condições comerciais de comissão e prazo. Uma cadeia possui apenas uma matriz, escolhida pelo cliente, onde estão cadastrados todos os produtos e taxas aplicados nas filiais.

Cessão de Recebíveis: operação de antecipação dos recebíveis realizada no domicílio bancário, disponível para o banco Bradesco.

Chargeback: devolução da transação pelo banco emissor, por contestação do portador.

Cessão: operação de antecipação de pagamentos efetuadacom a Cielo ou com o mercado. Registros de contrapartida de operações feitas com o mercado dentro dos arquivos de venda, dependem do envio dos dados por parte do financiador a Cielo em tempo hábil. Operações enviadas de forma tardia não serão demonstradas nos arquivos de venda, sendo necessário solicitar o reprocessamento dos extratos aos canais de atendimento.

Data da Venda: dia em que a venda foi realizada pelo cliente Cielo. No caso de clientes que operam com soluções ecommerce, esta é a data na qual o portador realizou a compra no site e não a data na qual foi feita a confirmação da venda pelo cliente Cielo.

Data da Apresentação: dia em que a venda foi submetida para processamento na Cielo, podendo ser um sábado, domingo ou feriado. Essa é a data base para o cálculo da programação de pagamento e pode ser diferente da data da venda, de acordo com o tipo de solução de captura utilizado.

Data da Captura: data em que a transação foi capturada no sistema Cielo. Para clientes Cielo que operam com soluções e-commerce, esta é a data na qual a transação foi confirmada pelo cliente.

Data do Envio ao Banco: data em que o arquivo de pagamento (crédito ou débito) foi enviado para o banco de domicílio do cliente.

Data do Pagamento: dia do efetivo pagamento do valor na conta-corrente do cliente, considerando o prazo de pagamento acordado. Caso a data calculada não seja dia útil, o pagamento será realizado no primeiro dia útil posterior. Inicialmente, após a captura da venda, é informada a data prevista de pagamento, que poderá ser postergada no caso do valor ser utilizado para compensar a cobrança de algum débito proveniente de cancelamento de venda, chargeback ou cobrança de serviços. O pagamento também poderá ser antecipado caso o cliente realize uma operação de antecipação.

Matriz de Extrato: cadastro que permite a inclusão de todos os estabelecimentos controlados pelo cliente, independente do tipo de pagamento (centralizado ou individual).

Gravame: operação de crédito no modelo de garantiaefetuada com um agente financiador. Não acarreta a antecipação da data de pagamento dos valores, apenas a troca de titularidade do recebedor.

Número Único da Transação: é atribuido pela Cielo e identifica cada transação de forma única, permitindo que a conciliação das ações de ajustes e antecipação de recebíveis realizadas tanto no RO quanto no CV sejam conciliadas por essa chave, Para isso, a solução de conciliação deverá usar somente as partes fixas do número único, seguindo esta composição.

Parcelado Loja Arredondamento do Valor da Parcela: é sempre realizado na 1ª parcela e ocorre nos casos em que o resultado da divisão do valor da venda pela quantidade de parcelas for uma dízima periódica. Neste caso, a 1ª parcela será maior do que as demais.

Parcelado Loja - Prazo: no extrato de Vendas com Plano Parcelado, todas as parcelas serão enviadas com a data de apresentação original. No entanto, no extrato de pagamentos, será demonstrada a data de liberação da respectiva parcela. O cálculo da data de pagamento de todas as parcelas tem como base a data da apresentação da 1ª parcela e possui uma lógica diferente para transações de cada uma das bandeiras, conforme abaixo:

VISA, ELO, DINERS e demais bandeiras: As parcelas serão liberadas mensalmente no mesmo dia da 1ª parcela, não importando se o dia é útil ou não. Desta forma, uma venda em 04 parcelas apresentada em 10/01/2015 terá o seguinte plano de liberação (prazo de pagamento: 30 dias):

A única exceção para a regra acima ocorre quando o dia não existir no mês de liberação da parcela. Exemplo: venda cuja 1ª parcela foi apresentada em 31/01/2015. Como não existe dia 31 no mês de fevereiro, a parcela deste mês será apresentada no último dia do mês, ou seja, 28/02/2015.

MASTERCARD: a data de apresentação da 1ª parcela também será a data base para liberação de todas as parcelas do plano, no entanto, as parcelas futuras serão sempre 30 dias após apresentação da primeira parcela, mantendo essa lógica até a conclusão do plano. No exemplo da venda apresentada em 10/01/2015 utilizado anteriormente, notamos que as parcelas serão liberadas em 30, 60, 90 após a apresentação da primeira parcela (prazo de pagamento: 30 dias):

Rejeição de Transação: ocorre quando o cliente ou a venda não possuem os atributos necessários para o correto processamento e agendamento do pagamento.

Revenda: ocorre quando existe uma alteração no plano de pagamento de uma venda parcelada, seja na quantidade de parcelas, ou no valor total da transação.

Solução de Captura: equipamento e/ou software de processamento de dados (POS, PDV, e-commerce, mobile payment, EDI etc.) que se conecta à rede Cielo para autorização e captura de transações.

Resumo de Operações (RO): o número do RO identifica um agrupamento de vendas em determinada data. Tem 7 posições e será formatado conforme abaixo.

Saldo em Aberto: compreende todos os lançamentos à receber com a Cielo. Devem ser considerados os pagamentos da Cielo não realizados no passado devido à cancelamentos e contestações.

Tipos de cadastro: com o cadastro por Grupo Comercial, que utiliza a raiz de CNPJ, todos os novos estabelecimentos da raiz são automaticamente inclusos no extrato eletrônico, evitando perdas de informações.