XBRL, built as an ontology. So it tells you where and why.

The problem

The time goes into hunting for what is wrong.

XBRL validators are good at saying no. They rarely say where, almost never say why, and rather than tell you what to change, they hand the job back to you.

• An error code lands, and nothing tells you which file or which line it came from.
• Working out what it even means takes a trip through the specification.
• And once you know what is wrong, still nobody says what to change.
• So every question from the filing team comes back to your developers.
• And after an upgrade, what passed yesterday quietly fails today.

Integrate

Your interface. Your workflow. MirrorMere stays out of sight.

One file in your build and you are done. Each specification is its own module, so you can take only the ones you deal with — and whichever one catches a problem, the answer comes back in the same shape.

// One result type, whichever specification produced it.
ValidationOutcome outcome = validator.validate(report);

if (!outcome.isValid()) {
    for (ValidationFinding f : outcome.errors()) {
        f.code();      // ixe:illegalMultipleUseOfId
        f.specRef();   // Inline XBRL 1.1, Section 4
        f.location();
    }
}