Designing a Statutory Payroll Deduction Engine for Philippine Compliance

Payroll is not a CRUD app. The hard part isn't storing employees or generating PDFs — it's getting the numbers right. In the Philippines, every payroll run must compute four separate statutory deductions, each with its own rule set, bracket table, rate changes over time, and edge cases.

If the math is wrong, employees don't get paid correctly and the company faces compliance penalties. This post walks through how I structured the deduction engine to be testable, auditable, and adaptable to rate changes without code deploys.

class PayrollService
{
  public function compute(Employee $e, $period): PayrollResult
  {
    $gross = $this->calculateGrossPay($e, $period);
    $sss   = $this->deductSSS($gross);
    $ph    = $this->deductPhilHealth($gross);
    $pi    = $this->deductPagIbig($gross);
    $tax   = $this->deductWithholdingTax($gross, $sss + $ph + $pi, $period);
    return new PayrollResult($gross, $sss, $ph, $pi, $tax);
  }
  // Each deduct* method is independently testable
}

Each deduction type is a separate method on PayrollService. The public compute() method orchestrates them. This structure means:

• ▸Each deduction can be unit-tested in isolation with known inputs and expected outputs
• ▸Adding a new deduction type (e.g., a company-specific loan deduction) doesn't touch existing logic
• ▸The HTTP layer (controller) stays thin — it calls compute() and returns the result

The alternative to DB-backed bracket tables is hard-coding lookup arrays in PHP. I chose the database approach for three reasons:

• ▸Rate changes don't require deploys. When SSS updates its contribution table (which happens every few years), an admin inserts new rows with a future effectivity_date. The engine automatically uses the correct table for the payroll period.
• ▸Audit trail by default. Every rate change is a timestamped row in the database. You can reconstruct what the deduction should have been on any given date — useful for retroactive adjustments.
• ▸Test coverage is simpler. Tests insert known bracket tables before running, so the test data is explicit in the test file, not hidden in a PHP array somewhere.

The tradeoff: each payroll run requires 4+ database lookups (one per deduction type). For 24 employees, this adds milliseconds. For thousands of employees, you'd want to cache the current rate tables in Redis — the engine is designed for that swap.

Philippine law requires employers to pay "13th month pay" — an additional half-month's salary paid by December. Critically, the first ₱90,000 of 13th month pay and other bonuses is tax-exempt. This means the withholding tax engine must track year-to-date non-taxable compensation across pay periods.

My implementation adds a cumulative_non_taxablecolumn on the payroll_periods table. Each payroll run sums the prior periods' non-taxable amounts. Once the running total hits ₱90,000, any excess is included in taxable income. The tracker resets on January 1st of each year.

// Pseudocode for the 13th month cap
const TAX_EXEMPT_CAP = 90_000;
ytdNonTaxable = PayrollPeriod::ytdSum(employee, period);
if (ytdNonTaxable < TAX_EXEMPT_CAP) {
  exemptAmount = min(bonus, TAX_EXEMPT_CAP - ytdNonTaxable);
  taxableBonus = bonus - exemptAmount;
}

The deduction engine is the most testable part of the system because it's a pure function: salary in, deductions out. The test suite covers:

Tests use SQLite in-memory with seeded bracket tables. The 80+ test suite runs in under 3 seconds in CI. Each deduction method has a corresponding test class that reads like a spec document — the test names describe the business rule being verified.

A payroll engine is a good example of a principle I try to follow: make the variable things variable. Government rate tables change. Tax brackets change. What shouldn't change is the calculation pipeline itself. By pushing the variable data into the database with versioning, the code stays stable and the compliance team (or future me) can update rates without touching a deployment pipeline.