Document Purpose: Explain why unmanaged runtime extensions are problematic, why managed extensions are necessary, and the Dutch SBR taxonomy versioning anti-pattern
Last Updated: January 2026
Target Audience: XBRL architects, taxonomy designers, IT decision makers, regulators
The Original Promise:
XBRL stands for eXtensible Business Reporting Language. The "X" promised that companies could extend taxonomies at runtime to add their own concepts.
The Reality:
Unmanaged extensions create chaos. When Pepsi and Coca-Cola both extend a taxonomy to add "VendingMachinesPlaced" (a key growth indicator), they do it differently, making the data incomparable and analysis impossible.
The Solution:
Managed extensions like the Dutch SBR program, where extensions are submitted, reviewed, and incorporated into official taxonomies.
The New Problem:
The Dutch SBR creates a NEW taxonomy EVERY YEAR with DIFFERENT NAMESPACES for the SAME FORMS. A VAT return form that hasn't changed requires different IT systems every year. This breaks the entire investment case for XBRL automation.
The Real Solution:
Use XBRL Versioning 1.0 to track changes. Keep stable namespaces. Only create new taxonomy versions when concepts actually change.
XBRL = eXtensible Business Reporting Language
The "X" was not decoration. It meant:
Original Vision (circa 2000):
1. Regulators create base taxonomy
└─ Contains common concepts (Revenue, Assets, etc.)
2. Companies extend at runtime
└─ Add company-specific concepts
└─ Add industry-specific concepts
└─ Add emerging business model concepts
3. Systems process everything
└─ Understand base concepts
└─ Accommodate extensions
└─ Enable analysis
Result: Flexible, future-proof reporting!
Example Vision:
<!-- Base taxonomy (regulator-defined) -->
<concept name="Revenue"/>
<concept name="CostOfSales"/>
<concept name="OperatingExpenses"/>
<!-- Company extension (runtime) -->
<concept name="pepsi:VendingMachineRevenue" extends="Revenue"/>
<concept name="pepsi:VendingMachinesPlaced"/>
<concept name="pepsi:VendingMachineServiceCosts" extends="OperatingExpenses"/>
The Promise:
Companies could innovate in reporting without waiting for regulators to update taxonomies. New business models could be represented immediately.
Legitimate Use Cases:
Emerging Industries
Company-Specific Disclosure
Industry-Specific Needs
The Appeal:
No waiting for standards bodies. No regulatory lag. True business agility.
Scenario: Both companies want to report vending machine placements (a key growth indicator affecting market valuation).
What Happens:
Pepsi Extension (April 2024):
├─ Namespace: http://pepsi.com/xbrl/2024
├─ Concept: pepsi:VendingMachinesDeployed
├─ Type: xbrli:integerItemType
├─ Period Type: Instant
├─ Balance: N/A
└─ Label: "Number of Vending Machines Deployed"
Coca-Cola Extension (May 2024):
├─ Namespace: http://coca-cola.com/xbrl/2024
├─ Concept: coke:VendorMachinesPlaced
├─ Type: xbrli:positiveIntegerItemType
├─ Period Type: Duration
├─ Balance: N/A
└─ Label: "Vendor Machines Placed During Period"
The Problems:
Problem 1: Different Concept Names
Pepsi: VendingMachinesDeployed
Coke: VendorMachinesPlaced
Even spell "vending" differently!
Cannot query both with same code.
Problem 2: Different Semantics
Pepsi: Instant (total deployed)
Coke: Duration (placed during period)
Fundamentally different meanings!
"10,000" means different things.
Problem 3: Different Types
Pepsi: integerItemType (can be negative? for removals?)
Coke: positiveIntegerItemType (only positive)
Data validation differs.
Problem 4: No Common Parent
No way to query:
"Give me vending machine data for all beverage companies"
Would need to know every possible extension concept name.
When 10 Companies Extend:
Company A: vendingMachinesDeployed
Company B: vendorMachinesPlaced
Company C: numberOfVendingUnits
Company D: vendingMachineInstallations
Company E: placedVendingEquipment
Company F: deployedVendingAssets
Company G: vendingMachineCount
Company H: installedVendingMachines
Company I: vendingUnitPlacements
Company J: vendingMachineAssets
Analyst's Nightmare:
# Trying to analyze vending machine data
def get_vending_machines(xbrl_instance):
# Need to check ALL possible extension names
possible_concepts = [
"vendingMachinesDeployed",
"vendorMachinesPlaced",
"numberOfVendingUnits",
"vendingMachineInstallations",
# ... 100+ more variations
]
for concept in possible_concepts:
if concept in instance:
return instance[concept]
# Give up
return None
The Result:
The Fundamental Problem:
Design Time (Development):
├─ Developer creates data model
├─ Database schema defined
├─ Forms/UI generated
├─ Mapping logic written
├─ Validation rules coded
└─ METADATA KNOWN
Runtime (Production):
├─ New extensions appear
├─ Unknown concepts
├─ Unknown types
├─ Unknown relationships
└─ METADATA UNKNOWN
Question: How does the system process unknown metadata?
Answer: IT CANNOT COPE
Example IT Challenge:
// Design-time: Developer knows metadata
class FinancialReport {
BigDecimal revenue;
BigDecimal expenses;
BigDecimal vendingMachinesDeployed; // Known concept
public void validate() {
if (vendingMachinesDeployed < 0) {
throw new ValidationException("Cannot be negative");
}
}
public void mapToDatabase() {
db.insert("vending_machines", vendingMachinesDeployed);
}
}
// Runtime: Extension appears
// Concept: "pepsi:VendorEquipmentUnitsPlaced"
// Question: Where does this map in the database?
// Question: What validation rules apply?
// Question: How does the form display it?
// Answer: UNKNOWN - System cannot process
The Reality:
For IT systems to process data:
1. Schema must exist in database
2. Mapping must be configured
3. Validation rules must be defined
4. UI must be generated
5. Business logic must be coded
All require DESIGN-TIME KNOWLEDGE.
Runtime extensions = UNMAPPABLE.
When Extensions Are Unmanaged:
Industry: Beverage Manufacturing
Common Need: Report vending machine data
Company A Extension:
├─ pepsi:VendingMachinesDeployed (integer)
├─ pepsi:VendingMachineRevenue (monetary)
└─ pepsi:VendingMachineServiceCosts (monetary)
Company B Extension:
├─ coke:VendorMachinesPlaced (positiveInteger)
├─ coke:VendorMachineIncome (monetary)
├─ coke:VendorMachineMaintenanceExpense (monetary)
└─ coke:VendorMachineLocations (string)
Company C Extension:
├─ drpepper:NumberOfVendingUnits (decimal ???)
├─ drpepper:VendingUnitSales (monetary)
└─ drpepper:VendingUnitOperatingCosts (monetary)
Result:
├─ 10+ different concept names for same thing
├─ Incompatible data types
├─ Different period types
├─ No analysis possible
└─ Extensions ADD COMPLEXITY, not value
XBRL 2.2 (Never Released):
The idea was to introduce class concepts as a way to manage extensions.
<!-- Base taxonomy defines CLASS -->
<xs:element name="VendingMachineMetrics"
type="xbrli:stringItemType"
abstract="true"
substitutionGroup="xbrli:item">
<annotation>
<documentation>
Abstract class for vending machine-related metrics.
All company extensions MUST extend this class.
</documentation>
</annotation>
</xs:element>
<!-- Company extensions MUST extend the class -->
<xs:element name="VendingMachinesDeployed"
type="xbrli:integerItemType"
substitutionGroup="base:VendingMachineMetrics"
nillable="true">
<annotation>
<documentation>
Number of vending machines deployed (total count).
Extends VendingMachineMetrics class.
</documentation>
</annotation>
</xs:element>
How It Would Work:
1. Regulator defines ABSTRACT CLASSES
└─ VendingMachineMetrics (class)
└─ DigitalRevenueMetrics (class)
└─ EmployeeMetrics (class)
2. Companies MUST extend classes
└─ pepsi:VendingMachinesDeployed extends VendingMachineMetrics
└─ coke:VendorMachinesPlaced extends VendingMachineMetrics
3. Analysts can query by CLASS
└─ "Give me all VendingMachineMetrics"
└─ Returns both Pepsi and Coke concepts
4. Systems can process by CLASS
└─ "VendingMachineMetrics go in database table X"
└─ "VendingMachineMetrics validate as integers"
Example Query:
(: Find all vending machine data across all companies :)
for $fact in //xbrli:*[
@concept-class = 'VendingMachineMetrics'
]
return $fact
Technical Reasons:
XML Schema Limitations
Backwards Compatibility
Governance Complexity
Political Reasons:
Regulatory Resistance
Industry Fragmentation
Practical Reasons:
The SEC Said "No Extensions"
ESEF Said "Anchor or Die"
The Industry Moved to Managed Extensions:
Old Model (Failed):
├─ Companies create extensions freely
├─ Submit filings with extensions
├─ Chaos ensues
└─ Analysis impossible
New Model (Works):
├─ Companies propose extensions
├─ Regulator reviews extensions
├─ Approved extensions added to taxonomy
├─ Next version includes new concepts
└─ Everyone uses same concepts
Examples:
SEC (United States):
- Companies submit extensions
- Extensions must ANCHOR to US GAAP concepts
- SEC reviews for duplicates
- SEC Data Quality Committee (DQC) provides guidance
- Common extensions incorporated in next US GAAP release
ESMA (European Union):
- ESEF requires anchoring to IFRS
- Extensions must link to closest IFRS concept
- ESMA monitors extensions
- Common extensions considered for IFRS
Dutch SBR (Netherlands):
- Companies submit extension requests
- SBR program reviews requests
- Approved extensions added to taxonomy
- Next taxonomy version includes extensions
- Everyone benefits from standardization
SBR = Standard Business Reporting
The Problem SBR Solved:
Before SBR (Netherlands, pre-2013):
Company must file:
├─ Financial statements → Chamber of Commerce
├─ Tax return → Tax Authority
├─ Statistical data → Statistics Netherlands
└─ Regulatory reports → Various agencies
Issues:
├─ Same data entered multiple times
├─ Different formats for each agency
├─ Manual re-keying (errors)
├─ No data reuse
└─ High compliance costs
The SBR Solution:
With SBR (Netherlands, 2013+):
Company files ONCE:
├─ Single XBRL document
├─ Sent to Digipoort (single entry point)
├─ Automatically distributed to:
│ ├─ Chamber of Commerce
│ ├─ Tax Authority
│ ├─ Statistics Netherlands
│ └─ Other agencies
└─ Each agency extracts what they need
Benefits:
├─ File once, satisfy all
├─ Reduced errors
├─ Lower compliance costs
├─ Data reuse across government
└─ Better data quality
Managed Extensions in SBR:
Process:
1. Company needs concept not in taxonomy
2. Company submits extension request to SBR
3. SBR reviews request:
├─ Is concept truly needed?
├─ Does similar concept exist?
├─ Is definition clear?
└─ Will others need this?
4. SBR approves or denies
5. If approved: Added to NEXT taxonomy version
6. All companies can now use standardized concept
Result: Managed evolution, no chaos
Example:
2015: Company requests concept for "Crowdfunding Revenue"
└─ SBR reviews: New business model, legitimate need
2016: Added to taxonomy as "CrowdfundingRevenue"
└─ Standardized definition
└─ Proper linkbase relationships
└─ All companies can use
2017: 50 companies use CrowdfundingRevenue
└─ Comparable data
└─ Meaningful analysis possible
└─ SUCCESS
Compared to Unmanaged:
Unmanaged Extensions (Pepsi/Coke):
├─ Each company creates own concept
├─ Different names, types, semantics
├─ No comparability
├─ No reuse
└─ CHAOS
Managed Extensions (SBR):
├─ SBR reviews and standardizes
├─ Single concept name, type, semantics
├─ All companies use same concept
├─ Full comparability
├─ Reusable across organizations
└─ SUCCESS
Key Benefits:
Quality Control
Standardization
Reusability
Comparability
The SBR Anti-Pattern:
2020: NT (Nederlandse Taxonomie) 2020
├─ Namespace: http://www.nltaxonomie.nl/nt2020/...
├─ VAT Return entry point
├─ Annual Report entry point
└─ Corporate Tax entry point
2021: NT 2021
├─ Namespace: http://www.nltaxonomie.nl/nt2021/...
├─ VAT Return entry point (SAME FORM!)
├─ Annual Report entry point
└─ Corporate Tax entry point
2022: NT 2022
├─ Namespace: http://www.nltaxonomie.nl/nt2022/...
├─ VAT Return entry point (STILL SAME FORM!)
├─ Annual Report entry point
└─ Corporate Tax entry point
2023: NT 2023
├─ Namespace: http://www.nltaxonomie.nl/nt2023/...
├─ VAT Return entry point (UNCHANGED!)
├─ Annual Report entry point
└─ Corporate Tax entry point
The Insanity:
SAME VAT RETURN FORM
SAME CONCEPTS
SAME RELATIONSHIPS
SAME CALCULATIONS
SAME EVERYTHING
BUT:
DIFFERENT NAMESPACE EVERY YEAR
= NEW TAXONOMY EVERY YEAR
= REWORK SYSTEMS EVERY YEAR
Imagine Paper Forms:
2020: VAT Return Form (Yellow paper)
├─ Box 1: Sales
├─ Box 2: Purchases
├─ Box 3: VAT Due
└─ Submit to tax office
2021: VAT Return Form (Purple paper)
├─ Box 1: Sales (SAME!)
├─ Box 2: Purchases (SAME!)
├─ Box 3: VAT Due (SAME!)
└─ Submit to tax office
2022: VAT Return Form (Green paper)
├─ Box 1: Sales (STILL SAME!)
├─ Box 2: Purchases (STILL SAME!)
├─ Box 3: VAT Due (STILL SAME!)
└─ Submit to tax office
Question: Why change the paper color when the form is IDENTICAL?
Answer: NO REASON!
XBRL Equivalent:
Question: Why change the namespace when concepts are IDENTICAL?
Answer: NO REASON!
What IT Must Do Every Year:
Step 1: Download NEW taxonomy
├─ NT 2024 released (November 2023)
├─ Different namespace: .../nt2024/...
└─ Must be implemented by January 2024
Step 2: Update all mappings
├─ accounting:Sales → nt2023:Omzet
└─ accounting:Sales → nt2024:Omzet (REMAP!)
Step 3: Regenerate all schemas
├─ JSON Schema for API
├─ XML Schema for validation
├─ Database schema for storage
└─ ALL different due to namespace change
Step 4: Update all transformations
├─ ERP → XBRL mapping
├─ Accounting system → XBRL mapping
├─ All must use NEW namespace
└─ Code changes required
Step 5: Update all validation rules
├─ Validation engine must load NEW taxonomy
├─ Cache invalidated
├─ New ruleset
└─ Retesting required
Step 6: Update all user interfaces
├─ Forms refer to concepts by namespace
├─ Must update ALL forms
├─ Must update ALL labels
└─ UI changes required
Step 7: Regression testing
├─ Test all integrations
├─ Test all mappings
├─ Test all validations
└─ Test all UI
Step 8: Deploy to production
├─ Before January 1st
├─ Or filings fail
└─ High-pressure deployment
The Cost:
Typical Dutch SME using XBRL:
Annual IT Cost:
├─ Software vendor update: €2,000
├─ Consultant to implement: €5,000
├─ Internal IT time: €3,000
├─ Testing time: €2,000
├─ Deployment downtime: €1,000
└─ TOTAL: €13,000 per year
For what benefit?
└─ ZERO - Form didn't change!
Multiply by 1 million Dutch companies:
└─ €13 BILLION wasted annually
The XBRL Promise:
Invest in XBRL integration:
├─ Year 1: €50,000 implementation
├─ Year 2-10: €5,000/year maintenance
├─ Total 10-year cost: €95,000
└─ ROI: Automation, accuracy, efficiency
The SBR Reality:
Invest in XBRL integration:
├─ Year 1: €50,000 implementation
├─ Year 2: €13,000 rework (new taxonomy!)
├─ Year 3: €13,000 rework (new taxonomy!)
├─ Year 4: €13,000 rework (new taxonomy!)
├─ Year 5: €13,000 rework (new taxonomy!)
├─ Year 6: €13,000 rework (new taxonomy!)
├─ Year 7: €13,000 rework (new taxonomy!)
├─ Year 8: €13,000 rework (new taxonomy!)
├─ Year 9: €13,000 rework (new taxonomy!)
├─ Year 10: €13,000 rework (new taxonomy!)
└─ Total 10-year cost: €167,000
ROI DESTROYED!
The Feedback:
CFO: "Why do we need to update our system every year?"
IT: "Because the taxonomy namespace changed."
CFO: "Did the tax form change?"
IT: "No, it's exactly the same."
CFO: "Then why must we change our system?"
IT: "Because... the namespace changed."
CFO: "That's insane."
IT: "Yes."
The Right Approach:
2020: NT Version 1.0
├─ Namespace: http://www.nltaxonomie.nl/core/...
├─ VAT Return entry point
└─ Version: 1.0
2021: NT Version 1.0 (NO CHANGE - form didn't change)
├─ Namespace: http://www.nltaxonomie.nl/core/...
├─ VAT Return entry point
└─ Version: 1.0 (SAME!)
2022: NT Version 1.1 (Minor change - new optional field)
├─ Namespace: http://www.nltaxonomie.nl/core/...
├─ VAT Return entry point
├─ New optional concept: DigitalServicesVAT
└─ Version: 1.1
└─ BACKWARDS COMPATIBLE
2023: NT Version 2.0 (Major change - restructure)
├─ Namespace: http://www.nltaxonomie.nl/core/2/...
├─ VAT Return entry point (restructured)
└─ Version: 2.0
└─ Migration guide provided
Benefits:
IT Systems:
├─ Only update when form ACTUALLY changes
├─ Backwards compatible for minor changes
├─ Migration support for major changes
└─ Predictable maintenance costs
Companies:
├─ Lower IT costs
├─ Higher ROI
├─ Better XBRL adoption
└─ Willingness to invest
XBRL Has a Versioning Specification!
XBRL Versioning 1.0:
├─ Version reports track changes
├─ Concept changes
├─ Relationship changes
├─ Label changes
└─ Can determine compatibility
Example Version Report:
<ver:versioningReport>
<ver:taxonomyPackage>
<ver:id>NT-Core-VAT</ver:id>
<ver:fromDate>2023-01-01</ver:fromDate>
<ver:toDate>2024-01-01</ver:toDate>
</ver:taxonomyPackage>
<ver:changes>
<!-- No changes for VAT form -->
<ver:unchanged>
<ver:concept>nl:Sales</ver:concept>
<ver:concept>nl:Purchases</ver:concept>
<ver:concept>nl:VATDue</ver:concept>
</ver:unchanged>
</ver:changes>
</ver:versioningReport>
Interpretation:
Version Report says: "NO CHANGES"
Therefore:
├─ Keep same namespace
├─ Keep same version number
├─ No IT changes required
└─ ZERO maintenance cost
Decision Tree:
Did concepts change?
├─ NO → Don't create new version
└─ YES → Did they change semantically?
├─ NO (just labels/docs) → Minor version (1.0 → 1.1)
│ └─ Same namespace
└─ YES (concept meaning changed) → Is it backwards compatible?
├─ YES (added optional concepts) → Minor version
│ └─ Same namespace
└─ NO (removed/changed required concepts) → Major version (1.0 → 2.0)
└─ New namespace
Examples:
Example 1: No Change
VAT form unchanged 2023 → 2024
Action: NO new version
Namespace: SAME
Version: 1.0 → 1.0 (unchanged)
IT Impact: ZERO
Example 2: Label Change
2023: Concept "Purchases" Label "Aankopen"
2024: Concept "Purchases" Label "Aankopen (incl. imports)"
Action: Documentation update only
Namespace: SAME
Version: 1.0 → 1.0.1 (patch)
IT Impact: None (labels stored in taxonomy)
Example 3: New Optional Concept
2023: VAT form has concepts A, B, C
2024: VAT form adds optional concept D (digital services)
Action: Minor version
Namespace: SAME
Version: 1.0 → 1.1
IT Impact: Systems continue to work
Can ignore new optional concept
Or add support when needed
Example 4: Breaking Change
2023: VAT calculation method X
2024: VAT calculation method Y (incompatible)
Action: Major version
Namespace: NEW (version 2)
Version: 1.x → 2.0
IT Impact: Migration required
Version report explains changes
Migration guide provided
US GAAP Gets It Right:
US GAAP 2020:
├─ Namespace: http://fasb.org/us-gaap/2020-01-31
├─ Version: 2020
├─ Concepts: ~15,000
US GAAP 2021:
├─ Namespace: http://fasb.org/us-gaap/2021-01-31
├─ Version: 2021
├─ Concepts: ~15,100 (100 added)
├─ Version report shows:
│ ├─ Added concepts: 100
│ ├─ Deprecated concepts: 50
│ ├─ Modified labels: 200
│ └─ New relationships: 150
└─ Clear migration path
BUT: Most companies can stay on 2020 if no changes affect them
SEC allows prior-year taxonomies for X years
Migration is OPTIONAL for many companies
Key Insight:
US GAAP creates new namespace yearly BUT:
├─ Most changes don't affect most companies
├─ Companies can delay migration
├─ Version reports show exactly what changed
└─ IT can make informed decision: Migrate or not?
SBR Should Do:
NT 2024:
├─ Namespace: SAME as NT 2023 (if no VAT changes)
├─ Version report: "No changes to VAT concepts"
├─ Companies: Continue using same integration
└─ IT cost: ZERO
Per Company (Dutch SME):
Annual Taxonomy Update Cost:
├─ Software vendor update: €2,000 - €5,000
├─ Consultant implementation: €3,000 - €10,000
├─ Internal IT time: €2,000 - €5,000
├─ Testing: €1,000 - €3,000
├─ Deployment: €500 - €2,000
└─ TOTAL: €8,500 - €25,000 per year
Multiply by lifecycle:
└─ 10 years: €85,000 - €250,000
For forms that DIDN'T CHANGE!
National Cost (Netherlands):
1 million companies × €10,000 average
= €10 BILLION per year
= €100 BILLION over 10 years
Wasted on namespace changes.
Reduced Innovation:
Company considering new XBRL integration:
Before knowing about yearly updates:
├─ ROI calculation: 3 years
├─ Net benefit: €50,000 over 5 years
└─ Decision: Invest
After learning about yearly updates:
├─ ROI calculation: Never achieves ROI
├─ Net cost: €20,000 over 5 years
└─ Decision: Don't invest
Result: Innovation stalled
Lower Quality:
Annual Update Pressure:
├─ Must update by January 1st
├─ No time for proper testing
├─ Rush deployment
├─ Higher error rate
├─ Production issues
└─ Bad user experience
Vendor Lock-In:
Only large software vendors can afford:
├─ Annual taxonomy updates
├─ Testing infrastructure
├─ Support organization
└─ Rapid deployment
SME software vendors:
├─ Cannot keep up
├─ Exit market
└─ Reduced competition
What Could Be Done Instead:
€10 billion per year could fund:
Option 1: Eliminate all IT waste
├─ Fix unnecessary namespace changes
├─ Use XBRL Versioning properly
├─ Stable taxonomies
└─ Cost: €0
└─ Savings: €10 billion/year
Option 2: Invest in real improvements
├─ Better validation tools
├─ Better user interfaces
├─ Better documentation
├─ Better training
└─ Transform XBRL adoption
DO:
✅ Managed extensions (good!)
├─ Review extension requests
├─ Standardize concepts
├─ Add to official taxonomy
└─ Everyone benefits
✅ Use XBRL Versioning
├─ Create version reports
├─ Show exactly what changed
├─ Enable informed migration decisions
└─ Reduce unnecessary updates
✅ Stable namespaces
├─ Only change namespace for breaking changes
├─ Keep namespace stable for minor changes
├─ Use semantic versioning
└─ Backwards compatibility
✅ Deprecation periods
├─ Announce changes 12 months ahead
├─ Overlap period (both versions valid)
├─ Migration guides
└─ Support multiple versions simultaneously
DON'T:
❌ Yearly namespace changes for unchanged forms
└─ Destroys ROI, kills adoption
❌ Unmanaged extensions
└─ Creates chaos, prevents analysis
❌ Forced migrations without reason
└─ Wastes resources, frustrates users
❌ Surprise changes
└─ Impossible to plan, high risk
Versioning Strategy:
Version X.Y.Z
X (Major): Breaking changes
├─ Removed concepts
├─ Changed semantics
├─ Restructured relationships
└─ NEW NAMESPACE required
Y (Minor): Backwards-compatible additions
├─ New optional concepts
├─ New optional relationships
├─ Extended enumerations
└─ SAME NAMESPACE
Z (Patch): Non-functional changes
├─ Label changes
├─ Documentation updates
├─ Example fixes
└─ SAME NAMESPACE
Decision Matrix:
Change Type | Version Change | Namespace Change |
─────────────────────────────────────────────────────────────────
No changes | None | No |
Label/documentation only | X.Y.Z → X.Y.Z+1 | No |
New optional concepts | X.Y → X.Y+1 | No |
Deprecated concepts (grace) | X.Y → X.Y+1 | No |
Removed concepts | X → X+1 | Yes |
Changed semantics | X → X+1 | Yes |
Restructured | X → X+1 | Yes |
Defensive Design:
Assume taxonomies change:
├─ Abstract taxonomy references
├─ Configuration-based mapping
├─ Version-aware processing
└─ Support multiple taxonomy versions
Example:
public interface TaxonomyMapper {
Concept map(String accountingCode, String taxonomyVersion);
}
// Not hardcoded:
BAD: concept = "http://nltaxonomie.nl/nt2024/Omzet"
// Configuration-based:
GOOD: concept = config.getConcept("Sales", taxonomyVersion)
Migration Automation:
✅ Automated version detection
✅ Automated migration rules
✅ Automated testing
✅ Rollback capability
✅ Gradual rollout
Multi-Version Support:
Support N and N-1 versions:
├─ 2024 taxonomy (current)
├─ 2023 taxonomy (previous)
└─ Automatic migration between versions
Benefit:
├─ Customers control migration timing
├─ Reduces pressure
└─ Higher satisfaction
Version Report Integration:
✅ Parse XBRL Versioning reports
✅ Show customers what changed
✅ Highlight impacts on their data
✅ Suggest migration strategy
✅ Automate migration where possible
The eXtensible Promise:
Why It Failed:
The XBRL 2.2 Class Solution:
What Worked: Managed Extensions:
What Doesn't Work: Yearly Namespaces:
The Solution: XBRL Versioning:
Lesson 1: Extensions Need Management
Unmanaged extensions = Chaos
Managed extensions = Success
Lesson 2: Namespace Stability Matters
Changing namespace = Breaking change
Breaking changes = High cost
High cost = Low adoption
Lesson 3: Versioning Is a Specification
XBRL Versioning 1.0 exists
Use it!
Lesson 4: ROI Drives Adoption
Predictable costs = Investment
Unpredictable costs = No investment
No investment = No adoption
For Dutch SBR Program:
URGENT CHANGE NEEDED:
1. Stop creating yearly namespaces
2. Adopt semantic versioning
3. Use XBRL Versioning reports
4. Only change namespace for breaking changes
5. Save Dutch companies €10 billion per year
For Other Jurisdictions:
LEARN FROM SBR:
Good:
✅ Managed extensions
✅ Multi-agency coordination
✅ Single point of entry
Bad:
❌ Yearly namespace changes
❌ No version stability
❌ Ignoring XBRL Versioning spec
Do the good, avoid the bad!
XBRL eXtensibility:
Dutch SBR:
The Future:
It's fixable. Fix it.
This document explains why the "eXtensible" promise failed, why managed extensions work, and why the Dutch SBR yearly taxonomy anti-pattern must be fixed.