<style>.reveal{opacity:1!important;transform:none!important}</style> Skip to content

Jordan statutory pack v3 is production-grade — GCC packs are in validation See coverage

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.

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 → Waiting → 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.

How the transaction engine works

Salary change · Lina Haddad

TXN-48213

Workflow

  1. 1 Draft
  2. 2 Waiting
  3. Approved

Posting

Posted · immutable

Corrections are reversing or retroactive entries — never edits.

  1. 09:12Submitted by the HR Partner
  2. 10:41Approved by the Payroll Manager
  3. 11:03Posted to the June 2026 run
  1. 01

    Draft

  2. 02

    Approve

  3. 03

    Post

  4. 04

    Reflect

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.

  • Safe retries & settlement holds

    Runs are safe to retry without paying anyone twice, and settlement holds keep a transaction waiting until its 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.

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.