2015年7月

Audit Data Standards

Base Standard
2015年7月版

AuditDataStandards.Base.July2015
監査データ標準(基礎編)(2015年7月)

Prepared by the AICPA Assurance Services Executive Committee
Emerging Assurance Technologies Task Forceaicpa.org/FRC
www.aicpa.org/FRC

Copyright © 2015 by American Institute of Certified Public Accountants, Inc. New York, NY 10036-8775
Permission is granted to make copies of this work provided that such copies are for personal, intra organizational, or
educational use only and are not sold or disseminated and provided further that each copy bears the following credit line:

本資料の複製は、個人利用、社内利用、または教育目的の場合のみ、かつ、販売または流布および提供目的ではない場合に、複製物に以下の文言を含めることで許可される。
“Copyright © 2015 by American Institute of Certified Public Accountants, Inc. Used with permission.”

Copyright © 2015 by American Institute of Certified Public Accountants. All rights reserved. Translated with permission.

なお、日本語の本仮翻訳は、AICPA の許可のもと、XBRL Japan 開発委員会 ADS サブワーキング（SWG リーダー 公認会計士 木村章展）が実施をした。英語の原文が正である。今後、AICPA での ADS の改訂などを受けて、予告なく翻訳を改訂する場合もある。

Page 2 of 18

Assurance Services Executive Committee (2014-2015)
Robert Dohrer, Chair
Dorsey Baskin
Bradley Beasley
Greg Bedard
Nancy Bumgarner
Chris Halterman
Charles E. Harris

Don Kluthe
Chris Kradjan
Michael Ptasienski
Beth A. Schneider
Miklos Vasarhelyi
Deetra B. Watson
Don Pallais (Observer)

Emerging Assurance Technologies Task Force
Audit Data Standard Working Group
William R. Titera, Chair
Glenn Galfond, Lead
Paul Barbour
Karl Busch
Eric E. CohenCharles E. Harris
Kristine Hasenstab

Steven HenchockMark Mayberry
Phillip McCollough
Josh Phillips
Joel Pinkus
Miklos Vasarhelyi

Additional Contributors
D.J.Elmore
Gianluca Garbellotto

AICPA Staff
Amy Pawlicki

Dorothy McQuilken

DirectorBusiness Reporting, Assurance &Advisory Services

ManagerBusiness Reporting, Assurance &Advisory Services

Page 3 of 18

Audit Data Standards 監査データ標準
標準化の利点はよく認識され、様々な一般的な IT 標準の開発に結びついている。データ標準が必要な理由は、企業1のデータの効率的な交換に直面しているマネジメント、内部監査人および外部監査人にとって継続した問題である。このプロセスは、経理部門および IT 人員が異なる観点からこのような情報を要求することから複雑になる。例えば、ある場合には、監査関連のデータ依頼は、経理部門からより関与に制限のある企業の IT 部門へ直接転送される。多くの場合では、監査人にとってデータ要求は負担である。
AICPA アシュアランスサービスエグセクティブ委員会は監査および他の関連する目的のために一般に要求されるファイルとフィールドのためのフォーマットの標準化によって監査プロセスの効率性および有効性にこの監査データ標準(ADS)が貢献するだろうと考えている。同様に、もし企業が内部監査人および外部監査人などとデータを共有することを決めれば、標準化された情報(債権者のような)の他の消費者も利益を得るであろう。大企業、そして中小企業、公開若しくは非公開企業は、監査データ標準の適用からさらに利益を得るかもしれない。監査人によって定期的に要求されたデータの標準化によって、企業は情報の要求プロセスを自動化し、複製することができ、それによって、要求されたデータを提供するのに必要な時間と労力を減らすことができる。さらに、企業のスタッフおよび内部監査人は、内部目的のための標準化されたデータを利用することにより強化された解析能力から利益を得るであろう。さらに、この標準はそのデータを外部監査人が強化されたデータ分析を行なうのに利用可能とするであろう。
これらの標準は、良く設計された会計および財務報告システムに導入することができるすぐれた慣行である。この監査データ標準の現在の公表物は、総勘定元帳、売掛債権、受注・入金、および仕入・支払と関連があり、在庫、買掛債務、固定資産、給与などの補助元帳の監査データ標準が将来加えられることを意図している。
監査データ標準はテクニカル・デザイン(ファイル、テーブル、フィールド、フォーマットなど)、およびその使用についての理解にとって不可欠なデータに関する補足的質問を提示している。前者は、通常 IT システム設計に対して提示されることが適している。後者は、一般的に経理あるいは財務担当者によって、IT 担当者からの入力による情報が提供される。これらが情報の抽出のための任意の推奨されたデータ標準であることに留意すること。これらのデータ抽出標準は必須のものではない。
また、権威のある監査あるいは会計基準から提示されたものでもない。
特に規模および産業特性により、均一性の価値および個々の企業への適応の利点を認識して、これらの標準は、ある程度の柔軟性を提供する。これらの標準は、各国特有の要件に対応しており、国際的な適用が可能である。これは最低の標準で、制限するのが目的ではない。したがって、ユーザはユーザ定義のフィールドをカスタマイズして、作成してもよい(例えば、項目は除かれるべきではない。
しかし、標準にまだ存在しないところで、項目が加えられるかもしれない)。しかしながら、標準化(特に示されなかった時)の利点を達成するために、個々のカスタマイゼーションは回避されるべきである(言いかえれば、項目が標準に定義されている場合は、それを再定義しない)。一旦企業が特定の取り決めを採用すれば、主な IT システムの変更の実施や標準化されたデータの供給者および利用者

1

この表現としての企業は、企業、パートナーシップ、政府機関、非営利事業体などを表現するために意図され、営利団体に限定されるものではないことに留意する。

Page 4 of 18

の相互に合意された拡張がない限り、一貫してこの取り決めによってそのデータを提供するべきである。
監査データ標準の規約は、そのデータ標準の設計者が携わった大多数のシステムからの要求を基に設計された。つまり、フラットファイル(パイプ区切り)のフォーマットでは、「反復性」がある特定のフィールドは特定の数字で固定されたことを意味する。次のような場合である。
監査データ標準(基礎編)の Business_Unit_Listing: Business_Unit_Hierarchy[1] – [5]監査データ標準(総勘定元帳編)等の GL_Detail_YYYYMMDD_YYYYMMDD:
 Segment[01] – [05]監査データ標準(売掛債権編)または(受注・入金編)の Customer_Master_YYYYMMDD: 住所および請求先住所
 監査データ標準(仕入・支払編)等の Invoices_Received_YYYYMDD_YYYYMMDD
 GL_Debit_Account_Number および GL_Credit_Account_Number
最後の例では、入力行には貸方および借方の勘定科目がある。詳細ではなく概要を生成する場合、全請求書には以下の場合を除いて貸方および借方の組が 1 つのみ存在する。
1. 監査人およびクライアントが、詳細行の最後に貸方および借方の勘定科目を付加することと、そのフォーマットで問題ないことに同意した場合
2. パイプ区切りのフォーマットではなく、XBRL GL フォーマットが使用される場合。XBRL GL カラムの注釈に記載される通り、XBRL GL はフラットファイルフォーマットよりも多くの項目を許可するデータ表現方法を採用している。
さらに複雑で階層的または重複する項目が必要になる場合、XBRL GL は監査データ標準を使用した共有データを表現するにはより実用的なフォーマットである。
監査データ標準を導入する企業は、最初に支援のためにエンタープライズ・リソース・プランニング(ERP)か会計パッケージベンダと連絡をとるべきである。ベンダが監査データ標準の適用に対して解決策を持たない場合、ベンダは監査データ標準にマッピングするために利用することができるスクリプトを作成しているため、それを使用してデータを抽出、変換、ロード(または ETL)する。
このデータ標準を導入する前に、職務分離のテストと内部統制の利用を通じてデータの信頼度が評価されるべきである。これらのタイプの評価標準のためのガイダンスは aicpa.org で入手可能である。
総勘定元帳、売掛債権、受注・入金、および仕入・支払などの監査データ標準はそれぞれこの基礎標準文書と共に利用されるべきであることに留意することは重要である。
この版の監査データ標準(基礎編)は、2013 年 8 月付の監査データ標準(基礎編)の更新版である。この版には、新しい税テーブル(2.5 Tax_Table_YYYYMMDD)と新しいデータ型が含まれる。版を追跡するには、各ファイルを一意に識別および区別するためのファイル命名規則を定めることを勧める。

Page 5 of 18

1.0. 基礎標準
基礎標準には、次のサブセクションの内容が含まれる。
1.1 ファイルとフィールドのためのフォーマット
1.2 User_Listing
1.3 Business_Unit_Listing
1.4 Segment0X_Listing (X=1 to 5)
1.5 Tax_Table_YYYYMMDD

1.1 ファイルとフィールドのためのフォーマット
ファイル名: 監査データ標準は、必要なデータファイルについて記述するファイル名を提供する。
しかし、これらの名前は単に示唆された名前である。各組織は、下記のようなファイルに関する追加情報を含めるために相互に同意されたファイル名を使用してもよい。
 ファイル作成日時
 ファイルバージョン番号
 データ適用の組織単位
ファイルフォーマット: ファイルは 2 つのフォーマットのどちらかで提供される。フラットファイルフォーマットあるいは財務情報記述言語(XBRL GL)である。もし必要であれば、ファイルは、ZIPファイルフォーマットあるいは相互に利用することに合意した他の圧縮ソフトを利用して圧縮される。
(1) フラットファイルフォーマット
フラットファイルフォーマットはパイプ区切り2の UTF-8 テキストファイルフォーマットである。
これは、多くのソフトウェアプログラムに広く支援される、単純で環境に依存しないファイルフォーマットである。フラットファイルフォーマットの利点は、ファイルサイズおよび広範囲の利用がされていることである。一方で、制限として、国際的な適用可能性およびリレーショナル若
しくは次元の概念の表示可能性があげられる。ファイルはそれぞれ、各データフィールドの監査データ標準フィールド名をリストするヘッダーレコードを含んでいるべきである。フィールドの情報は次の仕様に従うべきである。
データタイプTEXTNUMERIC

標準左寄せ。先頭または末尾の空白はなし。
通貨記号と桁区切り(例えば、コンマ)を利用してはならない。
小数点記号が含まれている必要があり、ピリオド(".")である必要がある。
整数ではない場合、小数点が含まれる必要がある。
負の数は数字の前に( - )マイナス記号で示される。

2

漢字や日本語文字セット(または両方)が抽出されている状況では、タブ区切り形式がパイプ区切り形式の代替として推奨されている。

Page 6 of 18

DATE

ISO 8601 - 日付は CCYYMMDD。

TIME

ISO 8601 - 24 時間制の時刻(HHMM)(例えば、PM1:00 = 1300)で表す。

BOOLEANtrue または false。

(2) XBRL GL
XBRL GL は、詳細な ERP データ(World Wide Web Consortium の XML 勧告に基づいたフォーマット)のための XBRL の利用についてのセマンテックなアグリーメントである。XBRL GL アプローチの潜在的な利点は、検証機能が組み込まれていること、国際市場に、または国際市場のための幅広い対応をしていること、そして、より強力なデータ表現を提供する能力を持っていることである。
潜在的な欠点は、追加の XBRL タグデータの包含による圧縮されないデータファイルサイズが増加することや、一部の GL ベンダには XBRL GL が採用されないことである。
XBRL GL タクソノミは、XML スキーマおよび関連するファイルから構成され、データファイルの生成および検証(つまり適合性のチェック)をガイドするために使用される。XBRL GL タクソノミは、XBRL ウェブサイトで見ることができる。XBRL GL ファイルの例は標準ダウンロードに含まれており、続いて記述されたフィールドに伴う必要な構造を示している。
監査データ標準によって表わされるプロフィールに XBRL GL ファイルを関連させるために、ネームスペースは、「xmlns:ads=http://www.aicpa.org/ads/YYYY-MM-DD)」のような形式で宣言される。ここでの「YYYY-MM-DD」は、該当する監査データ標準の公開日である。その後、それは「ads:User_Listing」のようなこの文書に定義された異なるテーブルを明示的に識別するために使用される。
データフィールド: 監査標準データは、多数の情報テーブルを含んでいる。テーブルはそれぞれ、データフィールドについて記述する列を持っている。また、データフィールド記述はそれぞれ、「レベル」カラムを持ち、データの重要性を示すために「1」あるいは「2」、どちらか一方のラベルを持っている。第 1 レベルの項目は必須である(IT システムか追加の手段によって利用可能な場合)。第 2レベルの項目は推奨されるが、必ずしも入手可能だとは限らないかもしれない。クライアントは、入手可能でないフィールドを特定するべきである。

Page 7 of 18

1.2 User_Listing
このテーブルはシステム内の各ユーザに関する識別子と情報を保持している。入手可能な場合、システム内の各ユーザは、姓名、役職および役割を持っているべきである。
フィールド番フィールド名号
1
User_ID2

User_Active_Status

レベ
ル
12

フラットファイルデータ
XBRL GL タクソノミ要素3
データ型 長さ4TEXT
25 gl-cor:identifierCode withgl-cor:identifierCategory= “systemUser”

TEXT

10 gl-cor:identifierActive

3

説明
取引を ERP システムに入力する個々に対する一意の識別子。このフィールドは、フィールド
Entered_By、Last_Modified_By、および Approved_By に基づいて、このテーブルと他のテーブルの情報を結合するために使用される。
(非アクティブなユーザによる取引の識別のための)利用者の状態を表示している。このフィールドの値は、フラットファイルデータの場合には「アクティブ」または「非アクティブ」のどちらかでなければならない。XBRL GL の場合には、ブール演算子で表現し、アクティブが”true”、非アクティブが”false”となる。

XBRL GL ファイル構造のサブディレクトリ\plt\case-c-b-m-u-t にある XML スキーマファイル gl-plt-2006-10-25.xsd のエントリポイントから取得される。これは schemaLocation および schemaRef に使用されるべきである。必要に応じて代替案も使用される。後日の草案の合意が得られない、又は有益でない限り、ユーザは、最新の利用可能な推奨バージョンを利用する必要がある。

4

文書全体を通して、この列は、推奨される最大の長さを示している。

Page 8 of 18

フィールド番フィールド名号
3
User_Active_Modified_Date

レベル2

フラットファイルデータ
XBRL GL タクソノミ要素3
データ型 長さ4DATE
gl-cor:dateAcknowledged

4First_Name

1

TEXT

5

Last_Name

1

TEXT

6

Title2TEXT

7Department

2TEXT

8

Role_Responsibility

2TEXT

100 gl-cor:identifierContactFirstName
100 glcor:identifierContactLastN
ame
100 glcor:identifierContactPrefix
100 glcor:identifierContactAtten
tionLine
100 gl-cor:
identifierContactPositionR
ole

Page 9 of 18

説明
ユーザを有効化した日と無効にした日。
ファーストネーム(名)。
ラストネーム(姓)。

役職(例えば、経理部門マネージャ)。
所属部門名(例えば、経理部)。

各自の機能的役割や主要な責任(例
えば、買掛金)。

XBRL GL への追加コメント
ユーザリストのうちで追加的に必須若しくは望ましいフィールドは次のとおりである。
要素
gl-cor:entriesType

内容
value = “other”

gl-cor:entriesComment

value = “ads:User_Listing”

コメント[entriesType]は必須フィールドである。[other]は列挙型の値である。
[entriesComment]は情報収集に共通しているものを説明する説明フィールドであり、この表現に関連して収集するタイプの監査データ標準の名前空間と修飾子を導入する。

Page 10 of 18

1.3 Business_Unit_Listing
事業単位リストは、事業単位の記述と事業単位階層の定義を含んでいる。
フィールド番フィールド名号
1
Business_Unit_Codeレベル1

フラットファイルデータ
XBRL GL タクソノミ要素
データ型 長さTEXT
25 XBRL GL tracks
hierarchy ID,
hierarchy description,and hierarchy type, so
it can track code
“NA,” description“N. America,” andtype “global area”
using
gl-cor:accountSubID,
glcor:accountSubDescript
ion, and glcor:accountSubType,respectively.
Interrelations andhierarchies arecaptured by glcor:parentSubAccountType (What is thehierarchy type thisunit rolls up to?).

Page 11 of 18

説明
財務諸表が監査対象となり、そのための試算表が作成されるレベルで事業単位、地域、支店などを識別するために利用される。例えば、財務会
計基準審議会(FASB)会計基準編纂書
280、セグメント報告に定義されている報告セグメントのコンセプトに合わせたコードを使用することができる。

フィールド番フィールド名号
2
Business_Unit_Description

レベ
ル1

フラットファイルデータ
XBRL GL タクソノミ要素
データ型 長さTEXT
100 See above; anunlimited number ofunits and structures
are permitted.
TEXT
100 Rather than duplicate
fixed relationships
between higher-level
hierarchies, they arecaptured once per
Business_Unit.
TEXT
100 See above; anunlimited number ofunits and structures
are permitted.

3

Business_Unit_Hierarchy1

2

4

Business_Unit_Hierarchy2

2

5

Business_Unit_Hierarchy32TEXT

100 See above; anunlimited number ofunits and structures
are permitted.

6Business_Unit_Hierarchy42TEXT

7

Business_Unit_Hierarchy5

2TEXT

100 See above; anunlimited number ofunits and structures
are permitted.
100 See above; anunlimited number ofunits and structures
are permitted.

Page 12 of 18

説明
事業単位の名前や特徴を示す事業単位の(平易な英語による)説明。

事業単位構造が存在する場合は、階層の最上位レベルを把握するためにフィールドを使用する(例えば、北米、南米、ヨーロッパ、中東、アフリカ、極東などのような値を持つグローバルエリア)。
事業単位構造が存在する場合は、階層の次の下位レベルを把握するためにフィールドを使用する(例えば、東海岸、西海岸、中央ヨーロッパ、などのような地域)。
事業単位構造が存在する場合は、階層の次の下位レベルを把握するためにフィールドを使用する(例えば、ロサンゼルス、ボストン、フランクフルトなどのような都市)。
事業単位構造が存在する場合は、階層の次の下位レベルを把握するためにフィールドを使用する。
事業単位構造が存在する場合は、階層の次の下位レベルを把握するためにフィールドを使用する。

XBRL GL への追加コメント
この設計は、Business_Unit_Hierarchy_(n+1)が Business_Unit_Hierarchy_(n)の更なる細分化する階層であると推測できる。単位のサブ単位への割り当てが適切であれば、XBRL GL は、無制限の細分化と階層を追跡できる。
事業単位リストのうちで追加的に必須若しくは望ましいフィールドは次のとおりである。
要素
gl-cor:entriesType
gl-cor:entriesComment

内容
value = “other”

コメント[entriesType]は必須フィールドである。[other]は列挙型の値である。
value =
[entriesComment]は情報収集に共通しているものを“ads:Business_Unit_Listing” 説明する説明フィールドであり、この表現に関連して収集するタイプの監査データ標準の名前空間と修飾子を導入する。

1.4 Segment0X_Listing (X=1 to 5)
異なる次元(例えば利益単位部門、部門、支店、製品、地理的な地域)によって財務資料を分析することは多くの場合有用である。この標準はセグメントと呼ばれて、この標準では、5 次元以内を含めて考えている。5 つまでのセグメントをリストするテーブルは、その値のテキスト説明に 5 つのセグメントの各々の値を対応している。セグメント 1‐5 の(オプション)目的は基礎標準質問事項の質問 10の中にある。
XBRL GL はセグメントに、より明示的なコンテキストを提供している。各セグメントのグルーピングに関連する暗黙の表現および順序は必須ではない。それがセグメントのプレゼンテーション順序を維持するのに重要であると考えられれば、次のフィールドを使用することができる。値/記述ペアはすべて単一の XBRL GL インスタンスに含むことができる。
利用されるセグメントごとに、以下の表を完成させる。

Page 13 of 18

フィールド番フィールド名号
1
Segment0X_Value

2

Segment0X_Description

レベ
ル2

2

フラットファイルデータ
XBRL GL タクソノミ要素
データ型 長さTEXT
25 gl-cor:accountSubID;
the explicit
definition of thebroad purpose for thesegment or the numericvalue (1.5) can be putin glcor:accountSubType
TEXT
100 glcor:accountSubDescription

説明Segment0X の値(X は 1 から 5 である)。

セグメント名または Segment0X_Valueの他の識別特性を示すための記述(Xは 1 から 5 である)。

XBRL GL への追加コメント
セグメントリストのうちで追加的に必須若しくは望ましいフィールドは次のとおりである。
要素
gl-cor:entriesType

内容
value = “other”

gl-cor:entriesComment

value =
“ads:Segment0X_Listing” ifprovided as individual
files, or“ads:Segment_Listing” if
combined as one

コメント[entriesType]は必須フィールドである。[other]は列挙型の値である。
[entriesComment]は情報収集に共通しているものを説明する説明フィールドであり、この表現に関連して収集するタイプの監査データ標準の名前空間と修飾子を導入する。

Page 14 of 18

1.5 Tax_Table_YYYYMMDD
税の徴収元または未払税の支払先の組織のマスターテーブル。

フィール
フィールド名ド番号
1 Regulator_Code

フラットファイル
レベデータ
ル データ型 長さ

XBRL GL タクソノミ要素

1TEXT

25

gl-cor:taxCode2

Regulator_Country

1TEXT

3

gl-bus:identifierCountry

3

Regulator_Region

1?

TEXT

25

4

Regulator_Name

1

TEXT

100

5Regulator_Role

1

TEXT

20

glbus:identifierStateOrProv
ince
gl-cor:taxAuthority AND
gl-cor:glcor:identifierAuthority
gl-bus:dmJurisdiction

6

Regulator_Default_Payable_GL_Account_Number

1

TEXT

100

7

Regulator_Default_Accrual_GL_Account_Number

1

TEXT

100

gl-cor:accountMainID withglcor:accountTypeDescriptio
n = “payable”
gl-cor:accountMainID withglcor:accountTypeDescriptio
n = “accrual”

Page 15 of 18

説明
この監督機関または管轄区域を参照するのに使用されるコード。キーとして使用されるか、ファイルを相互参照するのに使用される。
ISO 3166-1 アルファ 2 または ISO
3166-1 アルファ 3 の形式を推奨。
国内の小区域。米国では、これは国となる。カナダでは州となる。
税の徴収元または未払税の支払先の組織の監督機関の名前。
次の選択肢がある。連邦(Federal)、地域(Regional)、地方(Local)
監督機関への支払債務を表すのに使用される GL 勘定科目。
Chart_Of_Accounts
GL_Account_Name に関連する。
監督機関への未払金を表すのに使用される GL 勘定科目。

フィールフィールド名ド番号
8 Regulator_Default_Expense_GL_Account_Number

フラットファイル
レベデータ
ル データ型 長さ
1TEXT

1009Regulator_Identifier

1TEXT

25

10Regulator_Reporting_Organiza
tion1TEXT

100

11Regulator_Active_Flag

1BOOLEAN1XBRL GL タクソノミ要素

説明

gl-cor:accountMainID withglcor:accountTypeDescriptio
n = “expense”
glcor:identifierAuthorityCodeglbus:organizationIdentifiergl-cor:identifierActive

監督機関に関連する費用を表すのに使用される GL 勘定科目。

Page 16 of 18

組織を監督機関に報告するために、監督機関によって割り当てられた税またはその他のコード。
Organization_Location_File_YYYYMMDD と相互参照される。
True(アクティブ)または False(非アクティブ)。

1.6 基礎標準質問事項
次の情報は関係データについての理解および利用に不可欠である。企業の財務管理をその IT 担当者とのコンサルテーションによって行う場合、可能な限り、データが提供されるごとにその項目の各々を管理対象とするべきである。これらの質問は、すべてを含むことは意図しておらず、例示として示されている。このデータ標準を導入する前に、内部統制の利用と職務分離のテストを通じてシステムのデータの信頼度が評価されるべきである。
監査データ標準の例外

次の事項を考慮すること。
1. 監査データ標準の例外はあるのか。
 ファイルフォーマット(例えば、パイプ区切りではない、ヘッダー行はない、など)
 フィールドフォーマット(例えば、数字フィールドに小数点がない、日付の代替フォーマットなど) (例えば統計か予算項目など)非財務のものとして識別されるレコード
 含まれているべきであったが、抽出時に入手可能でなかったレコード
 含まれているべきだったが入手可能でなかった(1 レベル)フィールド
2. システムによって供給されるのではなく、計算されるフィールドはどれか。
企業情報

次の事項を考慮すること。
1. 財務管理部門チーム(CFO、コントローラなど)に関連した名前、役職、およびユーザ ID はどれであるか。
2. 企業は、データに影響するかもしれない重要な買収、売却あるいはシステムの移行活動をしているか。
ユーザおよび事業単位管理次の事項を考慮すること。
1. ユーザ ID の使用および再使用の方針および手続はどのようなものであるか。

Page 17 of 18

2. 事業単位が買収されるか売却される場合、事業単位 ID の使用および再使用の方針および手続はあるか。
3. 事業単位、および関連する階層、測定されている(例えば地域、生産ライン)レベルを識別する過程はあるか。
4. セグメント、および関連する階層、ならびに測定されている(例えばアカウント、利益単位部門、部門、事業単位、資金、プログラム、支店、プロジェクト)のレベルを識別する過程はあるか。
5. 従業員が週末及び週末を挟んで仕訳入力をしている企業の締め日程を特定しているか。特定している場合、どの週末か。
6. どのセグメントが使用され、また、どのように表示しているか。
7. 決算日程はいつか。どれだけの日数(日程)が各四半期あるいは期末に決算作業となっているか。各事業年度の終了日はいつであるか。
8. 観察された企業の休日はどれであるか。

Page 18 of 18