2015年7月

Audit Data Standards

General Ledger
Standard
2015年7月版

AuditDataStandards.GL.July2015
監査データ標準(総勘定元帳編)(2015 年 7 月)

Prepared by the AICPA Assurance Services Executive Committee
Emerging Assurance Technologies Task Forcewww.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 の改訂などを受けて、予告なく翻訳を改訂する場合もある。

www.aicpa.org/FRC

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

Director
Business Reporting, Assurance &Advisory Services

ManagerBusiness Reporting, Assurance &Advisory Services

www.aicpa.org/FRC

Audit Data Standards 監査データ標準
標準化の利点はよく認識され、様々な一般的な IT 標準の開発に結びついている。データ標準が必要な理由は、企業1のデータの効率的な交換に直面しているマネジメント、内部監査人および外部監査人にとって継続した問題である。このプロセスは、経理部門および IT 人員が異なる観点からこのような情報を要求することから複雑になる。例えば、ある場合には、監査関連のデータ依頼は、経理部門からより関与に制限のある企業の IT 部門へ直接転送される。多くの場合では、監査人にとってデータ要求は負担である。

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

1

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

www.aicpa.org/FRC

の相互に合意された拡張がない限り、一貫してこの取り決めによってそのデータを提供するべきである。

監査データ標準の規約は、そのデータ標準の設計者が携わった大多数のシステムからの要求を基に設計された。つまり、フラットファイル(パイプ区切り)のフォーマットでは、「反復性」がある特定のフィールドは特定の数字で固定されたことを意味する。次のような場合である。
Business_Unit_Listing in Base Standard: 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 で入手可能である。
各セクションのコンテンツについての補足詳細は以下のとおりである。次の図は、現在の標準でテーブルの関係を示すデータ・ダイアグラムを提供している。AICPA のウェブサイトにある監査データ標

www.aicpa.org/FRC

準(基礎編)と共に監査データ標準(総勘定元帳編)が使用されるべきであることに留意することは重要である。
この版の監査データ標準(総勘定元帳編)は、2013 年 8 月付の監査データ標準(総勘定元帳編)の更新版である。この版には、更新されたデータ関連テーブルおよび更新されたテーブル全体のフィールド情報を含む。版を追跡するには、各ファイルを一意に識別および区別するためのファイル命名規則を定めることを勧める。

監査データ標準におけるテーブル間のデータの関係

www.aicpa.org/FRC

1 総勘定元帳標準
総勘定元帳標準監査データは関連情報を含んでいる多数のテーブルで定義される。各テーブル内の「レベル」カラムは、データの重要性を示すために「1」あるいは「2」のラベルを持っている。第 1レベルの項目は必須である。(IT システム若しくは追加の手段によって入手可能な場合)。第 2 レベルの項目は推奨されるが、必ずしも入手可能だとは限らないかもしれない。被監査会社は、入手可能でないフィールドを特定するべきである。
以下の標準化データは、データ、会計プロセスおよび財務 IT システムについて記述するために使用されるべきデータプロファイリングレポートおよび質問事項である。
総勘定元帳標準データ
1.1 GL_Detail_YYYYMMDD_YYYYMMDD
1.2 Trial_Balance_YYYYMMDD_YYYYMMDD
1.3 Chart_Of_Accounts
1.4 Source_Listingwww.aicpa.org/FRC

1.1 GL_Detail_YYYYMMDD_YYYYMMDD
GL_Detail テーブルは仕訳入力行をすべて格納し、仕訳入力ヘッダ情報をすべて同様に含んでいる。このテーブル中の列はそれぞれ、関連する仕訳入力 ID、関連するアカウント番号、および仕訳入力行に関連した借方貸方のような各仕訳入力取引の詳細情報を含んでいる。ファイルは、仕訳入力行レベル(要約されたレベルでない)である。
フィー
ルド番
フィールド名号
1
Journal_ID

1

フラットファイルデータ
XBRL GL タクソノミ要素2
データ型 長さ3TEXT
100 gl-cor:entryNumber

レベ
ル

2

Journal_ID_Line_Number

1

TEXT

100 gl-cor:lineNumber

3

JE_Header_Description

1

TEXT

256 gl-cor:entryComment

4

JE_Line_Description

1

TEXT

256 gl-cor:detailComment

5

Source1TEXT

25 gl-cor:SourceJournalID(fixed/enumerated list)or
gl-cor:glcor:sourceJournalDescri
ption (free form)

2

説明
各仕訳入力の一意の識別子。複数フィールドの結合が必要な場合がある。
仕訳入力項目内の各行の一意の識別子。
仕訳入力伝票ヘッダに記載されているような全仕訳項目の説明。
仕訳入力項目内の個々の行の説明。
発信元(ソース)(仕訳入力項目は、
売上仕訳、入金仕訳、管理費仕
訳、給与仕訳、経理部手動入力、表計算などのように、発信元のソースのコード)。

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

3

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

Page 8 of 29

フィー
ルド番
フィールド名号
6
Business_Unit_Code7

Effective_Date

1

フラットファイルデータ
XBRL GL タクソノミ要素2
データ型 長さ3TEXT
25 gl-cor:accountSubID
with glcor:accountSubType of“Business_Unit”

1

DATE

レベ
ル

gl-cor:postingDate

Page 9 of 29

説明
財務諸表が監査対象となり、そのための試算表が作成されるレベル
で事業単位、地域、支店などを識別するために利用される。例えば、財務会計基準審議会(FASB)会
計基準編纂書 280、セグメント報告に定義されている報告セグメン
トのコンセプトに合わせたコードを使用することができる。
仕訳入力項目の日付に関係なく、仕訳が受信または入力されている日付。これは、時に決算日または会計効力発生日と呼ばれる。ユー
ザは 20X1 年 3 月 5 日に終了した期間の業績を見たい場合は、仕訳入力よりオープンな期間の中の全日分を集計することができ、20X1 年
3 月 5 日に終了する期間を指定す
る。

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

9

10

4

PeriodGL_Account_Number4

レベ
ル
1

1

1

フラットファイルデータ
XBRL GL タクソノミ要素2
データ型 長さ3TEXT
4 gl-bus:fiscalYearEnd
Note that glbus:fiscalYearEnd is at
a higher level of the
XBRL GL hierarchicalstructure than thedetail lines are, anefficient structuring
would include pregrouping by
bus:fiscalYearEnd
TEXT
10 gl-bus:postingCode

TEXT

100 gl-cor:accountMainID

ACCOUNT_NUMBER は英数字を含むことができる。

Page 10 of 29

説明
Effective_Date が記帳された会計年度。YYYY は区切りに使用される。
XBRL GL タクソノミフレームワークのための会計期末 CCYY-MM-DD(ISO8601)。

Effective_Date が記帳された会計期間。
例には、週単位の期間として W1–
W53、月単位の期間として M1–M12、四半期単位の期間として Q1–Q4 を含む。
GL 財務諸表勘定科目の識別子。このファイルの GL_Account_Number
は Trial_Balance とChart_Of_Accounts ファイルで使用される GL_Account_Number と一致する必要がある。

フィー
ルド番
号
11
Amount12

フィールド名1

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

レベ
ル

1

TEXT

1 gl-cor:debitCreditCode

13

Amount_Credit_Debit_IndicatorAmount_Currency

1

TEXT

3 gl-muc:amountCurrency

14Entered_By

1

TEXT

25 gl-cor:enteredBy

15

Entered_Date

1

DATE

gl-cor:enteredDate

16Entered_Time

2

TIME

17

Approved_By

2

TEXT

18

Approved_Date

2

DATE

(This is included in
the ISO 8601
representation of glcor:enteredDate, seeprevious row)
25 gl-cor:entryResponsiblePerson
gl-usk:nextDateRepeat
Page 11 of 29

説明
監査の下でエンティティの機能通貨またはグループ通貨で記録された取引金額。すべて取引が単一通貨に記録されているため、多通貨換算を実行する必要はない。
金額は借方か貸方かの指標。"C"は貸方、"D"は借方。
金額に関連する機能通貨やグルー
プ通貨。ISO 4217 コーディングを参照。
記録を残した人の(User_Listing
file 内の)User_ID。
仕訳入力がシステムに入力された日付。これは、時に作成日と呼ばれる。可能な場合、これは、(ユーザが入力した日付ではなく)システ
ムで生成された日付にする必要がある。この日付は、必ずしも仕訳
入力は GL または期末日に記帳された日付と一致しない。
この取引をシステムに入力した時間。ISO 8601 表記の 24 時間制の時刻(HHMM)(例: PM1:00 = 1300)。

入力を承認した人の(User_Listing
ファイルの)ユーザ ID。
入力が承認された日付。

20

Last_Modified_Date2

フラットファイルデータ
XBRL GL タクソノミ要素2
データ型 長さ3TEXT
25 gl-bus:
enteredByModified
DATE
gl-usk:lastDateRepeat

21

Reporting_Amount

2

NUMERIC

22

Reporting_Amount_Currency

2

TEXT

23

Local_Amount

2

NUMERIC

24

Local_Amount_Currency

2

TEXT

25

Reversal_Indicator

1

TEXT

26

Reversal_Journal_ID

2

TEXT

フィー
ルド番
フィールド名号
19
Last_Modified_Byレベル2

glcor:amountTriangulation
Amount3 glmuc:amountTriangulation
Currency
gl-muc:amountOriginalAmount3 gl-muc:amountOriginalCurrency
1 gl-usk:reverse
true = entry is to bereversed
false with glusk:reversingDate =provided = entry is areversal
not provided = none of
the above.
100 gl-usk:reversingStdId

Page 12 of 29

説明
この入力を最後に修正したユーザの(User_Listing の)User_ID。
記帳する前に入力が最後に変更された日付。
報告企業が財務諸表を作成する通貨での計上額。
報告企業の財務諸表作成のための通貨(例えば、米ドル、ユーロ、ISO 4217 コーディングを参照)。
取引開始の国での通貨の金額。
通貨は、現地報告するために使用される(例えば、米ドル、ユーロ、ISO 4217 コーディングを参照)。
この仕訳が取消であるか、反対仕訳とするかどうかを示している。
「1」の場合は取消、「2」の場合は反対仕訳である。XBRL GL の場
合は、ブール演算子で表現し、「true」とは、反対仕訳であることを示し、reversingDate の規定
による「false」とは、仕訳を取消していることを示している。
Reversal_Indicator が「１」の場
合には、反対仕訳の Journal_ID を
識別する。

フィー
ルド番
フィールド名号
27
Segment01

28
29
30
31

Segment02
Segment03
Segment04
Segment05

レベ
ル
2

2
2
2
2

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

Page 13 of 29

説明
プロフィット・センター、部門、ファンド、プログラム、支店、プ
ロジェクトなどのために使用することができる準備されたセグメン
トフィールド。

上記参照
上記参照
上記参照
上記参照

XBRL GL への追加コメント
1. gl-cor:sourceJournalID は下記についてのより明瞭な理解を促進するために列挙されたリストである:
 cd—現金支払(ベンダーへの小切手の送付)
 cr—現金入金(他からの小切手の受領)
 fa—固定資産
 gi—郵便振替為替制度あるいは他の銀行調整
 gj—普通仕訳
 im—在庫管理
 jc—ジョブコスト
 pj—仕入仕訳(仕入による負債)
 pl—給料支払仕訳
 sj—売上仕訳
 se—標準仕訳
 ud—定義されたユーザ
 ot—他のソースからの仕訳入力
GL リストのうちで追加的に必須若しくは望ましいフィールドは次のとおりである。
要素
gl-cor:entriesType

内容
value = “journal” or “entries”

gl-cor:entriesComment

value =
“ads:GL_Detail_YYYYMMDD_YYYYMMDD”

Page 14 of 29

コメント[Entries]は、会計仕訳の広範なリストに使用される。[journal]の列挙型の値のような入力の一覧が借方と貸方が等しいときに利用される。
[entriesComment]は情報収集に共通しているものを説明する説明フィールドであり、この表現に関連して収集するタイプの監査データ標準の名前空間と修飾子を導入する。

1.2 Trial_Balance_YYYYMMDD_YYYYMMDD
Trial_Balance(試算表)テーブルは総勘定元帳勘定残高情報をすべて格納している。Trial_Balance ファイルはある時点での期末残高を含んでいる。取引と残高の差を防ぐために、Trial_Balance は、GL_Detail として同時に作成される。
フィー
ルド番
フィールド名号
1
GL_Account_Number

1

フラットファイルデータ
XBRL GL タクソノミ要素
データ型 長さ
TEXT
100 gl-cor:accountMainID

レベ
ル

2

Business_Unit_Code

1

TEXT

3

Balance_AsOf_Date

1

DATE

25

gl-cor:accountSubID withgl-cor:accountSubType of“Business_Unit”

A common end-of date isnoted by glcor:periodCoveredEnd;
mixed period end dates
could be noted by glcor:postingDate

Page 15 of 29

説明
GL 財務諸表勘定科目の識別子。このファイルの GL_Account_Number
は GL_Detail とChart_Of_Accounts ファイルで使用される GL_Account_Number と一致する必要がある。
財務諸表が監査対象となり、そのための試算表が作成されるレベル
で事業単位、地域、支店などを識別するために利用される。例えば、財務会計基準審議会(FASB)会
計基準編纂書 280、セグメント報告に定義されている報告セグメン
トのコンセプトに合わせたコードを使用することができる。
Trial_Balance ファイルが作成された残高の日付(例えば、レポート
が 20150122 で作成実行された場合
でも、期末残高の日付は20141231)。

フィー
ルド番
フィールド名号
4
Fiscal_Year5

Periodレベル
1

1

フラットファイルデータ
XBRL GL タクソノミ要素
データ型 長さ
TEXT
4gl-bus:fiscalYearEnd ccyy-mm-dd

TEXT

6

Amount_Beginning

1

NUMERIC

7

Amount_Beginning_Reporting

2

NUMERIC

8Amount_Beginning_Local

2

NUMERIC10

gl-bus:postingCodeXBRL GL does not haveseparate beginning andending amounts on aline.This would use asecond line, with
optional glcor:xbrlInclude =“beginning_balance” andgl-cor:periodCoveredStart
glmuc:amountOriginalTriangu
lationAmount with glcor:xbrlInclude =“beginning_balance”
glmuc:amountOriginalAmountwith gl-cor:xbrlInclude =“beginning_balance”
Page 16 of 29

説明
Balance_AsOf_Date が記帳された会
計年度。YYYY は区切りに使用される。XBRL GL タクソノミフレームワークのための会計期末 CCYY-MMDD(ISO 8601)。
Balance_AsOf_Date が記帳された会計期間。
例には、週単位の期間として W1–
W53、月単位の期間として M1–M12、四半期単位の期間として Q1–Q4 を含む。
機能通貨またはグループ通貨で記録された期首開始残高金額(つまり、前の期間の期末残高である)。
すべて取引が単一通貨に記録されているため、多通貨換算を実行する必要はない。

法定報告のために使用される報告
通貨での期首開始残高金額。

多通貨追跡のための各国での通貨で期首開始残高金額。

フィー
ルド番
フィールド名号
9Amount_Currency

1

フラットファイルデータ
XBRL GL タクソノミ要素
データ型 長さ
TEXT
3 gl-muc:amountCurrency

レベ
ル

10

Amount_Reporting_Currency

2

TEXT

3

glmuc:amountOriginalTrangul
ationAmountCurrency

11

Amount_Local_Currency

2

TEXT

3

12

Amount_Ending

1

NUMERIC

glmuc:amountOriginalCurrencygl-cor:amount with
optional glcor:xbrlInclude =“ending_balance”

13

Amount_Ending_Reporting

2

NUMERIC

14

Amount_Ending_Local

2

NUMERIC

glmuc:amountOriginalTriangu
lationAmount with glcor:xbrlInclude=“ending_balance”.
glmuc:amountOriginalAmountwith glcor:xbrlInclude=“ending_balance”

Page 17 of 29

説明
残高に関連する機能通貨やグルー
プ通貨。ISO 4217 コーディングを参照。
機能別若しくは連結報告、現地、
実際金額に対して非連結報告のための通貨。ISO 4217 コーディングを参照。
通貨は現地報告に使用される。ISO4217 コーディングを参照。
機能通貨またはグループ通貨で記録された期間終了の残高金額。すべて取引が単一通貨に記録されているため、多通貨換算を実行する必要はない。
法定報告のために使用される報告
通貨での期末残高金額。

多通貨追跡のための各国での通貨で期末残高金額。

フィー
ルド番
フィールド名号
15 Segment01

16
17
18
19

Segment02
Segment03
Segment04
Segment05

レベ
ル
2

2
2
2
2

フラットファイルデータ
XBRL GL タクソノミ要素
データ型 長さ
TEXT
25 gl-cor:accountSubID
associated with the glcor:accountSubType as
defined in the
Segment0X_Listing tables.
(Note:XBRL GL tracks
hierarchy ID, hierarchy
description, andhierarchy type, so it can
track code NA,
description N. America,
and type global area
using
gl-cor:accountSubID, glcor:accountSubDescription, and glcor:accountSubType,
respectively.)TEXT
25 上記参照
TEXT
25 上記参照
TEXT
25 上記参照
TEXT
25 上記参照

説明
プロフィット・センター、部門、ファンド、プログラム、支店、プ
ロジェクトなどのために使用することができる準備されたセグメン
トフィールド。

上記参照
上記参照
上記参照
上記参照

XBRL GL への追加コメント
試算表は、開始時と終了時だけの場合は稀である。多くの場合、開始時、期間変更(借方期間、貸方期間)時、終了時がある。
Page 18 of 29

試算表リストのうちで追加的に必須若しくは望ましいフィールドは次のとおりである。
要素
gl-cor:entriesType
gl-cor:entriesComment

内容
value = “trialbalance”

コメント
明示的に XBRL GL の標準列挙に従って、試算表としてこれを定義している。
value =
[entriesComment]は情報収集に共通しているものを“ads:Trial_Balance_YYYYMMDD” 説明する説明フィールドであり、この表現に関連して収集するタイプの監査データ標準の名前空間と修飾子を導入する。

Page 19 of 29

1.3 Chart_Of_Accounts
勘定科目一覧表は総勘定元帳のすべての勘定科目を格納しており、勘定科目の名前、説明、財務諸表項目とのマッピングの情報が含まれる。異なる勘定科目表が異なる事業単位に必要とされる場合、事業単位フィールドは現地ベースと連結ベースでの勘定科目間を識別するために利用される。
フィー
ルド番
フィールド名号
1
GL_Account_Number

1

フラットファイルデータ
XBRL GL タクソノミ要素
データ型 長さ
TEXT
100 gl-cor:accountMainID

レベ
ル

2

GL_Account_Name

1

TEXT

3

Account_Type

1

TEXT

4

Account_Subtype

1

TEXT

100 glcor:accountMainDescription
25 gl-cor:mainAccountType

25 glcor:mainAccountTypeDescripti
onPage 20 of 29

説明
GL 財務諸表勘定科目の識別子。このファイルのGL_Account_Number は
GL_Detail と Trial_Balance フ
ァイルで使用し、
GL_Account_Number と一致する必要がある。
GL アカウントの名前。
財務諸表に関するハイレベルカ
テゴリにグループ化する。資産、負債、資本、収益、費用などである。
財務諸表上、下位レベルのカテ
ゴリにグループ化する。例えば、引当金勘定、仮勘定、内部取引勘定などが含まれる。

フィー
ルド番
フィールド名号
5
FS_Caption

レベル
1

フラットファイルデータ
XBRL GL タクソノミ要素
データ型 長さ
TEXT
100 glcor:summaryReportingElement

6

GL_Account_Description

2

TEXT

7

Business_Unit_Code

1

TEXT

256 glcor:accountTypeDescription
25 gl-cor:accountSubID with glcor:accountSubType of“Business_Unit”

8

Parent_GL_Account_Number

2

TEXT

100 gl-cor:parentAccountMainID

Page 21 of 29

説明
財務諸表の説明。GL アカウン
トにより財務諸表を集計する説
明のグループ化(例えば、現金及び現金同等物、買掛金、売上
原価など)。試算表レベルであることが望まれる。
GL_Account_Number に関連したラベルまたは説明。
財務諸表が監査対象となり、そのための試算表が作成されるレベルで事業単位、地域、支店などを識別するために利用される。例えば、財務会計基準審議会(FASB)会計基準編纂書 280、セグメント報告に定義されている報告セグメントのコンセプトに合わせたコードを使用することができる。
アカウント階層の親である
GL_Account_Number への参照。
勘定科目一覧表の階層の事前に定義されたレベル以上のものを可能にするために設けられてい
る。

フィー
ルド番
フィールド名号
9
Segment01

10
11
12
13

レベ
ル
2

Segment02
Segment03
Segment04
Segment052222

フラットファイルデータ
XBRL GL タクソノミ要素
データ型 長さ
TEXT
25 gl-cor:accountSubID
associated with glcor:accountSubType from
Segment0X_Listing(Note:XBRL GL tracks
hierarchy ID, hierarchy
description, and hierarchy
type, so it can track codeNA, description N. America,
and type global area using
gl-cor:accountSubID, glcor:accountSubDescription,and gl-cor:accountSubType,
respectively.)
TEXT
TEXT
TEXT
TEXT

25
25
25
25

上記参照
上記参照
上記参照
上記参照

説明
プロフィット・センター、部門、ファンド、プログラム、支店、プロジェクトなどのために使用することができる準備されたセグメントフィールド。

上記参照
上記参照
上記参照
上記参照

XBRL GL への追加コメント
勘定科目一覧表のうちで追加的に必須若しくは望ましいフィールドは次のとおりである。
要素
gl-cor:entriesType

内容
value = “account”

gl-cor:entriesComment

value =コメント
XBRL GL の列挙に従って、勘定科目の一覧としてこれを定義している。
[entriesComment]は情報収集に共通しているものを
Page 22 of 29

“ads:Chart_Of_Accounts”

説明する説明フィールドであり、この表現に関連して収集するタイプの監査データ標準の名前空間と修飾子を導入する。

Page 23 of 29

1.4 Source_Listing
ソースリストは、GL_Detail ファイル中で提供される出所に関する追加情報を提供する。ビジネスプロセスに関係がある情報と共に、
ERP モジュールあるいは補助元帳の中で、出所はそれぞれ記述する。
フィー
ルド番
号
1
Sourceフィールド名レベル
1

フラットファイルデータ
XBRL GL タクソノミ要素
データ型 長さ
TEXT
25 gl-cor:sourceJournalID ifan enumerated set is
feasible;
glcor:sourceJournalDescripti
on otherwise.

2

Source_Description

1

TEXT

3

ERP_Subledger_Module

2

TEXT

4

System_Manual_Identifier

2

TEXT

100 gl-bus:batchDescription if
glcor:sourceJournalDescripti
on is used above.
100 glbus:measurableDescription

1 gl-bus:entryOrigin

Page 24 of 29

説明
発信元(ソース)(仕訳入力項目
は、売上仕訳、入金仕訳、管理費
仕訳、給与仕訳、経理部手動入力、表計算などのように、発信元のソースのコード)。コードは発信元をユニークに識別できなければならない。
GL_Detail ファイル内のソースフ
ィールドと一致する必要がある。
ソースの平易な英語の説明。より一般的な仕訳の中には、仕入、売却、入金、現金支出、および一般
販売管理費がある。
補助元帳や ERP モジュールの記述
は、仕訳入力の発信元である。システムや重要な会計プロセスと紐づいている。いくつかの例では、ソースによって表すことができる。
ソースがシステム生成または手動で入力した仕訳を作成するかどうかを定義している。値は、「S」
又は「M」を利用する。

フィー
ルド番
フィールド名号
5Business_Process_Major

6

Business_Process_Minor

レベ
ル
2

2

フラットファイルデータ
XBRL GL タクソノミ要素
データ型 長さ
TEXT
100 glbus:measurableCodeDescript
ion
TEXT
100 glbus:measurableCodeCategory

説明
ビジネスプロセス(例えば、販売)に関連付けられている取引の主要なクラスである。
主要なビジネスプロセスのサブプ
ロセス(例えば、受注、返品、割引など)。

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

内容
value = “other”

gl-cor:entriesComment

value =
“ads:Source_Listing”

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

Page 25 of 29

1.5 総勘定元帳データプロファイリングレポート
ERP または GL から抽出されるデータの各セットについては、次のテストはデータプロバイダによって行なわれ、監査人によって独立して確認されるべきである。妥当性検証は、データが要求される各期間の間で行なわれるべきである。データ妥当性検証は下記を含んでいる。
テスト
説明
日付とコントロールトータル
Required files(要求さ要求されたすべてのファイルおよびデータフィールドが提供されていれているファイル)ることを確認する。
Date ranges(日付範囲)
 Entry_Date(GL_Detail)の最小と最大の日付
 Effective_Date(GL_Detail)の最小と最大の日付
 各期間での提供されたデータの中で Effective_Date(GL_Detail)の最小と最大の日付
Control totals(コント 仕訳行数、借方合計、貸方合計、総和(GL_Detail)の合計
ロールトータル) GL 勘定科目数と残高金額総合計 (Trial_Balance)
仕訳入力と試算表レビュー
Missing data(欠損デーフィールドによって表示された欠損や空白値の数。
タ)
Invalid data(不適切なフィールドフォーマットの要件に準拠していないフィールドのレコー
データ)
ドの数(例えば、日付や時刻フォーマットに準拠していない日付や時間、小数点以下 2 桁を含まない数値フィールドなど)。
0 ドルで貸借一致しない仕訳の割合
Nonbalancing
entries(貸借不一致の入力)
Nonbalancing
GL_Detail からの値で、ソース毎のレコードの数と金額の合計。
sources(貸借不一致のソース)
Trial_Balance 中 GL_Detail で発見される、GL 勘定科目のAccounts missing from
GL_Account_Number による数と金額の合計。
TB(試算表からの欠損勘定)Completeness/Financial Statement Roll-Forward
Account roll期首から期末までのすべての勘定科目のロールフォワード。(すべてのforward(勘定科目ロール GL_Account_Number ごとに、the Amount_Beginning [fromフォワード)
Trial_Balance]と total of Amount [from GL_Detail],とAmount_Ending [from Trial_Balance]を合計したものと theAmount_Ending and sum of Amount_Begining and total amount の差
異)Page 26 of 29

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

GL
次の事項を考慮すること。
1. ユニークなジャーナル ID フィールド(例えば、2 つ以上の他のフィールドの連結など)を作成するための暗黙の構造があるか。ある場合、構造はどのようなものであるか。
2. 仕訳入力は財務諸表において(例えば、入力された時、承認された時など)いつと認識しているのか。
3. ユニークなアカウント番号シーケンスは、事業単位、サブアカウントなど(アカウントフ
レックスフィールド)のような分類ととらえるか。その場合、アカウント番号シーケンスについて記述する。
4. 関連当事者間取引はどのように識別されるか(例えば完全あるいは部分的に所有された子会社との取引)。
5. データを分析する場合、個別の GL システム(例えば ERP、複数 GL、ERP 導入での実例)を考慮する必要があるか。データ中の様々な補助簿はどのように区別しているか。
6. このデータ抽出はどの GL システムからであるか。データ抽出のために(例えば、使用される ERP プログラムの識別、カスタムクエリーとしての SQL コード)ドキュメンテーションを備えているのか。
a. すべての事業単位を通じて GL で支援されているスプレッドシートを含むアプリケー
ション数や仕訳入力のためのソース数はどのくらいあるのか。
b. それらのタイプおよび名前(アプリケーション = ERP モジュール、補助元帳あるいは GL への入力できるソース)はどのようになっているのか。
c. どのタイプのアプリケーションが連結財務諸表作成プロセスの中で利用されるか。
また、それらはどのように子会社総勘定元帳および補助元帳と関係があるか。
d. 削除を扱う過程はどれであるか。また、それが ERP システムで複製されるか。
7. 連結財務諸表のプロセスはどれであるか。財務諸表は正しく連結されるか。その場合、そのプロセスについて記述する。
Page 27 of 29

8. ERP が連結目的に使用される場合、財務報告プロセスでのどの時点で、連結されるのか。
毎日か、あるいは毎月か、四半期であるか。
9. 財務諸表を連結するおよび準備する場合、連結仕訳修正は作られるのか。これらはどのよ
うにとらえられるか。また、それらはどのように GL や ERP に組み入れられるか。
10. 反対仕訳は手動で入力されるか。それとも、それは自動プロセスであるか。
11. 財務諸表(例えばメモ入力)と関係がない取引データがあるか。その場合、それらはどのよ
うに識別されるか。
12. どのように GL Account_Type および Account_Subtype を使用したか。
13. 非財務のデータは含まれているか、その場合、それはどのように識別することができるか。
14. そのアプリケーションはどのようにマニュアルと自動仕訳入力を定義しているか。標準トランザクションと非標準のトランザクションの相違を示す取引規準について記述する。
15. 通貨換算はどのように扱われるか。
16. 通貨は、どのようにアプリケーション内に識別されるか。
17. 外貨取引レコードは現地の通貨および金額、および報告(親会社)通貨金額の両方を含んでいるか。その場合、外貨を親会社あるいは連結された(機能的)GL 通貨(毎月、毎日、など)にいつ換算するか。
18. システムは、貸借不一致仕訳入力を許可するか。その場合、このデータ送信中の貸借不一
致仕訳の理由はどのようなものであるか。また、貸借不一致により残高が 0 にならない仕
訳入力はどのくらいあるのか。
19. そのアプリケーションは貸借の片側の仕訳入力を許可したか。その場合、これらのタイプの入力を許可する状況はどのようなものか。
20. GL は、個々の取引が関連する詳細情報がないヘッダ情報としてシステムに存在することを可能にしているか。その場合、これらの入力にフラグを立て、一層の評価のために識別しているか。
21. ユーザは、前の決算期間への仕訳入力をすることができるか。後日入力をどのような状況で許可しているか。システムは、後日入力を識別、追跡しているか。
22. GL の内に仕訳入力識別子番号を再使用することができるか。その場合、何が仕訳入力番号をユニークにするか。
23. 入力は、どれくらい頻繁に GL(リアルタイムかバッチ処理)で入力されるか。もしバッチ処理によって入力されれば、入力スケジュールはどのようなものであるか。
24. システムに入力された事業単位またはセグメントからの仕訳入力数はどれくらいであるか。
それらは要約された入力か詳細の入力か。
Page 28 of 29

25. 仕訳入力のための時刻記録(東海岸時間、GMT など)はどのようにされているのか。

ユーザおよび事業単位管理
次の事項を考慮すること。
1. 手動入力の承認はどのように扱われるか。それは紙ベースのプロセスであるか、それとも、承認プロセスは GL システムに組み込まれているか。
2. 仕訳入力はどのようにレビューされるか。仕訳入力の金額について要求されるレビューのレベルに関して定めがあるか。このプロセスはシステムに組み込まれているか。それとも、それは手動のプロセスであるか。
3. 手動仕訳入力(スプレッドシートと MS Access のアップロードなどを含む)を作成し、修正し、承認することができる承認されるユーザは誰であるか。これらのユーザのリストを提供する。
4. バッチ処理で手動仕訳入力アップロードすることを許可、利用するか。
5. 抽出された GL データを提供する場合、仕訳行数および合計金額は、手動生成あるいはデータを抽出したアプリケーションによって作成されているのか。

Page 29 of 29