XBRL and iXBRL: why regulators no longer accept anything else
Ilustración de red de datos conectados sobre fondo azul con el título XBRL e iXBRL: el idioma del regulador

For decades, a financial statement was a document. It was prepared in a spreadsheet, laid out in a PDF and sent to the regulator, who read it like any other reader: with their eyes. That model has run its course. Today, supervisory bodies in Latin America receive thousands of reports per period and need to compare, validate and analyze them automatically. That is what XBRL is for.

What XBRL is, in practical terms

XBRL (eXtensible Business Reporting Language) is an open standard that tags every figure in a financial report with its meaning. The figure 1,250,000 stops being a loose number in a cell and becomes "cash and cash equivalents, consolidated, as of December 31, in pesos, according to the IFRS taxonomy." That tag travels with the data.

The consequence is enormous: the regulator no longer interprets, it reads. It can cross-check the figure against the previous period, against another entity in the same sector and against the consistency rules of the standard itself. All without human intervention.

So, what is iXBRL?

iXBRL (Inline XBRL) solves the weak point of the original format: a pure XBRL file is perfectly readable by a machine and unreadable for a person. Inline XBRL embeds the tags inside an HTML document, so the same file serves both audiences.

  • A single deliverable. Double preparation comes to an end —the "nice" PDF on one side and the technical XBRL on the other— and with it the risk that the two do not match.
  • Visual traceability. The reviewer sees the report exactly as it is published and, at the same time, can inspect the tag behind every figure.
  • Fewer observations. By eliminating manual reconciliation between versions, one of the most frequent causes of rejection disappears.

Where the process breaks

In our experience supporting implementations in regulated markets across the region, reports rarely fail because of the figure itself. They fail because of the path that figure travels:

  • A poorly chosen taxonomy element, semantically similar but different from a regulatory standpoint.
  • Incorrectly declared contexts and units: periods that do not close, inconsistent currencies, mixed scales.
  • Extensions created for convenience when an applicable standard element already existed.
  • Taxonomy updates that arrive in the middle of a closing cycle and that no one propagates to the templates.

The error does not show up at submission. It shows up weeks earlier, at the moment someone decides which tag a figure gets.

What a mature XBRL process does

A solid reporting operation does not depend on the team remembering the rules. It builds them into the process: taxonomies that update themselves, real-time technical and semantic validation during preparation, direct submission to the regulator and full traceability that makes it possible to reconstruct, months later, where each piece of data came from and who approved it.

That is the leap: moving from reviewing the report at the end to building it right from the source. At BPENNOVA we have spent more than fifteen years supporting that shift at banks, insurers and issuers across the region. Let's talk about your reporting cycle.

Recent Articles