iXBRL for CIPC: why packs are marked TEST
What Achekam's iXBRL tool produces from a set of statements or a trial balance, why every pack says TEST for now, and what stays with the firm.
By Achekam · · 4 min read · For Accountants & audit firms in South Africa
A manager runs a client's statements through the iXBRL tool, opens the ZIP and finds TEST written across the output. The first reaction is usually that something has failed. It has not. The marking is deliberate, and it tells you something important about the difference between a file that is well tagged and a file a regulator will accept.
For South African firms the distinction matters because the tagged file is what CIPC receives, and CIPC administers the Companies Act. This article explains what Achekam builds, why its packs are TEST packs today, what has to happen before a production pack can be made, and which steps never leave the firm's hands.
Two starting points: statements or a trial balance
Achekam turns either a set of financial statements or a trial balance into an iXBRL file. You can start from FINANCIAL INTAKE > iXBRL Projects, or from the publish step at the end of the Financials Studio.
Starting from the statements is the natural route for a set the firm has prepared and issued in Achekam. Starting from a trial balance suits a client whose statements were produced elsewhere but whose balances you hold.
One design choice helps here. A firm can add its own statement lines and groups and rename any row title, but each custom line still totals into a standard line. That keeps the notes, the cash flow and the iXBRL tags consistent with one another, so a line you renamed for the client's benefit does not lose its place in the tagging.
Validation and the ZIP pack
Once the file is built, Achekam checks it with its own validation and packs the iXBRL file and the validation report together in a ZIP.
Read the report rather than treating the ZIP as a finished article. Achekam's validation is its own check of the file it built. It is not CIPC's acceptance, and nothing in the report should be read as a statement that CIPC will take the file.
Why the pack says TEST
An iXBRL file is only as good as the taxonomy behind it: the dictionary of elements each figure is tagged against. A regulator publishes its own taxonomy, and a filing has to use it.
The taxonomy built into Achekam is a partial list that Achekam wrote itself. It is enough to exercise the process, tag a set, run validation and see how the output looks. It is not the official CIPC taxonomy, so Achekam marks every pack made with it as TEST, with the reason TAXONOMY_NOT_OFFICIAL. Achekam refuses to make a production pack until someone uploads and approves the official CIPC taxonomy package.
That refusal is the honest choice. A file tagged against an unofficial list could look complete and still be wrong in ways nobody notices until the regulator rejects it.
Moving to a production pack
The route from TEST to production runs through the taxonomy, not through the statements. Until the official CIPC package has been uploaded and approved in Achekam, every pack stays a test pack, however polished the statements behind it. CIPC's XBRL programme page covers the mandatory iXBRL filing of annual financial statements for qualifying entities, the taxonomy and the programme's objectives.
When your firm takes that step, treat it as a controlled change:
- obtain the taxonomy package from CIPC itself, not from a copy passed around by e-mail;
- record which version was loaded and when;
- have the approval done by someone other than the person who uploaded it, as a matter of firm policy;
- rebuild a recent client's file and compare the validation report with the TEST version before relying on it.
What stays with the firm
Achekam does not file iXBRL with CIPC. The pack it produces is for the firm, or the client, to lodge through CIPC's own channels.
| Step | Who does it |
|---|---|
| Prepare, review and issue the statements | The firm, with the Studio |
| Build the iXBRL file and run Achekam's validation | Achekam, when staff start it |
| Load and approve the official CIPC taxonomy | Someone in the workspace |
| Check the tagging against the issued statements | A person at the firm |
| Lodge with CIPC | The firm or the client, outside Achekam |
The issued statements are the anchor for all of this. Achekam makes the statements as an A4 PDF on its server, and issuing stores the final PDF with a fingerprint and locks that version. Whatever you lodge should be built from the same set you issued, so check that the figures in the tagged file match the locked PDF line for line before anything goes to CIPC.
Using TEST packs well
A TEST pack is still useful. It lets a team rehearse the process on real clients before the official taxonomy is loaded, and it shows early where a custom line or a renamed row needs attention.
- Build a TEST pack from a set you have already issued.
- Read the validation report and note every warning.
- Compare the tagged figures with the locked PDF.
- Check how your custom lines rolled into standard lines.
- Keep the TEST output out of anything sent to CIPC or to the client as a filing.
Where this leaves the firm
If your firm needs production iXBRL, the next step is a decision about who loads and approves the official CIPC taxonomy, and when. Until then, use TEST packs to prepare, not to file. How the underlying set is locked is covered in issuing statements: the final PDF and a locked version, and the client's sign-off before that point in getting the client's approval on draft statements.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
