Real Time Information was the biggest change to Pay As You Earn since 1944, and it became mandatory for every UK employer in April 2013 [1]. Today around 30.3 million people are reported to HMRC through it every month, each payment carrying a duty to file on or before the day the worker is paid [2] [3].
An RTI API is the part of a payroll system that turns that legal duty into a machine submission. It builds the return, wraps it in the format HMRC's gateway expects, sends it, and reads back the response. For any developer embedding UK payroll into a platform, the RTI layer is the point where a calculation becomes a compliance event, so it has to be understood in detail.
This article explains what the RTI API sends, how a submission travels to HMRC, the timing rules that decide whether a filing is on time, and the penalties that follow when it is not. It is written for developers and product teams building or integrating UK payroll, and it treats HMRC recognition as the baseline any serious engine already meets.
Key takeaways
- RTI is filed through two submissions: the Full Payment Submission (FPS) and the Employer Payment Summary (EPS) [3].
- The FPS must reach HMRC on or before payday, and it reports pay, tax, National Insurance and student loan deductions for each employee [4].
- Submissions travel to HMRC's transaction engine as GovTalk XML messages, validated against a published schema [5].
- Late filing penalties run from £100 to £400 per tax month, scaled by the number of employees [6].
- Software that files RTI must be HMRC-recognised, which is the entry requirement for any UK payroll engine [7].
What the RTI API sends to HMRC
RTI is not a single message. It is a small family of submissions, each covering a different reporting need, and an RTI API has to know which one to send in any given situation. Two of them carry the day-to-day load.
The two submissions that carry RTI
The Full Payment Submission reports what each employee was paid and what was deducted, and it is generated by a payrun [4]. The Employer Payment Summary reports employer-level adjustments that the FPS cannot carry, such as statutory pay recovery, a claim for the Employment Allowance, or a tax month in which nobody was paid [8].
The split matters because the two submissions fire under different triggers. An FPS is driven by a payment to an employee, while an EPS is driven by a reporting event that may involve no payment at all [8]. Where an employer runs both weekly and monthly payrolls, a separate FPS is required for each payday, so the API cannot assume one submission per month [3]. Modelling both submission types cleanly is one of the reasons platforms embed a dedicated HMRC-recognised payroll API rather than build the reporting logic themselves.
What a Full Payment Submission contains
An FPS is detailed. For each employee it carries the name, National Insurance number, payroll identifier, address, date of birth and tax code, together with the year-to-date totals for pay, PAYE, National Insurance and student loan deductions [4]. Everyone paid must be included, even a worker earning less than £96 in a week, which is the point at which employer reporting still applies although National Insurance may not [3].
Because the figures are year-to-date rather than period-only, the FPS is cumulative, and an error in one period propagates into the next unless it is corrected. This is why the API must validate employee data before it files: a missing National Insurance number or an invalid tax code produces a return that HMRC will reject or that will misallocate a worker's tax, and the National Insurance calculation itself depends on the correct category letter and the 15% employer rate for the 2026-27 tax year [9]. An SME payroll platform built on a reliable RTI layer runs that validation on every payrun so the filing is right the first time.
How an RTI submission reaches HMRC
A correctly built FPS is only useful if it arrives in the exact shape HMRC's systems accept. That shape is defined by the Real Time Information technical specifications, which HMRC publishes for each tax year alongside its generic messaging specifications [10] [11].
The transaction engine and the GovTalk envelope
RTI submissions travel to HMRC's transaction engine as GovTalk messages. The document is XML, UTF-8 encoded, and transported over HTTP, with the payroll payload sitting inside the body of a GovTalk envelope [5]. The envelope carries a header that identifies the message type through a Class element and a Qualifier element, and the transaction engine validates that header against the GovTalk schema before the payload is passed on [5].
HMRC provides the artefacts developers need to build this correctly, publishing Rules and Interface Management (RIM) artefacts, data item guides and valid XML samples through its support collection for software developers [12]. An RTI API abstracts all of this away from the calling platform: the platform posts structured payroll data, and the engine produces the schema-valid GovTalk message and handles the response. Developers integrating at that level can review the endpoint and payload definitions in the Moonworkers API documentation rather than working directly against the raw XML.
HMRC recognition and testing
No software may file live RTI without being recognised by HMRC. Recognition confirms that a product meets HMRC's specifications for sending Full Payment Submissions, Employer Payment Summaries and other RTI messages, and recognised products are listed on the GOV.UK register of payroll software [7] [13]. Before recognition, a product is validated against a test service that checks the GovTalk header and the submission structure, so the engine is proven against HMRC's own validation before it ever touches a real employer's data [11].
Recognition is a floor, not a differentiator. HMRC has stated that its wider strategy is to release richer APIs and encourage third-party innovation, building on the way RTI itself was delivered through close work with software developers [14]. For a platform choosing a payroll engine, the interesting questions sit above recognition: how clean the API is, how it reports errors, and whether the reporting step is automatic on every payrun.
The on or before rule and its exceptions
The single most important timing rule in RTI is that the FPS must be sent on or before the day the employee is paid, the so-called 'on or before' reporting requirement introduced with RTI in 2013 [15]. An RTI API therefore has to tie the submission to the pay date, not to the date the payrun happens to be processed.
The three-day grace period
HMRC applies a limited concession. An FPS is not automatically penalised where all reported payments are made within three days of the employee's payday, but this is not a licence to file late every period. Employers who regularly file after payday, even within the three days, may be reviewed and considered for a penalty [16]. Where an FPS genuinely has to go after payday, the submission must carry a late reporting reason, and an engine that supports the full set of reason codes lets the employer file compliantly in the situations HMRC allows [17].
Late filing penalties
When a filing is late without a valid reason, the penalty is fixed and scales with the size of the payroll. The table below sets out the monthly fixed penalty by employee count. An employer is liable to one penalty for each tax month for each PAYE scheme, and is not charged for the first month in a tax year in which a return is late [18].
| Number of employees | Monthly late filing penalty |
|---|---|
| 1 to 9 | £100 |
| 10 to 49 | £200 |
| 50 to 249 | £300 |
| 250 or more | £400 |
Beyond the fixed penalty, a return still outstanding after three months attracts an additional penalty of 5% of the tax and National Insurance that would have been shown on the missing submission [19]. Because these penalties recur monthly and per scheme, an accountant running many client payrolls has a strong reason to automate filing, which is why a multi-client payroll platform treats on-time RTI as a default rather than a manual task.
When to send an EPS instead of, or alongside, an FPS
The EPS is where the RTI API handles everything the FPS cannot. It is a monthly employer-level submission, and knowing when it is required is essential to avoid both missed claims and false non-filing notices. The table below sets out the main triggers.
| Situation | EPS action | Deadline |
|---|---|---|
| No employees paid in the tax month | Send an EPS instead of an FPS, with the no-payment indicator | By 19th of the following month |
| Recovering statutory pay (SMP, SPP and similar) | Send an EPS in addition to the FPS | By 19th of the following month |
| Claiming the Employment Allowance | Report the claim on an EPS | Once per tax year |
| CIS deductions suffered by a limited company | Report on an EPS | Monthly |
| Apprenticeship Levy due on a pay bill above £3,000,000 | Declare on an EPS | Monthly |
The no-payment case is the one an RTI API must handle carefully. Where no employee is paid in a tax month, no FPS should be sent, and an EPS carrying the no-payment indicator tells HMRC that no charge is due for that period [8]. Without it, HMRC may estimate the amount due and raise a penalty, so an engine that fires the EPS automatically protects the employer from a filing gap [20]. Larger employers with complex schemes often route this through an enterprise payroll integration so every entity files correctly each month.
Why RTI belongs inside the payroll engine, not bolted on
RTI reporting is not a feature that can sit beside a payroll calculation as an afterthought. The submission depends on year-to-date figures that only the calculation holds, it has to fire on the pay date, and it has to select the right message type for the situation. When the reporting logic lives inside the engine that also does the calculation, those dependencies are satisfied automatically.
This is the practical difference between a data integration and a payroll engine. A data integration moves figures between an existing payroll product and the tools around it, leaving the RTI filing inside the host product. An embeddable engine owns the filing itself, so another platform can offer full UK payroll, including on-time RTI, as a native feature without building the GovTalk layer [14]. For a developer, the deeper technical picture of how these calls fit together is set out in the companion guide to the payroll REST API.
Conclusion
The RTI API is where a payroll calculation becomes a legal filing. It builds the FPS and EPS, wraps them in a schema-valid GovTalk message, sends them to HMRC's transaction engine on or before payday, and reads back the acknowledgement, all while carrying the year-to-date totals that keep the return consistent across periods. The rules that govern it, the on or before requirement, the three-day concession and the tiered penalties, are the reason reporting cannot be treated as a background export.
As HMRC continues to widen its API strategy and more platforms embed UK payroll as a native capability, the engines that handle RTI cleanly, filing automatically, validating before submission and selecting the right message type, will be the ones product teams build on. The filing layer is quiet when it works, and expensive when it does not, which is exactly why it belongs inside the engine.
Frequently asked questions
What is the difference between an FPS and an EPS?
The Full Payment Submission (FPS) reports what each employee was paid and what was deducted, and it is sent on or before payday whenever employees are paid [4]. The Employer Payment Summary (EPS) reports employer-level adjustments that the FPS cannot carry, such as statutory pay recovery, the Employment Allowance, or a tax month with no payments [8]. An employer may need to send both in the same month, the FPS for the payroll and the EPS for the adjustment.
Does an RTI API have to be HMRC-recognised?
Yes. Any software that files Real Time Information must be recognised by HMRC, which confirms it meets the specifications for sending Full Payment Submissions, Employer Payment Summaries and other RTI messages [7]. Recognised products appear on the GOV.UK register of payroll software [13]. Recognition is best understood as the entry requirement every serious UK payroll engine meets, not a distinguishing feature.
What format does an RTI submission use?
RTI submissions are XML documents sent to HMRC's transaction engine as GovTalk messages, UTF-8 encoded and transported over HTTP [5]. The payroll data sits inside a GovTalk envelope whose header identifies the message type, and the transaction engine validates that header against a published schema before accepting the payload [5]. A payroll API produces this message from structured input, so the calling platform never has to build the XML by hand.
What are the penalties for filing RTI late?
Late filing penalties are fixed and scale with the number of employees: £100 for 1 to 9 employees, £200 for 10 to 49, £300 for 50 to 249, and £400 for 250 or more, charged for each tax month a scheme files late [18]. An employer is not charged for the first late month in a tax year, and a return still outstanding after three months attracts a further penalty of 5% of the tax and National Insurance that should have been reported [19].
