2.1 Opprinnelsen av XBRL og XML

For å forstå XBRL i noe mer detalj er det nødvendig å trekke de lengre linjene og knytte det opp mot øvrig teknologiutvikling. Det var tilbake på 70-tallet at SGML* Standard Generalised Markup Language (SGML) ble etablert som ISO 8879 først i 1986. ble utviklet, en standard som definerte overordnede krav og spesifikasjoner for merkespråk til bruk i en tekstfil* Med tekstfil menes her «plain text»-filer hvor standarder som Unicode UTF-8 og ASCII brukes for å representere tegn ut ifra datamaskinens binære datapunkt («character encoding»). Selv om XHTML er et tekstfilformat, åpner Base64 for å inkorporere bilder direkte i XHTML-filen, noe som benyttes i utstrakt grad i ESEF-rapporter (Baker, 2021).. Merking åpnet for å knytte metadata til data i et elektronisk format, ved bruk av blant annet merker og attributter. Som et eksempel kan et tall (data) merkes som inntekter for et spesifikt år (metadata). Å bruke tekstfiler til å lagre data på en strukturert måte var god utnyttelse av datamaskinens begrensede ressurser i en tid da lagring og overføringskapasitet var vesentlig mer kostbart enn det vi er vant med i dag. Fortsatt den dag i dag er tekstfiler en sentral del av den digitale verden.

For å sette SGML inn i en kontekst er det hensiktsmessig også å nevne HTML i korte trekk. Filformatet HTML er godt egnet til overføring og gjengivelse («rendering») av nettsider, og en sentral byggesten i utviklingen av internett. Mens SGML setter de overordnede rammene for merkespråk, er HTML-standarden en anvendelse av SGML, som blant annet beskriver merker og attributter som er mulige å bruke, og hvilken funksjon de skal ha.

Målet med standardisering er ofte å gjøre praksis mer ensartet. Ved å etablere en HTML-standard skulle alle nettlesere kunne lese en HTML-fil og gjengi nettsiden på samme måte («interoperabilitet»). Bruken av HTML utviklet seg imidlertid ikke helt heldig ved utbredelsen av internett på 90-tallet. Standarden ble ikke alltid etterlevd, og det ble utviklet proprietære løsninger for de enkelte nettleserne fremfor å følge en universell standard* Dette ble til dels også gjort bevisst. Som en konsekvens av konkurransen mellom nettlesere («browser wars»), ble merkene ikke alltid tolket på samme måte, og nettlesere hadde også egne merker og varianter av eksisterende merker. De gjeldende standardene ble også snilt tolket av nettlesere, slik at også HTML-filer med feil og mangler ble forsøkt gjengitt av nettlesere.. Mangelen på ensartet praksis bidro trolig til at HTML ikke var like aktuell for lagring og overføring av data. Den oppdaterte HTML-standarden er bedre etterlevd i dag, men det er fortsatt en fleksibel og mindre streng standard, og nettlesere vil aktivt forsøke å rette opp og gjengi feilaktig kode i HTML (Ferrara, 2025) (Anderson, 2004).

Siden SGML er en forholdsvis generell standard, som blant annet inneholder flere valgalternativer, ble det ansett nødvendig med et strengere alternativ. Særlig for lagring og overføring av data er det mindre hensiktsmessig med fleksibilitet og valgalternativer fordi IT-applikasjoner da ikke nødvendigvis håndterer data på samme måte. Som en underkategori av SGML ble «Extensible Markup Language» (XML) utviklet, med færre valgalternativer og strengere struktur- og innholdskrav. Etter hvert er det blitt enda flere merkespråk, som kan organiseres i en form for familietre, hvor SGML er «mor» og XML en underkategori (Ferrara, 2025)* Extensible Markup Language (XML) 1.0 vedlikeholdes av World Wide Web Consortium, forkortet W3C..

Tilsvarende SGML, og i motsetning til HTML, definerer ikke XML hvilke elementer eller attributter som kan brukes for å merke data, men setter de overordnede rammene gjennom noe strengere regler enn SGML. For å anvende XML til et spesifikt formål må formålet dermed begrense hvilke merker og attributter som kan brukes. Det kan gjøres gjennom utarbeidelse av et XML-skjema* «XML Schema Definition» (.xsd)., hvor tillatte merker og attributter er definert (W3C, 2004).

Mot slutten av 1990-tallet, i kjølvannet av utviklingen av XML, ble det tatt initiativ til utvikling av en global standard for elektronisk rapportering. Initiativet kom opprinnelig fra miljøet rundt American Institute of Certified Public Accountants (AICPA)* Revisoren Charles Hoffman nevnes som grunnleggeren av XBRL, men utviklingen ble innen kort tid del av et større miljø., men ble etter kort tid trukket ut gjennom etableringen av den globale organisasjonen XBRL International i 1999. Dette som følge av at ambisjonen om å utvikle en global standard, ikke passet inn i AICPA med USA som et mer lokalt nedslagsfelt (Waldt, 2004)* I 2009 ble XBRL Europe etablert som en selvstendig organisasjon med fokus på prosjekter i Europa..

Organisasjonen utviklet grunnlaget for dagens XBRL 2.1-spesifikasjon. Gjennom spesifikasjonen defineres hvilke merker og attributter som kan brukes som metadata, og hvilken funksjon de skal ha. Spesifikasjonen er implementert i et XML-skjema som er inkludert i appendiks til XBRL 2.1. For at noen skal kunne legge ned påstand om et dokuments etterlevelse av XBRL, eksempelvis finansregnskapet i en årsrapport, må dokumentet dermed både etterleve XBRL 2.1-spesifikasjonene og XML 1.0* Et dokument som etterlever XML 1.0 sies å være «well-formed», mens ved etterlevelse av det spesifiserte skjemaet er dokumentet også «valid».. Standarden sikrer på denne måten et konsistent format for utarbeidelse og utveksling av finansiell data, som gjør at data effektivt kan utveksles direkte mellom IT-applikasjoner, inkludert til investorer og myndighetsorgan (XBRL International, 2013).

2.2 Fra XML og XBRL til HTML/XHTML og Inline XBRL

EU vurderte XBRL basert på XML som ett av flere alternativ i kost-nytte-analysen tatt inn i høringsdokumentet* Lovgiver påla ESMA å utføre en kost-nytte-vurdering blant annet for å kompensere for at konsekvensanalyse ikke ble gjennomført i forkant av lovvedtaket (ESMA, 2015).. Siden XML først og fremst er tilpasset maskinell behandling, blir da XML-filen et supplement til det menneskelesbare filformatet. Hvis brukerne da skulle bli usikre på om de to separate filene var identiske eller ikke, ville de fort valgt den filen de hadde mest tillit til, noe som hadde gjort den andre filen overflødig (ESMA, 2015).

Da US SEC innførte elektronisk rapportering, var det i første omgang XBRL basert på XML, og dermed to separate filer. Enkelte undersøkelser viste at brukerne ikke alltid hadde full tillit til den maskinlesbare rapporten, og at de derfor la mer vekt på den menneskelesbare rapporten. Det dukket også opp påstander om at utstederne bevisst rapporterte XBRL-filer av lav kvalitet, med formål å undergrave US SECs mandat om innføring av elektronisk rapportering, blant annet gjennom unødig bruk av selskapsspesifikke merker («extensions»). Uten brukernes tillit blir den maskinlesbare rapporten overflødig, så rapporteringskvalitet i alle steg er avgjørende (Harris & Morsfield, 2012).

Siden løsningen med to separate filer hadde enkelte ulemper, ble en undergruppe av XBRL utviklet, som ble navngitt Inline XBRL. I Inline XBRL inkorporeres den maskinlesbare XBRL-dataen i et format som er bedre egnet for menneskelig lesbarhet, hvor filformat som HTML eller XHTML brukes i stedet for XML. I stedet for to filer er det altså kun én fil som inneholder både den maskinlesbare og den menneskelesbare rapporten. Som beskrevet i Inline XBRL 1.1-spesifikasjonen, må den maskinlesbare XBRL-rapporten kunne trekkes ut av filen på en slik måte at den etterlever kravene i XBRL 2.1. Som vil vises senere i artikkelen, er metadata inkludert i den samme filen som også gir en menneskelesbar rapport, men «gjemt» på en slik måte at det ikke påvirker hvordan en nettleser vil gjengi den menneskelesbare rapporten* Nettlesere gjengir ikke XBRL-metadata som ligger som XBRL-elementer. Det er kun selve innholdet som blir gjengitt av nettleserne, og dermed synlig i den menneskelesbare rapporten. (XBRL International, 2013).

En av fordelene ved XML er at det åpner for en nøstet struktur («nesting»). Ved å plassere elementer inni hverandre etableres en hierarkisk struktur som skaper relasjoner mellom data. Eksempelvis gjøres dette i SAF-T-rapporter, ved at data tilhørende den enkelte bokføring «nøstes» sammen med bokføringsnummeret, inkludert beløp, konto og bokføringsdato. Denne løsningen er ikke like hensiktsmessig når data skal kunne gjengis som en menneskelesbar rapport av en nettleser. Derfor er konseptet «linkbase», som er en annen tilnærming for å etablere disse relasjonene, særlig viktig for Inline XBRL. Det gjør det mulig å gjenskape årsrapporten i riktig format, også maskinelt, samtidig som man bevarer utstedernes fleksibilitet rundt utformingen av årsrapporten.

2.2.1 Hvorfor XHTML?

De fleste kjenner godt til HTML som et format til bruk i nettlesere for gjengivelse av nettsider. Som beskrevet ovenfor, er HTML en forholdsvis fleksibel standard, og nettlesere vil forsøke å gjengi nettsider selv om den underliggende HTML-filen inneholder feil. Siden dette gir noe risiko for at HTML-filer ikke tolkes konsistent på tvers av IT-systemer, er det ikke et godt egnet format for datalagring og -overføring. Da er de strengere reglene i XML bedre egnet.

XML er imidlertid ikke et godt egnet grunnlag for en menneskelesbar rapport. Derfor legger Inline XBRL opp til bruk av filformatet XHTML, som i tillegg til å etterleve HTML-standarden også etterlever de strengere kravene i XML-standarden. XHTML kan derfor leses av en nettleser og gjengi en menneskelesbar rapport, på samme måte som en nettside kan gjengis basert på en HTML-fil. Sammenlignet med ordinære HTML-filer vil derimot en nettleser ikke forsøke å rette opp og gjengi feilaktig kode i XHTML. Nettleseren vil heller stoppe umiddelbart og gi en feilmelding hvis dokumentet inneholder syntaksfeil (XBRL International, 2013).

2.3 Taksonomi

De tekniske spesifikasjonene XBRL 2.1 kan noe forenklet sagt anses som et rammeverk som må fylles med innhold* I artikkelen er «facts» slik det er definert i XBRL, oversatt til «innhold».. XBRL gir de grunnleggende byggestenene som skal være felles for alle rapporter basert på XBRL, inkludert strukturer, merker, attributter og datatyper. XBRL er imidlertid ikke tilstrekkelig til å kommunisere finansiell rapportering i seg selv. For å få i stand en rapport må også attributtverdier fra regnskapsspråket inkluderes, samt den finansielle dataen fra selskapet (XBRL International, 2026).

Taksonomien reflekterer en definert regnskapsstandard og bygger videre på XBRL-rammeverket for klassifisering av innholdet. En programvare som skal lese en XBRL-rapport, vil kunne finne og håndtere data basert på XBRL-spesifikasjonen, men det er taksonomien som definerer hvilken regnskapslinje eller -note som tallet eller teksten hører til.

Tilsvarende som for XBRL, er også taksonomier definert i et skjema som definerer hvilke merker og attributter som kan benyttes. XBRL åpner imidlertid for bruk av selskapsspesifikke merker («extensions»), for å ta høyde for tilfeller som faller utenfor de områdene som er definert av taksonomien (XBRL International, 2026).

I høringsprosessen til de tekniske standardene ble det diskutert hvorvidt ESEF skulle åpne for selskapsspesifikke merker. Erfaringene fra US SEC, hvor unødig bruk av selskapsspesifikke merkinger reduserte sammenlignbarheten mellom selskap, trakk i retning mot ikke å åpne for dette. Man falt imidlertid ned på at fleksibiliteten innebygd i IFRS tilsa at det burde være tillatt. Tiltak ble etablert for å forebygge de potensielle ulempene, herunder «ankring» til nærmeste IFRS-merking, samt krav om tredjeparts bekreftelse av revisor (Harris & Morsfield, 2012) (ESMA, 2025).

ESMA oppdaterer taksonomien på årlig basis ved å oppdatere den delegerte kommisjonsforordning (EU) 2018/815. EU-kommisjonen vedtar denne gjennom delegert myndighet (RTS). ESEF-taksonomien er i stor grad basert på IFRS-taksonomien utgitt av IASB, som har eksistert i lengre tid. IASB utarbeidet det første utkastet allerede i 2002, og det ble etter hvert videreutviklet som et delprosjekt under paraplyprosjektet «disclosure initiative» (Ramin & Prather, 2003).

2.3.1 Eksempel på merking

Et eksempel kan være nyttig for bedre å forstå hvilke roller XBRL-teknologien og taksonomien har ved merking av finansiell informasjon. I stedet for å åpne XHTML-filen i en nettleser, som gir en menneskelesbar rapport, kan filen åpnes som ren tekst i et enkelt tekstredigeringsprogram, eksempelvis gjennom Microsoft Notisblokk. Da ser man hvordan filen er oppbygd, og dermed hvordan XBRL åpner for effektive søk på enkeltelementer i finansregnskapet.

I illustrasjonen ovenfor er XBRL-element fra to rapporter hentet ut. Selv om eksemplene er fra forskjellige jurisdiksjoner og regnskapsspråk, er strukturen stort sett lik. Den viktigste forskjellen ligger i «name»-attributtet. Hvilken verdi denne attributten kan ha, defineres av taksonomien fra regnskapet.

Som nevnt ovenfor, vil en nettleser ikke gjengi alle merkene og attributtene i en Inline XBRL-fil. Det er kun innholdet som vil fremkomme i den menneskelesbare rapporten. XHTML-filen vil også bestå av øvrige merker og attributter fra HTML og CSS, som blant annet definerer hvor innholdet skal plasseres og hvordan det skal se ut i den menneskelesbare rapporten, men som ikke faller under XBRL-standarden.

3.1 Primæroppstillingene – «ix:nonFraction»

Etter bearbeiding av filen kan ønsket data hentes ut blant annet ved søk på elementer og attributter. I illustrasjonen nedenfor er rapportert innhold for «Revenue», både for rapporteringsperioden og sammenligningstall, hentet ut og lagret som en liste i et nytt objekt. Listen kan så skrives ut for å vise hvert element i listen. Ønsker man kun å vise innholdet og ikke tilhørende metadata, kan kommandoen «get_text()» legges til. I begge tilfeller er verdiene lagret og vist som ren tekst («string») og må derfor bearbeides før maskinen kan håndtere innholdet som en numerisk tallverdi.

Elementene i illustrasjonen ovenfor viser ikke all relevant data. Eksempelvis årstall, som knytter innholdet til rapporteringsperioden eller sammenligningstallene, vises ikke i elementet. Dette skyldes ikke programmet, men hvordan XBRL-rapporten er utformet. For å unngå dataredundans, hvor samme data gjentas unødig gjennom XHTML-filen, samles enkelte data i en separat seksjon i filen* Elementene markert med ix:resources og ix:references inneholder data som ikke skal gjengis av en nettleser i den menneskelesbare rapporten, men som en maskin behøver for å tolke data. Nettleseren skal ikke gjengi denne dataen i den menneskelesbare rapporten, noe som kan oppnås eksempelvis ved å legge til «div style=none» før elementet., inkludert årstall. I stedet for å oppgi rapporteringsperioden for hvert element, inneholder attributten «contextRef» en henvisning til denne separate seksjonen, hvor data om årstall ligger.

Å hente ut data på denne måten kan virke tungvint, særlig sammenlignet med det å finne tallet i den menneskelesbare rapporten. Nytteverdien kommer imidlertid til syne ved egendefinerte analyser og sammenligninger på tvers av selskap og bransjer, som må gjentas ved jevne mellomrom. Gjennom en eksisterende kildekode, gjerne kombinert med API for nedlasting av ESEF-rapporter, vil den samme øvelsen kunne gjentas jevnlig, uten å være særlig ressurskrevende.

Med egendefinerte analyser gis regnskapsbrukeren mulighet til å strukturere data på en måte som dekker regnskapsbrukernes informasjonsbehov, eksempelvis ved å gjøre analyse på forholdstall eller å sette opp egne delsummer og resultatmål.

I illustrasjonen beregnes en rentabilitet basert på «Profit or Loss». Enkelte foretrekker imidlertid et annet rentabilitetsmål enn regnskapsmessig egenkapitalavkastning. Andre resultatmål, eksempelvis driftsresultat eller (adjusted) EBITDA etter investeringer, vurdert mot sysselsatt kapital, kan for enkelte være et mer ønskelig informasjonsgrunnlag. Rentabiliteten vurderes så mot et avkastningskrav for å vurdere virksomhetens lønnsomhet.

Det er imidlertid en utfordring at resultatmål som ikke er definert av IAS 1, ikke nødvendigvis er konsistente på tvers av selskap og bransjer. Når det gjelder APM-er, eksempelvis (adjusted) EBITDA, vil de ofte ligge utenfor finansregnskapet, og dermed ikke være gjenstand for krav til merking. Begge disse ulempene gjør at det maskinlesbare formatet, slik det foreligger nå, ikke nødvendigvis dekker behovet til disse brukerne. Håpet er at implementeringen av IFRS 18, med nye krav til resultatmål, vil kunne forebygge noen av disse ulempene. Mer om dette senere.

3.2 Noteinformasjon – «ix:nonNumeric» og «ix:continuation»

I motsetning til primæroppstillingene hvor alle tall merkes i detalj, krever ESEF kun blokkmerking av notene. For at XHTML-filen også skal kunne brukes til å gjengi en menneskelesbar rapport, må XBRL-elementene deles opp i flere deler i blokkmerkingen. Dette for å gi rom til XHTML-elementer som blant annet skal definere stil og struktur i den menneskelesbare rapporten, inkludert tekststørrelse, tabeller, skrifttype, farger og avsnitt. Disse elementene faller utenfor XBRL-standarden* I motsetning til filings hos US SEC som må etterleve strenge format- og stilregler, har det i Europa vært tradisjon med særegne format på årsrapportene, gjerne med utstrakt bruk av bilder, farger og tekststiler. Problemstillingen med blokkmerking er derfor mindre hos US SEC enn under ESEF (XBRL International, 2024)..

For å hente ut noteinformasjon kan man ta utgangspunkt i samme funksjoner fra «BeautifulSoup» som ovenfor. Men som illustrasjonen ovenfor viser, vil man da kun hente ut første del av noten.

For å sette hele noten i blokkmerkingen sammen i et maskinlesbart format, er det mulig å legge til en iterasjon til «BeautifulSoup»-funksjonen, som setter delene sammen* Ved å bruke verdiene i attributtene «continuedAt», som vil være «Id»-attributten til neste del, kan delene knyttes sammen maskinelt. Det første XBRL-elementet i en blokkmerket note har startmerket «ix:nonNumeric», mens de resterende delene har startmerket «ix:continuation».. På denne måten opprettes et objekt bestående av en liste med alle delene av noten som gjør at man kan hente frem de delene av noten man måtte ønske, eventuelt vise hele noten maskinelt. I illustrasjonen nedenfor er derimot hver enkelt del hentet direkte fra filen, i stedet for å sette dem sammen i en fullstendig liste.

I illustrasjonen er to elementer fra noten skrevet ut. Av det første elementet ser man at ren tekst kan gjengis maskinelt med samme struktur som i den menneskelesbare rapporten. Det andre elementet viser derimot at tabeller ikke nødvendigvis gjengis på en god måte. Dataen leses maskinelt inn som ren tekst, til tross for at det er presentert i den menneskelesbare rapporten som en tabell med tall. Årsaken er at selve strukturen i den menneskelesbare rapporten ikke defineres av XBRL-elementene, men av XHTML-elementene. Dette er en konsekvens av blokkmerking på tabeller, i stedet for detaljert merking* US SEC krever detaljmerking av tall i tabeller i noter (SEC, 2009)..

For å bevare tabellstrukturen ved bruk av maskinlesbar data, må XHTML-elementene inkorporeres i kildekoden. Det er fullt mulig å gjøre det, men siden tabeller kan settes opp på ulike måter* Forskjellen på strukturelle elementer og presentasjonselementer, samt ESMAs anbefaling knyttet til valget, beskrives senere i artikkelen., vil det være vanskelig å skrive kildekode som håndterer dette konsistent. Siden XHTML-elementene ikke dekkes av XBRL-standarden, vil standarden ikke sikre at utstederne gjør dette på samme måte. Den infrastrukturen som skal åpne for effektiv bruk av teknologiske verktøy, gjennom en bred obligatorisk merking med standardiserte krav, vil da mangle (XBRL International, 2024).

Estimater er en god måte å eksemplifisere dette på. En regnskapsbruker kan ønske å sammenligne forutsetninger og sensitiviteter, eksempelvis for nedskrivningsvurderinger eller bransjespesifikke estimater. Ved å bruke XHTML-merkingen som ligger i filen, er det mulig å gjenskape tabellen. Men så lenge tabellene ikke er satt opp med samme type XHTML-element, samt at forutsetningene ikke er konsistent merket eller navngitt, blir det krevende, tilnærmet umulig, å skrive en kildekode som alltid håndterer dataen på riktig måte på tvers av enheter. Da blir det vanskelig å gjennomføre en slik sammenligning maskinelt på en mer effektiv måte enn ved bruk av den menneskelesbare rapporten (ESMA, 2024) (XBRL International, 2024).

Denne ulempen er uheldig da bruken av tabeller ofte er en hensiktsmessig måte å kommunisere informasjon på i en menneskelesbar rapport. Dette ble også lagt vekt på i IASBs rapport om «Better Communication in Financial Reporting» fra 2017, hvor det ble oppmuntret til økt bruk av tabeller og illustrasjoner for å kommunisere informasjon i regnskapet. At viktig informasjon derfor ligger i tabellene, og ikke i notens øvrige tekst, er derfor rimelig å legge til grunn. Også ESMA anerkjenner at det på området er noe motstridende mål (ESMA, 2016).

Når man ser de klare ulempene med blokkmerking, er det legitimt å stille spørsmålet om merking av noteinformasjonen virkelig gir regnskapsbrukerne en nytte som overstiger utstedernes kostnader. For utsteder er det trolig vesentlig mer ressurskrevende å merke noteinformasjonen enn det er å merke tallene i primæroppstillingene. Det gjøres sjelden større endringer på strukturen i primæroppstillingene, mens noteinformasjonens innhold og omfang endres fra år til år.

At noteinformasjonen er viktig for regnskapsbrukerne, er det imidlertid liten tvil om. Gjennom IASBs arbeid med standardsetting ser det stort sett ut til at brukerne av regnskapet, inkludert investorer, heller ønsker mer enn mindre noteopplysninger. Det er derfor forståelig når ESMA krever merking av noteinformasjon, fordi det er nødvendig for at brukerne skal få en full forståelse for et selskaps situasjon, også gjennom et maskinlesbart format (ESMA, 2015).

Samtidig må det legges vekt på at blokkmerking er fornuftig ved at det reduserer ressursbruken for utstederne, til sammenligning med detaljert merking. Det er også verdt å merke seg at det ikke virker å være konsensus rundt hva som er den mest egnede tekniske løsningen for noteinformasjon, i motsetning til primæroppstillingene hvor det er forholdsvis stor grad av enighet rundt beste løsning. Det sees derfor på løsninger for hvordan man kan videreutvikle merkingen av noter, noe som vil beskrives senere i artikkelen.

3.3 Bruk av Namespace

Som illustrert i de to foregående avsnittene, kan spesifikk data hentes ut direkte fra XHTML-filen. Det er imidlertid også fullt mulig å hente ut all maskinlesbar XBRL-data i sin helhet. Inline XBRL-dokumentet inneholder i praksis en fullstendig maskinlesbar rapport* I XBRL definert som et «target document» (XBRL International, 2022). som etterlever kravene i XBRL 2.1-spesifikasjonen. Denne maskinlesbare rapporten er imidlertid spredt utover i XHTML-filen, innimellom XHTML-elementer.

Å hente ut den maskinlesbare rapporten kan gjøres ved å bruke «namespace»-funksjonen innebygd i XML. For XBRL-element brukes blant annet prefikset <ix:, eksempelvis <ix:nonFraction og <ix:nonNumeric. Denne prefikset gjør det mulig å skille element knyttet til XBRL fra øvrige element i XHTML-filen, og kan dermed brukes til uthenting av ønsket data, også ved bruk av «BeautifulSoup».

På samme måte vil alle elementer der name-attributtet knyttes til IFRS-taksonomien ha prefiks «ifrs-full:, eksempelvis ‘<ix:nonFraction name=”ifrs-full:Revenue” id=”fact-3…’. Det gjør det mulig å hente ut all data merket med den definerte taksonomien, men også mulig å skille taksonomier hvis det blir brukt flere. Hvilke muligheter det gir, beskrives noe mer under «XBRL også for ikke-noterte selskaper».

4.1 Merking av noter

ESMA har notert seg utfordringene knyttet til merking av noteinformasjon, og de ser at brukerne ikke har vært i stand til å utnytte merket noteinformasjon fullt ut. I et høringsnotat offentliggjort i 2024* «Feedback statement» er ennå ikke offentliggjort. er ett av formålene* Det primære formålet med høringsprosessen virker å være merking av bærekraftsinformasjon. å se på hvilke løsninger som finnes på disse utfordringene. Et godt utgangspunkt er å forstå hva merket noteinformasjon er og kan bli brukt til (ESMA, 2024).

I 2024* Siden særegne format på årsrapportene er vanligere i Europa enn hos US SEC-selskap, ble utfordringene med blokkmerket noteinformasjon tydeligere etter at obligatorisk merking av noteinformasjon under ESEF trådde i kraft. offentliggjorde XBRL International et notat som blant annet identifiserte ulike bruksområder for blokkmerket noteinformasjon. Bruksområdene omfattet isolert gjengivelse av enkeltnoter («isolated rendering»)* Isolert gjengivelse gjør det mulig å sammenligne noter side om side. XBRL er imidlertid tydelig på at det å beholde stilen på noten, inkludert bilder og illustrasjoner, ikke er et mål ved maskinell bruk av data, inkludert ved isolert gjengivelse., økte muligheter for søk og orientering («navigation and highlighting»), automatisert tekstanalyse* Ren tekst kan være nyttig input for ulike typer analyser, eksempelvis semantisk analyse, «data mining» og «natural language processing» (KI). og grunnlag for fullstendighetstest («Disclosure check list»* Utfordringen med en maskinell fullstendighetssjekk av noteopplysningene er å ta høyde for selskapets vurdering av vesentlighet, samt at noteinformasjonen skal være selskapsspesifikk og ikke generell. /«Disclosure indicator»). ESMA har i høringsnotatet inkludert denne informasjonen når de ser på alternativer for videre utvikling (XBRL International, 2024) (ESMA, 2024).

Endelig utfall av høringsprosessen kan potensielt medføre større endringer, eksempelvis krav til mer detaljert merking av noter. I mellomtiden har ESMA gjort enkelte tiltak for å gjøre rapportene, og særlig tabeller i noter, mer egnet til bruksområdene beskrevet ovenfor. Slik kravene er i dag, er det mulig å benytte både «strukturelle elementer», som <table>, og «presentasjonselementer»* For en XHTML-fil utarbeidet på grunnlag av en ordinær PDF vil presentasjonsmerking være egnet for å gjenskape en menneskelesbar rapport tilsvarende den ordinære PDF. Til sammenligning vil XHTML-filer utarbeidet direkte fra årsoppgjørssystemet i større grad bruke strukturelle merker., eksempelvis <span> og <div>, for å få en nettleser til å gjengi en tabell i den menneskelesbare rapporten. For maskinell bruk er de strukturelle elementene mer hensiktsmessige for å bevare eksempelvis tabellstrukturen. At disse benyttes i stedet for «presentasjonselementer», anbefales nå av ESMA, men over tid kan det fort bli et krav (ESMA, 2025).

Mens ESMA vurderer alternativer, kan det også være fornuftig for utstederne å se på hvilke muligheter som finnes for å gjøre den maskinlesbare rapporten mer tilgjengelig og nyttig for brukerne. At utstederne i større grad forutsetter at regnskapet også skal kunne leses av en maskin, ikke bare av personer, kan bidra til å påvirke hvordan notene utformes.

Det er heller ikke forbud mot detaljmerking av noteinformasjon, inkludert tabeller. Men uten et obligatorisk krav kan det imidlertid ikke forventes at alle detaljmerker på frivillig basis. Det vil begrense brukernes mulighet for sammenligninger på tvers av selskap og bransjer, som vil være en av de viktigere bruksområdene for maskinell bruk av detaljmerket data. Da spørs det om ressursbruken gir tilstrekkelig nytte til å forsvare kostnaden.

4.2 APM – Nye krav etter IFRS 18

At alternative resultatmål (APM) stort sett ikke merkes, eventuelt bare blokkmerkes, ble trukket frem som en klar ulempe i høringssvarene tilbake i 2016* Som påpekt i høringssvar, inkludert 88 svar fra organisasjoner i Frankrike, tar IFRS-taksonomien ikke høyde for APM.. Den utstrakte bruken av APM tilsier at det foreligger et vesentlig informasjonsbehov som ikke dekkes av resultatmålene definert av IFRS. Både egenkapitalinvestorer og långivere ser ut til å ønske mer eller annen type informasjon enn den de får av resultatmål definert av IFRS. Derfor er det ikke utenkelig at enkelte investorer fortsatt vil ha behov for databehandlere, for å få informasjonen fra APM-er på et mer anvendelig elektronisk format (EFRAG, 2014).

ESMA anerkjenner APM-er som en informasjonskilde som supplerer resultatmål definert av IFRS. Det har derfor ikke vært ønskelig med et forbud, men det er gjort tiltak for å sikre at informasjonen ikke misleder brukeren eller tilslører («obscure») vesentlig informasjon* Det refereres til ESMAs veiledning «Guidelines on Alternative Performance Measures (2015)».. Praksis er imidlertid ikke fullt ut ensartet, både med tanke på valg av APM, samt måling og presentasjon av disse. APM-er ligger derfor ikke i et rammeverk som er godt egnet for merking og digital rapportering (ESMA, 2015).

ESMA trakk imidlertid frem at ESEF ikke begrenser merking av APM, og at det er fullt mulig å bruke egendefinert merking («extensions»), samt detaljert merking som alternativ til blokkmerking. Også her vil en slik frivillig løsning trolig ikke være en god løsning. Uten et obligatorisk krav kan det ikke forventes at alle detaljmerker, noe som igjen begrenser brukernes mulighet for sammenligninger på tvers av selskap og bransjer (ESMA, 2016).

IASB forventer at implementeringen av IFRS 18 «Presentation and Disclosure in Financial Statements» vil bidra til forbedret digital tilgang til finansiell informasjon. Viktige relevante resultater inkluderer mer ensartet praksis rundt presentasjon, flere obligatoriske resultatmål og et rammeverk for «Management Performance Measures» (MPM)* Resultatbaserte APM-er som er «...subtotal of income and expenses...». (IFRS 18.117).. I denne sammenheng er rammeverket for MPM, en viktig underkategori av APM, spesielt viktig. Det sikrer at MPM blir del av regnskapet, samt at MPM i note må avstemmes mot nærmeste resultatmål definert av IFRS. Dette gir en standardisert tabell godt egnet for merking og digital rapportering (IFRS 18.123 (c)) (IFRS® Foundation, 2024).

IASB har i taksonomien for 2025 inkludert detaljerte merker som kan benyttes for merking av MPM-tabellen, i tillegg til den ordinære blokkmerkingen. Hvorvidt ESMA vil kreve detaljert merking av tabellen, er fortsatt uklart. Her er det imidlertid gode muligheter for å forbedre regnskapsbrukers mulighet til maskinell behandling av denne dataen. For å forstå hvordan slik detaljert merking kan fungere, er det mulig å se på hvordan egenkapitaloppstillingen merkes i dag* XBRL 2.1 er supplert med standarden «XBRL Dimensions 1.0» som definerer hvordan seksjonene under <segment> og <scenario> skal brukes. For å gjenskape rekkefølgen i tabellstrukturen, må også linkbase trekkes inn. (IFRS® Foundation, 2025).

4.3 XBRL også for ikke-noterte selskaper

Som beskrevet innledningsvis, så EU-kommisjonen for seg en bredere innføring av rapportering i tråd med XBRL, som ikke var begrenset til utstedere. En bred innføring kunne vært et godt bidrag til EUs ambisjon om at informasjon kun må rapporteres én gang, selv om det skal brukes til flere formål og av ulike myndighetsorgan («once-only principle»). Flere kjenner seg nok igjen i at dagens rapporteringskrav for næringslivet tidvis er overlappende, så her er det rom for forenklingstiltak for næringslivet.

XBRL åpner for at generell rapportering av regnskapsinformasjon kan suppleres med ytterligere XBRL-data, for å dekke et særskilt rapporteringsformål. Denne supplerte dataen må ikke nødvendigvis reflekteres i den menneskelesbare rapporten, men kan også bare være tilgjengelig gjennom maskinell uthenting. Da kunne myndigheter heller krevd at XBRL-data ble supplert med den dataen de måtte ha behov for, eventuelt med en separat taksonomi, slik at de kunne hentet data gjennom API-spørringer på regnskapsregisteret, i stedet for å kreve separat rapportering. Dermed ville selskap kunne dekket flere rapporteringskrav med én rapport og én innsendelse, noe som ville redusert ressursbruken både hos selskapene og brukerne, samt redusert risikoen for feilaktig rapportering (XBRL International, 2025).

Selv om EU ikke innførte et bredere krav til rapportering etter XBRL, er det fullt mulig for medlemsstatene å gjøre det på eget initiativ. Kostnadene ved en slik innføring ville ikke nødvendigvis vært så høye, da regnskapslovens oppstillingsplan kunne støttet en forholdsvis sømløs innføring av merking av primæroppstillingene. Det finnes flere land som på eget initiativ har innført dette i nasjonal lovgivning, og man skal ikke lenger enn til Danmark for å se et eksempel på mulighetene en slik innføring kan gi (XBRL International, 2022).

4.4 Krav til merking av øvrig periodisk rapportering

Kravet til elektronisk rapportering er begrenset til årsrapporten. Den lovpålagte halvårsrapporten, samt eventuelle kvartalsrapporter, er ikke gjenstand for tilsvarende krav. Til sammenligning krever US SEC XBRL-merking av både kvartals- (10-Q) og årsrapportering (10-K), i tillegg til tilsvarende merkingskrav for enkelte andre rapporteringsforpliktelser til markedet (SEC, 2009).

For en regnskapsbruker som skal bruke informasjon fra periodisk rapportering til kortsiktig gevinst, er det avgjørende at informasjonen fra utsteder gjøres tilgjengelig på et elektronisk format ved første offentliggjøring. Siden kvartalsrapportene ikke merkes, og de fleste velger å offentliggjøre en rapport for fjerde kvartal i god tid før selve årsrapporten offentliggjøres, vil informasjonen være tilgjengelig i markedet før den elektroniske rapporteringen offentliggjøres. Det innebærer at denne type investorer fortsatt må belage seg på å bruke den menneskelesbare kvartalsrapporten, for å kunne gjøre investeringsbeslutninger så snart informasjonen gjøres tilgjengelig i markedet.

Samtidig er det viktig å huske på forskjellen mellom informasjon som er nyttig for investorer, og informasjon som klassifiseres som innsideinformasjon. Etter klassisk økonomisk teori er kun prissensitiv informasjon ansett som nyttig informasjon. Det finnes imidlertid grunnlag for å påstå at denne distinksjonen blir for streng. Selv om finansregnskapet gir nyttig informasjon, særlig ved å gi en strukturert sammensetning av finansiell informasjon, er det ikke nødvendigvis innsideinformasjon. Eventuell innsideinformasjon som blir kjent gjennom regnskapsavslutningsprosessen, vil i mange tilfeller uansett måtte offentliggjøres før regnskapet er klart, i tråd med den løpende informasjonsplikten etter «Market Abuse Regulation (MAR)* Innsideinformasjon skal offentliggjøres så fort som mulig (artikkel 17, 1. ledd (596/2014)). Selv om det finnes unntaksregler i form av utsatt offentliggjøring, er det verdt å merke seg at tilfellene listet opp i ESMAs «Mar Guidelines on delayed disclosure» ikke inkluderer utsatt offentliggjøring av informasjon oppdaget under regnskapsavslutningsprosessen. Hvorvidt dette burde vært inkludert ble diskutert særlig hos FCA UK (se eksempelvis «Primary Market Bulletin 52» og «Technical Note 506.2»). (EFRAG, 2014) (Barker, Hendry, Roberts, & Sanderson, 2012).

Hvis lovgivers intensjon er at maskinlesbar informasjon skal være nyttig for investorer, bør det forventes at kravet på et tidspunkt utvides til øvrig periodisk rapportering. Det er noe krevende å forstå bakgrunnen for at det er viktigere at notene i årsrapporten merkes, enn at kvartalsrapportene merkes.

4.5 Kunstig intelligens – «XBRL is dead»

Det er vanskelig å unngå temaet kunstig intelligens (KI) ved vurdering av veien videre for XBRL og ESEF. Det er liten tvil om at kunstig intelligens vil få stor betydning for hvordan brukere innhenter og bearbeider finansiell informasjon. Det er imidlertid viktig å være bevisst at KI bygger på sannsynlighetsregning, noe som innebærer risiko for feil og hallusinering, særlig ved ny type informasjon i ny form.

Hvilke konsekvenser KI vil ha for XBRL og ESEF, ser ut til å dele seg i to overordnede perspektiv. Det ene perspektivet forventer at XBRL og ESEF kommer til å bli overflødig og unødvendig. Etter hvert som KI utvikles, skal informasjon kunne hentes ut og behandles på en effektiv måte med tilstrekkelig lav risiko, uten at informasjonen presenteres i et strukturert format. Et slikt syn tilsier at offentliggjøring i PDF skal være tilstrekkelig. I podkast-episoden med det treffende navnet «XBRL is dead» argumenteres det langt på vei for at dette er en reell mulighet.

Det andre perspektivet legger også til grunn at KI vil få stor betydning. Forskjellen er imidlertid troen på at teknologi leverer bedre resultat på et strukturert og organisert data- og informasjonsgrunnlag. Daglig leder i XBRL International beskrev dette med en treffende analogi: «AI without structured data is like a self-driving car without roads, maps and experience on the road. It might get somewhere, but not where you want to go» (XBRL International, 2025).