Integración

No construya un motor de validación. Déjenos la comprobación.

MirrorMere no escribe su XBRL: lo comprueba. Sus pantallas, su flujo y sus restricciones de despliegue siguen igual, y la comprobación ocurre debajo.

Solicitar una evaluación técnica Cómo trabajamos juntos

Las integraciones posibles hoy

Indicado en su estado real de disponibilidad.

Nada se presenta como disponible antes de serlo. Lo que está en la hoja de ruta se señala como tal.

Disponible

SDK de Java

Añada un jar a su compilación y llámelo. Sin agente ni servicio que haya que mantener aparte.

Disponible

CLI y procesos por lotes

Un jar ejecutable que se lanza desde la línea de comandos o desde un proceso por lotes. Encaja en un pipeline que ya tienen.

Disponible

Contenedor e instalación privada

Funciona sin restricciones dentro de una red cerrada. Nada de sus documentos sale de ahí.

Según acuerdo comercial

OEM y marca blanca

Incorpórelo a la solución que ya venden, con la forma que les convenga. Las condiciones se acuerdan caso por caso.

Previsto

API REST

Una API XBRL sobre HTTP está prevista para el segundo semestre de 2026.

MirrorMere no se deja ver.

SDK de Java

Lo que vuelve le dice dónde, por qué y qué mirar.

Lo que recibe no es una lista de códigos de error. Cada hallazgo dice en qué punto del documento está, qué cláusula incumple y, por tanto, qué debe mirar quien tiene la presentación entre manos. Llega igual lo detecte Dimensions o Inline XBRL: puede ponérselo delante tal cual.

ValidationOutcome outcome = validator.validate(report);

for (ValidationFinding f : outcome.errors()) {
    f.code();      // what went wrong
    f.specRef();   // the clause it breaks
    f.location();  // where in the document
}

Una sola llamada, y ya está dentro todo lo que hace falta para revisar: dónde, por qué y qué corregir.

CLI y procesos por lotes

Tres comandos lo hacen todo. No hace falta nada más.

validate: Comprueba una presentación. Acepta un paquete de envío, un conjunto de ficheros Inline XBRL o un único documento: varios ficheros que pertenecen a la misma presentación se comprueban juntos, como uno solo.
cts: Ejecute usted mismo las pruebas estándar publicadas: todas, o solo la parte que le interese. De ahí salen las cifras de la página de certificación.
doctor: Revisa la máquina antes de que se fíe de un resultado: ¿están las taxonomías donde deben, está el entorno bien? Un fichero que falta aparece aquí como problema de configuración, y no después como un visto bueno.

Redes cerradas

Donde no hay Internet, funciona igual.

Los equipos de finanzas y auditoría suelen trabajar en redes aisladas de Internet. Los motores que descargan de la Web aquello contra lo que validan se detienen ahí. Peor todavía: algunos siguen comprobando menos, sin decir nada. MirrorMere no sale nunca.

Las taxonomías se entregan como ficheros que usted conserva. Nada se descarga durante la ejecución.
Si le falta algo que necesita, lo dice. No deja pasar el documento en su lugar.
Cada ejecución anota qué taxonomías utilizó: si dos máquinas discrepan, se comparan en vez de discutir.
Ningún tráfico saliente de ningún tipo: ni informes de uso, ni comprobación de licencia.

Si ya usa una herramienta de código abierto

El código abierto es una buena opción.

Existen validadores XBRL libres y gratuitos, y algunos tienen la misma certificación de Validating Processor que nosotros. Si solo necesita comprobar una presentación de vez en cuando, le servirán. Vender un producto con la validación dentro pide tres cosas más.

Una biblioteca, no un programa que hay que tener corriendo

MirrorMere es una biblioteca en Java puro pensada para vivir dentro de su producto: un fichero en su compilación, invocado directamente desde su código. Ningún proceso aparte que mantener vivo, ningún puente que cuidar.

Hay a quién preguntar

Cuando se revisa una especificación, seguirla es obligación nuestra, no algo que usted deba esperar. Y si se atasca, la pregunta llega a quienes escribieron el motor.

Responde al porqué

MirrorMere razona sobre una ontología del propio XBRL, así que un hallazgo llega con dónde está, qué cláusula incumple y qué cambiar, en palabras sobre las que puede actuar quien tiene la presentación.

Tampoco tiene que elegir. Ejecutar ambos y comparar es razonable: cuando dos implementaciones independientes llegan al mismo veredicto, esa coincidencia es en sí una prueba.

Compromiso con las normas

Las especificaciones no dejan de cambiar. Seguirlas es nuestro trabajo, no el suyo.

Es algo que se instala una vez y se conserva durante años. Por eso, cuando una especificación cambia, nos toca a nosotros seguirla; nada sale hasta volver a pasar todas las pruebas estándar. Y sus preguntas llegan a quienes escriben el motor.

Nada sale hasta que pasan las pruebas

Cada versión debe superar antes todas las baterías estándar. Un cambio que rompa una nunca llega hasta usted.

Una revisión toca un solo módulo

Cuando se revisa una especificación, solo cambia su módulo. El resto, aquello de lo que usted depende, sigue igual.

Las definiciones de errores están en un solo sitio

Qué significa cada error, y la cláusula que lo respalda, está en un único sitio en vez de repartido por el código. Cuando cambia una especificación solo hay un punto que actualizar: más rápido, y más difícil de olvidar.

Versiones: Cada resultado lleva la versión que lo produjo. Si meses después la respuesta cambia, puede ver qué cambió en lugar de discutirlo.
Seguimiento de las especificaciones: Cuando se revisa una especificación o su batería de pruebas, se vuelve a ejecutar entera antes de publicar nada.
Soporte: Contacto técnico directo con quienes construyen el motor, sin una cola de tickets delante.
Despliegue: El despliegue local y en red cerrada es lo normal, no una excepción que haya que negociar.
Licencia de evaluación: Una licencia que cubre todo el periodo de evaluación, sin límite de puestos ni de volumen mientras prueba.
Licencias de terceros: Las bibliotecas de terceros y sus licencias se entregan con el producto, listas para pasar tal cual a su departamento jurídico.

Se acaba la búsqueda del «por qué».

Empiece por aquí

Cuéntenos qué están construyendo.

Cuéntenos qué está construyendo y dónde se ha atascado, y lo resolveremos con usted. Eso es lo que merece la pena comprar, no el fichero.

Recibe el motor, el ejecutor de línea de comandos y las herramientas de prueba: la misma compilación que usamos nosotros.
Ejecútelo con sus propias presentaciones, no con una muestra elegida por nosotros.
Todas las cifras de este sitio puede rehacerlas usted: las baterías son públicas y el ejecutor viene en el paquete.
Primero un acuerdo de confidencialidad, antes de que nada cambie de manos.

¿Prefiere el correo? Escríbanos directamente. manager@codebplat.co.kr