Integrazione

Non dovete costruire un motore di validazione.

MirrorMere non è uno strumento per scrivere XBRL, ma un motore che verifica che quello prodotto sia conforme. Schermi, processi e vincoli di deployment restano come sono; entra dentro solo il controllo.

Richiedi una valutazione tecnica Come lavoriamo insieme

Le integrazioni possibili oggi

Dichiarato allo stato di avanzamento reale.

Nulla è presentato come disponibile prima di esserlo. Ciò che è in roadmap è indicato come tale.

Disponibile

SDK Java

Aggiungete un jar alla build e richiamatelo. Nessun agent, nessun servizio da tenere acceso a fianco.

Disponibile

CLI e batch

Un jar eseguibile, lanciato da riga di comando o da un job batch. Si inserisce in una pipeline che avete già.

Disponibile

Container e installazione privata

Funziona senza vincoli dentro una rete chiusa. Nulla dei vostri documenti ne esce.

Su accordo commerciale

OEM e white label

Integratelo nella soluzione che già vendete, nella forma che vi serve. Le condizioni si concordano caso per caso.

Previsto

API REST

Un'API XBRL su HTTP è prevista per il secondo semestre del 2026.

MirrorMere resta invisibile.

SDK Java

Ciò che torna vi dice dove, perché e che cosa guardare.

Ciò che tornate ad avere non è un elenco di codici d'errore. Ogni rilievo dice dove si trova nel documento, quale clausola viola e quindi che cosa deve guardare chi ha in mano il deposito. Arriva nella stessa forma sia che l'abbia intercettato Dimensions sia Inline XBRL: potete metterglielo davanti così com'è.

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 chiamata, e tutto ciò che serve per la revisione è già dentro: dove, perché e che cosa correggere.

CLI e batch

Tre comandi fanno tutto. Non serve altro.

validate: Controlla un deposito. Accetta un pacchetto di trasmissione, un insieme di file Inline XBRL o un singolo documento: più file che appartengono allo stesso deposito vengono controllati insieme, come uno solo.
cts: Eseguite voi stessi i test standard pubblicati: tutti, o solo la parte che vi interessa. I numeri della pagina certificazione vengono da qui.
doctor: Controlla la macchina prima che vi fidiate di un risultato: le tassonomie sono al loro posto, l'ambiente è a posto? Un file mancante emerge qui come problema di configurazione, non dopo come un via libera.

Reti chiuse

Anche dove Internet non arriva, funziona lo stesso.

I reparti finanza e revisione lavorano spesso su reti staccate da Internet. I motori che scaricano dal Web ciò su cui validano lì si fermano. Peggio ancora: alcuni proseguono controllando meno, senza dirlo. MirrorMere non esce mai.

Le tassonomie vi vengono date come file che tenete voi. Nulla viene scaricato durante l'esecuzione.
Se manca qualcosa che gli serve, lo dice. Non lascia passare il documento al suo posto.
Ogni esecuzione annota quali tassonomie ha usato: se due macchine divergono, si confronta invece di discutere.
Nessun traffico in uscita di alcun tipo: né statistiche d'uso, né controlli di licenza.

Se usate già uno strumento open source

L'open source va benissimo.

Esistono validatori XBRL liberi e gratuiti, e alcuni hanno la nostra stessa certificazione di Validating Processor. Se dovete controllare un deposito ogni tanto, bastano. Vendere un prodotto con la validazione dentro richiede tre cose in più.

Una libreria, non un programma da tenere acceso

MirrorMere è una libreria in puro Java pensata per stare dentro il vostro prodotto: un file nella build, chiamato direttamente dal vostro codice. Nessun processo separato da tenere vivo, nessun ponte da mantenere.

C'è qualcuno a cui chiedere

Quando una specifica cambia, starle dietro è un nostro obbligo, non qualcosa che dovete attendere. E se vi bloccate, la domanda arriva a chi ha scritto il motore.

Non siete obbligati a scegliere. Farli girare entrambi e confrontare è una cosa ragionevole: quando due implementazioni indipendenti arrivano allo stesso verdetto, quell'accordo è già una prova.

Impegno sugli standard

Le specifiche cambiano di continuo. Starle dietro è il nostro mestiere, non il vostro.

Versioni: Ogni risultato porta con sé la versione che l'ha prodotto. Se mesi dopo la risposta cambia, potete vedere che cosa è cambiato invece di discuterne.
Aggiornamento alle specifiche: Quando una specifica o la sua suite di test viene rivista, l'intera suite viene rieseguita prima di qualsiasi rilascio.
Supporto: Contatto tecnico diretto con chi costruisce il motore, senza una coda di ticket davanti.
Installazione: L'installazione on-premise e in rete chiusa è la norma, non un'eccezione da negoziare.
Licenza di valutazione: Una licenza che copre l'intero periodo di valutazione, senza limiti di postazioni o di volume mentre provate.
Licenze di terze parti: Le librerie di terze parti e le loro licenze sono incluse nella consegna, pronte da passare così come sono al vostro ufficio legale.

La caccia al «perché» sparisce.

Si comincia da qui

Diteci che cosa state costruendo.

Diteci che cosa state costruendo e dove vi siete bloccati, e lo sbroglieremo insieme a voi. È questo che vale la pena comprare, non il file.

Ricevete il motore, l'esecutore da riga di comando e gli strumenti di test: la stessa build che usiamo noi.
Provatelo sui vostri depositi reali, non su un campione scelto da noi.
Ogni numero di questo sito potete rifarlo voi: le suite sono pubbliche e l'esecutore è nel pacchetto.
Prima un accordo di riservatezza, prima che qualcosa passi di mano.

Preferite la posta? Scriveteci direttamente. manager@codebplat.co.kr