ISO 21926

Semantic data model for audit data services

The Audit Data Collection ISO 21378:2019 defines the functional requirements for exchanging audit data in flat file tables. In line with the development of a subsequent new version of ISO 21378:2019, the study group ISO TC 295 SG1 proposes the definition of a development framework consisting of the following components: 1.Developing a semantic data model; 2.Developing a logical/hierarchical data model based on the semantic data model; 3.Developing exchange formats based on the logical/hierarchical data model. This new work item proposal concerns the development of a semantic data model (which is part 1 of the framework).

Titre manque

General Information

• Status: Not Published
• ICS: 03.120.20 - Product and company certification. Conformity assessment
• ICS: 35.240.99 - IT applications in other fields
• Technical Committee: ISO/TC 295 - Audit data services
• Drafting Committee: ISO/TC 295 - Audit data services
• Current Stage: 6000 - International Standard under publication
• Start Date: 29-May-2026
• Completion Date: 30-May-2026

Overview

ISO 21926: Semantic data model for audit data services is an international standard developed by ISO Technical Committee 295 to define a unified methodology and framework for building semantic data models tailored for audit data services (ADS). The primary goal of this standard is to enable consistent, standardized exchange and extraction of audit data, regardless of underlying systems or technologies. This supports integration, interoperability, and clarity among diverse stakeholders, such as auditors, auditees, IT professionals, and software developers.

By leveraging a semantic data model, organizations can bridge the gap between business needs and technical implementations, ensuring audit data is accessible, structured, and reusable. This facilitates efficient audits, compliance with regulatory requirements, and robust data governance across industries.

Key Topics

• Multi-layered Semantic Modelling
  The standard introduces a layered modelling framework:

  • Foundational Semantic Model (FSM): Establishes the core data architecture and definitions.
  • Business Semantic Model (BSM): Customizable to specific regional, jurisdictional, or industry requirements.
  • Logical Hierarchical Model (LHM): Structures data hierarchically to support technical exchange formats.

• Standardized Methodology
  ISO 21926 describes:

  • Specification of object classes, attributes, and associations.
  • Techniques to decouple audit data from source systems, including ERP solutions.
  • Methods such as the graph walk technique for transforming relational data to hierarchical structures.

• Data Exchange and Binding
  The framework supports the creation of:

  • Exchange formats (CSV, XML, JSON) derived from the hierarchical model.
  • Syntax and semantic bindings to ensure consistency across multiple data standards and schemas.

• Naming Conventions and Definitions
  Specifies naming conventions aligned with international metadata standards (e.g., ISO/IEC 11179), promoting global interoperability and clarity.

Applications

The ISO 21926 semantic data model for audit data services is designed for use in collecting, exchanging, and validating audit-related data across various domains, such as:

• Financial and Compliance Audits
  Provides standardized structures for extracting data from general ledgers, accounts receivable/payable, inventory, payroll, property, plant & equipment, and tax records.

• Regulatory Reporting
  Supports the preparation and submission of audit data to regulatory bodies with clear specifications for cross-domain data exchange.

• Integration with ERP and Audit Software
  Enables seamless data extraction and mapping from enterprise resource planning (ERP) systems for audit purposes.

• Data Validation and Quality Assurance
  Offers clear object definitions and bindings to facilitate development of auditing tools and validation solutions.

The practical value includes improved audit transparency, easier compliance with evolving standards, adaptability to jurisdictional requirements via model extensions, and the ability to integrate and reuse audit data in new contexts.

Related Standards

ISO 21926 is part of a broader family of international standards for audit data services, working in conjunction with:

• ISO 21378: Functional requirements for audit data collection (ADC), defining required data elements and extraction processes.
• ISO/TS 21377: Guidelines for implementing audit data collection solutions.
• ISO 5401, ISO 5405: Standards addressing additional data and content requirements relevant to audit data services.
• ISO/IEC 11179 Series: Metadata registries standards, foundational for data definition and naming principles.
• ISO/IEC 19505: Unified Modeling Language (UML) standards for describing and visualizing semantic models.

These related standards ensure comprehensive guidance across the entire lifecycle of audit data - from specification and modelling to exchange, validation, and regulatory compliance.

---

By implementing ISO 21926, organizations and software providers can build future-proof, semantically consistent frameworks for managing and exchanging audit data, meeting both current and evolving audit and regulatory requirements.

Standards Content (Sample)

International
Standard
First edition
Semantic data model for audit data
services
PROOF/ÉPREUVE
Reference number
© ISO 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
PROOF/ÉPREUVE
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative reference . 1
3 Terms and definitions . 1
4 Abbreviated terms . 10
5 Naming conventions . 10
6 Audit data services standards .10
6.1 General .10
6.2 Target users classified for this document .11
7 Semantic data model .12
7.1 General . 12
7.2 Workflow for data model development and syntax and semantic binding . 12
7.3 Representation terms .14
7.3.1 General .14
7.3.2 Character string .14
7.3.3 Numeric . 15
7.3.4 Date and time . 15
7.3.5 Other . 15
7.4 Foundational Semantic Model (FSM) . 15
7.4.1 General . 15
7.4.2 Properties table for the Foundational Semantic Model (FSM) .17
7.5 Business Semantic Model (BSM) .19
7.5.1 General .19
7.5.2 Properties table for the BSM. 20
7.6 Logical Hierarchical Model (LHM).21
7.6.1 General .21
7.6.2 Relationship between metamodels of BSM and LHM (informative) .21
7.6.3 Graph walk method . 22
7.6.4 Meta data model of the Logical Hierarchical Model (LHM) . 23
7.6.5 Properties table for the Logical Hierarchical Model (LHM) . 25
7.6.6 Logical hierarchical model table example .27
7.7 Hierarchical Message Definition (HMD) . 29
7.7.1 General . 29
7.7.2 Properties table for Hierarchical Message Definition . . 29
7.7.3 Syntax binding . 29
7.7.4 Semantic binding . 30
Annex A (informative) Tabular definitions of semantic data model .31
Annex B (informative) Graph walk method .32
Annex C (informative) Guidelines on creating extensions .35
Bibliography .36
PROOF/ÉPREUVE
iii
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 295, Audit data services.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
PROOF/ÉPREUVE
iv
Introduction
A semantic data model for audit data services (ADS) provides a unified definition of accounting data elements,
focusing on making audit data accessible while bridging the gap between stakeholders such as auditors,
auditees, software developers and IT professionals. By offering a methodology that decouples accounting
information from specific systems and applications, the model facilitates standardized data extraction for
financial audits.
The increasing complexity of audits necessitates tools for managing, analysing and displaying audit data.
This document outlines a methodology and framework for developing and maintaining the model, as well
as for creating data exchange formats and binding to existing audit data standards. By integrating practical
applicability with a strong theoretical foundation, the model and framework aim to remain relevant in the
evolving audit data landscape.
This document aims to:
— Provide a comprehensive lexicon: The model organizes audit data within a fundamental semantic
structure, based on the tables and fields defined in ISO 21378.
— Offer structured guidelines: This document includes guidance for adapting and extending the model to
meet regional or organizational requirements, enhancing its versatility.
— Describe the binding process: This document explains the steps required to transform the foundational
model into a logical hierarchical model, and subsequently to specific hierarchic message definitions,
resulting in file formats such as CSV, XML and JSON.
This document comprehensively addresses the semantic data model for ADS. It introduces the framework and
foundational knowledge for implementing audit data services based on modelling techniques. Furthermore,
it explains how the logical hierarchical model can be derived from the business semantic model using the
graph walk method. The logical hierarchical model is the basis for the hierarchic message definitions, that
are the basis for the exchange formats.
The electronic version of the semantic data model and its derivatives includes:
— foundational semantic model (FSM);
— business semantic model (BSM);
— logical hierarchical model (LHM).
These models can be downloaded in tabular format, see Annex A.
PROOF/ÉPREUVE
v
International Standard ISO 21926:2026(en)
Semantic data model for audit data services
1 Scope
This document aims to define a methodology and framework to build a sematic data model for audit data
services (ADS), adapt it (by extensions), and convert it to exchange formats.
The methodology describes a standardized semantic structure for audit data, focusing on specifying
object classes and their attributes and associations, how to decouple audit data from specific systems (ERP
applications) and how to extract and exchange data uniformly for audits, and describes the methods used
for this such as graph walk (from relational to hierarchical model), syntax binding (to technical formats),
semantic binding (link to other standards).
The semantic data model applies to areas such as general ledger journal entries, accounts receivable, sales,
accounts payable, purchasing, inventory (movement and data), and property, plant, and equipment, customs
and indirect tax and payroll.
These areas are limited to the functional requirements set forth in ISO 21378, ISO 5401, and ISO 5405 and
can be extended with future extensions to ISO 21378.
This document describes the methodology and framework, not the full implementation or concrete technical
exchange standards.
2 Normative reference
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 11179-4, Information technology — Metadata registries (MDR) — Part 4: Formulation of data
definitions
ISO/IEC 11179-5, Information technology — Metadata registries (MDR) — Part 5: Naming principles
ISO/IEC 19505-1, Information technology — Object Management Group Unified Modeling Language (OMG UML)
— Part 1: Infrastructure
ISO/IEC 19505-2, Information technology — Object Management Group Unified Modeling Language (OMG UML)
— Part 2: Superstructure
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
PROOF/ÉPREUVE
3.1
class
description of a set of objects (3.14) that share the same attributes (3.9), operations, methods, relationships
(3.3) and semantics
[SOURCE: ISO/IEC 11179-3:2023, 3.1.1, modified — The domain "" has been removed; note 1 to
entry has been removed.]
3.2
abstract class
class (3.1) that does not provide a complete declaration and typically cannot be instantiated
Note 1 to entry: An abstract class is intended to be used by other classes as a general class for specialization (3.6).
[SOURCE: ISO/IEC 11179-3:2023, 3.1.1, modified — The domain "" has been removed; notes 2
and 3 to entry have been removed.]
3.3
relationship
connection among model elements
Note 1 to entry: In this document, a relationship is one of: an association (3.4) a generalization (3.5) or a specialization
(3.6).
[SOURCE: ISO/IEC 11179-3:2023, 3.1.4, modified — The domain "" has been removed.]
3.4
association
semantic relationship (3.3) between two classes (3.1) or between two or more instances of the same class
Note 1 to entry: An association is a type of relationship.
[SOURCE: ISO/IEC 11179-3:2023, 3.1.5, modified — The domain "" has been removed; note 2 to
entry has been removed.]
3.5
generalization
relationship (3.3) between a more general class (3.1) (the parent) and a more specific class (the child) that is
consistent with the general class and that adds additional information
Note 1 to entry: A generalization is a type of relationship.
Note 2 to entry: The more general class is referred to as the superclass (3.7).
Note 3 to entry: The more specific class is referred to as a subclass (3.8).
Note 4 to entry: A generalization is directed from the subclass to the superclass.
Note 5 to entry: A subclass may not have all of the attributes (3.9) and relationships of the superclass.
Note 6 to entry: Generalization is the inverse of specialization (3.6).
[SOURCE: ISO/IEC 11179-3:2023, 3.1.7, modified — The domain "" has been removed; the word
'fully' has been removed to allow subclasses within both the aligned and distinct layers the flexibility to
exclude properties inherited from their superclass; note 5 to entry has been replaced by a new one; note 7 to
entry has been removed.]
3.6
specialization
relationship (3.3) between a more general class (3.1) (the parent) and a more specific class (the child) that is
consistent with the general class and that adds additional information
Note 1 to entry: A specialization is a type of relationship.
PROOF/ÉPREUVE
Note 2 to entry: The more general class is referred to as the superclass (3.7).
Note 3 to entry: The more specific class is referred to as a subclass (3.8).
Note 4 to entry: A specialization is directed from the superclass to the subclass.
Note 5 to entry: A subclass may not have all of the attributes (3.9) and relationships of the superclass.
Note 6 to entry: Specialization is the inverse of generalization (3.5).
[SOURCE: ISO/IEC 11179-3:2023, 3.1.8, modified — The domain "" has been removed; the word
'fully' was removed to allow subclasses within both the aligned and distinct layers the flexibility to exclude
properties inherited from their superclass; note 5 to entry has been replaced by a new one; note 7 to entry
has been removed.]
3.7
superclass
class (3.1) that is a generalization (3.5) of one or more other classes
Note 1 to entry: The classes being generalized are known as subclasses (3.8).
[SOURCE: ISO/IEC 11179-3:2023, 3.1.9, modified — The domain "" has been removed; notes 2
and 3 to entry have been removed.]
3.8
subclass
class (3.1) that is a specialization (3.6) of another class
Note 1 to entry: The class being specialized is known as the superclass (3.7).
[SOURCE: ISO/IEC 11179-3:2023, 3.1.10, modified — The domain "" has been removed; notes 2
and 3 to entry have been removed.]
3.9
attribute
characteristic of an object (3.14) or set of objects
Note 1 to entry: An attribute describes one non-repeatable characteristic of an object. The attribute has a certain value
domain (3.30).
[SOURCE: ISO/IEC 11179-3:2023, 3.1.11, modified — The domain "" has been removed; note 1
to entry has been added.]
3.10
datatype
set of distinct values, characterized by properties (3.16) of those values and by operations on those values
[SOURCE: ISO/IEC 11179-3:2023, 3.1.13]
3.11
identifier
sequence of characters, capable of uniquely identifying that with which it is associated, within a specified
context (3.18)
Note 1 to entry: Unlike a name (3.20), an identifier is linguistically neutral.
[SOURCE: ISO/IEC 11179-3:2023, 3.1.16]
3.12
aggregation
"whole–part" association (3.4) where the part can exist independently of the whole
Note 1 to entry: Aggregation is a special type of association.
PROOF/ÉPREUVE
Note 2 to entry: The relationship (3.3) between the aggregate and its components is a weak "has-a" relationship: The
components may be part of several aggregates, may be accessed through other objects (3.14) without going through
the aggregate, and may outlive the aggregate object. The state of the component object still forms part of the aggregate
object.
3.13
composition
"whole–part" association (3.4) where the part cannot exist independently of the whole
Note 1 to entry: A composition is a special type of association.
Note 2 to entry: The relationship (3.3) between the composite and its parts is a strong “has-a” relationship: The
composite object (3.14) has sole responsibility for the existence and storage of the composed objects. A composed
object can be part of at most one composite. If a composite object is deleted, all of its part instances that are objects are
deleted with it.
3.14
object
anything perceivable or conceivable
Note 1 to entry: Objects can be material (e.g. 'engine', 'sheet of paper', 'diamond'), immaterial (e.g. 'conversion ratio',
'project plan') or imagined (e.g. 'unicorn', 'scientific hypothesis').
[SOURCE: ISO/IEC 11179-3:2023, 3.2.1]
3.15
object class
set of ideas, abstractions or things in the real world that are identified with explicit boundaries and meaning
and whose properties (3.16) and behaviour follow the same rules
[SOURCE: ISO/IEC 11179-3:2023, 3.2.2]
3.16
property
quality common to all members of an object class (3.15)
Note 1 to entry: In general, two types of properties can be distinguished: attributes (3.9) and associations (3.4).
[SOURCE: ISO/IEC 11179-3:2023, 3.2.3, modified — Note 1 to entry has been added.]
3.17
concept
unit of knowledge created by a unique combination of characteristics
Note 1 to entry: Concepts are not necessarily bound to particular languages. They are, however, influenced by the
social or cultural background which often leads to different categorizations.
[SOURCE: ISO/IEC 11179-5:2015, 4.3]
3.18
context
setting in which a designation (3.19) or definition (3.23) is used
[SOURCE: ISO/IEC 11179-5:2015, 4.4]
3.19
designation
representation of a concept (3.17) by a sign which denotes it
[SOURCE: ISO/IEC 11179-5:2015, 4.6]
PROOF/ÉPREUVE
3.20
name
designation (3.19) of an object (3.14) by a linguistic expression
[SOURCE: ISO/IEC 11179-3:2023, 3.2.12]
3.21
binding
mapping from one framework or specification to another, enabling data (3.27), commands or both to be
passed between them
[SOURCE: ISO/IEC 11179-3:2023, 3.2.21]
3.22
naming convention
specification of how signs of designations (3.19), scoped identifiers (3.11) or both are formulated
Note 1 to entry: A naming convention can apply to scoped identifiers when they are included in the associated
namespace.
[SOURCE: ISO/IEC 11179-3:2023, 3.2.22]
3.23
definition
representation of an item by a descriptive statement which, in a given language and context(s) (3.18), serves
to differentiate it from other items
[SOURCE: ISO/IEC 11179-3:2023,3.2.23, modified — The domain "" has been removed; “registry
item(s)” has been changed to "item(s)".]
3.24
definition text
text of the definition (3.23)
[SOURCE: ISO/IEC 11179-3:2023, 3.2.24]
3.25
extension
feature not defined by this document
[SOURCE: ISO/IEC 11179-3:2023, 3.2.40]
3.26
notation
formal syntax and associated semantics for the representation of information
[1]
EXAMPLE UML, MOF, OCL, OWL/RDF, SKOS, CGIF, XCL, XTM or ISO/IEC 11404 .
Note 1 to entry: A formal syntax consists of a set of symbols and the rules for their use.
Note 2 to entry: A formal syntax is often intended for machine processing.
[SOURCE: ISO/IEC 11179-3:2023, 3.2.36]
3.27
data
re-interpretable representation of information in a formalized manner suitable for communication,
interpretation, or processing
Note 1 to entry: Data can be processed by humans or by automatic means.
[SOURCE: ISO/IEC 11179-3:2023, 3.2.29]
PROOF/ÉPREUVE
3.28
multiplicity
specification of the range of allowable number of elements in a set
Note 1 to entry: Multiplicity specifications can be given for associations (3.4) or roles within associations and hierarchic
classes (3.47) in a logical hierarchic model.
Note 2 to entry: A multiplicity is a (possibly infinite) subset of the non-negative integers.
[SOURCE: ISO/IEC 11179-3:2023, 3.2.38, modified — The words "cardinalities that a set can assume" in the
definition have been substituted with "number of elements in a set"; note 1 to entry has been modified so
that multiplicity is only applicable to associations and hierarchic classes in a logical hierarchic model; for
attributes, mandatory/optional/conditional status should be used.]
3.29
value meaning
semantic content of a value
[SOURCE: ISO/IEC 11179-3:2023, 3.2.46, modified — Note 1 to entry has been deleted.]
3.30
value domain
VD
set of permissible values (3.31)
Note 1 to entry: The value domain provides representation but has no implication as to what data (3.27) element
concept (3.17) the values are associated with nor what the values mean.
Note 2 to entry: The permissible values can either be enumerated, expressed via a description, or a combination of the
two.
[SOURCE: ISO/IEC 11179-3:2023, 3.2.47]
3.31
permissible value
designation (3.19) of a value meaning (3.29)
Note 1 to entry: Permissible values may be specified either as part of a value domain (3.30) or only associated with a
value meaning.
Note 2 to entry: Within a value domain, permissible values can either be enumerated, expressed via a description, or a
combination of the two.
Note 3 to entry: Explicit mapping of a single permissible value to a single value meaning is possible only when both the
value meaning and permissible value are enumerated, e.g. for code sets. For described permissible values, it is possible
for the described meaning to be associated with a range of values, e.g. weight in kilograms.
[SOURCE: ISO/IEC 11179-3:2023, 3.2.48]
3.32
mandatory
always required
Note 1 to entry: One of three obligation statuses applied to the attributes (3.9) of items, indicating the conditions
under which the attribute is required; see also conditional (3.34) and optional (3.33).
[SOURCE: ISO/IEC 11179-3:2023, 3.2.75, modified — In note 1 to entry, the word “registry” has been
removed; note 2 to entry has been deleted.]
PROOF/ÉPREUVE
3.33
optional
permitted but not required
Note 1 to entry: One of three obligation statuses applied to the attributes (3.9) of items, indicating the conditions
under which the attribute is required. See also conditional (3.34) and mandatory (3.32).
[SOURCE: ISO/IEC 11179-3:2023, 3.2.76, modified — Note 1 to entry, the word “registry” has been removed;
note 2 to entry has been deleted.]
3.34
conditional
required under certain specified conditions
Note 1 to entry: One of three obligation statuses applied to the attributes (3.9) of items, indicating that conditions exist
under which the attribute is required. See also mandatory (3.32) and optional (3.33).
Note 2 to entry: if this status is used, the conditions under which the attribute is required should be specified with the
attribute.
[SOURCE: ISO/IEC 11179-3:2023, 3.2.77, modified — In note 1 to entry, the word “registry” has been removed
and changed for readability; note 2 to entry has been replaced by a new one.]
3.35
navigation
ability to traverse an association (3.4) between source class (3.1) and target class through their end properties
(3.16)
Note 1 to entry: navigation allows objects (3.14) of one class to "reach" or reference objects of another class via the
associations defined between them, leveraging the properties that represent the ends of these associations.
3.36
unidirectional association
association (3.4) between two classes (3.1) where one class is aware of, or can access, the other class, but the
reverse is not true
Note 1 to entry: The association has a defined direction from the source class to the target class, indicating that
instance of the source class can interact with or hold references to instance of the target class, but instance of the
target class does not have a corresponding reference back to instance of the source class.
3.37
bidirectional association
association (3.4) where both classes (3.1) involved are aware of each other and can access each other directly
Note 1 to entry: an instance of one class can interact with instances of the other class, and vice versa, allowing
navigation (3.35) and communication in both directions
3.38
foundational semantic model
FSM
initial layer in a multi-layered semantic data (3.27) model framework that establishes core architectural
principles and base definitions from which more detailed and specialized semantic models are developed
Note 1 to entry: The FSM is designed to provide consistent and standardized foundation ensuring interoperability and
clarity across different implementations of the semantic data model.
PROOF/ÉPREUVE
3.39
business semantic model
BSM
layer in a semantic data (3.27) model framework that customizes the foundational semantic model (3.38) to
align with specific regional or jurisdictional requirements, integrating local data standards, regulations and
practices
Note 1 to entry: The BSM enables semantic data models to accommodate variations in legal, cultural, and business
practices across different regions, enhancing the model's applicability and compliance with local standards.
3.40
logical hierarchical model
LHM
structured hierarchical model, derived from the semantic model using the graph walk method (3.51) and
independent of specific implementation technologies, which includes hierarchic classes (3.47), hierarchic
attributes (3.49), hierarchic associations (3.48), conditions, and content constraints.
Note 1 to entry: The LHM facilitates the organization and representation of data (3.27) in a structured, hierarchical
format to ensure clear communication of information and enforcement of data integrity across diverse systems.
3.41
hierarchical message definition
HMD
work product that defines message types
Note 1 to entry: HMD is a selected part of LHM (3.40), to create the exchange format.
3.42
associated class
class (3.1) that is linked to another class through an association (3.4), representing a relationship (3.3)
between the two classes within a semantic model
Note 1 to entry: An associated class is the target class in an association where the belonging class owns the association
as a property (3.16).
Note 2 to entry: The relationship between a belonging class and an associated class can be categorized into reference
association, aggregation (3.12), composition (3.13), or specialization (3.6), depending on the type of association.
3.43
syntax binding
process of linking elements in a semantic data (3.27) model to their corresponding representations in one or
more existing or newly defined data formats or schemas
Note 1 to entry: Syntax binding is not limited to defining new schemas but also applies to mapping a semantic model to
existing schema structures, ensuring compatibility with established standards.
3.44
semantic binding
process of establishing a logical relationship (3.3) between concepts (3.17) in a semantic model and their
corresponding meaning in a reference ontology, taxonomy, or controlled vocabulary
Note 1 to entry: Semantic binding ensures consistency in meaning and interpretation across different implementations
by linking data (3.27) elements to standardized definitions.
Note 2 to entry: Semantic binding is not limited to defining multiple occurrences of a referenced class (3.1) in a
structured format, such as mapping multiple tax classes (e.g. Tax1, Tax2) to ordered columns in a CSV file.
Note 3 to entry: Semantic binding may also include conditional mappings, such as linking an amount field with a debit
credit indicator ('D') to a debit amount column, ensuring that data is interpreted correctly based on contextual rules.
Note 4 to entry: Semantic binding supports flexible transformation rules, enabling adaptation to different domain-
specific requirements, localization needs, and reporting standards.
PROOF/ÉPREUVE
Note 5 to entry: Semantic binding may also define links from a CSV file to a hierarchical message definition (HMD)
(3.41), ensuring that flat-structured data in CSV format can be logically mapped to hierarchical structures in an HMD.
3.45
originating class
class (3.1) that serves as the origin of an association (3.4) and establishes a relationship (3.3) to an associated
class
Note 1 to entry: This terminology can be used to express a direction of an association in the semantic model. The
association starts at the originating class and ends at the associated class.
Note 2 to entry: In general, the direction of the association in the semantic model does not imply that the same
direction should be used in the logical hierarchical model (3.40), when it is created using the graph walk method (3.52).
The direction of an association in the logical hierarchical model is determined by the required functionality of the
information exchange.
3.46
hierarchic status
code that indicates the degree of obligation of a hierarchic attribute (3.49) or the degree of obligation of a
hierarchic class (3.47) in a logical hierarchical model (3.40).
Note 1 to entry: See also mandatory (3.32), optional (3.33) and conditional (3.34).
Note 2 to entry: hierarchic status is also applicable to a hierarchical message definition (3.41), as this is a subset of a
logical hierarchical model.
3.47
hierarchic class
class (3.1) from the semantic model that is used in the logical hierarchic model
Note 1 to entry: One class in the semantic model can be associated with multiple hierarchic classes. This typically
occurs if during the graph walk one class can be reached via multiple association paths in the semantic model.
3.48
hierarchic association
association (3.4) from the semantic model that is used in the logical hierarchical model (3.40)
Note 1 to entry: One association in the semantic model can be associated with multiple hierarchic associations.
This typically occurs if during the graph walk one association can be traversed multiple times to create the logical
hierarchical model.
Note 2 to entry: A hierarchic association has additional attributes (3.9) like mandatory/optional/conditional status
and multiplicity (3.28). The multiplicity of the hierarchic association shall be less than or equal than the multiplicity of
the association in the semantic model in the direction that it has been used in the logical hierarchical model.
3.49
hierarchic attribute
attribute (3.9) from the semantic model that is used in the logical hierarchic model
Note 1 to entry: As a class (3.1) from the semantic model can have multiple related hierarchical class instances, also
attributes from the semantic model can have multiple related hierarchic attributes in the logical hierarchical model
(3.40).
3.50
relational model
abstract representation of data (3.27) that defines the logical structure of the data, focusing on classes (3.1),
associations (3.4) between classes and attributes (3.9), without considering the physical implementation
details
Note 1 to entry: A relational model can graphically be presented as a graph with nodes and edges. In general cycles
may exist when traversing the graph, unlike a logical hierarchical model (3.40).
PROOF/ÉPREUVE
3.51
graph walk method
procedure to traverse a relational semantic model by systematically visiting its classes (3.1) and associations
(3.4) according to specific rules, used to create a hierarchical model
Note 1 to entry: The procedure starts by selecting a class in the semantic model to be the root class of the logical
hierarchical model (3.40), after which the associations are traversed repeatedly step by step and selected to be used in
the logical hierarchical model. Each step enlarges the association path with another association, but it is not allowed to
add an association that already occurs in the path. In this way multiple paths are selected from the root class and it can
occur that one class from the semantic model has multiple related hierarchic classes (3.47) in the logical hierarchical
model.
3.52
representation term
high-level datatype (3.10) description
4 Abbreviated terms
ADC audit data collection (see ISO 21378 and ISO/TS 21377)
ADS audit data service
UML Unified Modeling Language
CSV Comma Separated Values
XML eXtensible Markup Language
JSON JavaScript Object Notation
ERP Enterprise Resource Planning
5 Naming conventions
a) The naming conventions as defined in ISO 11179-5 shall be applied in this document.
b) The name of the line class is derived by appending "Line" to the class term of the associated header
class.
c) A class name ending with “Line” may be used for a non-line item class only if there is no corresponding
class name after removing the trailing “Line”.
6 Audit data services standards
6.1 General
The documents on audit data services developed by ISO/TC 295 address content specifications as well as the
techniques for collecting, pre-processing, managing, and analysing audit data to facilitate its identification,
communication, receipt, preparation, and use. The core components of these services are audits and the
associated audit data.
Audit data is essential for conducting audits and encompasses various areas, including public sector budgets,
financial reports, nonfinancial enterprises, taxation, and social insurance. This data supports a range of
audit purposes, such as government audits, external independent audits, internal audits, and reviews by
other regulatory bodies.
ISO 21378 provides common definitions for accounting data elements and outlines the necessary information
to extract relevant audit data efficiently.
PROOF/ÉPREUVE
The following documents can also be referenced:
— ISO/TS 21377;
— ISO 5401;
— IS0 5405;
— ISO/TS 24815;
— ISO/TS 24816.
6.2 Target users classified for this document
The following target users play a crucial role in the successful implementation and utilization of this
document, ensuring that audit data services are effective, compliant, and valuable across diverse domains.
— Auditee
Auditees are responsible for providing audit data upon request by auditors and regulators. Their role
includes ensuring that data from various systems is collected and delivered cohesively. They require clear
and unambiguous audit data specifications, ease of integration with ERP and surrounding systems, and
compliance with audit requirements.
— Auditor
Auditors, including government auditors, external independent auditors, and internal auditors, focus on
verifying and validating audit data. They need alignment with existing audit vocabularies, data reusability,
and enhanced cross-domain data exchange to perform thorough audits effectively.
— Regulator
Regulators oversee compliance with regulatory requirements and seek clear and unambiguous audit data
specifications, interoperability of business information, and effective data validation tools to enforce
regulations across sectors.
— Audit data service software developer
IT engineers developing ERP systems and data collection software are crucial for implementing audit data
solutions. Their responsibilities include supporting seamless integration, developing software for auditing
processes, and ensuring compatibility with multiple exchange formats and validation tools. While they do
not need an in-depth understanding of the semantic model framework, they should effectively map source/
target applications and audit data bindings.
— Semantic data model software developer
IT engineers developing semantic data model design software play a crucial role in implementing the
audit data service model. Their responsibilities include supporting object class modelling and developing
hierarchical message definitions.
— Standard developer
Entities responsible for creating and maintaining audit data standards should fully understand the semantic
model framework. They adapt the shared data model to meet jurisdictional regulations and laws, ensuring
compliance while maintaining consistency across diverse regulatory environments. This requires a
comprehensive understanding of the framework to extend standards effectively and accommodate regional
variations.
PROOF/ÉPREUVE
7 Semantic data model
7.1 General
This document provides an in-depth analysis of the semantic data model specifically designed for audit data
services, presenting a structured approach built on three integral layers: the foundational semantic model
(FSM), the business semantic model (BSM), and the logical hierarchical model (LHM). Each layer serves a
distinct and essential purpose within the overarching architecture and functionality of the model:
— Foundational semantic model (FSM)
The FSM is a relational model that forms the core architecture by leveraging Unified Modeling Language
(UML) to define classes and their interrelationships. This foundational layer encapsulates the structure
and semantics of data within a system, serving as the basis for subsequent specialization and adaptation. It
provides the necessary abstraction for constructing a versatile and extensible semantic framework.
Extensions to the semantic model can be created, for instance for regional and sector specific reasons.
This can be done by adding classes and associations or by defining specializations of existing classes.
Specialization involves creating a new subclass of a class defined in the semantic model and adding new
attributes and associations to it.
— Business semantic model (BSM)
The BSM is a selection of classes and associations from the semantic model and regional and sector-specific
extensions. In this way the BSMs are tailored to specific regional requirements and ensuring its relevance in
diverse contexts.
The transformation from FSM to BSM is driven by the process of selecting existing classes and associations
from the FSM.
— Logical hierarchical model (LHM)
The LHM is derived from the BSM through the graph walk method. This process organizes the relational
data from the BSM into a hierarchical structure, that s be used for exchange formats.
The graph walk method transforms the BSM into the LHM by systematically traversing the BSM. By selecting
and deselecting associations within the BSM the LHM's hierarchical organization should be established.
— Hierarchic message definition (HMD)
The technical spe
...

ISO/DISPRF 21926:2025(en)
ISO/TC 295
Secretariat: SAC
Date: 2026-03-1804-30
Semantic data model for audit data services
PROOF
ISO/PRF 21926:2026(en)
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication
may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying,
or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO
at the address below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: + 41 22 749 01 11
EmailE-mail: [e-mail]
Website: www.iso.org
Published in Switzerland
© 2025© ISO TC 295 2026 – All rights reserved
ii
ISO/DISPRF 21926:20252026(en)
Contents
Foreword . iv
Introduction . v
1 Scope . 1
2 Normative reference . 1
3 Terms and definitions . 1
4 Abbreviated terms . 11
5 Naming conventions . 11
6 Audit data services standards . 11
6.1 General . 11
6.2 Target users classified for this document . 12
7 Semantic data model . 12
7.1 General . 12
7.2 Workflow for data model development and syntax and semantic binding . 13
7.3 Representation terms . 15
7.4 Foundational Semantic Model (FSM) . 17
7.5 Business Semantic Model (BSM) . 22
7.6 Logical Hierarchical Model (LHM) . 25
7.7 Hierarchical Message Definition (HMD) . 38
Annex A (informative) Tabular definitions of semantic data model . 40
Annex B (informative) Graph walk method . 41
Annex C (informative) Guidelines on creating extensions . 45
Bibliography . 46

iii
ISO/PRF 21926:2026(en)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
ISO document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent rights
in respect thereof. As of the date of publication of this document, ISO had not received notice of (a) patent(s)
which may be required to implement this document. However, implementers are cautioned that this may not
represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 295, Audit data services.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
© 2025© ISO TC 295 2026 – All rights reserved
iv
ISO/DISPRF 21926:20252026(en)
Introduction
A semantic data model for audit data services (ADS) provides a unified definition of accounting data elements,
focusing on making audit data accessible while bridging the gap between stakeholders such as auditors,
auditees, software developers and IT professionals. By offering a methodology that decouples accounting
information from specific systems and applications, the model facilitates standardized data extraction for
financial audits.
The increasing complexity of audits necessitates tools for managing, analysing and displaying audit data. This
document outlines a methodology and framework for developing and maintaining the model, as well as for
creating data exchange formats and binding to existing audit data standards. By integrating practical
applicability with a strong theoretical foundation, the model and framework aim to remain relevant in the
evolving audit data landscape.
This document aims to:
— — Provide a comprehensive lexicon: The model organizes audit data within a fundamental semantic
structure, based on the tables and fields defined in ISO 21378.
— — Offer structured guidelines: This document includes guidance for adapting and extending the model
to meet regional or organizational requirements, enhancing its versatility.
— — Describe the binding process: This document explains the steps required to transform the
foundational model into a logical hierarchical model, and subsequently to specific hierarchic message
definitions, resulting in file formats such as CSV, XML and JSON.
This document comprehensively addresses the semantic data model for ADS. It introduces the framework and
foundational knowledge for implementing audit data services based on modelling techniques. Furthermore,
it explains how the logical hierarchical model can be derived from the business semantic model using the
graph walk method. The logical hierarchical model is the basis for the hierarchic message definitions, that are
the basis for the exchange formats.
The electronic version of the semantic data model and its derivatives includes:
— — foundational semantic model (FSM);
— — business semantic model (BSM);
— — logical hierarchical model (LHM).
These models can be downloaded in tabular format, see Annex AAnnex A.
v
DRAFT International Standard ISO/DIS 21926:2025(en)

Semantic data model for audit data services
1 Scope
This document isaims to define a methodology and framework to build a sematic data model for audit data
services (ADS), adapt it (by extensions), and convert it to exchange formats.
The methodology describes a standardized semantic structure for audit data, focusing on specifying object
classes and their attributes and associations, how to decouple audit data from specific systems (ERP
applications) and how to extract and exchange data uniformly for audits, and describes the methods used for
this such as graph walk (from relational to hierarchical model), syntax binding (to technical formats), semantic
binding (link to other standards).
The semantic data model applies to areas such as general ledger journal entries, accounts receivable, sales,
accounts payable, purchasing, inventory (movement and data), and property, plant, and equipment, customs
and indirect tax and payroll.
These areas are limited to the functional requirements set forth in ISO 21378, ISO 5401, and ISO 5405 and
maycan be extended with future extensions to ISO 21378.
TheThis document describes the methodology and framework, not the full implementation or concrete
technical exchange standards.
2 Normative reference
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 11179-4:2004(en), Information technology — Metadata registries (MDR) — Part 4: Formulation of
data definitions
ISO/IEC 11179-5:2015(en), Information technology — Metadata registries (MDR) — Part 5: Naming principles
ISO/IEC 19505-1:2012(E), Information technology — Object Management Group Unified Modeling Language
(OMG UML) — Part 1: Infrastructure
ISO/IEC 19505-2:2012(E), Information technology — Object Management Group Unified Modeling Language
(OMG UML) — Part 2: Superstructure
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— — ISO Online browsing platform: available at https://www.iso.org/obp
— — IEC Electropedia: available at https://www.electropedia.org/
ISO/PRF 21926:2026(en)
3.1 3.1
class
description of a set of objects (3.14(3.14)) that share the same attributes (3.9(3.9),), operations, methods,
relationships (3.3(3.3)) and semantics
[SOURCE: ISO/IEC 11179-3:2023, 3.1.1, modified — The domain "" has been removed; note 1 to
entry has been removed.]
3.2 3.2
abstract class
class (3.1(3.1)) that does not provide a complete declaration and typically cannot be instantiated
Note 1 to entry: An abstract class is intended to be used by other classes as a general class for specialization (3.6(3.6).).
[SOURCE: ISO/IEC 11179-3:2023, 3.1.1, modified — The domain "" has been removed; notes 2
and 3 to entry have been removed.]
3.3 3.3
relationship
connection among model elements
Note 1 to entry: In this document, a relationship is one of: an association (3.4(3.4)) a generalization (3.5(3.5)) or a
specialization (3.6(3.6).).
[SOURCE: ISO/IEC 11179-3:2023, 3.1.4, modified — The domain "" has been removed.]
3.4 3.4
association
semantic relationship (3.3(3.3)) between two classes (3.1(3.1)) or between two or more instances of the same
class
Note 1 to entry: An association is a type of relationship.
[SOURCE: ISO/IEC 11179-3:2023, 3.1.5, modified — The domain "" has been removed; note 2 to
entry has been removed.]
3.5 3.5
generalization
relationship (3.3(3.3)) between a more general class (3.1(3.1)) (the parent) and a more specific class (the
child) that is consistent with the general class and that adds additional information
Note 1 to entry: A generalization is a type of relationship.
Note 2 to entry: The more general class is referred to as the superclass (3.7(3.7).).
Note 3 to entry: The more specific class is referred to as a subclass (3.8(3.8).).
Note 4 to entry: A generalization is directed from the subclass to the superclass.
Note 5 to entry: A subclass may not have all of the attributes (3.9(3.9)) and relationships of the superclass.
Note 6 to entry: Generalization is the inverse of specialization (3.6(3.6).).
[SOURCE: ISO/IEC 11179-3:2023, 3.1.7, modified — The domain "" has been removed; the word
'fully' has been removed to allow subclasses within both the aligned and distinct layers the flexibility to
exclude properties inherited from their superclass; note 5 to entry has been replaced by a new one; note 7 to
entry has been removed.]
© 2025© ISO TC 295 2026 – All rights reserved
ISO/DISPRF 21926:20252026(en)
3.6 3.6
specialization
relationship (3.3(3.3)) between a more general class (3.1(3.1)) (the parent) and a more specific class (the
child) that is consistent with the general class and that adds additional information
Note 1 to entry: A specialization is a type of relationship.
Note 2 to entry: The more general class is referred to as the superclass (3.7(3.7).).
Note 3 to entry: The more specific class is referred to as a subclass (3.8(3.8).).
Note 4 to entry: A specialization is directed from the superclass to the subclass.
Note 5 to entry: A subclass may not have all of the attributes (3.9(3.9)) and relationships of the superclass.
Note 6 to entry: Specialization is the inverse of generalization (3.5(3.5).).
[SOURCE: ISO/IEC 11179-3:2023, 3.1.8, modified — The domain "" has been removed; the word
'fully' was removed to allow subclasses within both the aligned and distinct layers the flexibility to exclude
properties inherited from their superclass; note 5 to entry has been replaced by a new one; note 7 to entry has
been removed.]
3.7 3.7
superclass
class (3.1(3.1)) that is a generalization (3.5(3.5)) of one or more other classes
Note 1 to entry: The classes being generalized are known as subclasses (3.8(3.8).).
[SOURCE: ISO/IEC 11179-3:2023, 3.1.9, modified — The domain "" has been removed; notes 2
and 3 to entry have been removed.]
3.8 3.8
subclass
class (3.1(3.1)) that is a specialization (3.6(3.6)) of another class
Note 1 to entry: The class being specialized is known as the superclass (3.7(3.7).).
[SOURCE: ISO/IEC 11179-3:2023, 3.1.10, modified — The domain "" has been removed; notes 2
and 3 to entry have been removed.]
3.9 3.9
attribute
characteristic of an object (3.14(3.14)) or set of objects
Note 1 to entry: An attribute describes one non-repeatable characteristic of an object. The attribute has a certain value
domain (3.30(3.30).).
[SOURCE: ISO/IEC 11179-3:2023, 3.1.11, modified — The domain "" has been removed; note 1
to entry has been added.]
3.10 3.10
datatype
set of distinct values, characterized by properties (3.16(3.16)) of those values and by operations on those
values
[SOURCE: ISO/IEC 11179-3:2023, 3.1.13]
ISO/PRF 21926:2026(en)
3.11 3.11
identifier
sequence of characters, capable of uniquely identifying that with which it is associated, within a specified
context (3.18(3.18))
Note 1 to entry: Unlike a name (3.20(3.20),), an identifier is linguistically neutral.
[SOURCE: ISO/IEC 11179-3:2023, 3.1.16]
3.12 3.12
aggregation
"whole–part" association (3.4(3.4)) where the part can exist independently of the whole
Note 1 to entry: Aggregation is a special type of association.
Note 2 to entry: The relationship (3.3(3.3)) between the aggregate and its components is a weak "has-a" relationship: The
components may be part of several aggregates, may be accessed through other objects (3.14(3.14)) without going through
the aggregate, and may outlive the aggregate object. The state of the component object still forms part of the aggregate
object.
3.13 3.13
composition
"whole–part" association (3.4(3.4)) where the part cannot exist independently of the whole
Note 1 to entry: A composition is a special type of association.
Note 2 to entry: The relationship (3.3(3.3)) between the composite and its parts is a strong “has-a” relationship: The
composite object (3.14(3.14)) has sole responsibility for the existence and storage of the composed objects. A composed
object can be part of at most one composite. If a composite object is deleted, all of its part instances that are objects are
deleted with it.
3.14 3.14
object
anything perceivable or conceivable
Note 1 to entry: Objects can be material (e.g. 'engine', 'sheet of paper', 'diamond'), immaterial (e.g. 'conversion ratio',
'project plan') or imagined (e.g. 'unicorn', 'scientific hypothesis').
[SOURCE: ISO/IEC 11179-3:2023, 3.2.1]
3.15 3.15
object class
set of ideas, abstractions or things in the real world that are identified with explicit boundaries and meaning
and whose properties (3.16(3.16)) and behaviour follow the same rules
[SOURCE: ISO/IEC 11179-3:2023, 3.2.2]
3.16 3.16
property
quality common to all members of an object class (3.15(3.15))
Note 1 to entry: In general, two types of properties can be distinguished: attributes (3.9(3.9)) and associations (3.4(3.4).).
[SOURCE: ISO/IEC 11179-3:2023, 3.2.3, modified — Note 1 to entry has been added.]
© 2025© ISO TC 295 2026 – All rights reserved
ISO/DISPRF 21926:20252026(en)
3.17 3.17
concept
unit of knowledge created by a unique combination of characteristics
Note 1 to entry: Concepts are not necessarily bound to particular languages. They are, however, influenced by the social
or cultural background which often leads to different categorizations.
[SOURCE: ISO/IEC 11179-5:2015, 4.3]
3.18 3.18
context
setting in which a designation (3.19(3.19)) or definition (3.23(3.23)) is used
[SOURCE: ISO/IEC 11179-5:2015, 4.4]
3.19 3.19
designation
representation of a concept (3.17(3.17)) by a sign which denotes it
[SOURCE: ISO/IEC 11179-5:2015, 4.6]
3.20 3.20
name
designation (3.19(3.19)) of an object (3.14(3.14)) by a linguistic expression
[SOURCE: ISO/IEC 11179-3:2023, 3.2.12]
3.21 3.21
binding
mapping from one framework or specification to another, enabling data (3.27(3.27),), commands or both to
be passed between them
[SOURCE: ISO/IEC 11179-3:2023, 3.2.21]
3.22 3.22
naming convention
specification of how signs of designations (3.19(3.19),), scoped identifiers (3.11(3.11)) or both are formulated
Note 1 to entry: A naming convention can apply to scoped identifiers when they are included in the associated
namespace.
[SOURCE: ISO/IEC 11179-3:2023, 3.2.22]
3.23 3.23
definition
representation of an item by a descriptive statement which, in a given language and context(s) (3.18(3.18),),
serves to differentiate it from other items
[SOURCE: ISO/IEC 11179-3:2023,3.2.23, modified — The domain "" has been removed; “registry
item(s)” has been changed to "item(s)".]
3.24 3.24
definition text
text of the definition (3.23(3.23))
[SOURCE: ISO/IEC 11179-3:2023, 3.2.24]
ISO/PRF 21926:2026(en)
3.25 3.25
extension
feature not defined by this document
[SOURCE: ISO/IEC 11179-3:2023, 3.2.40]
3.26 3.26
notation
formal syntax and associated semantics for the representation of information
[1][1]
EXAMPLE UML, MOF, OCL, OWL/RDF, SKOS, CGIF, XCL, XTM or ISO/IEC 11404 .
Note 1 to entry: A formal syntax consists of a set of symbols and the rules for their use.
Note 2 to entry: A formal syntax is often intended for machine processing.
[SOURCE: ISO/IEC 11179-3:2023, 3.2.36]
3.27 3.27
data
re-interpretable representation of information in a formalized manner suitable for communication,
interpretation, or processing
Note 1 to entry: Data can be processed by humans or by automatic means.
[SOURCE: ISO/IEC 11179-3:2023, 3.2.29]
3.28 3.28
multiplicity
specification of the range of allowable number of elements in a set
Note 1 to entry: Multiplicity specifications can be given for associations (3.4(3.4)) or roles within associations and
hierarchic classes (3.47(3.48)) in a logical hierarchic model.
Note 2 to entry: A multiplicity is a (possibly infinite) subset of the non-negative integers.
[SOURCE: ISO/IEC 11179-3:2023, 3.2.38, modified — The words "cardinalities that a set can assume" in the
definition have been substituted with "number of elements in a set"; note 1 to entry has been modified so that
multiplicity is only applicable to associations and hierarchic classes in a logical hierarchic model; for
attributes, mandatory/optional/conditional status should be used.]
3.29 3.29
value meaning
semantic content of a value
[SOURCE: ISO/IEC 11179-3:2023, 3.2.46, modified — Note 1 to entry has been deleted.]
3.30 3.30
value domain
VD
set of permissible values (3.31(3.31))
Note 1 to entry: The value domain provides representation but has no implication as to what data (3.27(3.27)) element
concept (3.17(3.17)) the values are associated with nor what the values mean.
Note 2 to entry: The permissible values can either be enumerated, expressed via a description, or a combination of the
two.
© 2025© ISO TC 295 2026 – All rights reserved
ISO/DISPRF 21926:20252026(en)
[SOURCE: ISO/IEC 11179-3:2023, 3.2.47]
3.31 3.31
permissible value
designation (3.19(3.19)) of a value meaning (3.29(3.29))
Note 1 to entry: Permissible values may be specified either as part of a value domain (3.30(3.30)) or only associated with
a value meaning.
Note 2 to entry: Within a value domain, permissible values can either be enumerated, expressed via a description, or a
combination of the two.
Note 3 to entry: Explicit mapping of a single permissible value to a single value meaning is possible only when both the
value meaning and permissible value are enumerated, e.g. for code sets. For described permissible values, it is possible
for the described meaning to be associated with a range of values, e.g. weight in kilograms.
[SOURCE: ISO/IEC 11179-3:2023, 3.2.48]
3.32 3.32
mandatory
always required
Note 1 to entry: One of three obligation statuses applied to the attributes (3.9(3.9)) of items, indicating the conditions
under which the attribute is required; see also conditional (3.34(3.34)) and optional (3.33(3.33).).
[SOURCE: ISO/IEC 11179-3:2023, 3.2.75, modified — In note 1 to entry, the word “registry” has been removed;
note 2 to entry has been deleted.]
3.33 3.33
optional
permitted but not required
Note 1 to entry: One of three obligation statuses applied to the attributes (3.9(3.9)) of items, indicating the conditions
under which the attribute is required. See also conditional (3.34(3.34)) and mandatory (3.32(3.32).).
[SOURCE: ISO/IEC 11179-3:2023, 3.2.76, modified — Note 1 to entry, the word “registry” has been removed;
note 2 to entry has been deleted.]
3.34 3.34
conditional
required under certain specified conditions
Note 1 to entry: One of three obligation statuses applied to the attributes (3.9(3.9)) of items, indicating that conditions
exist under which the attribute is required. See also mandatory (3.32(3.32)) and optional (3.33(3.33).).
Note 2 to entry: if this status is used, the conditions under which the attribute is required should be specified with the
attribute.
[SOURCE: ISO/IEC 11179-3:2023, 3.2.77, modified — In note 1 to entry, the word “registry” has been removed
and changed for readability; note 2 to entry has been replaced by a new one.]
3.35 3.35
navigation
ability to traverse an association (3.4(3.4)) between source class (3.1(3.1)) and target class through their end
properties (3.16(3.16))
ISO/PRF 21926:2026(en)
Note 1 to entry: navigation allows objects (3.14(3.14)) of one class to "reach" or reference objects of another class via the
associations defined between them, leveraging the properties that represent the ends of these associations.
3.36 3.36
unidirectional association
association (3.4(3.4)) between two classes (3.1(3.1)) where one class is aware of, or can access, the other class,
but the reverse is not true
Note 1 to entry: The association has a defined direction from the source class to the target class, indicating that instance
of the source class can interact with or hold references to instance of the target class, but instance of the target class does
not have a corresponding reference back to instance of the source class.
3.37 3.37
bidirectional association
association (3.4(3.4)) where both classes (3.1(3.1)) involved are aware of each other and can access each other
directly
Note 1 to entry: an instance of one class can interact with instances of the other class, and vice versa, allowing navigation
(3.35(3.35)) and communication in both directions
3.38 3.38
foundational semantic model
FSM
initial layer in a multi-layered semantic data (3.27(3.27)) model framework that establishes core architectural
principles and base definitions from which more detailed and specialized semantic models are developed
Note 1 to entry: The FSM is designed to provide consistent and standardized foundation ensuring interoperability and
clarity across different implementations of the semantic data model.
3.39 3.39
business semantic model
BSM
layer in a semantic data (3.27(3.27)) model framework that customizes the foundational semantic model
(3.38(3.38)) to align with specific regional or jurisdictional requirements, integrating local data standards,
regulations and practices
Note 1 to entry: The BSM enables semantic data models to accommodate variations in legal, cultural, and business
practices across different regions, enhancing the model's applicability and compliance with local standards.
3.40 3.40
logical hierarchical model
LHM
structured hierarchical model, derived from the semantic model using the graph walk method (3.51(3.51))
and independent of specific implementation technologies, which includes hierarchic classes (3.47(3.47),),
hierarchic attributes (3.49(3.49),), hierarchic associations (3.48(3.48),), conditions, and content constraints.
Note 1 to entry: The LHM facilitates the organization and representation of data (3.27(3.27)) in a structured, hierarchical
format to ensure clear communication of information and enforcement of data integrity across diverse systems.
3.41 3.41
hierarchical message definition
HMD
work product that defines message types
Note 1 to entry: HMD is a selected part of LHM (3.40(3.40),), to create the exchange format.
© 2025© ISO TC 295 2026 – All rights reserved
ISO/DISPRF 21926:20252026(en)
3.42 3.42
associated class
class (3.1(3.1)) that is linked to another class through an association (3.4(3.4),), representing a relationship
(3.3(3.3)) between the two classes within a semantic model
Note 1 to entry: An associated class is the target class in an association where the belonging class owns the association
as a property (3.16(3.16).).
Note 2 to entry: The relationship between a belonging class and an associated class can be categorized into reference
association, aggregation (3.12(3.12),), composition (3.13(3.13),), or specialization (3.6(3.6),), depending on the type of
association.
3.43 3.43
syntax binding
process of linking elements in a semantic data (3.27(3.27)) model to their corresponding representations in
one or more existing or newly defined data formats or schemas
Note 1 to entry: Syntax binding is not limited to defining new schemas but also applies to mapping a semantic model to
existing schema structures, ensuring compatibility with established standards.
3.44 3.44
semantic binding
process of establishing a logical relationship (3.3(3.3)) between concepts (3.17(3.17)) in a semantic model and
their corresponding meaning in a reference ontology, taxonomy, or controlled vocabulary
Note 1 to entry: Semantic binding ensures consistency in meaning and interpretation across different implementations
by linking data (3.27(3.27)) elements to standardized definitions.
Note 2 to entry: Semantic binding is not limited to defining multiple occurrences of a referenced class (3.1(3.1)) in a
structured format, such as mapping multiple tax classes (e.g. Tax1, Tax2) to ordered columns in a CSV file.
Note 3 to entry: Semantic binding may also include conditional mappings, such as linking an amount field with a debit
credit indicator ('D') to a debit amount column, ensuring that data is interpreted correctly based on contextual rules.
Note 4 to entry: Semantic binding supports flexible transformation rules, enabling adaptation to different domain-
specific requirements, localization needs, and reporting standards.
Note 5 to entry: Semantic binding may also define links from a CSV file to a hierarchical message definition (HMD)
(3.41(3.41),), ensuring that flat-structured data in CSV format can be logically mapped to hierarchical structures in an
HMD.
3.45 3.45
originating class
class (3.1(3.1)) that serves as the origin of an association (3.4(3.4)) and establishes a relationship (3.3(3.3)) to
an associated class
Note 1 to entry: This terminology can be used to express a direction of an association in the semantic model. The
association starts at the originating class and ends at the associated class.
Note 2 to entry: In general, the direction of the association in the semantic model does not imply that the same direction
should be used in the logical hierarchical model (3.40(3.40),), when it is created using the graph walk method
(3.52(3.52).). The direction of an association in the logical hierarchical model is determined by the required functionality
of the information exchange.
3.46 3.46
hierarchic status
code that indicates the degree of obligation of a hierarchic attribute (3.49(3.49)) or the degree of obligation of
a hierarchic class (3.47(3.47)) in a logical hierarchical model (3.40(3.40).).
ISO/PRF 21926:2026(en)
Note 1 to entry: See also mandatory (3.32(3.32),), optional (3.33(3.33)) and conditional (3.34(3.34).).
Note 2 to entry: hierarchic status is also applicable to a hierarchical message definition (3.41(3.41),), as this is a subset of
a logical hierarchical model.
3.47 3.47
hierarchic class
class (3.1(3.1)) from the semantic model that is used in the logical hierarchic model
Note 1 to entry: One class in the semantic model can be associated with multiple hierarchic classes. This typically occurs
if during the graph walk one class can be reached via multiple association paths in the semantic model.
3.48 3.48
hierarchic association
association (3.4(3.4)) from the semantic model that is used in the logical hierarchical model (3.40(3.40))
Note 1 to entry: One association in the semantic model can be associated with multiple hierarchic associations. This
typically occurs if during the graph walk one association can be traversed multiple times to create the logical hierarchical
model.
Note 2 to entry: A hierarchic association has additional attributes (3.9(3.9)) like mandatory/optional/conditional status
and multiplicity (3.28(3.28).). The multiplicity of the hierarchic association shall be less than or equal than the multiplicity
of the association in the semantic model in the direction that it has been used in the logical hierarchical model.
3.49 3.49
hierarchic attribute
attribute (3.9(3.9)) from the semantic model that is used in the logical hierarchic model
Note 1 to entry: As a class (3.1(3.1)) from the semantic model can have multiple related hierarchical class instances, also
attributes from the semantic model can have multiple related hierarchic attributes in the logical hierarchical model
(3.40(3.40).).
3.50 3.50
relational model
abstract representation of data (3.27(3.27)) that defines the logical structure of the data, focusing on classes
(3.1(3.1),), associations (3.4(3.4)) between classes and attributes (3.9(3.9),), without considering the physical
implementation details
Note 1 to entry: A relational model can graphically be presented as a graph with nodes and edges. In general cycles may
exist when traversing the graph, unlike a logical hierarchical model (3.40(3.40).).
3.51 3.51
graph walk method
procedure to traverse a relational semantic model by systematically visiting its classes (3.1(3.1)) and
associations (3.4(3.4)) according to specific rules, used to create a hierarchical model
Note 1 to entry: The procedure starts by selecting a class in the semantic model to be the root class of the logical
hierarchical model (3.40(3.40),), after which the associations are traversed repeatedly step by step and selected to be
used in the logical hierarchical model. Each step enlarges the association path with another association, but it is not
allowed to add an association that already occurs in the path. In this way multiple paths are selected from the root class
and it can occur that one class from the semantic model has multiple related hierarchic classes (3.47(3.47)) in the logical
hierarchical model.
3.52 3.52
representation term
high-level datatype (3.10(3.10)) description
© 2025© ISO TC 295 2026 – All rights reserved
ISO/DISPRF 21926:20252026(en)
4 Abbreviated terms
ADC audit data collection (see ISO 21378 and ISO/TS 21377)
ADS audit data service
UML Unified Modeling Language
CSV Comma Separated Values
XML eXtensible Markup Language
JSON JavaScript Object Notation
ERP Enterprise Resource Planning
5 Naming conventions
a) a) The naming conventions as defined in ISO 11179-5 shall be applied in this document.
b) b) The name of the line class is derived by appending "Line" to the class term of the associated
header class.
c) c) A class name ending with “Line” may be used for a non-line item class only if there is no
corresponding class name after removing the trailing “Line”.
6 Audit data services standards
6.1 General
The documents on audit data services developed by ISO/TC 295 address content specifications as well as the
techniques for collecting, pre-processing, managing, and analysing audit data to facilitate its identification,
communication, receipt, preparation, and use. The core components of these services are audits and the
associated audit data.
Audit data is essential for conducting audits and encompasses various areas, including public sector budgets,
financial reports, nonfinancial enterprises, taxation, and social insurance. This data supports a range of audit
purposes, such as government audits, external independent audits, internal audits, and reviews by other
regulatory bodies.
ISO 21378 provides common definitions for accounting data elements and outlines the necessary information
to extract relevant audit data efficiently.
The following documents can also be referenced:
— — ISO/TS 21377;
— — ISO 5401;
— — IS0 5405;
— — ISO/TS 24815;
— — ISO/TS 24816.
ISO/PRF 21926:2026(en)
6.2 Target users classified for this document
The following target users play a crucial role in the successful implementation and utilization of this document,
ensuring that audit data services are effective, compliant, and valuable across diverse domains.
— — Auditee
Auditees are responsible for providing audit data upon request by auditors and regulators. Their role includes
ensuring that data from various systems is collected and delivered cohesively. They require clear and
unambiguous audit data specifications, ease of integration with ERP and surrounding systems, and compliance
with audit requirements.
— — Auditor
Auditors, including government auditors, external independent auditors, and internal auditors, focus on
verifying and validating audit data. They need alignment with existing audit vocabularies, data reusability, and
enhanced cross-domain data exchange to perform thorough audits effectively.
— — Regulator
Regulators oversee compliance with regulatory requirements and seek clear and unambiguous audit data
specifications, interoperability of business information, and effective data validation tools to enforce
regulations across sectors.
— — Audit data service software developer
IT engineers developing ERP systems and data collection software are crucial for implementing audit data
solutions. Their responsibilities include supporting seamless integration, developing software for auditing
processes, and ensuring compatibility with multiple exchange formats and validation tools. While they do not
need an in-depth understanding of the semantic model framework, they should effectively map source/target
applications and audit data bindings.
— — Semantic data model software developer
IT engineers developing semantic data model design software play a crucial role in implementing the audit
data service model. Their responsibilities include supporting object class modelling and developing
hierarchical message definitions.
— — Standard developer
Entities responsible for creating and maintaining audit data standards should fully understand the semantic
model framework. They adapt the shared data model to meet jurisdictional regulations and laws, ensuring
compliance while maintaining consistency across diverse regulatory environments. This requires a
comprehensive understanding of the framework to extend standards effectively and accommodate regional
variations.
7 Semantic data model
7.1 General
This document provides an in-depth analysis of the semantic data model specifically designed for audit data
services, presenting a structured approach built on three integral layers: the Foundational Semantic
Modelfoundational semantic model (FSM), the Business Semantic Modelbusiness semantic model (BSM), and
the Logical Hierarchical Modellogical hierarchical model (LHM). Each layer serves a distinct and essential
purpose within the overarching architecture and functionality of the model:
© 2025© ISO TC 295 2026 – All rights reserved
ISO/DISPRF 21926:20252026(en)
— — Foundational Semantic Modelsemantic model (FSM)
The FSM is a relational model that forms the core architecture by leveraging Unified Modeling Language (UML)
to define classes and their interrelationships. This foundational layer encapsulates the structure and
semantics of data within a system, serving as the basis for subsequent specialization and adaptation. It
provides the necessary abstraction for constructing a versatile and extensible semantic framework.
Extensions to the semantic model can be created, for instance for regional and sector specific reasons. This
can be done by adding classes and associations or by defining specializations of existing classes. Specialization
involves creating a new subclass of a class defined in the semantic model and adding new attributes and
associations to it.
— — Business Semantic Modelsemantic model (BSM)
The BSM is a selection of classes and associations from the semantic model and regional and sector-specific
extensions. In this way the BSMs are tailored to specific regional requirements and ensuring its relevance in
diverse contexts.
The transformation from FSM to BSM is driven by the process of selecting existing classes and associations
from the FSM.
— — Logical Hierarchical Modelhierarchical model (LHM)
The LHM is derived from the BSM through the graph walk method. This process organizes the relational data
from the BSM into a hierarchical structure, that s be used for exchange formats.
The graph walk method transforms the BSM into the LHM by systematically traversing the BSM. By selecting
and deselecting associations within the BSM the LHM's hierarchical organization should be established.
— — Hierarchic Message Definitionmessage definition (HMD)
The technical specifications of the exchange formats are derived from a hierarchic message definition, which
is a subset of the logical hierarchical model. This supports exchange of audit data in multiple files. The bindings
of the hierarchic message definition to the exchange formats are derived from the LHM syntax bindings.
The models should be documented in a tabular format. Each table of one of the above models that is defined
in this clause contains the columns that are required. However, additional columns may be added with
application specific data, for instance XML tag, language specific description, business term, etc.
To articulate and present the models effectively the ISO/IEC 11179 naming and definition principles
SHALLshall be applied and UML (ISO/IEC 19505-1:2012 and ISO/IEC 19505-2:2012) SHALL) shall be applied
for presentation of classes, properties and associations.
7.2 Workflow for data model development and syntax and semantic binding
The sequence of steps in Figure 1Figure 1 outlines the progression from conceptual data models to tangible,
format-specific schemas, highlighting the methodical approach to data model implementation.
ISO/PRF 21926:2026(en)
Figure 1— Workflow for data model and exchange formats development
Figure 1Figure 1 illustrates a structured workflow for the development of data models and their binding to
specific data formats. It visualizes the progression from abstract semantic models to practical
implementations, providing clarity on each transformative step. The steps include:
— — Extend
In the FSM layer, the semantic model is expanded by new classes to form the extended semantic model. In an
extension the semantic model can also be further refined through specialization. This specialization
introduces more detailed and structured elements, tailoring the model to fit specific regional and sector
specific requirements. Guidelines on how to create exchange formats for certain extensions is described in
Annex CAnnex C.
© 2025© ISO TC 295 2026 – All rights reserved
ISO/DISPRF 21926:20252026(en)
— — Refinement
The BSM is a refinement of the semantic model and its extensions. The value domains of attributes can be
refined on this level. An attribute, when specified with a representation term that aligns with its data type,
further refines its value domain to meet regional requirements, for instance to define an international code
list.
Additionally, the value domain may specify constraints such as the maximum length of character strings,
format requirements using regular expressions, and restrictions on values.
— — Gra
...