Around 30.3 million people were paid through PAYE in the UK in June 2026, each reported to HM Revenue and Customs on or before payday under Real Time Information [1]. Those payments run through roughly 2.73 million VAT and PAYE registered businesses, many of which already sit inside an enterprise resource planning system for finance, procurement and stock [2]. The gap, for the software teams that build and extend those ERPs, is UK payroll.
An ERP records who works for the business, what they cost and how those costs post to the ledger. What it usually cannot do is calculate PAYE income tax across three regimes, apply the correct National Insurance category letter, assess auto-enrolment on every pay run and file the resulting Full Payment Submission with HMRC. A payroll API closes that gap by exposing a compliant UK payroll engine as programmable endpoints the ERP calls from inside its own workflow.
This guide sets out what a payroll API for an ERP has to cover, how the integration is architected, where the build-versus-buy line sits, and what separates a genuine payroll engine from a thin tax calculator wrapped in an API. It is written for the engineering leads, product managers and technical founders responsible for adding UK payroll to an ERP or an ERP module.
Key takeaways
- A UK payroll API lets an ERP deliver compliant PAYE, National Insurance, auto-enrolment and RTI filing without the vendor building the statutory rulebook in-house [3][4].
- Only software on HMRC's recognised list can legally submit RTI, so the engine behind the API must carry HMRC recognition [3].
- Employer National Insurance is charged at 15% on earnings above the £5,000 Secondary Threshold for the 2026-27 tax year, and the engine must apply this on every calculation [5].
- An embeddable payroll engine differs from an ERP integration API: the engine is the payroll product, called from inside the host ERP, rather than a connector between two existing systems.
- The integration surface covers three income tax regimes, more than a dozen NI category letters, five student loan plans and a Full Payment Submission on or before every payday [6][7][4].
Why an ERP reaches for a payroll API
An ERP is the system of record for a business. It already holds the employee master data, the cost centres, the general ledger and, in many cases, time and attendance. Payroll is the natural next step, because gross-to-net pay is where headcount turns into a cash outflow and a set of ledger entries. The problem is that UK payroll is not a calculation the ERP team can safely treat as arithmetic.
The UK operates three separate income tax regimes, more than a dozen National Insurance category letters and five student loan plans, all of which a compliant payroll must apply correctly on every run [6][5]. Each of those rulebooks changes at least once a year, usually from 6 April, and each change has to be reflected in the code before the first pay run of the new tax year. Building that in-house means committing an engineering team to a permanent compliance maintenance burden that has nothing to do with the ERP's core value.
A payroll API moves that burden outside the ERP. The ERP sends employee and pay-period data to the engine, the engine returns the calculated payslip and files the statutory submission, and the ERP posts the results to its own ledger. The compliance logic lives with a specialist provider that holds HMRC recognition and updates the engine each April, so the ERP team ships payroll without becoming a payroll company.
The maintenance burden of building payroll in-house
The visible part of a payroll build is the gross-to-net calculation. The hidden part is everything around it: the annual rate changes, the RTI schema updates HMRC publishes each year, the tax code uplift at year-end, the P60 generation, and the edge cases that only surface once real employees hit them. HMRC issues a new set of technical specifications for software developers every tax year, and a payroll engine that misses one of those updates produces incorrect deductions from the first April pay run [3].
Directors' National Insurance is a good example of the hidden complexity. Directors are assessed on an annual earnings basis even when they are paid monthly, which means the calculation cannot simply be replicated period by period from the employee logic [5]. An in-house build has to encode this, test it against HMRC's own director test data, and keep it correct through every rate change. A payroll API that already passes HMRC's recognition tests carries that logic as a baseline, which is why the HMRC-recognised payroll API route removes an entire category of maintenance from the ERP roadmap.
Integration API versus embeddable engine
There is a distinction that decides the whole architecture, and it is easy to miss. A payroll integration API connects an existing payroll product to surrounding tools so data can be synced between them. An embeddable payroll engine is the payroll product itself, exposed so another platform can call it from inside its own interface, with the end user never leaving the host [4].
For an ERP, the embeddable engine is almost always the right model. The business already lives inside the ERP for finance and operations, and forcing its payroll administrators into a separate product breaks the workflow the ERP exists to provide. An engine called through an API keeps the entire pay run inside the ERP screens, while the compliance calculation and the HMRC filing happen behind the scenes. This overview of what a payroll API is and how it works sets out the pattern in more detail.
The statutory surface a payroll API must cover
Before designing the integration, the ERP team needs a clear picture of what the engine on the other side of the API is responsible for. A genuine UK payroll engine covers the full statutory surface, not just a headline income tax calculation. Getting this list wrong at the evaluation stage is the most common reason an ERP payroll project stalls after launch.
The core components break down as follows.
| Component | What the engine must handle |
|---|---|
| Income tax (PAYE) | Three regimes: England and Northern Ireland, Scotland, Wales, routed by tax code prefix |
| National Insurance | Every category letter, employer and employee rates, directors on an annual basis |
| Student loans | Plans 1, 2, 4 and 5, plus postgraduate loans, with the correct thresholds |
| Auto-enrolment | Assessment on every pay run, contribution calculation, pension scheme output |
| Statutory pay | SMP, SPP, SSP, SAP, ShPP, SPBP and SNCP, with eligibility and recovery |
| RTI submissions | Full Payment Submission on or before payday, Employer Payment Summary at month-end |
| Year-end documents | P60 generation, P45 on leaving, P11D where benefits apply |
Each of these is a rulebook in its own right, and each has to be current for the 2026-27 tax year before the engine can be used in production.
Income tax across three regimes
The single most misunderstood feature of UK payroll is that "UK income tax" is not one thing. Employees in England and Northern Ireland pay a basic rate of 20% up to £50,270, a higher rate of 40% up to £125,140 and an additional rate of 45% above that, all measured above a Personal Allowance of £12,570 [6]. Wales sets its own rates but has so far matched those figures, and Welsh taxpayers carry a `C` prefix on their tax code.
Scotland is materially different. It operates six income tax bands for the 2026-27 tax year, and Scottish taxpayers carry an `S` prefix [7]. The Scottish higher-rate threshold sits well below the £50,270 point used in the rest of the UK, so an engine that hard-codes a single higher-rate threshold will miscalculate every Scottish employee in the affected band. A payroll API for an ERP must route each employee to the correct regime from the tax code, and the ERP integration only has to pass the code across, not understand the routing itself.
National Insurance and its category letters
National Insurance is calculated separately from income tax and uses its own thresholds. Employees pay 8% on earnings between the Primary Threshold of £12,570 and the Upper Earnings Limit of £50,270, then 2% above that. Employers pay 15% on earnings above the £5,000 Secondary Threshold for the 2026-27 tax year [5]. The employer rate rose from 13.8% to 15% on 6 April 2026, which makes accurate employer NI one of the largest single cost lines the ERP will post to its ledger.
The complexity for the engine is the category letter. Each employee has a National Insurance category that determines which rates and reliefs apply, and the employer must apply the correct letter on every run [12]. Employees under 21 on category M and apprentices under 25 on category H attract zero employer NI up to £50,270, a relief that only applies if the letter is set correctly [5]. The ERP holds the data that determines the letter (age, apprenticeship status, veteran status), so the integration has to map those fields to the engine cleanly.
Auto-enrolment on every pay run
Workplace pension duties are assessed on every pay run, not once at onboarding. For the 2026-27 tax year, auto-enrolment uses a £10,000 earnings trigger and a qualifying earnings band of £6,240 to £50,270, with a minimum total contribution of 8% of qualifying earnings [8][11]. An employee who crosses the trigger in a given period has to be assessed and, where eligible, enrolled.
A payroll engine handles this assessment automatically and outputs the contribution figures the ERP needs to fund the pension and post the deduction. The engine should support the main master-trust schemes natively so the ERP does not have to build a separate pension integration on top of the payroll one. This keeps the pension file, the payslip and the ledger entry in a single flow rather than three disconnected systems.
Integration architecture: how the ERP calls the engine
With the statutory surface understood, the integration itself follows a predictable shape. The ERP is the system of record and the user interface; the payroll API is the calculation and filing engine. Data flows out to the engine, results flow back, and the ERP owns everything the user sees.
A typical pay run through an embedded payroll API moves through these stages.
| Stage | ERP responsibility | Engine responsibility |
|---|---|---|
| Employee sync | Push employee master data (tax code, NI number, pay elements) | Store and validate against HMRC formats |
| Pay period input | Send hours, salary, additions and deductions for the period | Calculate gross-to-net for each employee |
| Calculation | Receive and display the payslip figures | Apply PAYE, NI, student loans, pension, statutory pay |
| Approval | Present figures to the payroll administrator for sign-off | Hold the calculated run pending confirmation |
| Filing | Trigger the submission | File the Full Payment Submission with HMRC under RTI |
| Posting | Post the payroll journal to the general ledger | Return the journal breakdown and payslip documents |
The ERP never has to encode a tax rule. It sends structured data and receives structured results. The interface teams will spend most of their time on the mapping between the ERP's data model and the engine's expected payload, which is why a well-documented API matters more than any single feature.
Authentication, sandboxes and webhooks
A modern payroll API is built the way software is built today, with token-based authentication, a sandbox environment for testing against non-production data, and webhooks for asynchronous events such as a completed filing or an HMRC response. The ERP team should be able to evaluate the engine and start integrating from public documentation without going through a sales process. Moonworkers publishes its API documentation openly for exactly this reason, so an engineering team can read the endpoint reference before committing.
Webhooks are particularly important for RTI. The Full Payment Submission is filed with HMRC and the response comes back asynchronously, so the ERP needs an event to update the pay run status rather than polling for it. A payroll API that exposes filing events lets the ERP show the administrator a clear "filed and accepted" state, which is the moment the pay run is genuinely complete.
Keeping the ERP as the system of record
The point of embedding rather than integrating is that the ERP stays in control. The employee record lives in the ERP, the approval workflow lives in the ERP, and the general ledger posting lives in the ERP. The engine is a service the ERP calls, not a second product the user has to learn. This is the difference between an embeddable engine and a bolt-on, and it is what keeps the payroll experience native to the ERP. For larger deployments with multiple legal entities, the same pattern scales through the enterprise payroll tier without changing the integration model.
Build versus buy, decided honestly
Every ERP team that reaches this point weighs building payroll in-house against embedding an engine. The decision usually comes down to whether UK payroll compliance is a core competency the business wants to own, or a regulated commodity it wants to consume.
Building in-house gives total control over the calculation and the data model, and avoids a per-payslip cost to a third party. Against that, it commits the team to reading HMRC's software developer specifications every year, passing HMRC recognition to file RTI at all, and maintaining the calculation through every rate change and schema update indefinitely [3][9]. For most ERP vendors, payroll compliance is not where they differentiate, and the maintenance cost outweighs the licence saving.
Embedding an engine trades a per-payslip fee for the removal of that entire burden. The engine carries HMRC recognition, so RTI filing is legal from day one, and the annual updates arrive without the ERP team touching the tax logic. A per-payslip model also means the cost scales with payroll activity rather than with a fixed licence, which suits an ERP whose customers range from a handful of employees to several thousand. The per-payslip pricing approach aligns the cost of the engine with the ERP's own usage, rather than forcing a large upfront commitment.
The honest test is this: if the ERP team would not choose to build its own tax filing engine for corporation tax or VAT, it should think hard before building one for payroll. Payroll sits in the same category of regulated, annually changing, penalty-backed compliance, and the same logic that says "consume a specialist service" applies.
Compliance and HMRC recognition
Whatever the architecture, one requirement is non-negotiable. Only software on HMRC's recognised list can legally submit Real Time Information, and that recognition means the software has passed HMRC's own test scenarios for Full Payment Submissions, Employer Payment Summaries and the other RTI returns [3][9]. HMRC recognition is the market entry threshold for any UK payroll product, not a bonus feature, and an ERP that embeds a payroll engine inherits that recognition through the engine.
The RTI obligation itself is strict. The Full Payment Submission reports each employee's pay, tax and National Insurance to HMRC on or before the day they are paid, and late or incorrect submissions can trigger automatic penalties [4][15]. At month-end, an Employer Payment Summary may be needed for adjustments such as statutory pay recovery or the Apprenticeship Levy, which applies to employers with a pay bill above £3 million [16]. An engine embedded in an ERP handles both submission types so the ERP's payroll module is complete rather than partial.
Student loans are a further compliance line the engine carries. The UK operates Plans 1, 2, 4 and 5 plus postgraduate loans, each with its own threshold, and deductions are collected through payroll and reported on the FPS [13]. Tax codes, too, are operated on a cumulative or a week 1 / month 1 basis depending on the code HMRC issues, and the engine reads that basis flag rather than the ERP having to interpret it [14]. The UK payroll API technical guide walks through each of these calculation surfaces for teams that want the full engineering detail.
Conclusion
Adding UK payroll to an ERP is less a calculation problem than a compliance one. The gross-to-net maths is finite, but the surrounding obligations, three income tax regimes, a dozen NI category letters, five student loan plans, auto-enrolment on every run, and a Full Payment Submission on or before payday, form a rulebook that changes every April and carries HMRC penalties for getting it wrong. A payroll API lets the ERP deliver all of that as a native feature while the compliance logic stays with a specialist engine that holds HMRC recognition.
The direction of travel is towards more payroll being embedded inside platforms that are not, themselves, payroll products. ERPs, HR systems and vertical software are increasingly expected to run pay natively rather than exporting to a separate tool, and the embeddable payroll engine is the component that makes that possible. For an ERP team, the question is no longer whether to offer payroll, but whether to build the statutory rulebook or call one that already exists.
Frequently asked questions
What is a payroll API for an ERP?
A payroll API for an ERP is a programmable interface to a UK payroll engine that the ERP calls to calculate pay and file with HMRC. The ERP sends employee and pay-period data, and the engine returns the payslip figures and submits the Full Payment Submission under Real Time Information [4]. It lets the ERP offer compliant payroll without building the tax logic in-house.
Does the ERP need to be HMRC-recognised to run payroll?
The payroll engine behind the API must be on HMRC's recognised software list, because only recognised software can legally submit RTI [3]. When an ERP embeds a recognised engine, it inherits that recognition through the engine, so the ERP itself does not need separate recognition to offer payroll to its users.
Is it better to build UK payroll in-house or use a payroll API?
Building in-house gives full control but commits the team to reading HMRC's software developer specifications every year, passing HMRC recognition and maintaining the calculation through every annual rate change [3]. For most ERP vendors, payroll compliance is not a differentiator, so embedding a recognised engine through an API removes that maintenance burden while keeping payroll native to the product.
What UK payroll rules must the engine behind the API handle?
The engine must apply PAYE income tax across England and Northern Ireland, Scotland and Wales, National Insurance across every category letter, student loan Plans 1 to 5 plus postgraduate loans, auto-enrolment assessment on every pay run, and all statutory pay categories [6][5]. It must also file the Full Payment Submission on or before payday and produce year-end documents such as the P60 [4].
