
Guides
ATM route software: KPIs to track before buying
ATM route software decisions start with six data types and six KPIs, then test six practical requirements and three reports before you buy.
What to take away
- Decide what you need your ATM route software to tell you before you decide what to buy. Almost every software disappointment in this trade is a purchase made in the other order.
- A route needs six kinds of data, and most of it already exists in your processor's reports and your own visit logs.
- The number that matters most is per machine, per month, and it is completed withdrawals. Every other measure explains that one.
- Data you cannot export is data you have rented. Ask about export before you ask about features.
- A small route runs well on a maintained spreadsheet. The trigger for software is the number of reconciliations you can no longer do reliably by hand.
Operators buy monitoring, then a route app, then something for the books, and end up with three systems that disagree. This guide starts from the other end: what a route has to know, where that information comes from, and what a system is actually for.
The six kinds of data a route runs on
The six kinds of data
| Data | Where it comes from | What it answers |
|---|---|---|
| Transaction counts and values | The processor, per machine, per period | Whether a placement is working |
| Machine state | Monitoring or the machine itself | Who needs a visit today |
| Cash movements | Your own load and count records | How much capital is committed and where |
| Settlement | Bank and processor records | Whether the money came back and when |
| Faults and visits | Your own logs, written at the time | Why a machine underperforms |
| Agreements and hosts | Your own files | What you owe each venue and when it ends |
Only two of those six come from a vendor. The other four are yours to record, and no software creates them if the habit does not exist.
Six data sources
Vendor
- Transaction counts
- Yes
- Machine state
- Yes
- Cash movements
- No
- Settlement
- No
- Faults and visits
- No
- Agreements and hosts
- No
Yours
- Transaction counts
- No
- Machine state
- No
- Cash movements
- Yes
- Settlement
- Yes
- Faults and visits
- Yes
- Agreements and hosts
- Yes
The measures that actually change a decision
Keep the set small. A measure that never changes an action is a measure you should stop collecting.
Six decision-changing measures
- Completed withdrawals per machine per month
- Hours unavailable per machine, with cause
- Time to know a machine stopped
- Contribution per withdrawal
- Cash committed per machine
- Unexplained differences, count and value
Completed withdrawals per machine per month. The number the whole business rests on. Take it from the processor, not from the machine, and reconcile the two.
Hours unavailable per machine, with the cause. Downtime is revenue that does not come back, and the cause column is what makes it actionable.
Time to know. The gap between a machine stopping and you finding out. Usually the cheapest thing on the list to improve.
Contribution per withdrawal. What is left after the host share and the variable costs, calculated as set out in the pricing and profit guide.
Cash committed per machine. The load plus the amount dispensed but not yet settled. This is the measure that tells you what growth will cost.
Unexplained differences. Count and value, per period, closed or open.
Six numbers. If your systems cannot produce them, more features will not help.
What a system has to do, in order
What a system has to do
- Hold the data above without you retyping anything twice.
- Let you export all of it, in a form you can read without the vendor.
- Tell you which machines need a visit, early enough to act.
- Reconcile machine totals against processor reports against your counts.
- Keep a record you could hand to an accountant, a bank or an adviser.
- Keep working when you are on the road with poor signal.
Anything beyond those six is convenience. Convenience is worth paying for, but not before the six.
System requirements in order
- Hold data without retyping
- Export all data readably
- Flag machines needing visits early
- Reconcile machine, processor, counts
- Keep records for accountant or bank
- Work on the road with poor signal
Export is the question nobody asks
Ask any vendor how you get all your data out, in what format, and whether that includes historic records. Ask what happens to it if you stop paying.
A route's history is its most valuable asset after the placements themselves. It is how you value a site, defend a commission, satisfy a bank, or sell the business. Data you cannot retrieve is not yours.
Keep retention straight too: business records must support your books, as the IRS guidance on records a business should keep explains.
Your processor, sponsoring bank, and regulatory position create other retention duties, mapped in the licensing and compliance overview.
Security is part of the specification
These systems hold site addresses, access notes, machine states and transaction data. That is a useful package for the wrong person, and a small operation is not too small to be worth their time.
Security specification items
- Access control
- Updates
- Backups
- Processor and bank requirements in writing
Treat access control, updates and backups as part of what you are buying, not something to sort out later. The NIST small business quick-start guides show how a business this size can approach it without a security team.
Your processor and sponsoring bank will have their own requirements about the machine and the data. Put those in writing, not in memory. The physical side of the same problem is in the repair and security guide.
When a spreadsheet stops being enough
Not at a machine count. At a workload.
Signals spreadsheet is not enough
- Reconciliations done two days late
- Difference you cannot trace
- Two versions of the sheet exist
- Fault learned from host, not monitoring
The signals are consistent: reconciliations done two days late, a difference you cannot trace because two versions of the sheet exist, or a fault you learned about from the host because nobody read the monitoring. At that point the constraint is your attention, and software helps by removing steps rather than by adding views.
Until then, a maintained sheet with the six measures in it beats a system nobody updates. The routine that fills either of them is in the operations and workflow guide.
Buying without regretting it
Write the six measures and the six requirements on one page. Give it to each vendor and ask them to show you, with your own data, how each is produced. Then run a real trial on part of the route, not a demonstration.
Do not buy on the strength of a feature list. Do not buy something that cannot be exported. And do not buy a system sized for a fleet ten times your route, because you will pay for administration you do not need and get support attention appropriate to your invoice.
Stock and equipment records the system must carry are in the inventory and sourcing guide.
What you can honestly say about the service it lets you deliver is in the marketing and growth guide.
Three reports worth building once
Whatever holds your data, build these three and read them on a schedule.
The machine page. One machine, twelve months: withdrawals, value, hours unavailable, contribution, cash committed. This is what you look at before deciding to reprice, renegotiate or remove a placement, and it is what a buyer of the route would ask for.
The exception list. Every open difference and every fault older than your own standard, with a name and a date against each. Short by design. When it grows, something in the routine has slipped rather than something in the software.
The commitment sheet. Cash committed per machine, totaled, set beside the money you actually have. This is the report that answers whether you can add a placement, and almost no operator builds it until the answer has already been no for a month.
None of the three needs a product. They need the six kinds of data above to exist somewhere you can query, which is the whole argument for recording things at the time rather than reconstructing them later.
The banking view of your records
Your bank forms a view of the operation partly from how well you can answer questions about it. An operator who can produce counts, settlements and differences on request is a straightforward relationship. One who reconstructs them is not.
That review is meant to be risk-based rather than categorical, which is what the FinCEN statement on independent ATM operators asks of banks. Good records are how you make that assessment easy.
Common questions
Do I need dedicated route software?
Only when the volume of reconciliation and scheduling exceeds what you will reliably do by hand. Before that, it usually adds a place where data can disagree with itself.
Should monitoring, accounting and routing be one system?
Fewer systems means fewer disagreements, but a single system that does one job badly is worse than two that each do theirs. Judge it on whether the six measures come out cleanly.
How far back should I keep data?
Longer than you think, because valuing a site or answering a question a year later needs history. Confirm the actual retention duties with your accountant, processor and adviser rather than picking a number.
What is the most common measurement mistake?
Using an average across the route where a per-machine figure was needed. It makes a weak placement invisible and a strong one look ordinary.







