Document Purpose: Explain why XBRL requires mapping capabilities, why design-time schema generation is crucial, and how GLOMIDCO's approach enables both generating and consuming XBRL instances through visual mapping tools and UTL-X
Last Updated: January 2026
Target Audience: Integration architects, XBRL implementers, IT managers
The Challenge:
XBRL is a powerful reporting standard, but it's fundamentally incompatible with how most business systems represent data. Source systems (ERP, GL, Risk systems) don't naturally speak "XBRL," and XBRL instances arriving from external parties can't be directly consumed by internal systems.
The Missing Link: Mapping
┌──────────────┐
Business Data ────►│ MAPPING │────► XBRL Instance
(GL, ERP, etc) │ LAYER │ (Regulatory Report)
└──────────────┘
▲
│
┌────────┴─────────┐
│ Design-Time │
│ Schema │
│ Generation │
└──────────────────┘
GLOMIDCO Solution:
Result:
XBRL is not a natural data format.
Compare how systems represent the same information:
Account | Amount | Date | Entity | Currency
─────────────────────────────────────────────────────────
10100 | 5000000.00 | 2024-12-31 | US01 | USD
10200 | 3000000.00 | 2024-12-31 | US01 | USD
10300 | 2000000.00 | 2024-12-31 | US01 | USD
20100 | 4000000.00 | 2024-12-31 | US01 | USD
30100 | 6000000.00 | 2024-12-31 | US01 | USD
SELECT
exposure_class,
counterparty_type,
geographic_area,
SUM(exposure_amount) as total_exposure
FROM credit_exposures
WHERE reporting_date = '2024-12-31'
GROUP BY exposure_class, counterparty_type, geographic_area
{
"reportingDate": "2024-12-31",
"entity": "US01",
"financials": {
"balanceSheet": {
"assets": {
"currentAssets": {
"cash": 5000000,
"receivables": 3000000,
"inventory": 2000000
}
},
"liabilities": {
"currentLiabilities": 4000000
},
"equity": {
"totalEquity": 6000000
}
}
}
}
<xbrli:xbrl>
<xbrli:context id="c1">
<xbrli:entity>
<xbrli:identifier scheme="...">US01</xbrli:identifier>
<xbrli:segment>
<xbrldi:explicitMember dimension="us-gaap:StatementClassOfStockAxis">
us-gaap:CommonStockMember
</xbrldi:explicitMember>
</xbrli:segment>
</xbrli:entity>
<xbrli:period>
<xbrli:instant>2024-12-31</xbrli:instant>
</xbrli:period>
<xbrli:scenario>
<xbrldi:explicitMember dimension="us-gaap:ConsolidationItemsAxis">
us-gaap:OperatingSegmentsMember
</xbrldi:explicitMember>
</xbrli:scenario>
</xbrli:context>
<xbrli:unit id="USD">
<xbrli:measure>iso4217:USD</xbrli:measure>
</xbrli:unit>
<us-gaap:CashAndCashEquivalentsAtCarryingValue
contextRef="c1" unitRef="USD" decimals="0">
5000000
</us-gaap:CashAndCashEquivalentsAtCarryingValue>
<us-gaap:AccountsReceivableNetCurrent
contextRef="c1" unitRef="USD" decimals="0">
3000000
</us-gaap:AccountsReceivableNetCurrent>
<!-- ... many more facts ... -->
</xbrli:xbrl>
Key Differences:
| Aspect | Business Systems | XBRL |
|---|---|---|
| Structure | Tables, trees, simple objects | Context + dimensions + facts |
| Concepts | Account codes, field names | QNames from taxonomy |
| Dimensions | Implicit (columns) | Explicit (segment/scenario) |
| Units | Often implicit | Explicit unit definitions |
| Metadata | Minimal | Extensive (contexts, units, footnotes) |
| Natural? | Yes - how people think | No - technical standard |
Conclusion: You CANNOT directly map SAP data to XBRL without a transformation layer.
Option 1: Write Custom Code (Bad Idea)
// Hand-coding XBRL generation from SAP data
public XBRLInstance generateFromSAP(List<GLAccount> accounts) {
XBRLInstance instance = new XBRLInstance();
// Create context manually
Context ctx = new Context();
ctx.setId("c1");
Entity entity = new Entity();
entity.setIdentifier("US01", "...");
// Add dimensions manually
Segment segment = new Segment();
ExplicitMember member1 = new ExplicitMember();
member1.setDimension(new QName("http://fasb.org/us-gaap/2024", "StatementClassOfStockAxis"));
member1.setValue(new QName("http://fasb.org/us-gaap/2024", "CommonStockMember"));
segment.addMember(member1);
// ... 50 more lines of boilerplate ...
// Map each account
for (GLAccount account : accounts) {
Fact fact = new Fact();
// Map account code to XBRL concept
if (account.getCode().equals("10100")) {
fact.setConcept(new QName("http://fasb.org/us-gaap/2024",
"CashAndCashEquivalentsAtCarryingValue"));
} else if (account.getCode().equals("10200")) {
fact.setConcept(new QName("http://fasb.org/us-gaap/2024",
"AccountsReceivableNetCurrent"));
} else if (account.getCode().equals("10300")) {
fact.setConcept(new QName("http://fasb.org/us-gaap/2024",
"InventoryNet"));
}
// ... 1000 more account mappings ...
fact.setContext(ctx);
fact.setValue(account.getAmount().toString());
instance.addFact(fact);
}
return instance;
}
Problems:
Reality: For a real regulatory report with 50,000 data points, hand-coding would require 50,000+ lines of code!
Outbound: Generate XBRL (Most Common)
Business Systems Mapping XBRL Instance
(Source Data) ═══════════════► (Report Output)
Examples:
├─ SAP GL → SEC 10-K filing (US GAAP)
├─ Risk System → COREP/FINREP submission
├─ Treasury System → Liquidity report
└─ Consolidation tool → Annual report
Use Cases:
Inbound: Consume XBRL (Often Overlooked)
XBRL Instance Mapping Business Systems
(Report Input) ═══════════════► (Target Data)
Examples:
├─ Received SEC filing → Import to analysis database
├─ Subsidiary report → Import to consolidation system
├─ Competitor filing → Import to competitor analysis
└─ Regulatory data → Import to data warehouse
Use Cases:
Key Point: BOTH directions require mapping capabilities!
Typical SEC 10-K Filing (US GAAP):
Typical COREP/FINREP Submission:
Without proper mapping tools, this is unmanageable.
Problem: Business systems use different names than XBRL taxonomies.
SAP Account Code → XBRL Concept
─────────────────────────────────
10100 → us-gaap:CashAndCashEquivalentsAtCarryingValue
10200 → us-gaap:AccountsReceivableNetCurrent
10300 → us-gaap:InventoryNet
20100 → us-gaap:AccountsPayableCurrent
Complexity:
Problem: Business systems have implicit dimensions, XBRL has explicit dimensions.
Example: Breakdown by Business Segment
In SQL:
SELECT segment, SUM(revenue)
FROM sales
WHERE period = '2024'
GROUP BY segment
Result:
segment | revenue
─────────────────────
Retail | 100M
Commercial | 150M
Investment | 80M
In XBRL:
<!-- Retail segment -->
<context id="retail_2024">
<entity>...</entity>
<period>2024</period>
<scenario>
<xbrldi:explicitMember dimension="us-gaap:StatementBusinessSegmentsAxis">
company:RetailSegmentMember
</xbrldi:explicitMember>
</scenario>
</context>
<us-gaap:RevenueFromContractWithCustomerExcludingAssessedTax
contextRef="retail_2024" unitRef="USD" decimals="0">
100000000
</us-gaap:RevenueFromContractWithCustomerExcludingAssessedTax>
<!-- Commercial segment -->
<context id="commercial_2024">
<entity>...</entity>
<period>2024</period>
<scenario>
<xbrldi:explicitMember dimension="us-gaap:StatementBusinessSegmentsAxis">
company:CommercialSegmentMember
</xbrldi:explicitMember>
</scenario>
</context>
<us-gaap:RevenueFromContractWithCustomerExcludingAssessedTax
contextRef="commercial_2024" unitRef="USD" decimals="0">
150000000
</us-gaap:RevenueFromContractWithCustomerExcludingAssessedTax>
<!-- Investment segment -->
<!-- ... same pattern ... -->
Mapping Required:
SQL "segment" column value → XBRL dimension member
─────────────────────────────────────────────────────
"Retail" → company:RetailSegmentMember
"Commercial" → company:CommercialSegmentMember
"Investment" → company:InvestmentSegmentMember
Plus must:
Problem: Source data granularity ≠ XBRL reporting granularity
Example:
Source: GL has 500 expense accounts
Account | Description | Amount
─────────────────────────────────────
60100 | Salaries | 5M
60110 | Bonuses | 1M
60120 | Benefits | 2M
60200 | Office Rent | 0.5M
60210 | Utilities | 0.2M
... | ... | ...
(500 accounts total)
XBRL: 10 line items
<us-gaap:EmployeeServiceExpense>8M</us-gaap:EmployeeServiceExpense>
<us-gaap:OccupancyExpense>0.7M</us-gaap:OccupancyExpense>
...
Mapping Required:
GL Accounts 60100, 60110, 60120 → us-gaap:EmployeeServiceExpense
GL Accounts 60200, 60210 → us-gaap:OccupancyExpense
Must handle:
Problem: Must create unique contexts for each dimension combination.
With 3 dimensions:
Must:
Problem: Generated XBRL must pass validation.
Must ensure:
Human brains understand visual patterns better than code.
Compare:
Code-Based Mapping:
if (account.startsWith("10")) {
if (account.equals("10100")) {
return "us-gaap:CashAndCashEquivalentsAtCarryingValue";
} else if (account.equals("10200")) {
return "us-gaap:AccountsReceivableNetCurrent";
}
// ... 500 more conditions ...
}
Visual Mapping (MuleSoft DataWeave):
%dw 2.0
output application/json
---
{
facts: payload.accounts map {
concept: $.accountCode match {
case "10100" -> "CashAndCashEquivalentsAtCarryingValue"
case "10200" -> "AccountsReceivableNetCurrent"
case "10300" -> "InventoryNet"
else -> error("Unknown account: " ++ $.accountCode)
},
value: $.amount,
context: "default"
}
}
Visual Mapping (Tibco BW Mapper):
[Drag and drop visual interface]
accountCode ─────►[Lookup]─────► concept
↓
[Mapping Table]
10100 → Cash...
10200 → Receivables...
amount ──────────────────────────► value
Benefits:
Problem: Middleware tools (MuleSoft, Tibco, webMethods) need schemas to enable visual mapping.
GLOMIDCO Solution: Generate XSD or JSON Schema from XBRL taxonomy at design time.
┌─────────────────────────────────────────────┐
│ XBRL Taxonomy Package │
│ (Complex XBRL with Table Linkbase) │
└─────────────────────────────────────────────┘
│
│ GLOMIDCO Processor
│ Design-Time Schema Generator
▼
┌───────────┴───────────┐
│ │
▼ ▼
┌───────────────┐ ┌───────────────┐
│ XSD Schema │ │ JSON Schema │
│ (for Tibco, │ │ (for MuleSoft,│
│ webMethods) │ │ APIs) │
└───────────────┘ └───────────────┘
│ │
│ │
▼ ▼
┌───────────────┐ ┌───────────────┐
│ Visual │ │ Visual │
│ Mapping in │ │ Mapping in │
│ Middleware │ │ Middleware │
└───────────────┘ └───────────────┘
// GLOMIDCO API
SchemaGenerator generator = new SchemaGenerator();
// Select taxonomy and entry point
TaxonomyPackage taxonomy =
TaxonomyPackage.load("us-gaap-2024.zip");
EntryPoint entryPoint =
taxonomy.getEntryPoint("Full US GAAP Taxonomy");
// Select viewpoint (more on this later)
Viewpoint viewpoint = Viewpoint.TABLE_ORIENTED;
// Generate schema
Schema schema = generator.generateSchema(
entryPoint,
viewpoint,
SchemaFormat.XSD // or JSON_SCHEMA
);
// Export for middleware
schema.saveTo("us-gaap-2024-table-view.xsd");
Instead of complex XBRL:
<context id="c1">
<entity>
<identifier>...</identifier>
<segment>
<explicitMember dimension="...">...</explicitMember>
</segment>
</entity>
<period>...</period>
</context>
<fact contextRef="c1" ...>value</fact>
Schema presents simplified structure:
<!-- XSD generated by GLOMIDCO -->
<xs:element name="Report">
<xs:complexType>
<xs:sequence>
<xs:element name="Entity" type="xs:string"/>
<xs:element name="Period" type="xs:date"/>
<xs:element name="Facts" type="FactsType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="FactsType">
<xs:sequence>
<xs:element name="CashAndCashEquivalents" type="MonetaryType"
minOccurs="0"/>
<xs:element name="AccountsReceivable" type="MonetaryType"
minOccurs="0"/>
<xs:element name="Inventory" type="MonetaryType"
minOccurs="0"/>
<!-- ... all concepts as elements ... -->
</xs:sequence>
</xs:complexType>
Or as JSON Schema:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"entity": {"type": "string"},
"period": {"type": "string", "format": "date"},
"facts": {
"type": "object",
"properties": {
"cashAndCashEquivalents": {"type": "number"},
"accountsReceivable": {"type": "number"},
"inventory": {"type": "number"}
}
}
}
}
In MuleSoft:
1. Import generated JSON Schema
2. Use DataWeave mapper
3. Drag source fields to target fields
4. Add transformations visually
5. Test with sample data
In Tibco BW:
1. Import generated XSD
2. Use visual mapper palette
3. Connect source to target
4. Add functions/lookups
5. Validate mapping
At runtime, GLOMIDCO processor:
Developer sees simple structure, GLOMIDCO handles XBRL complexity!
Key Insight: Different use cases need different views of the taxonomy.
Use Case: Simple fact-by-fact population
Structure:
{
"facts": [
{
"concept": "us-gaap:CashAndCashEquivalents",
"value": 5000000,
"entity": "US01",
"period": "2024-12-31",
"dimensions": {}
},
{
"concept": "us-gaap:AccountsReceivable",
"value": 3000000,
"entity": "US01",
"period": "2024-12-31",
"dimensions": {}
}
]
}
Best for:
Use Case: COREP/FINREP and other table-based reports
Structure:
{
"tables": {
"C_01_00_OwnFunds": {
"rows": [
{
"rowCode": "r010",
"columns": {
"c010": 1500000000,
"c020": 1500000000
}
},
{
"rowCode": "r020",
"columns": {
"c010": 1250000000,
"c020": 1250000000
}
}
]
}
}
}
Best for:
Use Case: Following presentation structure
Structure:
{
"financialStatements": {
"balanceSheet": {
"assets": {
"currentAssets": {
"cash": 5000000,
"receivables": 3000000,
"inventory": 2000000,
"totalCurrentAssets": 10000000
},
"nonCurrentAssets": {
"property": 15000000,
"intangibles": 5000000,
"totalNonCurrentAssets": 20000000
},
"totalAssets": 30000000
}
}
}
}
Best for:
Use Case: Multi-dimensional analysis
Structure:
{
"dimensions": {
"bySegment": {
"retail": {
"revenue": 100000000,
"expenses": 80000000,
"netIncome": 20000000
},
"commercial": {
"revenue": 150000000,
"expenses": 120000000,
"netIncome": 30000000
}
}
}
}
Best for:
// Generate table-oriented schema for COREP
SchemaGenerator generator = new SchemaGenerator();
TaxonomyPackage corep =
TaxonomyPackage.load("eba-corep-finrep-3.4.zip");
// Select specific templates
List<String> templates = Arrays.asList(
"C 01.00", "C 02.00", "C 03.00"
);
Schema schema = generator.generateTableSchema(
corep,
templates,
SchemaFormat.JSON_SCHEMA
);
System.out.println(schema.toJSON());
Generated JSON Schema:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"reportingEntity": {
"type": "string",
"description": "LEI of reporting entity"
},
"reportingDate": {
"type": "string",
"format": "date"
},
"tables": {
"type": "object",
"properties": {
"C_01_00": {
"type": "object",
"description": "Own Funds",
"properties": {
"r010_c010": {
"type": "number",
"description": "Total Own Funds"
},
"r020_c010": {
"type": "number",
"description": "Tier 1 Capital"
},
"r030_c010": {
"type": "number",
"description": "Common Equity Tier 1"
}
}
},
"C_02_00": {
"type": "object",
"description": "Own Funds Requirements"
}
}
}
}
}
Now MuleSoft can map to this structure visually!
GLOMIDCO also generates error schemas:
{
"errorSchema": {
"type": "object",
"properties": {
"validationErrors": {
"type": "array",
"items": {
"type": "object",
"properties": {
"code": {"type": "string"},
"message": {"type": "string"},
"severity": {"type": "string", "enum": ["ERROR", "WARNING"]},
"location": {
"type": "object",
"properties": {
"template": {"type": "string"},
"row": {"type": "string"},
"column": {"type": "string"}
}
}
}
}
}
}
}
}
Enables proper error handling in middleware flows.
Not everyone has (or can afford) enterprise middleware:
Traditional alternatives:
UTL-X (Universal Transform Language - XBRL) is GLOMIDCO's open-source functional mapping language.
Key Features:
// UTL-X mapping: SAP GL to US GAAP XBRL
namespace sap = "urn:sap:gl";
namespace us-gaap = "http://fasb.org/us-gaap/2024";
taxonomy "us-gaap-2024.zip";
entrypoint "Full US GAAP";
// Define default context
context default {
entity: input.companyLEI,
period: instant(input.reportingDate),
dimensions: {}
}
// Map GL accounts to XBRL concepts
fact us-gaap:CashAndCashEquivalentsAtCarryingValue {
context: default,
value: sum(
input.accounts
.filter(a => a.code in ["10100", "10110", "10120"])
.map(a => a.balance)
),
unit: currency(input.reportingCurrency)
}
fact us-gaap:AccountsReceivableNetCurrent {
context: default,
value: sum(
input.accounts
.filter(a => a.code.startsWith("102"))
.map(a => a.balance)
),
unit: currency(input.reportingCurrency)
}
// Dimensional fact with segment breakdown
fact us-gaap:Revenues {
for segment in input.segments {
context: {
entity: default.entity,
period: default.period,
dimensions: {
us-gaap:StatementBusinessSegmentsAxis:
toMember(segment.name, "SegmentMember")
}
},
value: segment.revenue,
unit: default.unit
}
}
Key Features:
sum(), avg(), etc..filter() method// UTL-X mapping: XBRL to SAP import format
input xbrl "competitor-10k.xbrl";
output format "SAP_IDoc";
// Extract cash value
extract cash = fact(us-gaap:CashAndCashEquivalentsAtCarryingValue) {
where: context.period.end == "2024-12-31",
select: value
}
// Extract by segment
extract revenue_by_segment = facts(us-gaap:Revenues) {
where: context.period.year == 2024,
groupBy: context.dimension(us-gaap:StatementBusinessSegmentsAxis),
select: {
segment: dimensionMemberName,
revenue: sum(value)
}
}
// Generate SAP IDoc
output {
IDOC: {
E1_ACCOUNTING_DATA: [
{
ACCOUNT: "10100",
AMOUNT: cash,
CURRENCY: extractedCurrency
},
...revenue_by_segment.map(seg => {
SEGMENT: seg.segment,
REVENUE: seg.revenue
})
]
}
}
Design Time:
// Validate mapping against taxonomy
@designTime {
validate: true,
taxonomy: "us-gaap-2024.zip",
checkConcepts: true,
checkDimensions: true
}
Init Time:
// Load taxonomy once, compile mapping
@initTime {
compiledTaxonomy: load("us-gaap-2024.zip"),
optimizations: true,
caching: true
}
Runtime:
// Fast execution using compiled taxonomy
@runtime {
useCompiledTaxonomy: true,
parallelProcessing: true
}
Hand-Coded Java: 500 lines
public XBRLInstance transform(List<GLAccount> accounts) {
XBRLInstance instance = new XBRLInstance();
// ... 50 lines of boilerplate ...
for (GLAccount account : accounts) {
if (account.getCode().startsWith("101")) {
// ... 10 lines per concept ...
}
}
// ... 450 more lines ...
return instance;
}
UTL-X: 50 lines
taxonomy "us-gaap-2024.zip";
context default { /* 5 lines */ }
fact us-gaap:CashAndCashEquivalents {
value: sum(accounts.filter(/* 2 lines */))
}
// ... 40 more lines for all facts ...
Result: 90% less code, much more maintainable!
Scenario: Public company generates 10-K filing from SAP
Challenge:
Solution:
SAP GL Data
│
▼
MuleSoft Flow
├─ DataWeave mapper
├─ Maps using generated JSON Schema
└─ Calls GLOMIDCO connector
│
▼
GLOMIDCO Processor
├─ Validates mapping
├─ Generates contexts
├─ Creates XBRL instance
└─ Validates against US GAAP
│
▼
SEC Filing (10-K.xbrl)
Development Time:
Scenario: European bank generates regulatory reports
Challenge:
Solution (as described in Document 13):
60 Independent Flows (one per template)
├─ Each uses table-oriented viewpoint
├─ Maps source data to table structure
└─ Generates partial XBRL
│
▼
GLOMIDCO Intelligent Merger
└─ Merges to complete submission
Scenario: Parent company consolidates subsidiary XBRL reports
Challenge:
Solution:
Subsidiary XBRL Reports (20 files)
│
▼
GLOMIDCO Processor (with inbound mapping)
├─ Reads XBRL instances
├─ Extracts facts using UTL-X
└─ Maps to consolidation format
│
▼
Consolidation System (SAP BPC)
UTL-X Mapping:
input xbrl "subsidiary-*.xbrl";
output format "SAP_BPC";
// Extract revenue by subsidiary
extract consolidated_revenue = facts(*/Revenue) {
groupBy: context.entity,
select: {
subsidiary: entityName,
revenue: sum(value),
currency: unit.currency
}
}
// Handle currency conversion
transform consolidated_revenue {
revenue: convertCurrency(
revenue,
currency,
"EUR",
ratesAt(context.period.end)
)
}
Scenario: Banking regulator receives COREP/FINREP from 500 banks
Challenge:
Solution:
500 Bank Submissions
│
▼
GLOMIDCO Batch Processor
├─ Validates each submission
├─ Extracts facts using UTL-X
└─ Maps to relational database
│
▼
PostgreSQL Database
├─ Normalized structure
├─ Ready for analysis
└─ Queryable with SQL
Result:
Scenario: Analyst firm analyzes competitor SEC filings
Challenge:
Solution:
SEC EDGAR Filings (XBRL)
│
▼
UTL-X Extraction Script
├─ Extract revenue
├─ Extract expenses
├─ Extract assets/liabilities
└─ Extract segment data
│
▼
Excel/Database
└─ Comparative analysis
UTL-X Script:
input xbrl "edgar-filings/*.xbrl";
output format "CSV";
extract key_metrics = {
company: context.entity,
year: context.period.year,
revenue: fact(us-gaap:Revenues).value,
netIncome: fact(us-gaap:NetIncomeLoss).value,
totalAssets: fact(us-gaap:Assets).value,
totalEquity: fact(us-gaap:StockholdersEquity).value,
segments: facts(us-gaap:Revenues) {
where: hasDimension(us-gaap:StatementBusinessSegmentsAxis),
select: {
name: dimensionMemberName,
revenue: value
}
}
}
Using GLOMIDCO with MuleSoft/Tibco/webMethods:
✅ Visual Mapping
✅ Faster Development
✅ Lower Risk
✅ Leverage Existing Tools
✅ Bidirectional
Using GLOMIDCO with UTL-X:
✅ No Middleware Required
✅ XBRL-Aware
✅ Functional Programming
✅ Three-Phase Architecture
✅ Both Directions
✅ Maintainability
✅ Testability
✅ Auditability
✅ Scalability
✅ Compliance
| Use Case | Recommended Viewpoint |
|---|---|
| Simple financial statements | Hierarchical (Presentation) |
| Regulatory tables (COREP/FINREP) | Table-Oriented |
| Multi-dimensional analysis | Dimensional |
| Fact-by-fact population | Flat |
| Mixed requirements | Custom (contact GLOMIDCO) |
For Outbound (Generate XBRL):
For Inbound (Consume XBRL):
Taxonomy v3.3 → Schema v1.0 → Mapping v1.0
↓ ↓ ↓
Taxonomy v3.4 → Schema v2.0 → Mapping v2.0
↓ ↓ ↓
Taxonomy v3.5 → Schema v3.0 → Mapping v3.0
Strategy:
❌ Don't: Try to map directly to XBRL XML structure
✅ Do: Use generated schemas with simplified structure
❌ Don't: Hand-code context generation
✅ Do: Let GLOMIDCO handle contexts automatically
❌ Don't: Ignore validation errors
✅ Do: Fix validation errors iteratively
❌ Don't: Create monolithic mappings
✅ Do: Break into smaller, testable mappings
❌ Don't: Skip documentation
✅ Do: Document mapping rules and business logic
XBRL instances don't magically appear from business systems.
They require systematic transformation from:
And XBRL instances arriving from external parties can't be directly consumed.
They require systematic transformation from:
Visual mapping tools need schemas to function.
GLOMIDCO's design-time schema generation:
Result: XBRL becomes mappable like any other data format.
Not everyone can afford enterprise middleware.
UTL-X provides:
Result: XBRL mapping accessible to everyone.
Without proper mapping capabilities, XBRL is impractical.
With GLOMIDCO's approach:
XBRL mapping done right = XBRL adoption success.
This document explains why XBRL mapping is essential, how GLOMIDCO's design-time schema generation enables visual mapping in middleware platforms, and how UTL-X provides an open-source alternative for organizations without enterprise middleware.