Philippine payroll is not a rounding problem, it is a table problem. SSS contributions come from a published bracket schedule with employee, employer and EC shares plus mandatory provident fund amounts above a salary ceiling; PhilHealth is a percentage with a floor and a ceiling that move on their own schedule; Pag-IBIG has its own rate breakpoint and monthly cap; and BIR withholding runs off the graduated TRAIN tables applied per payroll period, with de minimis benefits and the PHP 90,000 13th-month-and-other-benefits exclusion sitting on top. Microsoft Dynamics 365 Business Central ships no Philippine payroll localization at all — most teams run the whole thing in a spreadsheet, then key summary journals back into Business Central, which means the general ledger is always one manual step behind the payroll register and nobody can reconcile an employee's year-to-date figure without opening the workbook.

What we build is a proper AL extension for Business Central — delivered as a per-tenant extension for SaaS, or as an app package you deploy on-premises — that puts the payroll engine inside the system that already holds your chart of accounts, dimensions and vendors. Contribution schedules live in real setup tables with effective-from dates, so when SSS or PhilHealth publishes a new circular you add the new version rather than editing history; every past run recomputes against the table version that was in force on its period. A calculation codeunit walks each employee's payroll period, resolves the applicable bracket, computes employee and employer shares, applies the BIR graduated table to taxable compensation net of mandatory contributions, and writes payroll lines that post to the G/L through standard journal posting with your own dimension setup — cost centre, project, department — carried onto every line.

The pack is built the way Business Central expects: table and page extensions on Employee for the SSS, PhilHealth, Pag-IBIG and TIN identifiers plus tax status; new ledger tables for payroll runs, lines and year-to-date accumulators; event subscribers rather than base-application modifications, so a Microsoft release wave upgrade does not break the extension; permission sets that separate the payroll clerk who enters timesheets from the officer who releases and posts; and job queue entries for the scheduled work — draft run generation, contribution accrual and report file build. Payslips render as report objects you can email straight from Business Central or archive to the employee card. Bank file export is a configurable layout so the same run produces the format your disbursement bank actually accepts. Statutory outputs — the SSS contribution collection list, PhilHealth remittance report, Pag-IBIG MCRF, BIR 1601-C monthly remittance figures, 2316 employee certificates and the alphalist source data — are generated from the same posted ledger, not re-keyed. API pages exposed over the REST API v2.0 / OData v4 endpoints let a time-and-attendance system push hours in and let Power BI, Power Automate or a Dataverse-connected app read run summaries out without anyone touching the database.

This is build-to-order, and we are explicit about what that means: there is no AppSource button to press today. You request a quotation, we run a scoping call on your actual pay structure — pay frequencies, allowance and de minimis catalogue, night differential and overtime rules, loan deductions, the bank file spec your bank issued you, and which Business Central version and deployment type you are on. We then build the extension against that scope, install it on your sandbox, run a parallel period against your existing payroll so the peso figures are proven line by line before anything posts to your production general ledger, and hand over the git repository with the AL source. Typical delivery is one working week from confirmed scope, longer only if you want integrations we have not scoped, such as a biometric time system or a multi-entity shared services setup.

Statutory tables change. We build the schedules as data you can maintain yourself, document the update procedure in the handover pack, and stay available during the post-go-live support window to handle the first rate change with you rather than leaving you to discover it at month end.