1 Status

This Proposed Recommendation has been approved for publication by the XBRL Standards Board. Proposed Recommendation status indicates that the document is complete, and will move to Recommendation status if no adverse feedback is received.

2 Abstract

xBRL-CSV Table Constraints are a set of backwards-compatible extensions to xBRL-CSV that enable basic but extremely efficient validation checks.

3 Introduction

This specification defines a number of additional validation instructions that sit within xBRL-CSV metadata files, supporting efficient validation of CSV files prior to loading of an XBRL taxonomy and construction of an OIM report model.

This specification does not stipulate a processing model. The design is intended to enable streaming and parallelisation. Most checks can be performed using constant memory, operating on a single row at a time. However, processors remain free to load entire CSV files into memory, or transfer them to persistent storage, if this is convenient for implementing the checks described here or for later operations.

3.1 Documentation conventions

3.1.1 Definitions

Green text denotes a definition of the term in bold font. For example:

An example term is defined by this text.

3.1.2 Non-normative notes

Text in a blue box denotes a non-normative explanatory note:

This is non-normative commentary.

3.1.3 Error codes

QNames in parenthetical red text after a "MUST" or "MUST NOT" statement prescribe standardised error codes to be used if the preceding condition is violated. For example,

The example property MUST be defined (eg:exampleErrorCode).

"MUST" or "MUST NOT" statements that do not have a prescribed error code are not automatically enforceable, and processors are not required to detect violations.

3.2 Namespaces and namespace prefixes

Prefixes used in this specification are to be interpreted according to the following table:

The namespace URI https://xbrl.org/PR/2026-03-18/tc MUST NOT be bound to a prefix other than tc (tcme:invalidNamespacePrefix).

4 Validation

This specification defines three types of validation and two types of processor.

Validation falls into the following categories:

• Metadata validation - essential validation of Table Constraint metadata to ensure internal consistency
• Metadata linting - additional validation of Table Constraint metadata for consistency with the taxonomy
• Report validation - constraints applied to xBRL-CSV data tables

A Table Constraint report validator is a processor that takes an xBRL-CSV report as input and enforces report related constraints defined in this specification.

On encountering a document with the xBRL-CSV document type, a Table Constraint report validator MUST perform Report validation, raising tcre error codes as appropriate.

A Table Constraint metadata validator is a processor that takes an xBRL-CSV report as input and enforces metadata related constraints defined in this specification.

On encountering a document with the xBRL-CSV document type, a Table Constraint metadata validator MUST perform Metadata validation, raising tcme error codes as appropriate.

Some table constraint metadata overlaps with information present in the taxonomy, and it is important that this information is consistent.

A Table Constraint linter is a processor that checks consistency of Table Constraint metadata with the taxonomy.

This specification does not define specific checks that must be performed by a Table Constraint linter, but instead provides some non-normative, non-exhaustive recommendations for checks that could be performed by such a processor.

4.1 JSON structure

Table constraint instructions are embedded within xBRL-CSV metadata files, and subject to the same basic JSON syntax restrictions (xbrlce:invalidJSON).

This specification documents the allowed types for all values in JSON metadata. Types are specified as:

• string, array, object, number, boolean, null — these denote the specified JSON primitive type; or
• non-negative integer — this denotes a JSON number, that is a whole number with a value of zero or more.

Values in the JSON metadata MUST have the JSON type specified with the value constrained as noted above (xbrlce:invalidJSONStructure).

The JSON null value MUST NOT be used unless explicitly specified (tcme:invalidJSONStructure).

In addition, the following constraints apply to JSON metadata (tcme:invalidJSONStructure):

• properties marked as "required" MUST be present wherever the enclosing object is present;
• values in array properties declared as being a set or an ordered set MUST be unique;
• array properties declared as being non-empty MUST contain at least one value; and
• objects defined by this specification MUST NOT contain properties other than those described in the object definition.

A set is a collection of values that contains no repeated members. The ordering of the values within the set is not significant.

An ordered set is a collection of values that contains no repeated members. The order of values within the set is significant.

4.2 Table constraint properties

Table constraints are defined by the inclusion of additional properties in xBRL-CSV metadata files. The names of these additional properties are QNames using the tc reserved prefix.

xBRL-CSV metadata files MUST NOT include any tc-prefixed properties other than those defined in this specification, and the defined properties MUST NOT appear within JSON objects other than those defined in this specification (tcme:misplacedOrUnknownProperty).

4.3 Column roles

The xBRL-CSV specification explicitly defines three roles for a column:

• a fact column produces facts in the OIM model;
• a comment column contains information that does not survive into the OIM model; and
• a property group column contains references to objects that assist in the construction of facts.

This specification uses the following additional definitions:

• Any column that is not a comment column is a content column.
• A content column that is neither a fact column nor a property group column is a property column.
• A property column that supplies a value for a dimension is a dimension column.
• A column with value constraints is a constrained column.

4.4 Parameter definitions

Expected parameters can be documented by placing a tc:parameters property as an additional property of a table template object.

The value of the tc:parameters property is a parameters object.

The keys of a parameters object MUST be identifiers (xbrlce:invalidIdentifier). Each key gives the name of the expected parameter.

Each value is a value constraint object.

A parameter that has been defined using this mechanism is known as a defined parameter.

4.4.1 Column parameter conflicts

A constrained column MUST NOT have the same name as a defined parameter in the same table template (tcme:columnParameterConflict)

When processing a data table, processors MUST raise an error (tcre:columnParameterConflict) if a report parameter or table parameter has the same name as a constrained column in the corresponding table template.

4.5 Column value constraints

Constraints can be applied to all values in an xBRL-CSV column by placing a tc:constraints property in the additional properties of a column object.

The value of the tc:constraints property is a value constraint object.

4.6 Value constraints

A value constraint object specifies constraints on the values for a column or parameter. It has the following properties:

type (string)

(required) Identifies a table constraint datatype that values MUST satisfy.

optional (boolean)

(optional) Controls whether a value MAY be omitted. Defaults to false.

nillable (boolean)

(optional) Controls whether nil values are allowed. Defaults to false.

enumerationValues (array)

(optional) A non-empty set of strings specifying allowed values.

patterns (array)

(optional) A non-empty set of patterns constraining the allowed values.

timeZone (boolean)

(optional) Controls whether date values include a time zone component.

periodType (string)

(optional) Additional type restriction for values of type period

durationType (string)

(optional) Additional type restriction for values of type xs:duration

length (non-negative integer)

(optional) required length of the value.

minLength (non-negative integer)

(optional) minimal length of the value.

maxLength (non-negative integer)

(optional) maximal length of the value.

minInclusive (string)

(optional) the minimal value for the fact including the value of the property.

maxInclusive (string)

(optional) the maximal value for the fact including the value of the property.

minExclusive (string)

(optional) the minimal value for the fact excluding the value of the property.

maxExclusive (string)

(optional) the maximal value for the fact excluding the value of the property.

totalDigits (non-negative integer)

(optional) the maximum number of digits allowed for a value.

fractionDigits (non-negative integer)

(optional) the maximum number of digits after the decimal point.

The constrained column or defined parameter associated with a value constraint object is known as the constraint subject.

The enumerationValues, patterns, length, minLength, minInclusive, maxInclusive, minExclusive, maxExclusive, totalDigits and fractionDigits properties are referred to as XML Schema facet properties. XML Schema facet properties map to XML Schema facets as follows:

• enumerationValues maps to the XML Schema enumeration facet;
• patterns maps to the XML Schema pattern facet, with values in the set being treated as equivalent to multiple <pattern> elements within a <simpleType>;
• all other properties map to the XML Schema facet with the same name.

4.6.1 Application of value constraints

A value for a constrained column or defined parameter is known as a constrained value.

Value constraints are applied to:

• Any cell for a constrained column in a row in which at least one column has a value.
• Any value for a report parameter for which a defined parameter exists in any table template. Constraints from each such defined parameter are applied to the value.
• Any value for a table parameter for which a defined parameter exists in the corresponding table template definition.

Value constraints for a constrained column are applied to the effective column value of the cell. Value constraints for a defined parameter are applied to the effective parameter value.

4.6.2 Value processing

Parameter and cell values are subject to special value processing defined by the xBRL-CSV specification before constraints in this specification apply, as described in the following sections.

The term null value is used in this specification to represent the absence of a value.

4.6.3 Effective column value

The effective column value is the value of a cell in a constrained column, after applying the resolution of any applicable parameters, as described below:

• If a cell has a literal value of the empty string, #none or #nil, the effective column value is the null value;
• Otherwise, the the effective column value is the result of applying special value processing to the literal value.

A cell in an xBRL-CSV table has content if its effective column value is anything other than the null value .

4.6.4 Effective parameter value

The effective parameter value is the value obtained for a defined parameter, as described below:

• A value v is the first of the following that exists, if any:
  • A table parameter for the defined parameter in the current table template;
  • A CSV report parameter for the defined parameter; and
  • A metadata report parameter for the defined parameter.
• If no such parameter exists then the effective parameter value is the null value;
• If the parameter value is a JSON null, the effective column value is the null value;
• If the parameter value is #none or #nil, the effective column value is the null value;
• Otherwise the effective parameter value is the result of applying special value processing to value v.

4.6.5 Effective field value

The effective field value is the value obtained for a field as described below:

• If the field is a constrained column then the effective field value is the effective column value for the cell in that column in the current row;
• Otherwise the effective field value is the effective parameter value for that parameter.

4.6.6 Type validation

A table constraint datatype specifies the datatype for values in a column. A table constraint datatype MUST be one of the following (tcme:unknownType):

• an XML Schema built-in datatype, identified by a QName, apart from the types disallowed by the OIM specification;
• an xBRL-CSV core dimension, identified by a string; or
• the string decimals, indicating that the constraint subject provides a value for the decimals property.

In the first case, the QName MUST be expressed as a valid xs:QName in canonical lexical representation.

An xBRL-CSV core dimension is one of the following OIM core dimensions, identified by the specified string:

The specified table constraint datatype is used to determine an effective XML Schema lexical base type as follows:

• If the table constraint datatype is an xBRL-CSV core dimension then the effective XML Schema lexical base type is as shown in the "Effective XML Schema lexical base type" from the table above; otherwise
• If the table constraint datatype is decimals then the effective XML Schema lexical base type is xs:integer; otherwise
• The effective XML Schema lexical base type is the specified XML Schema built-in datatype.

An effective XML Schema semantic base type is determined in the same way, with the exception that the period xBRL-CSV core dimension is treated as a pair of xs:dateTime values corresponding to the start and end of the period. The effective XML Schema semantic base type is used for establishing key equality and ordering (see Section 4.8).

An effective XML Schema type is derived by restriction from the effective XML Schema lexical base type as described in Section 4.6.12.

All values for a constrained value MUST be valid against the effective XML Schema type, as defined in the XML Schema specification (tcre:invalidValue).

The decimal suffix feature defined in xBRL-CSV MUST NOT be used for columns on which a type constraint is defined (tcre:invalidValue).

Where the table constraint datatype is an xBRL-CSV core dimension, values for the constrained value MUST be valid according to the allowed representations for that dimension, as prescribed by the xBRL-CSV specification (tcre:invalidValue).

If specified, each item in the enumerationValues set MUST be a valid value for the effective XML Schema type (tcme:illegalConstraint).

    "c0090": {
        "dimensions": {
            "concept": "dict:somedate"
        }
        "tc:constraints": {
            "type": "xs:date"
        }
    },

4.6.7 Required values

If optional is set to false, then:

• if the constraint subject is a constrained column then the column MUST be present in the header row of each table based on the containing table template (tcre:missingColumn) and for each row in a table based on the containing table template that has a value in any column, the effective column value for the constrained column MUST NOT be the null value (tcre:missingValue);
• if the constraint subject is a defined parameter, then if an xBRL-CSV report includes a table for the table template in which the parameter is defined then the effective parameter value MUST NOT be the null value (tcre:missingValue).

4.6.8 Nillable values

If nillable is not set to true, the constrained value MUST NOT be a JSON null or the string #nil (tcre:invalidValue).

4.6.9 Time zone

The following XML Schema types optionally allow a time zone component; each of these is known in this specification as optionally-time-zoned schema type: xs:date, xs:time, xs:dateTime, xs:gYearMonth, xs:gMonthDay, xs:gDay.

If the timeZone property is specified, type MUST be period or an optionally-time-zoned schema type (tcme:illegalConstraint).

If timeZone is set to true, all values for the constraint subject MUST have a time zone component (tcre:missingTimeZone).

If timeZone is set to false, the values MUST NOT have a time zone component (tcre:unexpectedTimeZone).

If the timeZone property is absent, the presence or absence of a time zone component is unconstrained.

4.6.10 Period type

If the periodType property is specified, type MUST be period (tcme:illegalConstraint).

The periodType property takes one of the following values (tcme:unknownPeriodType), with noted implications for constraint subject value validation:

• year, half, quarter, week, month, day
  • The constrained value MUST be in the corresponding abbreviated format as defined in xBRL-CSV period formats (tcre:invalidPeriodType).
• instant
  • The constrained value MUST be an explicit or abbreviated xBRL-CSV period format that denotes an instant (tcre:invalidPeriodType).

"tc:constraints": {
    "type": "period"
    "periodType": "year"
}

4.6.11 Duration type

If the durationType property is specified, the type MUST be xs:duration (tcme:illegalConstraint).

The durationType property takes one of the following values (tcme:unknownDurationType):

• yearMonth
• dayTime

If durationType is yearMonth then the value MUST only contain year and month components (tcre:invalidDurationType).

If durationType is dayTime then the value MUST only contain day, hour, minute and second components (tcre:invalidDurationType).

4.6.12 XML Schema type restriction

The effective XML Schema type is an XML Schema simple type definition that is obtained from the effective XML Schema lexical base type as described in this section.

The properties of the simple type definition for the effective XML Schema type are as follows:

{name}

absent

{target namespace}

absent

{variety}

atomic

{facets}

The union of the set constraining facets defined by the XML Schema facet properties of the value constraint object and the {facets} of the effective XML Schema lexical base type.

{fundamental facets}

A set of fundamental facets as defined in XML Schema Part 2.

{base type definition}

The XML schema type definition for the effective XML Schema lexical base type.

{final}

The empty set

{annotation}

absent

Any facets specified by XML Schema facet properties MUST satisfy the relevant Schema Component Constraints specified for the facet including the Valid Restriction constraints, defined in XML Schema Part 2 (tcme:illegalConstraint).

4.6.12.1 Notes on application of XML Schema constraints

    "tc:constraints": {
        "type": "xs:string",
        "patterns": [ 
            "[a-z][a-z][a-z]",
            "[A-Z][A-Z][A-Z]" 
        ]
    }

"tc:constraints": {
    "type": "period",
    "enumerationValues": [ 
        "2021",
        "2022"
    ]
}

4.6.13 Value constraint linting

4.7 Keys

Constraints across multiple rows may be enforced by including a tc:keys property as an additional property of a table template object.

The value of the tc:keys property is a keys object. It has the following properties:

unique (array)

(optional) a non-empty array of unique key objects

reference (array)

(optional) a non-empty array of reference key objects

sortKey (string)

(optional) the name of a unique key index to be used for sorting rows in a table.

At least one of unique and reference MUST be specified (tcme:missingKeyProperty).

Each of the key objects has a name property subject to the following constraints:

• The value MUST be an identifier (xbrlce:invalidIdentifier).
• The value MUST be unique among the keys defined in the same keys object (tcme:duplicateKeyName).

Each of the key objects has a fields property subject to the following constraints (tcme:illegalKeyField):

• Each entry in the fields array MUST correspond to a constrained column or a defined parameter in the current table template.
• The type property for an entry MUST NOT be xs:double, xs:float, xs:hexBinary or xs:base64Binary.
• If the type property for an entry specifies a type to which the timeZone property is applicable (see Section 4.6.9) then the timeZone property MUST be specified.
• If the type property for an entry is xs:duration then the durationType property MUST be specified.

If sortKey is specified, the value MUST correspond to the value of the name property of a unique key object appearing in the unique property (tcme:unknownKey).

4.7.1 Unique keys

A unique key enforces uniqueness of values appearing within certain columns.

A unique key is defined by a unique key object.

It has the following properties:

name (string)

(required) Name for the unique key.

fields (array)

(required) a non-empty ordered set of strings identifying columns or parameters.

severity (string)

(optional) Specifies how a violation of the uniqueness of the key is treated. Allowed values are error and warning (tcme:unknownSeverity). Defaults to error.

shared (boolean)

(optional) Specifies whether the key may span multiple templates. Defaults to false.

Where unique key objects in different templates share the same value for the name property, all such objects MUST have the shared property set to true (tcme:duplicateKeyName).

The following constraint applies to the fields property of unique key objects:

• Fields corresponding only to defined parameters MUST come before the fields corresponding to constrained columns (tcme:illegalUniqueKeyOrder).

The key value for a row is the ordered set of effective field values for the constrained columns or defined parameters specified in the fields array in that row.

Processors MUST raise tcre:uniqueKeyViolation if the same key value appears in more than one row, across all tables constrained by the same unique key (see Section 4.7.1.2). Equality is established as described in Section 4.8.

4.7.1.1 Multiple templates with the same unique key

Where multiple templates define a unique key with the same name and the shared property is set to true, a shared unique key is defined. Uniqueness of a shared unique key is enforced across all tables for all templates sharing that unique key.

The following constraints apply to all keys comprising a shared unique key:

• all keys MUST have the same value for the severity property (tcme:inconsistentSharedKeySeverity); and
• the keys MUST have consistent fields (tcme:inconsistentSharedKeyFields).

4.7.1.2 Cross-table unique keys

Multiple tables may be constrained by the same unique key. This occurs where:

• Multiple tables use the same table template; or
• Multiple tables use table templates with a shared unique key.

4.7.2 Row sorting

Unique key enforcement can be optimised by checking that the rows in a table are sorted according to that key and, in the case that a key is used across multiple tables, the ranges for the key values are disjoint, such that the tables could be combined by concatenation into a single table that is sorted according to that key (see Section 4.7.4.1).

When the sortKey property is present in the tc:keys object for a table template definition, the rows for tables for that template MUST be sorted according to the specified key, as described in Section 4.7.3.

4.7.3 Key ordering

The sort key fields are the fields of the unique key named by the sortKey property.

To establish row ordering, each row is considered in turn. For each row, the effective field value for each of the sort key fields is compared to the corresponding value in the previous row:

• if the value is greater than that of the previous row, or this is the first row, validation proceeds to the next row; otherwise
• if the value in less than that of the previous row, tcre:sortKeyViolation is raised; otherwise
• if this is not the last of the sort key fields, comparison moves to the next field, and this process is repeated; otherwise
• tcre:sortKeyViolation is raised.

Values are compared as described in Section 4.7.4.

4.7.4 Key value comparison

Values that form part of a key value are compared according to the effective XML Schema semantic base type for the field using the XML Schema definitions of equality and, where available, ordering.

Regardless of type, a null value is considered equal to another null value (per Section 4.8), and a null value sorts before a non-null value.

Ordering is defined by XML Schema for types with an ordered fundamental facet of total (see XML Schema appendix C.1), and also for xs:duration, xs:dateTime, xs:time, xs:date, xs:gYearMonth, xs:gYear, xs:gMonthDay, xs:gDay and xs:gMonth, as the constraints in this specification requiring timeZone and durationType to be specified for key fields ensure that a total order is available.

The effective XML Schema semantic base type for the period xBRL-CSV core dimension is a pair of xs:dateTime values representing the start and end values. It is sorted according to the start value and then the end value.

Types for which an XML Schema ordering is not defined are compared as follows:

• for types of, or derived from xs:boolean, false values sort before true values.
• for types of, or derived from, xs:string, xs:QName and xs:anyURI, values are whitespace normalised according to the type's whiteSpace facet and compared lexically according to their unicode codepoints
  • this is equivalent to the XPath 3.1 expression fn:compare($cur, $prev, "http://www.w3.org/2005/xpath-functions/collation/codepoint") where $cur and $prev are the whitespace normalized string representations of the values for the current and previous rows respectively

4.7.4.1 Cross-table row sorting

In the case of cross-table unique keys (see Section 4.7.1.2), row sorting is applied across all tables for a table template.

In addition to establishing row sorting within each table, for each table A for a template constrained by a unique key there MUST NOT exist another table B for that template for which (tcre:sortKeyViolation):

• The key value for the last row of A is greater than or equal to the key value for first row of B; and
• The key value for the last row of B is greater than or equal to the key value for first row of A.

There is no constraint on the ordering of rows in tables for different templates even where there is a shared unique key.

4.7.5 Reference keys

A reference key checks the values in a column (or combination of columns) against an index corresponding to a unique key.

It is common for reference keys to refer to unique keys in a different table template (hence the database term "foreign key"), but reference keys can also refer to a unique key within the same table template (a "self-referential foreign key").

A reference key is defined by a reference key object. It has the following properties:

name (string)

(required) the name for the reference key.

fields (array)

(required) a non-empty ordered set of strings identifying columns or parameters.

referencedKeyName (string)

(required) the name of the unique key in which corresponding values are sought.

negate (boolean)

(optional) if true, the constraint is inverted so that it passes only if a match is not found in the referenced index. Defaults to false.

severity (string)

(optional) Specifies how a violation of the uniqueness of the key is treated. Allowed values are error and warning (tcme:unknownSeverity). Defaults to error.

The reference key and the unique key specified in referencedKeyName MUST have consistent fields (tcme:inconsistentReferenceKeyFields).

This key specified by referencedKeyName MUST exist as a unique key in at least one template in the xBRL-CSV effective metadata (tcme:unknownKey).

The index of values corresponding to the key specified in referencedKeyName is known as the target index. When that name is found in multiple templates, the values from all templates are combined.

The ordered set of values for the parameters and columns in fields for a given row, is known as the local key value.

Reference key validation proceeds as follows for each row in the table template in which at least one of the columns or parameters in the fields object has content (tcre:referenceKeyViolation):

• If negate is false, there MUST be a key value in the target index that is equal to the local key value.
• If negate is true, the MUST NOT be a key value in the target index that is equal to the local key value.

Equality is determined as described in Section 4.8.

4.8 Key equality

Two key values are considered equal if the values for all fields in the keys are equal, as defined below:

• If the effective field value for both key values is the null value, they are considered equal; otherwise
• If the effective field value for either key values is the null value, they are not equal; otherwise
• The effective field values for both key values are compared as described in Section 4.7.4.

4.9 Key field consistency

Keys A and B have consistent fields if:

• they have the same number of fields; and
• for each field in A, the corresponding field in B:
  • has the same type;
  • has the same value for the timeZone constraint (if specified); and
  • has the same value for the durationType constraint (if specified).

4.10 Column ordering

The order of the columns in a CSV file may be enforced by adding the tc:columnOrder property to a tableTemplate.

Definition:

tc:columnOrder (array)

(optional) An ordered set of column names.

If tc:columnOrder is defined then:

• All columns defined for the template MUST be included in the list of column names and all columns listed MUST be defined in the template (tcme:inconsistentColumnOrderDefinition);
• Tables for the template MUST include all columns in the header row (tcre:missingColumn); and
• Columns appearing in any table for the template MUST appear in the order specified by the tc:columnOrder property (tcre:invalidColumnOrder).

4.11 Table constraints

Constraints can be applied to the data tables for a table template by placing a tc:tableConstraints property in the additional properties of a table template object.

The value of the tc:tableConstraints property is a table constraint object, which has the following properties.

minTables (number)

(optional) Specifies the minimum number of data tables required for the table template.

maxTables (number)

(optional) Specifies the maximum number of data tables allowed for the table template.

minTableRows (number)

(optional) Specifies the minimum number of rows required in each data table for the table template.

maxTableRows (number)

(optional) Specifies the maximum number of rows allowed in each data table for the table template.

The value for these properties MUST be a JSON number, which MUST be a positive integer (xbrlce:invalidJSONStructure).

The number of data tables provided for the table template MUST be:

• greater than or equal to the value of minTables, if specified (tcre:minTablesViolation); and
• less than or equal to the value of maxTables, if specified (tcre:maxTablesViolation).

A fact row is a row in a data table that has a value for at least one fact column .

In each data table for the table template, the number of fact rows MUST be:

• greater than or equal to the value of tc:minTableRows, if specified (tcre:minTableRowsViolation); and
• less than or equal to the value of tc:maxTableRows, if specified (tcre:maxTableRowsViolation).

4.12 Examples

4.12.1 Keys example

{
  "documentInfo": {
    "documentType": "https://xbrl.org/2021/xbrl-csv",
    "namespaces": {
      "eg": "http://example.com/oim/tc",
      "lei": "http://standards.iso.org/iso/17442",
      "iso4217": "http://www.xbrl.org/2003/iso4217",
      "xs": "http://www.w3.org/2001/XMLSchema",
      "tc": "https://xbrl.org/PR/2026-03-18/tc"
    },
    "taxonomy": [
      "../base/customers.xsd"
    ]
  },
  "dimensions": {
    "period": "2025-01-01@end",
    "entity": "lei:legalEntityIdentifier"
  },
  "tableTemplates": {
    "naturalPersonCustomers": {
      "columns": {
        "customer_id": {
          "tc:constraints": {
            "type": "xs:integer"
          }
        },
        "name": {
          "dimensions": {
            "concept": "eg:Name"
          }
        },
        "birthDate": {
          "dimensions": {
            "concept": "eg:birthDate"
          }
        },
        "salesSizeGroup": {
          "dimensions": {
            "concept": "eg:salesSizeGroup"
          },
          "tc:constraints": {
            "type": "xs:QName",
            "enumerationValues": [
              "eg:Small",
              "eg:Medium",
              "eg:Large"
            ]
          }
        }
      },
      "dimensions": {
        "eg:customerID": "$customer_id"
      },
      "tc:keys": {
        "unique": [
          {
            "name": "customerPK",
            "fields": [
              "customer_id"
            ],
            "shared": true
          }
        ]
      }
    },
    "legalEntityCustomers": {
      "columns": {
        "customer_id": {
          "tc:constraints": {
            "type": "xs:integer"
          }
        },
        "name": {
          "dimensions": {
            "concept": "eg:Name"
          }
        },
        "incorporationDate": {
          "dimensions": {
            "concept": "eg:incorporationDate"
          }
        },
        "countryCodeVAT": {
          "dimensions": {
            "concept": "eg:countryCode"
          },
          "tc:constraints": {
            "type": "xs:string",
            "optional": true
          }
        },
        "salesSizeGroup": {
          "dimensions": {
            "concept": "eg:salesSizeGroup"
          },
          "tc:constraints": {
            "type": "xs:QName",
            "enumerationValues": [
              "eg:Small",
              "eg:Medium",
              "eg:Large"
            ]
          }
        }
      },
      "dimensions": {
        "eg:customerID": "$customer_id"
      },
      "tc:keys": {
        "unique": [
          {
            "name": "customerPK",
            "fields": [
              "customer_id"
            ],
            "shared": true
          }
        ],
        "reference": [
          {
            "name": "LegalEntityCountryToCountriesFK",
            "fields": [
              "countryCodeVAT"
            ],
            "referencedKeyName": "countriesUK"
          }
        ]
      }
    },
    "countries": {
      "columns": {
        "country_id": {
          "tc:constraints": {
            "type": "xs:integer"
          }
        },
        "countryCode": {
          "dimensions": {
            "concept": "eg:countryCode"
          },
          "tc:constraints": {
            "type": "xs:string"
          }
        },
        "VATrules": {
          "dimensions": {
            "concept": "eg:VATrules"
          }
        }
      },
      "dimensions": {
        "eg:countryID": "$country_id"
      },
      "tc:keys": {
        "unique": [
          {
            "name": "countriesPK",
            "fields": [
              "country_id"
            ]
          },
          {
            "name": "countriesUK",
            "fields": [
              "countryCode"
            ]
          }
        ]
      }
    }
  },
  "tables": {
    "natural_persons_data": {
      "template": "naturalPersonCustomers",
      "url": "../base/natural-person-data.csv"
    },
    "legal_entity_data": {
      "template": "legalEntityCustomers",
      "url": "../base/legal-entity-data.csv"
    },
    "country_data": {
      "template": "countries",
      "url": "../base/country-data.csv"
    }
  }
}

4.12.2 Parameter example

{
  "documentInfo": {
    "documentType": "https://xbrl.org/2021/xbrl-csv",
    "namespaces": {
      "eg": "http://example.com/oim/tc",
      "lei": "http://standards.iso.org/iso/17442",
      "iso4217": "http://www.xbrl.org/2003/iso4217",
      "xs": "http://www.w3.org/2001/XMLSchema",
      "tc": "https://xbrl.org/PR/2026-03-18/tc"
    },
    "taxonomy": [
      "../base/sales.xsd"
    ]
  },
  "dimensions": {
    "entity": "lei:legalEntityIdentifier"
  },
  "tableTemplates": {
    "sales": {
      "columns": {
        "product_id": {
          "tc:constraints": {
            "type": "xs:token",
            "nillable": false
          }
        },
        "sales": {
          "dimensions": {
            "concept": "eg:Sales",
            "period": "$calendar_month",
            "unit": "iso4217:EUR",
            "eg:ProductId": "$product_id"
          }
        }
      },
      "tc:parameters": {
        "calendar_month": {
          "type": "period",
          "periodType": "month",
          "timeZone": false
        }
      },
      "tc:keys": {
        "unique": [
          {
            "name": "sales_pk",
            "fields": [
              "calendar_month",
              "product_id"
            ]
          }
        ]
      }
    }
  },
  "tables": {
    "salesJan24": {
      "url": "../base/salesJan24.csv",
      "template": "sales",
      "parameters": {
        "calendar_month": "2024-01"
      }
    },
    "salesFeb24": {
      "url": "../base/salesFeb24.csv",
      "template": "sales",
      "parameters": {
        "calendar_month": "2024-02"
      }
    },
    "salesMar24": {
      "url": "../base/salesMar24.csv",
      "template": "sales",
      "parameters": {
        "calendar_month": "2024-03"
      }
    }
  }
}

Appendix A Intellectual property status (non-normative)

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (https://www.xbrl.org/legal).

This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (https://www.xbrl.org/legal).