Statement (V3/V4)

The Statement API in Getnet Split Payments lets the platform query the financial breakdown of every event generated by a split transaction: sales, commissions, adjustments, chargebacks, and settlements. The returned data is the basis for reconciling the marketplace's finances with the amounts passed on to each partner.

Requirements

Marketplace accredited with Getnet, with the seller_id (the anchor's access key) on hand.
Valid access token, sent in the Authorization header in the format Bearer <token>.

Choose the API Version

The Statement API is available in two active versions, V3 and V4. Version V2 has been discontinued and should no longer be used.

Version	Endpoint(s)	Characteristics
V3	`GET /v3/mgm/statement/not-paginated` and `GET /v3/mgm/statement/paginated`	Two separate endpoints, one paginated and one not. Includes payment plan, anticipations, and liens.
V4	`GET /v4/mgm/statement`	A single endpoint, always paginated (the `page` parameter is required).

V4 introduces the following schema changes relative to V3:

The product fee is shown separately from the MDR (Merchant Discount Rate).
The MDR is calculated per item.
A cancellation transaction now shows the original transaction's date.
A new field identifies payments made through Receba-Já.
The anchor's CNPJ now appears in the summary block.
The transaction_sign field no longer exists: the positive or negative sign is now embedded directly in the value itself.
The payment_summaries block is discontinued, replaced by a payments object inside each of the details, commissions, adjustments, and chargeback blocks.

Note: The examples and field descriptions in the sections below (Understand Specific Events in the Statement) use the V3 schema, including transaction_sign and payment_summaries. On V4, apply the same logic described using the sign embedded in the value (instead of transaction_sign) and each block's payments object (instead of payment_summaries).

Query the Statement

Send a GET request to the chosen version's endpoint, providing the seller_id and at least one additional filter.

Set the Authorization header with the access token, in the format Bearer <token>.
Provide seller_id (required) and one of the period or identification filters listed below.
Also provide the page parameter (required, starting at 1) on V3's paginated endpoint and on V4.
Send the request and check the response code in Check the Error Codes, further below.

Provide the Query Parameters

Field	Required	Description
`seller_id`	Yes	The anchor's access key. Alone, it isn't enough: it must be combined with another filter.
`subseller_id` or `subsellerid_ext`	No	Filters the result by partner. These are alternative forms of the same filter. Don't send both together.
`release_status`	No	`S` (payment released) or `N` (payment not released). Requires a `schedule_date` period to also be provided.
`blocks_codes`	No	Restricts the returned blocks. Accepted codes: `TR` (transactions), `CO` (commissions), `AD` (adjustments), `CB` (chargebacks), or `PS` (payments), comma-separated.
`page`	Yes on V4 and on V3's paginated endpoint	The search page, starting at `1`.
`rows_amount`	No	Number of records per page. Each block (summary, details, commission, etc.) counts as one record.

Use the Period or Identification Filters

Use only one of the filters below per request: they can't be combined with each other or with another period filter.

Filter	When to use
`schedule_date_init` / `schedule_date_end`	Loads every schedule item touched in the period, regardless of payment date. Recommended filter for reconciliation.
`transaction_date_init` / `transaction_date_end`	Loads the schedule items for transactions captured in the given period.
`liquidation_date_init` / `liquidation_date_end`	Returns only schedule items whose payment has already been settled (`payments` block populated).
`confirmation_date_init` / `confirmation_date_end`	Loads the schedule items for transactions confirmed in the given period.
`order_id`	Returns every schedule item for every transaction of a specific order (sale and cancellation).
`acquirer_transaction_id`	Returns every schedule item related to the NSU (Número Sequencial Único, the transaction identifier assigned by the acquirer) of a specific transaction, including commissions.

Understand the Return Blocks

The statement is divided into blocks. Each block includes a reference_number: the reference number generated once the balance is netted during the settlement process, which groups together every payout made in that settlement.

Block	Contains
`summary`	Transaction data (sale amount, date, NSU, authorization code, card brand, order number).
`details`	The sale's schedule items. Since schedule items are generated per item, a transaction can have several `details` entries, one per installment (or just one, in the case of Receba-Já).
`commissions`	The schedule items for the commission the anchor charges on the sale.
`adjustments`	Adjustments posted to the schedule, either system-originated (for example, reversal of a negative schedule) or anchor-originated (entries made via API).
`chargeback`	The chargeback adjustment posted to the anchor's own store. Contains the original transaction's data, but doesn't reference a specific item.
`payments` (V4, inside each block above) or `payment_summaries` (V3, its own block)	Details the payments sent and confirmed, stating whether the amount was settled to a free account or under a lien agreement.

Understand the Record Types

The type_register field identifies the nature of each returned entry:

Type	Represents
1	Sales summary, grouping transactional entries.
2	Sales receipts, detailing the type-1 sales.
3	Financial adjustments: credit, debit, chargebacks, and services.
4	System-originated adjustments (such as reversal of a negative schedule) and entries between the anchor's own store and the partner's, including those made by the anchor via API (`adjustment_origin: "M"`).
5	Financial information about the type-1 transactional movements, detailing the payment allocation of each movement made that day.
6	Details of the Receivable Units (UR) consolidated in type 5.
7	Netting (sum and subtraction) of every block with the same `reference_number`. Identifies where the payment was made and whether a lien agreement is associated with it. Does not return type-4 information.

Understand Specific Events in the Statement

Identify the Payment Plan

The payment_plan_name field in details indicates whether the schedule follows the normal payment flow (one installment per details entry, following the sale's installment plan) or Receba-Já (anticipation, always a single details entry, with the plan name in the format "RecebaJá 2 dias"). The anticipation appears as an adjustment in the adjustments block, identifiable by the adjustment_type and operation_identifier_code fields.

Example of details under Receba-Já:

JSON

{
  "type_register": 2,
  "release_status": "S",
  "item_id": "MR001",
  "number_installments": 1,
  "installment": 1,
  "installment_amount": 384334,
  "subseller_rate_amount": 369960,
  "payment_date": "2024-12-06T00:00:00",
  "payment_plan_name": "RecebaJá 2 dias",
  "reference_number": null
}

JSON

1
2
3
4
5
6
7
8
9
10
11
12
{
  "type_register": 2,
  "release_status": "S",
  "item_id": "MR001",
  "number_installments": 1,
  "installment": 1,
  "installment_amount": 384334,
  "subseller_rate_amount": 369960,
  "payment_date": "2024-12-06T00:00:00",
  "payment_plan_name": "RecebaJá 2 dias",
  "reference_number": null
}

Identify Boleto, Prepaid Card, and Two-Card Payment

Paid boleto: summary.product_id = 101 (Santander Boleto) and summary.transaction_type = 7. The details.boleto_payment_date field is populated. When the boleto isn't paid, the details block isn't loaded. A boleto always settles at D+1, regardless of the payment plan. A boleto reversal appears in the adjustments block, in the product_id (101), our_number, nsu_boleto_adjustment, and adjustment_id fields.
Prepaid card: identified by the summary.prepaid_card field, with a value of "S" or "N".
Two-card payment: identified by the payment_tag field in the summary block (for example, "Cartão 1" and "Cartão 2") and by the payment_tag and item_split_tag fields in the details block.

Identify a Blocked Schedule

There's no specific field for a blocked schedule. The condition is identified by combining other fields. If, in the details block, release_status is "S", payment_date is already past due, and the sum of every returned block (details, commissions, adjustments, chargeback, and payments/payment_summaries) is greater than zero, the partner's schedule may be blocked, either by the anchor's own action or by Getnet's fraud prevention.

Recognize a Full Order Cancellation

A cancellation generates a new transaction, referencing the original one. In the original transaction, transaction_status_code changes to 92 (reversed). In the new cancellation transaction, summary.transaction_type = 5 and marketplace_original_transaction_id references the original transaction.

JSON

{
  "type_register": 1,
  "transaction_type": 5,
  "marketplace_original_transaction_id": 75770856,
  "transaction_sign": "-",
  "card_payment_amount": 10000
}

JSON

1
2
3
4
5
6
7
{
  "type_register": 1,
  "transaction_type": 5,
  "marketplace_original_transaction_id": 75770856,
  "transaction_sign": "-",
  "card_payment_amount": 10000
}

Note: When a cancellation occurs, the cancellation transaction's item is already released (release_status: "S") from the start, even if the original item hadn't been released yet. The cancellation transaction's schedule follows the same payment plan as the original transaction.

Recognize a Partial Item Cancellation

In a partial cancellation:

The original transaction keeps transaction_status_code approved, and the original item's amount becomes equal to the non-canceled amount.
The cancellation transaction carries the partial canceled amount in summary.card_payment_amount.
sum_details_card_payment_amount shows the amount already updated after the cancellation.
The cancellation transaction's commissions block carries the refunded commission, with subseller_rate_amount and mdr_rate_amount negative.

Distinguish Chargeback from Chargeback Reversal

A chargeback is always posted to the anchor's own store, in the chargeback block, and doesn't reference a specific item.

Debit (chargeback): transaction_sign: "-", adjustment_type: 4.
Credit (chargeback reversal): transaction_sign: "+", adjustment_type: 25.

The vlr_mdr_marketplace, vlr_fee, and vlr_somaMdrFee fields show the MDR and fee refunded (on debit) or charged again (on reversal).

Interpret Credit and Debit Adjustments

Adjustments appear in the adjustments block with type_register: 4. The adjustment_origin field indicates the origin: "M" for entries made by the anchor via API, or a system origin for the rest. transaction_sign indicates "+" (credit) or "-" (debit).

In the table below, IF stands for Financial Institution and NF for Non-Financial Institution, the same terminology used in Balance API. In the table's numbering, codes 3, 4, and 13 through 17 don't exist.

The API returns the descriptions below in Portuguese; they're listed here as-is, matching what the response actually contains.

Code	Description	Code	Description
1	Ajuste a Crédito	10	Multa Bandeira
2	Ajuste a Débito	11	Ajuste a Débito Estorno do Boleto Loja
5	Saldo de Liquidação Negativa	12	Ajuste a Débito Estorno do Boleto Loja Própria Âncora
6	Crédito para Negativo Expirado	18	Ajuste a débito de cessão de antecipação IF
7	Débito para Negativo Expirado	19	Ajuste a débito de cessão de antecipação NF
8	Ajuste a Crédito Antecipação ST	20	Ajuste a crédito de cessão de antecipação IF
9	Ajuste a Débito Antecipação ST	21	Ajuste a crédito de cessão de antecipação NF

Interpret Negative and Positive Commission

In the commissions block, transaction_sign indicates whether the net amount paid to the anchor is negative (the anchor charged the seller nothing, or a lower rate than the one Getnet charged) or positive (the standard case).

Understand Schedule Netting (Settlement)

Every record sharing the same reference_number was netted and paid together in the same settlement. Record type 7 summarizes that payment:

JSON

{
  "type_register": 7,
  "amount_paid": "1.050,67",
  "contract_number": null,
  "nu_liquid": "202402200000164372294",
  "operation_type": "Liquidação de valor da \"UR\" livre",
  "reference_number": 170456
}

JSON

1
2
3
4
5
6
7
8
{
  "type_register": 7,
  "amount_paid": "1.050,67",
  "contract_number": null,
  "nu_liquid": "202402200000164372294",
  "operation_type": "Liquidação de valor da \"UR\" livre",
  "reference_number": 170456
}

nu_liquid is the settlement identification code generated by Núclea. The contract_number field identifies a lien agreement. When empty, the settlement is for a free UR, as indicated in operation_type.

Check the Error Codes

The API returns the messages below in Portuguese; they're listed here as-is, matching what the response actually contains.

Code	Message
ERR001	Código de autorização inválido.
ERR002	Campo `seller_id` é obrigatório.
ERR003	Tamanho máximo do campo `seller_id`: 50 caracteres.
ERR004	Tamanho máximo do campo `subseller_id`: 10 dígitos.
ERR005	O valor informado para o campo `subseller_id` deve ser numérico.
ERR006	O valor informado para o campo `subseller_id` deve ser maior que zero.
ERR007	Tamanho máximo do campo `acquirer_transaction_id`: 19 dígitos.
ERR008	O valor informado para o campo `acquirer_transaction_id` deve ser numérico.
ERR009	Valor informado para o campo `release_status` é inválido. Valores permitidos: `S` ou `N`.
ERR010	O campo indicado foi preenchido incorretamente. Informe uma data válida no formato `AAAA-MM-DD`.
ERR011	Além do `seller_id`, é necessário informar outro parâmetro para que a consulta seja realizada.
ERR012	É necessário informar os dois campos do intervalo de datas (início e fim).
ERR013	A data inicial informada é maior que a data final.
ERR014	O período máximo de pesquisa entre a data inicial e final foi excedido.
ERR015	Apenas um período de data deve ser informado como filtro da consulta.
ERR016	Ao consultar por `acquirer_transaction_id` ou `order_id`, os campos de período não devem ser informados.
ERR017	Não é possível informar `acquirer_transaction_id` e `order_id` juntos. Informe apenas um deles.
ERR018	Foram informados apenas valores vazios para a lista de códigos de blocos. Informe valores válidos.
ERR019	Os códigos de blocos informados são inválidos. Códigos permitidos: `TR`, `CO`, `AD`, `CB` ou `PS`, separados por vírgula.
ERR020	Para uma consulta paginada é necessário informar o campo `page`.
ERR021	O campo `page` deve conter apenas valores numéricos maiores que 0, limitados a 10 dígitos.
ERR022	O campo `rows_amount` deve conter apenas valores numéricos, limitados a 10 dígitos.
ERR023	A quantidade de registros por página informada em `rows_amount` é maior que o limite configurado.
ERR024	O número da página informado é superior ao total de páginas retornadas para os filtros solicitados.
ERR025	Exceção capturada durante o processamento da consulta.

To reconcile, filter by schedule_date_init and schedule_date_end and group the movements by reference_number, which bundles everything paid together.

Next Steps

Settlement: see the overview of how and when each seller gets paid, including Receba-Já.
Balance API: check the consolidated balance, without the Statement's item-level detail.
Concepts and Glossary: look up the terms used throughout the Split documentation.

On this page

Statement (V3/V4)

Seller Onboarding (PF and PJ)

Balance and Adjustments

Payouts

Reconciliation and Statement

Statement (V3/V4)

Requirements

Choose the API Version

Query the Statement

Provide the Query Parameters

Use the Period or Identification Filters

Understand the Return Blocks

Understand the Record Types

Understand Specific Events in the Statement

Identify the Payment Plan

Identify Boleto, Prepaid Card, and Two-Card Payment

Identify a Blocked Schedule

Recognize a Full Order Cancellation

Recognize a Partial Item Cancellation

Distinguish Chargeback from Chargeback Reversal

Interpret Credit and Debit Adjustments

Interpret Negative and Positive Commission

Understand Schedule Netting (Settlement)

Check the Error Codes

Next Steps