Dynamics 365 Business Central does not include a native payroll engine. Microsoft leaves payroll to certified ISV partners and custom AL extensions, because payroll rules are national and change frequently — so payroll either comes from a localised product or is built as an extension that keeps employee data, calculation, approval and bank files inside Business Central.
Custom AL HR & Payroll Execution Pipeline Inside Business Central
Employee & Grades
Personal info, grade compensation bands, and department cost allocations.
Prorated Calculations
Earning codes, mid-month hires/exits, unpaid leave & loan deduction amortizations.
Approval Workflow
Audit-logged approvals by HR Director and CFO before GL posting.
GL Post + WPS Bank File
Automatic journal entry to General Ledger and encrypted WPS bank disbursement file.
Employees view payslips, request loans, and track leave via Dataverse-connected Power Apps.
Why it belongs inside the ERP
Payroll run outside Business Central has to come back in as a journal. Every month somebody exports a summary, maps it to accounts, and posts it. It works until the month it does not, and the failure lands in the accounts, not in HR.
Inside the ERP, payroll cost posts where it was incurred — by department, by dimension, by project — without a re-keying step. That is the argument. It is not about convenience for HR; it is about the general ledger being correct without manual intervention.
The standard architecture gap
Business Central gives you employee master records and the ledger. It does not give you pay periods, earning codes, proration, loan recovery, approval states, or bank file generation. That gap is what an AL module fills.
What a complete module contains
| Layer | Capability | Why it is structured this way |
|---|---|---|
| Human resources | Employee and department records | Department drives cost allocation, not just reporting. |
| Salary details on the employee | Pay data sits where payroll reads it — no second source. | |
| Compensation by grade | A band change flows to everyone on that grade at once. | |
| Setup | Payroll periods | Every run, calculation and report anchors to a period. |
| Earning codes | Pay is composed from components, not hardcoded fields. | |
| Calculation | Prorated amounts | Joiners, leavers and mid-period changes paid correctly without manual maths. |
| Loans and scheduled deductions | Balances recovered through payroll and visible, not tracked on the side. | |
| Approval and output | Salary approval workflow | Draft to approved is a real state change with an audit trail. |
| Bank files | Structured disbursement files — the GCC WPS/SIF mechanism. | |
| Monthly salary reports | Reconciliation and record-keeping for HR, finance and management. |
The single most important line in that table is the approval workflow. A payroll run that can produce a bank file without an approval state is a system where nobody can later say who authorised a payment.
WPS and the GCC
The Wage Protection System requires employers to disburse salaries through structured bank files so that authorities can verify workers were paid, in full and on time. Practically, that means an approved payroll run has to produce a Salary Information File in the exact format the bank and the regulator expect.
The format is prescriptive and it changes. Build the file layout as configuration instead of as code, or every regulatory amendment becomes a deployment.
Employee self-service
Employee-facing functions — payslips, leave requests, loan applications — belong in a Power Apps portal, not in Business Central itself. Employees do not need ERP licences and should not have ERP access.
Requests flow back through Dataverse and standard API endpoints into Business Central, which stays the system of record. The portal is a window, not a second copy of the data.
To model gross-to-net pay distribution, IRS Pub 15-T tax withholding, or supplemental compensation, explore our free client-side Paystub & Payroll Generator and Bonus Tax Calculator.