Statements, reporting and reconciliation

What is a batch summary report?

A batch summary report is a high-level record of payment activity grouped into a batch. It commonly shows aggregate information such as the number or amount of sales and credits submitted for settlement, along with identifiers or dates that help a merchant locate the related detail.

The exact name, fields, cutoff time, grouping rules, and connection to a bank payout depend on the payment provider and account setup. Treat the summary as a map to the underlying transactions, not as proof that every item has reached the bank or that every report uses the same date boundary.

The short answer

Payment transactions that are submitted for settlement may be organized into groups called settlement batches. Current Braintree documentation describes its Settlement Batch Summary as a report of total sales and credits for each batch. Its reporting overview also explains that the report lists transactions in a settlement batch by payment method. These are useful examples of what a batch summary can contain, but they are not universal field requirements.

A merchant may encounter a terminal batch report, gateway settlement summary, processor batch view, or payout reconciliation screen. Start with the provider's current definition and the statements, reporting and reconciliation hub before comparing totals across systems.

What to look for on the report

Batch identity

Look for a batch number, settlement date, account or location label, and any reference that connects the summary to transaction detail. A date by itself may not identify the same operating period used by the POS system.

Activity totals

The report may summarize sale and credit counts or amounts, sometimes with a payment-method breakdown. Confirm whether refunds, voids, reversals, or other adjustments appear in the batch, appear separately, or follow a different reporting path.

Status and timing

Check whether the batch is open, closed, submitted, settled, or represented by another provider-defined status. Record the cutoff time and time zone because late transactions may move to the next batch.

When the summary does not explain a difference, use the related guide on why a transaction may be missing from a batch rather than resubmitting the payment.

How a batch summary differs from other reports

A batch summary usually answers which activity was grouped together for a settlement step. A POS sales report answers what the operating system recorded as sales during its selected business period. A transaction export provides itemized payment records. A payout or deposit report explains which activity is associated with money sent to a bank account. Those reports can overlap without being interchangeable.

Stripe's current payout reconciliation documentation illustrates the distinction. Its report can group transactions associated with an automatic payout as a settlement batch and provides both summary and itemized downloads. Stripe also notes that manually controlled or instant payouts require a different reconciliation approach because the platform cannot always identify a provider-created transaction grouping for them. This provider-specific example reinforces a general review principle: verify the report's purpose before expecting its total to equal another system's total.

For a workflow that connects operating records to processing records, read how to reconcile POS sales to processor batches.

A repeatable review process

  1. Identify the source. Record the provider, merchant account or business unit, report name, date range, time zone, and filters.
  2. Confirm the batch boundary. Determine which event and cutoff place a transaction into the batch. Do not assume that the POS business day and settlement day end at the same moment.
  3. Compare counts before amounts. Check whether the number of sales, credits, or other listed events agrees with the itemized report for the same boundary.
  4. Trace a small sample. Match several non-sensitive transaction references from the detail to the summary, including an ordinary sale and any separately reported adjustment.
  5. Connect the next record. Use the provider's documented batch, settlement, payout, or deposit reference to continue the reconciliation.
  6. Document exceptions. Preserve the exact field label, expected total, actual total, source report, owner, and next action without altering the original export.

If detailed data is needed, review how to export credit card processing data. For the next stage of the workflow, see how to reconcile batches to bank deposits.

Why totals may not match immediately

A mismatch does not automatically mean a transaction is lost. The POS report and batch report may use different time zones, business-day settings, statuses, or inclusion rules. A transaction can be authorized during one period and captured or submitted during another. Refunds and other changes may also appear in a later report or separate category.

Multiple merchant accounts, locations, terminals, ecommerce channels, or payment methods can create additional groupings. Braintree notes that its batch cutoff depends on account setup and that certain payment types can be excluded from its summary. That is why a merchant should preserve filters and ask the responsible provider to define an unfamiliar field instead of forcing two totals to agree.

When a partial refund is part of the difference, the page on how partial refunds appear in reports provides a focused review method.

Common batch summary questions

Does a batch summary equal a bank deposit?

Not necessarily. A deposit can follow a different timing boundary or relate to one or more grouped records. Use the provider's documented identifiers and payout or deposit detail to make the connection.

Should every POS sale appear in the same batch?

No universal assumption is safe. Transaction status, capture timing, batch cutoff, channel, account, and provider rules can change which batch contains an item.

Is the summary enough to investigate an exception?

Usually the itemized report is also needed. Use masked transaction references, dates, amounts, and statuses to trace the exception while keeping sensitive data out of general notes and messages.

Choose the next reporting step

First confirm the batch definition, cutoff, identifiers, statuses, and included transaction types with the provider that produced the report. Then compare a small itemized sample and document any timing or filter differences before escalating an exception.

If you need help organizing provider questions and a provider-neutral reconciliation workflow, contact Payments Max with a high-level description of the report names and issue. Do not submit cardholder data, passwords, bank credentials, complete account numbers, secret API keys, or unredacted reports through the general form.

To learn more about how TSYS can help improve the way your organization accepts payments, markets to new customers, or manages its HR responsibilities, get in touch by calling 585-981-8463 to get started.

CONTACT US