SEC actualiza las preguntas frecuentes sobre el proceso de informes digitales

Publicado el febrero 18, 2022

¿Sabía que la Comisión de Bolsa y Valores de los Estados Unidos (SEC) tiene un conjunto de preguntas frecuentes detalladas sobre las presentaciones XBRL, que se ha actualizado recientemente?

La Oficina de Divulgación Estructurada dentro de la División de Análisis Económico y de Riesgos de la SEC ha agregado a su página web ‘Interpretaciones del personal y preguntas frecuentes relacionadas con la divulgación interactiva de datos’, que cubre las presentaciones a su sistema de recopilación, análisis y recuperación de datos electrónicos (EDGAR) utilizando Inline XBRL. Las preguntas técnicas en profundidad abordadas por el personal abarcan la validación, la presentación y la representación, el uso de taxonomías estándar de la SEC, extensiones e instancias de la empresa, el etiquetado de detalles y la selección de elementos.

Si bien no hay una manera fácil de ver qué contenido es nuevo, toda la página es un recurso muy útil para cualquier persona involucrada en informes financieros en los Estados Unidos.

Lea más aquí.

Interpretaciones del personal y preguntas frecuentes relacionadas con la divulgación interactiva de datos

De vez en cuando, el personal de la División de Análisis Económico y de Riesgos publicará interpretaciones y preguntas frecuentes para ayudar a los solicitantes a comprender cómo cumplir con las normas interactivas de divulgación de datos de la Comisión.

Las respuestas a estas preguntas frecuentes representan las opiniones del personal de la División de Análisis Económico y de Riesgos. No son reglas, reglamentos o declaraciones de la Comisión de Bolsa y Valores. Además, la Comisión no las ha aprobado ni desaprobado.

Para obtener más información, consulte también las Interpretaciones de Cumplimiento y Divulgación de la División de Finanzas Corporativas para el Comunicado 33-9002.

Preguntas Frecuentes

A. Validación

Pregunta A.1 (Reservada)

Pregunta A.2

P: ¿Cómo valida el validador de Análisis y Recuperación de Recopilación Electrónica de Datos (EDGAR) el HTML incrustado en block text?

Un: En todos los envíos y archivos adjuntos de la SEC que no sean Ex. 101, EDGAR rechaza HTML que no se ajusta a una restricción de la definición de tipo de documento (DTD) HTML 3.2 o 4.0, en particular rechazando cualquier cosa que pueda representar una amenaza para la seguridad de un destinatario. Sobre ese principio general, el Validador EDGAR analizará el contenido de los Datos Interactivos que, cuando se procese, puede interpretarse como HTML, y lo rechazará si contiene contenido que la DTD existente rechazaría. EDGAR Filer Manual (Volumen II) secciones 6.5.15 y 6.5.16 abordan esto actualmente. Tenga en cuenta que el contenido de Block Text también debe estar bien formado eXtensible Markup Language (XML) como se describe en la sección 6.5.15. Este es un requisito más fuerte que la validación contra EDGAR HTML 3.2 o 4.0 DTD.

Pregunta A.3

P: ¿Cómo puedo saber si una advertencia o un error de mi validación de presentación de prueba está relacionado con eXtensible Business Reporting Language (XBRL) y qué habría sucedido si la presentación hubiera estado activa?

Un: Con la excepción de las presentaciones que contienen documentos XBRL en línea, se puede aceptar una presentación EDGAR con «Advertencias» incluso si algunas de sus pruebas adjuntas tienen errores. Las pruebas que tienen errores se eliminan de la presentación antes de que se acepte en EDGAR. Los archivos XBRL son exhibiciones. Por lo tanto, un mensaje de error que se parece a este «WRN: XBRL Error …» significa que los archivos XBRL se eliminarán de una presentación en vivo, pero el resto de la presentación se aceptará en EDGAR. Si esto sucede, el solicitante debe presentar una Enmienda con el XBRL corregido.

Un mensaje que se parece a este «WRN: XBRL Warning…» significa que hay un error menos grave en la exhibición XBRL, pero el archivo XBRL no se eliminará. Alentamos a los declarantes a corregir las advertencias en sus presentaciones posteriores. Un mensaje que se parece a «ERR:» o «WRN:» pero no menciona XBRL no es un problema de XBRL, y se debe a algún otro aspecto de la presentación.

Un documento XBRL en línea combina el documento HTML con elementos y atributos XBRL, y se valida sin tratar el contenido XBRL como un documento de instancia independiente. En consecuencia, si un envío tiene un archivo adjunto XBRL en línea con un error XBRL, EDGAR suspenderá todo el envío. Consulte la sección 5.2.5 del Manual del archivador EDGAR (Volumen II) para obtener más información.

B. Presentación y representación — Todas las presentaciones

Pregunta B.1

P: ¿Puedo seguir viendo las presentaciones realizadas bajo el Programa de Presentación Voluntaria?

Un: No. Los visores de datos del programa de presentación voluntaria más antiguos están separados del Visor de datos interactivo y ya no son compatibles.

Pregunta B.2 (Reservada)

Pregunta B.3

P: ¿Cómo me aseguro de que una instrucción se represente con puntos como filas en lugar de como columnas, con un eje específico como columnas, ignorando algún eje u otros arreglos?

Un: La Sección 6.24 del Manual del Archivador EDGAR (Volumen II) contiene reglas orientadas a la representación, incluidas las restricciones a la representación de declaraciones. Se permiten algunos tratamientos especiales para el Estado de Flujo de Efectivo (sección 6.24.14) y el Estado de Cambios en el Patrimonio de los Accionistas (sección 6.24.15).

Pregunta B.4

P: ¿Los estados financieros de la empresa operadora y los resúmenes de riesgo/rendimiento del folleto del fondo deben estar en Inline XBRL?

Un: Sí. Todos los períodos de introducción gradual relevantes finalizaron en septiembre de 2021. Consulte la versión No. 33-10514 y 17 CFR 232.405 (f) para obtener detalles adicionales.

Pregunta B.5 (Reservada)

Pregunta B.6

P: ¿Cómo organizo que los hechos con diferentes tipos aparezcan en la misma fila?

Un: En su mayor parte, el renderizador no puede colocar hechos de diferentes tipos en la misma fila. El motor de renderizado tiene la capacidad de renderizar diseños de datos dimensionales complejos, incluidas filas con una combinación de tipos de datos, mediante la «incrustación» de comandos de diseño de tabla en bloques de texto; esto se describe en la guía de representación de riesgos/retornos.

Pregunta B.7

P: Obtuve algunas de las bases de enlaces de etiquetas para mi envío de un sitio que usaba xml:lang=»en» en lugar de xml:lang=»en-US», ¿se renderizarán correctamente?

Un: Cualquier base de enlaces de etiquetas sin etiquetas en el lenguaje «en-US» nunca aparecería en el archivo edgartaxonomies.xml, por lo que una presentación que haga referencia a dicha base de enlaces sería rechazada por el Validador antes de la representación. Al copiar etiquetas, el archivador debe editar las etiquetas para usar en-US.

Pregunta B.8

P: ¿Por qué parte de mi representación HTML escapada es como HTML sin procesar?

Un: Asegúrese de que el HTML incrustado aparece dentro de los elementos cuyo tipo es dtr-types:textBlockItemType. No es suficiente que el nombre del elemento termine con «TextBlock». Las diferentes versiones de la taxonomía de informes financieros US GAAP (taxonomía GAAP) pueden tener convenciones de nomenclatura de elementos más o menos consistentes, pero lo importante es el tipo de elemento, no el nombre del elemento. Consulte EDGAR Filer Manual (Volumen II) sección 6.5.16 para ver ejemplos de escape correcto.

Pregunta B.9 (Reservada)

Pregunta B.10

P: ¿Qué significa que la presentación «coincida» con el documento HTML/ASCII original?

Un: EDGAR Filer Manual (Volumen II) sección 6.13 establece este requisito con mayor precisión. Las relaciones de presentación dentro de un rol dado (por ejemplo, para una declaración) deben ser las mismas que el orden original. Además, la sangría de los estados financieros en formato HTML/ASCII es mucho más «plana» que el anidamiento profundo de una taxonomía estándar típica, y la base de enlaces de presentación debe reflejar eso. Además, EDGAR Filer Manual (Volumen II) sección 6.13.4 fuerza los paréntesis fuera de los roles de declaración principales, y en roles separados específicamente para paréntesis.

Esta es la razón por la cual las bases de enlaces de presentación estándar generalmente no están en la lista de taxonomías en el sitio web de la SEC. Considere: el orden de los elementos debe coincidir con el orden del archivo HTML/ASCII original. Si se incluyera una base de enlaces de presentación estándar (para una declaración o una divulgación) en el DTS de una instancia, entonces cualquier cambio de orden (debido a una diferencia en la materialidad, por ejemplo) requeriría tanto una relación de prohibición como la nueva etiqueta. En el caso de las bases de enlaces de presentación estándar de la Taxonomía GAAP de los Estados Unidos, es probable que solo un pequeño porcentaje de esas relaciones de presentación, incluso en las declaraciones y divulgaciones más pequeñas, coincidan con el orden de los estados financieros de un declarante. El validador EDGAR permite al archivador construir el orden de presentación apropiado para la instancia y no requiere otras relaciones de presentación. Un archivador debe esperar que su base de enlaces de presentación de la empresa cambie de alguna manera con cada nueva presentación, aunque tal vez no tanto como la instancia y las etiquetas cambian.

Pregunta B.11

P: ¿Cómo hago que un bloque de texto aparezca por sí mismo en un rol de enlace de presentación como parece requerir EDGAR Filer Manual (Volumen II) sección 6.12.3? ¿Tengo que proporcionar un encabezado?

Un: La forma de satisfacer estas reglas es usar un resumen para ser el padre del bloque de texto, en cada uno de los roles separados. Por ejemplo

06100 — Divulgación — Segmentos de negocio (Nivel 1) Divulgación de segmentos [Resumen] + Divulgación de segmentos [Bloque de texto]

06101 — Divulgación — Reservas de petróleo (nivel 1) Divulgación de reservas de petróleo [Resumen] + Divulgación de reservas de petróleo [Bloque de texto]

Y así sucesivamente.

Pregunta B.12

P: ¿Deben los archivadores usar una determinada convención de nomenclatura para los títulos de los grupos de presentación?

Un: Las secciones 6.7.12, 6.24.14 y 6.24.15 del Edgar Filer Manual (Volumen II) definen estas convenciones.

Pregunta B.13

P: ¿Deben los declarantes usar una determinada convención de ordenación para los grupos de presentación?

Un: La Sección 6.24.1 del Manual del Archivador EDGAR (Volumen II) aborda los grupos de presentación, incluidas las reglas sobre el pedido.

Pregunta B.14 (Reservada)

Pregunta B.15

P: Al etiquetar un elemento de línea con múltiples descripciones de texto en el HTML original presentado en un rollo hacia adelante durante 3 años, el elemento de elemento de línea requiere tres etiquetas de negación diferentes que limitan los roles de etiqueta disponibles, ¿se sigue aplicando la sección 6.11.1 del Manual del archivador EDGAR (Volumen II)?

Un: Sí, para adaptarse a este escenario, combine el texto de los tres puntos de una manera que sea legible y no pierda ninguna información.

Presentación y representación — Resúmenes de riesgo/rendimiento

Pregunta C.1

P: ¿Existe alguna guía publicada por la SEC sobre XBRL para las presentaciones de resumen de declaraciones de riesgo?

Un: Sí. Haga clic en el siguiente enlace para encontrar la Guía de preparadores de resumen de rendimiento de riesgo de fondos mutuos: https://xbrl.sec.gov/rr/2018/rr-preparers-guide-2018-03-12.pdf

D. Taxonomías estándar

Pregunta D.1

P: ¿A qué archivos de una taxonomía estándar puede referirse un envío de datos interactivos?

Un: Los archivos de esquema o bases de enlaces incrustadas de una taxonomía que definen elementos, tipos o roles se enumeran en el sitio web de la SEC https://www.sec.gov/info/edgar/edgartaxonomies.shtml tan pronto como la taxonomía esté disponible para su uso en EDGAR.

Los archivos linkbase o linkbases incrustados de una taxonomía generalmente no se pueden usar excepto en circunstancias específicas, en cuyo caso la linkbase aparecerá en la lista. Las circunstancias específicas pueden incluir:

La base de enlaces define un formulario, como el Formulario N-1A, que exige un orden de presentación particular, y las etiquetas de los elementos no necesitan ser modificadas por el archivador;

La base de enlaces contiene relaciones de definición que no se pueden anular porque definen una tabla de datos estructurada de una manera ordenada por una Regla de la Comisión.

Los esquemas de punto de entrada (esquemas sin elementos o tipos, sino solo referencias de bases de enlace) generalmente no se permitirán, excepto cuando admitan las excepciones (a) y (b) anteriores.

Pregunta D.2 (Reservada)

Pregunta D.3 (Reservada)

Pregunta D.4

P: ¿Se aplican todas las reglas del edgar Filer Manual (Volumen II) capítulo 6 a las taxonomías estándar?

Un: No. Las reglas del capítulo 6 del Manual de EDGAR Filer se aplican a las extensiones e instancias de la empresa. Aunque las taxonomías estándar son consistentes con muchas de las reglas del Manual del Archivador edgar, aquí hay algunas excepciones:

Los nombres de archivo, los espacios de nombres, los atributos schemaLocation y xlink:href de una taxonomía estándar no están restringidos por ninguna de las reglas del Manual de EDGAR Filer.

Declaraciones de elementos: Una taxonomía estándar puede incluir elementos que no siguen la convención de nomenclatura LC3, tipos no numéricos con tipo de punto «instantáneo» u otras variaciones.

Declaraciones de rol: un linkbase xlink:role podría definirse como si se usara en un solo tipo de linkbase en lugar de los tres.

Bases de enlaces: Aunque siempre es válido con respecto a las recomendaciones de XBRL International, puede haber cualquier número de violaciones del Manual del Archivador EDGAR (Volumen II).

Pregunta D.5

P: ¿Prohíbe EDGAR Filer Manual (Volumen II) sección 6.9.3 el uso de arcos «prohibidos» porque tal arco causaría que algún arco fuera «ineficaz»?

Un: La regla solo se aplica a los arcos de la taxonomía de extensiones de empresa. Si la taxonomía de extensión de la empresa tiene un arco de «prohibición» que prohíbe un arco en una taxonomía estándar, entonces es la taxonomía estándar la que tiene el arco «ineficaz», no la extensión de la empresa. En la práctica, los arcos en una taxonomía estándar generalmente tienen prioridad = 10, lo que significa que en EDGAR no se pueden anular en absoluto.

Pregunta D.6

P: La regla 6.5.20 del Manual del Archivador de EDGAR requiere que algunos formularios contengan un elemento de información de entidad «Document Fiscal Period Focus» en el contexto requerido. ¿Qué valores deben usar los archivadores para este elemento?

Un: Los declarantes deben usar los siguientes valores:

FY — Año fiscal, utilizado para presentaciones anuales

Q1 — Primer trimestre del año fiscal, utilizado para las presentaciones del Formulario 10-Q

Q2 — Segundo trimestre del año fiscal, utilizado para las presentaciones del Formulario 10-Q

Q3 — Tercer trimestre del año fiscal, utilizado para las presentaciones del Formulario 10-Q

Pregunta D.6.1

P: Estoy preparando un FORMULARIO 10-KT por un período distinto de 12 meses (por ejemplo, del 1/1/2012 al 31/8/2012), ¿debo usar «FY» para el DocumentFiscalPeriodFocus?

Un: Sí.

Pregunta D.7

P: Estoy preparando el FORMULARIO S-4 de una empresa que también incluye XBRL para la empresa adquirente. ¿Debo incluir el elemento EntityCentralIndexKey con nuestro número CIK para la empresa adquirente?

Un: Debe proporcionar un elemento EntityCentralIndexKey en el contexto requerido y debe ser para la empresa matriz (consolidada). Tenga en cuenta que los contextos requeridos se distinguen por no tener elementos xbrli:segment (es decir, sin miembros de dimensión).

Pregunta D.8

P: Una vez que una nueva taxonomía (por ejemplo, taxonomía US GAAP) está aprobada y disponible para su uso, ¿cuándo debe un archivador hacer la transición a la nueva versión?

Un: Las actualizaciones de la Taxonomía U.S. GAAP están sujetas a cambios en las normas contables y mejoras en la taxonomía. En general, solo admitimos dos versiones de la Taxonomía U.S. GAAP a la vez. La indicación de que la taxonomía actualizada está disponible para su uso se hará a través de la página de taxonomías estándar en https://www.sec.gov/info/edgar/edgartaxonomies.shtml. El personal de la SEC recomienda encarecidamente a los declarantes que utilicen la versión más reciente de cualquier versión de taxonomía para sus envíos de datos interactivos para aprovechar las etiquetas más actualizadas relacionadas con las nuevas normas de contabilidad y otras mejoras.

Ya sea que una presentación utilice la versión del año actual o la versión del año anterior de la Taxonomía GAAP de los Estados Unidos, la versión de otras taxonomías utilizadas en la presentación debe ser compatible. En general, eso significaría el mismo año de versión que la Taxonomía GAAP de los Estados Unidos. La única excepción a esta regla de compatibilidad es el período de tiempo entre la aceptación por parte de EDGAR de la nueva Taxonomía U.S. GAAP y otras taxonomías seces para ese año, y la nueva Taxonomía de las Normas Internacionales de Información Financiera (NIIF) para ese año, debido a que la Taxonomía IFRS se acepta en EDGAR en una fecha diferente.

E. Extensiones e instancias de la empresa

Pregunta E.1

P: Los caracteres que son «especiales» están prohibidos por EDGAR Filer Manual (Volumen II) 5.2.1.2.1 y 7.3.4.33, pero aparecen en el HTML / ASCII original, entonces, ¿cómo puedo incluirlos en las etiquetas?

Un: Utilice los códigos de caracteres numéricos XML de la columna titulada Referencia de caracteres (dec) de la tabla en EDGAR Filer Manual (Volumen II) sección 5.2.2.6.

Pregunta E.2

P: ¿Qué significa que una etiqueta de elemento sea «la misma» que el documento HTML/ASCII original?

Un: EDGAR Filer Manual (Volumen II) sección 6.11.1 establece esto con mayor precisión. En términos generales, todo el contenido del documento HTML/ASCII original debe aparecer en algún lugar de los archivos adjuntos EX-101, y todo el contenido de los archivos adjuntos EX-101 debe aparecer en algún lugar del original. Las reglas adoptadas en la Versión 33-9002 no requieren una apariencia idéntica, y tampoco lo hace el Manual edgar filer (Volumen II). Lograr una correspondencia adecuada es la fuente de muchas de las reglas «semánticas» en EDGAR Filer Manual (Volumen II) Capítulo 6.

Esta es la razón por la cual las bases de enlaces de etiquetas estándar generalmente no están en la lista de taxonomías en el sitio web de la SEC. Considere: todas las etiquetas de elementos deben coincidir con la redacción exacta en el archivo HTML/ASCII original. Si se incluyera una base de enlace de etiqueta estándar en el DTS de una instancia, cualquier etiqueta que fuera diferente requeriría tanto una relación de prohibición como la nueva etiqueta. Por ejemplo, la Taxonomía U.S. GAAP contiene más de 15,000 etiquetas de elementos, sin embargo, es probable que un porcentaje muy pequeño de ellas coincida exactamente con la partida del estado financiero de un declarante. El validador EDGAR permite al archivador asignar una etiqueta a cada elemento que se utiliza en la instancia y no requiere otras etiquetas. Un archivador debe esperar que la base de enlaces de etiquetas de su empresa cambie de alguna manera con cada nueva presentación, al igual que la instancia cambiará.

Pregunta E.3

P: ¿Estoy obligado a usar roles de linkbase existentes o a crear los míos propios? ¿Pueden cambiar con cada presentación?

Un: EDGAR Filer Manual (Volume II) sección 6.7.12 explica que los archivadores deben desarrollar un esquema de ordenación y nomenclatura que sea apropiado para la organización de su documento HTML / ASCII original, al tiempo que admite una representación sensata (aunque obviamente no idéntica). Eso implica roles específicos del archivador. Cambiar los roles con frecuencia es similar a cambiar con frecuencia los elementos utilizados en la instancia: no hay una regla en contra, pero dada esa libertad para definir los roles desde el principio, una cantidad razonable de previsión debería conducir a un arreglo estable.

Pregunta E.4 (Reservada)

Pregunta E.5 (Reservada)

Pregunta E.6

P: El envío que estoy etiquetando requiere la flotación pública, entonces, ¿qué contexto debo usar?

Un: Consulte el EDGAR Filer Manual (Volumen II) sección 6.5.21 para obtener ejemplos del contexto requerido.

Pregunta E.7

P: ¿Estoy obligado a poner un valor para AmendmentDescription cuando establezco el valor en true para AmendmentFlag?

Un: Sí. EnmiendaDescripción debe ser un hecho no vacío si y sólo si la AmendmentFlag se establece en true (EFM 6.5.20)

Pregunta E.8 (Reservada)

Pregunta E.9

P: ¿Puede el contenido de un bloque de texto estar en un idioma que no sea el inglés de EE. UU. («en-US»)?

Un: Sí; sin embargo, la sección 6.5.14 del EDGAR Filer Manual (Volumen II) requiere que las instancias que contengan un hecho en un idioma que no sea el inglés de EE. UU. también deben contener un hecho utilizando el mismo elemento y todos los demás atributos con un atributo xml:lang igual a «en-US». Por ejemplo, un hecho en inglés de los Estados Unidos puede aparecer en una instancia sin el hecho francés, pero el hecho francés no puede aparecer sin el hecho en inglés de los Estados Unidos.

Pregunta E.10

P: Dado que el destino de las relaciones dimensión-predeterminado y dimensión-dominio debe ser un dominio o miembro, ¿por qué no también la relación dominio-miembro?

Un: Esa restricción no funcionaría porque la relación dominio-miembro también representa la jerarquía de elementos principales.

Pregunta E.11

P: ¿La sección 6.16.3 del Manual del archivador EDGAR (Volumen II) permite arcos efectivos predeterminados de múltiples dimensiones, siempre y cuando todos tengan el mismo origen y destino?

Un: Tenga en cuenta que la especificación XBRL Dimensions 1.0 requeriría que se señalara un error de validación si los objetivos eran diferentes, sin importar en qué rol de enlace aparecieran. Además, si los arcos duplicados tuvieran el mismo rol de enlace y prioridad, uno de ellos sería ineficaz y, por lo tanto, prohibido por EDGAR Filer Manual (Volumen II) sección 6.9.3.

Pregunta E.12 (Reservada)

Pregunta E.13

P: EDGAR Filer Manual (Volumen II) sección 6.7.10 parece redundante con la prohibición de XBRL 2.1 de declaraciones de roles duplicadas.

Un: XBRL 2.1 prohíbe las declaraciones de rol duplicadas en un archivo de esquema; EDGAR Filer Manual (Volumen II) sección 6.7.10 se aplica a todo el DTS.

Pregunta E.14

P: ¿La discusión de EDGAR Filer Manual (Volumen II) sección 6.8.1 sobre el uso de un espacio de nombres actualizado contradice la Regla 405 (c) (1) de la Regulación S-T (17 CFR §232.405 (c) (1)), que requiere que cada elemento de datos y etiqueta contenidos en el Archivo de datos interactivo reflejen la misma información en los datos correspondientes en la Presentación Oficial Relacionada?

Un: Lol El usuario del nombre local del mismo elemento en una versión posterior de un espacio de nombres no se considera «diferente» a los efectos de cumplir con la Regla 405(c)(1) de la Regulación S-T.

Pregunta E.15

P: ¿Deben etiquetarse los elementos de línea que aparecen con un guión («-«) en la versión original de HTML/ASCII con un «0»?

Un: Un archivador simplemente no puede etiquetar el elemento para los elementos de línea que aparecen como un campo vacío o un guión. Por ejemplo, si «Notas por cobrar» aparece en el balance general con un saldo de $ 1,000 este fin de año y un guión el fin de año pasado, el declarante simplemente no puede etiquetar el elemento «Notas por cobrar» para el saldo del año pasado. Tomar esta acción hará que nuestro motor de renderizado genere un campo vacío para el balance del año pasado. El renderizador no renderizará guiones. Si el archivador desea etiquetar uno o más elementos de línea que aparecen con un campo vacío o un guión con un valor cero (con un valor apropiado del atributo decimals para indicar los dígitos que faltan) porque eso es lo que la administración cree que representa el elemento, y cree que la distinción es útil, puede optar por hacerlo. Esta guía se aplica a todos los estados financieros, incluido el estado de patrimonio de los accionistas, los cronogramas de los estados financieros, así como a los datos de notas al pie etiquetados en el Nivel 4.

Para la partida Compromisos y contingencias del balance general en la que todas las columnas están en blanco o tienen guiones, el archivador debe establecer el atributo xsi:nil en true sin etiquetar el elemento con ninguna información. Esta guía se describe en EDGAR Filer Manual (Volumen II) sección 6.6.15. Al realizar esta acción, nuestro motor de renderizado representará un campo vacío debajo de todas las columnas. Una razón diferente para usar el atributo xsi:nil es que el diseño del patrimonio de los accionistas en edgar Filer Manual (Volumen II) sección 6.24.15 puede producir resultados no deseados cuando se dejan sin etiquetar demasiados valores de inicio y fin del período. Este es un caso en el que agregar hechos valorados «nulos» a menudo resolverá este dilema.

Además, un declarante puede tener una partida como Acciones preferentes en el balance general donde todas las columnas están en blanco o tienen guiones. Este podría ser el caso cuando hay acciones autorizadas, pero no se emite ninguna. Para etiquetar elementos monetarios como este, el archivador puede establecer el atributo NIL en true sin etiquetar ninguna información, similar al elemento de línea Compromisos y contingencias como se describió anteriormente. Al realizar esta acción, nuestro motor de renderizado representará un campo vacío debajo de todas las columnas. Véase también la pregunta F.4.

Pregunta E.16

P: ¿Deben los declarantes usar las estructuras de tablas y ejes predefinidos en la Taxonomía GAAP de EE. UU.?

Un: Recomendamos encarecidamente que los solicitantes utilicen las estructuras de tablas y ejes predefinidos tal como existen en la Taxonomía GAAP de EE. UU. Por lo general, se debe evitar la creación de nuevos hipercubos (tablas) y dimensiones (ejes). Las tablas y ejes personalizados tienen un impacto negativo en el análisis de la información financiera que afecta a la comparabilidad y deben evitarse siempre que sea posible. Además, los archivadores también deben evitar crear nuevos dominios o cambiar los elementos miembro predeterminados para dimensiones predefinidas.

Por ejemplo, cuando los declarantes etiquetan una nota de Propiedad, Planta y Equipo en el Nivel 4, deben copiar la Planta y Equipo de Propiedad dimensional predefinida [Tabla], y los ejes, de la base de enlaces de Taxonomía GAAP de los Estados Unidos; extender miembros o partidas solo cuando sea necesario.

Pregunta E.17

P: ¿Cuáles son algunos de los matices asociados con la preparación de un archivo de datos interactivo en situaciones que involucran a entidades separadas que presentan un solo conjunto de estados financieros, en lo que respecta a múltiples CIK, como por un declarante que es una empresa matriz consolidada con subsidiarias de propiedad total (que tienen sus propios CIK), o por compañías que cotizan en bolsa duales con sus propios CIK?

Un: Los Formularios 104.16 de la División de Interpretación de Cumplimiento y Divulgación de la Ley de Intercambio Interactivo de Datos de la División de Finanzas Corporativas explican que, en los casos de compañías que cotizan en bolsa dual, el declarante puede elegir qué CIK usar, pero debe continuar usando ese CIK en cada presentación, siempre y cuando las compañías continúen cotizando en la lista dual y presenten informes conjuntos. Aunque no se aborda en un CDI, en el caso de la empresa matriz consolidada, se debe utilizar el CIK de la empresa matriz consolidada. En cualquiera de los casos antes mencionados, ese CIK debe usarse de manera uniforme en todos los elementos «identificadores» XBRL en cada presentación, y el mismo CIK debe usarse en el elemento identificador de manera consistente en cada presentación posterior. Esta entidad se conoce como la Entidad Consolidada y es la «entidad legal predeterminada», como se describe en edgar Filer Manual (Volumen II) sección 6.6.3. Cuando los hechos sobre más de una entidad están contenidos en un solo documento de instancia, se conoce como «instancia de consolidación» (consulte edgar Filer Manual (Volumen II) sección 6.6.4). Las secciones 6.6.3 a 6.6.8 del Manual del archivador de EDGAR (Volumen II) detallan cómo modelar una instancia de consolidación, y aunque se han resumido en la tabla a continuación, los solicitantes deben consultar el Manual del archivador edgar (Volumen II) para obtener detalles completos.

Pregunta E.18

P: ¿Puedo informar de los CIK asociados a las distintas filiales a que se hace referencia en la pregunta E.17?

Un: Actualmente, los CIK de las subsidiarias no están obligados a ser reportados dentro del conjunto único de estados financieros que satisfacen las obligaciones de información de los informes como el Formulario 10-K. Debido a eso, los CIK asociados con las diversas subsidiarias no son necesarios en el respectivo dei:EntityCentralIndexKey. El sistema EDGAR permite su inclusión pero no los requiere. Por ejemplo, supongamos que la entidad consolidada tiene un CIK (hipotético) 9876543210. A continuación, todos los elementos «identificador» de la instancia deben contener 9876543210, y el valor de dei:EntityCentralIndexKey en el contexto requerido debe ser 9876543210, y el valor de dei:RegistrantName en el contexto requerido debe ser el nombre de la entidad con CIK 9876543210. Pero supongamos que otro CIK (hipotético), 8765432109, se informa en el mismo caso para la subsidiaria Abcd. En ese caso, el solicitante puede, pero no está obligado a, incluir hechos para dei:EntityCentralIndexKey y dei:RegistrantName que se encuentran en un contexto para el cual dei:LegalEntityAxis tiene el miembro AbcdMember.

Pregunta E.19

P: ¿Qué período de contexto se debe utilizar para un evento que ocurrió durante el segundo trimestre para un solicitante de registro de fin de año fiscal 12/31?

Un: Para un elemento con el tipo de punto «instantáneo», si la divulgación incluye la fecha real, use la fecha en la que ocurrió el evento. Si la divulgación menciona que el evento ocurrió en el mes de mayo, use el último día del mes, por ejemplo, 5/31. Si la divulgación solo menciona que ocurrió en el segundo trimestre, use la fecha de finalización del informe del segundo trimestre de 6/30. Para un elemento con el tipo de período «duración», si la divulgación menciona que el evento ocurrió en el mes de mayo, use el período de duración 5/1 a 5/31. Si la divulgación solo menciona que ocurrió en el segundo trimestre, entonces use el período del segundo trimestre de 4/1 a 6/30.

Pregunta E.19.1

P: ¿Qué período de contexto se debe usar para un elemento de duración cuando se especifica la fecha real (por ejemplo, «el 14 de septiembre de 2021»)?

Un: Un período de duración puede utilizar cualquier período que permita la validación de EDGAR (consulte la sección 6.5.9 del Manual del archivador de EDGAR (Volumen II)) y cuya fecha de finalización refleje la fecha especificada.

Pregunta E.20

P: EDGAR Filer Manual (Volumen II) sección 6.8.6 prohíbe el uso de información específica de la empresa o del período en los nombres de los elementos. ¿Esto se aplica a todos los tipos de artículos?

Un: EDGAR Filer Manual (Volumen II) sección 6.8.6 se aplica a elementos con tipos de elementos distintos de «domainItemType». Los elementos con otros tipos de elementos, incluidos (entre otros) los tipos de elementos monetarios, porcentuales, enteros, acciones, por acción, cadena o bloque de texto, no deben incluir información específica de la empresa o del período en el nombre del elemento. Los miembros del dominio pueden incluir información específica de la empresa o del período en el nombre del elemento.

Por ejemplo, los declarantes no deben crear un elemento monetario con el nombre «AcquisitionOfDefCo» o FourthQuarterAdjustment». Sin embargo, pueden crear un miembro de dominio con el nombre «AbcSegmentMember».

Pregunta E.21

P: ¿Cuáles son las reglas sobre el uso de tipos de unidades en una presentación de datos interactivos?

Un: Consulte la sección 6.5.35 del Manual del archivador EDGAR (Volumen II) para conocer las restricciones del registro de tipo de unidad.

Pregunta E.22

P: ¿Puede un envío de datos interactivos contener más de un archivo adjunto EX-101.* de cualquier tipo?

Un: Depende del tipo. Sólo un EX-101. INS (instancia) siempre está permitido. Sin embargo, como implica la sección 6.3.10 del Manual del Archivador edgar (Volumen II), la mayoría de las presentaciones contendrán al menos un EX-101. SCH (esquema), pero puede contener más, definiendo diferentes espacios de nombres compatibles con las secciones 6.7.4 y 6.7.5. En general puede haber cualquier número de EX-101. PRE (base de enlaces de presentación), EX-101. LAB (label linkbase), o EX-101. Archivos adjuntos DEF (definition linkbase) (EDGAR Filer Manual (Volume II) sección 6.8.2). El número total de archivos adjuntos está sujeto a cualquier límite general de archivos adjuntos impuesto por EDGARLink Online. El número de archivos adjuntos distintos se puede reducir incrustando cualquiera o todas las bases de enlaces en el EX-101. Accesorio SCH.

Pregunta E.23 (Reservada)

Pregunta E.24

P: ¿Se permiten cálculos para elementos con cantidades fuera de un «contexto requerido»?

Un: Sí, los cálculos que cumplan las reglas del Manual del archivador edgar (Volumen II) para las bases de enlaces de cálculo (consulte las reglas del Manual del archivador EDGAR (Volumen II) en las secciones 6.14 y 6.15) fuera del contexto requerido son opcionales. Tenga en cuenta que los contextos requeridos se distinguen por no tener elementos xbrli:segment (ejes y miembros de dimensión).

Pregunta E.25

P: My Form10-K incluye elementos de línea en el HTML/ASCII original que se incluyen en las reglas de cálculo del Manual del archivador EDGAR (Volumen II) en las secciones 6.14 y 6.15. Sin embargo, esos mismos elementos de línea se presentan tanto en una declaración principal como en una nota de pie de página. Además, la nota de pie de página contiene partidas adicionales que no se encuentran en la declaración principal. ¿Un único conjunto de relaciones de base de enlaces de cálculo que incluya todas las partidas requeridas en la nota al pie de página satisfará los requisitos de cálculo de EDGAR para ambos conjuntos de elementos?

Un: Sí. Cada relación de cálculo se aplica a toda la presentación. Un elemento debe ser la fuente (por ejemplo, pasivos corrientes) de una sola relación de cálculo para cualquier objetivo (por ejemplo, la parte actual de la deuda a largo plazo), sin tener en cuenta el conjunto de base (por ejemplo, balance, nota al pie de la deuda). Consulte EDGAR Filer Manual (Volumen II) sección 6.15 para obtener más detalles.

Pregunta E.26

P: Si una empresa cambia su nombre o símbolo de ticker, ¿deben cambiarse los nombres de archivo XBRL y el prefijo de espacio de nombres recomendado para que se ajusten al nuevo nombre?

Un: Sí. EDGAR Filer Manual (Volumen II) sección 6.3.3 indica que los nombres de los documentos deben comenzar con el símbolo de cotización del solicitante de registro o alguna otra abreviatura mnemotécnica y deben ser los mismos que los utilizados para la instancia en la misma presentación. Aunque no es un requisito, si una empresa cambia posteriormente los nombres o los símbolos de cotización, sugerimos que los nombres de archivo y la abreviatura mnemotécnica del prefijo de espacio de nombres recomendado se actualicen para reflejar el cambio.

Pregunta E.27

P: ¿Cuáles son las condiciones para determinar cuándo se requiere una relación de cálculo?

Un: Las normas de la Comisión exigen que los declarantes incluyan relaciones de cálculo para determinados elementos de partidas contributivas para los estados financieros y las notas a pie de página conexas. Las relaciones de cálculo requeridas en las taxonomías de empresas XBRL proporcionan información clave que muestra las relaciones entre los elementos y sus correspondientes hechos numéricos, y cómo se suman y restan entre sí. Además, las relaciones de cálculo requeridas mejoran la calidad de los datos al:

Proporcionar un contexto vital para la interpretación de extensiones de elementos personalizados;

Apoyar la continuidad de los datos de la empresa; y

Reducir el número de cantidades incorrectas.

El EDGAR Filer Manual (Volumen II), capítulo 6, secciones 6.14 y 6.15 establece requisitos específicos de relación de cálculo, incluidos ciertos ejemplos y excepciones. La sección 6.14 aborda las restricciones de sintaxis de las relaciones de cálculo. La sección 6.15 aborda el contenido de las relaciones de cálculo.

Punto 6.15.2: Determinación de cuándo se requieren relaciones de cálculo

La Sección 6.15.2 del Manual del Archivador EDGAR (Volumen II) establece:

«Si el documento HTML/ASCII original muestra dos o más elementos de línea junto con su neto o total durante o al final del período de contexto requerido, y la instancia contiene hechos numéricos correspondientes, entonces el DTS de la instancia debe tener una relación de cálculo efectiva desde el elemento total hasta cada uno de los elementos de línea contribuyentes».

Si una partida cumple las cinco condiciones siguientes, tal como se establece en la sección 6.15.2, la partida requiere una relación de cálculo:

Condición 1. En la presentación HTML/ASCII, ¿aparece la partida en los estados financieros o en las notas a pie de página? (Nota: Si la partida aparece tanto en los estados financieros como en las notas al pie, debe responder «sí» a esta pregunta).

En caso afirmativo, continúe con la condición 2.