BookKeptevidence chain
Guide · the quarterly return

The employment intermediaries quarterly report

A return most agencies file late, wrong, or from the wrong source data. This guide covers who owes one, what HMRC actually asks for, the modelling mistake that quietly under-reports every quarter, and why a blank cell beats a guessed one.

Who owes a return

An agency that supplies workers to clients and does not operate PAYE on what those workers are paid owes a quarterly return to HMRC. That covers the ordinary shape of contract recruitment: the worker is paid through their own limited company or through an umbrella that runs the payroll, and the agency sits in the middle. The agency reporting the supply is not a judgement about who employs the worker; it is a report of the supply itself.

What it asks for

The return is filed on HMRC's own template gov.uk report template, uploaded manually. There is no API submission route, which is worth knowing before anyone promises you automated filing. Per worker it asks for identity details, the engagement, and what they were paid.

On identity, HMRC asks for the National Insurance number and, where that is not held, for date of birth, gender and address instead. That fallback exists because agencies genuinely do not always hold a NINO, not as an invitation to approximate.

The modelling mistake

The return is a list of workers supplied in the period. It is not a list of invoices raised in the period. Those two sets look similar most quarters and diverge in exactly the cases that matter.

Every one of those is an omitted worker, and an omitted worker is precisely what the penalty regime is aimed at. Penalties escalate for repeated failure and reach £3,000 fixed plus daily amounts ESM2190. Build the return from placements that overlap the period, then join payment figures on where invoices exist.

Why a blank beats a guess

A missing NINO exported as blank is an incomplete return with a visible hole, and the hole is a prompt to go and get the number. The same cell filled with something inferred is a wrong return that looks complete. Gender in particular should never be derived from a name; where it is needed because the NINO is absent, it is a question for the worker, not an inference.

The solution

BookKept builds the return from placements

The export lists every placement that overlapped the quarter, with payment figures joined on from invoices where they exist, so a worker whose invoice landed in the next period still appears. NINO, date of birth and address ride on the worker record and export blank where the agency does not hold them, as a prompt rather than a guess. Gender is not stored anywhere in the product and is never inferred. The result is the CSV for upload, produced from the same records the rest of the chain runs on.

See what it does