Conference PaperPDF Available

Public process management: A method for introducing standard business reporting


Abstract and Figures

Businesses have to file many reports to show compliance with rules and regulations. Regulators try to reduce the administrative burden, by providing a standardized representation format and agreements about reporting procedures and the use of technical infrastructure. However, developing and managing such a standardized reporting scheme is hard. It involves inter-dependencies between processes, data and technology and the interests of many stakeholders. Drawing on existing practice this paper presents Public Process Management (PPM): a general method for process management in the public sector. In this paper we apply PPM specifically to the problem of introducing a standardized reporting scheme in an application domain. The method is driven by quality management and process redesign approaches, but deals with unique characteristics of compliance reporting: legal data requirements, provenance, process compliance and multiple stakeholders. In particular, PPM stresses strict adherence to an iterative development schedule, and shared conceptual models of processes, data definitions, technological infrastructure and governance agreements. The usefulness and adequacy of the method are illustrated by a case study on Standard Business Reporting, a standardized reporting channel in the Netherlands for both public and private agencies.
Content may be subject to copyright.
Public Process Management:
a method for introducing Standard Business Reporting
Joris Hulstijn
Remco van Wijk
Delft University of Technology
The Netherlands
Niels de Winne
Nitesh Bharosa
Delft University of Technology
The Netherlands
Marijn Janssen
Yao-Hua Tan
Delft University of Technology
The Netherlands
Businesses have to file many reports to show compliance with
rules and regulations. Regulators try to reduce the administrative
burden, by providing a standardized representation format and
agreements about reporting procedures and the use of technical
infrastructure. However, developing and managing such a
standardized reporting scheme is hard. It involves inter-
dependencies between processes, data and technology and the
interests of many stakeholders. Drawing on existing practice this
paper presents Public Process Management (PPM): a general
method for process management in the public sector. In this paper
we apply PPM specifically to the problem of introducing a
standardized reporting scheme in an application domain. The
method is driven by quality management and process redesign
approaches, but deals with unique characteristics of compliance
reporting: legal data requirements, provenance, process
compliance and multiple stakeholders. In particular, PPM stresses
strict adherence to an iterative development schedule, and shared
conceptual models of processes, data definitions, technological
infrastructure and governance agreements. The usefulness and
adequacy of the method are illustrated by a case study on
Standard Business Reporting, a standardized reporting channel in
the Netherlands for both public and private agencies.
Categories and Subject Descriptors
H.1.0 [Models and Principles]: General, J.1 [ Administrative
Data processing]: Administrative Data processing -- Government
General Terms
Standardization, Legal Aspects
e-government, financial reporting, compliance
In response to incidents, society often calls for more or more
stringent regulation. Also in business there are many corporate
governance guidelines and auditing standards. Power [1] calls this
the audit society. Compliance to the rules must be shown.
Companies must therefore file an increasing amount of
compliance reports. Consider for example tax reports, annual
financial statements, reports about compliance with food and
health regulations, applications for a loan, or evidence of
corporate governance. A compliance report contains data, which
serves as evidence that the business complies to some regulation
or internal guideline. Preparing reports takes a lot of effort.
Governments try to reduce the administrative burden for
businesses by standardizing business reporting formats and
procedures, and providing shared information technology support.
There are at least three possible scenarios to achieve this: (1) One
stop shop government [2]: data only needs to be provided once to
a single entry point. Different government agencies can reuse the
data. (2) Store once, report many. Companies only have to store
their data once in a particular data representation format; from this
data various reports can be generated. (3) Continuous control
monitoring: data for reports is sent   
information systems on a continuous basis, to monitor
compliance [3]. This approach may be - [4]:
compliance rides along on commercial data.
An open data representation standard like XBRL with a taxonomy
to provide a shared semantics could facilitate these approaches. In
principle, data elements of the com  
only need to be mapped once onto the data elements for reporting.
Not only will this improve efficiency, but it will also improve
reliability, as the original commercial data is used for reporting
and there is less opportunity for manipulation. To accomplish
these objectives, the complete information processing chain needs
to be re-configured. Standards, procedures and information
technology infrastructure need to be developed or selected,
adopted and maintained. This process can be hard to manage. It
involves complex inter-dependencies between processes, data and
technology and the interests of many stakeholders. Standardized
reporting has four specific challenges:
1. Legal requirements: data definitions are determined by law,
2. Provenance: the origin and processing history, as well as the
quality of different kinds of data need to be assured.
3. Process compliance: processes for handling report data are
restricted by rules, such as archiving or due diligence, and
4. Multiple Stakeholders: setting up a reporting schedule needs
involvement by many stakeholders and end-users.
Moreover, in general information technology projects in
government often turn out to be more expensive than estimated,
require more time than planned, and do not deliver intended
results [5-7]. In the literature there is much knowledge about the
redesign of processes and workflow, originating from approaches
like Business Process Redesign [8] and Total Quality
Management [9]. Both have a generic nature and are not focused
on the public domain. To meet these challenges, therefore,
specific management techniques are needed.
In this paper we present Public Process Management (PPM):
a general method for process management and information
systems development in the public sector. The method is based on
existing practices, which have been developed over several
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
Dg.o11, June 1215, 2011, College Park, MD, USA.
Copyright 2011 ACM 978-1-4503-0762-8/11/06.00.
information system and process redesign projects in the Dutch
government. See for example [10, 11]. We have documented this
approach and apply it specifically to the introduction of
standardized reporting in the Netherlands, and test whether it
meets the above mentioned challenges.
The PPM method provides an iterative approach to the analysis,
design, implementation, deployment, and maintenance phases of
a development project, focusing on an architecture with a separate
process layer, data layer, and technical infrastructure layer, as well
as the governance issues. Deadlines are strictly maintained. Issues
which cannot be addressed can be postponed till the next
development round. Like in business process management, PPM
makes extensive use of graphical modeling tools, in particular
BPMN and BPEL for process modeling [12], as well as ontology
and taxonomy description languages like XBRL for data
modeling. Models are understood by both domain experts and
system developers, and help to lessen the implementation gap.
Detailed process models help to decide which tasks can be
automated, which tasks need to be supported by information, and
which tasks can be dropped. Moreover, a shared representation of
the data, process and technology layers gives stakeholders an
overview of the needs of other stakeholders, and an increased
willingness to share required information. Explicit and shared
models may also facilitate a predictable decision making process
in the network.
From the experience of standards development for international
trade facilitation at the United Nations it appeared that process
modeling plays two important roles [4, 13]. First, process
modeling is a prerequisite for developing a standard in the first
place. Data definitions can only be reliably agreed on when the
processes and decisions for which the data will be used are
known. For example, the definition of income used to calculate
taxes is different from that used to calculate social benefits.
Second, process modeling is essential for harmonizing processes
across different agencies to handle the reports. Standardization
itself is again a prerequisite for process simplification and
harmonization. As our research framework we adopt the inter-
organizational systems (IOS) paradigm [14]. We focus on ways to
manage the IOS development and adoption process.
The working hypothesis of PPM is that (1) strict adherence to an
iterative development schedule with clear deadlines and
deliverables, and (2) developing shared conceptual models of the
process, data and technical infrastructure layers and governance
agreements, will make the development, adoption and
maintenance of standardized reporting schemes easier to manage
and result in a more effective solution.
To illustrate the plausibility of this working hypothesis, we
discuss a case study of the Standard Business Reporting program
in the Netherlands. Standard Business Reporting (SBR) is a
program to reduce administrative burden for businesses by
providing a standardized data representation format (XBRL),
shared semantics (Netherlands Taxonomy) and reporting platform
(Digipoort) for filing official reports. The approach was
developed in the Netherlands Taxonomy Project (NTP) and later
adopted by Australia, after which it was re-branded SBR, see [11].
We study the development and adoption of the taxonomy and the
technical infrastructure, but also the governance structure and
management processes underlying current operations.
The paper is structured as follows. In Section 2 we characterize
our current application domain for PPM: standardized reporting.
Section 3 contains a detailed exposition of PPM. In Section 4 we
describe the SBR case study.
Public process management is a set of practices, which have been
developed over several years of implementing XBRL-based
reporting solutions in the Netherlands. Currently, the method is
used for financial applications, including agencies such as the tax
office, bureau of statistics and chamber of commerce. In addition,
a similar XBRL-based reporting platform is being developed for
banking applications. However, there is no reason why XBRL
could not be used in other application domains too, such as health
care or food processing. In fact, a pilot project in the meat
processing industry has recently been completed [15]. Here,
XBRL reports could be used to continuously monitor compliance
with food safety regulations. Despite the apparent diversity, there
are common elements to these applications.
Reporting: all applications are about reporting. A report is
defined here as a formal statement that certain facts apply.
Compliance: reports serve either as evidence or as
declaration that the citizen or company is compliant with a
business rule, guideline or legal regulation.
Actors: citizens or companies filing reports, institutions
(public or private) verifying compliance, and possibly
intermediaries (consultants, accountants, bookkeepers) and
software or technology infrastructure providers.
Institutions requesting reports can be regulating authorities
(national bank), government agencies (tax office), professional
organizations (chamber of commerce), or commercial parties (e.g.
banks). Institutions can demand reports because they are supposed
to offer a public service, i.e. to reduce risks to society concerning
safety and security, or maintain financial stability [16].
A generic reporting situation is shown in Figure 1. On the left we
find the company; on the right the institution. The company needs
to report about primary processes, but typically this is done
indirectly. The company collects data about primary processes for
management and control purposes. For instance, when there is an
incident, it must be analyzed, dealt with and resolved. This is an
example of internal control. Aggregating over internal control
information, the company can generate reports for demonstrating
compliance to external stakeholders. There is a transfer of
information from company to institution (the report), followed by
a confirmation from the institution that the company fulfilled its
reporting duty, possibly followed later by an official decision.
Figure 1. Generic reporting situation
This generic reporting situation may exists for many reports and
institutions simultaneously. Simplification can be implemented in
different ways. In each scenario the division of labour (decoupling
point) between company and institution is shifted.
1. One stop shop government: various public services are
delivered through a single entry point, sometimes called a single
window, focused on the needs of the company or citizen [2].
Consider for example trade facilitation, such as the establishment
of a single entry point for all cross-border regulatory paperwork
(customs declarations, VAT report, veterinary check, etc. ) [4].
Internal Control
However, in many settings the single-window concept is both
legally and practically impossible. Legally, data collected for one
purpose may not be used for another purpose without written
consent of the data owner. Practically, the content of a report may
differ because of the underlying purpose. In a tax report, a
company will try to report as little revenue as possible within the
rules. In the annual financial statement the company may want to
show as much revenue as possible to please shareholders. Finally,
the quality level of data may differ between reports. For example,
for a statistics report the raw business data are sufficient, whereas
annual financial statements must be consolidated and verified by
an external accountant. The following scenario is more plausible.
2. Store once, report many. Generally there is a lot of overlap
between the contents of various compliance reports. For instance,
corporate tax declarations contain much the same information as
the annual financial statements. Moreover, different reporting
institutions require different formats, authentication mechanisms,
or software support systems. Companies need to learn, install and
maintain all these separate reporting mechanisms separately.
Ideally a company will store the required information only once,
using a shared data representation format and semantics, after
which reports for many stakeholders can be generated on the basis
of the same software system. Although the role of the company is
larger than in scenario 1 or 3, it does have economic benefits to
adopt this scenario. The data representation standard and
underlying software support may be shared and reused. This will
also eventually also reduce regulatory burden on the part of
institutions. For businesses, further benefits may result from
innovations based on standardization of financial services. How
such innovations will affect the market is an open question.
3. Continuous Control Monitoring [3]. When the frequency of
reports is increased, the report as a document is replaced by a
continuous stream of control monitoring data, from company to
institution. Provided that reliability of the reporting stream can be
guaranteed by a system of internal control measures, continuous
monitoring has the advantage that assurance can be provided
continuously on the basis of current events, instead of incidentally
on the basis of past events, as in the case of traditional auditing.
There are two variants. The institution pulls the control data out of
       -
backing [4]), or alternatively obtains them from a validated copy
tion systems. Compare the architecture
of [3]. The latter method has less legal and practical obstacles.
Wimmer [2] has also analysed the various stages of e-goverment
projects. The more advanced the stage, the more complex the
project. A project can provide (1) information about public
services, (2) the possibility to contact people (communication), (3)
the possibility to download and fill in forms to apply for public
services (interaction or contracting), and (4) the possibility to
handle a complete service (transaction). The reporting situation is
of the fourth kind: a company completes a transaction, because it
fulfils its legal duty to report. In particular when alternative
reporting channels are discouraged, this means that reporting
services need to fulfil the highest standards with respect to
reliability, accessibility, usability and confidentiality.
Projects in the standardized reporting domain have some
interesting challenges, which make it difficult to use more general
project management techniques.
1. Legal Data Requirements. The contents required by
compliance reports are determined by law. Therefore, data
definitions most conform to legal requirements. This may
hinder interoperability.
2. Provenance. The actual contents of reports may differ in
quality level (verified or raw data), precision, origin,
reliability level, aggregation level and processing history.
Process Compliance. There are regulations about how
processes of institutions must be conducted related to aspects
like archiving, protection of copyright, good governance,
legitimacy of decisions, audit trail, and so on.
3. Multiple Stakeholders. The reporting domain involves many
public and private parties, possibly with diverging interests.
No agency can build an information system by itself. Solving
interdependencies often results in a tedious and political
decision making process [17].
The Public Process Management method has developed in
practice to meet these challenges, among others.
This section contains an exposition of the various techniques and
practices which make up PPM. In general, it makes sense to
partition a project into smaller parts. PPM has two partitioning
principles. Firstly, development proceeds iteratively in phases
with clear deadlines and deliverables: analysis and design,
implementation, execution and monitoring. This provides a
temporal partitioning. Secondly, there is a separation between the
different layers of a projected solution: process layer, data layer,
technological infrastructure, and governance aspects. We start by
explaining the development phases.
3.1 Iterative Development Phases
PPM is designed to operate in a political arena, in which many
stakeholders need to collaborate in a project, even though they
may have diverging interests. In such circumstances, requirements
creep is likely [18]. One must accept that some demands of some
stakeholders will never be met, and settle for what is feasible
given the limited budget and time [17]. In particular, it makes
sense to enforce deadlines after relatively short intervals (two or
three months), so that a sense of progress is maintained. This is
called time-boxing. It is a well-established guiding principle of
rapid software development [19, 20]. Under time pressure,
disputes about what would be nice to have will be postponed and
replaced by concerns about achieving the most needed
functionality. Typically, a project like this develops incrementally
over several implementation rounds. Requirements from
stakeholders are prioritized according to the MoSCoW scheme:
         
then be scheduled for the next development round of the project.
The development phases themselves are fairly standard (Figure 2).
They correspond to the traditional phases (or activities) of the
engineering life cycle: analysis, design, implementation and
testing, adoption (or deployment) and maintenance (and
evaluation) [21]. Each phase or activity produces one or more
deliverables. The analysis phase results in a requirements
specification: what objectives should the IT solution fulfill? The
design phase results in a blueprint of what the solution should
look like. Here, many of the design choices have to be settled. The
implementation phase results in a working solution, which
conforms to the requirements and has been tested in a restricted
setting. During the adoption phase, the solution is rolled out over
all remaining application areas and taken into production. The
maintenance and evaluation phase, finally, involves the endless
process of monitoring performance, evaluating and improving the
solution. Only during this stage the full benefits of a controlled
solution will be reached.
Figure 2. Iterative development phases with deliverables
3.2 Layers
Like in many approaches to Business Process Management [22]
and Enterprise Architecture [23], the central philosophy of PPM is
that redesign projects involve changes at several layers
simultaneously. The relevant layers for the introduction of a
shared reporting format are: processes, data, and technical
infrastructure. Governance aspects relate to all layers (Table 1).
Similar layer structures are used in enterprise architecture [23].
Another relevant analogy is with NORA 2.0, the standardized
Dutch government ICT architecture, which distinguishes a
business architecture (compare process layer), an information
architecture (compare data layer) and a technical architecture
(compare technical infrastructure layer).
Table 1. Integrated architecture: process, data and technical
infrastructure layers, as well as governance aspects
Processes: actors, activities, control flow,
messages, coordination
Data: data model, taxonomy, inference,
integrity constraints
Technical Infrastructure: network,
storage, processing, message delivery
A lower layer delivers functionality to be used by a higher layer.
Conversely, a higher layer must rely on functionality of the layer
below it, although the details may be hidden behind an interface.
This is the well-known principle of abstraction. Layers are often
interconnected. For example, for each choice-fork in a process
analysis there are certain data elements in the data layer which
determine the choice condition. Similarly, when a process analysis
shows a message being exchanged between parties, this triggers
the question what data elements this message should contain, and
how this message should be securely delivered.
The following section describes each of the three layers and the
governance aspects in more detail.
3.3 Process Layer
We start with the process layer. Thinking in terms of business
         
Business Process Reengineering [9, 24]. The idea was to re-design
organizations using information technology, and focus on the
added value of activities to some specific customer. In case of
public processes, the customer will usually be the citizen, or some
other recipient of the outcome of the process. We use the
following description, taken from Davenport [24] 
simply a structured, measured set of activities designed to produce
a specific output for a  To redesign
processes, one must first analyze the existing situation (system-as-
is), derive the underlying objectives (including compliance) and
measure current performance with respect to aspects like costs,
through put, lead time and quality of outcomes. It is important to
consider the actual way the work is being done; not how the work
is supposed to be done. Once the current situation is known to
all stakeholders -- the process is redesigned to meet the objectives,
but in a simpler way to improve effectiveness, efficiency, control
and compliance. For instance, processes can be improved by
reducing the number of steps, reducing the number of
dependencies between steps so parts of the process can be
executed in parallel, or by reducing the number of parties
involved, thereby reducing overall complexity. The redesign
produces a clear vision of the projected new situation (system-to-
be). After that, the organization needs to change and gradually
adopt the vision, and the corresponding information technology.
Measuring initial performance is important, so that improvements
during the change process can be made visible.
BPMN Modeling
In order to make detailed models of both the existing situation and
the envisioned new situation, we make extensive use of business
process modeling tools, in particular Business Process Modeling
Notation (BPMN) and Business process Execution Language
(BPEL) [12]. BPMN makes the work flow of a process explicit,
indicating the order of activities, roles or actors who execute
activities, choice points, parallel execution, message exchange and
coordination. Given a BPMN model, it is relatively
straightforward to analyze a business process. BPEL in turn
makes it possible to execute process models in a simulation
environment, for instance to test the system-to-be against
requirements. In general, graphical models like these (e.g. also
activity diagrams or interaction diagrams as in the Unified
Modeling Language ) have been shown to be useful for business
process documentation, and therefore facilitate knowledge sharing
among stakeholders [25].
Figure 3. Simplified BPMN model of Reporting Process
Once a detailed BPMN model has been constructed, it can be used
and analyzed in various ways.
Complexity is determined, for instance by counting the
number of steps, the number of actors involved, the number
of choice points or the number of data items needed to make
choices. In general process complexity is an indicator for
other performance measures, like lead time, number errors,
capacity etc. Brooks [26] distinguishes the essential
complexity of a process, which must be faced, with
accidental complexity, which can be reduced without loss of
quality in the outcomes. Complexity reduction forms an
important part of the business case of a process redesign.
and testing
evaluation Require-
System in
RegulatorGatewayCompany / Citizen
Service Delivery
time outs; exception handling
Tasks, roles and information needs are determined. For each
data element, one can for example specify in which activity
the information is created, and in which activities it is
subsequently used (create-use matrix). Such a matrix can
also be adapted to register access control rights for users in
different roles, or in differ stages of the process.
Process Compliance is analyzed. Does the process as
described adhere to rules and regulations? Consider for
instance archiving. All messages, data used in decisions and
outcome data, must be archived in such a way that the
process can be traced back. This is called an audit trail.
For example, in Figure 3 we count eleven activities, although
some are composed of sub-activities. Choice points are hidden
inside processes (validation, internal processing). There are
exception handling links (indicated by an electricity sign), and
time outs (indicated with a clock sign), which can be logged.
Message exchange is indicated by a dashed line with an envelope
sign. In this case, information needs that can be easily discovered
are about the causes of exceptions and delays, and prerequisites
for validation. Compliance with archiving regulations for the
Gateway process can for example be verified, by making sure that
the Provide Response step will always store the audit trail of a
session into a reliable read-only device.
Kinds of Processes
In PPM processes are distinguished according to their functions
(compare also Figure 1).
1. primary processes directly add value, i.e. help to achieve the
main objectives of the organization
2. recording processes collect, register, store and retrieve
evidence about the primary processes, for management,
control and accountability purposes
3. control processes should detect, prevent and repair possible
defects (not reaching objectives) in the primary process
4. accountability processes report to external stakeholders
whether objectives are being met concerning primary
processes, current situation and future expectations.
Typically these processes are executed by different departments
within an organization (segregation of duties, see below). These
processes are interlinked, but they can be executed in parallel,
although in different time frames. For instance, accountability
processes repeat on a quarterly basis, while control is active on a
daily basis. Note that for some organizations, information
processing is their primary business (e.g. tax office) while for
others it is only secondary (e.g. meat processing firms).
In order to define recording and control processes, primary
processes must be specified in terms of performance indicators. In
management accounting one traditionally recognizes three
different ways in which a process can be specified [24, 27].
1. behavior: specify sequence of activities to be executed,
2. outcome: specify the intended results of the activities, or
3. qualification: specify competencies for executing activities.
Separation of Duties
In accounting theory the principle of separation of duties is
considered very important [28]. Some roles or functions in an
organization may not be played by the same person. Separate
functions create independent registrations, which can later be
compared to test for accuracy and completeness of the records. In
public processes, there is often a separation between the front
office, which is supposed to support the citizen, and the back-
office which is supposed to uphold rules and regulations. In
information systems, separation of duties can be maintained by
role-based access control (RBAC) [29]. Employees have a
personal login, which is linked to the organizational roles they
play and the tasks they are authorized to perform. This in turn
determines which information they should have access to. In other
words: organizational structure prescribes access control. A
common security principle is that employees should only have the
right to access or manipulate data when this is absolutely
necessary for the execution of their tasks (principle of least
privilege) [28]. This principle is opposed to the principle of
transparency found in many open source initiatives where
reliability is maintained by transparency, rather than restriction.
3.4 Data Layer
The essential component of the reporting situation sketched in
Section 2, is the report itself: a message from citizen or company
to regulator, stating that they are compliant with a specific rule or
regulation, because certain facts hold about the business. The
required content of such a message must be specified. Such a
specification consists of representation format (syntax) and a
specification of the meaning (semantics). In the reporting domain,
it makes sense to use an open standard as a representation format.
In PPM the default choice is XBRL, although other variants of
XML can in principle also be used, such as for example HR-XML
for the exchange of data about Human Resource management. For
semantics the default choice is the Netherlands Taxonomy (NT).
Extensible Business Reporting Language (XBRL) is a platform-
independent language based on Extensible Markup Language
(XML) for formatting business information in a way that can be
read across different applications [30]. The fundamental idea of
XBRL is to allow for a separation of reporting facts from
reporting meta-data [30, 31]. Facts are grouped and categorized
by tags: labels which designate the beginning and end of data
elements. For example, this data specifies that the net turnover is
<cbs-bedr:NetTurnover unitRef=”U01_euro”> 12.030
</cbsbedr:NetTurnover>. The intended meaning of the tagged
values is specified by means of so called meta-data: data about
data. Taken together all meta-data forms a so called taxonomy.
The connection is made by means of link-bases: documents
specifying typed links between the referenced elements in XML
or XBRL documents. In practice these links look like URLs
referring to a shared definition repository. In our example, we
have defined a namespace, cbs-bedr, to refer to the taxonomy at
bedrijven. (NT part about Statistics reports for companies).
A specific piece of XBRL with data is called an instance. An
instance is composed of various parts (Figure 5). In addition to
data (e.g. numerical values or text fields), reference is made to the
concepts or attributes which are specified (e.g. net turnover), the
context (e.g. entity number and year to which the data refer), the
currency (e.g. Euro), and additional footnotes or comments. Also
on the conceptual level, a concept (meaning of a tag) is composed
of various parts: the taxonomy providing the definitions of the
concepts contains legal references to laws or standards motivating
the concept definition, calculations or rules, so called dimensions,
and a human readable label, possible in various languages.
Calculations and formulas (rules) are used to specify business
rules, which apply to the data in a XBRL instance. They are ideal
for specifying and automatically verifying formal reconciliation
relations, as used in accounting. For example, the summation of
turnover calculated over October, November and December
separately, should equal the net turnover calculated over the final
quarter. If not, someone made an error and the XBRL instance
should not be accepted as valid.
An instance contains basic data elements. These can be grouped,
structured and presented in different ways, based on the
presentation format chosen. This mechanism can be compared to
style sheets or DTDs in HTML. Data in a single instance can in
principle be used to generate different reports. For example, it
makes sense to present financial data to human users by a
traditional T-shape balance mirroring debit and credit.
Figure 5. Example of the Structure of an XBRL Instance
Generating an XBRL instance from given accounting data is
relatively straightforward. Many commonly used accounting
software applications are already adapted for XBRL. Writing or
adapting a taxonomy is more complex. Taxonomies are written by
experts using special tools. In the case of XBRL, experts must
have a background in accounting or taxation, in addition to
understanding the use of meta-data and taxonomies. Because a
taxonomy is essentially a large set of links (linkbase) a tool is
needed to relate the various cross references and keep an
overview. A list of tools is maintained by XBRL International
( A particularly important aspect of
developing taxonomies is the traceability of the data definitions.
For example, the way in which net turnover or profit should be
calculated for a statistics report is specified by an administrative
decision (Besluit Gegevensverwerving CBS, 2003). The way in
which net turnover or profit should be calculated for a tax report
may differ. Therefore the taxonomy itself should make reference
to the authority from which the definition promulgates.
XBRL is an extensible standard. When required, the standard can
be enhanced with additional definitions for specific domains. For
example, those aspects of the Netherlands Taxonomy which relate
specifically to statistics reporting are addressed in a specific
section of the taxonomy, which is maintained locally, by CBS.
This ability to extend the taxonomy may seem like a great benefit,
because it allows one to develop definitions locally, where
expertise is located. However, allowing extensions is a danger
too: they damage the universal applicability of a standard. A
standard is useful precisely because it removes the need of
individual users to adjust to different circumstances. When
taxonomies are extended for new domains, the individual user will
not be able to follow and use all these extensions. Therefore some
central form of governance and coordination is necessary (see
Section 3.6) For more about the trade-off between extension and
standard, we refer to [32].
3.5 Technical Infrastructure Layer
The main component of the technical infrastructure layer is the
Gateway, which serves as an interface between citizen or
company and regulator. In doing so it provides a public service.
The technical infrastructure layer should seamlessly integrate the
data and process layers. It should provide mechanisms for users to
identify and authenticate themselves, to establish a secure
connection, to provide reports and store them in a dependable
way, and to receive a response whether the report is acceptable
and validated according to the XBRL syntax.
A gateway infrastructure is a way of exchanging information and
must therefore meet certain requirements [33]. Here we mention:
confidentiality, integrity, authentication, non-repudiation,
availability, reliability, scalability, adaptability, maintainability
and usability. Confidentiality means that reports should not be
accessible to any person, apart from the person filing the report
and the people authorized by the regulator to handle the report.
Integrity means that the report should be delivered in exactly the
same state as it was filed. Authentication means that the sender of
a report must be uniquely identified (e.g. by the chamber of
commerce number) and authenticated (e.g. by encryption key).
Once a report has been delivered the sender should not be able to
deny having sent it (non-repudiation). Availability is crucial for a
service on which citizens depend: the service should be accessible
at all times except for previously announced service windows.
Reliability (dependability) means that the system can be relied
upon: it should behave the same in similar circumstances. Finally,
the system should be relatively easy to use and understand in
order to not discourage potential users.
A common way to develop a gateway infrastructure is by a
Service Oriented Architecture [34, 35]. SOA represents a style for
configuring and implementing information system architectures.
A characteristic of SOA is the idea of wrapping functions
provided by different applications as individual services and
preparing them for multiple use. The services correspond to
building blocks, which can represent various functions. Among
the various possibilities of implementing a SOA, using XML in
the form of Web services is most common [36]. Like XBRL, the
main components of Web services are based on XML.
The World Wide Web Consortium (W3C) suggests that three
components are needed for the implementation of web services.
Firstly, a suitable carrier or packaging protocol is required to
enable the exchange of messages between applications. This is
accomplished using the Simple Object Access Protocol (SOAP).
SOAP prescribes the structure of a message, and organizes the
possible function calls between applications [34]. Underneath,
SOAP employs various transport protocols, for example http, ftp
and smtp. Secondly, to use Web services, access to the service
must be ensured by an interface description. It is necessary to
specify which methods and functions are part of a Web Service,
so a call can be processed and answered. For this purpose the
W3C developed one of the most established XML standards, the
Web services Description Language (WSDL) [35]. Third, a
directory service for finding relevant Web services is required.
The Universal Description, Discovery and Integration (UDDI)
standard is such a building block. Web services are registered in
an UDDI with the characteristics of the services offered [34].
3.6 Governance aspects across the layers
SBR is more than technology. It is a set of agreements about
standards and procedures. For this reason, there must be clear
ways of making sure the agreements remain up to date. IT
governance refers        
 [37 p. 261]. Weill and Ross [38] identify three main
governance mechanisms.
1. decision-making structures: organizational committees and
roles that locate decision-making responsibilities [29].
2. alignment processes: techniques for securing widespread and
effective involvement and,
3. formal communications: two-way communication and a good
participation/collaboration relationship
Consider for example updates of a taxonomy. Because the
circumstances change and because laws and regulations are
frequently altered, the taxonomy must also be regularly updated.
How can the update process best be organized? Given the Weill
and Ross model, we have to decide up-front: who has the
authority to decide about changing the taxonomy, how to make
sure updates are aligned with internal processes of the demanding
stakeholders and changes do not have irreparable consequences,
and how can the new version of the taxonomy be announced to
Regarding decision making and responsibilities: often it makes
sense to have a steering committee with representatives of the
gateway infrastructure, the stakeholders, intermediaries and end-
users. A steering committee has the authority to make changes
and should guard uniformity of the standard.
Note that governance aspects change during development.
Initially, in the analysis and design phases, the process is best seen
as a project, with a clear end-point: delivery of a taxonomy. But
after the taxonomy has been taken into use, its maintenance is
better characterized as a standardized work-flow. Therefore it
makes sense to end its project character and put it under
In the Netherlands, the Standard Business Reporting Program
(SBR Program) is a set of innovative projects in the area of
business to government information exchange. In the SBR
Program several government agencies and industry partners
collaborate to simplify and standardize (financial) reporting. This
collaboration is enshrined in an agreement (covenant) that was
signed by over eighty parties, both public and private.
4.1 Data Collection
The research is still in an exploratory phase, so we use a case
study method [39], rather than questionnaires. The purpose is to
identify potential success factors for information system
development and process redesign projects in government,
especially concerning compliance. In particular we want to
evaluate the use of iterative development and strict time-boxing,
and the focus on specific architecture layers, i.e. working
hypotheses (1) and (2). Data for this case study was collected by
various means. We have interviewed and closely examined many
of the issues in the paper with leading experts on the SBR
program in the Netherlands. In addition we used publicly
available information about the SBR program and Netherlands
Taxonomy (see Results were validated
against earlier research on SBR [10], which was conducted
4.2 Case Description
The program started in 2004 as Netherlands Taxonomy Project
(NTP). In 2006, a generic infrastructure project was carried out
drawing up requirements for the a new process infrastructure for
financial reporting based on XBRL. In 2007 the first versions of
the technical infrastructure developed for exchanging the data
were ready. Stakeholders decided that the technical infrastructure
should be maintained by the government IT maintenance agency
Logius (previously GBO.overheid). In 2009 the taxonomy project
was handed over to Logius altogether and a steering group
consisting of senior representatives of all Ministries involved was
appointed. As of 2009, NTP continues under the international
name Standard Business Reporting (SBR). Similar approaches
have been adopted by Australia, and later also New Zealand,
China and Singapore.
Figure 6. SBR landscape with reports and stakeholders
Figure 6 gives an overview of the SBR landscape. On the left we
find a company, and possibly an intermediary (accountant,
bookkeeping, tax consultant etc), who are both supported by
software providers. In the middle we find the various taxonomy
variants chosen for the different reporting streams, and the gate
ways. Institutions demanding reports are shown on the right.
       -scenario. That
means that although the data definitions and the infrastructure
may be re-used over different reporting chains, the actual act of
reporting remains specifically addressed to one agency. The one-
stop-shop scenario (single window) or the continuous monitoring
scenario would be too far reaching. Firstly because it is legally not
allowed to re-use data collected for one purpose, for different
purposes. Secondly, because reports may have a different function
and may therefore have different contents. Thirdly, because data
for different report may have a different quality level, aggregation
level, precision or source.
The figure shows the core SBR program with reporting streams
for CBS (production statistics, investment statistics and short term
statistics, i.e. revenue per period), Chamber of Commerce
(possibility to file the annual financial report) and Tax Office
(revenue taxes (OB), corporate taxes (VpB), income taxes (IB),
intra-EU performance (ICP), and short versions of VbP and IB.
In addition to the core SBR program, there are similar initiatives
developed at UWV and several large banks. UWV is the
government agency responsible for social benefits. They have a
project to standardize the sick-leave reporting process. Employers
must announce to UWV when an employee reports ill at work,
and when they have recovered. This project does not use XBRL
Chamber of
Tax Office
sick leave
all national
end user intermediary representation format gateway report stakeholder
but HR-XML, a variant of XML for Human Resource
management. UWV will use the same technical infrastructure
(Digipoort) as the core SBR program. There is also a project
related to Electronic Purchasing and Invoicing, which should
streamline purchasing at a national scale. This project makes use
of electronic invoices represented in XBRL. All invoices which
are being sent to a national agency can currently be presented in
XBRL. Finally, a consortium of banks are involved in a similar
project to standardize the loan approval process. They have
chosen to develop their own gateway, called Rapportage Portaal.
The banks have developed an extension of the NT, but have
agreed to follow all updates and releases of the official NT, so
efficient reuse does remain possible (in principle). The technical
infrastructure for identification and authentication of business
parties is currently being streamlined in a project called E-
herkenning (E-recognition), which should in the long run replace
and standardize existing identification and authentication
solutions. This is not listed in the figure.
4.3 Issues and Dilemmas
Below we will discuss several issues and dilemmas in the context
of the development phases and layers, and how they have been
dealt with. This provides interesting insights in SBR.
Development Phases
The development phases are enforced quite strictly. Figure 7
shows a development schedule as it has been used in several roll-
out projects in the SBR domain. There are two crucial go/no go
decisions. One after the analysis and design phase, when
commitment is needed that the project will go ahead as specified
in the blueprint. Note that analysis and design are merged. This
does not mean that a requirements specification (analysis) and a
design (blueprint) should not be separate deliverables, but rather
that determining requirements and developing ideas about what is
feasible should be intertwined. Another reason is that these phases
involve similarly skilled people: visionaries and architects, with
an eye for unforeseen possibilities. By contrast, the
implementation phase needs project managers who get the job
done. In the third phase the implemented process and technology
components are deployed in practice. Initially this is done in a
small application area. Only after evaluation and acceptance of the
working solution, possibly after alterations to the analysis and
design documents, and with an enriched business case, a roadmap
can be drawn up to scale up deployment in other application areas.
This also involves a marketing plan to make sure external parties
(companies, intermediaries) will adopt the new way of reporting.
Figure 7. Development schedule chart in use within SBR
Process layer
We discuss a dilemma concerning feedback reports. Consider
once again Figure 3. Suppose you have just filed a tax report for
revenue tax. Shortly thereafter you receive a feedback response
from Digipoort that the message was received in order. You
conclude that you have satisfied your legal duty to report.
However, later the tax office discovers that the tax report you
submitted is faulty. Although it was validated as correct XBRL,
economically it makes no sense. For instance the revenue reported
was 10 times as much as could be expected from other key data,
like sales and salary costs. You will have to re-submit. But what if
the fault only appears much later? Can we expect a company to
debug and re-submit a tax declaration concerning data which are
no longer current? And what about the feedback response? The
response is sent by a technological infrastructure, Digipoort, on
the basis of syntactic validation. What is its legal status? Giving
no response at all would be bad from a usability point of view:
users want to know if they succeeded in filing a report. But a
response appears to come from the tax office directly.
Data layer
Concerning the data layer we discuss the dilemma of allowing
extensions, versus uniformity of a standard (Section 3.4). As was
explained above, the general policy in the SBR program is to
prefer the NT taxonomy, but to also allow other open standard
data formats for specific domains (UBL, HR-XML). In the case of
the banks, an intermediate solution is chosen. Banks use their own
extension of the taxonomy, but in the release schedule they follow
updates of the NT. Therefore users can still expect to be able to
re-use the common data part.
Another issue concerns the possibility of XBRL generating
different reports from the same data, by using presentation
formats. This leads to a legal problem. By law, an accountant
verifies whether the annual financial statements   
imageof commercial reality. When the metaphor of an image is
taken too literally, this means that the accountant can only take
responsibility for the reliability of a document in its actual
presentation; not for the underlying data elements. After all,
presentation formats could leave some relevant data elements out,
and not only accuracy but also completeness of the reported data
are testified by the accountant. This issue still needs to be settled
by experts of the Dutch accountants association Royal NIVRA.
Technical Infrastructure layer
In the SBR program, the role of gateway is played by Digipoort.
SBR uses open technology standards were possible, like XBRL,
An interesting dilemma concerns authentication. Originally,
intermediaries who were authorized to file reports on behalf of
their clients, needed to prove this using a complicated
authentication procedure, with credentials provided by
commercial Authorization Service Providers (AuSP). However,
this process is complicated and difficult to understand for end-
users. Also, AuSPs are commercial parties who charge a fee for
the authentication service. This has lead to resistance among end-
users. Recently therefore, the user platform decided to drop the
AuSP requirement in favour of usability and accessibility.
Compensating measures exist, because all parties logging into
Digipoort must already authenticate with usual PKI government
credentials; the report itself identifies the party.
Table 2. Annual release schedule of taxonomy versions
Available for
1st of May
Taxonomy partners
1st of November
Taxonomy partners
15th of November
Market parties
1st of December
Version 20xx
All parties
Analysis and Design Implementation Controled Deployment Scale up
Go / No Go Go / No Go
Detailed Analysis
Implementation Plan
Business Case
(Extension) Taxonomie
Implemented Process
XBRL enabled
Acceptance Agreement
Evaluation Report
Enriched Business case
Marketing plan
Governance issues
A strict release schedule is maintained for different stakeholders.
In this way, partners can test and use the taxonomy so possible
defects are found -- before troubling market parties (Table 2).
According to the Weill and Ross model of information technology
governance we need to determine three things. First,
responsibilities are laid down in the following organization chart
(Figure 8). SBR is governed by a council, in which all major
stakeholders have a say. User groups are represented in the SBR
platform. They can give feedback on the way the program
develops. The platform is supported by three expert groups, one
for data, one for processes and technology and one for marketing
and communications. Expert groups are meant to initiate, discuss
and solve current issues. This structure ensures that all major
stakeholders have a say, while also guaranteeing enough expertise
to reach workable solutions. Second, we need to ensure alignment
among stakeholders. The actors in the SBR domain form a
network, who share a data standard (NT) and provide a service: an
information processing chain for reporting applications. Therefore
there are frequent meetings (e.g. platform meetings; expert group
meetings) to make sure parties know of reported issues and
scheduled changes. Regarding adoption by end users, a
professional marketing and communications plan is maintained.
Third, formal communication procedures must be strictly
followed. For example, before releasing a new version of the
taxonomy, it must be tested by all stakeholders. Now suppose one
party did not perform the test and the release has to be postponed.
This needs to be communicated in a uniform way.
Figure 8. Organization structure of taxonomy management
4.4 Discussion
Now that we have seen the development phases and layers, we are
in a position to review how PPM deals with the challenges we
identified in Section 2 in the case of SBR.
1. Legal requirements. Legal requirements and additional
requirements from stakeholders are dealt with in the data layer.
They are part of taxonomy definitions themselves. Changes to
these definitions are carefully managed by a release schedule, and
frequent meetings (expert meetings, platform meetings).
2. Provenance. Because SBR has chosen    
approach, the resulting differences in content and quality of
information are no problem. Users still prepare each report
separately, but they can reuse data representations and underlying
software support systems. Provenance issues are dealt with in
data, process and technological layers simultaneously.
3. Process compliance. Process compliance can be ensured by
examining BPMN process models. These models can be
understood be (some) legal experts, who can interpret the law and
other regulations to determine whether the new solution respects
process restrictions.
4. Multiple stakeholders. There are several ways in which the
dynamics of a landscape with many players is managed. There are
various coordination and governance mechanisms, like a clear
organizational structure and frequent meetings. If still no
agreement can be reached it is possible that stakeholder groups
develop their own extension. In that case the procedures can still
be aligned as in the case of the banks. During development,
feature creep can be avoided by time-boxing and prioritizing
issues for the next release. A general principle for project
management in multi-actor networks is that the more diverse the
interests, the stricter the procedures for coordination and
communication must be, compare [40].
Companies have to file many compliance reports, to both private
and public institutions. Projects have been undertaken to redesign
the reporting streams by a standardized representation format like
XBRL and a shared taxonomy with technological support and
procedures and agreements. Managing such projects is hard,
because it involves the interplay of design decisions concerning
data, processes, technology and alignment of many stakeholders.
In particular, redevelopment projects in the reporting domain must
deal with legal data requirements, provenance issues, process
compliance and interests of many stakeholders. To meet these
challenges, several best practices have been developed under the
name of Public Process Management (PPM). PPM has two main
working hypotheses: (1) to maintain a development scheme with
strict deadlines (time-boxing) so progress is made visible and new
visions remain feasible, and (2) to focus on process, data and
technological layers, as well as governance issues.
In this paper we have argued that PPM can deal with the four
challenges we identified for the reporting domain. We have
provided evidence of the two working hypotheses with reference
to a case study of the SBR program in the Netherlands. In
particular, we explained that several combinations of the XBRL
format, the Netherlands Taxonomy or its extensions and the
Digipoort infrastructure can be reused in different configurations.
Also we have shown that a clear organizational structure and
governance procedures are necessary.
An interesting observation concerns the balance between
restrictive and flexible project management strategies. In a
political networked environment, project management methods
like PPM need to balance between  
behavior and providing flexibility for participants to develop
solutions which fit their needs [17, 40]. For example, time-boxing
is restrictive; it fixes the duration of a project phase. Therefore
other variables, such as the content to be provided or the priorities
of issues must remain flexible. Similarly, the possibility to
develop an extension to the Netherlands Taxonomy, as in the case
of the banking portal, provides flexibility in the data layer. That is
only possible given the fact the banks have restricted themselves
to following the release schedule of the Netherlands Taxonomy.
As a general conclusion, we could say that although none of the
techniques which make up PPM are by themselves very new or
innovative, the fact that these concepts are used together in a
cohesive way is novel, at least in government information
technology projects. Reports have shown that the successful
adoption of XBRL and the objective of reducing administrative
burden, is still a long way ahead [10]. Mistakes have been made.
For instance, an initial focus on technology while neglecting
business models for adoption, may have lead to a delay. But the
PPM methods we have reported on here, demonstrate that there
are ways of dealing with these issues. In the end, best practices are
just that: practices which have been shown to be useful. We hope
this paper will help others avoid some of the pitfalls and mistakes
that are inevitably made in a complex project like this.
SBR Council
SBR Platform
Expert Group
Expert Group
Processes and
Expert Group
Marketing and
SBR Program
1. Power, M., The Audit Society: Rituals of Verification. 1997:
Oxford University Press.
2. Wimmer, M.A., Integrated Service Modelling for Online
One-stop Government. Electronic marktes, 2002. 12(3): p.
3. Alles, M., et al., Continuous monitoring of business process
controls: A pilot implementation of a continuous auditing
system at Siemens. Accounting Information Systems, 2006.
7: p. 137161.
4. Tan, Y.H., et al., eds. Accelerating Global Supply Chains
with IT-Innovation. 2011, Springer Verlag, Berlin.
5. McAfee, A., When too much IT knowledge is a dangerous
thing. MIT Sloan Management review, 2003: p. 83-89.
6. Heeks., R., e-Government as a Carrier of Context. Journal of
Public Policy, 2005. 25: p. 51-74.
7. Algemene Rekenkamer, Lessen uit ICT-projecten bij de
overheid Deel A. 2007, Algemene Rekenkamer.
8. Keen., P.G.W., Information systems and organizational
change. Communications of the ACM, 1981. 24(1): p. 24-33.
9. Hammer, M., Reengineering Work: D 
obliterate. Harvard Business Review, 1990. Jul/Aug: p. 104-
10. Janssen, M., et al., Uit het Zicht: Beleidsmaatregelen voor het
versnellen van het gebruik van ICT-toepassingen voor
administratieve lastenverlichting. 2010, Technische
Universiteit Delft: Delft.
11. OECD, Forum on Tax Administration: Taxpayer services
sub-group, Guidance Note on Standard Business Reporting.
2009, OECD.
12. White, S.A. and D. Miers, BPMN Modeling and Reference
Guide: Understanding and Using BPMN. 2008: Future
Strategies Inc., Lighthouse Pt, FL.
13. Huemer, C., et al., B2B Services: Worksheet-Driven
Development of modeling Artifcats and Code. The Computer
Journal,, 2009. 52(8): p. 1007-1027.
14. Robey, D., G. Im, and J. Wareham, Theoretical foundations
of empirical research on inter-organizational systems:
assessing past contributions and guiding future directions.
Journal of the Association for Information Systems, 2008.
9(9): p. 497-518.
15. Hulstijn, J., et al., Continuous Control Monitoring-based
Regulation: a case in the meat processing industry, in GRCIS
2011, M. Indulska, et al., Editors. 2011, Springer Verlag
16. Power, M., Organized Uncertainty: Designing a World of
Risk Management. 2007: Oxford University Press.
17. de Bruijn, J.A. and E.F. ten Heuvelhof, Network and
Decision Making. 2000: Lemma, Utrecht, Netherlands.
18. Jones, C., Strategies for managing requirements creep.
Computer, 1996. 29(6): p. 92-94.
19. Martin, J., Rapid application development. 1991: Macmillan
Publishing, Indianapolis, IN.
20. Larman, C. and V.R. Basili., Iterative and Incremental
Development: A Brief History. IEEE Computer, 2003. June.
21. Sage, A. and W. Rouse, Handbook of Systems Engineering
and Management 2ed. 2009: Wiley.
22. Cardoso, J. and W.M.P. van der Aalst, Handbook of
Research on Business Process Modeling. 2009: Information
Science Publishing, Hershey, PA, USA.
23. Lankhorst, M., ed. Enterprise Architecture at Work:
Modelling, Communication and Analysis. 2009, Springer
Verlag: Berlin.
24. Davenport, T.H., Process innovation: reengineering work
through information technology. 1993: Harvard Business
School Press.
25. Davies, I., et al., How do practitioners use conceptual
modeling in practice? Data and Knowledge Engineering,
2006. 58(3): p. 358-380.
26. Brooks, F.P., No silver bullet: essence and accidents of
software engineering. IEEE Computer, 1987. 20(4): p. 10-19.
27. Mintzberg, H., The Structuring of Organizations: A Synthesis
of the Research. 1979: Prentice Hall.
28. Knechel, W., S. salterio, and B. Ballou, Auditing: Assurance
and Risk. 3 ed. 2007: Thomson Learning, Cincinatti.
29. Sandhu, R.S., et al., Role-Based Access Control Models.
IEEE Computer, 1996. 29(2).
30. P. Engel, et al., Extensible Business Reporting Language
(XBRL) -- Recommendation. 2003, XBRL International,.
31. Spies, M., An ontology modelling perspective on business
reporting. Information Systems, 2010. 35: p. 404-416.
32. Wagenhofer, A., Economic Consequences of Internet
Financial Reporting, in New Dimensions of Business
Reporting and XBRL, Roger Debreceny, Carsten Felden, and
M. Piechocki, Editors. 2007, Springer Verlag, Berlin. p. 99 -
33. A.W Duthler and M. Voulon, Het juridisch kader van
betrouwbaar elektronisch berichtenverkeer. IT en Recht.
2010: Kluwer Academic.
34. Newcomer, E. and G. Lomow, Understanding SOA with
Web services. 2005, NJ: Pearson Education.
35. Erl, T., Service-Oriented Architrecture - Concepts,
Technology, and Design. 2006, Upper Saddle River, NJ:
Pearson Education.
36. Marks, E. and M. Bell, Service-Oriented Architecture: A
Planning and Implementation Guide for Business and
Technology. 2006, Hoboken: John Wiley and Sons.
37. Sambamurthy, V. and R.W. Zmud, Arrangements for
Information Technology Governance: A Theory of Multiple
Contingencies. MIS Quarterly, 1999. 23(2): p. 261-290.
38. Weill, P. and J. Ross, A matrixed approach to designing IT
governance. MIT Sloan Management Review, 2005. 46(2): p.
39. Eisenhardt, K.M., Building Theories from Case Study
Research. Academy of Management Review, 1989. 14(4): p.
40. Koppenjan, J.F.M. and E.H. Klijn, Managing Uncertainties in
Networks. 2004: Routledge, London.
... Bharosa et al. (2011) studied the SBR implementation in the Netherlands and found seven key transformation principles: (1) Make SBR a by-product of the data already in the company's accounting systems, (2) Include controls for auditing in software, (3) Keep the business focus, (4) Position SBR as a cross-government policy initiative, (5) Stimulate private sector involvement, (6) Combine restrictive and flexible project management strategies, and (7) Underline the attention given to end-to-end security over the reporting chain. Hulstijn et al., (2011) also studied the Dutch SBR implementation and identified issues and dilemmas associated with the development schedule, process, data and technical infrastructure layers, as well as governance. While these principles offer a useful guide to stakeholders in increasing the general awareness of SBR and assist in setting up an SBR program, we noted a lack of studies addressing the specific task of developing the associated taxonomy. ...
... While previous research Hulstijn et al., 2011) offers guidelines on how to successfully implement SBR programs overall, our study focuses on the specific phase of taxonomy development in the SBR program. Due to the nature of SBR, which requires the concerted efforts of several government agencies as well as private organizations, our design principles highlight the co-creation aspects of the standard development. ...
Full-text available
Standard Business Reporting (SBR) is a consolidated reporting model for the digital transmission of financial data to several statutory bodies. It requires the development of a national taxonomy, which facilitates the joint tax, statistics and financial reporting through a common government gateway, thus reducing the administrative burden of statutory reporting. An SBR program is a complex and innovative project that requires the co-ordination of public and private constituencies. Drawing on the findings of a longitudinal study in the Finnish SBR program, we contribute to the literature by identifying a set of design principles for SBR taxonomy development: (1) competence, (2) win-win-win vision, (3) multi-channel communication, (4) intelligent scope, (5) expertise commitment, (6) track record, and (7) co-creation. These principles were derived from an inductive analysis of empirical data collected from multiple sources. Our findings offer a guide that will be useful to other jurisdictions embarking on similar SBR initiatives.
... Die dezentrale Bearbeitung von Behördenkontakten führt jedoch dazu, dass Unternehmen teilweise Daten redundant an unterschiedlichste Verwaltungseinheiten übermitteln müssen. Diese Daten werden außerdem oftmals dezentral und teilweise redundant im Unternehmen vorgehalten [Hu11]. Beim Sammeln und Übermitteln entsteht hierdurch für einzelne Unternehmensbereiche ein großer Aufwand, welcher sich in den Bürokratiekosten niederschlägt. ...
... Beim Sammeln und Übermitteln entsteht hierdurch für einzelne Unternehmensbereiche ein großer Aufwand, welcher sich in den Bürokratiekosten niederschlägt. Unternehmen und Verwaltungen streben deshalb zum einen die automatisierte Abwicklung der Informations-und Meldepflichten an, indem auf zentrale Datenbestände im Unternehmen zugegriffen wird und somit Aufwand und Bürokratiekosten reduziert werden [LR00;Hu11], und zum anderen die Reduktion von redundant zu übermittelnden Informationen und Daten [WJK10]. ...
... Several studies suggested two scenarios to implement the SBR initiatives (OECD, 2009;Hulstijn et al., 2011;Eierle et al., 2014): The first scenario is shown in Figure 2, called "One-stop shop" architecture. All statutory business reports are filed through a "common gateway" to multiple government agencies, as shown in Figure 2. ...
Full-text available
Few studies have comprehensively described Standard Business Reporting (SBR) as a policy-driven initiative based on inline eXtensible Business Reporting Language (iXBRL) aimed at reducing the administrative burden of statutory business reporting. The SBR term is still difficult to understand even by the countries where it has been implemented. The objective of this study is twofold. First, it describes in detail the evolution of the SBR initiatives in the UK. Second, it investigates the drivers and inhibitors of the take-up of the SBR initiative by small businesses based on the technology, organization, and environment (TOE) framework. It draws on contextual data and 23 interviews with participants involved in the development of these initiatives. The findings show that the following are perceived as drivers of the take-up of the SBR initiatives by small private companies: the relative advantages of using WebFiling, commercial filing software, and the digital services, the organizational accountant's readiness, and the influence of commercial filing software. However, we find no evidence that the relative advantage of using the joint-filing facility via iXBRL was perceived as a driver of the take-up of this innovation. The findings indicate that the absence of critical mass among government agencies inhibits its diffusion. This study provides specific implications to small businesses, the accountants working in small businesses and practice, government agencies in the UK, and other jurisdictions embarking on the SBR initiatives for further developments to reduce the reporting burden on smaller entities.
... Regarding the impact of ABR initiatives on increasing the ease of doing business (i.e. business), most studies focus in Eastern European [18,32,54,59], and Northern European countries [6,9,10,26,52]. However, there are also case studies for East Africa [35]. ...
Conference Paper
Burden reduction is a key issue in modern public administrations’ and businesses’ agendas. Compliance with mandatory regulations can have a direct impact on a country’s economic performance, growth, and development. Research in this area, contributes to a better understanding of the implications and context of administrative burden, and increases the efficiency of the strategies adopted to reduce it. The goal of this study is to undertake a review of the current state of the art on Administrative Burden Reduction (ABR), in order to gain a deeper insight about the subject, identify current gaps, and better plan for future research. A total of 122 papers were identified as relevant, out of a pool of 742 papers retrieved from the current literature. The relevant papers were analyzed across four dimensions: methodology, type and focus, and targeted stakeholders. Three key gaps were identified and discussed in relation to: citizen orientated services and burden reduction; empirical research and post-initiative re-evaluation; and, the role of stakeholders, interest groups and end-users in driving ABR. Lastly a conceptual framework model and next steps are proposed.
... We also found three studies that directly link to the use of XBRL in the public sector; for example, the implementation of an XBRL taxonomy by the Dutch Government for national statistics purposes (Roos 2010), the implementation of Standard Business Reporting (SBR) in Australian Government (Madden 2011), and the adoption of XBRL at U.K. Companies House (CH) (Mousa 2010). We found this limited research somewhat surprising as numerous papers related to XBRL implementation in public organizations can be found in professional journals (see, e.g., Abdolmohammadi, Harris, and Kenneth 2002;Kull 2008;Kull and Chon 2008), research reports (e.g., Abraham and Kull 2008), conference papers (e.g., Hulstijn et al. 2011;Ida 2012), and book chapters (e.g., Mauss, Bleil, Balloni, and Vanti 2008;De Winne, Janssen, Bharosa, van Wijk, and Hulstijn 2013). Global XBRL implementation has largely tended to support government management of companies' financial reports (Debreceny and Farewell 2010b). ...
Extensible business reporting language (XBRL) was developed from an established markup computer language (eXtensible Markup Language, XML). XBRL facilitates data and information exchange between different information systems (IS). This important feature has attracted much research since the early 2000s. This article aims to provide a framework for XBRL research's contributions to information systems (IS). An integrative review is needed to draw an overall picture and canvas key findings regarding the various XBRL topics examined in past studies. Such a review also identifies research opportunities, and guides future XBRL research. We conducted thematic analysis using an integrative literature review. A sample of 150 XBRL articles obtained from various peer-reviewed academic journals was used to understand past XBRL studies and suggest XBRL's future research direction. This article identifies and proposes four current XBRL research streams, namely, XBRL's impact on business, XBRL's adoption, XBRL's technical development, and XBRL education. This paper then examines the key findings of these XBRL papers, offers several potential areas where further investigation may be warranted, and suggests XBRL research-informed practices.
Standards play an important role in the interoperable exchange of information among actors with different business functions. Particularly in government, standards enhance communication between public administrations and lay the ground of interoperability in e-government service provision. Still, practice often struggles with numerous challenges such as complex administrative procedures, jurisdiction, numerous stakeholders with diverging wants and needs and the ultimate goal of social welfare. At the same time, academia provides a limited number of approaches to address existing challenges and transferring findings from a private organizations' context is rarely a viable approach. The authors introduce effective management of standardization in e-government by describing the shape of standardization in that specific domain and by encompassing suitable coordination mechanisms. They follow a qualitative explorative research approach and apply coordination theory to pragmatically interpret our findings, offering implications for both theory and practice.
The higher education institutions worldwide aim to enhance the efficiency and quality of teaching and learning and to increase their competitiveness on national, regional and global levels. The challenge is how best to meet both national and international standards. In response, the Higher Education Accreditation Commission (HEAC) recently, sets eight standards for the external quality assurance of Jordanian higher education institutions which enabling them to gain the quality assurance certificate (QAC). In line with this, Al-Zaytoonah University of Jordan (ZUJ) is seeking to meet these standards by keeping all accreditation and quality assurance documents as required by the HEAC. Although various types of educational technologies have been employed by Jordanian universities to meet the accreditation and quality assurance standards (i.e. e-Learning, e-library, e-forms, etc.), none of them drives out all duplicated data and unnecessary descriptions of files. This paper proposes eXtensible Mark-up Language and its applications as a mechanism for digitising the filing system employed and presents two scenarios for managing its implementation at the ZUJ. To the authors’ knowledge, this is the first study to manage the digital filing project in Jordan. The study contributes to the emerging literature by extending our knowledge of the digital filing system. The findings should be of interest to the presidents of private universities, heads of quality assurances offices. They will also be of interest to professional accrediting bodies seeking to improve the quality assurance aspects to provide accreditation to private universities in Jordan and to other jurisdictions in other countries.
Last years have been characterized by an increasing need for transparency towards public organizations with a pressing request for publishing on line official documents and financial data. In this context scholars and operators opened a discussion on the adoption of XBRL in public organizations to promote wide diffusion and timely use of financial data. The aim of this paper is to conduct a theoretical analysis to understand whether XBRL could be easily adopted by Italian public organizations. The analysis highlights criticalities related to the definition of the XBRL taxonomy due to the heterogeneity of accounting information systems of public organizations. It shows also that the coding system of the mandatory integrated chart of accounts could offer perspectives to XBRL adoption.
In an era of wicked social problems, a smarter, more responsive, more efficient governance structure is necessary to take advantage of the enormous capability of the public to congregate, interact, and collaborate in finding solutions to intricate sociotechnical challenges. The bedrock for such a structure is open and shared information; the key to opening and sharing information lies in interagency information sharing and integration. With the objective to supplement previous research based on rich qualitative data, this study systematically identifies and tests some important determinants of the success of inter-organizational collaboration and information sharing initiatives through quantitative empirical analysis. Based on a national survey of government managers from two policy domains (criminal justice and public health) in the United States, this study found four statistically significant predictors of inter-organizational information sharing success. From those, we found compatibility of technical infrastructure and formally assigned project managers as the two most important predictors explaining the success of inter-organizational information sharing initiatives.
Full-text available
An enterprise architecture tries to describe and control an organisation?'s structure, processes, applications, systems and techniques in an integrated way. The unambiguous specification and description of components and their relationships in such an architecture requires a coherent architecture modelling language. Lankhorst and his co-authors present such an enterprise modelling language that captures the complexity of architectural domains and their relations and allows the construction of integrated enterprise architecture models. They provide architects with concrete instruments that improve their architectural practice. As this is not enough, they additionally present techniques and heuristics for communicating with all relevant stakeholders about these architectures. Since an architecture model is useful not only for providing insight into the current or future situation but can also be used to evaluate the transition from ?as-is? to ?to-be?, the authors also describe analysis methods for assessing both the qualitative impact of changes to an architecture and the quantitative aspects of architectures, such as performance and cost issues. The modelling language and the other techniques presented have been proven in practice in many real-life case studies. So this book is an ideal companion for enterprise IT or business architects in industry as well as for computer or management science students studying the field of enterprise architecture. © Springer-Verlag Berlin Heidelberg 2005. All rights are reserved.
- This paper describes the process of inducting theory using case studies from specifying the research questions to reaching closure. Some features of the process, such as problem definition and construct validation, are similar to hypothesis-testing research. Others, such as within-case analysis and replication logic, are unique to the inductive, case-oriented process. Overall, the process described here is highly iterative and tightly linked to data. This research approach is especially appropriate in new topic areas. The resultant theory is often novel, testable, and empirically valid. Finally, framebreaking insights, the tests of good theory (e.g., parsimony, logical coherence), and convincing grounding in the evidence are the key criteria for evaluating this type of research.
One of the major challenges for European governments is to solve the dilemma of increasing the security and reducing fraud in international trade, while at the same time reducing the administrative burden for commercial as well as public administration organisations. To address these conflicting demands, the ITAIDE project has developed a large set of innovative IT-related tools and methods that enable companies to be better in control of their business operations. These tools and methods have been integrated in the ITAIDE Information Infrastructure (I3) framework. By using the I3 framework, companies are better positioned to apply for the Trusted Trader status, and enjoy trade facilitation benefits such as simplified customs procedures and fewer inspections of their goods. Hence, the I3 framework can contribute to making global supply chains faster, cheaper, and more secure. The I3 framework has been tested and validated in five real-life Living Labs, spanning four different sectors of industry, and conducted in five different EU countries. National Tax & Customs organizations from various European countries have actively participated in the Living Labs. The United Nations CEFACT group, experts from the World Customs Organization and representatives of key industry associations have also provided valuable feedback and ideas for the Living Labs and the project in general. © Springer-Verlag Berlin Heidelberg 2011. All rights are reserved.
An enterprise architecture tries to describe and control an organisation's structure, processes, applications, systems and techniques in an integrated way. The unambiguous specification and description of components and their relationships in such architecture requires a coherent architecture modelling language. Lankhorst and his co-authors present such an enterprise modelling language that captures the complexity of architectural domains and their relations and allows the construction of integrated enterprise architecture models. They provide architects with concrete instruments that improve their architectural practice. As this is not enough, they additionally present techniques and heuristics for communicating with all relevant stakeholders about these architectures. Since an architecture model is useful not only for providing insight into the current or future situation but can also be used to evaluate the transition from 'as-is' to 'to-be', the authors also describe analysis methods for assessing both the qualitative impact of changes to an architecture and the quantitative aspects of architectures, such as performance and cost issues. The modelling language and the other techniques presented have been proven in practice in many real-life case studies. So this book is an ideal companion for enterprise IT or business architects in industry as well as for computer or management science students studying the field of enterprise architecture.
An enterprise architecture tries to describe and control an organisation's structure, processes, applications, systems and techniques in an integrated way. The unambiguous specification and description of components and their relationships in such architecture requires a coherent architecture modelling language. Lankhorst and his co-authors present such an enterprise modelling language that captures the complexity of architectural domains and their relations and allows the construction of integrated enterprise architecture models. They provide architects with concrete instruments that improve their architectural practice. As this is not enough, they additionally present techniques and heuristics for communicating with all relevant stakeholders about these architectures. Since an architecture model is useful not only for providing insight into the current or future situation but can also be used to evaluate the transition from 'as-is' to 'to-be', the authors also describe analysis methods for assessing both the qualitative impact of changes to an architecture and the quantitative aspects of architectures, such as performance and cost issues. The modelling language and the other techniques presented have been proven in practice in many real-life case studies. So this book is an ideal companion for enterprise IT or business architects in industry as well as for computer or management science students studying the field of enterprise architecture.
The eXtensible Business Reporting Language, or XBRL, is a royalty-free language based on XML that provides for a standardization of method and content in the exchange of business information. XBRL aims to reduce inefficiencies in data exchange and analysis, coupled with an improved comparability of information. The first taxonomies based on XBRL have: identified opportunities for significant improvement in the efficiency of data exchange and automated analysis. shown that comparisons between and the compatibility of information within business reports have not improved due to XBRL.