PAGSA COMMENTS ON DRAFT MONTHLY PAYE BRS V0.4 (1 of 2) – 26th June 2023

The following are comments from the PAGSA on the Draft Monthly PAYE BRS V0.4 from the 26th of June 2023

Comments from Rob (PAGSA Manco) – Start
Definitions – Transaction Period (Page 6): In response to an earlier PAGSA proposal to replace “period” by “month” (and incidentally to also replace “assessment” by “accrual”), SARS indicated that to provide for other systems (eg. provisional tax), they want to retain the word “period” instead of “month”. However in BRS V0.4 the description of ‘Transaction period’ starts with “… tax month …”. Consider removing the word “tax” – it does not appear to serve any purpose and is confusing. It is essential to retain the word ‘month’ in the description because the BRS is specifying the technical requirements for the submission of tax certificates on a monthly frequency. Further, please note that in the body of the BRS, the words ‘month’ and ‘period’ seem to be inconsistently applied.
Definitions – “Tax Year”: The term “tax year” is used in some of the other definitions and is generally understood to be a year from 1 March to the end of February in the employment world. As a suggestion, consider defining the term to make it clear what is meant.
Section 4 – Rules for Import File Structure (Page 9 Point 3) : The name of the Registration Information Record is incorrect:
– Employer Registration Information Record [Must be “ee”].
Application of ‘Record Status’ – Employee Monthly Certificate – Page 53: The options for the Record Status field for tax certificate administration are: (N)ew, (A) Amended, (C) Cancelled. SARS have decided that the ‘delta’ of the change must not be submitted and that tax certificate must be ‘replaced’. How must a tax certificate be replaced?
– By first cancelling the incorrect certificate, then submitting a new certificate (this would mean two transactions)?
– By amending the existing certificate?
Further to this, on page 54, it is stated that: “If a certificate is cancelled and replaced with a new certificate, the certificate number of the cancelled/replaced certificate MAY NOT be reused and allocated to the same or another employee in the same or prior transaction year”. Does this mean that a replacement certificate must have a new certificate number even though it completely replaces the original incorrect certificate?
Directive Number (page 57): In the ‘Data’ column it states that “this field can be repeated up to 5 times”. This instruction is not repeated for each of the directive fields that follow, but it should be, or else there must be a general instruction header for all directive fields. The same applies to the directive fields in the YTD certificate specification. See also Deon’s comments in this regard.
General Comment Regarding File and Record Structure Principles: The following comments are made from my position of no longer being ‘hands-on’ with the design and coding of computer systems for many years (decades …). Bear with me … I am trying to standardise record structures to simplify both the coding of systems as well as the debugging of data, so perhaps these comments will resonate somewhere.
My comments focus on achieving consistency by standardising the records and fields as far as possible.
1. There are 7 record types listed in section 4.2, and 9 different record types listed in section 5.1 in point 4 (7 x fixed length records) and point 5 (2 x variable length records). This is because the ‘Employee Monthly Certificate’ consists of 2 records: a ‘Header’ record, followed by a ‘Financial Information’ record, as does the ‘Employee Year-to-Date Certificate. I assume that the intention is that the ‘Header’ record (fixed length) must be followed directly by the ‘Financial Information’ record (variable length) in the file, in which case these two record types must be physically connected into one record when creating the tax certificate. Is this correct?
2. The third field in the Employee Demographic and Employee Header record types is ‘Record Status’ with values (N(ew), A(mend), and C(ancel)). [As an aside, many systems use A(dd), (C)hange, and D(elete) that are then in alphabetical sequence].
a. The Employer Demographic record does not have such a field – [Consider adding this field?]
b. The Employer Declaration record has the ‘Declaration Status’ –

[While this field has a similar purpose, it understandably has different values (OR and RFC) that relate to the current EMP201 administration and presumably cannot be aligned to N, A, and C].
3. There is a “Unique Employee Identifier’ field, a ‘Unique Monthly Financial Record Identifier’ field, and a ‘Unique YTD Financial Record Identifier’ field. Presumably these fields link the various records for an employee together. The structure of the three ‘Unique … Identifier’ fields is not specified. Consider specifying the first portion of the number as a standard format and then allow the payroll to add to that to ensure that the number is unique as is the case with the tax certificate number. Why are there three different names? Consider a standard name such as ‘Unique Employee Identifier’.
4. Seven of the nine record types are now specified to be fixed length and source codes have been removed from them. The other two record types (the employee ’Monthly Financial Information’ and ‘YTD Financial Information’ records are variable length, code driven, and pipe delimited (the same as the current bi-annual BRS). Within the fixed length records, there are variable length fields. Assuming that the intention is that each field must start on a fixed position in the record followed by a fixed length, this makes no sense to me.
For example: The Employer Demographic record (fixed) has an optional field ‘Employer Physical Address: Complex’ that has a length of ‘0:0 if not completed, or 1:26 if completed’. Therefore the length of the data in this field in the record can vary from 0 to 26 characters, yet it is included in a fixed length record. If the record contains variable length fields, then it effectively becomes a variable length record, irrespective of whether the fields are still pipe delimited and despite the apparent intention to place the fields in a fixed position within the record. Deon picked this up at an early stage of BRS V0.4 and I haven’t yet seen an explanation of how this must work.
5. I am assuming that the reason for changing the 7 x record types to fixed length and the removal of the source codes is because there are no more available source codes. If not, then my comments that follow can be ignored. It is not possible for me to substantiate the following comment, but it appears that by removing the codes and imposing fixed length records for 7 of the current record types, the volume of data to be transmitted will be increased rather than reduced, particularly if one takes into account the submission of corrections to earlier accrued amounts that will increase the number of fixed length records that are submitted. In his comments, Tom motivates the advantages of using source codes that have stood the test of time (25 years) coupled to pipe delimited variable length records, and I agree with him. Is it possible to consider finding an alternative solution such as increasing the length of the source code from 4 to 6 digits, or changing the source code format from a numeric 4-digit field to an alphanumeric 4-character field? Without knowledge of the current application of these codes internally within SARS or the SARS plans for systems in the future, it occurred to me that this is an opportune time to change the format of these codes to allow their use to be expanded to other administration and system areas such as provisional tax, and to third-party data from retirement funds, medical schemes, banking institutions, perhaps Government data, VAT, etc. If a change to the code structure will facilitate a wider application and more flexible systems in the future, then the time to make the change is now.
6. In the Employee Demographic record, the mandatory field “Employee Residential Address: Street/ Name of Farm” is specified to have a min/max length of ‘4:26’. Why is there a minimum length of 4 characters for this field and not one?
There are some other fields that have min/max lengths that on the face of it, don’t make sense.
Comments from Rob (PAGSA Manco) – End

Comments from Niel (PAGSA Manco) – Start
Section 1.2 – LIST OF DEFINITIONS: “Type of Certificate” – Page 5: Move “Type of Certificate” to the correct alphabetical position in the list of definitions.
Section 1.2 – LIST OF DEFINITIONS: “Period of Assessment” – Page 6: This term was deleted in version 0 4 of the BRS. Although the term is not necessary, if the term is re-instated, it will make employers realise that there is a difference between –
1. “Transaction Month”: (Refer to the definition of ‘transaction month’, also understood to be the payroll processing month), and
2. “Accrual Month”: (The month in respect of which payroll taxes are payable – consider changing ‘period’ to ‘month’ to align the term to “transaction month”). If “Accrual Month” is re-instated, consider amending the description to read: “The month during which the remuneration became payable or was paid, whichever occurred first, i.e. the month during which the remuneration accrued to the employee.”
Detailed explanations of:
1. “back-dated accrual rules”, when backdated salaries or pensions are considered
2. “ante-dated salaries or pensions” as contemplated in section 7A of the IT Act,
3. how employers should deal with “antedated salaries or pensions” for PAYE purposes (i.e. directive application, PAYE calc, declaration, etc),
4. the deemed accrual rules applicable to “variable remuneration” as contemplated in section 7B of the IT Act,
should be added to the Guide to Employers in respect of Employees’ Tax, SDL and UIF contributions purposes, especially if the term “Period of Assessment” or “Assessment Month” is not re-introduced!
Section 1.2 – LIST OF DEFINITIONS: “Transaction Year” – Page 6: Consider adding the following words into the 2nd sentence of the 1st paragraph: “This could include employees’ tax, unemployment insurance fund contributions and skills development levies on remuneration which accrued during a previous tax year.”
Section 5.3.2 – EMPLOYER DECLARATION: Total Monthly Liability – Page 29: This field is described as “The total tax liability payable to SARS”. Should the name of the field not be the “Total Monthly Liability Payable”, i.e. total monthly liability payable after ETI utilised?
Section 5.4.1 – EMPLOYEE DEMOGRAPHICS: Income Tax Reference Number – Page 35: Amend the “Transaction Period” in the Conditional Rule column to read “Transaction Month”.
Section 5.4.2.2 – EMPLOYEE MONTHLY CERTIFICATE – Header: Certificate Number – Page 54: To confirm: The same ‘CCYY02’ certificate no can therefore be used for the 12 monthly submissions during the year and will only be unique if read with the Transaction Month?
Section 5.4.3.5 – EMPLOYEE MONTHLY CERTIFICATE – Monthly Financial Information – Deductions, Contributions and Information Codes: Current S 11(nA) remuneration overpayment recoupment – Page 74: To confirm: “Current …… recoupments” refers to recoupments during current year of assessment?
Section 5.4.3.6 – EMPLOYEE MONTHLY CERTIFICATE – Monthly Financial Information – Employee’s tax deductions: 4150 Reason code for IT3(a) – Page 79: The first sentence in the Logic column reads “Value can only be 2 or 02 if the Gross Employment Income (taxable) [source code 3699] is less than the Income Tax Threshold for the employees.” Theoretically 3699 may be greater than the tax threshold, but the balance of rem (i.e. after taking par. 2(4) deductions into account) may not exceed tax threshold! The logic validation will however still work!
Section 5.4.3.7 – EMPLOYEE MONTHLY CERTIFICATE – Monthly Financial Information – Gross Remuneration Codes: Gross SDL Remuneration – Page 82: Does the term ‘Gross SDL Remuneration’ refer to remuneration before or after taking par. 2(4) deductions into account? Keep in mind that SDL is payable on the ‘leviable amount’ which is equal to the balance of remuneration as calculated for PAYE purposes, i.e. after taking the par 2(4) deductions into account. The ‘leviable amount’ may therefore be less than Gross Remuneration!
Section 5.4.3.7 – EMPLOYEE MONTHLY CERTIFICATE – Monthly Financial Information – Gross Remuneration Codes: Tax Provision Indicator – Page 83: What is the difference between this field (Tax Provision Indicator) and the Provision for annual payments?
Comments from Niel (PAGSA Manco) – End

Comments from Deon (Intercode) – Start
Definitions – Transaction Period (Page 6): If a ‘transaction period’ always refers to a specific month, consider renaming to “Transaction Month” instead. [Rob: Agreed, but see the SARS explanation in my section of the comments]
Section 4.6 – File Name Structure Requirements (Page 9): This section contains bullet points listing the fields that make up the file name, including the “source code” associated with each field. Consider removing these bullet points and source codes, as those fields are now in a fixed layout and no longer have any source codes.
Section 5.1 – General Rules point 4 (Page 12): This section specifies that “The following record types must be created in a fixed format with the start and end position of each field as determined by the minimum and maximum field length indicated for each field”. From the above it is unclear whether these records should be created in a fixed layout or as pipe delimited values. When this was queried with SARS, we received a reply indicating that the relevant records must be created in pipe delimited format with no fixed start and end position for each field, but the fields would have to be in a specific order.
Consider rewording section 5.4 to clarify what is required.: [Rob: See also comments from other members in this regard]
Conditional and Optional Fields in Fixed-Format Delimited Records
For all record types that are specified in a fixed delimited layout, conditional and optional fields must still be included in the file (indicated by two consecutive pipes), even if their values are zero. Failure to do so will cause all subsequent fields to have incorrect field (or column) indexes.
File Header – Data Type Being Supplied (Page 15): Data Type is “AN”, but value can only be “MPD” (Alpha).
File Header – Channel Identifier (Page 15): Data Type is “AN”, but all possible values are Alpha only.
File Header – Technical Contact Email (Page 18): The minimum field length is specified as “3”. Considering that email addresses must have an “@” sign and a domain (indicated by a “.”), it would stand to reason that the minimum length of an email address should be at least “5” (e.g.: [email protected]). The same would apply to all email address throughout the BRS.
Employer Physical Address – Street Name of Farm (Page 19): Both the field name and description contain a spelling mistake in “Street Name of Farm” (should be or Farm). Search and replace other instances as well (total 10 instances).
Telephone and Cell Phone Numbers: In various instances throughout the BRS telephone and cell phone number fields are defined as “AN”, though the validation rules state that “Only numeric values are allowed”. Consider changing the Data Type of all telephone/cell phone fields to “N” instead.
SDL Reference Number (Page 23): The field “Length” is defined as “1:10” (Should be 10:10).
UIF Reference Number (Page 23): The field “Length” is defined as “1:10” (Should be 10:10).
Employer SIC7 Code (Page 24): Data type is defined as “AN” but “Only numeric values are allowed”.
Transaction Month (Page 25): Description states “The period during which…” If the “period” can only be a month, consider rewording to “The month during which…”
Employer Declaration (Pages 26 to 29): Not all the fields highlighted in yellow have both a minimum and maximum length defined.
Employee Demographics – Unique Employee Identifier (Page 31): The description states that “The value of this field must be unique and must not be re-used in any other monthly payroll file”. It is our understanding that this field is only used to link records related to the same employee within the current declaration file. As such, there is no reason why the same identifier could not be re-used to identify all records related to the same employee in a different declaration file together within the context of that file. On the contrary, there is a high likelihood that the same unique identifier will always be used to link the records of a particular employee in different declaration files. Also consider updating the Name, Description and Logic columns for this field to use the same naming convention as is used for the same identifier in the Employee Monthly Certificate and Employee Year-To-Date Certificate records, to make it clear the values should match in all these records. [Rob: and use the same for this field in all the record types]
Employee Demographics – First Two Names (Page 32): The minimum length for this field is defined as “3”. An employee might have only one first name, which might be “Al” or “Li”. Taking Asian countries into account, it is also conceivable that an employee’s first name might consist of one letter only.
Employee Demographics – ETI Indicator (Page 37): The “Logic” column of this field includes references to codes 3020, 3025, 3190, and 2030, all of which no longer exist (because of the “fixed” record layout). Check the BRS throughout for references to “field codes” that no longer exist.
Employee Monthly Certificate – General Rules (Page 52): The first bullet point states that “…, those who do not have a value must not be reported”. It should be clarified that this now only applies to financial codes. For fixed layout records, fields that do not have a value will still have to be reported to maintain the integrity of the field (or column) indexes.
Employee Monthly Certificate – Transaction Month (Page 53): Description states “The tax period during which…”. In a payroll context a “tax period” usually refers to a period in respect of which a tax certificate was issued, which usually spans multiple months. Consider rewording as “The month during which…” or “The payroll month during which…”.
Employee Monthly and YTD Certificates – Directive Number (Pages 57 and 94): The validation rules state that “This field can be repeated up to 5 times”. Considering that:
• The Employee Monthly Financial Information Header record now uses a fixed layout, and;
• The Employee Monthly Financial Information does not, and;
• The Employee Monthly Financial Information Header and the Employee Monthly Financial Information are in fact one record (i.e.: included in the file on a single line);
all directive number fields will therefore always have to be repeated 5 times (even if they are empty) to maintain the integrity of the field indexes. If all directive number fields are not included 5 times by means of consecutive pipes, E-Filing and/or Easy-File wouldn’t know which column in the file is the first “financial information column”.
Employee Monthly Certificate – Directive Numbers in General: Does it really make sense to include “Fixed Rate” directives in the monthly financial information at all? If an employee has a fixed rate directive it would apply to multiple months, or possibly the entire tax year (i.e.: to a “tax period”). If it was specified on a month-to-month basis, there would have to be requirement that the directive number or rate would have to remain the same for all the months in a tax period. If the fixed rate was introduced (or changed) in the middle of a tax year the employer would have to issue a separate certificate anyway. If that is the case, would it not make more sense to include fixed rate directives only in the YTD record instead, as the YTD record would include all the information for the entire tax period to which the fixed rate directive applies, and then include only lump sum directives in the monthly information?
Employee Year-To-Date Certificate – Periods in Year and Periods Worked (Page 92): For both the Pay Periods in Year of Assessment and Pay Periods Worked, the “1.000” in the Logic column should be “1.0000” (i.e.: 3.4).
Comments from Deon (Intercode) – End