Getting Ready to Tag Tables in PDF Documents

PDF tagging works a little bit differently from the other sources being available in the Tagger. Due to technical reasons, PDF tables cannot be detected automatically. Once you have started the Tagger and loaded the file, you will be directed to the Preview tab. The Table Tagging tab is empty. The tables in the PDF file have to be defined after opening the document.

To tag tables you need to perform the following steps:

1. Switch to the Preview tab

   Open

   

2. Select the page with the table that needs to be tagged from the dropdown menu.

   Open

   

3. Select the whole table using the mouse cursor (you can use the two little blue dots to help you with the selection of the desired area) or click on the “Automatically select table area” symbol on the top left corner. Ideally, the table is selected without the headline, but including the column headers. The table area will then become yellow. At this point, choose an abstract element from the Taxonomy and simply drag and drop it into the yellow table area. It is important to choose the first concept below the folder icon with the label containing Placeholder in English language. (The table is now marked as a whole and it acquires a blue frame, as showed in the image below).

4. Move to the Table Tagging tab where the table is now present and ready to be tagged.

5. The selected table area can be changed even after adding a table and tagging cells. Go to the Preview tab, right click on the blue border of the table and select “Edit”. All tags still within the updated selected area will be kept.

Tagging Values

Tagging a value in a table is a simple matter of drag and drop. Once the element from the XBRL taxonomy that suits a cell in the table has been identified, it can be dragged from the right part of the application onto the number that needs to be tagged.

When the cell is highlighted green, it means that the tagging was successful.

One element from the taxonomy can be mapped to different periods, as showed in the image below.

The Tagger tries to conclude the period or date for the specific tag from the value in the first row of the column. In the example above, the value -45,456 is tagged with the period from 1^st January 2018 to the 31^st December of 2018, while the value -41,766 is tagged with these dates for the year 2017.

The tagging details can be checked under the Tags and Tagging Properties tabs after clicking on a cell. The displayed values inherit their specific settings from the table; table settings default values are inherited from the document settings. Values can be changed in the Tagging Properties dialog for individual values, if needed. This tab can also be used for audit purposes: under Audit you can see last change date and time and the name of the user who made a change. Tags can be removed under Tags.

Auto Tag

After you click on the AutoTag current table button , the whole table will be checked and, if matches are found, automatically tagged. 

The following message will be displayed after the tagging is finished:

With the help of Auto Tagger Strictness and Auto Tagger Mode options, users can define how the auto tagging will be performed: whether AI should be used and whether the name comparison should be strict or not.

Two-Page Table Tagging

Sometimes tables span over two pages, with the row label names only being available on the first page:

In this case, the table cannot be tagged properly:

• RowLabelColumnId: This can be used if the row labels of a table are not the first row of a table. Simply set the column Id (0 based) of the column containing the labels.

• RowLabelTableId: Select a table from the dropdown that contains the row labels for this table. It can be used in conjunction with RowLabelColumnId if necessary.

In this case just select the table containing the labels:

When hovering over a row or looking at the cell details, the label taken from the first table will be shown:

It is also possible to tag the whole row including the first column:

Tagging of Two Tables on One Page

Some tables represent two different tables as one "physical" table (example below: assets and liabilities). Some of the Tagger's mechanisms designed to make the life easier for customers can pose a problem here, for example the automatic detection of row labels and adjacent cells.

To mitigate this situation, a new table setting has been introduced starting with Tagger version 1.5.5 called TwoInOneTableSplitColumnId.

This setting can be used to define a second RowHeader column, containing row names for the cells of the following columns, effectively splitting the table in two.

Customizing the Dimensional Hierarchy

The extension taxonomy filers usually have a dimensional hierarchy for the Statement of Changes in Equity. Usually, the Tagger infers this from the tagged elements and the default hierarchy in the ESEF taxonomy:

You will now see the hierarchy as it currently would be, based on the  dimension tags that have been set to the table. You can move them around as necessary and even add new layers by just dragging and dropping them from the taxonomy window. Once you're done, just Save the hierarchy.

It is also possible to Delete items, but only those that have been added manually and have not been tagged to an item. 

Customizing the Abstract Hierarchy

In addition to the Dimension Hierarchy Customizer, it is sometimes also necessary to change Abstract Hierarchies. If the hierarchy of a statement in your report does not resemble the one in the ESEF taxonomy, you can now rearrange the positions and levels, add additional abstracts from the taxonomy and remove abstracts that are part of the default:

Just select the hierarchy customizer for your table, select the role from which you want to copy the initial hierarchy and then drag and drop abstracts to this hierarchy. Once your are done, you drag and drop the abstract for a specific tag from this dialog onto the relevant tags, just as you did before from the taxonomy:

Rearranging the Row Order

It is important to bear in mind that the structure of statements in your company specific XBRL taxonomy extension will differ from what you have in the report. One such case is, for example, the following Statement of Changes in Equity. In the example report we can find two separate tables, one for each year. In the resulting taxonomy we will only have one combined table, with the period being selectable. In the below example we can further see that the table for 2017 has two rows more than the one for 2018. Where exactly these two rows are supposed to be placed in a combined table is up to the Filer and/or the Auditor. Per default they will just be added at the end, as shown below.

With the custom row ordering feature, this can easily be changed by you. Just click on the highlighted button and rearrange the rows to your requirements. The result in the extension taxonomy will change accordingly:

Custom Date Formats

There are countless ways to represent a date; therefore, it is challenging to support all formats automatically in the Tagger. If a date is not recognized by default, from Tagger version 1.8 a custom format description can be created for the table in question.

Click on the "table settings" icon.

Go to Date Format and click on the ellipsis symbol on the right: 

Select the desired date format, then click ok to save.

Member Tagging

Tables with several columns require both line item tags and column tags (members). 

First tag the line items. After that, mark the column to be tagged, select the element from the XBRL taxonomy and drag it from the right part of the application onto the selected column. After a successful tagging the column will be highlighted.

Members are represented by a special icon in the ESEF taxonomy and have a label [member]:

To create a new extension for the selected column, select the column and click on the button ("Add Dimension Member").

To create an extended dimension click the "Create" button first. You can either select an existing axis of the selected Hypercube or create a new one. Please note, that you can only create one new member at a time. A mix of line item member isn't possible.
If you want to create a new member but already used the Member Label you have to create a new Member Label. Just type in a new name, which can be a variant of the "old" name and click on save.

Use existing axis:
If you do not need to create a new axis, just select an existing one and add a new member. You can change the technical name if necessary. Click "Save" when you are done.

Create new axis:
To create a new axis check the "Extend" checkbox and add a label. You can change the technical name if necessary. Every axis needs one "Default" member, which will apply to all items in the table that have not explicitly been assigned a member of this particular dimension. Check the "Default" box for the member that is the default for your extended axis. Click "Save" when you are done.

Add additional labels:
After clicking "Save" you can add additional labels for multiple languages to both the axis and the member. Simply double-click the combination in the list and then click on the "Dimension" or "Member" button to add new labels.

Extensions and Anchoring

Extensions

Entity specific disclosures, which are not available in the standard taxonomy, must be reported as taxonomy extensions. 

The taxonomy extension is only allowed if the taxonomy does not contain a suitable item and if the core taxonomy element would lead to misrepresentation. A so-called "anchoring" must be used to specify the existing taxonomy positions with which the extension is semantically related.

To create a new extension for a line item, select the cell and click on the button Add XBRL Extensions to Selected Cell. The cell will be highlighted orange and a green cross appears beside the value.

It is also possible to click the button Add XBRL Extensions to All Untagged Cells: As a result all untagged cells will be highlighted orange and marked with a green cross. Please keep in mind that it can be difficult to differenciate the cells that already have an anchoring from those that are not edited yet, since they all have the same highlight colour.

Then go to the "Taxonomy Extension Properties" tab and select/add the corresponding attributes. The following attributes of the element are editable:

• Balance Type: debit, credit or unknown

• Element Name: technical name of the element (CamelCase)

• Item Type: select type (monetary, per share, string, text block etc.)

• Label of the Element: element label (is copied from the table)

• Period Type: instant, duration or unknown

• Reason for extension: You can describe the reasons, why a standard taxonomy concept cannot be used.

• Summation Element: It defines if the element is the sum of other elements, in which case no anchors are needed. If the selected element is a total, true is displayed. It changes automatically, when calculation is created.

Anchoring

The created extension needs to be linked to the core taxonomy. Extension taxonomy elements always have to be anchored to elements of the ESEF taxonomy, except for elements corresponding to subtotals (Summation Element: true). There are two options:

• an extension taxonomy element has a narrower accounting meaning or scope than an element in the core taxonomy

• an extension taxonomy element has a wider accounting meaning or scope than an element in the core taxonomy

For example, Very specific AMANA paid in capital in the table above is in the section Equity in the table, so it can be anchored to Total Equity in the ESEF taxonomy. To anchor the element, drag & drop the corresponding core taxonomy items to the Anchors area.

Additional/Multilingual Labels

If you want your extensions to have labels in different languages, not only the default language of your report, you can add labels for additional languages under Tagging Properties:

Defining Calculations in Tables

Subtotals do not have to be anchored to an ESEF taxonomy concept. You can use the Calculation tab to define subtotal elements by defining the summands of the selected cell.

To add calculation, first select the subtotal, then activate summands ("Select Summands: on"). After that select the relevant cells and click on "Add Selection". The selected line items will then be added to the calculation relationship.

When all required summands are selected, click on Select Summands button again to change it to "off" and continue with other cells. It is possible to select summands from different tables. Simply leave the "Select Summands" button "On" and change the table to add further items.

The Calculation tab also displays information to help guide the creation of proper calculation relationships. You can see the current calculated total in the upper right corner, plus the delta if the calculation does not match the value in the total. Next to the "Add Selection" button you can see information about the total: The label of row and column, the balance type and the period type. 

For more information about Sign Logic and weights please see the next section. Both settings can be changed for the items in the list right here in the calculation tab.

Please note that you cannot add calculations in the Statement of Changes in Equity table.

Calculations do have restrictions rooted in the XBRL specification, hence it is not possible to create calculations that:

• span dimensions

• contain a different period type than the total (will be highlighted red, see screenshot above)

• state a calculation like Starting Balance + Change during period = End Balance

Sign Logic (Reporting of Negative Values)

Introduction to Sign Logic

In some cases, the sign logic used in the report differs from the regulator's requirements. In general, XBRL taxonomies like the IFRS taxonomies require the reporting of positive numbers for certain item, like for "Cost of Sales" (ifrs-full:CostOfSales). If the item is presented as a negative number  on the face of a balance sheet, it might be required to invert its value in the XBRL report, but keeping it displayed as "negative". In some accounting systems (like SAP), all credit positions in the report have a negative sign, while the regulator expects those values to be reported with a positive sign.

Setting the proper Sign Logic in the Tagger is not always an easy task. Several factors add to choosing the right value. It is recommended to start off with this article from XBRL.org: Positive and Negative values in XBRL  (you need to be a member).

The main takeaway is: items may be displayed different from their value respective to the balance type. If a report displays -500 for a debit position (e.g. Cost of Sales), this usually means that the value is 500 (Cost) and just displayed with a minus to make its relation to other items in the report clearer without having to look at a tagged element's balance type. Negative cost would mean income, which for some items may be valid.

The following table explains the meaning of the balance attribute (also called BalanceType) according to their usage in different financial statements.

Furthermore, items like Profit (loss) explicitly allow negative values due to their concept meaning and the respective label. The default/positive meaning of this concept is a profit, but when a negative value is displayed it might just mean that there is a loss rather than a SignLogic error. Other examples are:

• Profit (Loss)

• Operating profit (Loss)

• Profit (Loss) before tax

• Gross Profit

• Earnings (loss)

• Earnings per share (loss)

• Gain (loss)

• Cash flows from (used in)

• Cash inflows (outflows)

• Income (expense)

• Finance income (expense)

• Increase (decrease)

Example of How Sign Logic is Used

Let's look at a concrete example:

• Financial income is tagged with: ifrs-full:FinancialIncome (Credit)

• Financial expenses is tagged with: ifrs-full:FinanceCosts (Debit)

• Net financial items is an extension with a Credit BalanceType. It could also be named Financial income (expenses)

Just looking at the table we can easily deduct that the company (in column 3) had a financial income of 394 monetary units, expenses of 1,184 monetary units leading to a total of 790 financial expenses. It is written the way it would be calculated: 394-1184=-790. Easy. It's also easy to see that there is an obvious mistake in the second column. 

If we would look at the same table in an XBRL Data view it would look like this:

It is obvious that we do have different signs in this table. While NetFinancialItems still has the minus sign, both FinancialIncome and FinanceCosts now are positive. If we look at the BalanceType property of those XBRL concepts, this makes sense again:

• FinancialIncome is Credit, translating to +394M

• FinanceCosts is Debit, translating to -1184M

• NetFinancialItems is Credit, translating to -790M

With this in mind, we can do the same calculation as above. 

The SignLogic Property

To connect the two views described above, XBRL knows a property called SignLogic. It tells the XBRL tools how to interpet the value displayed in the report. While this can in general be deducted from the concept itself, it is not something that can be completely automated. The real meaning of the displayed portion of a financial report can not be properly interpreted by just software (yet).

The XBRL Tagger offers multiple ways of tackle it by inverting the sign of an number.

When generating an iXBRL result document, it is possible to reverse the sign of values based on the balance attribute of the tagged element. For more information, see Generate Inline XBRL File.

In addition, it is possible to define a sign logic for a single cell. The sign logic applied to a selected cell is shown in the column "Sign logic" on the "Tags" tab.

The following values for SignLogic are possible:

• None: no special sign logic will be applied. The sign can be overwritten, e.g. if the setting "Reverse sign of debit position" is active while generating the report and the tagged element has a debit balance.

• As Reported: the value will always be added to the iXBRL document with the same sign as the sign in the report. Even if the setting "Reverse sign of debit position" is active while generating the report, the sign will not be changed, even if the tagged element has a debit balance.

• Reverse: the sign will be reversed. Negative values will be reported as positive values in the iXBRL document and vice versa.

• Always Positive: the value will always be reported with a positive sign.

• Always Negative: the value will always be reported with a negative sign.

Let's look again at the rows from our example above:

Calculation and Weight

The selected SignLogic is very important for the validation of calculation relationships. In our example, the calculation would look like this:

Net financial items = Financial Income - Financial Expenses

The weight attribute is automatically set depending on the balance type of the items involved and should not be changed, unless the concept has a balance type of Unknown.

If we now look at the complete picture we have the following result:

-790 * 1 (As Reported) = 394 * 1 (Always Positive) - (-1184 * -1 (Reverse)) ↔ -790 = 394 - 1184

If we perform the same calculation for the second column of our example, the calculation validation does not work out and we can again see the obvious mistake, which we might have not seen yet, but needs to be corrected.