Platform
A governance engine, not a database with forms
Most HR apps let you edit records in place. HRMSTONE doesn't. Every change is a typed transaction that routes for approval and posts immutably — so the system is provably correct under change.
The governance engine
Every change is a governed, audited transaction
Most HR apps let you edit records in place. HRMSTONE doesn't. Every change — a raise, a transfer, a leave request, a loan — is a typed transaction that moves along two independent axes: a workflow status and a posting status. Posted is immutable; corrections are reversing or retroactive entries, never silent edits.
Two-axis lifecycle
Workflow (Draft → Pending → Approved) × posting (Unposted → Posted). Posted = locked, accounting-style.
Approval engine
Ordered steps, committees, delegation, consultation and SLA escalation — segregation of duties by design.
Effective-dated & retroactive
Back-date a change and the engine computes the exact delta as arrears — it never corrupts history.
Provable & audited
Per-line calculation logs explain every number; an immutable trail records who did what, when.
The transaction kernel every change rides
- 1Draft
- 2Pending
- Approved
Posted · immutable
Corrections are reversing or retroactive entries — never edits.
- 1
Draft
- 2
Approve
- 3
Post
- 4
Reflect
What the kernel gives you
Properties you can't bolt on later
These come from modelling every change as a transaction from day one — they are the difference between an HR app and a system of record.
Typed transactions
A raise, a transfer, a leave request, a loan — each is a typed payload with its own validation, not a free-form edit.
Segregation of duties
Transaction-level permissions enforce who may create versus who may approve versus who may post — by configuration.
Effective-dating
Every change carries an effective date; back-dated changes are flagged retroactive and compute exact deltas.
Per-line calculation logs
Computed results carry a log explaining each line — auditors and employees can see exactly how a number was reached.
Idempotency & settlement stoppers
Idempotency keys make runs safe to retry; settlement stoppers hold a transaction until prerequisites clear.
Immutable posting
Posted is locked. Corrections are reversing or retroactive transactions, so history is never rewritten.
Frequently asked questions
What are the two axes?
Workflow status (Draft → Submitted → Approved/Rejected/Withdrawn) and posting status (Unposted → Posted). They move independently, so an approved transaction is still a deliberate, separate act to post.
What happens when I post something wrong?
You don't edit it. You create a reversing or retroactive transaction. The original stays in the record, the correction is fully attributed, and the ledger reconciles.
Does this slow teams down?
Routing is configured per change type — low-risk changes can auto-approve, high-risk ones route to committees with SLA escalation. The governance is proportionate, not bureaucratic.
Get started
Run payroll and HR for your whole group — on one governed platform.
Book a demo and see HRMSTONE run multi-country payroll, statutory filing and approvals — as SaaS, or on-premise for banks and government.
- Statutory-accurate, MENA & GCC
- SaaS or on-prem, your keys
- Arabic & English, Hijri & RTL