Export files in XBRL

What is XBRL/iXBRL?


In many jurisdictions, the local authorities expect their companies to file certain data regularly. The requested data can range from information about taxation to data about financial performance or compliance. To facilitate and standardise this data transmission, these authorities often work with XBRL.

XBRL stands for eXtensible Business Reporting Language and is a framework for exchanging business information. It allows communications between different parties to be defined by metadata that is set out in taxonomies (using special and pre-defined tags).

Next to that, there is also something called iXBRL (inline XBRL), an open standard that enables a single document to provide human-readable and structured, machine-readable data. Inline XBRL allows you to incorporate your XBRL tags into your HTML-formatted financial statements, rather than filing a separate XBRL instance document. This keeps the human-readable HTML format of the financial statements the same when viewed in a web browser while adding the XBRL tagging to those statements.

Process flow

A couple of steps are needed before an (i)XBRL export can be taken and filed. Each step is required in the process to be able to successfully export the data:

  • Taxonomy upload
  • Export file preparation
  • XBRL file generation and validation

1. Taxonomy upload


In Silverfin, XBRL files are generated via the s(mart)XBRL engine. As soon as a new taxonomy is released, our backend engineers process the available .xsd file and store it in the Silverfin platform. As soon as it has been added to the engine, a valid (i)XBRL file can be generated for that specific taxonomy.
Note that it can always happen that a certain taxonomy has not yet been uploaded to the system. If this is the case, please send an email to [email protected], provide them with the correct .xsd file and ask them to upload it to the sXBRL-engine before starting working on (i)XBRL.

2. Export file preparation


Creating an export file


Once the taxonomy is released and uploaded in Silverfin, an export file can be created. Both a name and a file name will be required.
  • The chosen ‘Name’ will be shown as the name of the export file on company level, so make sure the name is descriptive enough for the user to understand.
  • The file name is how the export file will be called eventually. It is here that the users can add the required extension for their files.
    • XBRL does require the .sxbrl extension and will result in an XBRL file being generated.
    • For iXBRL, the extension .html.sxbrl is needed. The resulting file will be an HTML file (and thus not an XBRL file).
    In the file name, it is possible to include liquid logic. This ranges from results and custom variables to reference company and period-specific information such as company name, period dates, etc. These can come in handy to make each XBRL export unique for a certain company.
  • Lastly, there is also the option to change the encoding type of the file.
    • The default (UTF-8) is a multibyte encoding that can represent any Unicode character. This option will have to be selected if you do have a lot of foreign language materials.
    • ISO 8859-1, on the other hand, is a single-byte encoding that can represent the first 256 Unicode characters.

    The default version supports more characters and language-specific characters and is in most cases the preferred option.

Example:

18841884

Code structure


❗️

Export files have a strict code structure. Deviating from the structure will break the XBRL file that is being generated.


The structure can be divided into three different layers, each with its own function.


Top layer (XML tagging and XBRL context)

The first few rows of an export file are always used to make a reference to the file type (which will normally be XML) and to the taxonomy file (.xsd format).


XBRL

421421

iXBRL

860860

Next, we have the code that is used to define the XBRL context. The attributes that are defined in this section will apply to the entire XBRL code that follows (unless it is overwritten somewhere).
These attributes are taxonomy specific and can contain information about:

  • Decimals
  • Start/end dates
  • Currency
  • Entity identifier
  • Date formatting
  • Remove blanks/zeros

Example BE Taxonomy:
22982298

Middle layer (iXBRL - HTML & CSS) - Optional

Note that this layer is not required for simple XBRL files, but if we would want to make the XBRL document human-readable, an additional HTML/CSS layer needs to be added to the XBRL file. This can be done by embedding the CSS styling in the iXBRL document directly (Embedded CSS).

The HTML file will only be styled if the CSS file is declared directly in the document. External references to a CSS file are not supported, so using them won’t style the export file at all. Next to that, it is also important to mention that script tags inside the CSS code are not allowed either. The big advantage of all this, is that the HTML file will load much faster because we do not have to make requests to external files.

Example CSS:

918918
This can be included in the export file in two ways:
  • By adding the CSS code to a different part, and including it in the file.
  • By nesting the code directly inside the head tag.

Example of using a different part:
12221222

Bottom layer (XBRL tags and Liquid code)

The largest part of the export file code will be in the bottom layer, which consists of both tags and dimensions. Every value in the XBRL file is represented by a unique combination of a tag, a dimension, and some tag properties. These tags and dimensions are always stored in a JSON file of a taxonomy package, they can be hidden or visible, and they are always tagged as absolute values.

CostSales
    ContinuingDiscontinuedOperationsDimension="ContinuingOperations" startDate="2020-12-31" endDate="2021-12-31"

Properties on the other hand can be general (think of schema, decimals, scale, date, monetary unit...) or data type specific (monetary, string, decimal, shares, date, boolean...).


sXBRL-engine

As explained before, Silverfin is using the sXBRL-engine for XBRL files. Without this engine, every possible XBRL tag would need to be coded literally (including all the attributes).


Without sXBRL engine:

<pfs:SomeTagExample>
 <pfs:SomeTagExampleTitle contextRef="CurrentDuration">
   Some title
 </pfs:SomeTagExampleTitle>
 <pfs:SomeTagExampleValue decimals="INF" contextRef="CurrentDuration" unitRef="U-EUR">
   200
 </pfs:SomeTagExampleValue>
</pfs:SomeTagExample>

With sXBRL engine:

SomeTagExample 
    SomeTagExampleTitle Some title
    SomeTagExampleValue 200

The engine will identify and create the correct attributes for each tag in the background, so by using the correct name of the tag, it will be populated in the correct way.

Hence also the reason we need to upload the taxonomy to our XBRL engine: if a new tag is used in the new taxonomy, and we refer to it in our export while the taxonomy isn’t uploaded yet in our engine, the export would not know how to create the tag, and it would lead to an XBRL error.

❗️

Indentation is of utmost importance when using tags, if proper indentation is not respected, it will break the XBRL file.

More information about indenting can be found in this section.


Liquid code

As illustrated in some of the examples above, an XBRL file is written as a combination of XBRL tags and liquid. In the most straightforward example, one XBRL tag would be linked to one specific field in a template. In the export file, we can generate that result by using result tags (more information on result tags here).

EntityInformation
  EntityAddress
    Street {{ period.reconciliations.company_information.results.company_street }}

Of course, also for the dimensions and other attributes linked to an XBRL tag, liquid coding can be used. In the example below (containing XBRL context definition), attributes like startDate, endDate and entityIdentifier are all populated via liquid logic.

s-xbrl-context decimals="2" startDate="{{ period.year_start_date }}" 
endDate="{{ period.year_end_date }}" 
unit="iso4217:EUR" 
entityIdentifier="{{ period.reconciliations.company_information.results.company_identifiervalue }}" 
entityScheme="http://www.fgov.be" instantDate="{{ period.minus_1y.year_end_date }}" 
removeIfZero="true" removeIfBlank="true"

General guidelines on tagging

  • Each data element should have a unique XBRL presentation (tagged in a unique way). If there are several data elements that fall under the same category (pure tag), dimensions should be used in the format: TagDimension=“DimensionValueAsPerJSON”. XBRL tags and dimensions that need to be used will depend on the schema that you will be working with.

  • There can be as many dimensions as needed to uniquely tag a data element. Refer to the taxonomy to check available dimensions and the values applicable to a tag.



    • Sales - TurnoverRevenue DetailedAnalysisDimension="Item1"
    • European sales - TurnoverRevenue CountriesDimension="RestEuropeOutsideUK" DetailedAnalysisDimension="Item2"
    • Rest of world sales - TurnoverRevenue CountriesDimension="RestWorldOutsideUK" DetailedAnalysisDimension="Item3"

    Note that the same combination of tag and dimension will be used per line item in the example above. However, their period type (startDate="{{ period.year_start_date }}" endDate="{{ period.year_end_date }}" for the 2019 value and startDate="{{ period.minus_1y.year_start_date }}" endDate="{{ period.minus_1y.year_end_date }}" for the 2018 value will be different, which will make the tagging unique and valid.

  • Some tags are mandatory to be present in the XBRL file filed to financial authorities. However sometimes, they are not to be displayed in export itself. In that case, hidden tags can be used. These tags should be implemented at the top of the file before the code of the visible tags is being rendered. The full list of mandatory tags should be found in taxonomy specification.

  • Hidden tags follow under s-xbrl-context hidden="true" CSS style element, while visible information follows under s-xbrl-context CSS style element.

    Example of hidden tags:




  • Indentation is important for correct rendering of CSS and tags, and mapping to the schema.
    • Indent by 2 spaces/tab at a time. Do not mix tabs and spaces for indentation.
    • Use a new line for every block, list, or table element, and indent every such child element.
    • Tags should always start on a new line and its content/child elements should be indented where applicable.




  • The sXBRL engine will always try to convert the first item in a row into a tag. If you want to include the content in the export and there is no tag in the current row, you should include a pipe | at the very beginning
  • Sometimes, strings can start with non-alphanumeric characters. To correctly render and display it, use |* ... *| around it.
  • In iXBRL export file, use newline_to_br to display a string that takes multiple lines in export. This will replace every newline (\n) in a string with an HTML line break.

Examples


1) Monetary value tagging (iXBRL) - UK

{% comment %}Table{% endcomment %}

table
  {% assign value = 335 %}
  tr
    td Cash and Cash Equivalents
    td
      |{% if value < 0 %}({% endif %}
      CashBankOnHand instantDate="{{ period.year_end_date }}" {% if value < 0 %}sign="-"{% endif %} {{ ABS(value) | integer }}
      |{% if value < 0 %}){% endif %}
  • Notice the usage of HTML syntax (table, tr, td)
  • Only absolute values are being tagged (the variable value can be negative, hence the ABS() ).
  • There is a check to see if the value is smaller than zero. If this is the case, brackets will be added for display purposes.
  • For system to recognise the sign of the value property sign="-" is added. CashBankOnHand has an expected "debit" balance. If the value of cash is positive, no sign="-" property should be added to the tag, if the cash is negative, sign="-" property should be added to the tag.
  • "date" property should be added. CashBankOnHand is an instant tag (as opposed to a tag with an end and start date), therefore, the instantDate property is added.
  • In the default decimalFormat="numdotdecimal" property, zeros cannot be shown as dashes "-" in iXBRL. Therefore, either integer filter should be used for the value, or {% currencyconfiguration %} tag with “negative_format” set to "0".
  • Notice the usage of |. Without it, these two rows would be displayed as a string in the export file.

2) Tax and tax exempt reserves (XBRL) - BE Corporate Tax

26222622
24822482
  • As this is XBRL, there is not HTML syntax present in this piece of code.
  • In the XBRL tag TaxableProvisions two values need to be included: one for the previous year and one for the current year
  • In the context, instantDate was already defined as {{ period.year_end_date }}, which is applicable to the whole document.
  • We have to specifically overwrite this context definition to be able to tag the Taxable provisions of the previous year. This is being done in row 108.
  • For the current year, we can again refer to the instantDate in the context, so there is no need to redefine it.
  • The values are fetched by calling results from another template, so they are not hard-coded.

3) Equity and liabilities note (iXBRL) - DK

15861586
  • This is an example of iXBRL, so there is HTML code present in the code
  • We are using pre-defined CSS classes to style the document (e.g. note-column, width1...). These were defined separately in the document.
  • On line 3257, we are using |, because we do not want to print this line. Instead, the locale will convert the value to the correct local formatting.
  • As in the first example, we are checking again if the value is negative to add a “-” sign for visual formatting.
  • There is logic to see if we need to show the previous year (see row 3260).
  • If a previous year needs to be shown, we repeat the logic for the current year, with the addition of {{ preceding_per }}. This will again overwrite the instantDate definition in the context.

3. XBRL file generation and validation


Once an export file is added and populated on firm level, XBRL files can be downloaded from Silverfin on company level. The user can select the applicable XBRL/iXBRL file they want to download, and the process to generate the export will start.

First, all the logic defined in liquid will be executed, populating the information needed, by taking it from other templates. Later, the sXBRL engine will parse this export file to generate the tags needed (XBRL and HTML elements if applicable). XBRL tags are generated using the schema created from the taxonomy .xsd files. Lastly, the generated tags are then populated with the correct and pre-defined values.

The resulting file will be in .xbrl or .html format and should be final. However, to be completely sure that the syntax of the file is correct, it is best practice to check the file with an external XBRL file validator. These validators will not check the content but will confirm if the tagging is being done in the correct way. Once all this is done without any issues, the file can be uploaded directly to the specific filing platform.

📘

For some markets, it is possible to file your (i)XBRL directly with Silverfin to the correct instances.