Two Audiences, One Document

Picture an analyst on a Monday morning at a credit-rating shop. A 250-page annual report has just landed in her inbox. She does not read it. She copies twelve numbers into a spreadsheet, fights three currency footnotes, then moves on to the next filing. Multiply her by every analyst, regulator, lender, and data vendor watching the same company, and you get the unspoken cost of paper-style reporting: a small army of humans rekeying the same numbers, each with a slightly different chance of typing 1,234 when the page said 12,340.

The CFO across town is not happy either. She wrote a careful narrative for her shareholders. She wants the report to read like prose, not a database dump. She does not want to file the same numbers twice (one beautiful PDF for humans, one cryptic XBRL bundle for machines) only to watch the two drift apart by version four of the audit.

Inline XBRL is the compromise both sides asked for. One file, served two ways. The reader opens it in a browser and sees a typeset page with serif headings and right-aligned columns. A consumer's parser opens the same file and sees XBRL facts wrapped in `ix:nonFraction` and `ix:nonNumeric` tags, each carrying a concept QName, a context reference, and (for numerics) a unit and a declared accuracy.

The atomic unit of meaning is the fact: a concept, a value, a context (entity plus period plus optional dimensions), a unit, and a decimals declaration. Everything else (presentation, calculation, labelling, language) is supporting infrastructure that helps humans navigate and helps machines reason about what they read.

The danger is precisely that one file. If the rendered text says EUR 12,450 thousand but the canonical machine value resolves to EUR 1,200, the document is a single object lying to two audiences in different ways. No validator catches that automatically. Audit-grade review treats the rendering and the tag as one fact, and reconciles them deliberately. That habit is what separates a clean filing from one that quietly poisons every dashboard downstream.

It is worth being precise about the letter that does the work, because the whole design hinges on it. The "i" in iXBRL stands for inline, and inline is the opposite of the model it replaced. Classic XBRL filed two separate artifacts: a human PDF or web page on one side, and a standalone `.xml` instance full of `<xbrli:...>` facts on the other. Two files meant two sources of truth, and two sources of truth drift apart the moment someone fixes a number in one and forgets the other. Inline XBRL collapses the two into one. The facts are not shipped beside the page; they are woven into it, embedded as `ix:` elements inside the very XHTML the reader scrolls through. The visible "12,450" and the machine-readable fact live in the same XHTML file, so they are governed together rather than maintained in separate artifacts. But they are still linked by tagging semantics, not literal byte identity: transforms, scale, sign, and hidden-fact handling can still make the machine value wrong if the tagging is wrong. The price of that guarantee is the lesson of this whole course: because the human glyphs and the machine value are now one object, a tagging mistake is no longer a cosmetic problem in a side file. It is a lie told by the document itself, to both audiences at once.

• An annual report serves a human (an investor, journalist, auditor) and a machine (a regulator's ingestion pipeline, a data vendor, a downstream analytics tool) at the same time.

• Before structured reporting, regulators received PDFs and rekeyed numbers. The error rate was non-zero and the cost was paid by everyone except the filer.

• iXBRL solves the coexistence problem by embedding machine-readable XBRL facts inside a human-readable XHTML document. The reader sees a typeset page; the machine sees tagged values.

• The unit of meaning in iXBRL is the fact: a concept, a value, a context (entity and period), a unit, and a declared accuracy. Everything else (presentation, calculation, labelling) is supporting infrastructure.

• If the human-rendered number and the machine-tagged value disagree, the filing is wrong even when no validator catches it. Audit-grade review treats the rendering and the tag as one fact, not two.

Structured reporting

A reporting regime where filed financial information is machine-readable in addition to human-readable, allowing automated ingestion, validation, and comparison.

iXBRL (Inline XBRL)

A W3C-style XML vocabulary that embeds XBRL facts inside an XHTML host document so a single file serves both human readers and machine consumers.

Fact

The atomic unit of an XBRL report: a concept reported with a value, a context (entity plus period plus optional dimensions), and (for numeric facts) a unit and declared accuracy.

<p>Total revenue was
  <ix:nonFraction name="ifrs-full:Revenue"
                   contextRef="c-2025"
                   unitRef="eur"
                   decimals="-3"
                   format="ixt:numdotdecimal">12,450</ix:nonFraction>
  thousand euro.
</p>