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.
Statements, reporting and reconciliation
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.
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.
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.
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.
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.
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.
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.
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.
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.
No universal assumption is safe. Transaction status, capture timing, batch cutoff, channel, account, and provider rules can change which batch contains an item.
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.
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