HR system architecture: the decisions that matter

Situation: HR data is queried as of a date and corrected retroactively; in-place edits lose history and break payroll reproducibility.

Choice: Employment and compensation are append-only ranges with exclusion constraints; the current state is the row valid today; retroactive corrections insert a new row and flag affected payroll periods.

• Rejected: Current-state table plus history log: easy to bypass.
• Rejected: Snapshot per payroll period: loses between-period changes.
• Consequence: Queries must always pass an as-of date.
• Consequence: Recalculation tooling is required for retro changes.

Situation: Tax and leave rules differ per jurisdiction and change on fixed dates; code changes per rule do not scale or audit.

Choice: Rule packs are data interpreted by a pure calculation engine; each run records the pack versions used; changes need two approvers and test vectors.

• Rejected: Hard-coded rules per country: fast to start, impossible to audit.
• Rejected: External payroll engine only: loses explainability and control.
• Consequence: Rule authoring needs tooling and test vectors.
• Consequence: Results are reproducible for audits.

Situation: Payroll fraud is dominated by one person altering pay or bank details and releasing the run.

Choice: Three distinct actors across prepare, approve and release, enforced by database constraints and role rules, with anomaly flags blocking release.

• Rejected: Single payroll admin: simple, high fraud risk.
• Rejected: Approval by UI convention only: easily bypassed.
• Consequence: Small employers need at least two people with payroll roles.
• Consequence: Break-glass for emergencies is a documented, audited override.

Indexes are chosen from the questions the app asks most often. Each line below names a table and the question its main index answers.

• employees: unique (org_id, employee_no) — employee number unique per tenant.
• employments: (employee_id, valid_from DESC) — current and historical employment.
• compensation_records: (employee_id, valid_from DESC) — current pay for an employee.
• leave_requests: (employee_id, starts_on DESC) — employee history.
• leave_ledger: (employee_id, leave_type_id, effective_on) — balance as of a date.
• time_entries: (employee_id, work_date) — a person's week.
• payroll_runs: unique (legal_employer_id, period_start, period_end) — one run per period per employer.
• payroll_items: unique (run_id, employee_id) — one item per employee per run.

Forge64 matches your description to one of 25 reference architectures, writes the plan and data model into the project, generates the app, and runs a quality gate over the code before you see it. Each app gets its own Postgres database and sign-in with no per-user fee. Hosting on Forge Cloud and Forge Payments are rolling out.

This is a reference design for the category, not a promise that every item is generated today. Built-ins such as background jobs, file uploads and search are rolling out; email sent from your app is coming soon, so anything here that needs it is something you add yourself for now.

What is the most important architecture decision for an HR system?

Effective-dated append-only employment and pay records. Employment and compensation are append-only ranges with exclusion constraints; the current state is the row valid today; retroactive corrections insert a new row and flag affected payroll periods.

Do I have to make these decisions myself?

No. Forge AI plans them from your description and writes the decisions into the project as architecture records you can read and change.

What do the alternatives cost me?

For example, for "Payroll rules as versioned data in rule packs": Hard-coded rules per country: fast to start, impossible to audit. External payroll engine only: loses explainability and control.

• How to build an HR system
• Example prompt for an HR system
• HR system security checklist
• HR system scaling checklist
• Often combined: accounting system
• Often combined: approval workflow app
• All app types