Device onboarding
Bringing a new machine into your stack is a manual checklist: install the RMM agent, enroll it in Intune, deploy the EDR agent, install the DNS roaming client, create the PSA configuration record, and add a billing line to the agreement. Six steps, six systems, usually done under time pressure — miss one and either the device goes unprotected or you manage it for free. Ledger tracks these steps for every device automatically (the DNS step reads "not yet measurable", see below), from the same connected-source data the device matrix already reads, so nobody has to keep the checklist in their head.
The six steps
| # | Step | System |
|---|---|---|
| 1 | RMM agent installed | RMM |
| 2 | Enrolled in Intune | MDM |
| 3 | EDR agent deployed | EDR |
| 4 | DNS roaming client installed | DNS filtering |
| 5 | PSA configuration record created | PSA |
| 6 | Billing line added to the agreement | Billing |
For steps 1-4, "done" means at least one observation of that category has ever been seen for the device — an onboarding checklist asks whether a step was ever completed, not whether the device's last check-in is still current, so a step reads done even once the source has gone stale (see the device matrix's own present/stale distinction, which onboarding deliberately collapses).
Step 5 vs. step 6 — a configuration record is not a billing line
Step 5 asks only "does a PSA configuration record exist for this device" — the same presence check behind the device matrix's own Billed column, before that column ever looks at whether the device is actually billed. Step 6 asks a separate, stricter question: is this specific device named on an active line of the agreement. A device can clear step 5 while still failing step 6 — a configuration record exists, but nothing on the agreement bills for it — and that gap is exactly how a machine ends up managed for free.
For a client whose agreement bills by quantity rather than by named device (see billing reconciliation's count-only pattern), there is no per-device line to check step 6 against, so it reads "—" (not applicable) for every device on that agreement, never a false ✗.
Reading the four states
| Symbol | State | Meaning |
|---|---|---|
| ✓ (green) | Done | This step has been completed at least once. |
| ✗ (red) | Missing | You use this system, but this device has no record there — an honest gap. |
| — (grey) | Not applicable | You don't use this system at all, or (step 6, count-only agreements) there is nothing per-device to check. |
| a "not yet measurable" chip | Not yet measurable | Ledger has no connected source for this step's category yet, for any device on your account, or (step 6) hasn't yet classified this client's billing pattern. |
"Missing" and "not yet measurable" are never the same thing and never shown the same way. "Missing" is a gap in your process — the system is connected, and this specific device fell through. "Not yet measurable" is a gap in Ledger's own visibility — nothing about this device or client can be scored one way or the other yet. Today that covers two separate cases. Step 4 (DNS filtering) reads "not yet measurable" because Ledger does not connect to DNS filtering services. Step 6 (billing line) reads "not yet measurable" for any individual client whose billing pattern hasn't been classified yet — before that client's billing/PSA connector has completed its first successful sync — independently of DNS and resolved by that client's own next successful sync, not by connecting anything new. A device's percent-complete figure only ever divides by the steps that could actually be scored — a step that is not applicable or not yet measurable is left out of both sides of that fraction, never counted as a failure.
Where to see it
Every device's row on the device matrix expands to show this six-step checklist for that one device. The rolled-up view — percent fully onboarded and how many devices are missing each step, per client and customer-wide — is its own screen, linked from the home page, and the same numbers appear in the per-client QBR summary and scheduled report.
The rollup is also available as a one-row-per-device CSV/XLSX export, using the same four states described above.