extensible Business Reporting Language (XBRL)

Transkript

1 extensible Business Reporting Language (XBRL) Tidsspilde eller merværdi? Af Rune Lind, Seniorkonsulent, SAS Institute Vi er stadig i en recession, som har varet overraskende længe, og der gøres mange tiltag for at undgå, at den gentager sig. Et af disse tiltag er Kapitalkravsdirek-tiverne (CRD IV) samt COREP/FINREP-rapporterne, som pengeinstitutter i EU er pålagt at aflevere, for at nationale og europæiske finanstilsyn bedre kan monitorere pengeinstitutternes helbred. I mit egoistiske verdensbillede er det mest interessante ved disse rapporter nok, at EU har besluttet, at rapporterne skal afleveres ifølge XBRLstandarden Extensible Business Reporting Language. En nørdet person som jeg, som synes, at XMLskemaer og transformationer er spændende at arbejde med, kan virkelig få sin lyst styret ved at arbejde med XBRL. XBRL tager standard-xml (dvs. XML-dokumenter med XML-skemaer), anvender udvidelsen XLINK og tilføjer en række nye XMLbaserede begreber såsom arcs, linkbases, value assertions, interval arithmetic m.m. Resultatet er en gang XML så omfattende, at man ofte stirrer målløs på skærmen og spekulerer på, hvordan det overhovedet er muligt at bruge så mange filer og elementer, bare for at udtrykke f.eks. A = B + C. Taksonomien til COREP og FINREP består af over filer! Kan det virkelig bruges til noget? Og hvis det kan, hvordan får man så styr på taksonomien, så man kan generere korrekte XBRL-rapporter? I denne artikel drøfter jeg udfordringerne forbundet med at anvende XBRL og den fremgangsmåde, jeg personligt foreslår, nemlig at bygge en flerdimensionel model, der så at sige bygger bro mellem kildedata, forretningen og XBRL-taksonomien. Behov for en ny rapportstandard Men måske skal vi lige gennemgå, hvorfor der overhovedet er behov for en standard for at udveksle rapporter såsom COREP/FINREP-rapporterne. Svaret ligger i, hvem eller hvad der skal læse rapporterne. Når den administrerende direktør i en virksomhed beder salgschefen om de seneste salgstal, så er det stadig ofte noget med at sende et Excel-regneark med en . Medmindre virksomheden er kommet ind i det 21. århundrede, og den administrerende direktør bare åbner sin Visual Analytics-rapport(!) Men Excel-rapporter og webbaserede rapporter er jo kun gode til at give en visuel fremstilling på en skærm, som en person kan se og forstå. Når rapporterne skal forstås af en maskine (f.eks. med det formål at læse tallene ind i en database), må der andre løsninger på banen. Mange af os har sikkert prøvet at importere et Excel-regneark i et program, og måske har regnearkets forfatter givet en celle grå baggrund, overstregning af teksten, samt en kommentar, hvor der står Bare se bort fra denne celle. Forstår en maskine den slags ting? Overhovedet ikke. Den celle bliver indlæst på lige fod med alle andre, og resultatet er noget rod. XML er en fin løsning på dette, eller rettere: XML er et fint format til udveksling af rapporter på tværs af organisationer. Finanstilsynet kan sende et XMLskema ud, som dikterer, hvordan indholdet af XMLrapporten skal være. Så kan programmer både skrive og læse indholdet. Dejligt så er den prut slået, eller hvad? Tja, XML-skemaer kan diktere strukturen og til dels også indholdet af XML-dokumenter, men de indeholder ingen standard for at beskrive koncepter

2 såsom aktiver, passiver, aktier, valutaer osv., eller mulighed for at beskrive sammenhængen mellem disse, og sådan noget som valideringer (f.eks., at aktiver = passiver eller forælderelementet er lig med summen af sine børn) er der ikke noget af. Hvad er så løsningen? Taksonomi og DPM Løsningen er XBRL-taksonomien. Det er i hvert fald blevet foreslået, og i løbet af de sidste 10 år er XBRLtaksonomien vundet frem i mange dele af verden. Når jeg hører ordet taksonomi, tænker jeg umiddelbart på biologi og klassifikation af dyr, og der er da også mange ligheder. I dyreriget betegner vi en edderkop som et dyr af typen spindler, fordi nogle biologer har bestemt at sådan er det bare det er vi blevet enige om at gøre. På samme måde kan et beløb i en XBRL-rapport beskrives ud fra en række domænemedlemmer, fordi taksonomien er blevet dikteret fra EU vi heldigvis alle er enige om at bruge de samme betegnelser. Når man afleverer et XBRL-dokument, angiver man også inde i dokumentet, hvilken taksonomi det hører til, og dermed ved modtageren, hvordan indholdet skal læses. Det svarer lidt til, at en edderkop går rundt med et skilt på ryggen, som angiver, at den skal klassificeres ud fra International Code of Zoological Nomenclature og derfor er en spindler. Hvis man modtager et Excel-regneark, hvor der står Antal kunder: , så ville det jo være rart at vide, hvilken definition af Kunde, som er anvendt. XBRL- taksonomien løser dette problem, eller formindsker det i hvert fald betydeligt, ved at ethvert XBRL-dokument selv indeholder referencer til taksonomien og definitioner. En XBRL-taksonomi som COREP/FINREPtaksonomien indeholder koncepter, dimensioner, metrikker (dvs. målbare elementer), relationer kaldet arcs som f.eks. dimensionshierarkier, hierarkier for kolonner og rækker i rapporter og meget andet godt. Her er der altså mulighed for at beskrive mere end bare tekniske elementer, men også forretningsmæssige og økonomiske koncepter kan defineres. Dejligt, tænker man så, indtil man indser, at taksonomien til COREP/FINREP består af over XML-filer med referencer på kryds og tværs samt en Microsoft Access-database, som svarer til taksonomien, men beskriver strukturerne på en anden måde. XML-filer har en tendens til at være lidt omstændelige, når de anvendes til at beskrive sammenhænge mellem elementer, og XBRL har samme problem, bare langt, langt værre. Lad mig komme med et eksempel. Eksempel på beløb, som skal rapporteres Som en del af kapitalkravsdirektivet CRD IV skal man bl.a. rapportere sine urealiserede gevinster og tab samt summen af disse. Helt konkret skal disse tre beløb angives i den første kolonne, række 100, 110 og 120 i skema C Når man skal aflevere disse beløb, som beskrives som tre celler i en tabel, hvordan finder man så ud af, hvordan dette beskrives i et XBRL-dokument? Jo, man slår selvfølgelig op i XML-filen c_05.01-labcodes.xml og finder de XLINK-labels, som har arcrole " og værdierne 010 (kolonnen) og 100 -, og 120 -rækkerne. Man ser så, at der er en XLINK-label med værdien 010 med label label_eba_c Ordet label kunne få én til at tro, at det er en etiket for elementet. Men nej, det er faktisk en identifikator for den pågældende XLINK-label, og en XLINK-label er - i denne sammenhæng - en egenskab eller et attribut ved det egentlige element (som jeg slet ikke er nået til endnu). I samme XML-fil finder vi så en såkaldt arc, altså et XML-element, som binder to andre elementer sammen. Vi finder en arc, som linker fra et element med label loc_eba_c19505 til vores label med labelen label_eba_c Labelen loc_eba_c19505 henviser til en såkaldt locator, som altså angiver, hvor det element, som locator lokaliserer, kan findes, og vi ser, at elementet har HREF c_05.01-rend.xml#eba_c19505, hvilket vil sige, at elementet kan findes i filen c_ rend.xml med identifikatoren eba_c Vi åbner således filen c_05.01-rend.xml og finder elementet med ID eba_c19505.

3 UDSNIT AF COREP XBRL-TABELDEFINITION Her i filen c_05.01-rend.xml kan vi så se, at elementet med identifikatoren eba_c19505 er en såkaldt Table RuleNode, og at noden indeholder tre Formula Concepts. Det første formula concept henviser til metrikken eba_met:mi243, det næste til, at dimensionen eba_dim:bas har værdien eba_ba:x11, og det tredje formula concept angiver, at dimensionen eba_dim:tof har værdien eba_of:x2. Siger det dig ikke lige noget, at eba_dim:tof er lig med eba_of:x2? Det kan jeg egentlig godt forstå. Man skal selvfølgelig slå op i filen dim_lab_en.xml for at se, at eba_dim:bas henviser til dimensionen Transitionally treated as in Own Funds og at værdien eba_of:x2 betyder CET1 Capital. Hvis du er tekniker som jeg, så ved du måske ikke lige, hvad CET1-kapital er for noget, og XBRL giver dig ikke nogen hjælp. Du må i gang med at google. Men nu ved du da, hvilken metrik og hvilke dimensionsværdier du skal skrive i dit XBRLdokument, altså hvilke tags dine beløb skal have, når du vil angive kolonne 010 og række 100 i skema C Eller rettere, det ved du faktisk ikke, for vi har kun kigget på kolonnen 010. Der er også en dimensionsværdi tilknyttet rækken 100, og desuden er der jo sammenhængen mellem denne celle og de underliggende, som vi slet ikke har nået, og valideringer har vi ligeledes ikke haft fat i, ligesom vi mangler at tænke på enhed (valuta), antal decimaler, periode/tidspunkt, organisatorisk enhed, solo/koncern osv. osv. Ovenstående lange smøre skal illustrere, at bare det at komme fra én celles værdi til XBRL-definitionen for den værdi går ad en lang vej gennem mange XMLfiler. SAS Institutes løsning indlæser og fortolker naturligvis de nødvendige dele af taksonomien, så metadata ligger klar til, når der skal genereres XBRLdokumenter. Dette gør processen langt lettere. Og det skal også nævnes, at European Bank Authority leverer en database, DataPoint Model (DPM), som indeholder mange af de samme informationer, som kan fås fra de mange XML-filer, og vores løsning anvender også dele af denne database, når det giver mening. XBRL-taksonomien og DPM-databasen stemmer godt overens, men man skal være opmærksom på deres forskellige udgangspunkt. Men uanset, hvordan man fortolker og anvender taksonomien, må konklusionen dog være, at COREP/FINREP-taksonomien er en meget omstændelig måde at beskrive værdier på. Hvor man kan specificere urealiserede tab og gevinster i én sætning, bruger XBRL-taksonomien mange forskellige filer, elementer, links og labels for at beskrive det samme, og hvis man foretrækker at anvende DPM-modellen, er det stadig mange tabeller, rækker og fremmednøgler, man skal have fat i. XBRL er ikke designet med simplificering som mål.

4 Hvorfor XBRL? Men hvorfor skal vi så egentlig anvende XBRL? Hvad er formålet med at gå over til dette rapporteringsformat? Ja, ét mål er jo ganske enkelt: Rapporter skal kunne læses af en maskine. En PDF-rapport f.eks. kan laves, så den ser vældig nydelig ud, men den er jo ikke velegnet til at blive læst af et computerprogram. Et andet mål er at knytte tags til værdier og beløb, som gør, at værdierne kan placeres og anvendes i hierarkier, hyperkuber og andre strukturer, som så kan anvendes til analyse. At have et beløb stående i kolonne 10, række 100 i en tabel i Excel fortæller i sig selv ikke noget om, hvordan det beløb kan nedbrydes eller summeres med andre eller på anden måde anvendes i forskellige sammenhænge til analyse. Ved at omsætte tabel-, kolonne-, række- og evt. slicer-værdier til dimensionelle værdier kan beløbet indgå i en struktur, hvorpå man kan slice and dice, dvs. udtrække forskellige analyser. En af tankerne med XBRL var at give virksomheder et sæt tags, hvormed de kunne tagge deres beløb omtrent som stregkoder i supermarkedet, og dermed anvende dem til analyse. Sagen er dog, at sådan anvender de fleste virksomheder ikke XBRL. Langt de fleste udtrækker data fra deres systemer i lige præcis det omfang, som det er nødvendigt for at kunne generere XBRLrapporter. De føler ikke behov for at tilføje nye attributter til alle deres data og ser måske taggingen som et nødvendigt onde. Og hvis det kun er enkelte værdier (og især beregnede værdier), som tildeles tags som vist foroven, så får man da heller ikke meget gavn af dem. De hierarkier, som f.eks. findes for dimensionerne i taksonomien, altså beskrivelser af, hvilke værdier som summer op i totaler, får man jo ikke gavn af, hvis man kun har hentet og tagget 2 ud af 7 værdier i et hierarki, og man henter og tagger kun 2 værdier, hvis COREP kun kræver 2 værdier. Altså ender man med en OLAP-kube (eller hyperkube, som det kaldes i taksonomien) med kun sporadisk udfyldte beløb i kuben, og den kan der hverken summes, slices eller dices på. Så er både COREP og FINREP reduceret til en rent teknisk øvelse, som er tidskrævende og let kan resultere i fejlagtige afleveringer. I SAS anbefaler vi, at man opbygger en model, som kan inkorporere de nødvendige dimensioner og hierarkier fra COREP/FINREP XBRL-taksonomien. Det skal ikke nødvendigvis være en 1:1- implementering af COREP/FINREP-taksonomien, for mange af taksonomiens dimensionsmedlemmer kan man nøjes med blot at mappe til på det tidspunkt, hvor XBRL-rapporterne skal genereres. Men når man har opbygget en model, f.eks. i SAS Financial Management, som er ideelt til formålet, kan den model så at sige bygge broen mellem medarbejdernes velkendte syn på forretningen og de hierarkier og sammenhænge, som COREP/FINREPtaksonomien foreskriver. Man kan let til- og fravælge hierarkier og niveauer i sin model for at få overblik og forståelse for taksonomiens struktur, så man kan føle sig tryg og sikker på, at beløbene giver mening, når tallene skal afleveres. Selve genereringen af XBRLdokumenterne kan så naturligvis ske med SAS XBRL-generator. Konklusion XBRL og COREP/FINREP-taksonomien kan altså være mere end blot en sur tjans, man skal igennem. Hvis man opbygger en robust model i SAS Financial Management til at binde forretningen og taksonomien sammen, kan man aflevere sine XBRLrapporter uden blot at håbe på, at tallene er rigtige, men have ro og selvtillid igennem hele processen fra kildedata til XBRL-dokumenter. Valideringer og konsistens i ens rapporter behøver ikke at være noget, man skal bruge de sene aftentimer på for at opnå, men det opnås som en naturlig del af ens dataflow. Jeg synes, at det er meget spændende at arbejde med XBRL hos mine kunder. XBRL er kommet for at blive i en årrække i hvert fald, og det vil et hvilket som helst kryds d. 25. maj nok ikke ændre noget ved. Der er absolut fordele i at få opbygget solide modeller til brug ved COREP og til FINREP for at binde forretningen sammen med taksonomiens væld af arcs, concepts, assertions og andre spændende, temmelig nørdede, komponenter. Læs om softwareløsninger til business intelligence og business analytics på

5