Agency Guide – XBRL

XBRL (eXtensible Business Reporting Language) is a reporting standard to prepare and submit reports in a structured and digital format. Many regulators around the world now require companies to file reports in XBRL, ensuring information can be validated, compared, and analysed more efficiently.

In the European Union, for example, listed companies must submit their annual financial reports in the European Single Electronic Format (ESEF), which is based on XBRL.

XBRL reports are delivered as a package (typically a zip file) that contains the report itself together with supporting files needed to meet the technical requirements. These requirements must be met in order for the report to be successfully submitted to the relevant authority. The information on this page will assist in delivering this.

It is no longer mandatory to report a PDF as the legal annual report for an organisation subject to XBRL. Since the introduction of XBRL, the mandatory reporting file is an XHTML based document on which XBRL tags are applied. This change means that you now need to take a number of things into consideration as the expected document is not a PDF but an XHTML. The reason that designers of the document must account for this is that the PDF that is produced in InDesign, is converted to the XHTML format. The conversion from PDF to XHTML is not straight forward and through experience with projects, the information that will follow gives the most consistent results.

We recommend that you separate the primary financial statements from the notes that need to have TextBlock tagging applied into separate chapters. It is also prudent to separate the notes into several chapters rather than having them all as a single chapter on the server. This means that changes in the document will not have an effect on all the tags that have been done.

• When you create your XBRL report, a PDF is converted to XHTML. Converting PDF to XHTML is complicated and it’s important that you have the right settings in your InDesign documents to avoid issues.
• Most of the issues are related to OpenType features in the documents’ fonts. In InDesign you can use different variants (glyphs) of the characters. If you use two or more glyphs of a character with the same Unicode in your report the Tagger cannot distinguish between them. Only one of the glyph variants will be used in the report. This could make the report look different in the Tagger compared to the PDF.
• Ligatures and different Figure Styles are known to create issues. For example, you cannot mix different Figure Styles in the report. The Tagger will then choose one Figure Style in the report and this may cause the XHTML not to be generated correctly. The recommendation is to set the report to Default Figure Style to avoid issues.
• The fonts you are using must be Unicode compatible. Most fonts today are compatible, but older or custom fonts may not be.
• Do not use Variable fonts in your report. You need to use Static fonts to avoid conversion issues.
• Variable fonts have many different variations of a typeface to be incorporated into a single file.
• Static fonts have a separate font file for every width, weight, or style.

• We recommend creating a test document including all Paragraph Styles that are used in the document/project.
• You can then test the XHTML conversion in CtrlPrint.

Read more about exporting an XHTML version of a chapter to test the PDF conversion here.

• Ensure that OpenType features are turned off in your Paragraph Styles.
• The recommendation is to use Default Figure Style in the report.
• If you want to change the Figure Style (e.g. Tabular Lining) you need to be sure to change the setting in the whole report to avoid issues in the conversion to XHTML. If you use different Figure Styles in your report the Tagger will choose one of them and this may cause the XHTML not to be generated correctly.

Ensure that Ligatures (e.g. “fi” and “ff”) are turned off in your Paragraph Styles. Ligatures are default in InDesign and must be turned off to avoid issues.

Avoid using “Insert White Space” in your report. “White spaces” can result in issues with spacing between words and letters in the XHTML. “Nonbreaking Space” is commonly used by designers but often creates issues. The recommendation is to use “Nonbreaking Space (Fixed Width)” instead. This space is more likely to work.

When creating superscript/subscript numbers in InDesign, you avoid using InDesign’s own “Superscript” and “Subscript” options. This is because they do not result in a unique Unicode character, so their formatting will be lost and they will become a standard-sized number when using the “Force” setting in the XBRL settings. For correct superscript/subscript formatting:

• Glyphs panel: Find and insert the correct superscript/subscript numbers
  (Window -> Type & Tables -> Glyphs).

Depending on the font you are using there could be issues if you use “Small Caps”. The recommendation is to avoid it. If you need to use “Small Caps”, pay attention to how the text looks after the conversion to XHTML.

If you insert a “Section Marker” in InDesign, it’s important that you do not use “All Caps” in the “Section Marker”. If you use “All Caps” font issues can arise in the Tagger and some Lowercase characters may be replaced with Uppercase characters in the report. If you want Uppercase characters in the “Section Marker” you can use Uppercase characters in the “Numbering & Section Options/Section Marker”.

“Private-use characters” are quite unusual to use in InDesign. If you use a “Private-use character” it will not be displayed correctly in XHTML. To get information about characters, open the Glyphs panel (Type>Glyphs).

“Private-use character”: A character whose use is defined by private users and companies rather than defined by a standard such as Unicode, and which therefore has no universally accepted meaning.

In InDesign, you can highlight the “Substituted Glyphs” that may create issues in the XBRL report. Not all of the highlighted glyphs will create issues.

• To highlight Substituted Glyphs in InDesign, go to Preferences > Composition and tick the “Substituted Glyphs” box

Note: The hyphen generated during word hyphenation at line breaks is always highlighted as “Substituted Glyphs” in InDesign.

CtrlPrint Preflight is a feature providing immediate feedback and actionable guidance within InDesign, especially for XBRL-compatible designs. CtrlPrint Preflight identifies potential problems in your CtrlPrint documents directly within your InDesign workflow. This proactive approach allows you to identify and address issues early, streamlining the design process, reducing time-consuming revisions, and ensuring adherence to our XBRL Best Practices.

Read more about CtrlPrint Preflight here.

When converting and tagging a PDF report in the XBRL Tagger, some facts (tags) might become hidden. The reason for this is that the Inline XBRL Specification does not allow individually formatted numbers to be tagged. E.g. when the font requires special spacing between single characters by using HTML tags like , the number is then no longer taggable. In order to preserve the spacing and formatting of the PDF in the XHTML report, the XBRL Tagger moves the tag to an unformatted hidden section of the document and includes a link to the visual original number.

Read more about avoiding issues with Hidden Facts

CtrlPrint Frames is a layer in the Tagger that allows users to TextBlock tag the content of one or multiple threaded InDesign Stories (text frames). The intended use of these is to allow users to TextBlock tag whole notes and avoid doing it repeatedly.

This functionality is related to the InDesign text frames, and as such, their location is easier to convert to XHTML from a PDF, so this type of tagging is less likely to be affected by content changes. However, it can be affected if the layout changes drastically and new InDesign text frames are inserted in the middle of the sequence.

You should discuss how the reporting company wants their text frames threaded and their intended use for CtrlPrint Frames.

Prepare Your Documents for TextBlock Tagging with CtrlPrint Frames

The text content in a Layer in InDesign needs to be sorted in the same way the reading order is displayed on the page/spread.

InDesign is used to create a PDF which is then converted to the XHTML format when the document is opened in the CtrlPrint Tagger. The XHTML document is where the tags can be applied. Actions taken in InDesign can have consequences for how the document is converted and should therefore be avoided. The recommendations below are general and there could be other things that impact this conversion as they are discovered. It is important to note, that significant changes to the layout of the document such as adding or deleting pages, or moving content location on a page, will most likely have an impact on the TextBlock tagging in the document.

• It is important to make sure there are no overlapping text frames in the InDesign document. This will cause an issue when using the CtrlPrint Frames functionality called “Nested Continuations” and is an error that must be rectified to submit a valid report. Read more about Nested Continuations
• Make sure to use the table functionality to make proper tables rather than using tabs and custom spaces.
• Leaving blank spaces in tables where numbers should be make it harder for the XHTML to be parsed correctly so we strongly recommend using dummy numbers until the real ones have been entered into the report.
• Colour transparency on coloured objects such as a rectangle that has text in it does not translate to XHTML. This can be resolved by using the correct colour for the desired visual and then placing the coloured element behind the text.

To ensure accurate tagging, careful consideration and planning are necessary when implementing columns in landscape-oriented reports. Testing indicates that using one text frame on the page and the native functionality for columns within the frame will have more consistent results for selecting text.