Compliance CK2
Validation Checks by Instafill.ai
1
Validates Corporation Registration Number structure and allowed characters
Checks that the three registration number segments (Part 1, Main Number, Suffix) are present (where required) and match the expected pattern for Close Corporations (e.g., numeric year/sequence formatting and separators). It should reject non-permitted characters (letters where digits are required, spaces, or punctuation other than the form’s separators). This is critical because the registration number is the primary key used by the registry to match the filing to the correct corporation. If validation fails, the submission should be blocked and the user prompted to correct the registration number to the official certificate format.
2
Ensures Corporation Name consistency across repeated fields
Verifies that the corporation name entered in Part A (Full name of corporation) matches the “NAME OF CORPORATION” header fields on subsequent pages, allowing only trivial differences such as whitespace or line breaks. This prevents internal inconsistencies where page headers and Part A reflect different entities, which can cause rejection or misfiling. If a mismatch is detected, the system should require the user to reconcile the names before submission.
3
Requires at least one Part A change with a valid commencement date
Checks that the amended founding statement actually records a change in Part A (e.g., name, principal business, financial year end, number of members, aggregate contribution) and that the corresponding “Date of commencement of change” is provided for the changed item(s). The form notes indicate changes are effective from registration date or the date indicated, so missing dates make the amendment ambiguous. If no change is indicated or dates are missing for changed fields, the filing should be rejected as incomplete.
4
Validates all date fields for format and calendar correctness
Validates that all dates (commencement of change, original incorporation date, financial year end date, member signature dates, and any date-of-birth used in lieu of an ID) follow a single accepted format (e.g., YYYY-MM-DD or DD/MM/YYYY) and represent real calendar dates. It should also prevent impossible values (e.g., 31/02) and enforce consistent formatting across the submission. If validation fails, the system should flag the specific field and require correction to avoid registry processing errors.
5
Checks logical ordering of key dates (incorporation vs. change dates)
Ensures the Date of original incorporation is not after any “Date of commencement of change” recorded in Part A or Part B. An amendment cannot legally commence before the entity exists, and such inconsistencies often indicate data entry mistakes. If the ordering is invalid, the system should block submission and request corrected dates or supporting explanation where permitted.
6
Validates Financial Year End as a day-month value and consistency with change date
Checks that “Date of end of financial year” is a valid day/month combination (and, if a year is provided, that it is plausible) and that a commencement date is supplied if the financial year end is being changed. Financial year end is used for statutory compliance and accounting officer obligations, so incorrect values can cause downstream compliance issues. If invalid or missing required commencement date, the system should require correction before acceptance.
7
Validates Number of Members as an integer within statutory bounds
Ensures “Number of members” is a whole number and falls within allowed Close Corporation limits (commonly 1–10, depending on jurisdictional rules applicable to the filing). This prevents filings that would be legally non-compliant or impossible to register. If the value is non-integer, negative, zero, or exceeds the maximum, the system should reject the submission and prompt for a compliant count.
8
Validates member interest percentages and enforces total equals 100%
For each member entry, validates that “Size of interest expressed as a percentage” is numeric, within 0–100, and uses an acceptable precision (e.g., up to two decimals). It also checks that the sum of all active members’ interests equals exactly 100% (with a small tolerance if decimals are allowed). This is essential because member interests define ownership and voting rights; totals not equaling 100% indicate an invalid membership structure. If the total is not 100% or any entry is out of range, the system should block submission and highlight the offending rows.
9
Validates Aggregate Members’ Contribution as a Rand amount and non-negative
Checks that “Aggregate members' contribution (R)” is a valid currency amount (digits with optional decimal cents), uses the Rand currency context, and is not negative. It should also enforce reasonable upper bounds to catch obvious keying errors (e.g., extra zeros) and disallow non-numeric characters. If invalid, the system should require correction because contribution values are part of the corporation’s founding particulars and may be used for legal and accounting purposes.
10
Ensures member identity information is complete and correctly typed (natural vs juristic person)
Validates that each member has either a valid identity number (for natural persons) or a registration number (for juristic persons), as described in Note 10(2). If “no identity document issued” is indicated (or the ID field is blank), the system must require a date of birth and an attachment indicator for the written statement per Note 8. This prevents unverifiable member records and reduces registry rejection risk. If the identity requirements are not met, the submission should be rejected with a clear instruction on what alternative information/attachment is required.
11
Validates member name fields and capacity requirements for special cases
Checks that member surname and full forenames are provided (or, for juristic persons/trustees/nomine officii, that the entity name and capacity are stated as required by Note 10(1)). It should flag entries that contain only initials, placeholders, or missing capacity where the member is acting as trustee/administrator/executor/curator. Correct identification is crucial for legal enforceability and registry accuracy. If validation fails, the system should require completion of the missing name/capacity details.
12
Requires residential and postal addresses for each member and validates minimum address content
Ensures each member record includes both a residential address (item 5) and a postal address (item 6), and that each address contains sufficient detail (e.g., street/stand, suburb/city, and postal code where applicable). This supports statutory contactability and service of notices. If either address is missing or clearly incomplete (e.g., only a suburb name), the system should prevent submission and request a complete address.
13
Validates member signature presence, signer authority, and signature date
Checks that each member entry includes a signature (item 7) and a date signed, and that the signature date is not in the future. If a representative/proxy signs, the system must require an indication that a power of attorney is attached (per Note 6) and capture the representative capacity. This is important because the form includes a confirmation statement that particulars are correct; missing or unauthorized signatures undermine validity. If validation fails, the filing should be rejected until signatures/authority evidence are provided.
14
Validates ‘Date of change’ and ‘items changed’ indicator for each member record
For each member row, validates that item 8 includes a date of change and clearly indicates which of items 1–6 changed (as required by Note 10(8)). This ensures the registry can interpret what was amended for that member (name, ID, interest, contribution, addresses). If the date is missing or the changed-item indicator is blank/invalid, the system should flag the row and require completion to avoid ambiguous amendments.
15
Validates ‘Persons who cease to be members’ section completeness and consistency
If any persons are listed as ceasing to be members, checks that each has full name and surname, identity number, and signature completed, and that they are not simultaneously listed as an active member with a non-zero interest. It should also ensure the cessation aligns with the note that membership ceases on the date of registration of the amended founding statement (i.e., no conflicting cessation date fields are introduced). This prevents contradictory membership records and ownership totals. If inconsistencies are found, the system should require the user to correct the membership roster and interest allocations.
16
Validates page count and required pages based on number of members
Checks that “Total number of pages” is a positive integer and matches the actual included pages, and enforces the rule that if there are 4 or fewer members, only pages 1 and 2 are required, while page 3 is required when there are more than 4 members. This reduces filing defects caused by missing member continuation pages or unnecessary pages that may confuse processing. If the page count is inconsistent with the member count or missing required continuation pages, the system should block submission and prompt to add/remove pages accordingly.