Statement and reconciliation

Daily reconciliation is mandatory. It is the control that catches the transactions your webhooks missed, the credits that were applied twice, and the withdrawals that silently failed.

API: GET /v1/statement, GET /v1/statements/consolidated

The daily routine

1. Fetch the consolidated summary with GET /v1/statements/consolidated.
2. Fetch the individual movements with GET /v1/statement, filtered by date.
3. Join LB Pay's records to yours on endToEndId.
4. Compare totalBalance from GET /v1/balance/closing-day against your computed balance.
5. Investigate every divergence before opening the next day.

Query limits

Two constraints will bite on the first call:

• A filter is mandatory. Either a date range or an endToEndId / productTransactionId. An unfiltered call returns MISSING_REQUIRED_FILTER.
• The date range cannot exceed 90 days. Longer ranges return INVALID_DATE_RANGE, so backfills must be paginated by period.

Not everything is a PIX

The statement also carries fees and judicial movements, distinguished by the method field (pix, tarifa, judicialMovement).

A reconciliation that only sums PIX will never balance

Fees debited as tarifa move real money out of your account. Ignoring them produces a divergence that grows daily and looks like a mystery.

Looking up a single transaction

GET /v1/statement accepts the endToEndId, which is how you answer a support question about one specific payment.

You can also look a transaction up directly in the internet banking, which accepts different identifiers per operation:

Operation	Search by
Deposit	chargeId, externalId or endToEndId
Withdrawal	externalId, transactionId or endToEndId

Storing all of them is what keeps that search possible from either side.

Store the endToEndId on every transaction

This is checklist item 26 and it is not optional. Without it stored on your side, you cannot join your ledger to LB Pay's, cannot issue a refund, and cannot investigate a dispute.

What to look for

Symptom	Likely cause
Transaction in LB Pay, absent from your ledger	Lost webhook — check contingency polling
Credited twice on your side	Missing webhook deduplication — see Credit exactly once
Two settlements for one player intent	Reused or regenerated externalId — see Idempotency
Withdrawal debited but never settled	Stuck in a transitional state; no sweeping job
Balance mismatch with no obvious transaction	Refund or CPF Shield reversal not recorded — see Ownership rules

Statement semantics

Statement lines are settled movements, not pending operations. A charge still PENDING does not appear on the statement — it shows in pendingBalance until it settles.

Related

• Balance

Error codes

Routes: GET /v1/statement, GET /v1/statements/consolidated

HTTP	Error code	Description
400	INVALID_DATE_RANGE	initDate / endDate invalid, in the future, or range exceeds 90 days
400	MISSING_REQUIRED_FILTER	Provide a date range or filter by endToEndId / productTransactionId
400	INVALID_PAGE_SIZE	pageSize must be between 1 and 100
400	INVALID_QUERY_PARAMETER	Malformed query parameter
400	InvalidParameter	Consolidated — invalid or missing startDate / endDate, page or limit
404	ACCOUNT_NOT_FOUND	Account not found

See HTTP errors for the codes shared by every route.