Belgian Federal Government VenSoc Taxonomy Architecture Guide
Transcription
Belgian Federal Government VenSoc Taxonomy Architecture Guide
Belgian Federal Government VenSoc Taxonomy Architecture Guide Version: 1.5 © 2008 FPS FIN – CONFIDENTIAL VENSOC TAXONOMY ARCHITECTURE GUIDE Table of Contents 1. Document controls..................................................................................................................... 4 DOCUMENT INFORMATION ............................................................................................................................. 4 DOCUMENT VERSIONING ............................................................................................................................... 4 2. Introduction ................................................................................................................................ 5 CONTENT OVERVIEW ..................................................................................................................................... 6 3. Domain model ............................................................................................................................ 7 INTRODUCTION ............................................................................................................................................... 7 REQUIREMENTS OF THE TAXONOMY............................................................................................................. 7 INVOLVED PARTIES AND PROCESSES ........................................................................................................... 9 RELEVANT PROCESSES ................................................................................................................................. 9 REFERENCE AUTHORITIES .......................................................................................................................... 10 DATA SCOPE OF THE TAXONOMY ................................................................................................................ 11 VERSIONING CONSIDERATIONS ................................................................................................................... 12 4. Logical model ........................................................................................................................... 13 INTRODUCTION ............................................................................................................................................. 13 TAXONOMY STRUCTURE .............................................................................................................................. 13 TAXONOMY REFERENCES............................................................................................................................ 13 SCHEMA MODULARITY ................................................................................................................................. 14 LINKBASE MODULARITY ............................................................................................................................... 15 OTHER ASPECTS .......................................................................................................................................... 16 EXTENSIBILITY ............................................................................................................................................. 16 5. Physical model ......................................................................................................................... 17 PHYSICAL COMPONENTS ............................................................................................................................. 17 FOLDER NAMING CONVENTION.................................................................................................................... 20 EXTENDEDLINKROLES ................................................................................................................................ 20 6. Annexes .................................................................................................................................... 21 LEXICON ....................................................................................................................................................... 21 OVERVIEW OF DIMENSIONS ......................................................................................................................... 22 OVERVIEW OF DATA TYPES USED BY THE VENSOC TAXONOMY ............................................................... 24 COPERFIN PROCESSES ............................................................................................................................... 25 © 2008 FPS FIN – CONFIDENTIAL 2 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE PROCESSUS 1 ‘COLLECTER ET GERER DONNEES PERSONNELLES’ ......................................................... 25 PROCESSUS 2 ‘COLLECTER ET GERER DONNEES FISCALES’.................................................................... 26 PROCESSUS 5 ‘CALCULER LES DETTES, CREANCES, RISQUES FINANCIERS OU DROIT DE REMBOURSEMENT........................................................................................................................................ 26 © 2008 FPS FIN – CONFIDENTIAL 3 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE 1. Document controls Document information Document Information Project FPS FIN_XBRL VenSoc File name be-tax-ArchitectureGuide-v1.05_ENG_STIRON Document versioning Date Version Description 20090126 1.5 Draft (This document is not a final version and can be modified) © 2008 FPS FIN – CONFIDENTIAL 4 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE 2. Introduction The VenSoc Taxonomy Architecture guide describes the architecture of the VenSoc tax return taxonomy (hereafter referred to as VenSoc taxonomy). Version 1.0 is the version submitted for validation at the start of the taxonomy design to guide the development of the first version of the VenSoc taxonomy. A public exposure draft version (version 2.0) of this document will be published at the end of the design phase to assist in the refinement of the VenSoc taxonomy in cooperation with external stakeholders. This document is part of a full set of documents that document the VenSoc taxonomy. The full set of documentation consists of: Title Filename Content VenSoc Taxonomy Architecture Guide be-tax-inc-ArchitectureGuide-vxx.doc The purpose of this document is to detail the architecture of the VenSoc taxonomy. VenSoc Taxonomy Style Guide be-tax-inc-StyleGuide-vxx.doc The purpose of this document is to define the styles guidelines to use for defining the concepts in the VenSoc taxonomy. VenSoc Taxonomy Patterns Guide be-tax-inc-PatternsGuide-vxx.doc The purpose of this document is to describe the basic patterns used in the VenSoc taxonomy, including examples and sample taxonomies. VenSoc Taxonomy Preparer Guide be-tax-inc-PreparerGuide-vxx.doc This document provides the necessary guidelines for preparers of tax filings for creating instance documents. (This document is not in scope of the initial design phase) VenSoc Taxonomy Presentation be-tax-inc-Taxonomy-vxx.doc This document presents the full VenSoc taxonomy The file name refers to the document version number (v.x-x). © 2008 FPS FIN – CONFIDENTIAL 5 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE Content overview Chapter 3 – Domain model provides a general overview of domain and covers the following subjects: • The main requirements identified for the taxonomy • The involved parties and processes • A description of the data domain • The organization of concepts • Versioning comments Chapter 4 – Logical model: describes the logical architecture of the taxonomy components. Chapter 5 – Physical model: describes the organisation of the taxonomy in physical files and folders. The annexes contain: Lexicon Overview of dimensions used in the VenSoc taxonomy Overview of data types used in the VenSoc taxonomy 1. 2. 3. © 2008 FPS FIN – CONFIDENTIAL 6 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE 3. Domain model Introduction The domain model describes: 1. the requirements of the taxonomy, 2. the stakeholders and parties involved, 3. the relevant processes at FPS Fin and the submitters, 4. reference authorities to the taxonomy, 5. data scope of the taxonomy, 6. versioning aspects of the taxonomy Requirements of the taxonomy The next table provides an overview of the requirements that have been defined to guide the design of the taxonomy. Requirement Description REQ-01: the taxonomy must be 100% XBRL compliant. The taxonomy must conform to the XBRL 2.1 specification, including the Dimensions, version 1.0 specification. REQ-02: the taxonomy should use business terminology and avoid technical jargon where possible. Terminology that can be understood by a business user should be used and technical jargon should be avoided. REQ-03: the data structure of the taxonomy reflects the full content of the tax return forms in a robust and consistent way. Tax return forms provide valuable insight in the logical structure of the concepts. The goal of the taxonomy is deliver a clear, transparent and consistent data structure to be used by software vendors and preparers to prepare the filings in the most efficient way. This does not necessarily involve the exact reproduction of the current tax return forms. The taxonomy will deliver a clear view however of the concepts used in the respective forms by grouping these concepts in the presentation linkbase REQ-04: the taxonomy should provide support for the front application To assist in the validation of the submission, a clear definition of the concepts and data types must be included in the taxonomy as well as business rules that logic consistency of an instance document. REQ-05: prepare for risk control functions FPS FIN wishes to enhance the risk control processes, allowing more targeted control of the tax returns. This will imply more analytical processing of the tax return data: relations between tax return concepts, aggregations, trends, patterns & data mining, etc. The VenSoc taxonomy should enable the consistency between the main tax return form and the appendices as well as the extended use of the data (from the appendices in particular) for analytical purposes. REQ-06: the taxonomy is aligned with other Where possible and relevant, the taxonomy should be aligned with other Belgian taxonomies, e.g. issued by NBB. © 2008 FPS FIN – CONFIDENTIAL 7 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE Requirement Description taxonomies used in the Belgian jurisdiction REQ-07: the taxonomy must enable software vendors to hide XBRL from end users1. (Take an ‘XBRL Inside’ approach) User friendliness is highly important for the successful market adoption of the taxonomy. The taxonomy should take user friendliness for preparers and submitters into account. REQ-08: the taxonomy should avoid redundancy of concepts. Requesting information only once is a key enabler to reduce the administrative burden for submitters. Redundancy should be avoided through the use of unique tags for equal concepts or referring to other existing taxonomies. REQ-09: contribute to improved collaboration in detection of fiscal and social fraude Improving the fraud detection via improved collaboration between government agencies is a key objective of the policy makers, as described in the “Plan d’action pour mieux lutter contre la fraude” > Bernard Clerfayt. (02/07/2008). This is one of the pillars for the XBRL business case. Collaboration between agencies against fraud depends on the coherence of the information shared, the parties involved and the alignment of processes. The VenSoc taxonomy should enable this by the application of XBRL as open standard for the exchange of information. REQ10: usefulness and userfriendly End users must be able to use the taxonomy in an accessible way. On the one hand this relates to FPS Finance to extend the taxonomy to be used by the internal back office systems, data structures and validation processes. On the other hand this relates to the mapping of the taxonomy to common practice accounting software and accounting practices. REQ11: performance The structural design of the taxonomy impacts the performance of the data processing of the tax filings received from the submitters. A modular design enables the taxonomy to only load those parts of the taxonomy that are relevant for the validation and processing. REQ12: Version control Although a versioning specification has not yet been published by XBRL International, a solid standard for versioning control of the taxonomy is key to manage the changes in respective taxonomies by software vendors and preparers as well as manage the consistency with taxonomies that 1 The definition of ‘end user’ will be part of the preparer guide. © 2008 FPS FIN – CONFIDENTIAL 8 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE Requirement Description are referenced by the VenSoc taxonomy. REQ13: Reusability Reusability is at the heart of the XBRL standard, as XBRL enables the reuse of concepts inside a taxonomy as well as concepts from other taxonomies. The taxonomy should therefore reuse concepts as much as possible. REQ14: Extensibility Extensibility enables the introduction of new concepts to a taxonomy or link additional taxonomies. The design of the taxonomy should reflect the tax domain in a way that the taxonomy can easily be extended to include other parts of the tax domain. The structure and naming conventions used for the taxonomy must enable the extension to other domains. Involved parties and processes The parties involved in the design and refinement of the VenSoc taxonomy are: • FPS Finance; FPS FIN owns the taxonomy. • XBRL Belgium; The ”Platform XBRL Belgium” coordinates the development of XBRL within the Belgian jurisdiction. • National Bank of Belgium; NBB plays a key role within the jurisdiction. NBB is the owner of the [be-frpfs] taxonomy. • Software vendors; software vendors provide software to support the tax return process. • Intermediaries (cijferberoepen) Relevant processes A description of the processes that are related to the VenSoc taxonomy is provided by the Coperfin process book (version 2002). The taxonomy relates to the functional processes of “Taxes & Recovery” in particular. The Coperfin process book describes the to be process architecture, as defined in 2002. Please refer to the annex of this document for a description of the Coperfin processes. Other processes (not described in the Coperfin process book) that could benefit from the use of the VenSoc taxonomy are: • Process performance reporting: monitor the performance of the tax return process (process ratio’s,...). • Distribution of the tax return process result. o Internal reporting o Exchange with the NIS (National statistics office) for (macro)economic analysis. o Exchange with other tax authorities o Etc… Support of these processes is not in scope of the taxonomy. From the perspective of the preparer and submitter of the tax filings, the following processes are relevant: 1. Process – Prepare the tax return This process includes: • the mapping of the taxonomy to the administrative software of the submitter • the basic up-front validations, based on the data scope of the instance document • some input support: multi-lingual value lists,… • the rendering of the (draft) tax return instance © 2008 FPS FIN – CONFIDENTIAL 9 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE The taxonomy supports this process in the data structure of the taxonomy that takes into account the data structures as used by administrative software packages as well as the validation of the data entry by defining strict data types. 2. Process – Submit the tax return This process involves the transmission of the XBRL instance document to FPS FIN. A preparer guide to assist software vendors and preparers in submitting the tax return, will be delivered during the refinement phase. 3. Process – Receive feedback of the tax return processing result This process involves the transmission of feedback messages from government to submitter. A preparer guide to assist software vendors and preparers in submitting the tax return, will be delivered during the refinement phase. Reference authorities The main authority reference for the tax filings is the Income Tax Code (WIB92 or CIR92). This code distinguishes the following income tax categories: Reference Scope French reference Dutch reference Corporate Income Tax Belgian companies, +- 400.000. ISoc VenB Individual Income Tax physical persons IPP PB Income Tax on Legal Entities Belgian legal entities other than “companies”; Mostly non-profit organizations (VZW), +-93.000 IPM RPB Income Tax on non-residents non-residents, includes physical and nonphysical persons; +-13.000 non-physical entities INR/Soc & BNI/Ven & INR/P.P. BNI/Nat . Pers. The scope of the VenSoc taxonomy is limited to Corporate Income Tax. Hereunder an overview of the reference texts, containing the body of knowledge for the said domain. The taxonomy is no authority in its own right; it articulates the concepts, definitions and relationships that are described in the below reference texts, and in a readable format for software applications. French Reference Dutch Reference Description CIR92 – Code des impôts sur les revenus 92 WIB92 – Wetboek van de inkomstenbelastingen 1992 Legal basis for income taxes, thoroughly reviewed in 1992. Main reference authority for [be-tax-inc]. AR CIR92 – Arrêté royal d'exécution du Code des impôts sur les revenus 92 KBWIB92 – Koninklijk besluit tot uitvoering van WIB92 Implementing order of the tax code for income taxes, thoroughly reviewed in 1992. Main reference authority for [betax-inc]. © 2008 FPS FIN – CONFIDENTIAL 10 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE NBB pfs – core taxonomy of the National Bank of Belgium (NBB) NBB pfs – core taxonomy of the National Bank of Belgium (NBB) A number of primary concepts from the NBB core taxonomy can be reused within [be-tax]. [be-tax] will copy the NBB references for these concepts. Data scope of the taxonomy The following concepts are in scope for the VenSoc taxonomy: • Primary concepts required for the tax return. • Dimensional members required for the tax return. • Concepts required for the presentation and structuring of the primary concepts and dimensional members. The following concepts are not in scope: • Concepts required for the exact reproduction of the current tax return forms. e.g. preparer instructions available on the forms. • Specific concepts required for the control and processing of the tax return The concepts to be defined in the taxonomy reflect the basic structure of today’s tax return forms. Hereunder a visual representation of the concept organization. Accounts - Legal reserve - Available reserves - Accumulated profits - Equity - Investment grants 275.1 – Tax return I – Reserves A Taxable reserved profit B Exempted reserved profit II – Disallowed expenses III – Dividends paid Annexes Annexes “Exempted capital gains” 276P Exemption capital gains sea vessels 275B Exemption capital gains river vessels 276N Exemption capital gains corporate vehicles 204.3 Exempted write downs debt claims and provisions risks and expenses 275K Exemption capital gains specific securities 276K Exemption capital gains tangible and intangible fixed assets IV – Breakdown profit 1. Taxable reserved profit 2. Disallowed expenses 3. Dividends paid 4. Fiscal result 5. Deductions 6. Shipping profit tonnage 7. Basic taxable amount V – Separate assessments VI – Diamond traders and tax credit VII – Participation exemption income movable assets VIII – Carry-over allowance corporate equity IX – Tax losses compensation X – Tax rate Annexes “Deductions” 275C Allowance corporate equity 275P Deduction patents 275U Investment deduction 276T Additional personnel 276W1 Additional personnel scientific research 276W2 Additional personnel development technological potential 276W3 Additional personnel head Export department 276W4 Additional personnel head TQM department 275R Investment reserve Tax credit 275W Tax credit research and development Depreciations 328K Degressive depreciation 328L Revocation degressive depreciation XI – Prepayments XII – Clearable advance levies XIII – Tax shelter XIV – Documents, statements ... XV – Financial account number © 2008 FPS FIN – CONFIDENTIAL 11 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE Versioning considerations As to the versioning of the taxonomy, the following aspects have to be taken into consideration: Tax assessment year • The VenSoc taxonomy supports the tax return of corporate income taxes for any tax assessment year. • A tax return version for a given tax assessment year needs to be maintained and supported for as long as 5 calendar years. • Changes to the tax return are not limited or fixed to any date. This means that changes in legislation with regard to any one tax assessment year can alter after year end. • As companies have to file tax filings before June 30th, the taxonomy and accompanying filing infrastructure should be available on March 31th. This enables companies to prepare their tax filings and allows for minimal 1 month to do the actual filing. • Currently around 5% of the VenSoc tax return forms change every year. Also new appendices are added regularly, which in practice take the longest to be published. Alignment with NBB • NBB publishes a preliminary version of the NBB taxonomy for any year in the month of October preceding the calendar year. • NBB publishes a final version of the NBB taxonomy on January 31rst that includes updates in the value lists (e.g. country lists) and the latest legislative changes. • NBB publishes the accompanying software that enables companies to file their annual statements no later than April 1rst. • NBB publishes a yearly taxonomy version, and only supports the latest version (regardless of the accounting period a preparer needs to submit). • The accounting periods of NBB and fiscal periods of FPS FIN are mostly aligned; although there may be exceptions. Alignment with back office systems • FPS FIN is preparing the replacement of the Vensoc application, and is considering to use an XML/XBRL based database. Alignment of versioning is needed between the respective versions of the VenSoc taxonomy and the application data model. • Alignment with software vendors, preparers and submitters. • Software vendors, preparers and submitters must have enough time available to embed the VenSoc taxonomy in their systems and processes. Alignment with developments of XBRL standard on versioning • XBRL International is currently working on a versioning specification to account for changes in taxonomies. This versioning specification is expected to be published before end of 2008. Taking into account these considerations, the first version of the VenSoc taxonomy will address versioning by applying a basic form of versioning that is embedded in the structure of filenames used. Please refer to chapter 5 for the description of this versioning approach. © 2008 FPS FIN – CONFIDENTIAL 12 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE 4. Logical model Introduction This chapter provides an overview of the logical components of the VenSoc taxonomy and how these are related. Please note: the logical model differs from the way the taxonomy is organized in physical files and folders. These are described in the next chapter. • E.g.: the dimensions schema “be-tax-d” in the logical model, will be physically split in a separate schema file (“d-“) per individual dimension. • E.g.: the logical hypercube schema “be-tax-hc” will be physically split in separate files. The physical files and folder structure are described in the physical model (Chapter 5). Taxonomy structure The taxonomy will use the following general description of the domain: • be the taxonomy within the Belgian jurisdiction. • tax the taxonomy belongs to the tax domain. o inc the taxonomy belongs to the income tax subdomain. o vat the taxonomy belongs to the value added tax subdomain (BTW/TVA). Within the be-tax-inc domain, the following sub domains apply: • rcorp Residential CORPorate Income Tax • rind Residential INDividual Income Tax • rle Residential Income Tax on Legal Entities • nrind Income Tax on Non-Resident INDividuals • nrcorp Income Tax on Non-Resident CORPorations This naming convention is key to the physical model of the taxonomy as described in chapter 5. The scope of the VenSoc taxonomy is limited to Residential CORPorate Income Tax (RCORP). This results in the following name of the taxonomy: be-tax-inc-rcorp. Taxonomy references The following external taxonomies are referenced by the VenSoc taxonomy: • XBRL Dimension taxonomy, version 1.0 • NBB taxonomy o The VenSoc taxonomy will not refer to the NBB ”Core” taxonomy, given the limited reusability of these concepts; although a limited number of primary concepts from the NBB core taxonomy will be reused within [be-tax]. [be-tax] will fully copy the NBB concepts. o The NBB ”Data type” schema will be reused by the VenSoc taxonomy. If extension to this schema are needed, NBB agreed to add these to the NBB data type schema to allow for one data type schema for both taxonomies. o The NBB ”Value list” taxonomy will be reused by the VenSoc taxonomy, and extended with be-tax value lists. © 2008 FPS FIN – CONFIDENTIAL 13 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE Schema modularity VenSoc tax return taxonomy (be-tax-inc-rcorp) This schema is the entry point for the VenSoc tax return. • It does not own any concepts, but imports concepts from “be-tax-inc” and “be-tax-hc”. • It contains a definition linkbase: connect the primary concepts imported from the core taxonomy (be-tax-inc) to the hypercubes imported from (be-tax-hc). • It contains a presentation linkbase, structuring the data domain according to the current tax return forms. Core taxonomy (be-tax-inc) Contains all primary and abstract concepts for the income tax domain. Dimension taxonomy (be-tax-d-..) The dimension taxonomy contains all dimensions used. For the VenSoc taxonomy two types of dimensions are distinguished: • Explicit Dimensions: commonly used breakdowns that are applied in several schedules and for several concepts. E.g. Asset type, Investment category. Explicit dimensions have a fixed number of dimension members. • Typed Dimensions: these are used for non-limitative lists, where it cannot be predicted how many rows the submitter needs to declare. E.g. capital gains. Hypercube taxonomy (be-tax-hc-...) Contains the hypercube concepts and imports the required dimension schema’s. © 2008 FPS FIN – CONFIDENTIAL 14 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE GCD taxonomy (gcd) Contains company identification information. Currently owned by NBB. Data type taxonomy The VenSoc taxonomy will adopt the data type schema of NBB. If additional data types are needed, these will be discussed and added to the NBB schema. Please refer to the appendices for an overview of the data types used by NBB and the VenSoc taxonomy. Linkbase modularity Reference linkbases References are provided for the concepts in the core taxonomy (be-tax-inc). Concepts in dimensional taxonomies do not have references in the current taxonomy version; dimensions can be reused in several tax return taxonomies in the future, with potentially different references. Reference characteristics: • Each reference contains the following reference parts: Publisher, Number • Only the “Standard” reference role is used. • Multiple references can be related to one concept (all with Standard reference role). • References are language neutral. Label linkbases Labels are available in 3 languages: Dutch (NL), French (FR) and German (DE). The ‘Standard Label’ role is required for all concepts. Other label roles like ‘Verbose Label’ 2, ‘Terse Label’3, “Period End Label” and “Period Start Label”4 are used when necessary to provide a relevant description of the concept in the presentation linkbase. The “documentation” label role can be used to document the application codes that exist in the current tax return forms, when possible and relevant. Presentation linkbases As the users of the VenSoc taxonomy are familiar with the current paper based or electronic forms, the presentation linkbase in be-tax-inc-rcorp reflects reflects the current forms structure. An extended link is created for each individual form. Since “be-tax-inc-rcorp”; [be-tax-inc-nrcorp]; [be-tax-inc-rle] will currently be the only entry point for the betax domain, no presentation linkbase is added to “be-tax-inc”. This may need to be added when additional entry points will be created. Definition linkbases Definition linkbases are only used for the dimensional taxonomies: • [be-tax-hc-…]: dimension and hypercube definition 2 complete description of the concept 3 a very short description 4 Period Start Label and Period End Label are used for instant type concepts that require a different representation at the beginning and at the end of the period. © 2008 FPS FIN – CONFIDENTIAL 15 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE • • [be-tax-inc-rcorp]; [be-tax-inc-nrcorp]; [be-tax-inc-rle]: connect the primary concepts to the hypercubes. Given the limited reusability, currently no definition linkbase is related to the [be-tax-d-…] schemas. Calculation linkbases Calculation linkbases have not been retained for this version of the taxonomy, due to its limited use. Formula linkbases As the final version of the XBRL Formula specification has not yet been published, formulas are not in scope for the version 1.0 of the VenSoc taxonomy [be-tax-inc-rcorp]; [be-tax-inc-nrcorp] and [be-tax-inc-rle]. Depending the status of the specification this will be reviewed. Other aspects The taxonomy will provide the possibility to include attachments for non-structured annexes, these will be stored in concepts using a data type designed for binary objects5. This capability is required to enable submitters to file signed documents as part of the VenSoc tax returns. As this capability has also been implemented by NBB, the be-tax will follow the NBB approach. Extensibility The VenSoc taxonomy does not require or allow extensions by preparers or submitters. Typed dimensions are used for lists with an unknown number of records (non-limitative lists) and the submitter will have to provide values for those typed dimensions in the instance document. 5 Data type is provided by NBB datatype taxonomy: pfd-dt: nonEmptyBase64BinaryItemType. © 2008 FPS FIN – CONFIDENTIAL 16 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE 5. Physical model Physical components Considering the FRTA file naming conventions and specific needs of the VenSoc taxonomy, the following adjusted file naming structure is defined for the VenSoc taxonomy: • Core taxonomy NamespacePrefix NamespaceIdentifier be-tax-inc http://www.minfin.fgov.be/be/tax/inc/ Files Filename Schema be-tax-inc-<<date of publication>>.xsd Example: be-tax-inc-2008-04-01.xsd Label link base be-tax-inc-<<date of publication>> -label.xml Example: be-tax-inc-2008-07-01-label.xml Presentation link base Not applicable in this version of the taxonomy. Reference link base be-tax-inc-<<date of publication>>-reference.xml Example: be-tax-inc-2008-04-01-reference.xml Definition link base • Not applicable in this version of the taxonomy. Dimensional taxonomy schema’s NamespacePrefix NamespaceIdentifier d-<<name of dimension>> http://www.minfin.fgov.be/be/tax/d/<<name of dimension>> Files File Name Schema be-tax-d-<<name of dimension>>-<<date of publication>>.xsd Example: be-tax-d-eiv-2008-04-01.xsd Comment: typed dimensions are grouped in one singe schema file: be-tax-d-ty-<<date of publication>>.xsd Label link base be-tax-d-<<name of dimension>>-<<date of publication>>-label.xml Example: be-tax-d-eiv-2008-04-01-label.xml Presentation link base Not applicable in this version of the taxonomy. © 2008 FPS FIN – CONFIDENTIAL 17 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE Definition link base • Not applicable in this version of the taxonomy. Hypercube taxonomy schema’s NamespacePrefix NamespaceIdentifier hc-<<name of hypercube>> http://www.minfin.fgov.be/be/tax/hc/<<name of hypercube>> Files File Name Schema be-tax-hc-<<name of hypercube>>-<<date of publication>>.xsd Example: be-tax-hc-eiv-2008-04-01.xsd Label link base Be-tax-d-<<name of hypercube>>-<<date of publication>>-label.xml Example: be-tax-hc-eiv-2008-04-01-label.xml Presentation link base Not applicable in this version of the taxonomy. Definition link base be-tax-hc-<<name of hypercube>>-<<date of publication >>-definition.xml be-tax-dim-eiv-2008-04-01-definition.xml • Corporate tax return taxonomy NamespacePrefix NamespaceIdentifier inc-rcorp http://www.minfin.fgov.be/be/tax/inc/rcorp Files File Name Schema be-tax-inc-<<abbreviation of income tax type>>-<<assessment year>>-<<date of publication>>.xsd Example: be-tax-inc-rcorp-2008-2007-11-01.xsd Label link base be-tax-inc-<<abbreviation of income tax type>>-<<assessment year>>-<<date of publication>>-label.xml Example: be-tax-inc-rcorp-2008-2007-11-01-label.xml Presentation link base be-tax-inc-<<abbreviation of income tax type>>-<<assessment year>>-<<date of publication>>-presentation.xml Example: be-tax-inc-rcorp-2008-2007-11-01-presentation.xml Definition link base be-tax-inc-<<abbreviation of income tax type>>-<<assessment year>>-<<date of publication>>-definition.xml Example: Be-tax-inc-rcorp-2008-2007-11-01-definition.xml © 2008 FPS FIN – CONFIDENTIAL 18 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE • Non-Resident Corporate tax return taxonomy NamespacePrefix NamespaceIdentifier inc-nrcorp http://www.minfin.fgov.be/be/tax/inc/nrcorp Files File Name Schema be-tax-inc-<<abbreviation of income tax type>>-<<assessment year>>-<<date of publication>>.xsd Example: be-tax-inc-nrcorp-2008-2007-11-01.xsd Label link base be-tax-inc-<<abbreviation of income tax type>>-<<assessment year>>-<<date of publication>>-label.xml Example: be-tax-inc-nrcorp-2008-2007-11-01-label.xml Presentation link base be-tax-inc-<<abbreviation of income tax type>>-<<assessment year>>-<<date of publication>>-presentation.xml Example: be-tax-inc-nrcorp-2008-2007-11-01-presentation.xml Definition link base be-tax-inc-<<abbreviation of income tax type>>-<<assessment year>>-<<date of publication>>-definition.xml Example: Be-tax-inc-nrcorp-2008-2007-11-01-definition.xml • Legal Entities tax return taxonomy NamespacePrefix NamespaceIdentifier inc-rle http://www.minfin.fgov.be/be/tax/inc/rle Files File Name Schema be-tax-inc-<<abbreviation of income tax type>>-<<assessment year>>-<<date of publication>>.xsd Example: be-tax-inc-rle-2008-2007-11-01.xsd Label link base be-tax-inc-<<abbreviation of income tax type>>-<<assessment year>>-<<date of publication>>-label.xml Example: be-tax-inc-rle-2008-2007-11-01-label.xml Presentation link base be-tax-inc-<<abbreviation of income tax type>>-<<assessment year>>-<<date of publication>>-presentation.xml Example: be-tax-inc-rle-2008-2007-11-01-presentation.xml Definition link base be-tax-inc-<<abbreviation of income tax type>>-<<assessment year>>-<<date of publication>>-definition.xml Be-tax-inc-rle-2008-2007-11-01-definition.xml © 2008 FPS FIN – CONFIDENTIAL 19 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE Folder naming convention All taxonomy files will be stored in one single folder. Folder name: be-tax-<<version date>> ExtendedLinkRoles In the tax return taxonomy, an extended link is created for each tax return form. It hosts the presentation and definition linkbases for that form. Example of naming convention: • RoleName: rcorp-Form275.1 • Name: rcorp-Form275.1 • Definition: rcorp-Form275.1 An ExtendedLinkRole is created for each hypercube schema. It hosts the hypercube’s definition linkbase. Example: • RoleName: hc-ricg • Name: hc-ricg • Definition: hc-ricg In the current taxonomy version, no ExtendedLinkRoles are created for dimension schema’s: these do not have a presentation or definition linkbase. © 2008 FPS FIN – CONFIDENTIAL 20 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE 6. Annexes Lexicon Term Definition Belastingplichtige Entity submitting the tax return VenB “Vennootschapsbelasting Belgische Ondernemingen”: corporate tax for Belgian companies. Aanslagjaar Assessment year VenSoc taxonomy The full set of taxonomies to support the VenSoc tax tax return. [be-tax-inc-rcorp] Taxonomy specific for tax on corporations [be-tax-inc-nrcorp] Taxonomy specific for tax on non-resident corporations [be-tax-inc-rle] Taxonomy specific for tax on legal entities [be-tax-inc] Taxonomy containing the primary concepts for the income tax domain. Concepts Elements of a taxonomy, could be dimensional or not dimensional Primary concepts Non-dimensional XBRL concepts © 2008 FPS FIN – CONFIDENTIAL 21 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE Overview of dimensions Hereunder an overview of the dimensions that are being used in the current forms used for VenSoc taxonomy: (This list will be refined during the creation of the taxonomy) Dim. Type Name of dimension Explicit BreakdownTotalDimension This dimension contains an explicit member for each typed dimension (supra) Explicit AssetTypeDimension Used for the tax return of capital gains and reinvestments. Explicit CalendarYearDimension Used for the “Additional Personnel” form Explicit DepreciationMethodDimension Used for the “Depreciation” forms Explicit InvestmentCategoryDimension Used for the “Investment deduction” and “Tax credit research and development” forms. Explicit IncentiveCategoryDimension Used for the “Investment deduction” and “Tax credit research development” forms. Dimension members • • • • • • • • • • • • • • • • • • • • • TotalDomain BreakdownMember ReserveOtherTypedTotalMember FixedAssetDegressiveDepreciationTypedTotalMember ReinvestmentTypedTotalMember FixedAssetTangibleIntangibleTypedTotalMember CapitalGainTypedTotalMember TaxableTypedTotalMember ProvisionRiskExpenseTypedTotalMember WriteDownDebtClaimTypedTotalMember EmployeeTypedTotalMember AssetTypeDomain CorporateVehicleMember SpecificSecurityMember RiverVesselMember TangibleIntangibleFixedAssetsMember FixedAssetMember SeaVesselMember CalendarYearDomain CalendarYearAssessmentYear-1Member CalendarYearAssessmentYear-2Member • • • DepreciationMethodDomain DegressiveDepreciationMember RevocationDegressiveDepreciationMember • • InvestmentCategoriesDomain PromoteReutilisationRefillableBeveragePackagesReusable IndustrialProductsMember SecurityDevicesMember EnergySavingsMember PatentsMember ResearchDevelopmentMember SmokeExtractionAirTreatmentSystemsHorecaOutletsMem ber SeaVesselsNonBelgianOriginMember IncentiveCategoryDomain InvestmentDeductionNoTaxCreditResearchDevelopment Member InvestmentDeductionTaxCreditResearchDevelopmentMe mber TaxCreditResearchDevelopmentMember • • • • • • • • • • © 2008 FPS FIN – CONFIDENTIAL 22 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE Dim. Type Explicit Name of dimension EmploymentFunctionDimension Used for the tax return forms related to hiring specific personnel. Explicit EmploymentPeriodDimension Used for the tax return forms related to hiring specific personnel. Explicit TaxPeriodDimension Used for the “Investment reserve” form Dimension members • • • • • • • • • • • • • • • • • EmploymentFunctionDomain DepartmentHeadTQMMember DepartmentHeadExportMember HighlyQualifiedResearcherMember EmployedIncreaseTechnologicalPotentialMember ResearcherMember EmploymentPeriodDomain PersonnelHiredTaxPeriodFullTimeMember PersonnelHiredTaxPeriodFullTimeReplacementMember PersonnelHiredPreviousTaxPeriodFullTimeMember PersonnelHiredPreviousTaxPeriodPartTimeMember PersonnelHiredPreviousTaxPeriodEmploymentEndedMem ber PersonnelFullTimeTransferTaxPeriodMember TaxPeriodDomain TaxPeriodAssessmentYear-1Member TaxPeriodAssessmentYear-2Member TaxPeriodAssessmentYear-3Member Typed AllowanceCorporateEquityTypedDi mension (Non-limitative list) Typed CapitalGainTypedDimension (Non-limitative list) Typed ReinvestmenTypedDimension (Non-limitative list) Typed ReserveOtherTypedDimension (Non-limitative list) Typed FixedAssetDegressiveDepreciationT ypedDimension (Non-limitative list) Typed ProvisionRiskExpenseTypedDimens ion (Non-limitative list) Typed WriteDownDebtClaimTypedDimens (Non-limitative list) ion Typed EmployeeTypedDimension (Non-limitative list) Typed InvestmentTypedDimension (Non-limitative list) © 2008 FPS FIN – CONFIDENTIAL 23 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE Overview of data types used by the VenSoc taxonomy Hereunder an overview of the data types is presented that are being used in VenSoc taxonomy: Data Type Defined by Used in VenSoc Taxono my Explanation Example Monetary14D2ItemType NBB yes Monetary value 14 positions + 2 decimals Standard format for most monetary values nonNegativeDecimal6D1ItemType NBB yes Number of employees in FTE nonNegativeDecimal6D2ItemType NBB yes nonNegativeInteger11ItemType NBB yes Numeric, non negative value 6 positions + 1 decimal Numeric, non negative value 6 positions + 2 decimals Non negative integer value 11 positions nonNegativeInteger1ItemType VenSoc, will be added to NBB data types yes Non negative integer value 1 position, value ranging from 1 to 6 Number of hours, reference numbers nonNegativeInteger6ItemType NBB yes nonNegativeMonetary14D2ItemType NBB yes nonPositiveMonetary14D2ItemType NBB yes Non negative integer value 6 positions Non negative monetary value 14 positions + 2 decimals Non positive monetary value 14 positions + 2 decimals nonNegativeSharesIntegeterItemType NBB yes © 2008 FPS FIN – CONFIDENTIAL Number of employees in FTE Number of hours, reference numbers Zero or more Zero of less Non negative 24 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE number of shares sharesIntegerItemType NBB yes yes Integer number of shares Decimal value 1 position + 4 decimals percentageItemType NBB 0,xxxx, maximum value equals 1 nonEmptyBase64BinaryItemType NBB Yes Binary large objects pdf document Coperfin processes Processus 1 ‘Collecter et gérer données personnelles’ Raison d’être Le processus ‘collecter et gérer données personnelles’ sert à identifier tous les contribuables (potentiels) et à rassembler leurs données ‘personnelles’, correctes et actuelles, et à les structurer dans un dossier unique. A cet effet, on tient compte des directives générales relatives au dossier unique telles qu’elles sont définies aux niveaux N-1 et N-2. Le processus ‘collecter et gérer données personnelles’ vise également à réunir toutes les données disponibles au sein et en dehors du SPF Finances qui sont relatives à ces contribuables (personnes physiques, morales, associations de fait,…) et à les gérer. Ainsi, ce processus permet également aux autres processus de mieux suivre les droits et obligations du contribuable. Alors que le processus ‘collecter et gérer données fiscales’ et ‘collecter et gérer données préavis d’arriv. et déclarations’ sont axés sur les données relatives à la situation fiscale et non fiscale d’un contribuable, le processus ‘collecter et gérer données personnelles’ se concentre sur les données relatives au contribuable en personne. Ce sont ces données qui aideront spécifiquement à déterminer la meilleure méthode d’interaction dans toutes ses formes, eu égard aux caractéristiques du contribuable. Le processus englobe la création initiale du dossier unique en termes de contenu. C'est la raison pour laquelle on tient compte de la collecte de données essentielles pour les prestations de services, la vérification et le recouvrement lorsque l’on met sur pied ce processus. Comme l’utilisation de ces données s’étend au-delà du SPF, on contrôle également dans le cadre de ce processus, la qualité des données. Lors d’inconsistances, un signal est envoyé au propriétaire des données. Les principaux objectifs de ce processus visent à : - Identifier tous les contribuables potentiels (et les autres catégories de citoyens /entités pertinentes) - Organiser le rassemblement de ces données en fonction du principe de ‘fourniture unique de données’ - Réunir ces données personnelles dans un dossier unique dont les principes sont respectés dans tout le SPF Finances - Obtenir ou entrer toutes les données nécessaires par la voie électronique - Veiller à un rassemblement de données aussi exhaustif et correct que possible afin qu’il n’y est pas de distorsion dans les résultats des analyses réalisées dans le cadre des processus ‘compréhension des clients’ et ‘gestion des risques’ sur la base de ces données. - Etablir les relations correctes entre les différents contribuables/entités afin d’obtenir une vue globale et exacte (p.ex. famille, relations entre les PME, fonctions au sein de PME /GE) © 2008 FPS FIN – CONFIDENTIAL 25 / 26 VENSOC TAXONOMY ARCHITECTURE GUIDE - Renforcer l’accessibilité de l’administration en désignant un account manager/poste de travail (responsable en premier ligne de la gestion d’un certain dossier) Processus 2 ‘Collecter et gérer données fiscales’6 Raison d’être Le processus ‘collecter et gérer données fiscales’ sert à : - obtenir toutes les informations relatives à la situation fiscale d’un contribuable identifié (informations rassemblées par l’administration elle-même, informations récoltées sur base des déclarations, informations récoltées après réaction du contribuable) - structurer après validation des exigences de forme, les informations dans un dossier unique. - détecter des anomalies objectives et les résoudre. Il s’agit d’anomalies que l’on n’a pas détectées lors d’une vérification de la situation fiscale mais qui visent à corriger de manière objective les éléments fiscaux. (p.ex. % de déduction des frais de restaurant) - traiter les litiges/contentieux susceptibles d’en découler. Processus 5 ‘calculer les dettes, créances, risques financiers ou droit de remboursement7 Raison d’être Le processus ‘calculer les dettes, créances, risques financiers ou droit de remboursement’ sert à calculer le montant dû ou à rembourser pour tous les types d’impôts (séparément) et d’indiquer comme montant dû par ou pour le contribuable. Pour certaines impôts le montant est incorporé dans le bilan de synthèse qui établit un aperçu de l’ensemble des obligations financières entre les administrations et les contribuables et en effectue le suivi. Les principaux objectifs de ce processus visent à : - Tenir à jour un relevé complet des droits et obligations fiscales du contribuable par le biais d’un historique complet et correct des interactions financières proactives avec ce contribuable. - Calculer correctement les impôts (inclus les impôts régionalisés), les droits, droits de magasin, amendes et rétributions et attribuer ceux-ci à la personne qui a l’obligation de s’en acquitter - Calculer correctement les risques financiers (par ex. : le calcul de la garantie à déposer dans le cas d’importation temporaire D&A) 6 Remarque : dans le cadre de ce processus ne seront pas uniquement traités les impôts directs et la TVA mais également les taxes de circulation avec signe distinctif fiscal, les taxes de circulation sans signe distinctif fiscal, appareils automatiques de divertissement, eurovignettes, jeux et paris, précomptes immobiliers. 7 Remarque : dans le cadre de ce processus ne seront pas uniquement traités les impôts directs et la TVA mais également les taxes de circulation avec signe distinctif fiscal, les taxes de circulation sans signe distinctif fiscal, appareils automatiques de divertissement, eurovignettes, jeux et paris, précomptes immobiliers. © 2008 FPS FIN – CONFIDENTIAL 26 / 26