A UK employer that files a Real Time Information return late can face a fixed monthly penalty ranging from £100 for a scheme of one to nine employees up to £400 for a scheme of 250 or more, and HMRC lists over 140 paid payroll products and around 10 free ones that have passed its recognition tests [1] [2]. Every one of those products has to send a Full Payment Submission on or before each payday, because that deadline is the spine of PAYE compliance in the UK [3].
This article is written for developers and product teams weighing up how much payroll compliance to build and how much to consume through an API. It explains what a payroll compliance API is, the submission surface it has to cover, the calculations it must get right, the inbound notices it has to apply, and the data protection duties that sit alongside the tax rules.
A payroll compliance API is the interface a platform calls to satisfy its PAYE obligations without owning the machinery behind them. Instead of building Real Time Information submission, statutory calculation and record keeping in-house, the platform sends employee and pay data to the API and receives compliant outputs: a validated submission, a correct set of deductions, an applied tax code. The compliance stays current on the API side, where it can track each year's specification changes.
Key takeaways
- A payroll compliance API handles the PAYE obligations a platform would otherwise build itself: Real Time Information submission, statutory calculation, notice handling and record keeping [3].
- The Full Payment Submission is due on or before payday, and late filing draws a fixed penalty from £100 to £400 depending on the number of employees in the scheme [1].
- HMRC recognition means software has passed HMRC's own RTI test scenarios, and it is a compliance baseline rather than a quality award [2].
- Compliance is not only outbound: an employer must apply inbound tax code notices (P6 and P9) and student loan notices (SL1 and SL2) before the next payrun [4].
- Payroll data includes special category data under UK GDPR, so a compliance API also carries data protection obligations, not only tax ones [5].
What a payroll compliance API is
Compliance in UK payroll is a set of legal obligations rather than a feature. An employer must operate PAYE, deduct the right income tax and National Insurance, report each payment to HMRC in real time and keep the records behind it [6]. Running payroll is itself a defined sequence of recurring HMRC tasks, from recording pay and working out deductions to reporting and paying, and a compliance API automates that sequence [15]. A payroll compliance API is the programmatic route to meeting those obligations: a platform calls it with the facts of a payrun, and the API produces the compliant result and, where relevant, transmits it to HMRC [3].
The distinction that matters for developers is between an API that moves data and an API that carries the compliance. A data API lets a platform read and write payroll figures. A compliance API is responsible for the figures being correct against the current specification and for the submission being accepted by HMRC. An HMRC-recognised payroll API sits in the second category, holding the calculation logic and the submission channel so the host platform does not have to [2]. Real Time Information has required this real-time reporting since April 2013, replacing year-end reporting, so the compliance surface has been fixed and well documented for over a decade [6].
Real Time Information, the core compliance surface
Most of what a payroll compliance API does converges on Real Time Information. Every time an employer pays someone, the software has to report that payment and its deductions to HMRC, and the format and timing of that report are defined by HMRC [3]. Two submission types carry the load.
FPS and EPS
The Full Payment Submission is the main return. It reports how much an employer has paid each employee and what has been deducted for PAYE, National Insurance and student or postgraduate loans, and it must be sent each time employees are paid [3]. The Employer Payment Summary is the adjustment return. It reports amounts the Full Payment Submission cannot, such as statutory payments an employer is reclaiming, and it is also used to tell HMRC that no employees were paid in a tax month [3]. The table below sets out the split.
| Submission | Purpose | Timing |
|---|---|---|
| Full Payment Submission (FPS) | Reports pay and deductions for each employee | On or before each payday [[3]](https://www.gov.uk/guidance/what-payroll-information-to-report-to-hmrc) |
| Employer Payment Summary (EPS) | Reports adjustments, reclaims, and nil-payment months | By the 19th of the following tax month [[3]](https://www.gov.uk/guidance/what-payroll-information-to-report-to-hmrc) |
A compliance API has to generate both, validate them against HMRC's schema, and handle the acknowledgement HMRC returns. Software that holds the HMRC Recognised badge has demonstrated it can produce and transmit valid returns with the right fields, identifiers and year-to-date figures [2]. The mechanics of consuming submission outcomes are explored further in the Moonworkers guide to the RTI API.
Deadlines and penalties
Compliance is enforced through deadlines, and a payroll compliance API has to respect two separate ones. The filing deadline is on or before payday for the Full Payment Submission, and missing it draws a fixed monthly penalty that scales with scheme size, as the table shows [1]. The payment deadline is separate: an employer must pay the tax and National Insurance to HMRC by the 22nd of the month when paying electronically, or the 19th by post [7].
| Employees in scheme | Monthly late filing penalty |
|---|---|
| 1 to 9 | £100 [[1]](https://www.gov.uk/hmrc-internal-manuals/compliance-handbook/ch401255) |
| 10 to 49 | £200 [[1]](https://www.gov.uk/hmrc-internal-manuals/compliance-handbook/ch401255) |
| 50 to 249 | £300 [[1]](https://www.gov.uk/hmrc-internal-manuals/compliance-handbook/ch401255) |
| 250 or more | £400 [[1]](https://www.gov.uk/hmrc-internal-manuals/compliance-handbook/ch401255) |
Filing penalties and payment penalties are independent, so a return filed late still draws a filing penalty even if the tax was paid on time, and a return over three months late can attract an additional penalty of 5% of the tax and National Insurance that should have been reported [1]. Because the outcome of a submission determines whether a penalty is at risk, a compliance API has to surface acceptance and rejection clearly, which is why an SME payroll platform treats the submission result as a first-class output rather than a side effect [7].
The calculations a compliance API must get right
Timely submission is worthless if the figures inside it are wrong. A payroll compliance API therefore owns the statutory calculations, and each of them is defined by an HMRC specification that changes at least once a year.
Tax codes, NI categories and inbound notices
Income tax deduction is driven by the tax code, which is a structured instruction, not a rate. A standard 2026-27 code of 1257L reflects the £12,570 Personal Allowance, while codes such as BR, D0, K and the S and C prefixes change the treatment entirely [4]. Compliance here is partly inbound: HMRC issues P6 notices to change a code in-year and P9 notices for the new tax year, delivered through the employer's PAYE Online account or directly to payroll software, and the employer must apply them before the next payrun [8] [4].
National Insurance adds a parallel obligation. The category letter on each employment selects the rate and any relief, and applying the wrong letter miscalculates employer National Insurance, which rose to 15% on earnings above the Secondary Threshold for the 2026-27 tax year [9]. A compliance API validates the category against the employee's circumstances and applies the correct rate, drawing on HMRC's National Insurance specification for software developers, which publishes the exact routines and test data [10]. Accountants applying notices across many clients rely on a multi-client payroll dashboard to keep every scheme's codes current [8].
Student loans, statutory pay and thresholds
Beyond tax and National Insurance, a compliance API has to handle deductions that follow their own rules. Student loan deductions depend on the plan type, and HMRC notifies the start and stop of collection through SL1 and SL2 notices that the software must apply, in the same way as tax code notices [11]. Where an employee has both a plan and a postgraduate loan, the compliance logic deducts the postgraduate loan first [11].
Statutory payments are the other moving part. Statutory Sick Pay changed structurally on 6 April 2026 when the Employment Rights Act 2025 removed both the waiting days and the lower earnings floor, so a compliant engine now has to pay from day one of a qualifying absence and to workers previously below the threshold [12]. Family-related payments, the P60 at year end and the many thresholds that reset each April all have to track the current figures, which is why a compliance API is a living system rather than a fixed one [13]. A platform serving small business payroll inherits these updates through the API instead of shipping its own each spring [12].
Inbound compliance, notices and identifiers
Compliance is often imagined as outbound submission, but a large part of it is inbound. HMRC pushes information to employers that must be acted on, and a payroll compliance API has to consume it. Tax code notices (P6 and P9) and student loan notices (SL1 and SL2) are the most common, retrieved through the employer's online channel and applied to the right employee before the next payrun [8] [4].
Identifiers are the other inbound concern. HMRC matches each submission to an existing employment using items including the National Insurance number and the payroll identifier, so a compliance API has to maintain these correctly and report changes in the prescribed way, or HMRC may create a duplicate employment [3]. Getting the identifiers right is as much a part of compliance as getting the arithmetic right, because a mismatched identifier produces a return that is technically valid but attached to the wrong record [6].
Data protection as part of payroll compliance
Payroll compliance in the UK is not only a tax matter. Payroll processes personal data, and some of it is special category data under Article 9 of the UK GDPR, including information about health, which appears whenever an employer records a sickness absence for Statutory Sick Pay [5]. Processing that data lawfully requires both a lawful basis and a separate Article 9 condition, and in many cases an appropriate policy document under the Data Protection Act 2018 [5].
The Information Commissioner's Office sets out how employers should handle employment records, from collecting only the minimum necessary data to retaining it no longer than required [14]. For a platform embedding payroll, this matters because the data flows through the compliance API. A well-designed API minimises what it holds, secures what it transmits and supports the retention rules that both HMRC and the ICO impose, so the host platform inherits a defensible data posture rather than assembling one [14]. Developers can inspect exactly what data each endpoint expects in the API documentation.
HMRC recognition, the compliance floor
For any UK payroll product, HMRC recognition is the entry threshold. To be listed, a product must pass HMRC's test scenarios for producing and transmitting valid Real Time Information returns, and the current list runs to over 140 paid products plus around 10 free ones capped at fewer than 10 employees [2]. Recognition proves the software can generate the right XML, the right fields and the correct handling of identifiers, tax codes and year-to-date figures [2].
What recognition does not test is instructive. HMRC does not assess usability, pricing, support or the depth of statutory coverage, and it cannot recommend one product over another [2]. For a developer, this means recognition is necessary but not sufficient: it confirms a compliance API can submit valid returns, and the criteria that actually separate one API from another are developer experience, breadth of statutory coverage and how cleanly the API embeds. The Moonworkers guide to HMRC payroll software covers what the badge does and does not guarantee in more detail [2].
Building versus embedding compliance
The decision a platform faces is whether to build the compliance surface or embed it. Building means owning Real Time Information submission, every statutory calculation, the inbound notice handling, the identifier matching and the data protection controls, and keeping all of it current as HMRC updates its specifications each April [10]. It also means carrying the penalty risk directly, since a late or malformed submission falls on the employer of record [1].
Embedding a payroll compliance API moves that burden to the engine. The host platform sends the facts of a payrun and receives a compliant result, while the engine keeps the calculations current, transmits the submission and surfaces the outcome [3]. This is different from wiring up an integration API that only syncs data with an existing payroll product, because an embeddable compliance engine is the payroll product, exposed for another platform to call while the end user stays inside the host [6]. For an ERP, an HR platform or a bureau tool handling enterprise payroll volumes, embedding turns a permanent compliance programme into an integration, and the annual specification changes arrive automatically rather than as a yearly project [14].
Conclusion
A payroll compliance API is defined by the obligations it discharges rather than the endpoints it exposes. It has to submit Real Time Information on time, calculate PAYE, National Insurance, student loans and statutory pay against the current specification, apply the notices HMRC pushes back, match identifiers correctly and protect the personal data that flows through it. Each of those is a legal duty with a penalty attached, and each changes on HMRC's schedule, not the platform's [1] [3].
The strategic point for a platform is that compliance is a moving target maintained by someone, and the only question is whether that someone is the platform's own team or the engine it embeds. As more HR, ERP and bureau products add UK payroll, the pull is towards consuming compliance as an API, so the specification changes, the notice handling and the data protection controls are inherited rather than rebuilt every April.
Frequently asked questions
What is the difference between a payroll API and a payroll compliance API?
A payroll API can mean any interface that reads or writes payroll data. A payroll compliance API takes responsibility for the data being correct against HMRC's current specification and for the Real Time Information submission being accepted. The distinction matters because a data-only API leaves the compliance risk with the host platform, whereas a compliance API holds the calculation logic and the submission channel itself [3] [2].
What penalties apply if a payroll submission is late?
Late filing of a Full Payment Submission draws a fixed monthly penalty based on scheme size, from £100 for one to nine employees up to £400 for 250 or more, and a return over three months late can attract a further 5% of the tax and National Insurance due. Filing penalties are separate from late payment penalties, so a return can be penalised for late filing even when the tax was paid on time [1].
Does a payroll compliance API have to handle incoming HMRC notices?
Yes. Compliance is not only outbound. HMRC issues tax code notices (P6 in-year and P9 for the new tax year) and student loan notices (SL1 and SL2), delivered through the PAYE Online channel or to the software directly, and the employer must apply them before the next payrun. A compliance API therefore has to retrieve and apply these notices, not just submit returns [8] [4].
Is data protection part of payroll compliance in the UK?
It is. Payroll processes personal data, and some of it, such as health information behind Statutory Sick Pay, is special category data under the UK GDPR. Processing it lawfully needs both a lawful basis and a separate Article 9 condition, and the ICO sets out how employment records should be handled and retained. A payroll compliance API therefore carries data protection duties alongside its tax duties [5] [14].
Image prompt for Imagen (also in frontmatter)
Documentary photograph, a UK software engineer reviewing a compliance checklist on a laptop in a quiet modern office, a second monitor showing a blurred dashboard, a printed document with a subtle official-looking header on the desk, soft daylight from a large window, late morning, palette of cool grey, deep green, navy and paper white, calm and precise atmosphere, asymmetric composition with the engineer in the right two-thirds, shot on a Sony A7 IV at 35mm f/2.8, photojournalism, gentle film grain, no warped hands, no legible text on screens (screens blurred), landscape orientation 16:9.
