Goal: Give a complete, searchable view of every invoice across all organisations — track what has been billed, what is still unpaid, and what is overdue — so the finance team can chase dues and audit billing history without opening Zoho manually.

Logic: Reads directly from the invoiceMaster collection. Each page fetches 50 records sorted by dueDate descending. Filtering by status passes the value as a status query on the collection — except Overdue, which is a computed filter: dueDate < today AND status NOT IN [void, paid, draft, rejected, pending_approval]. Searching queries both customerName and invoiceNumber with a case-insensitive regex. Org name is resolved from the zohoId field on each invoice.
Collections used: invoiceMaster

Column details

Organisation — org name looked up via zohoId on the invoice.

Invoice # — the invoiceNumber field from Zoho.

Invoice Date — invoiceDate: date the invoice was created.

Due Date — dueDate: payment deadline set on the invoice.

Total — total: full invoice amount before any payments.

Balance Due — balance: remaining unpaid amount on the invoice.

Status — status field: draft / sent / rejected / void / overdue / paid / partially_paid / signed / pending_approval.

Overdue Duration — days since dueDate passed (only shown when overdue; sorted descending by default).

Goal: Give a per-organisation financial snapshot — how much has been invoiced, how much is paid, and how much is still outstanding — so account managers can instantly see which orgs owe money and how many devices are driving that billing.

Logic: Base list comes from zohoContacts — every Zoho contact appears (contactId = Zoho ID, contactName = org name), even if they have no invoices yet. Four parallel aggregations then enrich each row: (1) invoice totals from invoiceMaster grouped by zohoId; (2) organizationId looked up from organisations via zohoId — needed to join Lynktrac devices; (3) Lynktrac device count from devices grouped by assignedToAdmin.orgId; (4) Zoho billing count from recurringInvoiceDevices — group by {zohoId, recurringInvoiceId}, take quantity once per profile, then sum across profiles per zohoId. All joined in-memory. Results sorted by Outstanding balance descending.
Collections used: zohoContacts invoiceMaster organisations devices recurringInvoiceDevices

Column details

Invoices — total number of invoices ever created for this org.

Total Invoiced — sum of the total field across all invoices for this org.

Paid — Total Invoiced minus Outstanding (derived; not a stored field).

Pending — count of invoices with status sent / partially_paid / signed (awaiting payment).

Overdue — count of invoices with status overdue in the invoice master.

Outstanding — sum of the balance field on active invoices (status: sent / overdue / partially_paid / signed).

Earliest Due — earliest dueDate among all active (unpaid) invoices for this org.

Global Defaults apply to every organisation unless an org-specific override is set below. Changes take effect on the next Evaluate All run.

Goal: Identify every billing discrepancy at the device level — find devices that Zoho is charging for but don't exist on the platform (ghost billing), and devices that are active on the platform but missing from Zoho invoices (revenue leakage) — so each mismatch can be investigated and corrected.

Logic: All records come from the recurringInvoiceDevices collection, which is pre-populated by a sync job. Records with source: 'zoho' represent Zoho billing entries; source: 'device_collection' represents Lynktrac-side devices. Each Zoho entry is matched against the devices collection by deviceId — a match sets isMatched: true (Case A). Unmatched Zoho entries are Case B. Lynktrac devices not found on any Zoho invoice become Case C (source: 'device_collection'). Entries where deviceId is null are Case D. The summary counts (shown in the stat cards) also use zohoContacts to derive how many Zoho contacts have no matching org (zohoContacts.contactId cross-referenced against organisations.zohoId). The UI groups by case and paginates 50 rows per page.
Collections used: recurringInvoiceDevices devices zohoContacts organisations

Case & column details

Case A · Matched — device exists in both Zoho billing records (source: 'zoho') and Lynktrac devices collection. Billing is correct.

Case B · Zoho Only — device is on a Zoho invoice (source: 'zoho') but not found in Lynktrac devices. Potentially over-billed / ghost device.

Case C · Trac Only — device exists in Lynktrac devices assigned to an org but has no matching Zoho invoice entry (source: 'device_collection'). Potentially under-billed / revenue leak.

Case D · No Device ID — entry in recurringInvoiceDevices where deviceId is null or missing. Data quality issue; cannot be matched.

Org Name / Zoho ID — looked up from the org linked to the billing entry.

Device ID / Type — the deviceId and deviceType fields from the billing or device record.

Goal: Surface all organisations and contacts that are not properly linked between Lynktrac and Zoho — so the ops team can complete the mapping, ensure every active org can receive invoices, and every Zoho contact has a corresponding platform account.

Logic: Lynktrac Orgs without Zoho — queries the organisations collection for approved, non-deleted orgs where zohoId is null or empty. Zoho Contacts without Org — reads all records from the local zohoContacts collection (a synced cache of Zoho Books contacts) and cross-references each contactId against all zohoId values in the organisations collection; contacts with no matching org are shown. The join key is zohoContacts.contactId = organisations.zohoId. Both lists are paginated and searchable.
Collections used: organisations zohoContacts

Tab & column details

Lynktrac Orgs — No Zoho Link — orgs in the organisations collection (approved, not deleted) where zohoId is null or empty. These orgs exist on the platform but cannot receive Zoho invoices.

Zoho Contacts — No Org — contacts fetched from Zoho whose contactId does not match any zohoId in Lynktrac orgs. They exist in Zoho but have no corresponding platform account.

Organisation Name / Org ID — name and internal organizationId from Lynktrac's organisations collection.

Added On — addedOn date the org was created on the platform.

Contact Name / ID / Email — fields from the Zoho contact record for the unmatched Zoho side.

Goal: Catch billing count mismatches at the org level — quickly see which organisations are being over-billed (Zoho charging for more devices than exist) or under-billed (platform has more devices than Zoho is invoicing) — so the billing team can prioritise corrections and recover lost revenue.

Logic:

1. Base list — all approved, non-deleted organisations from the organisations collection (isApproved: true, isDeleted: false).
2. Zoho Billing Count — total devices Zoho is currently invoicing for this org (active profiles only).
   • A recurring profile = one recurringInvoiceId in Zoho Books, identified by its recurrenceName. An org can have multiple profiles (e.g. one per vehicle type, branch, or contract period).
   • Profile status comes from the recurringInvoice collection (status field: active / stopped / expired). Only active profiles contribute to the Zoho Billing total. Stopped or expired profiles are shown in the expanded view but excluded from the sum.
   • Source: recurringInvoiceDevices (source: 'zoho'). Group by {zohoId, recurringInvoiceId} → take $first quantity per profile → sum quantities of active profiles per zohoId.
   • Org linked via organisations.zohoId only. matchedOrgId is not used for billing — it reflects the device-matching algorithm and can incorrectly cross-assign entries from other orgs.
3. Lynktrac Count — total devices assigned to this org on the platform.
   • Source: devices collection, count where assignedToAdmin.orgId = organisations.organizationId.
4. Delta = Lynktrac Count − Zoho Billing.
   • Positive (+) → Under-billed: platform has more devices than Zoho is invoicing — revenue leak.
   • Negative (−) → Over-billed: Zoho is billing more devices than exist — ghost billing.
   • Zero (0) → Matched: both counts agree.
5. Recurring profiles (expanded rows) — click ▶ to expand any org and see each recurring profile as a sub-row, showing: Profile Name (recurrenceName), Zoho contact, recurringInvoiceId, quantity, and status badge (active / stopped / expired). The Profiles column shows total profile count with the active count in parentheses when they differ (e.g. 5 profiles (3 active)). Only active profile quantities are summed into the Zoho Billing total.
6. Sort — ordered by |delta| descending so the biggest mismatches appear first.

Collections used: organisations recurringInvoiceDevices recurringInvoice devices zohoContacts

Column details

Org Name / Org ID — organisation name from the organisations collection. The internal organizationId is shown below the name and used to look up assigned devices in devices.

Primary Zoho ID — the Zoho contact ID stored in organisations.zohoId. This is the primary link between a Lynktrac org and its Zoho billing account. Used to fetch recurring invoice profiles.

Profiles — count of distinct recurring invoice profiles (recurringInvoiceId) for this org. When some profiles are inactive the format is N profiles (M active). Click ▶ to expand and see each profile's name, status, invoice ID, and quantity.

Zoho Billing — sum of quantity across active recurring profiles only (status = 'active' in recurringInvoice). Stopped or expired profiles are displayed in the expanded view but excluded from this total.

Lynktrac Count — count of devices in the devices collection where assignedToAdmin.orgId matches this org's organizationId. Represents actual devices on the platform.

Delta — Lynktrac Count minus Zoho Billing. Positive = under-billed (revenue leak). Negative = over-billed (ghost billing). Zero = aligned.

Status — Matched (delta = 0) · Under-billed (delta > 0) · Over-billed (delta < 0). Derived entirely from Delta.

Goal: Provide a full inventory view of all hardware on the platform — understand how devices are distributed across SIM operators, organisations, and device types, and instantly spot how many are active, in stock, disabled, or under repair — so operations and support teams can manage stock, plan deployments, and track asset health.

Logic: All data is sourced from the devices collection. Four parallel aggregations run on page load: (1) group by normalised sim1type for SIM operator counts — sim1type is lowercased and pattern-matched so Vodafone/VODAFONE/Vodafone Idea all count as one group; (2) group by status for device state counts; (3) group by assignedToAdmin.orgId for per-org counts, with org name looked up from the organisations collection; (4) group by deviceType for type counts. Clicking any stat card or chart segment triggers a filtered listing query against the same devices collection with the selected dimension as a query filter.
Collections used: devices organisations

Breakdown & column details

SIM Operator — derived from sim1type field; normalised so Vodafone/VODAFONE/Vodafone Idea all group as one. Unknown = null or empty sim1type.

Device Status — the status field: ACTIVE (deployed), INSTOCK (warehouse), DISABLE (retired), REQUEST_FOR_REPAIRING / UNDER_REPAIRING / REPAIRED (repair lifecycle).

Organisation — grouped by assignedToAdmin.orgId; org name looked up from the organisations collection.

Device Type — the deviceType field on each device record (e.g. GPS tracker model/category).

Device ID / IMEI — the unique identifier (_id or imei) for each device in the listing.

Admin — assignedToAdmin.adminName: the admin account the device is assigned under.