Statements, reporting and reconciliation
Reconcile POS sales to processor batches by comparing the same card-payment activity across both systems. Match the business date, location, currency, payment status, and batch boundary first. Then account for tips, refunds, voids, reversals, and transactions that crossed the cutoff.
A POS sales total and a processor batch total do not always describe the same scope. The POS may report cash, gift cards, or other tenders alongside card payments, while the processor report covers only activity submitted through that processing account. Use each provider's report definitions rather than assuming two similarly named totals are equivalent.
Start with the processor's completed batch or settlement detail. Record its batch identifier, open and close times, location or merchant account, currency, transaction count, and card-payment total. In the POS, filter to the same location, payment type, currency, and time boundary. Compare completed card transactions before comparing any later bank transfer.
Current Square reporting guidance separates sales and transaction reports and provides a workflow for matching transfers to sales. Stripe's current payout documentation likewise explains that automatic payouts may include multiple transactions and offers itemized reconciliation reports for the transactions associated with a payout. These examples support matching activity through detailed records, but report names and batch behavior vary by provider.
For related terminology and report concepts, use the statements, reporting and reconciliation FAQ hub.
A POS business day may follow store hours, while a processing batch may close automatically or at a configured time. Record both boundaries. Activity after the batch cutoff may belong to the next processor batch even when the POS assigns it to the earlier business date.
Compare one POS location with the processor account or merchant identifier that receives its card transactions. If several registers feed one account, combine only the registers known to share that reporting scope.
Limit the POS side to the card tenders and completed statuses represented by the processor batch. Exclude cash and unrelated tenders. Keep open checks, authorizations awaiting completion, and declined attempts separate from completed activity.
The payment processing glossary can help distinguish batches, settlements, transfers, and other terms used by different systems.
Keep a simple reconciliation worksheet with separate columns for the POS reference, processor reference, amount, status, business date, batch ID, and explanation. This makes the review repeatable without altering the original reports. For broader help reading processor documents, visit Merchant Statement Help.
If totals do not match, look for scope and timing differences before assuming a processing error. Tips may be added after an initial authorization and included only after a payment is completed. A refund can appear as a separate negative entry rather than changing the original sale. A void may remain visible in a POS activity log but not contribute to a completed processor batch.
Also check for transactions captured after the cutoff, activity from another register or location, offline transactions uploaded later, and payment records still awaiting completion. Compare the processor's itemized batch detail with the POS transaction detail one record at a time. A bank transfer should be a later checkpoint, because its grouping and timing may differ from a single POS business day or processing batch.
When report labels are unclear, ask the POS or processing provider which event controls the report date and which statuses are included. Avoid applying one provider's labels or workflow to another system without confirmation.
POS exports and processor reports can contain customer information and sensitive business identifiers. Store them in an access-controlled location, share them only with people who need them, and follow the retention policy established for the business. Use masked references whenever possible.
Do not paste cardholder data, bank credentials, passwords, secret API keys, complete account numbers, or unredacted reports into email or a general contact form. If a provider needs a report for support, use its approved secure channel and confirm what fields should be redacted.
If the counts and totals match after the filters are aligned, save the reports, worksheet, and batch identifier together. If they do not match, isolate the first unmatched transaction and trace its timestamp and status across both systems before expanding the review.
For help evaluating a reporting workflow, contact Payments Max with a high-level description of the POS report, processor report, and mismatch type. Do not submit cardholder data, credentials, complete account numbers, or unredacted exports 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
