Behaviour Specification

In order to cover any other situation where the usage of SPCM may be ambiguous from the API specification, this section describes how SPCM processes returns.

In particular, the examples provided elsewhere in this documentation are all for scenarios where an employer is submitting a quarterly return. However, SPCM supports submitting returns more frequently. SPCM also allows resubmitting data in case an error is discovered.

This section therefore shows how systems transmitting to SPCM can send data on different schedules other than quarterly, and can submit corrections to previously submitted data.

Submitting weekly or monthly returns

The example returns cover a whole quarter, by including all the periods of the quarter within the coverage array:

"coverage": [
  {
    "year": 2022,
    "frequency": "Monthly",
    "period": 1
  },
  {
    "year": 2022,
    "frequency": "Monthly",
    "period": 2
  },
  {
    "year": 2022,
    "frequency": "Monthly",
    "period": 3
  }
]

However, returns can contain any combination of periods. In particular, this means that returns can be made for a single period, or a rolling set of periods. The only requirement is that, ahead of any deadline which may be specified by the Revenue Service, returns must have been submitted for all the periods which the employer is required to report in order to comply with that deadline.

Updating static data

The 'static' data in a return consists of the details of the employer, employee and pension scheme objects.

Every static object included in a return is treated as a request to create or update that object, using the "id" property as the identifier. For each object, SPCM checks to see if an object was previously submitted within the relevant scope with a matching Id. For employers and pension schemes, the scope is all previous returns from the same API key. For employees, the scope is the API key and the Id of the containing employer.

If a matching record is found in the relevant scope, it is updated, otherwise it is created. The 'effective' date-time from the message header is held as a timestamp for the update. The value provided for this property should reflect the date and time when the data was extracted from the source system.

This means that, if a return was submitted which contains incorrect information in any static data, then this can be repaired simply by submitted a replacement return, using the same Ids for the same records, but with corrected data.

Note that if a return has any periods listed in the coverage array, then for each employer, you must list all employees paid during those periods, and for each employee, you must list all the relevant pay objects. However, if the coverage array is empty, then the return will only update static data, and only need to include those static objects which require updating.

Because reusing an Id means you are updating previously submitted data, you must use different Ids for things which are substantially different. In particular:

• You must not reuse an employee's Id if a new person takes over from a previous employee; the Id should stick to the person, not the role.
• You must use a new pension scheme Id if an employer switches from one scheme to a different one.

There is no way to request the deletion of static data. Employees which have left, employers or pension schemes which have been closed down or any data which was submitted in error can simply be disused in future returns.

Updating pay data

Pay data can be updated similarly to static data, except that it is identified within the scope of the employee Id by its year, frequency and period.

In order to submit a correction to pay data, you must send a return which includes the period being corrected within the coverage array. Therefore, for each employer in the return, you must re-provide a complete return for that employer for all periods in the coverage array. This means including all employees who were paid in any of those periods, along with all the relevant pay. Omitting an employee or a pay object will effectively remove any previously submitted pay data, replacing it with zeroes or nulls.

Pension schemes and the pay pensionSchemeId

The return schema for Secondary Pensions includes a pensionSchemeId field in the pay object. This cross-references to the Id of any pension schemes reported with the same API key.

Senders may include the details of all pension schemes being contributed to in every return. This may make returns easier to understand for a human, because the pension schemes are then defined in the same file. However, this is not absolutely required; pension schemes can instead be submitted in one return and then used in subsequent returns.