2015年7月

Audit Data Standards

Order to Cash
Subledger Standard
2015年7月版

AuditDataStandards.O2C.July2015
監査データ標準(受注・入金編)

Prepared by the AICPA Assurance Services Executive Committee
Emerging Assurance Technologies Task Force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 person
al, intra organizational, or educational use only and are not sold or disseminated and pro
vided 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 の改訂などを受けて、予告なく翻訳を改訂する場合もある。

Assurance Services Executive Committee (2014-2015)
Don Kluthe
Robert Dohrer, Chair
Dorsey Baskin

Chris Kradjan

Bradley Beasley

Michael Ptasienski

Greg Bedard

Beth A. Schneider

Nancy Bumgarner

Miklos Vasarhelyi

Chris Halterman

Deetra B. Watson

Charles E. Harris

Don Pallais (Observer)

Emerging Assurance Technologies Task Force
Audit Data Standard Working Group
William R. Titera, Chair

Steven Henchock

Glenn Galfond, Lead

Mark Mayberry

Paul Barbour

Phillip McCollough

Karl BuschJosh Phillips

Eric E. Cohen

Joel Pinkus

Charles E. Harris

Miklos Vasarhelyi

Kristine Hasenstab

Additional Contributors
D.J.Elmore
Gianluca Garbellotto

AICPA Staff
Amy Pawlicki

Dorothy McQuilken

Director
Business Reporting, Assurance & Advisory
ServicesManagerBusiness Reporting, Assurance & Advisory
ServicesAudit Data Standards

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

AICPAアシュアランスサービスエグセクティブ委員会は監査および他の関連する目的のために一般に要求されるファイルとフィールドのためのフォーマットの標準化によって監査プロセスの効率性および有効性にこの監査データ標準(ADS)が貢献するだろうと考えている。同様に、もし企業が内部監査人および外部監査人などとデータを共有することを決めれば、標準化された情報(債権者のような)の他の消費者も利益を得るであろう。
大企業、そして中小企業、公開若しくは非公開企業は、監査データ標準の適用からさらに利益を得るかもしれない。監査人によって定期的に要求されたデータの標準化によって、企業は情報の要求プロセスを自動化し、複製することができ、それによって、要求されたデータを提供するのに必要な時間と労力を減らすことができる。さらに、企業のスタッフおよび内部監査人は、内部目的のための標準化されたデータを利用することにより強化された解析能力から利益を得るであろう。さらに、この標準はそのデータを外部監査人が強化されたデータ分析を行なうのに利用可能とするであろう。

これらの標準は、良く設計された会計および財務報告システムに導入することができる
すぐれた慣行である。この公表物は受注・入金補助元帳について提示する。

監査データ標準はテクニカル・デザイン(ファイル、テーブル、フィールド、フォーマットなど)、およびその使用についての理解にとって不可欠なデータに関する補足的事項を提示している。前者は、通常ITシステム設計に対して提示されることが適している。
後者は、一般的に経理あるいは財務担当者によって、IT担当者からの入力による情報が提供される。これらが情報の抽出のための任意の推奨されたデータ標準であることに留1

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

意すること。これらのデータ抽出標準は必須のものではない。また、権威のある監査あるいは会計基準から提示されたものでもない。

特に規模および産業特性により、均一性の価値および個々の企業への適応の利点を認識して、これらの標準は、ある程度の柔軟性を提供する。これらの標準は、各国特有の要件に対応しており、国際的な適用が可能である。これは最低の標準で、制限することが目的ではない。したがって、ユーザはユーザ定義のフィールドをカスタマイズして、作成してもよい(例えば、項目は除かれるべきではない。しかし、標準にまだ存在しない
ところで、項目が加えられるかもしれない)。しかしながら、標準化(特に示されなかった時)の利点を達成するために、個々のカスタマイゼーションは回避されるべきである(言いかえれば、項目が標準に定義されている場合は、それを再定義しない)。一旦企業
が特定の取り決めを採用すれば、主なITシステムの変更の実施や標準化されたデータの供給者および利用者の相互に合意された拡張がない限り、一貫してこの取り決めによってそのデータを提供するべきである。

監査データ標準の規約は、そのデータ標準の設計者が携わった大多数のシステムからの要求を基に設計された。つまり、フラットファイル(パイプ区切り)のフォーマットでは、「反復性」がある特定のフィールドは特定の数字で固定されたことを意味する。次のよ
うな場合である。
•

監査データ標準(基礎編)のBusiness_Unit_Listing:— Business_Unit_Hierarchy[1] – [5]•監査データ標準(総勘定元帳編)等のGL_Detail_YYYYMMDD_YYYYMMDD:— Segment[01] – [05]•監査データ標準(売掛債権編)または(受注・入金編)のCustomer_Master_YY
YYMMDD:—
住所および請求先住所•

監査データ標準(仕入・支払編)等のInvoices_Received_YYYYMDD_YYYYMMD
D:— GL_Debit_Account_NumberおよびGL_Credit_Account_Number

最後の例では、入力行には貸方および借方の勘定科目がある。詳細ではなく概要を生成する場合、全請求書には以下の場合を除いて貸方および借方の組が1つのみ存在する。

1.

2.

監査人および被監査会社が、詳細行の最後に貸方および借方の勘定科
目を付加することと、そのフォーマットで問題ないことに同意した場
合パイプ区切りのフォーマットではなく、XBRL GLフォーマットが使用される場合。XBRL GLカラムの注釈に記載される通り、XBRL GLはフラットファイルフォーマットよりも多くの項目を許可するデータ表現方法を採用している。

さらに複雑で階層的または重複する項目が必要になる場合、XBRL GLは監査データ標準を使用した共有データを表現するにはより実用的なフォーマットである。
監査データ標準を導入する企業は、最初に支援のためにエンタープライズ・リソース・プランニング(ERP)か会計パッケージベンダと連絡をとるべきである。ベンダが監査データ標準の適用に対して解決策を持たない場合、ベンダは監査データ標準にマッピングするために利用することができるスクリプトを作成しているため、それを使用してデータを抽出、変換、ロード(またはETL)する。
これらのデータ標準を導入する前に、職務分離のテストと内部統制の利用を通じてデー
タの信頼度が評価されるべきである。これらのタイプの評価標準のためのガイダンスは
aicpa.orgで入手可能である。

1.受注・入金補助元帳標準

この公表物は受注・入金(O2C)業務について記載しており、前版の監査データ標準(売掛債権編)を拡張し、それに取って代わるものである。
この版の受注・入金監査データ標準は、受注・入金における基本的な分析を可能にすることを意図する。その分析とは、売掛債権残高のうちどれだけ入金があり償却があり、例外的に古い債権などで支払されているかについての指定された期間の活動水準の分析などである。この標準は、内部プロセスを改善するために企業のスタッフおよび内部監査によって行なわれるかもしれない分析と同様に監査の一部として行なわれる分析を促進することを意図されている。この標準の更新版では、さらに詳細かつ業種特有の内容が追加され、分析のための機会が拡大される可能性がある。
受注・入金はサプライチェーンに関連する複数の業務プロセスの一部である。図1はサプライチェーンのプロセスの概要である。この受注・入金監査データ標準とそれに関連する仕入・支払監査データ標準で提示されるサプライチェーンの各要素を示している。
図1:監査データ標準で提示されるサプライチェーンの各要素

受注・入金標準監査データは関連情報を含んでいる多数のテーブルで定義されている。
図2は、受注・入金標準でテーブルの関係を示すデータ・ダイアグラムを提供している。
AICPAのウェブサイトにある基礎標準文書と共に受注・入金補助元帳標準が使用されるべきであることに留意することが重要である。
図2:受注・入金監査データ標準におけるテーブル間のデータの関係

受注・入金標準監査データは、「詳細レベル」(販売注文や請求書等の各明細項目に対して情報があるレベル)で提供されることもあれば、「概要レベル」(販売注文や請求書等に関する総計情報レベル)で提供されることもある。管理しきれないデータ容量にならない限り、詳細レベルのデータが望ましい。図2では、緑色のテーブルは、詳細レベルのデータが提供される場合は含まれ、概要レベルのデータの場合は含まれない。

受注・入金標準の各テーブル内にあるデータフィールドの「レベル」カラムは、データの重要性を示すために「1」あるいは「2」、どちらか一方のラベルを持っている。第1レベルの項目は必須である(ITシステムか追加の手段によって利用可能な場合)。第2レベルの項目は推奨されるが、必ずしも入手可能だとは限らないかもしれない。利用可能ではないフィールドは別途指定されるべきである。
次のサブセクションでは、受注・入金監査データ標準について詳述している。

2.0 受注・入金標準データ2
2.1

Sales_Orders_YYYYMMDD_YYYYMMDD

2.2

Sales_Orders_Lines_YYYYMMDD_YYYYMMDD

2.3

Shipments_Made_YYYYMMDD_YYYYMMDD

2.4

Shipments_Made_Lines_YYYYMMDD_YYYYMMDD

2.5

Invoices_Generated_YYYYMMDD_YYYYMMDD

2.6 Invoices_Generated_Lines_YYYYMMDD_YYYYMMDD
2.7 Open_Accounts_Receivable_YYYYMMDD
2.8

Cash_Received_YYYYMMDD_YYYYMMDD

2.9

AR_Cash_Application_YYYYMMDD_YYYYMMDD

2.10

AR_Adjustments_YYYYMMDD_YYYYMMDD

2.11 AR_Adjustments_Lines_YYYYMMDD_YYYYMMDD
2.12 Receipt_Type_Listing_YYYYMMDD
2.13 AR_Adjustment_Type_Listing_YYYYMMDD
2.14 Customer_Master_Listing_YYYYMMDD

タブ区切りのフォーマットによる「フラット」な(階層構造を持たない、記録単位による)設計であるため、「明細項目」(詳細)はファイル構造内で定義されたSales_Orders_
Lines_YYYYMMDD_YYYYMMDDおよびSales_Orders_YYYYMMDD_YYYYMMDDなどのヘッダからは分離する必要があることに留意したほうがよい。次のXBRL GLガイダンスは、監査デー
タ標準のプロファイルとしてこの分離を規定する。ただし、XBRL GLは、情報交換における事前の同意によって、XMLの特性を利用してヘッダと詳細項目を結合して単一のファイルにすることができるため、ファイルの生成および交換ではより効率的で有力な手段となり得る。「1つの請求に対して1レコード」または「各出荷に関連する複数の販売注文に対して1レコード」というようなことまで言及する指示は、フラットファイルフ
2

テーブルに2つの日付を含む場合、その日付は抽出期間の開始日と終了日を表すことに留意する。テーブルに1つの日付を含む場合、その日付はデータ抽出日である。

ォーマットの限界を表す。例えば、XBRL GLではgl-tag:originatingDocument構造を利用することにより、1つのentryDetailを幅広い種類の関連する元文書に関連付けることができる(XBRL GLの指示では、可能な場合は、互換性を目的としてフラットファイルの制限を模倣するように設計されている)。

2.1 Sales_Orders_YYYYMMDD_YYYYMMDDSales_Orders_YYYYMMDD_YYYYMMDDファイルは、少なくとも、調査中の期間内に行われたすべての販売注文を含む。このファイルには、調査中の期間内に記録された取引に関連する、当期および前期のすべての販売注文が含まれるのが理想的である。しかし、これらの販売注文の一部は、はるか過去に行われた可能性があるため、被監査会社および監査人は含めるべき販売注文履歴を決定するための判断をしなければならない。
このファイルでは、各販売注文に対してそれぞれ1レコードとなる。
ィフィールド名レ ベ フラットファイルXBRL GLタクソノミ要素3
ル
ル
データ
番
データ型
長さ4

フ
ー
ド
号

1

Sales_Order_ID

1

TEXT

100

gl-cor:documentReferencewith glcor:documentType =“order-customer”

2

Sales_Order_Document_ID

1

TEXT

100

gl-cor:documentNumber

3

説明

各販売注文に一意の識別子。このIDは、(例えば、文書番号、文書種
別、および年)は、各販売注文を一意に識別するためのフィールドを連結することによって作成される必要がある。
販売注文の識別子番号または識別子
コード。

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

4

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

フ ィ
ー ル
ド 番
号

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

XBRL GLタクソノミ要素

3

Sales_Order_Date

1

DATE

4

Sales_Order_Fiscal_Year

1

TEXT

4

gl-bus:fiscalYearEnd

5

Sales_Order_Period

1

TEXT

10

gl-bus:postingCode

6

Business_Unit_Code

1

TEXT

gl-cor:documentDate

50

gl-bus:organizationIdenti
fier

説明

販売注文日。販売注文が入力された日とは関係がない。
Sales_Order_Dateが記帳された会計
年度。YYYYは区切りに使用される。
XBRL GLでは会計期末CCYYMMDD(ISO8601)。
Sales_Order_Dateが記帳された会計期間。
例には、週単位の期間としてW1–W5
3、月単位の期間としてM1–M12、四半期単位の期間としてQ1–Q4を含む。
財務諸表が監査対象となるレベルで事業単位、地域、支店などを識別するために利用される。Business_Uni
t_Listingファイル内のBusiness_Un
it_Codeと一致しなければならない。

7

Customer_Account_ID

1

TEXT

100

gl-cor:identifierCode wit
h glcor:identifierType =“customer”

8Entered_By

1

TEXT

100

9

Entered_Date

2

DATE

gl-cor:identifierCode wit
h glcor:identifierCategor
y = “systemUser”
gl-cor:enteredDate

10Entered_Time

2

TIME

11

Approved_By

2

TEXT

12

Approved_Date

2

DATE

100

(This is included in the
ISO 8601 representation of glcor:enteredDate, ment
ioned previously.)
gl-cor:entryResponsiblePe
rson
gl-usk:nextDateRepeat

支払が予想されている顧客の識別子
か、買掛計上に対する支払を行う顧客の識別子。Customer_Master_List
ing_YYYYMMDDファイル内のCustomer_Account_IDと一致しなければならない。
記録を残した人の(User_Listingファイル内の)User_ID。
注文がシステムに入力された日付。
これは、時に作成日と呼ばれる。可能な場合、これは、(ユーザが入力した日付ではなく)システムで生成された日付にする必要がある。この日付は、必ずしも、実際の取引の日付に対応していない。
この取引をシステムに入力した時間。ISO 8601表記の24時間制の時
刻(HHMM)(例: PM1:00 = 1300)。
顧客マスタの追加や変更の承認者の(User_Listingファイルの)ユーザI
D。
入力が承認された日付。

13

フ ィ
ー ル
ド 番
号

Approved_Time

2

フィールド名(This is included in the 入力が承認された時間。ISO 8601表
ISO 8601 representation o 記の24時間制の時刻(HHMM)
f gl(例: PM1:00 = 1300)。
usk:nextDateRepeat, menti
oned previously.)

TIME

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

14

Last_Modified_By

2

TEXT

15

Last_Modified_Date

2

DATE

16

Last_Modified_Time

2

TIME

17

Sales_Order_Amount_Local

1

NUMERIC

18

Sales_Order_Local_Currency

1

TEXT

100

XBRL GLタクソノミ要素

説明

gl-bus:enteredByModified

この入力を最後に修正したユーザの(User_Listingの)User_ID。
入力が最後に変更された日付。

gl-usk:lastDateRepeat(This is included in the 入力が最後に変更された時間。ISO
ISO 8601 representation o 8601表記の24時間制の時刻(HHMM)
f gl(例: PM1:00 = 1300)。
usk:lastDateRepeat, menti
oned previously.)
注記:詳細(明細項目)データが提供される場合、次のフィールドは省略される場合がある。

3

gl-muc:amountOriginalAmou
nt
gl-muc:amountOriginalCurr
ency

現地通貨で記録された販売金額。
現地国の報告で要求される通貨。ISO 4217コーディングを参照。

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

19

Segment01

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

TEXT

25

XBRL GLタクソノミ要素1

説明

プロフィット・センター、部門、フgl-cor:accountSubID withassociated gl-cor:account ァンド、プログラム、支店、プロジ
SubTypeェクトなどのために使用することができる準備されたセグメントフィー(Note:XBRL GL tracks
ルド。
hierarchy ID, hierarchy description, and hierarchy
type, so it can track cod
e NA, description N. America, and type global area
using
gl-cor:accountSubID, glco
r:accountSubDescription,and glcor:accountSubType,
respectively.)

20
21

Segment02
Segment03

2
2

TEXT
TEXT

25
25

上記参照
上記参照

上記参照
上記参照

22

Segment04

2

TEXT

25

上記参照

上記参照

23

Segment05

2

TEXT

25

上記参照

上記参照

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

value = “other”

gl-cor: entriesComment

value = “ads: Sales_Orders_YYYYMMDD_YYYYMMDD”

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

2.2 Sales_Orders_Lines_YYYYMMDD_YYYYMMDDSales_Orders_Lines_YYYYMMDD_YYYYMMDDファイルには、Sales_Orders_YYYYMMDD_YYYYMMDDファイル内にある販売注文に対する詳細な明細項目が含まれる。このファイルの使用は任意であるが、管理しきれないデータ容量ではない限り、使用することが推奨される。
このファイルでは、販売注文の各明細項目に対してそれぞれ1レコードとなる。

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

2

Sales_Order_Line_ID

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

XBRL GLタクソノミ要素

説明

各販売注文に一意の識別子。このIDは、 (例えば、文書番号、文書
種別、および年)は、各取引を一意に識別するためのフィールドを連結することによって作成される必要がある。
販売注文の明細行番号の識別子。

1

TEXT

100

gl-cor:documentReference w
ith glcor:documentType =“order-customer”

1

TEXT

10

gl-cor:lineNumber

3

Sales_Order_Line_Product_ID

1

TEXT

25

4

Sales_Order_Product_Code

1

TEXT

25

5

Sales_Order_Line_Product_Desc
ription

1

TEXT

100

6

Sales_Order_Line_Product_Grou
p_01
Sales_Order_Line_Product_Grou
p_02
Sales_Order_Line_Quantity

2

TEXT

25

2

TEXT

25

1

NUMERIC

7
8
9

2

TEXT

10

Sales_Order_Line_Unit_of_Meas
ure
Sales_Order_Line_Unit_Price

1

NUMERIC

11

Sales_Order_Line_Amount_Local

1

NUMERIC

12

Sales_Order_Line_Local_Curren
cy

1

TEXT

25

3

gl-bus:measurableIDOther

各販売商品に一意の識別子。このIDは、(例えば、事業単位、商品番号、および年など)は、各商品を一意に識別するためのフィールドを連結することによって作成される必要がある。
gl-bus:measurableID
取引文書に表示されるローカルな商品項目番号コード。
gl-bus:measurableDescriptio 商品の名前やその他の識別する特n
徴を表す説明(平易な英語)。
gl-bus:measurableCodeDescri 商品の記述子(01)。例えば、タイ
ption
ヤや付属品など。
gl-bus:measurableCategory
商品の記述子(02)。例えば、銘柄など。
gl-bus:measurableQuantity
販売注文明細行の数量。
gl-bus:measurableUnitOfMeasure
gl-bus:measurableCostPerUnitgl-muc:amountOriginalAmount

販売注文明細行の基本計量単位。
販売注文明細行の単位当たりの価格。
現地通貨で記録された販売金額。

gl-muc:amountOriginalCurren 現地国の報告で要求される通貨。Icy
SO 4217コーディングを参照。

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

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

TEXT

25

XBRL GLタクソノミ要素

説明

gl-cor:accountSubID with

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

associated gl-cor:account
SubType(Note: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:
accountSubDescription, andglcor:accountSubType, respe
ctively.)
14
15
16

Segment02
Segment03
Segment04

2
2
2

TEXT
TEXT
TEXT

25
25
25

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

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

17

Segment05

2

TEXT

25

上記参照

上記参照

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

value = “other”

gl-cor:entriesComment

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

2.3 Shipments_Made_YYYYMMDD_YYYYMMDD

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

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

TEXT

100

XBRL GLタクソノミ要素

説明

gl-cor:documentReference

各出荷に一意の識別子。このIDは、(例えば、文書番号、文書種別、および年)は、各出荷を一意に識別するためのフィールドを連結することによって作成される必要がある。
出荷日(出荷された日)。

2

Shipment_Date

1

DATE

gl-cor:documentDate

3

Shipment_Fiscal_Year

1

TEXT

4

gl-bus:fiscalYearEnd

4

Shipment_Period

1

TEXT

10

gl-bus:postingCode

Shipment_Dateが記帳された会計年度。YYYYは区切りに使用される。XB
RL GLタクソノミフレームワークのための会計期末CCYY-MM-DD(ISO 860
1)。
Shapment_Dateが記帳された会計期間。
例では週単位の期間としてW1–W53、月単位の期間としてM1–M12、四半期
単位の期間としてQ1–Q4が含まれている。

Shipments_Made_YYYYMMDD_YYYYMMDDファイルは、少なくとも、調査中の期間内に行われた販売注文に対するすべての出荷および出荷調整を含む。このファイルには、出荷が前期に行われた場合であっても、調査中の期間内に記録された取引(請求や支払など)に関連するすべての出荷が含まれるのが理想的である。監査人は、含めるべき出荷履歴を決定するための判断をしなければならない。このファイルには、関係がない産業(例えば、サービス業など)もある。

このファイルでは、各出荷に関連付けられる各販売注文に対してそれぞれ1レコードとなる。例えば、1つの出荷に3つの販売注文からの商品が含まれていた場合、この出荷に対しては3つのレコードがあることになり、1レコードは3つの販売注文のうちの1つずつに関連付けられる出荷内の複数商品に対応する。

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

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

1XBRL GLタクソノミ要素

説明

gl-cor:detailComment with 取引がはじめの出荷取引の場合はvalues “0” or “1”; gl 「0」となり、出荷調整の場合は-cor:documentType of「1」となる。
“shipment”
gl-cor:documentTypeDescri 出荷調整が行われている場合におけ
ption
る、その調整の理由についての説
明。
gl-cor:documentNumber
出荷帳票の参照番号(企業参照または物流企業識別子)。

6

Adjustment_Description

2

TEXT

100

7

Shipping_Document_ID

1

TEXT

100

8

Customer_Account_ID

1

TEXT

100

gl-cor:identifierCode wit 商品を仕入れる顧客。Customer_Mas
ter_Listing_YYYYMMDDファイル内のh glcor:identifierType =Customer_Account_IDに一致しなけ“customer”
ればならない。

9Business_Unit_Code

1

TEXT

50

gl-bus:organizationIdenti 財務諸表が監査対象となるレベルでfier
事業単位、地域、支店などを識別するために利用される。Business_Uni
t_Listingファイル内のBusiness_Un
it_Codeと一致しなければならない。

10

Sales_Order_ID

1

TEXT

11

Sales_Order_Date

1

DATE

12

Entered_By

1

TEXT

13

Entered_Date

2

DATE

14

Entered_Time

2

TIME

15

Approved_By

2

TEXT

100

gl-taf:originatingDocumen
tNumber with gltaf:originatingDocumentTy
pe = “order-customer”*

gl-cor:documentDate*

100

100

gl-cor:identifierCode wit
h glcor:identifierCategor
y = “systemUser”
gl-cor:enteredDate(This is included in the
ISO 8601 representation of glcor:enteredDate, above)gl-cor:entryResponsiblePe
rson

出荷された商品の販売注文ID。Sales_Orders_YYYYMMDD_YYYYMMDDファイ
ル内のSales_Order_IDと一致しなけ
ればならない。
販売注文がない場合、空白のままにする。
出荷された商品の販売注文日。販売
注文がない場合、空白のままにする。
出荷記録を残した人の(User_Listin
gファイル内の)User_ID。
注文がシステムに入力された日付。
これは、時に作成日と呼ばれる。可能な場合、これは、(ユーザが入力した日付ではなく)システムで生成された日付にする必要がある。この日付は、必ずしも、実際の取引の日付に対応していない。
この取引をシステムに入力した時間。ISO 8601表記の24時間制の時
刻(HHMM)(例: PM1:00 = 1300)。
出荷記録を承認した人の(User_List
ingファイル内の)User_ID。

16

Approved_Date

2

DATE

gl-usk:nextDateRepeat

17

Approved_Time

2

TIME

18

Last_Modified_By

2

TEXT

19

Last_Modified_Date

2

DATE

(This is included in the 入力が承認された時間。ISO 8601表
ISO 8601 representation o 記の24時間制の時刻(HHMM)(例: PM1:00 = 1300)。
f glusk:nextDateRepeat, menti
oned previously)
gl-bus:enteredByModified この入力を最後に修正したユーザの(User_Listingの)User_ID。
gl-usk:lastDateRepeat
入力が最後に変更された日付。

20

Last_Modified_Time

2

TIME

100

入力が承認された日付。

(This is included in the 入力が最後に変更された時間。ISO
ISO 8601 representation o 8601表記の24時間制の時刻(HHMM)
f gl(例: PM1:00 = 1300)。
usk:lastDateRepeat, menti
oned previously)
注記:詳細(明細項目)データが提供される場合、次のフィールドは省略される場合がある。

フ ィフィールド名ー ル
ド 番
号
21 Shipping_Amount_Local

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

NUMERIC

2

TEXT

23

Shipping_Amount_Local_CurrencySales_Order_Amount_Local

2

NUMERIC

24

Sales_Order_Local_Currency

2

25

Segment01

2

22

XBRL GLタクソノミ要素

説明

gl-muc:amountOriginalAmou
nt*

販売注文に関連する出荷帳票の商品の合計金額。
現地通貨で記録される。
現地国の報告で要求される通貨。ISO 4217コーディングを参照。
出荷帳票に関連する販売注文内の商品の合計金額。現地通貨で記録される。販売注文がない場合、空白のままにする。
現地国の報告で要求される通貨。ISO 4217コーディングを参照。販売注
文がない場合、空白のままにする。
プロフィット・センター、部門、ファンド、プログラム、支店、プロジ
ェクトなどのために使用することができる準備されたセグメントフィー
ルド。

3gl-muc:amountOriginalCurr
ency
gl-muc:amountOriginalAmou
nt

TEXT

3

gl-muc:amountOriginalCurr
ency

TEXT

25

gl-cor:accountSubID withassociated gl-cor:account
SubType(Note:XBRL GL tracks
hierarchy ID, hierarchy description, and hierarchy
type, so it can track cod
e NA, description N. America, and type global area

usinggl-cor:accountSubID, glco
r:accountSubDescription,and glcor:accountSubType,
respectively.)
26

Segment02

2

TEXT

25

上記参照

上記参照

27

Segment03

2

TEXT

25

上記参照

上記参照

28

Segment04

2

TEXT

25

上記参照

上記参照

29

Segment05

2

TEXT

25

上記参照

上記参照

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

コメント

value = “other”[entriesType]は必須フィールドである。
[other]は列挙型のである。
gl-cor: entriesComment
value = “ads:[entriesComment]は情報収集に共通しているものを説明する説明フィールドであShipments_Made_YYYYMMDD_YYYYMMDD”
り、
この表現に関連して収集するタイプの監
査データ標準の名前空間と修飾子を導入する。
*
出荷は複数の注文に対して行うことができるため、元の注文番号に関連する注文からの注文は、独立した1つのentryDetailとして表示され、注文明細行(元の注文情報を含む)と出荷明細行(元の注文情報を含まない、入力の見出しをグループ化することで関連付けられる)は区別される。
2.4 Shipments_Made_Lines_YYYYMMDD_YYYYMMDD

Shipments_Made_Lines_YYYYMMDD_YYYYMMDDファイルには、Shipments_Made_YYYYMMDD_YYYYMMDDファイル内にあるすべての出荷および出荷調整に対する詳細な明細項目が含まれる。このファイルの使用は任意であるが、管理しきれないデー
タ容量ではない限り、使用することが推奨される。このファイルには、関係がない産業(例えば、サービス業など)もある。
このファイルでは、各出荷または各出荷調整の各明細項目に対してそれぞれ1レコードとなる。

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

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

XBRL GLタクソノミ要素

説明

1

TEXT

100

gl-cor:documentReference

各出荷に一意の識別子。このIDは、(例えば、文書番号、文書種別、および年)は、各出荷を一意に識別するためのフィールドを連結することによって作成される必要がある。
Shipments_Made_YYYYMMDD_YYYYMMD
ファイル内のShipment_IDフィールドに一致しなければならない。

2

Shipping_Document_Line_ID

1

TEXT

10

gl-cor:lineNumber*

出荷帳票の明細行の参照番号。

3

Shipping_Product_ID

1

TEXT

25

gl-bus:measurableIDOther

各商品に一意の識別子。

4

Shipping_Product_Code

1

TEXT

25

gl-bus:measurableID

取引文書に表示される商品コード。

5

Shipping_Product_Description

1

TEXT

100

gl-bus:measurableDescription

商品の名前やその他の識別する特徴を表す説明(平易な英語)。

6

Shipping_Product_Bar_Code

2

TEXT

100

gl-bus:measurableIDOther

7

Shipping_Product_Group_01

2

TEXT

25

gl-bus:measurableCodeDesc
ription

商品統一コード(UPC)またはその他の一般識別子。
商品の記述子(01)。例えば、タイヤや付属品など。

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

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

TEXT

説明

25

gl-bus:measurableCategory 商品の記述子(02)。例えば、銘柄など。
gl-bus:measurableQuantity 出荷された商品量。

25

gl-bus:measurableUnitOfMe
asure
gl-bus:measurableCostPerU
nit
gl-muc:amountOriginalAmou
nt*

9

Shipping_Quantity

1

NUMERIC

10

Shipping_Unit_of_Measure

2

TEXT

11

Shipping_Unit_Price

1

NUMERIC

12

Shipping_Line_Amount_Local

1

NUMERIC

13

Shipping_Line_Amount_Local_Cu
rrencySales_Order_Line_ID

1

TEXT

3

1

TEXT

10

14

XBRL GLタクソノミ要素

計量の基本単位。

出荷された商品の単位あたりの価格。
販売注文に関連する出荷帳票内の明細項目の合計金額。
現地通貨で記録される。
gl-muc:amountOriginalCurr 現地国の報告で要求される通貨。ISency
O 4217コーディングを参照。
gl-cor:lineNumber*
出荷された商品に対する販売注文の明細行ID。Sales_Orders_YYYYMMDD_YYYYMMDDファイル内のSales_Order_
Line_IDに一致しなければならない。
販売注文がない場合、空白のままに
する。

15

Sales_Order_Quantity

2

NUMERIC

gl-bus:measurableQuantity

16

Sales_Order_Unit_of_Measure

2

TEXT

17

Sales_Order_Unit_Price

2

NUMERIC

gl-bus:measurableCostPerU
nit

18

Sales_Order_Line_Amount_Local

1

NUMERICgl-muc:amountOriginalAmou
nt

25

gl-bus:measurableUnitOfMe
asure

販売注文明細行のはじめの量。販売
注文がない場合、空白のままにする。
販売注文明細行の基本計量単位。販
売注文がない場合、空白のままにする。
販売注文明細行の単位当たりの価格。販売注文がない場合、空白のままにする。
出荷帳票の明細項目に関連する販売
注文内の明細項目の金額。現地通貨で記録される。販売注文がない場
合、空白のままにする。

フ ィフィールド名ー ル
ド 番
号
19 Sales_Order_Local_Currency

20

21

Segment01

Segment02

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

TEXT

3

2

TEXT

25

2

TEXT

25

XBRL GLタクソノミ要素

説明

gl-muc:amountOriginalCurr 現地国の報告で要求される通貨。ISency
O 4217コーディングを参照。販売注
文がない場合、空白のままにする。
gl-cor:accountSubID with
プロフィット・センター、部門、フassociated gl-cor:account ァンド、プログラム、支店、プロジ
SubTypeェクトなどのために使用することができる準備されたセグメントフィー(Note:XBRL GL tracks
ルド。
hierarchy ID, hierarchy description, and hierarchy
type, so it can track cod
e NA, description N. America, and type global area
using
gl-cor:accountSubID, glco
r:accountSubDescription,and glcor:accountSubType,
respectively.)
上記参照
上記参照

22

Segment03

2

TEXT

25

上記参照

上記参照

23

Segment04

2

TEXT

25

上記参照

上記参照

24

Segment05

2

TEXT

25

上記参照

上記参照

XBRL GLへの追加コメント
出荷済リストのうちで追加的に必須若しくは望ましいフィールドは次のとおりである。

要素
gl-cor:entriesType

内容
value = “other”

コメント[entriesType]は必須フィールドである。[other]は列挙型のである。
gl-cor: entriesComment value = “ads:[entriesComment]は情報収集に共通しているものを説明する説明フィールドであShipments_Made_Lines_YYYYMMDD_YYYYMMDD”
り、
この表現に関連して収集するタイプの監
査データ標準の名前空間と修飾子を導入する。
*
出荷は複数の注文に対して行うことができるため、元の注文番号に関連する注文からの注文は、独立した1つのen
tryDetailとして表示され、注文明細行(元の注文情報を含む)と出荷明細行(元の注文情報を含まない、入力の見出しをグループ化することで関連付けられる)は区別される。

2.5 Invoices_Generated_YYYYMMDD_YYYYMMDD

Invoices_Generated_YYYYMMDD_YYYYMMDDファイルは、少なくとも、調査中の期間内に生成されたすべての請求書を含む。
監査人は、含めるべき過去の請求書を決定するための判断をしなければならない。

このフラットフォーマットファイルでは、各請求書に関連付けられる各販売注文に対してそれぞれ1レコードとなる。例
えば、1つの請求書に3つの販売注文からの商品が含まれていた場合、この請求書に対しては3つのレコードがあることになり、1レコードは3つの販売注文の1つずつに関連付けられる請求書内の複数商品に対応する。XBRL GLはgl-taf:origin
atingDocumentNumberを利用してgl-cor:entryDetail行を関連する取引文書に関連付ける。ただし、この設計では、個別のglcor:entryHeaderレコードを使用することでフラットファイルフォーマットでより大きな比較可能性を持つ。

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

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

TEXT

100

100

2

Invoice_Number

1

TEXT

3

Invoice_Date

1

DATE

XBRL GLタクソノミ要素

gl-cor:documentReference

説明

各請求書に一意の識別子。このIDは、(例えば、文書番号、文書種
別、および年)は、各取引を一意に識別するためのフィールドを連結することによって作成される必要がある。請求書データを含む次のすべてのテーブルと同じIDが使用されていなければならない(Invoices_Generated_YYYYMMDD_YYYYMMDD、Open_Accounts_Receivable_
YYYYMMDD、AR_Cash_Application_YY
YYMMDD_YYYYMMDD、およびAR_Adjust
ments_YYYYMMDD_YYYYMMDD)。
gl-cor:documentNumber wit 内部で作成された請求書の識別番
h glcor:documentType = 号。
“invoice”
gl-cor:documentDate
請求書の日付。請求書が入力された日付とは関係がない。請求書の条件に基づいて計算された日付。

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

5

Invoice_Period

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

XBRL GLタクソノミ要素

1

TEXT

4

gl-bus:fiscalYearEnd

1

TEXT

10

gl-bus:postingCode

6

Invoice_Due_Date

1

DATE

7

Sales_Order_ID

1

TEXT

100

説明

Invoice_Dateが記帳された会計年度。YYYYは区切りに使用される。XB
RL GLタクソノミフレームワークのための会計期末CCYY-MM-DD(ISO 860
1)。
Invoice_Dateが記帳された会計期間。

例には、週単位の期間としてW1–W5
3、月単位の期間としてM1–M12、四半期単位の期間としてQ1–Q4を含む。
gl-cor:MaturityDate
顧客からの支払期日。債権の年齢調
べは、通常はこの日付に基づいて計算される。
gl-taf:originatingDocumen 請求項目に対する販売注文ID。SaletNumber with gls_Orders_YYYYMMDD_YYYYMMDDファイ
taf:originatingDocumentTy ル内のSales_Order_IDに一致しなけ
ればならない。
pe = “order-customer”*
販売注文がない場合、空白のままにする。

8

Business_Unit_Code

1

TEXT

50

9

Customer_Account_ID

1

TEXT

100

gl-cor:organizationidenti 財務諸表が監査対象となるレベルでfier
事業単位、地域、支店などを識別するために利用される。Business_Uni
t_Listingファイル内のBusiness_Un
it_Codeと一致しなければならない。
gl-cor:identifierCode wit 支払が予想されている顧客の識別子
h glidentifierType = “cu か、買掛計上に対する支払を行う顧客の識別子。Customer_Master_List
stomer”
ing_YYYYMMDDファイル内のCustomer_Account_IDと一致しなければなら
ない。

フ ィ
フィールド名ー ル
ド 番
号
10 Terms_Discount_Percentage

11

Terms_Discount_Days

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

XBRL GLタクソノミ要素説明

2

NUMERIC

gl-cor:terms

顧客が請求書の一定の日数前に支払う場合の割引率。フラットファイル
では、小数点以下１桁として表現される(例えば、10％が10.0として表現される)。拡張事業報告言語のXBR
L GLタクソノミフレームワークにおいては、3つのフィールドTerms_Dis
count_Percentage、Terms_Discount_DaysおよびTerms_Due_Daysの3つのフィールドは、「xx.x％ dd 最終支
払期日 dd」の形式で入力されることになる。例えば実質支払期間が30日で、10日以内に支払うと2％割引となる場合では「2％ 10 最終支払
期日 30」で表現される。

2

NUMERICSee description for field 請求書日付からの日数は、顧客が# 10割引を利用するために有利である。これは小数点以下がない桁数(例えば、nnn)として数字として表
現される。

12

Terms_Due_Days

2

NUMERIC

13Entered_By

1

TEXT

14

Entered_Date

2

DATE

15

Entered_Time

2

TIME

16

Approved_By

2

TEXT

100

100

See description for field# 10; explicit in gl-cor:maturityDate
gl-cor:identifierCode wit
h glcor:identifierCategor
y = “systemUser”
gl-cor:enteredDate

請求書に対する支払遅延となる前の、支払義務を果たすことが可能な日数。
記録を残した人の(User_Listingファイル内の)User_ID。

取引がシステムに入力された日付。
これは、時に作成日と呼ばれる。可能な場合、これは、(ユーザが入力した日付ではなく)システムで生成された日付にする必要がある。この日付は、必ずしも、実際の取引の日付に対応していない。
この取引をシステムに入力した時(This is included in the
ISO 8601 representation o 間。ISO 8601表記の24時間制の時
f glcor:enteredDate, abov 刻(HHMM)(例: PM1:00 = 1300)。
e)
gl-cor:entryResponsiblePe 顧客マスタの追加や変更の承認者のrson(User_Listingファイルの)User_I
D。

フ ィ
フィールド名ー ル
ド 番
号
17 Approved_Date

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

XBRL GLタクソノミ要素

説明

2

DATE

gl-usk:nextDateRepeat(This is included in the 入力が承認された時間。ISO 8601表
ISO 8601 representation o 記の24時間制の時刻(HHMM)
f gl(例: PM1:00 = 1300)。
usk:nextDateRepeat, menti
oned previously.)
gl-bus:enteredByModified この入力を最後に修正したユーザの(User_Listingの)User_ID。
gl-usk:lastDateRepeat
入力が最後に変更された日付。

18

Approved_Time

2

TIME

19

Last_Modified_By

2

TEXT

20

Last_Modified_Date

2

DATE

21

Last_Modified_Time

2

TIME

100

入力が承認された日付。

(This is included in the 入力が最後に変更された時間。ISO
ISO 8601 representation o 8601表記の24時間制の時刻(HHMM)
f gl(例: PM1:00 = 1300)。
usk:lastDateRepeat, menti
oned previously.)フ ィフィールド名ー ル
ド 番
号
22 Grouping_Codeレ ベ フラットファイル
ル
データ
データ型 長さ
2

TEXT

説明

複数の請求書のバッチ処理またはグループ化において関連する項目をグ
ループ化する仕組み。例えば、特定のERPシステムで見つかった請求書のグループ化をする場合などがある。
注記:詳細(明細項目)データが提供される場合、次のフィールドは省略される場合がある。

23

Invoice_Amount1

NUMERIC

24

Invoice_Amount_Currency

1

TEXT

25

Invoice_Amount_Reporting

1

NUMERIC

26

Invoice_Reporting_Currency

1

TEXT

100

XBRL GLタクソノミ要素

gl-bus:batchID

gl-cor:amount3

3

gl-muc:amountCurrency

機能通貨またはグループ通貨で記録された取引金額。すべて取引が単一通貨に記録されているため、多通貨換算を実行する必要はない。

請求金額に関連する機能通貨やグループ通貨。ISO 4217コーディングを参照。
gl-muc:amountTriangulatio 報告通貨で記録された取引金額。
nAmount
gl非連結報告のための請求書の報告金
muc:amountTriangulationCu 額に関連する報告通貨。ISO 4217コ
rrencyーディングを参照。

27

Invoice_Amount_Local

1

NUMERIC

28

Invoice_Local_Currency

1

TEXT

gl-muc:amountOriginalAmou 現地通貨での取引金額。
nt
通常は、原本請求書に記載された金額である。
3

gl-muc:amountOriginalCurr 現地国の報告で要求される通貨。ISency
O 4217コーディングを参照。

フ ィフィールド名ー ル
ド 番
号
29 Tax1_Type30

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

1

TEXT

TEXT

25

25

XBRL GLタクソノミ要素

説明

gl-cor:taxCode (Note thatXBRL GL permits an unlimi
ted number of tax codes and amounts with the glco
r:taxes structure.)

税1タイプのコード(例: 売上税、付加価値税)。

同上

税2タイプのコード(例: 売上税、付加価値税)。

このフィールドは、Tax_Table_YYYY
MMDDのRegulator_Codeフィールドと一致する必要がある。

このフィールドは、Tax_Table_YYYY
MMDDのRegulator_Codeフィールドと一致する必要がある。

31

Tax3_Type

1

TEXT

25

同上

税3タイプのコード(例: 売上税、付加価値税)。
このフィールドは、Tax_Table_YYYY
MMDDのRegulator_Codeフィールドと一致する必要がある。

32

Tax1_Type_Description

1

TEXT

100

33

Tax2_Type_Description

1

TEXT

100

34

Tax3_Type_Description

1

TEXT

100

gl-cor:taxDescription (No 税1タイプの説明(例: 税を支払う税
te that XBRL GL formalize 務当局や、税を特定するためのその他の情報など)。
s the tax authority withgl-cor:taxAuthority and p
rovides other standard fi
elds as well.)
同上
税2タイプの説明(例: 税を支払う税
務当局や、税を特定するためのその他の情報など)。
同上
税3タイプの説明(例: 税を支払う税
務当局や、税を特定するためのその他の情報など)。

フ ィフィールド名ー ル
ド 番
号
35 Tax1_Local

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

NUMERIC36

Tax2_Local

2

NUMERIC37

Tax3_Local

2

NUMERIC

38

Segment01

2

TEXT

XBRL GLタクソノミ要素

gl-cor:taxAmount25

説明

税1タイプの金額は、取引に含まれている。現地通貨で記録される。
同上
税2タイプの金額は、取引に含まれている。現地通貨で記録される。
同上
税3タイプの金額は、取引に含まれている。現地通貨で記録される。
gl-cor:subAccountID with
プロフィット・センター、部門、フassociated gl-cor:account ァンド、プログラム、支店、プロジ
SubTypeェクトなどのために使用することができる準備されたセグメントフィー(Note:XBRL GL tracks
ルド。
hierarchy ID, hierarchy description, and hierarchy
type, so it can track cod
e NA, description N. America, and type global area
using
gl-cor:accountSubID, glco
r:accountSubDescription,and glcor:accountSubType,
respectively.)39

Segment02

2

TEXT

25

上記参照

上記参照

40

Segment03

2

TEXT

25

上記参照

上記参照

41

Segment04

2

TEXT

25

上記参照

上記参照

42

Segment05

2

TEXT

25

上記参照

上記参照

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

value = “other”

gl-cor: entriesComment

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

請求書は多くの場合出荷情報に反映され、出荷は複数の注文に対して行うことができるため、元の注文番号に関連する注文や出荷からの各請求詳細は、独立した1つのentryDetailとして表示され、注文詳細(元の注文情報を含む)と請求詳細(元の注文情報はない、入力の見出しをグループ化することで関連付けられる)は区別される。

*

2.6 Invoices_Generated_Lines_YYYYMMDD_YYYYMMDD

Invoices_Generated_Lines_YYYYMMDD_YYYYMMDDファイルには、Invoices_Generated_YYYYMMDD_YYYYMMDDファイル内にある請求書の詳細な明細項目が含まれる。
このファイルの使用は任意であるが、管理しきれないデータ容量ではない限り、使用することが推奨される。
このファイルでは、請求書の明細項目または販売注文の明細項目の各組み合わせに対してそれぞれ1レコードとなる。
通常は請求書の各明細項目は販売注文の1つの明細項目に関連付けられるため、このファイルは請求書の各明細項目に対してそれぞれ1レコードとなる。稀に、請求書の明細項目が複数の販売注文の明細項目に関連付けられていることがあり、この場合は、このファイルでは請求書の明細項目に関連する販売注文の各明細項目に対してそれぞれ1レコード
となる。

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

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

XBRL GLタクソノミ要素

説明

各請求書に一意の識別子。このIDは、(例えば、文書番号、文
書種別、および年)は、各取引を一意に識別するためのフィールドを連結することによって作成される必要がある。請求書データを含む次のすべてのテーブ
ルと同じIDが使用されていなけ
ればならない(Invoices_Generated_YYYYMMDD_YYYYMMDD、Open_Accounts_Receivable_YYYYMMDD、AR_Cash_Ap
plication_YYYYMMDD_YYYYMMD
D、およびAR_Adjustments_YYYY
MMDD_YYYYMMDD)。
請求書の明細項目番号。

1

TEXT

100

gl-cor:documentReference

2

Invoice_Line_ID

1

TEXT

10

gl-cor:lineNumber*

3

Sales_Order_ID

1

TEXT

100

gl-taf:originatingDocument
Number with gl-taf:origina
tingDocumentType = “order-customer”*

請求項目に対する販売注文ID。
Sales_Orders_YYYYMMDD_YYYYMM
DDファイル内のSales_Order_IDと一致しなければならない。
販売注文がない場合、空白のま
まにする。

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

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

XBRL GLタクソノミ要素

1

TEXT

10

gl-cor:lineNumber*

説明

販売注文の明細行番号の識別子。
Sales_Orders_Lines_YYYYMMDD_YYYYMMDDファイル内のSales_Or
der_Line_IDに一致しなければならない。
販売注文がない場合、空白のままにする。
各販売商品に一意の識別子。

5

Invoice_Product_ID

1

TEXT

25

gl-bus:measurableID

6

Invoice_Product_Description

1

TEXT

100

gl-bus:measurableDescripti 商品の名前やその他の識別する
on
特徴を表す説明(平易な英語)。

7Invoice_Product_Group_01

2

TEXT

25

8

Invoice_Product_Group_02

2

TEXT

25

gl-bus:measurableCodeDescr 商品の記述子(01)。例えば、タiptionイヤや付属品など。
gl-bus:measurableCategory 商品の記述子(02)。例えば、銘
柄など。

9

Invoice_Line_Amount1

NUMERIC

gl-cor:amount10

Invoice_Line_Amount_Currency

1

TEXT

11

Invoice_Line_Amount_Reporting

1

NUMERIC

12

Invoice_Line_Reporting_Currenc
y

1

TEXT

13

Invoice_Line_Amount_Local

1

NUMERIC

14

Invoice_Line_Local_Currency

1

TEXT

3

15

Grouping_Code

2

TEXT

100

3

3

機能通貨またはグループ通貨で記録された取引金額。すべて取引が単一通貨に記録されているため、多通貨換算を実行する必要はない。
gl-muc:amountCurrency
請求金額に関連する機能通貨やグループ通貨。ISO 4217コーデ
ィングを参照。
gl-muc:amountTriangulation 報告通貨で記録された取引金
Amount額。
gl非連結報告のための請求書の報
muc:amountTriangulationCur 告金額に関連する報告通貨。ISrency
O 4217コーディングを参照。
gl-muc:amountOriginalAmoun 現地通貨での取引金額。
t
gl-muc:amountOriginalCurre 現地国の報告で要求される通ncy
貨。ISO 4217コーディングを参照。
gl-bus:batchID
複数の請求書のバッチ処理またはグループ化において関連する項目をグループ化する仕組み。
例えば、特定のERPシステムで見つかった請求書のグループ化をする場合などがある。

フ ィフィールド名ー ル
ド 番
号
16 Tax1_Type1718

Tax2_Type

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

1

1

TEXT

TEXT

TEXT

25

25

25

XBRL GLタクソノミ要素

説明

gl-cor:taxCode (Note thatXBRL GL permits an unlimit
ed number of tax codes andamounts with the glcor:tax
es structure.)

税1タイプのコード(例: 売上税、付加価値税)。

同上

同上

このフィールドは、Tax_Table_
YYYYMMDDのRegulator_Codeフィ
ールドと一致する必要がある。
税2タイプのコード(例: 売上税、付加価値税)。
このフィールドは、Tax_Table_
YYYYMMDDのRegulator_Codeフィ
ールドと一致する必要がある。
税3タイプのコード(例: 売上税、付加価値税)。
このフィールドは、Tax_Table_
YYYYMMDDのRegulator_Codeフィ
ールドと一致する必要がある。

フ ィフィールド名ー ル
ド 番
号
19 Tax1_Type_Description

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

TEXT

100

XBRL GLタクソノミ要素

説明

税1タイプの説明(例: 税を支払
う税務当局や、税を特定するためのその他の情報など)。

20

Tax2_Type_Description

1

TEXT

100

gl-cor:taxDescription (Note that XBRL GL formalizes
the tax authority with glcor:taxAuthority and provi
des other standard fields
as well.)
同上

21

Tax3_Type_Description

1

TEXT

100

同上

22

Tax1_Local

2

NUMERIC

gl-cor:taxAmount

税2タイプの説明(例: 税を支払
う税務当局や、税を特定するためのその他の情報など)。
税3タイプの説明(例: 税を支払
う税務当局や、税を特定するためのその他の情報など)。
税タイプ1の金額は、取引に含まれている。現地通貨で記録さ
れる。

フ ィ
フィールド名ー ル
ド 番
号
23 Tax2_Local

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

XBRL GLタクソノミ要素

2

NUMERIC

同上

同上

24

Tax3_Local

2

NUMERIC25

GL_Line_Debit_Account_Number

1

TEXT

100

gl-cor:accountMainID withglcor:accountPurposeDescr
iption = “debit-value”
in a second account structure (Note:XBRL GL permits an unlimited number ofaccounts or values with atransaction, and is not l
imited to a single debit
or credit value)

説明

税タイプ2の金額は、取引に含まれている。現地通貨で記録される。
税タイプ3の金額は、取引に含まれている。現地通貨で記録される。
取引において借方に記帳されたGL勘定科目の番号。

26

GL_Line_Credit_Account_Number

1

TEXT

100

27

GL_Tax1_Debit_Account_Number

1

TEXT

100

gl-cor:accountMainID withglcor:accountPurposeDescri
ption = “credit-value” in a second account structure
XBRL GL does not have fiel
ds explicitly associating
GL accounts to tax, althou
gh it does permit specification of accounts as tax a
ccounts (glcor:accountPurposeCode);
it associates tax detailin the glcor:taxes struct
ure with specific accounts by including them within the same gl-cor:entryDetail if the glcor:amountis the same, or within the same gl-cor:entryHeader
if amounts differ.As with
the GL lines above, the account numbers would be mapped to be mapped to glc
or:accountMainID.

取引において貸方に記帳されたGL勘定科目の番号。

税1の取引において借方に記帳されたGL勘定科目の番号。

フ ィ
フィールド名ー ル
ド 番
号
28 GL_Tax1_Credit_Account_Number

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

XBRL GLタクソノミ要素

説明

1

TEXT

100

同上

税1の取引において貸方に記帳されたGL勘定科目の番号。

29

GL_Tax2_Debit_Account_Number

1

TEXT

100

同上

税2の取引において借方に記帳されたGL勘定科目の番号。

30

GL_Tax2_Credit_Account_Number

1

TEXT

100

同上

税2の取引において貸方に記帳されたGL勘定科目の番号。

31

GL_Tax3_Debit_Account_Number

1

TEXT

100

同上

税3の取引において借方に記帳されたGL勘定科目の番号。

32

GL_Tax3_Credit_Account_Number

1

TEXT

100

同上

税3の取引において貸方に記帳されたGL勘定科目の番号。

32

Segment01

2

TEXT

25

gl-cor:accountSubID withassociated gl-cor:account
SubType(Note:XBRL GL tracks

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

hierarchy ID, hierarchy description, and hierarchy type, so it can track codeNA, description N. America, and type global area us
ing

33

Segment02

2

TEXT

25

gl-cor:accountSubID, glco
r:accountSubDescription, a
nd glcor:accountSubType, r
espectively.)
上記参照
上記参照

34

Segment03

2

TEXT

25

上記参照

上記参照

35

Segment04

2

TEXT

25

上記参照

上記参照

36

Segment05

2

TEXT

25

上記参照

上記参照

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

value = “other”[entriesType]は必須フィールドである。[other]は列挙型のである。
gl-cor: entriesComment value = “ads:[entriesComment]は情報収集に共通しているものを説明する説明フィールドであInvoices_Generated_Lines_YYYYMMDD_YYYYMMDり、
D”
この表現に関連して収集するタイプの監
査データ標準の名前空間と修飾子を導入する。
*
請求書は多くの場合出荷情報に反映され、出荷は複数の注文に対して行うことができるため、元の注文番号に関連する注文や出荷からの各請求詳細は、独立した1つのentryDetailとして表示され、注文詳細(元の注文情報を含む)と請求詳細(元の注文情報はない、入力の見出しをグループ化することで関連付けられる)は区別される。

2.7 Open_Accounts_Receivable_YYYYMMDD

Open_Accounts_Receivable_YYYYMMDDテーブルには、指定期日(監査期間の終了あるいは年度末のような)の業務の完了の時点でのすべての未決、未払、あるいは未解決の取引に関する詳細を含んでいる。調査中の期間における売掛債権残高のロールフォワードの場合に、これらのファイルが2つになる場合がある。
このテーブル中の列は、1つのユニークで識別可能な取引について顧客からの支払いが期待される残高を表わす。このファイルは請求書毎の概要レベルである必要はあるが、請求書の明細項目ごとの詳細レベルである必要はない。指定期日の時点での取引金額の合計は、同じ日の総勘定元帳(GL)中の売掛債権金額合計と一致するはずである。
ファイルは未決の請求書(最初の請求内容が表示され、請求金額が支払われていないまま残っているもの)を含むか、またはすべての文書(請求書・入金額・調整額を含む)を詳細レベルで含んで生成されることがある。いずれにしても、他のファイルからの情報を合わせることで情報の選別が可能になる。
フ ィフィールド名レベ フラットファイルデ
XBRL GLタクソノミ要素
説明
ー ル
ル
ータ
ド 番
データ型
長さ
号
1
Customer_Account_ID
1
TEXT
100
gl-cor:identifierCode wit 支払が予想されている顧客の識
h glcor:identifierType = 別子か、買掛計上に対する支払“customer”
を行う顧客の識別子。Customer_Master_Listing_YYYYMMDDファ
イル内のCustomer_Account_IDと一致しなければならない。

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

3

Transaction_Date

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

TEXT

1

DATE

100

XBRL GLタクソノミ要素

説明

gl-cor:documentReference

各請求書に一意の識別子。このIDは、(例えば、文書番号、文
書種別、および年)は、各取引を一意に識別するためのフィールドを連結することによって作成される必要がある。請求書データを含む次のすべてのテーブ
ルと同じIDが使用されていなけ
ればならない(Invoices_Generated_YYYYMMDD_YYYYMMDD、 Open_Accounts_Re
ceivable_YYYYMMDD、AR_Cash_A
pplication_YYYYMMDD_YYYYMMD
D、およびAR_Adjustments_YYYY
MMDD_YYYYMMDD)。
取引の日付。請求書が入力された日付とは関係がない。請求書の条件に基づいて計算された日付。

gl-cor:documentDate

4Transaction_Type

2

TEXT

5

Transaction_Due_Date

1

DATE

6

Balance_Amount

2

NUMERIC25

glcor:documentTypeDescrip 取引の借方または貸方の金額がtion
顧客によって消滅、または借方となった方法のコード値/指標(例えば、小切手、電信送金、現金、貸方メモ、請求書、利息
If additional informati
のみの請求書など)。上記がな
on is needed over the e
い場合、デフォルトの請求書となる。
numerated
gl-cor:documentType; see
the following enumerationtable.
gl-cor:maturityDate
顧客からの支払期日。すべての取引に支払期日があるわけではない(例えば、貸方メモなど)。
債権の年齢調べは、通常はこの日付に基づいて計算される。
gl-taf:documentRemainingB 機能通貨またはグループ通貨でalance
記録された残高の合計金額。すべて取引が単一通貨に記録されているため、多通貨換算を実行する必要はない。

フ ィフィールド名ー ル
ド 番
号
7Balance_Amount_Currency

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

TEXT

8

Balance_Amount_Reporting

2

NUMERIC

9Balance_Reporting_Currency

2

TEXT

10

Balance_Amount_Local

2

NUMERIC

11

Balance_Local_Currency

2

TEXT

12

Original_Balance_Amount1

NUMERIC

13

Original_Balance_Amount_Local

2

NUMERIC

3

3

3

XBRL GLタクソノミ要素

説明

gl-muc:amountCurrency

残高に関連する機能通貨やグループ通貨。ISO 4217コーディン
グを参照。
gl報告通貨で記録された残高金
muc:amountTriangulationAm 額。
ount
gl非連結報告のための残高の報告
muc:amountTriangulationCu 金額に関連する報告通貨。ISO
rrency4217コーディングを参照。
gl-muc:amountOriginalAmou 現地通貨での残高金額。
nt
gl-muc:amountOriginalCurr 現地国の報告で要求される通ency
貨。ISO 4217コーディングを参照。
gl-cor:amount
機能通貨またはグループ通貨で記録されたはじめの残高(はじめの請求金額)。
gl-muc:amountOriginalAmou 現地通貨での金額(はじめの請
nt
求金額)。

フ ィ
フィールド名ー ル
ド 番
号
14 Original_Balance_Amount_Reporti
ng
15

16

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

XBRL GLタクソノミ要素

説明

NUMERIC

gl報告通貨で記録された金額(は
muc:amountTriangulationAm じめの請求金額)。
ount
Business_Unit_Code
1
TEXT
50
gl-bus:organizationIdenti 財務諸表が監査対象となるレベルで事業単位、地域、支店など
fierを識別するために利用される。
Business_Unit_Listingファイ
ル内のBusiness_Unit_Codeと一致しなければならない。
Grouping_Code
2
TEXT
100
gl-bus:batchID
複数の請求書のバッチ処理またはグループ化において関連する項目をグループ化する仕組み。
例えば、特定のERPシステムで見つかった請求書のグループ化をする場合などがある。
注記:詳細(取引レベルの)データが提供される場合、次のフィールドは省略される場合がある。

17

Amount_Credit_Debit_Indicator

2

TEXT

1 gl-cor:debitCreditCode18

Amount_Currency

2

TEXT

3 gl-muc:amountCurrency

金額は借方か貸方かの指標。"C"は貸方、"D"は借方。
金額に関連する機能通貨やグループ通貨。ISO 4217コーディン
グを参照。

19

Amount_Reporting_Currency

2

TEXT

20

Amount_Local_Currency

2

TEXT

21

Reference_Number

2

TEXT

22

Reference_Date

2

DATE

3 gl非連結報告のための金額に関連
muc:amountTriangulationCu する報告通貨。
ISO 4217コーディングを参照。
rrency3 gl-muc:amountOriginalCurr 現地国の報告で要求される通ency
貨。ISO 4217コーディングを参照。
100 gl-cor:documentNumber
内部または外部で生成された取引の識別番号(例えば、小切手
番号、電信送金番号、または原始文書ID)。
gl-cor:documentDate
外部で生成された取引の日付(例えば、小切手日付や電信送
金日付)。

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

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

TEXT

25

XBRL GLタクソノミ要素

説明

gl-cor:accountSubID with プロフィット・センター、部
associated gl-cor:account 門、ファンド、プログラム、支SubType
店、プロジェクトなどのために(Note:XBRL GL tracks

使用することができる準備されたセグメントフィールド。

hierarchy ID, hierarchy
description, and hierarchy type, so it can track c
ode NA, description N. Am
erica, and type global area using
gl-cor:accountSubID, glc
or:accountSubDescription,and gl-cor:accountSubType, respectively.)
24

Segment02

2

TEXT

25

上記参照

上記参照

25

Segment03

2

TEXT

25

上記参照

上記参照

26

Segment04

2

TEXT

25

上記参照

上記参照

27

Segment05

2

TEXT

25

上記参照

上記参照

28

Clearing_Document

2

TEXT

100

gl-cor:documentApplyToNum 実際の取引活動とリンクする決
ber
済文書のID番号。

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

value = “other”

gl-cor: entriesComment

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

2.8 Cash_Received_YYYYMMDD_YYYYMMDD

Cash_Received_YYYYMMDD_YYYYMMDDファイルには、期間内のすべての支払受領済の取引(小切手、電信送金、現金など)が
含まれる。
フ ィ
フィールド名レ ベ フラットファイルXBRL GLタクソノミ要素
説明
ー ル
ル
データ
ド 番
データ型
長さ
号
1
Receipt_ID
1
TEXT
100
gl-cor:documentReference 支払領収済みの各取引に一意の識別子。このIDは、(例えば、顧客番号
や支払番号)は、各取引を一意に識別するためのフィールドを連結する
ことによって作成される必要がある。
2Customer_Account_ID
1
TEXT
100
gl-cor:identifierCode wit 支払を行う顧客の識別子か、買掛計上が行われる顧客の識別子。
h glcor:identifierType =Customer_Listing_YYYYMMDDファイ“customer”
ル内のCustomer_Account_IDと一致しなければならない。

3

Business_Unit_Code

1

TEXT

4

Receipt_Date

1

DATE

5

Receipt_Fiscal_Year

1

6

Receipt_Period

17Reference_Number

150

gl-bus:organizationIdenti 財務諸表が監査対象となるレベルでfier
事業単位、地域、支店などを識別するために利用される。Business_Uni
t_Listingファイル内のBusiness_Un
it_Codeと一致しなければならない。
gl-bus:documentReceivedDa 顧客の支払が受領された、または顧te
客の与信が通った日付。

TEXT

4

gl-bus:fiscalYearEnd

TEXT

10

gl-bus:postingCode

TEXT

100

gl-cor:documentNumber

Receipt_Dateが記帳された会計年度。YYYYは区切りに使用される。XB
RL GLタクソノミフレームワークのための会計期末CCYY-MM-DD(ISO 860
1)。
Receipt_Dateが記帳された会計期間。
例には、週単位の期間としてW1–W5
3、月単位の期間としてM1–M12、四半期単位の期間としてQ1–Q4を含む。
内部または外部で生成された取引の識別番号(例えば、小切手番号、電信送金番号、または原始文書ID)。

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

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

XBRL GLタクソノミ要素

gl-cor:documentDate

9

Amount_Credit_Debit_Indicator

2

TEXT

1

10

Receipt_Type

1

TEXT

25

11

Receipt_Amount1

NUMERIC

gl-cor:debitCreditCode

説明

外部で生成された取引の日付(例えば、小切手日付や電信送金日付)。

金額は借方か貸方かの指標。"C"は貸方、"D"は借方。
gl-cor:documentType = “c 取引の借方または貸方金額が顧客にheck” or gl-cor:document よって消滅または借方となった方法
Type = “paymentother” w のコード値/指標(例えば、小切手、
ith code in glbus:payment 電信送金、現金など)。Receipt_Typ
e_Listing_YYYYMMDDファイル内のRe
Methodceipt_Typeに一致しなければならない。
gl-cor:amount
機能通貨またはグループ通貨で記録された取引金額。すべて取引が単一通貨に記録されているため、多通貨換算を実行する必要はない。

フ ィフィールド名ー ル
ド 番
号
12 Receipt_Amount_Currency

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

TEXT

3

13

Receipt_Amount_Reporting

1

NUMERIC

14

Receipt_Amount_Reporting_Curr
ency

1

TEXT

15

Receipt_Amount_Local

1

NUMERIC

16

Receipt_Amount_Local_Currency

1

TEXT

3

17

Posting_Status

2

TEXT

20

3

XBRL GLタクソノミ要素

gl-muc:amountCurrency

説明

領収金額に関連する機能通貨やグループ通貨。ISO 4217コーディングを参照。
gl-muc:amountTriangulatio 報告通貨で記録された取引金額。
nAmount
gl非連結報告のための領収金額に関連
muc:amountTriangulationCu する報告通貨。ISO 4217コーディン
rrencyグを参照。
gl-muc:amountOriginalAmou 現地通貨での取引金額。
nt
gl-cor:amountOriginalCurr 現地国の報告で要求される通貨。ISency
O 4217コーディングを参照。
gl-cor:postingStatus enum 総勘定元帳への取引記帳のステータ
erations or gl-cor:postin ス(例えば、「記帳済」、「未記gStatus of “other” with 帳」)。
glcor:postingStatusDescript
ion

18

GL_Debit_Account_Number

2

TEXT

100

19

GL_Credit_Account_Number

2

TEXT

100

20

Entered_By

1

TEXT

100

21

Entered_Date

2

DATE

22

Entered_Time

2

TIME

gl-cor:accountMainID withglcor:accountPurposeDescr
iption = “debit-value”
in a second account structure
gl-cor:accountMainID withglcor:accountPurposeDescr
iption = “credit-value”
in a second account structure
gl-cor:identifierCode wit
h glcor:identifierCategor
y = “systemUser”
gl-cor:enteredDate

取引において借方に記帳されたGL勘定科目の番号。

(This is included in the
ISO 8601 representation of glcor:enteredDate, ment
ioned previously)

この取引をシステムに入力した時間。ISO 8601表記の24時間制の時
刻(HHMM)(例: PM1:00 = 1300)。

取引において貸方に記帳されたGL勘定科目の番号。

記録を残した人の(User_Listingファイル内の)User_ID。
この取引がシステムに入力された日付。これは、時に作成日と呼ばれる。可能な場合、これは、(ユーザが入力した日付ではなく)システム
で生成された日付にする必要がある。この日付は、必ずしも、CheckW
ire_Dateや実際の取引の日付に対応していない。

フ ィフィールド名ー ルド 番
号
23 Approved_By

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

TEXT

24

Approved_Date

2

DATE

25

Approved_Time

2

TIME

26

Last_Modified_By

2

TEXT

27

Last_Modified_Date

2

DATE

28

Last_Modified_Time

2

TIME

100

100

XBRL GLタクソノミ要素

説明

gl-cor:entryResponsiblePe 顧客マスタの追加や変更の承認者のrson(User_Listingファイルの)User_I
D。
gl-usk:nextDateRepeat
入力が承認された日付。
(This is included in the 入力が承認された時間。ISO 8601表
ISO 8601 representation o 記の24時間制の時刻(HHMM)
f gl(例: PM1:00 = 1300)。
usk:nextDateRepeat, menti
oned previously.)
gl-bus:enteredByModified この入力を最後に修正したユーザの(User_Listingの)User_ID。
gl-usk:lastDateRepeat
入力が最後に変更された日付。
(This is included in the 入力が最後に変更された時間。ISO
ISO 8601 representation o 8601表記の24時間制の時刻(HHMM)
f gl(例: PM1:00 = 1300)。
usk:lastDateRepeat, menti
oned previously.)フ ィフィールド名ー ル
ド 番
号
29 Segment01

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

TEXT

25

XBRL GLタクソノミ要素

説明

gl-cor:accountSubID withassociated gl-cor:account
SubType

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

(Note:XBRL GL tracks
hierarchy ID, hierarchy description, and hierarchy
type, so it can track cod
e NA, description N. America, and type global area
using

30

Segment02

2

TEXT

25

gl-cor:accountSubID, glco
r:accountSubDescription,and glcor:accountSubType,
respectively.)
上記参照

31

Segment03

2

TEXT

25

上記参照

上記参照

32

Segment04

2

TEXT

25

上記参照

上記参照

33

Segment05

2

TEXT

25

上記参照

上記参照

上記参照

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

内容

コメント

gl-cor:entriesType

value = “other”

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

2.9 AR_Cash_Application_YYYYMMDD_YYYYMMDD

AR_Cash_Application_YYYYMMDD_YYYYMMDDファイルは、調査中の期間内に適用されたすべての入金を含む。
このファイルでは、各請求書に対する領収書の各入金に対してそれぞれ1レコードとなる。例えば、1つの入金の領収書が3つの請求書に対して記入された場合、その領収書に対しては、3つのレコードがあることになり、1レコードは、入金が適用された各請求書に対応する。
フ ィ
フィールド名レベ フラットファイルデ
XBRL GLタクソノミ要素
説明
ー ル
ル
ータ
ド 番
データ型
長さ
号
1
AR_Application_ID
1
TEXT
100
gl-cor:documentReference 各取引に一意の識別子。このIDは、(例えば、文書番号、文書種
別、および年)は、各取引を一意に識別するためのフィールドを連結することによって作成される必要がある。
2
AR_Application_Date
1
DATE
gl-cor:documentDate
入金取引の日付。取引が入力された日とは関係がない。

3

AR_Application_Fiscal_Year

1

TEXT

4

gl-bus:fiscalYearEnd

4

AR_Application_Period

1

TEXT

10

gl-bus:postingCode

5

Customer_Account_ID

1

TEXT

100

6

Receipt_ID

1

TEXT

100

AR_Application_Dateが記帳された会計期間。
YYYYは区切りに使用される。XBR
L GLタクソノミフレームワークのための会計期末CCYY-MM-DD(ISO 8601)。
AR_Application_Dateが記帳された会計期間。

例には、週単位の期間としてW1–
W53、月単位の期間としてM1–M1
2、四半期単位の期間としてQ1–Q4を含む。
gl-cor:identifierCode wit 支払が予想されている顧客の識
h glcor:identifierType = 別子か、買掛計上に対する支払を行う顧客の識別子。Customer_“customer”
Master_Listing_YYYYMMDDファイル内のCustomer_Account_IDと一致しなければならない。
gl-taf:originatingDocumen Cash_Received_YYYYMMDD_YYYYMM
tNumber with glDDファイルの各取引に一意の識
taf:originatingDocumentTy 別子。一部またはすべての入金
pe = “check”*
額は顧客の買掛債務に適用される。

フ ィフィールド名ー ル
ド 番
号
7Invoice_ID

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

TEXT

100

XBRL GLタクソノミ要素

説明

gl-taf:originatingDocumen
tNumber with gltaf:originatingDocumentTy
pe =“invoice”*

各請求書に一意の識別子。このIDは、(例えば、文書番号、文
書種別、および年)は、各取引を一意に識別するためのフィールドを連結することによって作成される必要がある。請求書データを含む次のすべてのテーブ
ルと同じIDが使用されていなけ
ればならない(Invoices_Generated_YYYYMMDD_YYYYMMDD、Open_Accounts_Recei
vable_YYYYMMDD、AR_Cash_Application_YYYYMMDD_YYYYMMDD、およびAR_Adjustments_YYYYMMDD_YYYYMMDD)。
入金が顧客レベルのみ(請求書レベルではない)の場合は、空白のままとする。

フ ィフィールド名ー ルド 番
号
8Business_Unit_Codeレベ フラットファイルデ
ル
ータ
データ型
長さ
1

TEXT

50

100

9

Entered_By

1

TEXT

10

Entered_Date

2

DATE

11

Entered_Time

2

TIME

XBRL GLタクソノミ要素

説明

gl-organizationIdentifier 財務諸表が監査対象となるレベルで事業単位、地域、支店などを識別するために利用される。
Business_Unit_Listingファイル
内のBusiness_Unit_Codeと一致しなければならない。
gl-cor:identifierCode wit 記録を残した人の(User_Listingh glcor:identifierCategor ファイル内の)User_ID。
y = “systemUser”
gl-cor:enteredDate
この取引がシステムに入力された日付。これは、時に作成日と呼ばれる。可能な場合、これは、(ユーザが入力した日付ではなく)システムで生成された日付にする必要がある。この日付は、必ずしも、CheckWire_Da
teや実際の取引の日付に対応していない。
(This is included in the この取引をシステムに入力した
ISO 8601 representation o 時間。ISO 8601表記の24時間制
f glcor:enteredDate, ment の時刻(HHMM)(例: PM1:00 = 130
ioned previously)
0)。

12

Approved_By

2

TEXT

13

Approved_Date

2

DATE

14

Approved_Time

2

TIME

15

Last_Modified_By

2

TEXT

16

Last_Modified_Date

2

DATE

17

Last_Modified_Time

2

TIME

18

AR_Application_Amount

フ ィ
ー ル

フィールド名100

100

gl-cor:entryResponsiblePe 顧客マスタの追加や変更の承認
rson
者の(User_Listingファイルの)U
ser_ID。
gl-usk:nextDateRepeat
入力が承認された日付。
(This is included in the 入力が承認された時間。ISO 860
ISO 8601 representation o 1表記の24時間制の時刻(HHMM)
f gl(例: PM1:00 = 1300)。
usk:nextDateRepeat, menti
oned previously)
gl-bus:enteredByModified この入力を最後に修正したユー
ザの(User_Listingの)User_ID。
gl-usk:lastDateRepeat
入力が最後に変更された日付。

(This is included in the 入力が最後に変更された時間。
ISO 8601 representation o ISO 8601表記の24時間制の時刻
f gl(HHMM)(例: PM1:00 = 1300)。
usk:lastDateRepeat, menti
oned previously)
1
NUMERIC
gl-cor:amount
機能通貨またはグループ通貨で記録された取引金額。すべて取引が単一通貨に記録されているため、多通貨換算を実行する必要はない。
レベ フラットファイルデ
XBRL GLタクソノミ要素
説明
ル
ータ

ド 番
号
19 Amount_Currency

データ型

長さ

1

TEXT

3

20

AR_Application_Amount_Reporting

1

NUMERIC

21

Amount_Reporting_Currency

1

TEXT

22

AR_Application_Amount_Local

1

NUMERIC

23

Amount_Local_Currency

1

TEXT

3

24

GL_Line_Debit_Account_Number

2

TEXT

100

3

gl-muc:amountCurrency

売掛債権金額に関連する機能通貨やグループ通貨。ISO 4217コ
ーディングを参照。
gl-muc:amountTriangulatio 報告通貨で記録された取引金
nAmount
額。
gl非連結報告のための金額に関連
muc:amountTriangulationCu する報告通貨。
ISO 4217コーディングを参照。
rrencygl-muc:amountOriginalAmou 現地通貨での取引金額。
nt
gl-muc:amountOriginalCurr 現地国の報告で要求される通ency
貨。ISO 4217コーディングを参照。
gl-cor:accountMainID with 取引において借方に記帳されたG
glcor:accountPurposeDescr L勘定科目の番号。
iption = “debit-value”
in a second account struc
ture

フ ィ
フィールド名ー ル
ド 番
号
25 GL_Line_Credit_Account_Number

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

TEXT

100

XBRL GLタクソノミ要素

説明

gl-cor:mainAccountID with 取引において貸方に記帳されたG
glcor:mainAccountPurposeD L勘定科目の番号。
escriptio gl-cor:accountM
ainID with glcor:accountP
urposeDescription n = “credit-value" in a second
account structure

26

Segment01

2

TEXT

25

gl-cor:accountSubID with
プロフィット・センター、部
associated gl-cor:account 門、ファンド、プログラム、支SubType
店、プロジェクトなどのために使用することができる準備され(Note:XBRL GL tracks
たセグメントフィールド。
hierarchy ID, hierarchy description, and hierarchy
type, so it can track cod
e NA, description N. America, and type global area
using

27

Segment02

2

TEXT

25

gl-cor:accountSubID, glco
r:accountSubDescription,and glcor:accountSubType,
respectively.)
上記参照

28

Segment03

2

TEXT

25

上記参照

上記参照

29

Segment04

2

TEXT

25

上記参照

上記参照

30

Segment05

2

TEXT

25

上記参照

上記参照

上記参照

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

value = “other”[entriesType]は必須フィールドである。[other]は列挙型の値である。
gl-cor: entriesComment value = “ads:[entriesComment]は情報収集に共通しているものを説明する説明フィールドであAR_Cash_Application_YYYYMMDD_YYYYMMDD”
り、
この表現に関連して収集するタイプの監
査データ標準の名前空間と修飾子を導入する。
*
入金は、多くの場合複数の請求書に反映され、請求書は複数の出荷および注文に対して発行されるため、各支払に割り当てられる明細行の関係は独立したentryDetailとして表示され、割り当てられた各明細行と根本的な原始証憑は区別される。

2.10 AR_Adjustments_YYYYMMDD_YYYYMMDD

AR_Adjustments_YYYYMMDD_YYYYMMDDファイルには、請求書に記載され期間中の請求書の残高に影響を与えるすべての調整(例えば、帳消し、貸方メモ、およびその他の調整など)を含む。ここには、入金額の適用は含まない(それはAR_Cash_
Application_YYYYMMDDテーブルに含まれる)。
このファイルでは、各請求書の各調整に対してそれぞれ1レコードとなる。例えば、1つの調整取引が3つの請求書に影響を与える場合、その3つの調整に対する3つのレコードが存在し、1レコードはその調整に影響を受ける各請求書に対応する。
フ ィフィールド名レ ベ フラットファイルデ
XBRL GLタクソノミ要素
説明
ー ル
ル
ータ
ド 番
データ型
長さ
号
1
Adjustment_ID
1
TEXT
100
gl-cor:documentReference
記録された調整に一意の識別子。このIDは、(例えば、文書
番号、文書種別、および年)は、各取引を一意に識別するためのフィールドを連結することによって作成される必要がある。

2

Adjustment_Type

1

TEXT

25

3

Adjustment_Document_Number

1

TEXT

100

gl-cor:documentType using pr 取引の借方または貸方金額が顧ovided enumerations or
客によって消滅または借方となった方法のコード値/指標(例えgl-cor:documentType = {othe ば、貸方メモ、借方メモ、手数r} and and gl-bus:paymentMe 料、その他の調整など)。「1.9
thod with codes from
AR_Adjustment_Type_Listing_Y
AR_Adjustment_Type_Listing_Y YYYMMDD」を参照。
YYYM
MDD
gl-cor:documentNumber
内部で作成された調整文書(例
えば、貸方メモ)の識別番号。

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

5Adjustment_Date

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

TEXT

1

DATE

100

XBRL GLタクソノミ要素

説明

gl-taf:originatingDocumentNu 各請求書に一意の識別子。この
mer with gl-taf:originatingD IDは、(例えば、文書番号、文
書種別、および年)は、各取引
ocumentType = “invoice”
を一意に識別するためのフィールドを連結することによって作成される必要がある。請求書データを含む次のすべてのテーブ
ルと同じIDが使用されていなけ
ればならない(Invoices_Generated_YYYYMMDD_YYYYMMDD、Open_Accounts_Receivable_YYYYMMDD、AR_Cash_Ap
plication_YYYYMMDD_YYYYMMD
D、およびAR_Adjustments_YYYY
MMDD_YYYYMMDD)。
調整が顧客レベルのみ(請求書レベルではない)の場合は、空白のままとする。
gl-cor:postingDate
取引の日付。取引が入力された日付とは関係がない。

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

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

XBRL GLタクソノミ要素

1

TEXT

4

gl-bus:fiscalYearEnd

1

TEXT

10

gl-bus:postingCode

1

TEXT

50

説明

Adjustment_Dateが記帳された会計期間。
YYYYは区切りに使用される。XB
RL GLタクソノミフレームワー
クのための会計期末CCYY-MM-DD(ISO 8601)。
Adjustment_Dateが記帳された会計期間。

例には、週単位の期間としてW1–W53、月単位の期間としてM1–M
12、四半期単位の期間としてQ1–Q4を含む。
gl-bus:organizationIdentifie 財務諸表が監査対象となるレベルで事業単位、地域、支店など
rを識別するために利用される。
Business_Unit_Listingファイ
ル内のBusiness_Unit_Codeと一致しなければならない。

9

Customer_Account_ID

1

TEXT

100

10

Entered_By

1

TEXT

100

11

Entered_Date

1

DATE

12

Entered_Time

2

TIME

13

Approved_By

2

TEXT

14

Approved_Date

2

DATE

100

gl-cor:identifierCode with g 支払が予想されている顧客の識
lcor:identifierType = “cust 別子か、買掛計上に対する支払omer”を行う顧客の識別子。Customer_Master_Listing_YYYYMMDDファ
イル内のCustomer_Account_IDと一致しなければならない。
gl-cor:identifierCode with g 記録を残した人の(User_Listin
lcor:identifierCategory =gファイル内の)User_ID。
“systemUser”
gl-cor:enteredDate
取引がシステムに入力された日付。これは、時に作成日と呼ばれる。可能な場合、これは、(ユーザが入力した日付ではなく)システムで生成された日付にする必要がある。この日付は、必ずしも、実際の取引の日付に対応していない。
(This is included in the ISO この取引をシステムに入力した8601 representation of gl-co 時間。ISO 8601表記の24時間制
r:enteredDate, mentioned pre の時刻(HHMM)(例: PM1:00 = 13
viously.)00)。
gl-cor:entryResponsiblePerso 顧客マスタの追加や変更の承認
n
者の(User_Listingファイルの)
User_ID。
gl-usk:nextDateRepeat
入力が承認された日付。

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

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

TIME

16

Last_Modified_By

2

TEXT

17

Last_Modified_Date

2

DATE

18

Last_Modified_Time

2

TIME

19

Adjustment_Amount1

NUMERIC100XBRL GLタクソノミ要素

説明(This is included in the ISO 入力が承認された時間。ISO 86
8601 representation of gl01表記の24時間制の時刻(HHMM)
usk:nextDateRepeat, mentione (例: PM1:00 = 1300)。
d previously.)
gl-bus:enteredByModified
この入力を最後に修正したユー
ザの(User_Listingの)User_I
D。
gl-usk:lastDateRepeat
入力が最後に変更された日付。

(This is included in the ISO 入力が最後に変更された時間。
8601 representation of gl-la ISO 8601表記の24時間制の時刻
stDateRepeat, mentioned prev (HHMM)(例: PM1:00 = 1300)。
iously.)
注記:詳細(明細項目)データが提供される場合、次のフィールドは省略される場合がある。
gl-cor:amount

機能通貨またはグループ通貨で記録された取引金額。すべて取引が単一通貨に記録されているため、多通貨換算を実行する必
要はない。

フ ィ
フィールド名ー ル
ド 番
号
20 Adjustment_Amount_Currency

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

TEXT

3

21

Adjustment_Amount_Reporting

1

NUMERIC

22

Adjustment_Reporting_Currency

1

TEXT

23

Adjustment_Amount_Local

1

NUMERIC

24

Adjustment_Local_Currency

1

TEXT

3

25

Tax1_Type

1

TEXT

25

3

XBRL GLタクソノミ要素

説明

gl-muc:amountCurrency

調整金額に関連する機能通貨やグループ通貨。ISO 4217コーデ
ィングを参照。
gl-muc:amountTriangulationAm 報告通貨で記録された取引金
ount
額。
gl-muc:amountTriangulationCu 非連結報告のための調整の報告
rrency
金額に関連する報告通貨。ISO
4217コーディングを参照。
gl-muc:amountOriginalAmount

現地通貨での取引金額。

gl-muc:amountOriginalCurrenc 現地国の報告で要求される通y貨。ISO 4217コーディングを参照。
gl-cor:taxCode (Note that XB 税1タイプのコード(例: 売上
RL GL permits an unlimited n 税、付加価値税)。
umber of tax codes and amoun
このフィールドは、Tax_Table_
ts with the glcor:taxes stru
YYYYMMDDのRegulator_Codeフィ
cture.)
ールドと一致する必要がある。

26

Tax2_Type

1

TEXT

25

同上

税2タイプのコード(例: 売上税、付加価値税)。
このフィールドは、Tax_Table_
YYYYMMDDのRegulator_Codeフィ
ールドと一致する必要がある。

27

Tax3_Type

1

TEXT

25

同上

税3タイプのコード(例: 売上税、付加価値税)。
このフィールドは、Tax_Table_
YYYYMMDDのRegulator_Codeフィ
ールドと一致する必要がある。

28

Tax1_Type_Description

1

TEXT

100

29

Tax2_Type_Description

1

TEXT

100

gl-cor:taxDescription (Note 税1タイプの説明(例: 税を支払
that XBRL GL formalizes the う税務当局や、税を特定するた
tax authority with glcor:tax めのその他の情報など)。
Authority and provides otherstandard fields as well.)
同上
税2タイプの説明(例: 税を支払
う税務当局や、税を特定するためのその他の情報など)。

フ ィ
フィールド名ー ル
ド 番
号
30 Tax3_Type_Description

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

TEXT

100

31

Tax1_Local

2

NUMERIC32

Tax2_Local

2

NUMERIC33

Tax3_Local

2

NUMERIC34

GL_Debit_Account_Number

2

TEXT

100

35

GL_Credit_Account_Number

2

TEXT

100

XBRL GLタクソノミ要素

同上説明

税3タイプの説明(例: 税を支払
う税務当局や、税を特定するためのその他の情報など)。
gl-cor:taxAmount
税1タイプの金額は、取引に含まれている。現地通貨で記録される。
同上
税2タイプの金額は、取引に含まれている。現地通貨で記録される。
同上
税3タイプの金額は、取引に含まれている。現地通貨で記録される。
gl-cor:accountMainID with gl 取引において借方に記帳された
cor:accountPurposeDescriptio GL勘定科目の番号。
n = “debit-value” in a sec
ond account structure
gl-cor:accountMainID with gl 取引において貸方に記帳された
cor:accountPurposeDescriptio GL勘定科目の番号。
n = “credit-value” in a second account structureフ ィフィールド名ー ル
ド 番
号
36 GL_Tax1_Debit_Account_Number

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

TEXT

100

XBRL GLタクソノミ要素

説明

XBRL GL does not have fields explicitly associating GL
accounts to tax, although it does permit specificationof accounts as tax accounts(glcor:accountPurposeCode); it
associates tax detail in the gl-cor:taxes structure wi
th specific accounts by inc
luding them within the same
glcor:entryDetail if the gl-cor:amount is the same, orwithin the same glcor:entry
Header if amounts differ.Aswith the previously mention
ed GL lines, the account nu
mbers would be mapped to gl-cor:mainAccountID and be mapped to gl-cor:accountMain
ID.

税1の取引において借方に記帳されたGL勘定科目の番号。

37

GL_Tax1_Credit_Account_Number

1

TEXT

100

同上

税1の取引において貸方に記帳されたGL勘定科目の番号。

38

GL_Tax2_Debit_Account_Number

1

TEXT

100

同上

税2の取引において借方に記帳されたGL勘定科目の番号。

39

GL_Tax2_Credit_Account_Number

1

TEXT

100

同上

税2の取引において貸方に記帳されたGL勘定科目の番号。

40

GL_Tax3_Debit_Account_Number

1

TEXT

100

同上

税3の取引において借方に記帳されたGL勘定科目の番号。

フ ィ
フィールド名ー ル
ド 番
号
41 GL_Tax3_Credit_Account_Number

42

Segment01

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

XBRL GLタクソノミ要素

説明

1

TEXT

100

同上

税3の取引において貸方に記帳されたGL勘定科目の番号。

2

TEXT

25

gl-cor:accountSubID with

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

associated gl-cor:account
SubType(Note:XBRL GL tracks
hierarchy ID, hierarchy description, and hierarchy type, so it can track code NA,
description N. America, andtype global area using

43

Segment02

2

TEXT

25

gl-cor:accountSubID, glcor:accountSubDescription, and gl
cor:accountSubType, respecti
vely.)
上記参照
上記参照

44

Segment03

2

TEXT

25

上記参照

上記参照

45

Segment04

2

TEXT

25

上記参照

上記参照

46

Segment05

2

TEXT

25

上記参照

上記参照

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

value = “other”[entriesType]は必須フィールドである。
[other]は列挙型の値である。
gl-cor: entriesComment
value = “ads:[entriesComment]は情報収集に共通しているものを説明する説明フィールドであAR_Adjustments_YYYYMMDD_YYYYMMDD”
り、
この表現に関連して収集するタイプの監
査データ標準の名前空間と修飾子を導入する。
*
調整は、複数の根本的な原始証憑を表す場合があり、各調整の関連は独立したentryDetailとして表示され、調整と根本的な原始証憑は区別される。

2.11 AR_Adjustment_Lines_YYYYMMDD_YYYYMMDD

AR_Adjustment_Lines_YYYYMMDD_YYYYMMDDファイルには、AR_Adjustments_YYYYMMDD_YYYYMMDD.ファイル内にある請求書の詳細な明細項目が含まれる。このファイルの使用は任意であるが、管理しきれないデータ容量ではない限り、使用することが推奨される。
このファイルでは、各調整に影響を受ける請求書の各明細項目に対してそれぞれ1レコードとなる。
フ ィ
フィールド名レベ フラットファイルXBRL GLタクソノミ要素
説明
ー ル
ル
データ
ド 番
データ型
長さ
号
1
Adjustment_ID
1
TEXT
100
gl-cor:documentReference
記録された調整に一意の識別子。このIDは、(例えば、文書
番号、文書種別、および年)は、各取引を一意に識別するためのフィールドを連結する
ことによって作成される必要
がある。

2

Invoice_ID

1

TEXT

100

gl-taf:originatingDocument
Numer with gl-taf:originat
ingDocumentType = “invoice”

各請求書に一意の識別子。このIDは、(例えば、文書番号、
文書種別、および年)は、各取引を一意に識別するためのフィールドを連結することによって作成される必要がある。
請求書データを含む次のすべてのテーブルと同じIDが使用されていなければならない(Invoices_Generated_YYYYMMDD_YYYYMMDD、
Open_Accounts_Receivable_YYYYMMDD、
AR_Cash_Application_YYYYMMDD_YYYYMMDD、および AR_Adjustm
ents_YYYYMMDD_YYYYMMDD)。
入金が顧客レベルのみ(請求書レベルではない)の場合は、空白のままとする。

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

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

4Adjustment_Line_Amount1

NUMERIC

5

Adjustment_Line_Amount_Currency

1

TEXT

6

Adjustment_Line_Amount_Reporting

1

NUMERIC

7

Adjustment_Line_Reporting_Curren
cy

1

TEXT

8

Adjustment_Line_Amount_Local

1

NUMERIC10XBRL GLタクソノミ要素

gl-cor:lineNumber*gl-cor:amount

3

3

説明

調整が適用される元の請求書の明細項目番号。
入金が顧客レベルのみ(請求書レベルではない)の場合は、空白のままとする。
機能通貨またはグループ通貨で記録された取引金額。すべて取引が単一通貨に記録されているため、多通貨換算を実行する必要はない。

gl-muc:amountCurrency

調整金額に関連する機能通貨やグループ通貨。ISO 4217コーデ
ィングを参照。
gl-muc:amountTriangulation 報告通貨で記録された取引金
Amount額。
gl非連結報告のための調整の報告
muc:amountTriangulationCur 金額に関連する報告通貨。ISO
rency
4217コーディングを参照。
gl-muc:amountOriginalAmoun 現地通貨での取引金額。
t9

Adjustment_Line_Local_Currency

1

TEXT

3

gl-muc:amountOriginalCurre 現地国の報告で要求される通ncy
貨。ISO 4217コーディングを参照。

フ ィフィールド名ー ル
ド 番
号
10 Tax1_Type11

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

1

TEXT

TEXT

25

25

XBRL GLタクソノミ要素

説明

gl-cor:taxCode (Note thatXBRL GL permits an unlimit
ed number of tax codes andamounts with the glcor:tax
es structure.)

税1タイプのコード(例: 売上税、付加価値税)。

同上

税2タイプのコード(例: 売上税、付加価値税)。

このフィールドは、Tax_Table_
YYYYMMDDのRegulator_Codeフィ
ールドと一致する必要がある。

このフィールドは、Tax_Table_
YYYYMMDDのRegulator_Codeフィ
ールドと一致する必要がある。

12

Tax3_Type

1

TEXT

25

同上

税3タイプのコード(例: 売上税、付加価値税)。
このフィールドは、Tax_Table_
YYYYMMDDのRegulator_Codeフィ
ールドと一致する必要がある。

13

Tax1_Type_Description

1

TEXT

100

14

Tax2_Type_Description

1

TEXT

100

gl-cor:taxDescription (Note that XBRL GL formalizes
the tax authority with glcor:taxAuthority and provi
des other standard fields
as well.)
同上

15

Tax3_Type_Description

1

TEXT

100

同上

16

Tax1_Local

2

NUMERIC

gl-cor:taxAmount

税1タイプの説明(例: 税を支払
う税務当局や、税を特定するためのその他の情報など)。

税2タイプの説明(例: 税を支払
う税務当局や、税を特定するためのその他の情報など)。
税3タイプの説明(例: 税を支払
う税務当局や、税を特定するためのその他の情報など)。
税1タイプの金額は、取引に含まれている。現地通貨で記録さ
れる。

フ ィ
フィールド名ー ル
ド 番
号
17 Tax2_Local

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

NUMERICXBRL GLタクソノミ要素

同上18

Tax3_Local

2

NUMERIC19

GL_Debit_Account_Number

2

TEXT

100

20

GL_Credit_Account_Number

2

TEXT

100

説明

税2タイプの金額は、取引に含まれている。現地通貨で記録される。
同上
税3タイプの金額は、取引に含まれている。現地通貨で記録される。
gl-cor:accountMainID with 取引において借方に記帳された
glcor:accountPurposeDescri GL勘定科目の番号。
ption mainAccountPurposeDe
scription = “debit-value” in a second account st
ructuregl-cor:accountMainID with 取引において貸方に記帳されglcor:accountPurposeDescri たGL勘定科目の番号。
ption = “credit-value” in a second account structu
reフ ィ
フィールド名ー ル
ド 番
号
21 GL_Tax1_Debit_Account_Number

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

TEXT

100

XBRL GLタクソノミ要素

説明

XBRL GL does not have fiel 税1の取引において借方に記帳
ds explicitly associating されたGL勘定科目の番号。
GL accounts to tax, althou
gh it does permit specification of accounts as tax a
ccounts (glcor:accountPurposeCode);
it associates tax detailin the glcor:taxes struct
ure with specific accounts by including them within the same gl-cor:entryDetail if the glcor:amountis the same, or within the same gl-cor:entryHeader
if amounts differ.As withthe previous GL lines, the account numbers would be mapped to glcor:account
MainID.

22

GL_Tax1_Credit_Account_Number

1

TEXT

100

同上

税1の取引において貸方に記帳されたGL勘定科目の番号。

23

GL_Tax2_Debit_Account_Number

1

TEXT

100

同上

税2の取引において借方に記帳されたGL勘定科目の番号。

24

GL_Tax2_Credit_Account_Number

1

TEXT

100

同上

税2の取引において貸方に記帳されたGL勘定科目の番号。

25

GL_Tax3_Debit_Account_Number

1

TEXT

100

同上

税3の取引において借方に記帳されたGL勘定科目の番号。

26

GL_Tax3_Credit_Account_Number

1

TEXT

100

同上

税3の取引において貸方に記帳されたGL勘定科目の番号。

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

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

TEXT

25

XBRL GLタクソノミ要素

説明

gl-cor:accountSubID with

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

associated gl-cor:account
SubType(Note:XBRL GL tracks
hierarchy ID, hierarchy description, and hierarchy type, so it can track codeNA, description N. America, and type global area us
ing

29

Segment02

2

TEXT

25

gl-cor:accountSubID, glco
r:accountSubDescription, a
nd glcor:accountSubType, r
espectively.)
上記参照
上記参照

30

Segment03

2

TEXT

25

上記参照

上記参照

31

Segment04

2

TEXT

25

上記参照

上記参照

32

Segment05

2

TEXT

25

上記参照

上記参照

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

value = “other”[entriesType]は必須フィールドである。[other]は列挙型の値である。
gl-cor: entriesComment value = “ads:[entriesComment]は情報収集に共通しているものを説明する説明フィールドであAR_Adjustment_Lines_YYYYMMDD_YYYYMMDD”
り、
この表現に関連して収集するタイプの監
査データ標準の名前空間と修飾子を導入する。
*
調整は、複数の根本的な原始証憑を表す場合があり、各調整項目の関係は独立したentryDetailとして表示され、調整と根本的な原始証憑は区別される。

2.12 Receipt_Type_Listing_YYYYMMDD

Receipt_Type_Listing_YYYYMMDDファイルには、Receipt_Typeコードの詳細な説明が含まれる。
フ ィ
フィールド名レ ベ フラットファイルXBRL GLタクソノミ要素
説明
ー ル
ル
データ
ド 番
データ型
長さ
号
1 Receipt_Type
1
TEXT
25
gl-bus:paymentMethod
取引の借方または貸方金額が顧客によって消滅または借方となった方法のコード値/指標。
2

Receipt_Type_Description

1

TEXT

100

gl-cor:documentTypeDescri 取引のタイプを示すコード値の説明
ption(小切手、電信送金、現金など)。

XBRL GLへの追加コメントXBRL GLは、gl-cor:documentTypeに計数値を使用して、異なるタイプの取引文書と関連する目的を区別する。Receipt_
Type_Listing_YYYYMMDDとAR_Adjustment_Type_Listingの記録における違いは、gl-cor:documentTypeを含めることによって、Receipt_Type_Listing_YYYYMMDDの場合は領収の種別(例えば、小切手、その他の支払)、AR_Adjustment_Type_Li
sting_YYYYMMDDの場合は調整の種別(例えば、借方メモ、貸方メモ、手数料、手動調整など)を表すことである。次に、受注・入金で最も幅広く使用されるものを列挙する。
小切手(check)
借方メモ(debit-memo)
貸方メモ(credit-memo)
手数料(finance-charge)
請求書(invoice)
注文顧客(order-customer)
その他の支払(payment-other)
催促状(reminder)
手形(tegata)
出荷(shipment)
領収書(receipt)
手動調整(manual-adjustment)
その他(other)領収種別リストのうちで追加的に必須若しくは望ましいフィールドは次のとおりである。

要素

内容

gl-cor:entriesType

value = “other”

gl-cor: entriesComment

value = “ads:Receipt_Type_Listing_YYYY
MMDD”

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

2.13 AR_Adjustment_Type_Listing_YYYYMMDD

AR_Adjustment_Type_Listing_YYYYMMDDファイルには、AR_Adjustment_Typeコードの詳細な説明が含まれる。
フ ィ
フィールド名レ ベ フラットファイルXBRL GLタクソノミ要素
説明
ー ル
ル
データ
ド 番
データ型
長さ
号
1
AR_Adjustment_Type
1
TEXT
25
gl-bus:paymentMethod
調整の種別のコード値/指標。
2

AR_Adjustment_Type_Descriptio
n

1

TEXT

100

gl-cor:documentTypeDescri 取引のタイプを示すコード値の説明
ption(例えば、貸方メモ、借方メモ、手数料、その他の調整など)。

XBRL GLへの追加コメントXBRL GLは、gl-cor:documentTypeに計数値を使用して、異なるタイプの取引文書と関連する目的を区別する。Receipt_
Type_Listing_YYYYMMDDとAR_Adjustment_Type_Listingの記録における違いは、gl-cor:documentTypeを含めることによって、Receipt_Type_Listing_YYYYMMDDの場合は領収書の種別(例えば、小切手、その他の支払)、AR_Adjustment_Type_
Listing_YYYYMMDDの場合は調整の種別(例えば、借方メモ、貸方メモ、手数料、手動調整など)を表すことである。次は、受注・入金で最も幅広く使用される一覧である。
小切手(check)
借方メモ(debit-memo)
貸方メモ(credit-memo)
手数料(finance-charge)
請求書(invoice)
注文顧客(order-customer)
その他の支払(payment-other)
催促状(reminder)
手形(tegata)
出荷(shipment)
領収書(receipt)
手動調整(manual-adjustment)
その他(other)

売掛債権調整種別リストのうちで追加的に必須若しくは望ましいフィールドは次のとおりである。

要素

内容

gl-cor:entriesType

value = “other”

gl-cor: entriesComment

value = “ads:
AR_Adjustment_Type_Listing_YYYYMMDD”

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

2.14 Customer_Master_YYYYMMDD

Customer_Master_YYYYMMDDファイルには、調査中の期間に生じる変更に対応するために、1回以上データが生成されることが求められる。ファイルが生成される日付はファイル名の一部として記録される。
フ ィフィールド名レベ フラットファイルXBRL GLタクソノミ要素
説明
ー ル
ル
データ
ド 番
データ型
長さ
号
1
Customer_Account_ID
1
TEXT
100
gl-cor:identifierCode for 支払が予想されている顧客の識別internal # with gl-cor:id 子か、買掛計上に対する支払を行
entifierType = “custome う顧客の識別子。
r”
2
Customer_Account_Name
1
TEXT
100
gl-cor:identifierDescript 顧客の名前。
ion
3
Customer_Group
2
TEXT
100
gl-cor:identifierCategory 組織によって顧客をグループに区分する場合、この顧客が区分されるグループ。
4
Customer_Physical_Street_Addres 1
TEXT
100
gl-bus:identifierStreet
顧客の住所の行1。
s1(*) with glbus:identifier
AddressPurpose = “physical”
5Customer_Physical_Street_Addres 1
TEXT
100
gl-bus:identifierAddressS 顧客の住所の行2。
s2
treet2*

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

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

XBRL GLタクソノミ要素

1

TEXT

100

gl-bus:identifierCity*

説明

顧客が位置する都市。

7

Customer_Physical_State_Provinc
e

1

TEXT

6

gl-bus:identifierStateOrP 顧客が位置する国や都道府県。ISOrovince*
3166-2を推奨。

8

Customer_Physical_ZipPostalCode

1

TEXT

20

9

Customer_Physical_Country

1

TEXT

3

10

Customer_TIN

1

TEXT

100

11

Customer_Billing_Address1

1

TEXT

100

12

Customer_Billing_Address2

1

TEXT

100

13

Customer_Billing_City

1

TEXT

100

gl-bus:identifierZipOrPos 顧客が位置する都市の郵便番号。
talCode*gl-bus:identifierCountry* 顧客が位置する国別コード。ISO
316631661アルファ2またはISO 31
66-1アルファの3形式(XXまたはXX
X)を推奨。
gl-cor:identifierAuthorit 顧客の納税者番号。
yCode for tax #gl-bus:identifierStreet
顧客の請求先住所1。
(**) with glbus:identifie
rAddressPurpose =“billing”
gl-bus:identifierAddressS 顧客の請求先住所2。
treet2**gl-bus:identifierCity**
顧客の請求先の都市。

フ ィフィールド名レベ フラットファイルXBRL GLタクソノミ要素
説明
ー ル
ル
データ
ド 番
データ型 長さ
号
14 Customer_Billing_State_Province 1
TEXT
6gl-bus:identifierStateOrP 顧客の請求先の国。ISO 3166-2を
rovince**推奨。
15 Customer_Billing_ZipPostalCode
1
TEXT
20
gl-bus:identifierZipOrPos 顧客の請求先の都市の郵便番号。
talCode**16 Customer_Billing_Country
1
TEXT
3
gl-bus:identifierCountry* 顧客の請求先の国番号。ISO 3166*
1アルファ2またはISO 3166-1アルファの3形式(XXまたはXXX)を推奨。
17 Active_Date
2
DATE
XBRL GL uses gl顧客がアクティブとなった日付。
cor:identifierActive to n
ote that the customer iscurrently active or inact
ive. gl-cor:dateAcknowledged
18

Inactive_Date

2

DATE

19

Transaction_Credit_Limit

2

NUMERIC

20

Overall_Credit_Limit

2

NUMERIC

gl-cor:confirmedDate

顧客が非アクティブとなった日付。
gl-muc:amountRestatedAmou 顧客のために確立された請求書与nt
信限度。
gl-cor:amount
顧客の総残高の与信限度。

21

Terms_Discount_Percentage

2

NUMERIC

22

Terms_Discount_Days

2

NUMERIC

23

Terms_Due_Days

2

NUMERIC

24

Entered_By

1

TEXT

gl-cor:terms

100

顧客が請求書の一定の日数前に支払う場合の割引率。フラットファ
イルでは、小数点以下１桁として表現される(例えば、10％が10.0として表現される)。
拡張事業報告言語のXBRL GLタクソ
ノミフレームワークにおいては、3つのフィールドTerms_Discount_Pe
rcentage、Terms_Discount_DaysおよびTerms_Due_Daysの3つのフィー
ルドは、「xx.x％ dd 最終支払期
日 dd」の形式で入力されることになる。例えば実質支払期間が30日で、10日以内に支払うと2％割引となる場合では「2％ 10 最終支払期
日 30」で表現される。
フィールド番号8の説明を参 請求書日付からの日数は、顧客が照。
割引を利用するために有利である。これは小数点以下がない桁数(例えば、nnn)として数字として表現される。
See description for fiel 請求書に対する支払遅延となる前
d # 8; explicit in gl-co の、支払義務を果たすことが可能
r:maturityDate
な日数。
gl-cor:enteredBy
記録を残した人の(User_Listingファイル内の)User_ID。

フ ィフィールド名ー ル
ド 番
号
25 Entered_Date

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

DATE

26

Entered_Time

2

TIME

27

Approved_By

2

TEXT

28

Approved_Date

2

DATE

29

Approved_Time

2

TIME

XBRL GLタクソノミ要素

gl-cor:enteredDate

100

説明

注文がシステムに入力された日付。これは、時に作成日と呼ばれる。可能な場合、これは、(ユーザが入力した日付ではなく)シス
テムで生成された日付にする必要がある。
(This is included in the この取引をシステムに入力した時
ISO 8601 representation o 間。ISO 8601表記の24時間制の時
f glcor:enteredDate, ment 刻(HHMM)(例: PM1:00 = 1300)。
ioned previously.)
gl-cor:entryResponsiblePe 顧客マスタの追加や変更の承認者
rsonの(User_Listingファイルの)User_ID。
gl-cor:confirmedDate
顧客マスタの追加や変更が承認された日付。
(This is included in the 入力が承認された時間。ISO 8601
ISO 8601 representation o 表記の24時間制の時刻(HHMM)
f glusk:confirmedDate, me (例: PM1:00 = 1300)。
ntioned previously.)フ ィフィールド名ー ルド 番
号
30 Last_Modified_By

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

TEXT

31

Last_Modified_Date

2

DATE

32

Last_Modified_Time

2

TIME

33

PrimaryContact_Name

2

TEXT

34

PrimaryContact_Phone

2

NUMERIC

35

PrimaryContact_Email

2

TEXT

100

100

100

XBRL GLタクソノミ要素

gl-bus:enteredByModified

説明

この入力を最後に修正したユーザの(User_Listingの)User_ID。
gl-usk:lastDateRepeat
顧客記録が最後に変更された日付。
(This is included in the 入力が最後に変更された時間。ISO
ISO 8601 representation o 8601表記の24時間制の時刻(HHMM)
f gl(例: PM1:00 = 1300)。
usk:lastDateRepeat, menti
oned previously.)
gl顧客の一次連絡先の名前。
cor:identifierContactAtte
ntionLine
gl顧客の一次連絡先の電話番号。
cor:identifierContactPhon
eNumber
gl顧客の一次連絡先の電子メールア
cor:identifierContactEmai ドレス。
lAddressXBRL GLへの追加コメント
顧客リストのうちで追加的に必須若しくは望ましいフィールドは次のとおりである。
要素

内容

gl-cor:entriesType

value = “account”

gl-cor: entriesComment

value = “ads:Customer_Master_Listing_YYYYMMD
D”

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

3.0 受注・入金標準データプロファイルングレポート
抽出されるデータの各セットについては、次のテストがデータプロバイダによって行なわれ、監査人によって独立して確認されるべきである。妥当性検証は、データが要求される各期間の間で行なわれるべきである。データ妥当性検証は下記を含んでいる。
テスト
日付とコントロールトータル
Required files(要求されているファイル)Date ranges(日付範囲)

説明要求されたすべてのファイルおよびデータフィールドが提供されていることを確認する。
次の日付における最小値および最大値。
•

•

•

•

•

•

•

•

Sales_Orders_YYYYMMDD_YYYYMMDD− Sales_Order_Date− Entered_Date
Shipments_Made_YYYYMMDD_YYYYMMDD− Transaction_Date− Entered_Date
Invoices_Generated_YYYYMMDD_YYYYMMDD− Invoice_Date− Invoice_Due_Date− Entered_Date
Open_Accounts_Receivable_YYYYMMDD− Invoice_Date− Invoice_Due_Date
AR_Cash_Application_YYYYMMDD_YYYYMMDD− AR_Activity_Date− Entered_Date
Cash_Received_YYYYMMDD_YYYYMMDD− Receipt_Date− Entered_Date
AR_Adjustments_YYYYMMDD_YYYYMMDD− Adjustment_Date− Entered_Date
Customer_Master_Listing_YYYYMMDD − Entered_Date

Control totals(コントロールトータル)

次の場合におけるレコード数と金額フィールドの合計。
•
•
•
•
•
•
•

Sales_Orders_YYYYMMDD_YYYYMMDD
Shipments_Made_YYYYMMDD_YYYYMMDD
Invoices_Generated_YYYYMMDD_YYYYMMDD
Open_Accounts_Receivable_YYYYMMDD
AR_Cash_Application_YYYYMMDD_YYYYMMDD
Cash_Received_YYYYMMDD_YYYYMMDD
AR_Adjustments_YYYYMMDD_YYYYMMDD

データレビュー
Missing data(欠損データ)
Invalid data(不適切なデータ)

フィールドによって表示された欠損や空白値の数。
フィールドフォーマットの要件に準拠していないフィールドのレコー
ドの数(例えば、日付や時刻フォーマットに準拠していない日付や時間、小数点以下2桁を含まない数値フィールドなど)。

4.0 受注・入金

質問事項

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

1. データの提供は、明細項目レベル(例えば、販売注文の明細項目ごと、請求書の明細項目ごと、出荷帳票の明細項目ごと)か。または、総計レベル(例えば、販売注文ごと、請求書ごと、出荷ごと)か。
2. 提供されないレベル1およびレベル2のデータフィールドはどれか。
3. 売掛債権は顧客の請求書から追跡されるのか。または、顧客に総計で追跡されるのか。
4. 一部支払はどのように処理されるか。一部支払が処理される場合、原本請求書は残りの不足額を記録した補助元帳の中に保持されるか。あるいは、一部支払が行われた時点で記録される残高とともに新しい請求書が発行されるのか。新しい請求書が作成される場合、それらはどのようにシステムで識別されるか。
5. 新しい請求書が原本請求書の一部支払により生成される場合、原本の支払日は保持されるか。
それとも、新しい支払日が新しい請求書のために生成されるか。
6. システムは、どのようにして請求書の年齢を計算するか。請求書期日あるいは支払日に基づくか。
7. どのように、関連当事者との取引は識別されるか(例えば、完全子会社あるいは部分所有子会社との取引など)。
8. 支払残高が支払われた時点での未決の明細項目テーブル内の請求書についての組織としての管理ポリシーは何か。
9. 入金のポリシーは何か。入金が適用されるのは、特定の文書のみか、日付が古い支払残高か、顧客口座か。10.顧客債権と、そうではないものをどのように区別するか。

利用者および事業者単位の管理
次の事項を考慮すること。

1. 取引承認あるいは取引変更はシステム内に取り込まれているか。
2. ファイルテーブルおよびマスタファイルテーブルにアクセスして作成・修正・変更の承認をする権限を持っているユーザは誰であるか。
3. 収益を受け取り、信用を供与するプロセスはどれであるか。
4. システムは、どのように取引番号の再使用や手動による上書きを防いでいるか。5.すべての取引の時間フィールドは単一のタイムゾーンに正規化されているか。正規化されている場合、
タイムゾーンは何か。