Closing the Batch: Where the Day’s Money Goes

Authorizing a card, capturing the transaction and closing the batch are three separate events, and the gaps between them cost money in very different sizes. On $124,800 of monthly card volume, interchange downgrades from late settlement cost about $72 a month while ten uncaptured authorizations cost $1,200. The fee consequence is the one people worry about and it is seventeen times the smaller problem. Here is why the expensive one is invisible, and the four-minute check that finds it.

What closing a batch actually does

Authorizing a card reserves funds. Capturing the transaction tells the processor to collect them. Closing the batch submits the day's captures for settlement, which is what starts the clock on money reaching your bank.

Those are three separate events, and in most terminal setups the third one happens because someone does it or because a timer does it. Per our authorization analysis, the gap between them is where the operational problems live.

• An authorized but uncaptured transaction expires, and the sale is lost.
• A captured but unbatched transaction sits waiting, and funding does not begin.
• A batch closed after the processor's cutoff is treated as the next day's batch.
• A batch never closed may auto-close at a time you did not choose, or not at all.

What delay costs

Take a business taking $4,800 a day in card volume across 26 trading days, so about $124,800 a month, with an average ticket of $120.

Three distinct costs, and they are very different sizes:

Failure	Monthly cost
Three batches closed late: $14,400 delayed by a funding day	Timing only, no fee
Late-settled transactions downgrading at an extra 0.50%	$72
Ten authorizations never captured at a $120 ticket	$1,200

That ratio should redirect the attention. Per our interchange analysis, downgrade risk from delayed settlement is real and modest. A transaction that was authorized, delivered against, and never captured is the entire sale, and ten of those a month is $14,400 a year of work performed and not billed, which per our quoting analysis is margin erosion of exactly the kind that never appears in a monthly review.

Per our reconciliation analysis, the reason it goes unnoticed is that an uncaptured authorization appears nowhere: it is not a failed payment, not a refund, and not a discrepancy between two numbers. It is an absence, and absences do not appear in reports that list what happened.

Where the gaps come from

1. An open tab or ticket never closed out. The customer left, the authorization sits, nobody captures it.
2. A terminal that lost connectivity during the day, holding offline transactions that never uploaded.
3. Multiple terminals where one is batched nightly and one is forgotten.
4. Staff turnover, per our institutional memory analysis, where whoever knew the closing routine left and the successor learned most of it.
5. A pre-authorization for a service that was completed and invoiced separately, per our authorization holds analysis, so the hold expires rather than capturing.
6. Weekend and holiday cutoffs, where a Friday evening batch funds on Tuesday and nobody is tracking it, which per our latency analysis is three days of working capital nobody priced.

Item three is the most common cause in businesses with more than one register and the easiest to miss, because the batch report from the terminal that did close looks complete. Nothing in it indicates another device also had transactions.

Item two is the most expensive when it happens. Transactions stored offline on a terminal are not merely unbatched, they are unauthorized in some configurations, which means a decline that would have happened at the point of sale instead happens days later with the customer gone.

Automatic close and why it is not enough

Most terminals can be set to close automatically at a fixed time, which removes the main human failure and introduces three others.

• An open ticket at the auto-close time is still open, so the authorization is still uncaptured and the automation did not help.
• The auto-close time may sit after the processor cutoff, which costs a funding day every single day without anyone noticing.
• A failed automatic close is silent. Nobody was watching, so nothing reports it.
• Trading past the auto-close time puts the rest of the evening into the next day's batch.

The second bullet is worth checking today. If your auto-close runs at 11pm and your processor's cutoff is 9pm local, every batch you close is a next-day batch and you have been losing a funding day on every transaction since it was configured. Per our funding analysis, that shows up as funding being consistently a day slower than the schedule says, which is usually attributed to the processor.

The third bullet is the argument for a positive confirmation rather than an assumption. Automation that reports success is a control; automation that reports nothing is a hope.

Setting it up properly

1. Find out your processor's cutoff time, in your own time zone, and write it down.
2. Set auto-close at least an hour before it, not after.
3. Close manually if you trade past that time, and close a second batch.
4. Batch every device, and keep a list of devices, including the one in the back and the mobile reader someone takes to events.
5. Require a close-out of all open tickets before the batch, as a step in the closing routine rather than an assumption.
6. Confirm the batch was received, not merely sent, per our notice analysis, since transmitted and received are different.
7. Reconcile the three numbers daily, as above.
8. Check offline transaction storage after any connectivity problem, before the day is treated as closed.

Item one is the single highest-return action in this article and takes one phone call. A surprising number of businesses do not know their cutoff, which means they cannot know whether their close time is on the right side of it, and the consequence is a permanent one-day funding delay that is invisible because it is consistent.

Item five is what prevents the $1,200. Uncaptured authorizations are almost entirely open tickets, so a closing routine that requires zero open tickets before batching eliminates the largest cost in the table above.

The monthly check

Check	What it catches
Count of batches against trading days	A missing batch, which is otherwise invisible
Authorizations with no matching capture	The expensive one, per our authorization analysis
Average days from sale to funding	A cutoff misconfiguration, which shows as a consistent extra day
Interchange downgrades by reason	Whether late settlement is actually costing you anything
Batch totals against deposits	A batch that settled for less than it contained
Transactions by device	A terminal that stopped contributing, which usually means it stopped batching

The first row is the simplest and most neglected check in merchant operations. Twenty-six trading days should produce twenty-six batches. If the statement shows twenty-four, two days of transactions went somewhere, and nothing else in the statement will tell you that, because the batches that did happen all look correct.

The last row catches the multi-device failure from the other direction. A device whose transaction count falls to zero has either stopped being used or stopped reporting, and per our reconciliation analysis the second is far more common and looks identical in every report that only counts what arrived.

Frequently asked questions

---

This guide is educational and does not constitute payments, accounting, or compliance advice. All figures are stylized illustrations using assumed volumes, tickets, downgrade rates, and failure counts, and do not describe any particular merchant or processor. Cutoff times, batching and auto-close behaviour, authorization expiry periods, offline transaction handling, interchange qualification rules, and funding schedules vary by processor, by terminal, by card network, and by jurisdiction, and change over time. Confirm your own cutoff times and settlement behaviour with your acquirer.