Tagging a financial table from Excel: rows, dimensions and contexts

Why a table is tagged as a table

Every cell in a row shares a meaning: the row says what is measured, and sometimes which part of the business it covers. Every cell in a column shares a time and a unit. A table of twelve rows and three columns holds thirty-six numbers but only fifteen decisions. Tagging cell by cell repeats the same decision many times, with many chances to repeat it differently.

Tagging the table as a table means making each row decision once and each column decision once, and letting every cell take both. It is faster, and it is more consistent: two cells in one row cannot end up with different concepts because they were tagged on different afternoons.

Two requirements shape the work in the footnotes of a filing.

In the footnotes, each complete footnote, each significant accounting policy and each table is tagged as a block of text.

Within each footnote, each amount, whether a monetary value, a percentage or a number, is tagged separately, and each narrative disclosure may be tagged separately if the filer chooses.

The first makes the table, as a whole, a block of text that a reader can see. The second makes the amounts inside it facts in their own right, and those are the facts this guide is about. A block carries no values that anyone can compare or validate. The individual amounts do.

Prepare the table first

Most tagging problems start in the spreadsheet, before any concept is chosen. A table that is hard to read as a grid is hard to tag as one, so make the layout plain first.

• Tie the figures to the document. The spreadsheet is a working copy; the filing is what is read. If a number changed in the document, tag the number in the document.
• Keep one header row and one label column. A header split across three rows forces someone to guess which header belongs to which cell.
• Avoid merged cells that hide a period. One wide cell over two year columns is easy for a reader and ambiguous for software.
• Separate footnote markers from values. A number followed by a marker is not yet a number.
• Decide what a blank, a zero and a dash each mean. A dash usually means nil, and a blank may mean not applicable. They are different facts, or no fact at all.
• Mark the totals. Totals and subtotals are facts too, and they usually take a different concept from the rows above them.

Then read the table once, top to bottom, and write one sentence for each row and each column. If a row cannot be described in a sentence, its label is doing too much work, and its concept will be hard to choose.

Rows: the concept, then any dimension

A row’s meaning has up to two parts. The concept says what is measured, such as revenue or an operating lease liability. The dimension members, when there are any, say which slice of the whole the row covers, such as one reportable segment. Choose the concept first, and add members only when the row is a slice of something larger.

To choose the concept, start from the taxonomy the filing uses, and search by the meaning of the row, not only by its label. Labels in a table are written for readers and often shorten what the taxonomy calls the concept. When several candidates look close, the order in which to weigh them is set out by the staff.

When choosing an element, the element's references take precedence over its period type, which takes precedence over its balance, which takes precedence over its data type.

In practice, read the definition and references before trusting the label, then check that the concept’s period type suits the column: a concept defined for a point in time belongs under a date, and one defined for a span belongs under a year or a quarter. Prefer a concept from the standard taxonomy, and create an extension only after a proper search finds nothing that fits. Write down why, because a reviewer will ask.

Dimension members come second. Dimensions are how one concept is reported for many slices of the business: revenue for a segment and revenue for the whole company are the same concept, told apart by a dimension.

A fact may have any number of dimensions that the taxonomy defines, conventionally called axes, and each axis has a domain of possible values.

When a fact names no explicit member of an axis, an unstated default member may stand for all the members of that axis together.

That second point matters for total rows. A total does not carry a member that means everything; it carries no member on that axis, and the default stands for the whole. If a table lists two segments and then a total, the segment rows take members and the total row takes none.

The taxonomy specifies, for every concept, which dimensions are required, permitted or forbidden, and EDGAR validates each XBRL instance against the relevant taxonomies.

So you cannot attach any dimension to any concept. If the taxonomy does not permit the pairing, validation will fail, and the fix is to reconsider the concept, not to force the dimension. Watch for a heading that qualifies the rows beneath it: a line reading “Product line” above three indented rows usually means all three take members of a product axis, though the heading carries no number.

Columns: period and unit

A column header such as 2025 is a label, not a period. A fact needs real dates, and the dates depend on what the number measures.

• A flow, such as revenue, covers a span of time, so its column needs a start date and an end date. “Year ended December 31, 2025” runs from the first day of the fiscal year to the last.
• A balance, such as cash, describes one moment, so its column needs a single date. “As of December 31, 2025” is an instant.
• A comparative column repeats the logic for the earlier period. Take its dates from the earlier filing or the fiscal calendar, and do not assume last year began and ended on the same days.

Fiscal years that end on the last Saturday of a month move from year to year, so check the first and last column in particular. They are the ones most often copied from a template.

Every numeric fact also needs a unit. Most columns are in a currency, but counts of shares and per-share amounts have their own units, and a table may mix several. A heading that says “in thousands” gives the scale of the figure, not its unit.

Facts that share a concept, a period and the same members share one context. You do not build contexts by hand; you make sure the period and members are right, and the context follows. A common mistake is two columns meant to be different periods that resolve to the same one, because a date was copied across.

Signs and scale

Two details separate a table that looks right from one that is right. The first is the sign. A figure in parentheses reads as a negative to a person, but the fact stores a value, and whether that value is positive or negative depends on the concept.

The sign of a numeric fact is inverted when its element's balance is inconsistent with the concept being reported.

A numeric fact will occasionally have the reverse sign of the figure as conventionally shown, and a negating label is how such a figure is shown with its sign reversed.

Decide the sign by asking what the concept means, not how the cell looks. A repayment of debt printed in brackets in a cash flow statement is usually a positive amount of a concept that already means an outflow. Keep a list of the rows where the printed sign and the stored sign differ, so a reviewer can confirm them quickly.

The second detail is scale. A table headed “in thousands” prints 1,250 for a value of 1,250,000. The fact stores the full value, with a scale that tells the reader how to display it. Set the scale once for the table and check it against a total you can verify elsewhere. A scale that is off by a thousand is easy to miss, because every cell is wrong in the same way.

Check the facts it produces

A table should produce about as many facts as it has numeric cells, less any blanks you meant to leave out. A surprising count in either direction is the first sign that something is off.

1. Count the facts against the cells. Fewer facts than numbers means cells were skipped. More means a cell produced two, or a row was tagged twice.
2. Read one cell in every row and one in every column as a sentence: this concept, for this segment, over this period, in this unit, with this value. If the sentence is wrong, the row or column decision is wrong, and every cell in it needs the same correction.
3. Compare stored values with printed ones, especially at brackets, scale and rounding, where they differ on purpose.
4. Look for the same fact tagged twice. A figure that appears in a table and again in the narrative is one fact, and the values must agree.
5. Run validation, and read the findings before you read the numbers.

The same fact may be tagged in more than one place, and inconsistent numeric values, or non-numeric values that are not identical, produce XBRL errors.

Checking is not someone else’s job. A reviewer who sees only the finished page cannot see which concept sits behind a number. Hand over a list of the rows where a judgment was made, such as a concept chosen between near neighbors, a sign inverted or an extension created, and review becomes a conversation about those choices instead of a search for them.

How Disclose IQ approaches it

• Import the table from Excel as a spreadsheet, give each row its concept and any dimension members, and give each column its period and unit.
• Each cell of the table then becomes a fact, and the XBRL Tags panel lists every one.
• Run Auto-tag and the platform suggests a US GAAP concept for each untagged row of the spreadsheet. Accept, change or reject each one; nothing is tagged until a person accepts it.

General information, not legal advice. Read the current form and rules.