Know where every note is, from cassette to cash bag
Azimut SDK records every device movement as it happens — cash in cassettes and escrow, notes in reject bins, SIM and card stock, printer paper — so replenishment is planned from live positions instead of a count after an outage.
Live inventory positions
Balanced per denominationAppend-only inventory journal
Every movement balanced across locations
Coverage
What inventory handling covers
A kiosk holds value in more places than a single stock count can describe. Cash sits in cassettes, passes through escrow, and ends up in a reject bin, a cash bag, or a customer's hand. SIM and card stock sits in dispensers with its own reject path, and consumables run out on their own schedule. The SDK tracks each position in the same model, so operations see one picture per machine.
Cassettes and recyclers
Remaining and total note counts per cassette and denomination, dispensed and rejected totals, and the cassette status the device reports. Low thresholds can be acted on before a customer session reaches the cash step.
Escrow, rejects, and jams
Notes in the acceptance path, notes the device refused into a reject bin, and movements that ended without a confirmed location after a fault. Each one is a position, not a write-off.
Custody and handover
Cash bags and vault positions move with the notes. Handover and cash-in-transit reconciliation compare against the device's own record instead of a handwritten count.
SIM, card, and consumable stock
SIM dispenser availability and reject bins, card stock for issuance, and receipt paper status are tracked the same way, so service visits are planned around real stock levels.
The journal model
Every movement is recorded, balanced, and kept
Inventory handling is built on a double-entry journal that runs on the kiosk. A dispense moves notes from a cassette to the customer. A deposit moves them from escrow into a store. A rejected note moves to a reject bin. Each entry is balanced across the locations involved, per denomination, and written in the same durable step as the device outcome it describes.
That structure is what makes the numbers trustworthy. A movement that does not balance cannot be recorded, entries are immutable, and corrections are reversing entries rather than edits. When a device sends the same event twice, the stable identity means it is recorded once.
{
"code": "0000",
"message": "SUCCESS",
"data": [
{
"index": 1,
"denomination": 100,
"remainCount": 812,
"totalCount": 1000,
"outCount": 188,
"rejectCount": 0,
"status": "OK"
}
],
"errors": null
}Record the movement
Each dispense, deposit, reject, or handover is written as a balanced entry across locations — customer, cassette, reject bin, cash bag, vault. Entries are immutable, and a movement that cannot be balanced cannot be recorded.
Replicate under a stable identity
The entry is marked as sent before the network call leaves the kiosk, so a power cut between send and acknowledgement cannot lose the movement. A retry carries the same identity, so nothing is counted twice.
Settle or reconcile
An acknowledged entry settles. An ambiguous response stays open for retry, and a movement whose location is genuinely unknown becomes reconciliation work for an operator — recorded as an adjustment, never an edit.
Reconciliation
Uncertainty is recorded, not guessed away
Cash handling produces moments that are genuinely ambiguous: a jam mid-transport, a power cut during a dispense, a device reply that never arrives. Older integrations tend to resolve that by assuming a location — crediting or writing off a note that may still be inside the machine.
The journal keeps a position for notes known to exist but not yet located. It surfaces as reconciliation work, an operator resolves it with a recorded adjustment, and the original entry stays in history with its evidence. That is the difference between a record that can answer "what did this kiosk send?" months later and one that cannot.
Retries without double-counting
Replication carries a stable identity, so a lost acknowledgement is retried rather than reconstructed.
Audit that survives scrutiny
Every entry keeps its source and evidence, and corrections are visible as their own entries.
Works with your back office
Positions and movements can feed existing cash management, CIT, or reconciliation workflows.
Mixed device fleets
Dispensers, recyclers, acceptors, and dispensers from different vendors report into one journal.
Operations
Replenishment planned from live levels
A cassette that runs empty mid-session stops the machine for every customer behind it. Readiness checks and cassette positions are available before a flow starts, so an application can pull a cash step from the screen, keep the session in a safe state, and let operations dispatch a refill on its own schedule.
Across a fleet, the same positions answer the planning questions: which machines are close to empty, which denominations need a different mix, which ones are carrying more than they need, and where a service visit can combine a refill with a known fault. Because movements carry the transaction they belong to, the replenishment record and the transaction record reconcile against each other.
From the same JSON API
Inventory status is exposed alongside dispensing, printing, and identity operations. One contract, any language — see the SDK and its JSON API.
Questions
Inventory handling, answered
The details operations and engineering teams ask before they put a cash-handling fleet on an inventory model.
Put inventory handling on your fleet
Tell us which devices you run and how your cash or stock operation reconciles today. We will walk through the journal model, the API, and what a deployment looks like.