Published 2026-09-08 · LuckyMDM Blog
The short answer: one rented device needs two statuses recorded at the same time. Contract status says who owes what and who carries the liability. Physical status says where the handset is right now and whether a command can still reach it. Record only one of the two and the ledger will be wrong exactly when you need it.
Summary. The two statuses are driven by two different chains of events with two different clocks, so they drift apart and never self-correct. This page sets out the allowed values for each, the nine cell combinations that only appear once you cross the two columns, the four elements every status change must record, a ten-minute daily reconciliation routine, and the idle-day cost that a stuck status quietly generates.
Most operator ledgers carry a single status column: active, delinquent, closed. That column is a contract status. It describes a legal relationship and a flow of money, and it says nothing about where the hardware is.
When something goes wrong, the questions you actually need answered are different ones. Whose hands is the device in? Can it still receive a command? Has it been opened? Those are answers about physical status.
The two move independently. A device can be contract active, physically at a repair depot, or contract closed, physically still with the customer. With one column both cases render identically in the dashboard while requiring opposite responses.
That is the structural reason they separate. Contract status is driven by money and process: signature, first payment, each subsequent payment, grace period, settlement, return. Its timestamps come from the payment and contract systems. Physical status is driven by logistics and device state: pick, delivery, repair intake, recovery, bench, restock. Its timestamps come from carrier scans and from the device's own check-in.
Two clocks that do not share a source will drift. A subscriber posts the handset to a repair partner on the 20th; the scan lands the same day; the contract system keeps billing normally. At that moment contract status reads active and physical status reads at repair. Nothing notifies either side.
This is the part operators underestimate. Drift is a one-directional error, not noise that averages out: every transition recorded on only one side adds one more cell of divergence. By the time an account goes delinquent, you act on a ledger that says the device is with the subscriber when it has been sitting on a repair bench for three days. The lock command lands on the bench unit and the subscriber notices nothing at all.
Fix the value sets first, otherwise cross-checking has nothing to check against. The tables below are the smallest sets that hold up in a rental fleet; coarser than this and misclassification slips through, finer and data entry collapses under its own weight.
| Contract status | Meaning | Driven by | Clock source |
|---|---|---|---|
| Pending dispatch | Signed, not yet delivered | Contract effective | Contract system |
| Active | Within term, no arrears | Dispatch / first payment cleared | Payment system |
| In collections | Past due, reminder or recovery flow running | Missed payment on due date | Payment system |
| Settled, pending exit | Paid off, exit workflow incomplete | Settlement confirmation | Contract system |
| Terminated | Obligations ended | Return completed or write-off | Contract system |
| Physical status | Meaning | Evidence | Confidence |
|---|---|---|---|
| In stock | In own warehouse or store, ready to ship | Goods-in scan | High |
| With subscriber | Delivered, held by the lessee | Delivery confirmation | Decays after delivery |
| At repair | Held by a service partner | Repair intake plus partner receipt | Depends on third party |
| In transit | With a carrier | Tracking number | Depends on carrier data |
| In refurbishment | Recovered, awaiting test, wipe and restock | Recovery inspection record | High |
| Disposed | Sold on or scrapped, out of the rentable pool | Disposal record | High |
Note the confidence column on with subscriber. A delivery scan proves the handset reached the subscriber three days ago; it proves nothing about today. That is why this particular value must be paired with a field that refreshes daily — the last check-in time.
Put the two fields side by side and run a cross-tab. Most of the grid is legitimate. These nine cells mean a process has already broken. What they share is that each column looks reasonable on its own; only the pair is absurd.
| Contract status | Physical status | What it means |
|---|---|---|
| Pending dispatch | With subscriber | Shipped without recording dispatch; enrolment state probably unverified too |
| Pending dispatch | In refurbishment | Never rented at all; misread as a return |
| Active | In stock | Billed while sitting in your own warehouse; return paperwork missing |
| Active | At repair | Subscriber sent it in; term was never paused; dispute is now unavoidable |
| Active | Disposed | Device already sold on while payments continue. The most expensive cell in the grid |
| In collections | In stock | Handset already back, collections still running; a fast route to an unlawful contact |
| Settled, pending exit | With subscriber | Paid off, device not returned, personal data not wiped, management relation not lifted |
| Terminated | With subscriber | Contract over, asset not recovered. The asset is gone |
| Terminated | In transit | Termination was recorded without a physical event behind it |
A cross-tab finds the problem but cannot assign responsibility. For that, every transition needs four elements: who, when, which device, what action. Drop any one and the trail is unreconstructable.
LuckyMDM (Sichuan Starlight Network LLC) builds device asset management for rental and instalment operators, covering enrolment control, pre-lease screening and post-lease settlement. LuckyMDM holds contract status and physical status as two non-overwriting fields, and rejects any transition that does not carry the acting account, a server timestamp, the serial number and the action type together.
The test is a single sentence: if one person alone can move a device from active to disposed, the permission model has already failed. The most common internal route to a missing asset is not theft; it is a status edit that removes the device from the ledger. Dual review does not add work, it adds cost to the offence.
There is one more hard constraint on top of store, role and action scoping: the audit log must not be deletable. Delete rights on the log retroactively void every safeguard above it.
No new system required — two extra columns in the existing sheet will do. Run these in order.
| Action | Field to read | Pass condition |
|---|---|---|
| Run the cross-tab | Contract status x physical status | Zero rows matching the nine cells above |
| Reconcile check-ins | Last check-in time vs physical status | Every unit marked with subscriber past 24 hours goes to a human for confirmation |
| Spot-check physical | Five random units, ledger vs shelf | 100 per cent match; one miss triggers a full count |
The 24-hour figure in the second row is an operating convention rather than a standard: once a managed handset has been dark for more than a day, the probability that it is still recoverable through technical means falls away sharply, so it becomes a case for a phone call. The third action looks crude, and it is the only one that can prove the first two were done correctly. Ledger against ledger is not reconciliation; ledger against shelf is.
A stuck status is not just an accuracy problem. The interval between a return and the next lease start has no revenue attached while cost accrues every day.
Worked example with round numbers — treat it as an illustration of the method, not a benchmark. Acquisition USD 1,099, twelve-month term at USD 49 per month, so USD 588 of rent across the term. Spread over 365 days that is roughly USD 1.61 per day; fifteen idle days is about USD 24 of rent that simply evaporates. The usual trigger is precisely the failure described here: the handset is already on the shelf while the ledger still says with subscriber, so refurbishment and re-listing stay at the back of the queue.
Idle loss never appears as a line item the way arrears do. It is silent, and it only becomes visible once the two statuses are reconciled and the days are counted.
Repair, transit and onward sale can all happen inside the term. The mistake persists because it is right almost all of the time — and wrong on precisely the occasions that matter.
Settlement closes the contract status only. Physical status is still with subscriber: personal data present, Activation Lock still bound, management relation still attached. Skip it and the unit is either a privacy incident or a brick for the next owner, and residual value drops accordingly.
Count matching does not mean status matching. A fleet of 1,000 can be complete while thirty units carry the wrong physical status, and the count still passes. All the risk sits in those thirty.
Statuses that depend on third parties cannot be self-verified. At repair and in transit rest on a service partner's or a carrier's records. No amount of internal reconciliation establishes their truth; all you can do is require receipts and accept that these two cells are inherently weaker than the rest.
While a device is offline, physical status can only be inferred. With subscriber leans on the check-in signal. Once the device goes dark the signal stops refreshing and that cell decays hour by hour. An offline device is a reason to make a phone call, never a basis for an enforcement action.
No. Two columns in one ledger, with the rule that neither writes over the other — changing contract status must not silently change physical status. Most misclassification comes from exactly that convenience, a single "complete lease" button that edits both.
At that size do it by eye. The logic is identical: read the two columns together and ask whether the pair makes sense. Manual crossing is more reliable than automation below a few hundred units.
Decide it in the contract, in advance. Not charging while the subscriber does not hold the device is the common practice, but without a clause both sides argue afterwards and the operator has no footing.
Freeze every automated action on that unit — lock, collections contact, release — then establish the facts. An anomalous cell means the ledger is untrustworthy, and automated actions read the ledger. Acting before the correction multiplies the error.