Batch reports

These are the endpoints you reconcile against. A deposit in the merchant's bank account corresponds to a batch, not to a transaction, so matching the two means reading batches.

This endpoint pages differently from the transaction endpoints. It takes skip and take where transactions take offset and limit, and sort_column where transactions take sort_by. The two were built at different times and have not been reconciled.

last_checked_at returns what has changed since that timestamp, which makes this the endpoint to poll on a schedule rather than re-listing everything.

Once a batch has an ID, ask for its contents directly.

include_bad_transactions defaults to false. Turn it on when you are investigating a mismatch — a batch total that does not agree with your own figures often has an excluded transaction behind it.

A batch has no ID until it exists, so there is a separate endpoint for the batch that is still accumulating.

Use it to see what will settle at the next close. It takes client_id, integration, created_at, a timezone from the supported list, and card_type.

card_type here is not the same parameter as on GET /v1/transactions. It is narrower:

On this endpoint CREDIT also returns the rows whose card type was never determined, which is the behavior UNKNOWN gives you on the other one.

The order that works:

1. Poll GET /v1/batches/status with last_checked_at to find closed batches.
2. For each, read GET /v1/batches/{id}/transactions.
3. Match the batch total against the deposit.
4. When they disagree, re-read with include_bad_transactions=true.

For ACH, keep watching after settlement. A return can arrive days later and will not appear in the batch you already reconciled. See Find and report on transactions.

• Batches and settlement
• Find and report on transactions
• Client reports