Tagging text disclosures, not just numbers
Inline XBRL can tag a client's notes and policies as well as its figures. What that means for how notes are written, placeholders and AI drafts.
By Achekam · · 4 min read · For Accountants & audit firms in South Africa, Nigeria, Kenya
Ask most preparers what gets tagged in a digital filing and they will name the numbers: revenue, profit, total assets. The words are assumed to ride along untouched. That assumption is out of date. In Inline XBRL a note or an accounting policy can carry a tag just as a figure can, and once it does, the way it is written matters in a new way.
This article looks at what tagging text involves and how to write notes and policies that survive it.
Text can carry a tag too
XBRL International defines iXBRL, or Inline XBRL, as an open standard that enables a single document to provide both human-readable and structured, machine-readable data. It explains that iXBRL takes the HTML standard used for web pages and embeds extra tags into it, giving meaning to the figures and statements in a form a computer can understand. And it states plainly that in iXBRL, text disclosures can be tagged as well as numerical figures.
In practice, a whole block of narrative can be marked as "this is the revenue recognition policy" or "this is the description of the nature of operations". Anyone extracting data can then pull every company's revenue policy from a stack of filings without opening each one.
Which disclosures may carry tags
The IFRS Foundation states that the IFRS Accounting Taxonomy reflects the presentation and disclosure requirements of IFRS Accounting Standards, including elements from implementation guidance and illustrative examples. Disclosures the standards require, such as the basis of preparation, significant accounting policies and the notes behind major line items, therefore tend to have elements waiting for them.
How far a given filing goes is a matter for the regulator that receives it. Some regimes may tag only the primary statements; others may expect notes and policies to be tagged as blocks or in finer detail. Check the rules of the register the client files with before planning the work, and expect them to change over time.
Writing notes that tag cleanly
A tag marks a block of text as one thing. Notes that mix several subjects are hard to tag and hard to read. A few habits help:
- One subject per note. A note headed "Other matters" that holds lease commitments, a surety signed by a director and a pending legal claim cannot be tagged as any of them. Split it into its parts.
- Each policy under its own heading. Inventory, revenue, property and equipment, and leases each get their own paragraph, so each can be marked as the policy it is.
- No figures buried in prose that also appear in a table. A commitment stated in a sentence and in a table may need tagging twice, and the two must agree. Prefer the table and refer to it in words.
- Stable headings from year to year. Users of tagged data compare across years, and a policy that wanders between notes is harder to follow.
Placeholders left as "[to be completed]"
In Achekam's Financials Studio, notes draw their figures from the mapped trial balance, and facts the trial balance does not hold are left as "[to be completed]". The Studio's standard policy wording is based on IFRS for SMEs and labelled for review before issue, and staff can write their own policies.
Those placeholders are a sensible safety net, but they become a hazard in a tagged document. A placeholder that survives into a tagged note turns into structured data saying, in effect, that the client's contingent liability is "[to be completed]". Before any tagging step, search the set for every placeholder and resolve each with information from the client.
Standard wording that does not fit the client is a similar trap. A full IFRS reporter carrying IFRS for SMEs policy text would end up with the wrong policy permanently attached to its name in machine-readable form.
Achekam's own iXBRL tool covers South African clients only. For Nigerian and Kenyan clients any tagging happens in another tool, but the same preparation of the text applies.
AI-drafted text reviewed before tagging
Where an AI key is set up, Achekam's AI writes narrative text such as the nature of the business and note wording. That text is checked in code and labelled "AI draft - review before issue", and the figures come from code rather than from the AI. There is no separate accept step per paragraph; the safeguards are the review stages and the partner's signature. Without a key, standard wording is used.
For tagged reporting, treat that label as a gate before tagging, not just before signing. Read each AI-drafted paragraph against the client's facts, cut what is generic, and make sure the paragraph describes one subject so that it can carry one tag. Then let the reviewer see the final wording rather than the draft.
More on writing the policies and notes themselves is in accounting policies and notes, and the basics of the format are in what Inline XBRL is.
A check before the text is tagged
XBRL International's introduction to iXBRL explains how one document carries both the readable statements and the structured data, and where regulators require it. Before tagging, confirm that:
- No "[to be completed]" placeholder remains anywhere in the set.
- Every policy is the client's own and sits under its own heading.
- Every AI-drafted paragraph has been read and edited by a person on the team.
- Notes are split so that each covers a single subject.
- Any figure that appears in narrative agrees to the tables and the primary statements.
Good notes were always worth writing. Tagged reporting simply removes the option of leaving the text loose, because the text, too, is now data.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
