The five records behind every ATM day
ATM balancing is hard because no single file tells the whole story. The journal knows what the machine physically did. The host knows what it approved and posted. The network knows what it settled between institutions. The cash records know what went into and came out of the cassettes. The ledger only knows what somebody posted. A shortage is simply the place where two of those stories disagree, and the software has to hold all five to say which two.
| Source | What it records | What it proves | What it cannot tell you |
|---|---|---|---|
| Electronic journal | Card reads, dispenses, deposits and device errors at the terminal | What the machine physically did, note by note | Whether the host posted it |
| Switch or processor log | Authorizations, completions and reversals as the host saw them | What was approved and what the cardholder was charged | Whether cash actually left the cassette |
| Network settlement report | Foreign card activity, interchange and fees by network and settlement day | What your institution owes or is owed across each EFT network | Anything about your own cardholders at your own ATMs |
| Cash records | Cassette loads, pickups, counts and armored carrier deliveries | The cash position of each terminal per cycle | Which transaction caused a difference |
| General ledger | ATM cash, settlement and suspense account postings | What the books say | Whether the books match the machine |
The breaks ATM balancing actually produces
Across fleets the same six differences account for nearly all of the daily work. Naming them consistently is what lets a team stop investigating a fee as a mystery and start measuring which cause is growing.
| Break | How it shows up | Usual cause | Suggested action |
|---|---|---|---|
| Shortage on a cycle | Counted cash is below load minus journal dispenses | A dispense the journal recorded and the host never posted, or a loading or counting error | Trace the journal lines for the cycle against host reversals, then propose a write-off under approval if nothing explains it |
| Overage on a cycle | More cash in the cassettes than the host postings imply | A partial or failed dispense where the cardholder was still debited | Confirm the fault in the journal, open a dispute item and credit the cardholder once confirmed |
| Cutover timing | Late withdrawals appear on the next settlement day | Different business day boundaries between switch, network and GL | Match against the next settlement day and age from the cutover, not the transaction time |
| Settlement difference | Network settlement total differs from switch activity for the day | Interchange, surcharge or network fees netted into the settlement | Model the fee schedule so the net matches, and investigate only what remains |
| Deposit discrepancy | The amount read at the ATM differs from the verified deposit | Misread checks, mixed notes, envelope deposits | Adjust under maker-checker with the image or count attached |
| Unmatched reversal | A reversal with no original, or one original with two reversals | Communication timeouts and duplicate reversal messages | Tie the reversal to its original and reverse the duplicate under approval |
From one cycle to one worked item
Input
- Cash records · load 60,000.00 USD · pickup count 18,340.00 USD
- Host postings · 208 completions · 41,860.00 USD
- Electronic journal · 207 dispenses · 41,660.00 USD · 1 dispense fault at 21:14, 200.00 USD not presented
Output
- Overage 200.00 USD against the GL. The count agrees with the journal, and the host debited a cardholder for cash the machine never presented.
- Suggested action: confirm the fault in the journal lines, open a dispute item on the cardholder account, propose the credit and the cash posting under maker-checker.
- Routed to Card and ATM Operations, aged from the cycle close, journal lines and count sheet attached.
Reg E error resolution runs on the same evidence
When a cardholder reports that an ATM did not dispense, Regulation E starts a clock. Under 12 CFR 1005.11 an institution generally has 10 business days to investigate, or up to 45 days if it provisionally credits the account within those 10 business days, with longer windows for new accounts, point of sale and foreign-initiated transactions. The investigation itself is a reconciliation question: did the journal record the dispense, did the host post it, and does the count for that cycle show the cash left the machine.
When ATM balancing lives in a spreadsheet, every dispute is a fresh hunt through journal files. When the cycle is already reconciled, the answer is usually sitting on an overage item before the cardholder calls. Bankautomation holds the evidence and the approval trail. It does not decide the claim: the determination and the notice to the cardholder stay with your team, which is where the regulation puts them.
ATM reconciliation software compared with the alternatives
Banks and credit unions usually choose between four approaches. None is wrong for everyone. The right one depends on fleet size, how many networks you settle with, and whether ATM balancing sits with a dedicated team or with the accounting department.
| Approach | Good at | Weak at | Fits |
|---|---|---|---|
| Spreadsheets and the core balancing screen | No new vendor, familiar to the team | No aging, no audit trail, every dispute researched from scratch | A handful of terminals and one network |
| ATM channel management suites, for example NCR Atleos | Device, cash and transaction balancing data from the vendor that runs the fleet | Reconciliations outside the ATM channel, such as nostro or payments | Large fleets standardized on one ATM vendor |
| General reconciliation platforms, for example Trintech or ReconArt | Account certification and the month-end close across the balance sheet | Daily terminal cycles unless configured for them, and pricing is usually quoted | Institutions buying one close and certification platform |
| Bankautomation | Daily exception work: ATM and card settlement, nostro and payments in one worklist, with published pricing | Not a cash forecasting tool and not a close checklist, and it does not manage the ATM devices | Operations teams that want ATM balancing to be an owned, aged queue next to their other reconciliations |
What ATM reconciliation software costs
ATM reconciliation is sold three ways: bundled into an ATM vendor or processor contract, quoted per institution by reconciliation vendors, or published per plan. Bankautomation publishes its prices. The Operations plan is $1,200 a month for one process line, 250,000 matched items a month and three source connections. An ATM program usually needs more than three sources (journal, switch, network settlement, cash records and the GL), so most ATM teams land on the Platform plan at $3,900 a month, which adds unlimited source connections, maker-checker approvals and SSO. Every limit is on the pricing page.
How to roll it out without a project
Step 01
Pick one segment of the fleet
Start with the terminals that eat the most balancing time, often deposit-taking ATMs at busy branches, rather than the whole fleet at once.
Step 02
Map the sources once
Journal extract, switch activity, the settlement report for each network and the GL accounts. Each layout becomes a versioned mapping, not an integration build.
Step 03
Agree the tolerances
Cutover window, fee schedule per network and the dollar threshold below which a count difference is logged rather than investigated, each approved and recorded.
Step 04
Run in parallel for a few cycles
Compare the worklist with the spreadsheet your team already keeps. When the two agree, retire the spreadsheet for that segment and add the next one.
Try the card and ATM settlement sample
The resolver at the top of this page opens on the card settlement queue, which includes an ATM settlement line against core postings. Move the amount tolerance and watch which differences are absorbed and which stay as breaks. That is the control you are buying, on sample data, before you speak to anyone. The same engine runs payment reconciliation and nostro reconciliation, so ATM balancing does not need a tool of its own.
Sample data only. The demo never receives production or cardholder data, and nothing you paste into it is stored.
Questions about atm reconciliation software
How often should ATMs be balanced?
Transaction activity should be reconciled daily and cash at every replenishment cycle. The daily run catches cutover and settlement differences while the journal is fresh, and the cycle balance is where shortages and overages are confirmed against a physical count. Terminals with deposit modules often need a closer look, because deposits add a second source of differences.
What causes ATM shortages and overages?
Most shortages come from dispenses the journal recorded and the host never posted, often after a communication timeout, plus loading and counting errors. Most overages come from partial or failed dispenses where the cardholder was still debited. Reconciling journal, host postings and the count for each cycle separates those causes instead of lumping them into one variance.
What is ATM settlement reconciliation?
It is matching the daily settlement your institution receives or pays over each EFT network, such as STAR, Pulse, NYCE or CO-OP, against the switch activity behind it and the settlement account in your GL. Settlement nets withdrawals, interchange and fees into one amount per day, so the fee schedule has to be modeled for the totals to agree.
Can ATM reconciliation software help with Reg E disputes?
It can hold the evidence a Regulation E investigation needs on one item: the journal lines, the host posting, the cycle count and the approval trail. The decision on the claim and the notice to the cardholder stay with your team. Bankautomation is operations software and does not make compliance determinations.
Does it work with our core and our ATM processor?
Sources are read as files: journal extracts, switch or processor activity, network settlement reports and core GL exports, including plain CSV. Field mapping is configuration rather than an integration project, so the usual first step is a sample file from each source rather than an API build.
Is it for banks only, or credit unions too?
Both. The problem has the same shape at a community bank and a credit union: a fleet of terminals, several networks, a processor and a GL. Plans are sized by matched items and source connections, not by charter type. Credit union specifics, including share draft clearing and shared branching settlement, are on credit union reconciliation software, and the rest of the balance sheet is on account reconciliation software.