PAGSA COMMENTS ON DRAFT MONTHLY PAYE BRS V0.4 (2 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 Ania (Payspace) – Start
Section 1.2, page 6: Definition of “Transaction Period”.: Throughout the BRS, reference is made to “transaction month” and not “period”. Consider changing the definition to “Transaction Month” to align with the rest of the BRS.
Section 5.2, page 13: File Create Date: The data type for this field refers to FT (free text), however the format must be CCYYMMDDhhmmss, therefore only numeric values will be used.
Section 5.3.1, page 20: Employer Physical Address: Postal Code: The data type for this field refers to AN (free text), however only numeric characters are allowed. It states that the min and max can be 1:10 but in the data validations is state that only 4 numeric characters are allowed. This applies to all postal code fields in the BRS.
Section 5.3.2, page 25: Declaration Status: The min and max length is 3:3, however the status can be OR or RFC, consider changing to 2:3. In the description it refers to “new record, an original or request for correction”. Is new and original not the same since only OR or RFC is allowed.
Section 5.3.2, page 25: Transaction Month: In section 1.2 (definitions), the definition is “transaction period” and not month. Considering changing the definition to ‘transaction month’ to align with the rest of the BRS (aligns with bullet above).
Section 5.3.2, page 26 onwards, all numeric fields containing a decimal.: The data type refers to “N”, however, the field contains a full stop (“.”). Should this not be changed to AN to include the full stop in the data type.
Section 5.3.2, page 26: PAYE Liability: It should be the sum of 4102 and 4115.
Section 5.3.2, page 26: ETI Calculated: From what I understood is that ETI corrections should be done the same way it is currently done. In other words, if the employer underclaimed ETI in a previous period within the same 6-month reconciliation period, the ETI should be added to the current month’s ETI calculated. However, the 7004 value will refer to a previous month, therefore the ETI calculated will not balance with the underlying data of 7004 for the transaction month. Is my understanding correct?
Section 5.3.2, page 28: SDL Liability and UIF Liability: Will this be the only validation in which SDL will be allowed to be zero, exemption flagged on employer level? What if there are circumstances in which the employer submits file with just one employee containing a value which is exempt from SDL (e.g. severance pay), in this case, SDL will be zero but the employer may not be exempt from SDL? The same applies to UIF.
Section 5.3.2, page 28: SDL Liability: If an employer only becomes liable to pay SDL in the middle of the tax year, how will SARS apply the SDL validations at the end of the tax year on YTD data, will it simply use Gross SDL remuneration to validate the SDL amount?
Section 5.3.2, page 29: UIF Exempt Indicator and UIF Termination Date: In which case will an employer be exempt from UIF, can only apply to an employee considering section 4 of the Unemployment Insurance Contributions Act? This will affect the termination date.
Section 5.4.1, page 36: Employee SIC7 Code: All valid values are only numeric values (as per Appendix C), but the data type refers to AN.
Section 5.4.1, page 30: Should the below not refer to Street Name/Name of Farm to clarify across the entire BRS: Employee Physical Work Address Details: Street/Name of Farm
Section 5.4.1, page 50: Employee bank account number: The data type is AN but only numeric characters are allowed.
Section 5.4.2.1, page 52, General Rules: Should employees who are on for example maternity leave and receives 0.00 income (but are still employed) be excluded from the monthly file entirely based on the below rule? “At least one income code with a value greater than zero must be completed for every certificate reported in the month, except if medical scheme contribution in respect of retired/former employees (source code 4493) is completed and the employee has no other income to be reported;”
Section 5.4.2.1 page 52: General rules: Should the rule below not also apply to retirement fund contributions contributed on behalf of a retired employee, reported against IRP5 codes 4585 and 4586? “At least one income code with a value greater than zero must be completed for every certificate reported in the month, except if medical scheme contribution in respect of retired/former employees (source code 4493) is completed and the employee has no other income to be reported;”
IRP5 codes: Suggestion- is it possible to create a new IRP5 code for a fuel card/petrol card, especially since non-cash remuneration values are excluded from ETI remuneration and currently a travel allowance and fuel card are reported against IRP5 code 3701. [Rob: Agreed. The same principle applies to dividends (in specie dividends are not cash)]
Section 5.4.2.3.7, page 83, provision for annual payments: Clarity should be provided whether the provision for annual payments should report the actual portion of the annual payment included as provision in the month, or the provisional tax value calculated on the annual payment for the month.
Section 5.4.2.3.7, page 83, fixed rate taxation indicator: I assume this is only for non-standard employees taxed at 25% and par2(2B) fix rate taxation. If yes, please consider clarifying. The same will apply for the YTD certificate.
Section 5.4.2.3.7, page 85, ETI SEZ Code: All the SEZ codes are only numeric, but the data type refers to AN.
Section 5.4.3.1, page 87, general rules: I am still concerned about this, since variable remuneration items, directive lump sums etc. can be paid after the last month of employment, meaning that the YTD certificate will change after the last month of employment. In this case, should the employer submit another YTD certificate in February? Will it override the original one submitted in the termination month? If the employee is terminated in the transaction month, should the file ONLY contain a YTD certificate and not a monthly certificate for this employee?
Section 5.4.3.1, page 87, general rules: If a YTD certificate is cancelled in February (i.e., the certificate should not have existed for the entire year) should it include all previous 12 months with a cancelled certificate based on this rule.
Section 5.4.3.2, page 92: pay periods in the year of assessment and pay periods worked: Pay periods in the year of assessment and pay periods worked min and max should be 1.4:3.4. Consider changing the name to ‘pay periods employed’. Pay periods worked still refers to source code 3200 which no longer exists.
General:
• From what I understand, the ‘month of accrual’ will be indicated by the ‘unique monthly financial record’ since the ‘period of assessment’ field is removed for amended and cancelled certificates. In other words, if the employer submits an amended certificate for a previous month, the ‘unique monthly financial record’ number should be the same as the previous month.
• Clarity must be provided on how demographic data should be amended if necessary. The employee’s demographic data is not linked to a transaction period or period of assessment. How will demographic detail be amended for a previous period?
• According to me the pay periods worked is required to apply a PAYE validation (based on annualised balance of remuneration) each period, how will the PAYE validations be applied each period based on the monthly data? [Rob: It was agreed during the PAGSA/SARS discussions in 2021 that the only practical way for SARS to apply ETV to validate PAYE on a monthly basis was for payrolls to report the ‘Annualised Balance of Remuneration’ that was used by the payroll for that month on the monthly tax certificate.]
• Examples of corrections, cancellations etc. for the following would be appreciated and based on the examples, additional comments and/or questions may follow.
o variable remuneration
o non-variable remuneration,
o static data,
o incorrect lump sums (directives) etc.
Comments from Ania (Payspace) – End

Comments from Yolandi (Sage) – Start
ER declaration (5.3.2): Direct channels
1. In the meeting it was confirmed that the employer declaration must not be included for the direct channels as these fields will be pre-populated.
• I suggest that it is clarified in the BRS that the employer declaration must not be completed for either the direct or indirect channels as this will create the impression with payroll providers that they should cater for different layouts.
2. Should these values be declared again when submitting an ‘Amended’ or ‘Cancelled’ certificate for a previous period. For example, it is June, and an amended certificate is submitted for March – which affects the carry forward value of ETI for April until May. Should the employer submit an amended declaration for April and May as the ETI brought forward (and carry forward) value might have changed? It is not clear from the BRS.

ER declaration (5.3.2): ETI brought forward, ETI utilised, ETI carried forward, PAYE Payable
1. When submitting on eFiling or e@syFile, the employer declaration is not included in the file, and therefore the ETI brought forward, utilised, carried forward and PAYE Payable will not reported. If the direct channels are used for submission, will the ‘stand alone service’ allow for consolidations and declaration of these values.
2. Will SARS be populating these values in the ‘stand alone service’? Please clarify this in the BRS.
ER Declaration (5.3.2): UIF Termination Date
This is on employer level.
In which case will the employer not be required to pay UIF contributions from a specific date? For example, if all the employees in a particular month works less than 24 hours – do you expect a termination date in that month, and if in the next month the employees work more hours and contributes, there shouldn’t be a date?
The only other reason why an employer will be exempt is when it is a government employer, which is unlikely to change from a private sector employer to a government employer from a specific date.
ER declaration (5.3.2): UIF Exempt indicator
There is no UIF Exempt Indicator for the employee, but only an indicator for the employer? Is this the intention? If the employer is not exempt, it is possible that the employee might still be. Maybe add the ‘UIF Exempt Indicator’ on employee level too.
[Rob: My understanding is that if the employer is excluded from UIF contributions by the Application of the Act in section 4 of the UI Contributions Act (eg, a government employer) then all its employees will be automatically excluded.]
EE demographics (5.4.1): Record Status
• Is it possible to provide definitions for ’new’, ‘cancelled’ and ‘amended’ certificates in order to make it clear?
• Should a certificate be cancelled if I have declared an employee, but it should never have been declared? For example, the declaration was submitted but the employer only realises in the next month that the employee was terminated and shouldn’t have been included in the previous submission file.
• Should an amended certificate be submitted if demographics are amended?
• Should an amended certificate be submitted if the liabilities have not changed? For example, an incorrect non-taxable bursary code was used – 3815 instead of 3821?
EE demographics (5.4.1): Email contact field lengths
Align the contact length of the email addresses in the file header, employer demographics and employee demographics.
EE Monthly Certificate (5.4.2): General rule
1. Is there a specific reason why a negative value is allowed for an ‘amended’ monthly certificate?
2. Is PAYE (4102) allowed to be negative in a month? An example would be where the employee made provision for tax on annual bonus but resigns before the bonus is paid.
3. In practice, if an employer reported a non-taxable bursary amount against the incorrect non-taxable bursary code (3815 instead of 3821) for example, then the employer will simply enter a negative amount against the incorrect IRP5 code and a positive against the correct one. By doing this, there will be no tax implication but the codes on the year to date certificate will be correct. Is it expected that employers amend previous monthly certificates to correct this? If not, negatives must be allowed.
EE Monthly Certificate (5.4.2): Gross remuneration codes (3695)
Is it possible to specify which source codes may be classified as ‘gross annual income’. For example, may fringe benefits be seen as ‘annual payments? What about code 3622 (cash long service awards), shares (3707, 3717, 3718), dividends (3719, 3720, 3721, 3723), bursaries etc.
EE Monthly Certificate (5.4.2): Unique Monthly Financial Record Identifier
1. It is not clear from the BRS, what the purpose and difference is between the ‘unique employee identifier’, ‘unique monthly financial record identifier’ and the ‘unique YTD financial record identifier’..
2. May the ‘monthly unique identifier’ be the same as the ‘YTD unique identifier’?
3. Should the monthly and YTD identifier be different from the ‘unique employee identifier’?
4. Should there not a differentiator between employees with multiple certificates in the same period, for example where employee is re-employed in the same period?
EE Monthly Certificate (5.4.2): Certificate Number
Add a validation to include the transaction year before the calendar month.
EE YTD Certificate Information: General Rules (5.4.3.1)
Clarify that the Year-to-Date certificate must include the values of the current period e.g. the Year to Date certificate must not exclude the current transaction period values.
EE YTD Certificate information (5.4.3): Pay periods in year of assessment (3210)
Please clarify the acceptable values e.g days/weeks/bi-weeks/months.
General – Source codes
I’m assuming source codes will still be allocated to the fields without source codes?
Some source codes were removed from version 4 of the monthly BRS. Was this intentional?
General – Corrections
Is it possible to provide examples of the submission file when a ‘correction’ is made, in the following instances:
1. Under payment of variable remuneration in a prior month (section 7B).
2. Over payment of variable remuneration in a prior month (section 7B).
3. Under payment of non-variable remuneration in a prior month (non-section 7B).
4. Over payment of non-variable remuneration in a prior month (non-section 7B).
Comments from Yolandi (Sage) – End

Comments from Tom (PAL Solutions) – Start
Removal of source code identifiers
I want to comment on the removal of source codes from the record layout in several of the record types.
I understand that the administration for the allocation of new source codes is a painful process and involves extra work and resources. However, the benefits of a system with the volume of data that this system has makes it critical to have a source code driven file layout.
The current tax certificate file layout was designed in 1998 and has stood the test of time with major data item additions and deletions during the last 25 years.
With the complexity of different record types in the file the debugging of systems is going to be a nightmare.
Where a simple file layout with limited columns is used it is simple to include a header line defining each column and then importing that file into Excel to be able to check that the detail is recorded in the correct column.
With the proposed record layouts this will be a hair-raising task to identify where a problem is.
The initial release will have problems to get everything working, but the real drama is going to come when extra fields are added, or old fields removed from the file. The fact that the header record provides for the file version number will assist to know what the file layout should look like but with so many different systems being involved I can see that changes down the line are going to be an issue.
When the original file structure was introduced, I spent many hours with the SARS developers debugging the systems and if it wasn’t for the source codes that process would have been almost impossible to get resolved.
Another point to take into consideration is that it is less confusing to refer to a unique field code when referring to a data item than a description. SARS always refers to Section xx or Schedule yy or paragraph a(b)iii(2) in the Income Tax Act and then there is certainty to what is being referred to.
As that is a standard way of doing those references it makes logical sense to keep the source codes in the BRS.
Another point on this issue is that when data is sent between systems it is accepted practice to do so in an XML, JSON or some other format that identifies each data item with a tag. These tags are usually long descriptions. Therefore using a 4-digit source code is a much more efficient method of identifying the data items.
The current BRS specification will only require an additional first column in the tables for the recording of the Source Code and therefore the rest of the document is still effective.
References to other fields in the BRS can have the source code included for clarity.
Record Structure
Section 4 on page 9 defines the record structure as:
2 The record structure of the file for employee monthly data is as follows:
o File Header Record
o Employer Demographic Record
o Employer Declaration Record
o Employee Demographic Record
o Employee Monthly Certificate
o Employee Year to Date Certificate
o File Trailer Record
Section 5.4
Checking the record layout detail of the ‘Employee’ records in section 5.4.2 there is a section 5.4.2.2 – Header which is a ‘Fixed’ record layout with 12 fields defined in this section.
This is followed by section 5.4.2.3 – Monthly Financial Information
This is a source code record layout.
The major problem here is that this record has no ‘key’ information present. The data on this record is only financial detail.
Where it is required to submit details for more than one period there will always be a header and financial record present on the file so that the financial data can be allocated to the correct period.
From a processing point of view having a financial record without any ‘key’ details is not good.
It would make much more sense to only have one record with the header and financial data together. This would then conform to the detail specified on page 9.
The same situation applies to the year to date record.
Telephone and Cell phone numbers
The length specification in the ‘File Header’ and ‘Employer Demographics’ records for these numbers is 0:0 or 1:15, but the validation rules require a number to be at least 10 characters long where the field is present.
Section 5.4.1
Identity Number (Page 33)
Length is specified as 1:13 but the Validations require this to be a South African Id number which is 13 characters.
Passport number (page 34)
Length is specified as 1:18 but Validations require a minimum of 6 characters.
Date of Birth (page 35)
Format is fixed and validation specifies format as CCYYMMDD but length is 1:8, should be 8:8.
Page 44 onwards – Postal Address
As there are different formats of Postal address depending on the ‘Postal Address Structure Indicator’ it would be safer to have this as the last section of the record.
If it is accepted that the Source codes are to be retained in the records, then the positioning of the Postal address data fields in the record is not a concern.
Section 5.4.2.1 Page 52
Bullet 4
Why is it not allowed to have a negative value for a ‘New’ transaction BUT when it is an ‘Amended’ transaction a negative is allowed? I thought that with amendments the full transaction must be supplied and not the delta. Therefore with an amend a negative can be loaded but not when a new record is supplied.
Section 5.4.3.1 Page 87
Under the General Rules bullet 2 it is stated that the year-to-date certificate must be included ‘in the last month of employment for employees who are no longer employed’.
This is not practical as payrolls are processed in advance of pay day and therefore there are generally additional payments in the next month or even two months later.
Many of these payments are for variable payments for example overtime. The payroll system then keeps these employees in a state of termination in suspense so that any late payments can be processed. The user determines how long they want to keep the employee in this suspense state to allow for these late payments to be processed. The employee is then only terminated after the user defined suspense end date is reached. The termination date recorded for the employee is the actual termination date which can therefore be a few months back.
Under these circumstances if this rule is to be applied there will be a year-to-date record for each month that the employee is in this suspense state. The transaction month will be the month in which the employee was paid for the variable payment BUT the termination date will be before the transaction month.
This is what happens in the payroll world. Will the monthly processing of data cater for this condition?
Comments from Tom (PAL Solutions) – End