XBRL GL

Ha habido bastante debate sobre el formato de los archivos. Sin embargo, las diferencias en los planes de cuentas entre países representan un problema de compatibilidad mucho mayor en el intercambio de información contable y financiera entre distintas culturas contables. Las regulaciones fiscales también generan grandes diferencias en el contenido de la información contable y financiera entre países.

La cuestión fundamental es si es posible transferir datos contables a través de fronteras gubernamentales y si el receptor podrá comprenderlos. ¿Podrá alguien leer y entender un balance con un plan de cuentas extranjero? ¿Habrá alguna diferencia al transferirlo mediante archivos informáticos en formatos estandarizados?

La Comisión Europea ha dedicado grandes esfuerzos a la armonización de la administración tributaria y, por ejemplo, la última versión de la Directiva del IVA tiene como principal objetivo lograrlo y facilitar el uso de documentos comerciales electrónicos, como las facturas electrónicas, en el comercio transfronterizo, especialmente dentro del Espacio Económico Europeo (EIE) . Sin embargo, aún queda mucho camino por recorrer para lograr planes de cuentas verdaderamente compatibles y un intercambio internacional de información contable efectivo.

Una pregunta clave es si los acuerdos comerciales internacionales tienen mucho valor sin una armonización global de la legislación administrativa del IVA entre las partes firmantes. Los acuerdos de la UE con países como Noruega no incluyen la adhesión a la unión del IVA. Por consiguiente, las mercancías se quedan retenidas en aduanas (con los consiguientes costes) para la declaración del IVA, lo que requiere un gran esfuerzo administrativo. Este trabajo y estas demoras no se producen dentro de la unión del IVA de la UE. Con la armonización administrativa global de la legislación del IVA, se abren muchas posibilidades.

Otro problema son las regulaciones de contratación pública de la UE en exigencias de especificaciones de organizaciones de normalización , de reconocimiento de los esfuerzos del mercado privado de muchas iniciativas que se han hecho hasta ahora. En realidad, impide que la administración gubernamental participe, contribuya y utilice el trabajo que se ha hecho hasta ahora. UN/CEFACT es una organización oficial de normalización de la ONU , pero UN/CEFACT tiene grandes problemas para finalizar su proyecto y pocos, si acaso alguno, entienden la idea general de cómo aplicar la contabilidad UN/CEFACT, UN/CEFACT (EDIFICAS) cuando se le pregunta no puede/no quiere decir. Este es uno de los principales problemas para que las autoridades fiscales hagan exigencias/presten servicios a las empresas en el intercambio electrónico de datos. (Cabe preguntarse cuánto tiempo podrá el mundo permitirse la contratación pública moderna?) Sin embargo, XBRL busca el reconocimiento como organización de normalización .

XBRL presenta un problema general: está diseñado para usuarios receptores de información, como auditores y analistas, y no parece haber argumentos lo suficientemente convincentes para que los productores de información (las empresas que realizan la contabilidad) paguen por las funciones de generación de archivos XBRL GL en el software comercial . Sin el apoyo de los productores de información, no habrá datos para los analistas y auditores en formato XBRL GL, y por lo tanto, tampoco habrá mercado para el software comercial que los utilice.

La contabilidad es originalmente un trabajo manual, y parte de ella se ha informatizado mediante software comercial . Sin embargo, un aspecto comercial de la contabilidad reside en sus límites y en las funcionalidades que deberían incluirse en los paquetes de software comercial .

El trabajo contable consiste en elaborar comprobantes contables con sus respectivas entradas y verificar que sean correctas. Las principales herramientas de verificación son los extractos bancarios y los registros de caja, para demostrar que cada transacción monetaria se contabiliza correctamente. Sin embargo, esta verificación es en gran medida manual y requiere mucho trabajo; los ordenadores la realizan mucho mejor. En segundo lugar, se demuestra que existen pruebas de las transacciones mediante la documentación de los comprobantes. Estos comprobantes son facturas (y recibos) de entrada y salida, que en la práctica constituyen una carpeta física. (Aun así, la directiva del IVA de la UE y la legislación del IVA de muchos países exigen mantener carpetas físicas de comprobantes, lo que dificulta el trabajo con comprobantes escaneados. Esto a pesar de que la Comisión Europea tiene una visión de comprobantes electrónicos. La misma legislación genera problemas con las facturas electrónicas y su integración con la contabilidad. Por lo tanto, aún queda mucho por resolver).

Otra forma de verlo son las exigencias legales, y el 95% de todas las exigencias legales en materia de contabilidad provienen de la legislación del IVA, donde la Directiva del IVA de la UE ( Impuesto sobre el Valor Añadido de la Unión Europea ) es la documentación más completa. Desde esta perspectiva, es evidente que las facturas y los recibos son, ante todo, documentos contables (exigidos por la legislación del IVA), en segundo lugar, documentos de derecho civil y, en tercer lugar, documentos comerciales generales. La documentación contable exigida por la legislación del IVA constituye la principal normativa que regula todos los requisitos contables.

Para que el productor de datos obtenga beneficios, es muy probable que en este ámbito las funciones de integración y atomización sean un factor que justifique el pago por parte del cliente de software comercial que genera archivos de información contable (como XBRL GL SIE y UN/CEFACT). Para ello, las facturas (con cuentas por pagar y cuentas por cobrar ) y los extractos bancarios podrían considerarse documentos contables e incluirse en un formato de archivo estándar. Ninguno de los formatos de archivo actuales lo permite, pero abriría el mercado a software de automatización de terceros que utiliza inteligencia artificial.

La falta de integración contable es también la razón más probable por la que los formatos de factura electrónica aún tienen una penetración de mercado muy baja y el progreso es lento. Esto se debe principalmente a que los formatos de factura electrónica no están diseñados en primer lugar para cumplir con las exigencias de la legislación contable y del IVA, sino desde la perspectiva de documentos comerciales no regulados.

Resulta interesante que no existan formatos de archivo estándar para los extractos bancarios y que, según el grupo bancario TBG5 de la ONU/CEFACT, su existencia no redunda en beneficio de los bancos, sino de la contabilidad, para posibilitar la conciliación automática. Sin embargo, un formato de archivo estándar internacional para los extractos bancarios aportaría grandes ventajas al desarrollo de páginas de banca online con nuevas funcionalidades que beneficiarían a los clientes. Especialmente si se incluyera la integración con un formato de factura (recibo) estándar.

XBRL GL carece además de un conjunto de instrucciones de uso adicionales, y su formato de archivo no es lo suficientemente preciso ni claro, lo que genera mucha incertidumbre sobre su uso. Es difícil que un lector comprenda realmente qué representan los datos contenidos en un archivo XBRL GL externo.

La situación es como ponerse de acuerdo sobre el uso de un alfabeto común sin ponerse de acuerdo sobre para qué idioma usarlo. Si alguien envía una carta en portugués con caracteres latinos a un holandés, a menudo el holandés no entiende portugués, aunque pueda leer caracteres latinos. Tenemos el mismo problema aquí. Y sin una solución general, se deben establecer acuerdos entre cada usuario, tanto de escritura como de lectura, y esa no es una solución sencilla para lograr un gran volumen de ventas y un mercado para el software comercial .

SIE, como proveedor, puede resolver este problema, pero la ética de las organizaciones de normalización no permite que ni UN/CEFACT ni XBRL lo aborden. SIE podría desempeñar un papel clave en este ámbito, proporcionando una capa de instrucciones aplicadas a XBRL GL (y a la contabilidad UN/CEFACT). Sin embargo, en la reunión anual de SIE de 2013, tras un año de estudio de XBRL GL y con la presencia de un representante de XBRL GL International, los miembros principales debatieron sobre quién era el cliente que pagaba, y el proyecto de implementación de XBRL GL por parte de SIE fracasó.

En la prensa especializada se han publicado numerosos artículos sobre proyectos XBRL muy costosos con resultados muy limitados en su uso a gran escala. La contradicción entre la ética de la organización de estándares y las cuestiones relacionadas con la tecnología aplicada (un conjunto común de instrucciones de implementación) es difícil de resolver para lograr que dichos proyectos tengan más éxito.

En 1992, SIE resolvió el problema del formato de archivo SIE como una sociedad de proveedores no estandarizada . Todos los miembros, excepto un gran proveedor, acordaron una implementación común, incluyendo un conjunto de instrucciones de implementación, y la pusieron a disposición de todos los proveedores del mercado. Todos los demás proveedores (nacionales, futuros e internacionales) del mercado sueco de software comercial relacionado con la contabilidad tuvieron que, debido a la demanda de los clientes, adoptar el estándar para poder vender cualquier volumen. De hecho, la existencia del formato común demostró al mercado argumentos muy sólidos para los usuarios que generaban datos, ofreciendo grandes beneficios reales, especialmente en la interacción diaria entre la empresa, el consultor contable y la auditoría, que se volvía muy racional y se beneficiaba de la posible retroalimentación diaria de información. Es casi imposible convencer a los clientes de pago de los beneficios y las funcionalidades antes de que estén realmente disponibles, y este es un gran problema comercial que XBRL GL y UN/CEFACT deben resolver, al no ser una sociedad de interés de proveedores. Es interesante observar que la visión inicial de SIE era similar a la de XBRL: exportar datos contables a software comercial para la declaración de impuestos. Sin embargo, es posible encontrar datos de puntos de beneficio especiales para los productores y, de esta manera, hacerles pagar para obtener las características del formato de archivo estándar de contabilidad, pero se trata de un problema de diseño comercial complejo.

Existe una situación de estancamiento general en este sector del mercado. La gran incógnita para el futuro reside en cómo XBRL resolverá este problema.