Dentolize · HR Module Walkthrough
On this pageWhy it mattersWhat's actually deliveredThe core quality bet: payroll = accountingRisk & what to watchDecision framing

For Stakeholders

Why this module matters, what it de-risks, and where the honest edges are. Written for leadership, product, and anyone deciding whether to ship it.

Why it matters

Dentolize monetizes the front of the clinic. Every clinic also has a back office — hiring, leave, attendance, and above all payroll — that today lives in spreadsheets and a separate tool. This module pulls that back office onto the platform, which does three strategic things:

  1. Deepens the moat. Payroll and GOSI are sticky. Once a clinic pays staff

and provisions end-of-service inside Dentolize, switching cost rises sharply.

  1. Opens a regional wedge. WPS + GOSI + end-of-service + Ramadan hours is a

specifically Gulf package. It's a reason to choose Dentolize over both generic dental PMS and generic payroll tools.

  1. Raises ARPU credibly. It's a genuinely new product surface (HR/payroll),

not a feature bump — supportable as a paid tier or add-on.

What's actually delivered

A consolidated 37-item backlog across 22 commits:

  • Employee master & org — records, departments, positions, reporting lines,

org chart, job grades.

  • Leave, schedule & attendance — tenure leave, reduced-hours seasons, overtime

approval, missing-checkout guard, coverage warnings, self-service.

  • Payroll money paths — proration, structured allowances/deductions, employee

loans, GOSI, end-of-service accrual — all posted double-entry.

  • Payroll outputs — WPS/SIF export, payslips, WhatsApp delivery, HR reports.
  • Talent hub — ATS, onboarding/offboarding, training, discipline, performance,

benefits.

  • Reach — full mobile parity, 9 languages, permission-scoped access with

sensitive-field masking.

The core quality bet: payroll = accounting

The architectural decision that most reduces risk is that every money movement posts through the existing resilient accounting engine rather than a parallel ledger. Concretely:

  • Five new GL accounts (employee loans, GOSI payable, end-of-service provision,

GOSI employer expense, end-of-service expense) with role-based mapping and sane fallbacks for tenants that haven't seeded them yet.

  • One authoritative net-pay formula (computeLineNet) shared by draft, line

edit, and process paths — explicitly created to kill a class of "component silently dropped from one path" bugs.

  • Exactly-once settlement: each payroll line is flipped to Paid via a guarded

conditional update, so retries/concurrency can't double-pay.

  • A resilient outbox with registered retry handlers and pre-parked intents,

so a crash between "money moved" and "journal posted" self-heals.

The PR reports the payoff: migration chain replays from zero; unit suite 59/59; DB-backed integration suite 15/15 including a payroll-money test; two rich seed runs with balanced trial balance and gated subledgers at Δ0; a live WPS file whose total matched the run exactly.

Risk & what to watch

Regulatory framing (the main one). GOSI rates are configurable settings, not encoded statute, and end-of-service is a straight-line monthly approximation (half-month/year under 5y, full month after) using current base salary and base only. That's correct and conservative for provisioning and books, but it is not a certified statutory settlement engine. Product and legal should agree on marketing language so we never imply certified compliance. (Detail in Payroll Money Paths.)

Data sensitivity. The module stores national IDs, passports, and IBANs. It masks them from under-permissioned viewers and tenant-scopes every by-id path — good — but this is exactly the data that raises the stakes on any auth regression. Security & Permissions documents the controls; keep them under review.

Surface area. This is a big module touching accounting, cron, notifications, mobile, and web. The blast radius of a payroll bug is real money and staff trust. The mitigations above are strong; the ask is disciplined release gating (design partners first, not a wide GA).

Known, disclosed leftovers (from the PR, all minor):

  • Cosmetic column alignment on editable run summaries (pre-existing).
  • Mobile: no date-clearing in the HR record form; loan repayment dates to today

(no picker); no post-upload expiry editing; manager "assign leave" is web-only.

None of these touch ledger correctness; they're UX gaps to schedule, not blockers.

Decision framing

This is a land-and-expand, moat-deepening module whose central risk is regulatory positioning, not engineering soundness. The recommendation implied by the code: ship to design partners in KSA/GCC behind clear "supports GOSI / not a filing agent" language, watch the ledger-balance and WPS-reconciliation invariants in production, and close the mobile leftovers before wide GA.