Tagging client-specific lines: extension taxonomies
How a line that is unique to one client gets tagged in XBRL, why extensions come last, and why custom lines should still total into standard lines.
By Achekam · · 4 min read · For Accountants & audit firms in South Africa, Nigeria, Kenya
Every client has a line nobody else has. A game lodge shows "Anti-poaching costs", a church shows "Tithes and offerings", a courier business separates "Toll fees" from fuel. On paper that is a presentation choice. In a tagged filing it becomes a technical question: if the standard dictionary has no word for this line, how is it tagged?
The answer has two halves. Search harder for an existing element first, and use an entity-specific one only when nothing standard fits. Then make sure the custom line still adds up into something standard.
When the standard taxonomy seems to have no element
XBRL International explains that the concepts against which figures in an iXBRL report are tagged, such as "ifrs:Revenue", are drawn from a dictionary of concepts called a taxonomy. A standard taxonomy serves common needs, and many client-specific lines turn out, on closer reading, to be ordinary concepts wearing unusual names. "Tithes and offerings" is a church's revenue. "Anti-poaching costs" may well be a kind of security or operating expense.
So the first step is to ask what the figure is, not what the client calls it.
Common-practice elements before extensions
The IFRS Foundation states that the IFRS Accounting Taxonomy contains elements for disclosures not specifically required by IFRS Accounting Standards but commonly reported in practice. That changes the search. A line no standard requires may still have a standard element, simply because enough companies report it.
A sensible order of search:
- An element for the exact concept a standard requires.
- An element for a concept commonly reported in practice.
- A broader standard element that the line forms part of.
- Only then, an entity-specific element.
Extensions for items truly specific to the entity
XBRL International explains that an entity-specific taxonomy, known as an extension taxonomy, can be used in iXBRL to tag items specific to a reporting entity, such as its operating segments. Segments are a fair example of a genuine extension: one group's "Coastal retail" segment has no counterpart in anyone else's report.
Extensions carry a cost. Software comparing many filings cannot tell what an entity-specific element means relative to other companies unless it is anchored to something standard. Used freely, extensions defeat the purpose of tagging. Whether and how extensions are allowed is also a matter for each regulator's filing rules, so check before creating one.
Custom lines that total into standard lines
The safest pattern is to make the custom line a part of a standard line. "Toll fees" and "Fuel" sit beneath a standard expense line; "Tithes and offerings" sits within revenue. A user of the data can still find total revenue in its usual place, and the custom detail adds information without hiding the total.
Achekam's Financials Studio is built around this pattern. A firm can add its own statement lines and groups and reword any row title, and later builds keep those choices. Each custom line still totals into a standard line, so notes, cash flow and iXBRL tags remain consistent. The firm decides the presentation; the structure underneath stays anchored. How the feature works is described in custom statement lines and groups.
Achekam's iXBRL output is for South African clients only. Its built-in taxonomy is a partial list Achekam wrote, so it produces test packs; a production pack waits until the official CIPC taxonomy package is uploaded and approved, and Achekam does not file with CIPC. For Nigerian and Kenyan clients Achekam does not produce iXBRL, though the roll-up discipline applies whatever tool does the tagging.
Reviewing mapping before tagging
An extension on a well-understood line is a minor matter. A standard tag on a wrongly mapped account is a serious one, because it reports the wrong figure under a trusted name.
When Achekam's Studio builds a draft, AI mapping suggestions with a confidence of 0.5 or more go into the draft at once and are listed as proposals a person can accept, move or set aside. No rule was found that stops signing while those proposals remain open; the safeguards are the review stages and the partner's signature. The mapping workbench (Canvas, then "Mapping") shows each account's line and note and lets staff move accounts by hand.
So before any tagging step:
- decide every open AI mapping proposal one by one, rather than leaving them sitting in the draft;
- check that each custom line rolls up into the standard line a reader would expect;
- look hard at any account parked on a vague line such as "Other income" or "Sundry expenses", and move it if a specific line exists;
- for every proposed extension, record why no standard or common-practice element fitted.
XBRL International's iXBRL overview explains the open standard behind tagged reports, including taxonomies and where regulators require them. For the basics of the dictionary itself, read the IFRS Accounting Taxonomy and tagging.
A rule of thumb
An extension should be an exception that a reviewer can justify in a single sentence: what the item is, why no standard element describes it, and which standard line it belongs under. If that sentence is hard to write, the line probably is not as unique as the client believes, and a standard element will serve the readers of the data better.
Keep those sentences on the file and carry them forward. Next year the same client will have the same lines, and the firm's earlier reasoning saves the search. It also shows a reviewer, or a regulator asking questions about a filing, that each extension was a considered choice rather than a shortcut taken under deadline pressure.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
