Dynamic Talent Solutions · JobDiva vs NetSuite

Earned Revenue Tie-Out

Reconciles JobDiva timesheet-earned revenue (hours × bill rate) against NetSuite invoiced revenue, employee by employee, and isolates pending-approval hours as accrual, not revenue.

Employee reconciliation

JD Employee Status Match JD Company Client Business Head NS Bill Freq Appr. Hrs JD Earned Rev Pending Accrual NS Invoiced Variance

Top variances to investigate

|variance| ≥ $10,000, matched employees only

Pending-approval accrual detail

EmployeeDateWeek EndingReg HrsOT HrsBill RateAccrual $

Period-wise reconciliation

Employee Period JD Hrs JD Revenue NS Revenue Variance

Download

every table on this page, plus a combined workbook

Recompute for a new month

Upload the "Revenue Report with Segment" NetSuite export (Type, Document Number, Employee Name: Email, Amount columns) and the JobDiva per-day timesheet export. Amounts recompute entirely in your browser; nothing is uploaded anywhere.

How this reconciliation is built

Two sources, matched by a three-step rule. 1 · Email — exact. 2 · Employee name — for anyone still unmatched, JobDiva's VMS EMPLOYEE NAME (then its Employee name) is compared with NetSuite's Employee Name: VMS Employee Name (then its plain Employee Name, e.g. “EMP0008497 Primo Ahmad” without the id) as a set of words, so comma order, case and spacing don't matter (“Yehdego, Hermon” = “Hermon Yehdego”). 3 · First + last name — same idea, ignoring middle names and initials. Steps 2–3 only act on people still unmatched on both sides, and only when the name points to exactly one person — an ambiguous name is never guessed; it stays visible as JD-only / NS-only. A ◆ next to a name means it was matched by VMS name (hover the Match badge to see both emails and both VMS names side by side), and a ⚠ means an email match whose VMS names differ — worth a glance that it's really the same person. A JobDiva row with a blank email is no longer dropped: it is matched by VMS name only.

JobDiva — earned revenue

Per day-row: Regular Default Hours × Regular Bill Rate + Overtime Hours × Overtime Bill Rate + Doubletime Hours × Doubletime Bill Rate. Rows with Status = Approved count as earned revenue; every other status (chiefly Pending Approval) is pulled into its own accrual bucket and excluded from revenue, per the original instruction for this tool. A $0 Pending-Approval accrual is a valid result — it means everything currently in the file is approved, not that something broke.

NetSuite — invoiced revenue

The Revenue Report with Segment export is the single NetSuite source, summed directly by Employee Name: Email — both Type = Invoice (regular billing) and Type = Journal rows.

Month-end accrual journals: NetSuite posts a month-end batch — one Journal-type line per employee, all dated the last day of the month — recognizing revenue for days worked but not yet invoiced. This is the NetSuite-side counterpart to the JobDiva Pending-Approval accrual above. It's easy to miss if you only look at an Invoice-only export.

Supported layouts: the DTS and eTeam Inc exports are the same JobDiva timesheets_bystatus daily report and NetSuite Revenue Report with Segment (all income accounts — Contracting, Payroll & Passthrough, SOW, Intercompany and the negative MSP-Fee lines — Invoice and Journal rows, summed, so the total ties to the NetSuite “Total - Income” line). The reporting month is read from the JobDiva dates. Flat-fee assignments (Bill Rate Per M / BW / W / D) carry 1 unit in the hours field, so hours × rate gives the fee once.

Result (August DTS sample baked into this page): this reconciles exactly to NetSuite's own reported total for August ($700,438.25 = $700,438.25, $0.00 residual) once both Invoice and Journal rows are included from this one report.

A rocky path to get here — worth knowing if the numbers move again

Earlier versions of the Revenue Report with Segment export had a genuine defect: extra Segment columns (Business Heads / VP Delivery / Skill Set / Industry) caused each invoice line to fan out into duplicate rows with an inconsistent per-employee multiplier, making the Amount column unusable. That defect has since been fixed at the source — verified across all Invoice-type rows in the current export, zero duplicate groups. If a future upload shows implausible per-employee amounts again (e.g. a weekly bill in the tens of thousands for an hourly contractor), that same defect may have returned; flag it rather than trust the total.

Two source files were also silently replaced on disk mid-analysis while this tool was being built — once each for JobDiva and NetSuite. If numbers in this tool ever look stale or contradict what you see directly in JobDiva or NetSuite, re-export and re-upload rather than assuming the tool is wrong.

Prior-month hours in straddling invoices (optional third upload)

A NetSuite invoice for the first week of a month can start on the last day of the previous month (e.g. service period 8/31 – 9/4) and so bill 8/31 hours that the month's JobDiva file does not contain. Upload a JobDiva per-day report that holds those prior-month days (last month's export works) in the optional third slot. For every NS invoice whose From Date is before the month start and To Date falls inside it, the tool takes each person's approved hours × bill rate for the days from the invoice's From Date up to the day before the month start, caps it at the invoice amount, and removes it from NetSuite revenue — in the employee total and in that invoice's period row. Days already present in the main JobDiva file are never used twice, invoices that end before the month start are left alone (they are earlier-period billing), and the section “Prior-month hours inside NetSuite invoices” lists every straddling invoice with what was removed and why not when nothing could be.

Reading the table

Matched — found in both systems. JD only — approved hours with no NetSuite invoice or journal yet (normal billing lag, or truly unbilled). NS only — NetSuite revenue with no timesheet in the uploaded JobDiva extract (includes any row NetSuite couldn't tag to an employee at all). Rows flagged INVESTIGATE (|variance| ≥ threshold) are worth a source-invoice spot-check but are not, by themselves, evidence of a bug.