July 2015

Audit Data Standards

Procure to Pay
Subledger Standard
2015年7月版

AuditDataStandards.P2P.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 personal,
intraorganizational, or educational use only and are not sold or disseminated andprovided 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)
Robert Dohrer, Chair

Don Kluthe

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_YYYYMMDD—
住所および請求先住所
監査データ標準(仕入・支払編)等のInvoices_Received_YYYYMDD_YYYYMMDD:—

GL_Debit_Account_NumberおよびGL_Credit_Account_Number

最後の例では、入力行には貸方および借方の勘定科目がある。詳細ではなく概要を生成する
場合、全請求書には以下の場合を除いて貸方および借方の組が1つのみ存在する。
1. 監査人および被監査会社が、詳細行の最後に貸方および借方の勘定科目を付加する
ことと、そのフォーマットで問題ないことに同意した場合
2. パイプ区切りのフォーマットではなく、XBRL GLフォーマットが使用される場合。X
BRL GLカラムの注釈に記載される通り、XBRL GLはフラットファイルフォーマット
よりも多くの項目を許可するデータ表現方法を採用している。

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

2. 仕入・支払補助元帳標準

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

仕入・支払標準監査データは関連情報を含んでいる多数のテーブルで定義されている。図2は、

仕入・支払の標準でテーブルの関係を示すデータ・ダイアグラムを提供している。AICPAのウェブサイトにある基礎標準文書と共に仕入・支払補助元帳標準が使用されるべきであることに留意することが重要である。
図2:仕入・支払監査データ標準におけるテーブル間のデータの関係

仕入・支払標準監査データは、「詳細レベル」(仕入注文や請求書等の各明細項目に対する情報があるレベル)で提供されることもあれば、「概要レベル」(仕入注文や請求書等に関する総計情報レベル)で提供されることもある。管理しきれないデータ容量にならない限り、詳細
レベルのデータが望ましい。図2では、緑色のテーブルは、詳細レベルのデータが提供される
場合は含まれ、概要レベルのデータの場合は含まれない。
仕入・支払標準の各テーブル内にあるデータフィールドの「レベル」カラムは、データの重要性を示すために「1」あるいは「2」、どちらか一方のラベルを持っている。第1レベルの項
目は必須である(ITシステムか追加の手段によって利用可能な場合)。第2レベルの項目は推奨されるが、必ずしも入手可能だとは限らないかもしれない。利用可能ではないフィールドは別途指定されるべきである。

次のサブセクションでは、仕入・支払監査データ標準について詳述している。
2.0 仕入・支払標準データ2
2.1 Purchase_Orders_YYYYMMDD_YYYYMMDD
2.2 Purchase_Orders_Lines_YYYYMMDD_YYYYMMDD
2.3 Goods_Received_YYYYMMDD_YYYYMMDD
2.4 Goods_Received_Lines_YYYYMMDD_YYYYMMDD
2.5 Invoices_Received_YYYYMMDD_YYYYMMDD
2.6 Invoices_Received_Lines_YYYYMMDD_YYYYMMDD
2.7 Open_Accounts_Payable_YYYYMMDD
2.8 Payments_Made_YYYYMMDD_YYYYMMDD
2.9 AP_Cash_Application_YYYYMMDD_YYYYMMDD
2.10 AP_Adjustments_YYYYMMDD_YYYYMMDD
2.11 AP_Adjustments_Lines_YYYYMMDD_YYYYMMDD
2.12 Payment_Type_Listing_YYYYMMDD
2.13 AP_Adjustment_Type_Listing_YYYYMMDD
2.14 Supplier_Listing_YYYYMMDD

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

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

2.1 Purchase_Orders_YYYYMMDD_YYYYMMDD

Purchase_Orders_YYYYMMDD_YYYYMMDDは、少なくとも、調査中の期間内に行われたすべての仕入注文を含む。このファイ
ルには、調査中の期間内に記録された取引に関連する、当期および前期のすべての仕入注文が含まれるのが理想的である。しかし、これらの仕入注文の一部は、はるか過去に行われた可能性があるため、被監査会社および監査人は含める
べき仕入注文履歴を決定するための判断をしなければならない。

このファイルでは、各仕入注文に対してそれぞれ1レコードとなる。
フ ィ
フィールド名ー ル
ド 番
号
1
Purchase_Order_ID

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

TEXT

100

3

XBRL GLタクソノミ要素3

説明

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

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

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

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

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

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

TEXT

100

XBRL GLタクソノミ要素1

gl-cor:documentNumber

3

Purchase_Order_Date

1

DATE

gl-cor:documentDate

4

Purchase_Order_Fiscal_Year

1

TEXT

4

gl-bus:fiscalYearEnd

5

Purchase_Order_Period

1

TEXT

10

gl-bus:postingCode

説明

仕入注文の識別子番号または識別子
コード。
仕入注文日。仕入注文が入力された日とは関係がない。
Purchase_Order_Dateが記帳された会計期間。
YYYYは区切りに使用される。XBRL
GLタクソノミフレームワークのための会計期末CCYY-MM-DD(ISO 860
1)。
Purchase_Order_Dateが記帳された会計期間。

例には、週単位の期間としてW1–W5
3、月単位の期間としてM1–M12、四半期単位の期間としてQ1–Q4を含む。

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

XBRL GLタクソノミ要素1

説明

財務諸表が監査対象となるレベルで事業単位、地域、支店などを識別するために利用される。Business_Uni
t_Listingファイル内のBusiness_Un
it_Codeと一致しなければならない。
支払先の供給業者の識別子か、買掛計上先の供給業者の識別子。
Supplier_Listing_YYYYMMDDファイ
ル内のSupplier_Account_IDに一致しなければならない。
各仕入注文に一意の識別子。複数フィールドの結合が必要な場合があ
る。

1

TEXT

50

gl-bus:organizationIdenti
fier7

Supplier_Account_ID

1

TEXT

100

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

8

Purchase_Order_Requisition_ID

2

TEXT

100

9

Entered_By

1

TEXT

100

gl-taf:originatingDocumen
tNumber with gltaf:originatingDocumentTy
pe = “order-requisition”*
gl-cor:identifierCode wit
h glcor:identifierCategor
y = “systemUser”

記録を残した人の(User_Listingファイル内の)User_ID。

10Entered_Date

2

DATE

gl-cor:enteredDate

11

Entered_Time

2

TIME

12

Approved_By

2

TEXT

13

Approved_By_Date

2

DATE

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

14

Approved_By_Time

2

TIME

15

Last_Modified_By

2

TEXT

16

Last_Modified_Date

2

DATE

17

Last_Modified_Time

2

TIME

100

100

取引がシステムに入力された日付。
これは、時に作成日と呼ばれる。可能な場合、これは、(ユーザが入力した日付ではなく)システムで生成された日付にする必要がある。この日付は、必ずしも、実際の取引の日付に対応していない。
この取引をシステムに入力した時間。ISO 8601表記の24時間制の時
刻(HHMM)(例: PM1:00 = 1300)。
入力を承認した人の(User_Listing
ファイルの)ユーザID。
入力が承認された日付。

(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 The time the entry was last modi
ISO 8601 representation o fied.ISO 8601表記の24時間制の時
f gl刻(HHMM)
usk:lastDateRepeat, menti (例: PM1:00 = 1300)。

oned previously.)
注記:詳細(明細項目)データが提供される場合、次のフィールドは省略される場合がある。

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

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

NUMERIC

19

Purchase_Order_Local_Currency

1

TEXT

3

20

Segment01

2

TEXT

25

XBRL GLタクソノミ要素1

gl-muc:amountOriginalAmou
nt
gl-muc:amountOriginalCurr
ency
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.)

説明

現地通貨での取引金額。
現地国の報告で要求される通貨。ISO 4217コーディングを参照。
プロフィット・センター、部門、ファンド、プログラム、支店、プロジ
ェクトなどのために使用することができる準備されたセグメントフィー
ルド。

21

Segment02

2

TEXT

25

上記参照

上記参照

22

Segment03

2

TEXT

25

上記参照

上記参照

23

Segment04

2

TEXT

25

上記参照

上記参照

24

Segment05

2

TEXT

25

上記参照

上記参照

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

内容

gl-cor:entriesType

value = “other”

gl-cor: entriesComment

value = “ads:Purchase_Orders_YYYYMMDD_YYYYMMDD”

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

2.2 Purchase_Orders_Lines_YYYYMMDD_YYYYMMDD

Purchase_Orders_Lines_YYYYMMDD_YYYYMMDDファイルには、Purchase_Orders_YYYYMMDD_YYYYMMDDファイル内にある仕入注文に対する詳細な明細項目が含まれる。このファイルの使用は任意であるが、管理しきれないデータ容量ではな
い限り、使用することが推奨される。

このファイルでは、仕入注文の各明細項目に対してそれぞれ1レコードとなる。
フ ィ
フィールド名ー ル
ド 番
号
1
Purchase_Order_ID

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

TEXT

100

4

XBRL GLタクソノミ要素4

説明

gl-cor:documentReference wi 各仕入注文に一意の識別子。このI
th glcor:documentType = “o Dは、各仕入注文を一意に識別する
rder-vendor”
ためのフィールド(例えば、文書番
号、文書種別、および年)を連結することによって作成される必要がある。

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

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

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

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

TEXT

10

gl-cor:lineNumber
gl-bus:measurableID

3

Purchase_Order_Line_Product_I
D

1

TEXT

25

4

Purchase_Order_Line_Product_D
escription

1

TEXT

100

5

Purchase_Order_Line_Product_G
roup_ 01
Purchase_Order_Line_Product_G
roup_ 02
Purchase_Order_Line_Quantity

2

TEXT

25

2

TEXT

25

1

NUMERIC

2

TEXT

1

NUMERIC6789Purchase_Order_Line_Unit_of_M
easurePurchase_Order_Line_Unit_Price

XBRL GLタクソノミ要素3

25

説明

仕入注文の明細行番号の識別子。

各仕入商品に一意の識別子。このIDは、(例えば、事業単位、商品番号、および年など)は、各商品を一意に識別するためのフィールドを連結することによって作成される必要がある。
gl-bus:measurableDescriptio 商品の名前やその他の識別する特n
徴を表す説明(平易な英語)。
gl-bus:measurableCodeDescri 商品の記述子(01)。例えば、タイ
ption
ヤや付属品など。
gl-bus:measurableCategory
商品の記述子(02)。例えば、銘柄など。
gl-bus:measurableQuantity
仕入注文明細行の数量。
gl-bus:measurableUnitOfMeas 仕入注文明細行の基本計量単位。
ure
gl-bus:measurableCostPerUni 仕入注文明細行の単位当たりの価
t
格。

フ ィ
フィールド名レ ベ フラットファイルXBRL GLタクソノミ要素3
ー ル
ル
データ
ド 番
データ型
長さ4
号
10 Purchase_Order_Line_Amount_Lo 1
NUMERICgl-muc:amountOriginalAmountcal
11 Purchase_Order_Line_Local_Cur 1
TEXT
3
gl-muc:amountOriginalCurren
rencycy
12 Segment01
2
TEXT
25
gl-cor:accountSubID withassociated gl-cor:account
SubType(Note:XBRL GL tracks

説明

現地通貨での取引金額。
現地国の報告で要求される通貨。I
SO 4217コーディングを参照。
プロフィット・センター、部門、ファンド、プログラム、支店、プ
ロジェクトなどのために使用することができる準備されたセグメン
トフィールド。

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.)
13

Segment02

2

TEXT

25

上記参照

上記参照

14

Segment03

2

TEXT

25

上記参照

上記参照

15

Segment04

2

TEXT

25

上記参照

上記参照

16

Segment05

2

TEXT

25

上記参照

上記参照

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

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

2.3 Goods_Received_YYYYMMDD_YYYYMMDD
フ ィ
フィールド名ー ル
ド 番
号
1 Receipt_ID

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

TEXT

100

XBRL GLタクソノミ要素

説明

gl-cor:documentReference

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

2Receipt_Date

1

DATE

gl-cor:documentDate

3

Receipt_Fiscal_Year

1

TEXT

4

gl-bus:fiscalYearEnd

4

Receipt_Period

1

TEXT

10

gl-bus:postingCode

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

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

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

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

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

1XBRL GLタクソノミ要素

説明

gl-cor:detailComment withvalues “0” or “1”; gl-cor:documentType of “receipt”
gl-cor:documentTypeDescri
ption

取引がはじめの領収済み取引の場合は「0」となり、領収調整の場合は「1」となる。

6

Adjustment_Description

2

TEXT

100

領収調整が行われている場合における、その調整の理由についての説明。
出荷帳票の参照番号(企業参照番号
または物流企業識別子)。

7

Receipt_Document_ID

1

TEXT

100

gl-cor:documentNumber

8

Supplier_Account_ID

1

TEXT

100

9

Business_Unit_Code

1

TEXT

50

gl-cor:identifierCode wit 商品を提供する供給業者の識別子。
h glcor:identifierType =Supplier_Listing_YYYYMMDDファイ“vendor”
ル内のSupplier_Account_IDと一致しなければならない。
gl-bus:organizationIdenti 財務諸表が監査対象となるレベルで事業単位、地域、支店などを識別す
fier
るために利用される。Business_Uni
t_Listingファイル内のBusiness_Un
it_Codeと一致しなければならない。

10

Purchase_Order_ID

1

TEXT

11

Purchase_Order_Date

1

DATE

12

Entered_By

1

TEXT

13

Entered_Date

2

DATE

100

100

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

各仕入注文に一意の識別子。
Purchase_Orders_YYYYMMDD_YYYYMMD
Dファイル内のPurchase_Order_IDに一致しなければならない。

仕入注文がない場合、空白のままにする。
gl-cor:documentDate*
仕入注文日。仕入注文が入力された日とは関係がない。仕入注文がない
場合、空白のままにする。
gl-cor:identifierCode wit 記録を残した人の(User_Listingフh glcor:identifierCategor ァイル内の)User_ID。
y = “systemUser”
gl-cor:enteredDate
取引がシステムに入力された日付。
これは、時に作成日と呼ばれる。可能な場合、これは、(ユーザが入力した日付ではなく)システムで生成された日付にする必要がある。この日付は、必ずしも、実際の取引の日付に対応していない。

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

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

TIME

15

Approved_By

2

TEXT

16

Approved_By_Date

2

DATE

17

Approved_By_Time

2

TIME

18

Last_Modified_By

2

TEXT

19

Last_Modified_Date

2

DATE

20

Last_Modified_Time

100

100

XBRL GLタクソノミ要素

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

この取引をシステムに入力した時間。ISO 8601表記の24時間制の時
刻(HHMM)(例: PM1:00 = 1300)。
入力を承認した人の(User_Listing
ファイルの)ユーザID。
入力が承認された日付。

(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)(例: PM1:00 = 1300)。
f glusk:lastDateRepeat, menti
oned previously.)
注記:詳細(明細項目)データが提供される場合、次のフィールドは省略される場合がある。
2

TIME

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

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

NUMERIC

22

Receipt_Amount_Local

1

TEXT

23

Purchase_Order_Amount_Local

1

NUMERIC

24

Purchase_Order_Local_Currency

1

TEXT

XBRL GLタクソノミ要素

説明

gl-muc:amountOriginalAmou 現地通貨による、仕入注文に関連す
nt *る受領帳票の品目の合計金額。
3

3

gl-muc:amountCurrency*

現地国の報告で要求される通貨。ISO 4217コーディングを参照。
Gl-muc:amountOriginalAmou 現地通貨での取引金額。仕入注文がnt
ない場合、空白のままにする。
Gl-muc:amountOriginalCurr 現地国の報告で要求される通貨。ISency
O 4217コーディングを参照。仕入注
文がない場合、空白のままにする。

25

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 cod
e NA, description N. America, and type global area
using

26

Segment02

2

TEXT

25

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

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]は情報収集に共通しているものを説明する説明フィールドであGoods_Received_YYYYMMDD_YYYYMMDD”
り、
この表現に関連して収集するタイプの監
査データ標準の名前空間と修飾子を導入する。
*
領収は複数の注文に対して行うことができるため、元の注文番号に関連する注文からの各注文明細行は、独立した1つのentryDetailとして表示され、注文明細行 (元の注文情報を含む)と受領明細行(元の注文情報を含まない、入力の見出しをグループ化することで関連付けられる)は区別される。

2.4 Goods_Received_Lines_YYYYMMDD_YYYYMMDD

Goods_Received_Lines_YYYYMMDD_YYYYMMDDファイルには、Goods_Received_YYYYMMDD_YYYYMMDDファイル内にあるすべての出荷および出荷調整に対する詳細な明細項目が含まれる。このファイルの使用は任意であるが、管理しきれないデー
タ容量ではない限り、使用することが推奨される。このファイルには、関係がない産業(例えば、サービス業など)もある。
このファイルでは、各出荷または各出荷調整の各明細項目に対してそれぞれ1レコードとなる。
フ ィ
フィールド名レ ベ フラットファイルXBRL GLタクソノミ要素
説明
ー ル
ル
データ
ド 番
データ型
長さ
号
1
Receipt_ID
1
TEXT
100
gl-cor:documentReference
出荷受領済みの各取引に一意の識別子。このIDは、各出荷を一意に識別するためのフィールド(例えば、文
書番号、文書種別、および年)を連結することによって作成される必要がある。
2
Receipt_Document_Line_ID
1
TEXT
10
gl-cor:lineNumber*
受領帳票の明細行の参照番号。
3

Receipt_Product_ID

1

TEXT

25

gl-bus:measurableID

各商品に一意の識別子。

4

Receipt_Product_Description

1

TEXT

100

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

5

Receipt_Product_Bar_Codeフ ィ
フィールド名ー ル
ド 番
号
6Receipt_Product_Group_01

2

TEXT

100

gl-bus:measurableIDOther

商品統一コード(UPC)またはその他の一般識別子。

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

XBRL GLタクソノミ要素

説明

2

TEXT

25
25

7

Receipt_Product_Group_02

2

TEXT

8

Receipt_Quantity

1

NUMERIC

9

Receipt_Unit_of_Measure

2

TEXT

10

Receipt_Unit_Price

1

NUMERIC

11

Receipt_Line_Amount_Local

1

NUMERIC

12

Receipt_Line_Amount_Local_Cur
rency

1

TEXT

25

3

gl-bus:measurableCodeDesc 商品の記述子(01)。例えば、タイヤ
riptionや付属品など。
gl-bus:measurableCategory 商品の記述子(02)。例えば、銘柄など。
gl-bus:measurableQuantity 受領された商品量。
gl-bus:measurableUnitOfMe
asure
gl-bus:measurableCostPerU
nit
gl-muc:amountOriginalAmou
nt *計量の基本単位。
受領された商品の単位あたりの価格。
現地通貨による、仕入注文に関連する受領帳票の明細項目の金額。

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

13

Purchase_Order_Line_ID

1

TEXT

10

gl-cor:lineNumber*

14

Purchase_Order_Quantity

2

NUMERIC

gl-bus:measurableQuantity

15

Purchase_Order_Unit_of_Measur
e

2

TEXT

16

Purchase_Order_Unit_Price

2

NUMERIC

gl-bus:measurableCostPerU
nit

17

Purchase_Order_Line_Amount_Lo
cal

1

NUMERICgl-muc:amountOriginalAmou
nt

18

Purchase_Order_Line_Local_Cur
rency

1

TEXT

25

3

gl-bus:measurableUnitOfMe
asure

gl-muc:amountOriginalCurr
ency

受領された商品に対する仕入注文の明細行ID。Purchase_Orders_YYYYMM
DD_YYYYMMDDファイル内で使用されるPurchase_Order_Line_IDに一致しなければならない。
仕入注文がない場合、空白のままにする。
仕入注文明細行の品目量。仕入注文がない場合、空白のままにする。
仕入注文明細行の基本計量単位。仕入注文がない場合、空白のままにする。
仕入注文明細行の単位当たりの価格。仕入注文がない場合、空白のままにする。
現地通貨による、領収済み出荷帳
票に関連する仕入注文内の明細項
目の金額。仕入注文がない場合、空白のままにする。
現地国の報告で要求される通貨。I
SO 4217コーディングを参照。仕入注文がない場合、空白のままにする。

フ ィフィールド名ー ル
ド 番
号
19 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 cod
e NA, description N. America, and type global area
using

20

Segment02

2

TEXT

25

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

21

Segment03

2

TEXT

25

上記参照

上記参照

22

Segment04

2

TEXT

25

上記参照

上記参照

23

Segment05

2

TEXT

25

上記参照

上記参照

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

コメント

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

領収は複数の注文に対して行うことができるため、元の注文番号に関連する注文からの注文明細行は、独立した1つのentryDetailとして表示され、注文明細行(元の注文情報を含む)と受領明細行(元の注文情報を含まない、入力の見出しをグループ化することで関連付けられる)は区別される。

*

2.5 Invoices_Received_YYYYMMDD_YYYYMMDD

Invoices_Received_YYYYMMDD_YYYYMMDDファイルは、少なくとも、調査中の期間内に生成されたすべての請求書を含む。
このファイルには、請求書の受領が前期に行われた場合であっても、調査中の期間内に記録された取引(支払完了など)に関連するすべての請求書が含まれるのが理想的である。監査人は、含めるべき過去の請求書を決定するための判断をしなければならない。
このフラットフォーマットファイルでは、各請求書に関連付けられる各仕入注文に対してそれぞれ1レコードとなる。例
えば、1つの請求書に3つの仕入注文からの商品が含まれていた場合、この請求書に対しては3つのレコードがあることになり、1レコードは3つの仕入注文の1つずつに関連付けられる請求書内の複数商品に対応する。
XBRL GLはgl-taf:originatingDocumentNumberを利用して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_Received_YYYYMMDD_YYYY
MMDD、Open_Accounts_Payables_YYYYMMDD、AP_Cash_Application_YYYYM
MDD_YYYYMMDD、およびAP_Adjustmen
ts_YYYYMMDD_YYYYMMDD)。
gl-cor:documentNumber wit 外部で作成された請求書の識別番
h glcor:documentType = 号。
“invoice”
gl-cor:documentDate
請求書の日付。請求書が入力された日付とは関係がない。請求書の条件に基づいて計算された日付。

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

5

6

Invoice_Period

Invoice_Due_Date

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

XBRL GLタクソノミ要素

1

TEXT

4

gl-bus:fiscalYearEnd

1

TEXT

10

gl-bus:postingCode

1

DATE

gl-cor:MaturityDate

説明Invoice_Dateが記帳された会計年度。YYYYは区切りに使用される。XB
RL GLタクソノミフレームワークのための会計期末CCYY-MM-DD(ISO 860
1)。
Invoice_Dateが記帳された会計期間。
例には、週単位の期間としてW1–W5
3、月単位の期間としてM1–M12、四半期単位の期間としてQ1–Q4を含む。
供給業者への支払期日。すべての取引に支払期日があるわけではない(例えば、貸方メモなど)。債務の年齢調べは、通常はこの日付に基づいて計算される。

7

Purchase_Order_ID

1

TEXT

100

8

Business_Unit_Code

1

TEXT

50

9

Supplier_Account_ID

1

TEXT

100

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

各仕入注文に一意の識別子。
Purchase_Orders_YYYYMMDD_YYYYMMD
Dファイル内のPurchase_Order_IDに一致しなければならない。

仕入注文がない場合、空白のままにする。
gl-cor:organizationidenti 財務諸表が監査対象となるレベルで事業単位、地域、支店などを識別す
fier
るために利用される。Business_Uni
t_Listingファイル内のBusiness_Un
it_Codeと一致しなければならない。
gl-cor:identifierCode wit 支払先の供給業者の識別子か、買掛h glidentifierType = “ve 計上先の供給業者の識別子。
Supplier_Listing_YYYYMMDDファイ
ndor”
ル内のSupplier_Account_IDに一致しなければならない。

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

11

Terms_Discount_Days

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

XBRL GLタクソノミ要素

2

NUMERIC

gl-cor:terms

2

NUMERIC

フィールド番号10の説明を参照。

説明

請求書の一定の日数前に支払われる
場合の供給業者が提示する割引率。
フラットファイルでは、小数点以下１桁として表現される(例えば、10％が10.0として表現される)。XBRLGLにおいては、3フィールドの9、10、11は、例えば2％と「xx.x％ dd、Net dd」の形式で入力されることになる。拡張事業報告言語のXBRL
GLタクソノミフレームワークにおいては、3つのフィールドTerms_Disco
unt_Percentage、Terms_Discount_D
aysおよびTerms_Due_Daysの3つのフィールドは、「xx.x％ dd Net dd」の形式で入力されることになる。例
えば実質支払期間が30日で、10日以内に支払うと2％割引となる場合では「2％ 10 Net 30」で表現される。
請求書日付からの日数は、供給業者が割引を許可するために有利である。これは小数点以下がない桁数(例えば、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

XBRL GLタクソノミ要素

説明

See description for field 請求書に対する支払遅延となる前#10 explicit in gl-cor:ma の、支払義務を果たすことが可能な
turityDate
日数。
gl-cor:identifierCode wit 記録を残した人の(User_Listingフh glcor:identifierCategor ァイル内の)User_ID。
y = “systemUser”
gl-cor:enteredDate
取引がシステムに入力された日付。
これは、時に作成日と呼ばれる。可能な場合、これは、(ユーザが入力した日付ではなく)システムで生成された日付にする必要がある。この日付は、必ずしも、実際の取引の日付に対応していない。
(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 入力を承認した人の(User_Listingrson
ファイルの)ユーザID。

17

Approved_By_Date

2

DATE

gl-usk:nextDateRepeat

18

Approved_By_Time

2

TIME

19

Last_Modified_By

2

TEXT

20

Last_Modified_Date

2

DATE

(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
入力が最後に変更された日付。

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 Invoice_Amountレ ベ フラットファイル
ル
データ
データ型 長さ
1

NUMERICXBRL GLタクソノミ要素

gl-cor:amount23

Invoice_Amount_Currency

1

TEXT

3

24

Invoice_Amount_Reporting

1

NUMERIC

25

Invoice_Reporting_Currency

1

TEXT

26

Invoice_Amount_Local

1

NUMERIC

27

Invoice_Local_Currency

1

TEXT

3

28

Tax1_Type

1

TEXT

25

3

説明

機能通貨またはグループ通貨で記録された取引金額。すべて取引が単一通貨に記録されているため、多通貨換算を実行する必要はない。
gl-muc:amountCurrency
請求金額に関連する機能通貨やグループ通貨。ISO 4217コーディングを参照。
gl-muc:amountTriangulatio 報告通貨で記録された取引金額。
nAmount
gl非連結報告のための請求書の報告金
muc:amountTriangulationCu 額に関連する報告通貨。ISO 4217コ
rrencyーディングを参照。
gl-muc:amountOriginalAmou 現地通貨での取引金額。
nt
gl-muc:amountOriginalCurr 現地国の報告で要求される通貨。ISency
O 4217コーディングを参照。
gl-cor:taxCode (Note that 税1タイプのコード(例: 売上税、付XBRL GL permits an unlimi 加価値税)。
ted number of tax codes a
このフィールドは、Tax_Table_YYYY
nd amounts with the glco
MMDDのRegulator_Codeフィールドとr:taxes structure.)
一致する必要がある。

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

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

1

TEXT

TEXT

25

25

31

Tax1_Type_Description

1

TEXT

100

32

Tax2_Type_Description

1

TEXT

100

XBRL GLタクソノミ要素

同上

同上

説明

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

このフィールドは、Tax_Table_YYYY
MMDDのRegulator_Codeフィールドと一致する必要がある。
gl-cor:taxDescription (No 税1タイプの説明(例: 税を支払う税
te that XBRL GL formalize 務当局や、税を特定するためのそのs the tax authority with
他の情報など)。
gl-cor:taxAuthority and p
rovides other standard fi
elds as well.)
同上
税2タイプの説明(例: 税を支払う税
務当局や、税を特定するためのその他の情報など)。

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

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

TEXT

100

XBRL GLタクソノミ要素

同上34

Tax1_Local

2

NUMERIC

gl-cor:taxAmount35

Tax2_Local

2

NUMERIC

同上

36

Tax3_Local

2

NUMERIC

同上

説明

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

37

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

38

Segment02

2

TEXT

25

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

39

Segment03

2

TEXT

25

上記参照

上記参照

40

Segment04

2

TEXT

25

上記参照

上記参照

41

Segment05

2

TEXT

25

上記参照

上記参照

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

要素

内容

gl-cor:entriesType

value = “other”

gl-cor: entriesComment

value = “ads:Invoices_Received_YYYYMMDD_YYYYMMDD”

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

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

*

2.6 Invoices_Received_Lines_YYYYMMDD_YYYYMMDD

Invoices_Received_Lines_YYYYMMDD_YYYYMMDDファイルには、Invoices_Received_YYYYMMDD_YYYYMMDDファイル内にある請求書の詳細な明細項目が含まれる。
このファイルの使用は任意であるが、管理しきれないデータ容量ではない限り、使用することが推奨される。

このファイルでは、請求書の明細項目または仕入注文の明細項目の各組み合わせに対してそれぞれ1レコードとなる。
通常は請求書の各明細項目は仕入注文の1つの明細項目に関連付けられるため、このファイルでは請求書の各明細項目に対してそれぞれ1レコードとなる。稀に、請求書の明細項目が複数の仕入注文の明細項目に関連付けられていることがあり、この場合は、このファイルでは請求書の明細項目に関連する仕入注文の各明細項目に対してそれぞれ1
レコードとなる。

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

Invoice_Line_ID

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

1

XBRL GLタクソノミ要素

説明

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

TEXT

100

gl-cor:documentReference

TEXT

10

gl-cor:lineNumber*フ ィ
フィールド名ー ル
ド 番
号
3Purchase_Order_ID

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

XBRL GLタクソノミ要素

説明

各仕入注文に一意の識別子。
Purchase_Orders_YYYYMMDD_YYYYMMDDファイル内のPurchase_Or
der_IDに一致しなければならない。
仕入注文がない場合、空白のままにする。
仕入注文の明細行番号の識別子。Purchase_Orders_Lines_YY
YYMMDD_YYYYMMDDファイル内で使用されるPurchase_Order_Lin
e_IDに一致しなければならない。
仕入注文がない場合、空白のままにする。
各仕入商品に一意の識別子。

1

TEXT

100

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

4

Purchase_Order_Line_ID

1

TEXT

10

gl-cor:lineNumber*

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
25

8

Invoice_Product_Group_02

2

TEXT

9

Invoice_Line_Amount1

NUMERIC

10

Invoice_Line_Amount_Currency

1

TEXT

11

Invoice_Line_Amount_Reporting

1

NUMERIC

12

Invoice_Line_Reporting_Currency

1

TEXT

13

Invoice_Line_Amount_Local

1

NUMERIC33

XBRL GLタクソノミ要素

説明

gl-bus:measurableCodeDescr 商品の記述子(01)。例えば、タiptionイヤや付属品など。
gl-bus:measurableCategory 商品の記述子(02)。例えば、銘柄など。
gl-cor:amount
機能通貨またはグループ通貨で記録された取引金額。すべて取引が単一通貨に記録されているため、多通貨換算を実行する必要はない。
gl-muc:amountCurrency
請求金額に関連する機能通貨やグループ通貨。ISO 4217コーデ
ィングを参照。
gl-muc:amountTriangulation 報告通貨で記録された取引金
Amount額。
gl非連結報告のための請求書の報
muc:amountTriangulationCur 告金額に関連する報告通貨。ISO
rency
4217コーディングを参照。
gl-muc:amountOriginalAmoun 現地通貨での取引金額。
t14

Invoice_Line_Local_Currency

1

TEXT

3

15

Tax1_Type

1

TEXT

25

16

17

Tax2_Type

Tax3_Type

1

1

TEXT

TEXT

25

25

gl-muc:amountOriginalCurre 現地国の報告で要求される通ncy
貨。ISO 4217コーディングを参照。
gl-cor:taxCode (Note that 税1タイプのコード(例: 売上
XBRL GL permits an unlimit 税、付加価値税)。
ed number of tax codes and
このフィールドは、Tax_Table_Y
amounts with the glcor:tax
YYYMMDDのRegulator_Codeフィー
es structure.)
ルドと一致する必要がある。
同上
税2タイプのコード(例: 売上税、付加価値税)。

同上

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

フ
ー
ド
号

ィ
ル
番

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

XBRL GLタクソノミ要素

説明

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

18

Tax1_Type_Description

1

TEXT

100

19

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.)
同上

20

Tax3_Type_Description

1

TEXT

100

同上

21

Tax1_Local

2

NUMERIC

gl-cor:taxAmount22

Tax2_Local

2

NUMERIC

同上

23

Tax3_Local

2

NUMERIC

同上

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

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

25

GL_Line_Credit_Account_Number

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

TEXT

100

1

TEXT

100

XBRL GLタクソノミ要素

説明

gl-cor:accountMainID withglcor:accountPurposeDescri
ption = “debit-value” ina second account structure
gl-cor:accountMainID withglcor:accountPurposeDescri
ption = “credit-value” in a second account structu
re

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

(Note:XBRL GL permits an unlimited number of accounts or values with a transac
tion, and is not limited to a single debit or credit
value.)

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

26

GL_Tax1_Debit_Account_Number

1

TEXT

100

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 be mapped to glcor:accountMainID.

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

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

XBRL GLタクソノミ要素

説明

1

TEXT

100

同上

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

28

GL_Tax2_Debit_Account_Number

1

TEXT

100

同上

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

29

GL_Tax2_Credit_Account_Number

1

TEXT

100

同上

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

30

GL_Tax3_Debit_Account_Number

1

TEXT

100

同上

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

31

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

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

XBRL GLタクソノミ要素

説明

2

TEXT

25

上記参照

上記参照

35

Segment04

2

TEXT

25

上記参照

上記参照

36

Segment05

2

TEXT

25

上記参照

上記参照

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

value = “other”

gl-cor: entriesComment

value = “ads:Invoices_Received_Line_YYYYMMDD_YYYYMMDD”

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

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

*

2.7 Open_Accounts_Payable_YYYYMMDD

Open_Accounts_Payable_YYYYMMDDテーブルには、指定期日(監査期間の終了あるいは年度末のような)の業務の完了の時
点でのすべての未決、未払、あるいは未解決の債務取引に関する詳細を含んでいる。調査中の期間における買掛債務残高のロールフォワードの場合に、これらのファイルが2つになる場合がある。
このテーブル中の列は、1つのユニークで識別可能な取引について供給業者への支払いが期待される残高を表わす。このファイルは請求書毎の概要レベルである必要はあるが、請求書の明細項目ごとの詳細レベルである必要はない。指定期日の時点での取引金額の合計は、同じ日時の時点での総勘定元帳(GL)中の買掛債務金額合計と一致するはずである。
フ ィ
フィールド名レ ベ フラットファイルXBRL GLタクソノミ要素
説明
ー ル
ル
データ
ド 番
データ型
長さ
号
1
Supplier_Account_ID
1
TEXT
100
gl-cor:identifierCode wit 支払先の供給業者の識別子か、買掛計上先の供給業者の識別子。
h glcor:identifierType =Supplier_Listing_YYYYMMDDファイ{vendor}
ル内のSupplier_Account_IDに一致しなければならない。

2

Invoice_ID

1

TEXT

3

Invoice_Date

1

DATE

100

gl-cor:documentReference

各請求書に一意の識別子。このIDは、各取引を一意に識別するためのフィールド(例えば、文書番号、文
書種別、および年)を連結することによって作成される必要がある。請
求書データを含む次のすべてのテー
ブルと同じIDが使用されていなければならない(Invoices_Received_YYYYMMDD_YYYY
MMDD、Open_Accounts_Payables_YYYYMMDD、AP_Cash_Application_YYYYM
MDD_YYYYMMDD、およびAP_Adjustmen
ts_YYYYMMDD_YYYYMMDD)。

gl-cor:documentDate

請求書の日付。請求書が入力された日付とは関係がない。請求書の条件に基づいて計算された日付。

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

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

DATE

5Balance_Amount

2

NUMERIC

6

Balance_Amount_Currency

2

TEXT

7

Balance_Amount_Reporting

1

NUMERIC

8Balance_Reporting_Currency

1

TEXT

9

Balance_Amount_Local

1

NUMERIC

10Balance_Local_Currency

1

TEXT

XBRL GLタクソノミ要素

gl-cor:maturityDate

gl-taf:documentRemainingB
alance3

33

gl-muc:amountCurrency

gl-muc:amountTriangulationAmount
glmuc:amountTriangulationCu
rrencygl-muc:amountOriginalAmou
nt
gl-muc:amountOriginalCurr
ency

説明

供給業者への支払期日。すべての取引に支払期日があるわけではない(例えば、貸方メモなど)。債務の年齢調べは、通常はこの日付に基づいて計算される。
機能通貨またはグループ通貨で記録された残高金額。
すべて取引が単一通貨に記録されているため、多通貨換算を実行する必要はない。
残高に関連する機能通貨やグループ
通貨。ISO 4217コーディングを参照。
報告通貨で記録された残高金額。
非連結報告のための残高の報告金額に関連する報告通貨。ISO 4217コー
ディングを参照。
現地通貨での残高金額。
現地国の報告で要求される通貨。ISO 4217コーディングを参照。

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

12

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

NUMERIC1TEXTXBRL GLタクソノミ要素

gl-cor:amount50

説明

機能通貨またはグループ通貨で記録されたはじめの残高(はじめの請求
金額)。
すべて取引が単一通貨に記録されているため、多通貨換算を実行する必要はない。
gl-bus:organizationIdenti 財務諸表が監査対象となるレベルで事業単位、地域、支店などを識別す
fier
るために利用される。Business_Uni
t_Listingファイル内のBusiness_Un
it_Codeと一致しなければならない。

13

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

14

Segment02

2

TEXT

25

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

15

Segment03

2

TEXT

25

上記参照

上記参照

16

Segment04

2

TEXT

25

上記参照

上記参照

17

Segment05

2

TEXT

25

上記参照

上記参照

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

value = “other”

gl-cor: entriesComment

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

2.8 Payments_Made_YYYYMMDD_YYYYMMDD

Payments_Made_YYYYMMDD_YYYYMMDDファイルには、期間内のすべての支払済の取引(小切手、電信送金、現金など)が含まれる。
フ ィフィールド名レ ベ フラットファイルXBRL GLタクソノミ要素
説明
ー ル
ル
データ
ド 番
データ型
長さ
号
1
Payment_ID
1
TEXT
100
gl-cor:documentReference
支払済みの各取引に一意の識別子。
このIDは、(例えば、供給業者番号
や支払番号)は、各取引を一意に識別するためのフィールドを連結する
ことによって作成される必要がある。
2
Supplier_Account_ID
1
TEXT
100
gl-cor:identifierCode wit 支払先の供給業者の識別子か、買掛計上先の供給業者の識別子。
h glcor:identifierType =Supplier_Listing_YYYYMMDDファイ“vendor”
ル内のSupplier_Account_IDに一致しなければならない。
3
Business_Unit_Code
1
TEXT
50
gl-bus:organizationIdenti 財務諸表が監査対象となるレベルでfier
事業単位、地域、支店などを識別するために利用される。Business_Uni
t_Listingファイル内のBusiness_Un
it_Codeと一致しなければならない。

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

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

DATE

5

Payment_Fiscal_Year

1

TEXT

4

6

Payment_Period

1

TEXT

10

7

Reference_Number

1

TEXT

8

Reference_Date

1

DATE

100

XBRL GLタクソノミ要素

説明

gl-bus:documentReceivedDa 支払日、または買掛計上の日付。
tegl-bus:fiscalYearEnd
Payment_Dateが記帳された会計年度。YYYYは区切りに使用される。XB
RL GLタクソノミフレームワークのための会計期末CCYY-MM-DD(ISO 860
1)。
gl-bus:postingCode
Payment_Dateが記帳された会計期間。

gl-cor:documentNumber

gl-cor:documentDate

例には、週単位の期間としてW1–W5
3、月単位の期間としてM1–M12、四半期単位の期間としてQ1–Q4を含む。
内部または外部で生成された取引の識別番号(例えば、小切手番号、電信送金番号、または原始文書ID)。
外部で生成された取引の日付(例えば、小切手日付や電信送金日付)。

9

Amount_Credit_Debit_Indicator

1

TEXT

1

10

Payment_Type

1

TEXT

25

11

Payment_Amount1

NUMERIC

gl-cor:debitCreditCode

金額は借方か貸方かの指標。"C"は貸方、"D"は借方。
gl-cor:documentType = “c 取引の借方または貸方金額が供給業
heck” or gl-cor:document 者によって消滅または借方となったType = “payment-other” 方法のコード値/指標(例えば、小切with code in glbus:paymen 手、電信送金、現金など)。Payment_Type_Listing_YYYYMMDDファイル内
tMethodのPayment_Typeに一致しなければならない。

gl-cor:amount

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

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

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

TEXT

3

13

Payment_Amount_Reporting

1

NUMERIC

14

Payment_Amount_Reporting_Curr
ency

1

TEXT

15

Payment_Amount_Local

1

NUMERIC

16

Payment_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 ス(例えば、"Posted," "Not Posted
gStatus of {other} with g ")。
lcor: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

XBRL GLタクソノミ要素

説明

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勘定科目の番号。

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

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

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

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

TIME

23

Approved_By

2

TEXT

24

Approved_By_Date

2

DATE

25

Approved_By_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タクソノミ要素

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

この取引をシステムに入力した時間。ISO 8601表記の24時間制の時
刻(HHMM)(例: PM1:00 = 1300)。
入力を承認した人の(User_Listing
ファイルの)ユーザID。
入力が承認された日付。

(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 8601 representation of glusk:lastDateRepeat, above)

入力が最後に変更された時間。ISO
8601表記の24時間制の時刻(HHMM)(例: PM1:00 = 1300)。

29

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

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:entriesTypegl-cor: entriesCo
mment

内容
value = “other”
value = “ads:Payments_Made_YYYYMMDD_YYYYMMDD”

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

2.9 AP_Cash_Application_YYYYMMDD_YYYYMMDD

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

AP_Application_Fiscal_Year

1

TEXT

4

gl-bus:fiscalYearEnd

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

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

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

XBRL GLタクソノミ要素

説明

10

gl-bus:postingCode

例には、週単位の期間としてW1–W5
3、月単位の期間としてM1–M12、四半期単位の期間としてQ1–Q4を含む。
gl-cor:identifierCode wit 支払先の供給業者の識別子か、買掛計上先の供給業者の識別子。
h glcor:identifierType =Supplier_Listing_YYYYMMDDファイ“vendor”
ル内のSupplier_Account_IDに一致しなければならない。

5

Supplier_Account_ID

1

TEXT

100

6

Payment_ID

1

TEXT

100

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

AP_Application_Dateが記帳された会計期間。

Payments_Made_YYYYMMDD_YYYYMMDD
ファイルの各取引に一意の識別子。
一部またはすべての支払は供給業者の売掛債権に適用される。

7

Invoice_ID

1

TEXT

100

8

Business_Unit_Code

1

TEXT

50

各請求書に一意の識別子。このIDは、各取引を一意に識別するためのフィールド(例えば、文書番号、文
書種別、および年)を連結することによって作成される必要がある。請
求書データを含む次のすべてのテー
ブルと同じIDが使用されていなければならない(Invoices_Received_YYYYMMDD_YYYY
MMDD、Open_Accounts_Payables_YYYYMMDD、AP_Cash_Application_YYYYM
MDD_YYYYMMDD、およびAP_Adjustmen
ts_YYYYMMDD_YYYYMMDD)。
入金が顧客レベルのみ(請求書レベ
ルではない)の場合は、空白のままとする。
gl-organizationIdentifier 財務諸表が監査対象となるレベルで事業単位、地域、支店などを識別するために利用される。Business_Uni
t_Listingファイル内のBusiness_Un
it_Codeと一致しなければならない。
gl-taf:originatingDocumen
tNumber with gltaf:originatingDocumentTy
pe =“invoice”*

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

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

TEXT

10

Entered_Date

2

DATE

11

Entered_Time

2

TIME

12

Approved_By

2

TEXT

13

Approved_By_Date

2

DATE

100

100

XBRL GLタクソノミ要素

説明

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

記録を残した人の(User_Listingファイル内の)User_ID。

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

取引がシステムに入力された日付。
これは、時に作成日と呼ばれる。可能な場合、これは、(ユーザが入力した日付ではなく)システムで生成された日付にする必要がある。この日付は、必ずしも、実際の取引の日付に対応していない。
この取引をシステムに入力した時間。ISO 8601表記の24時間制の時
刻(HHMM)(例: PM1:00 = 1300)。
入力を承認した人の(User_Listing
ファイルの)ユーザID。
入力が承認された日付。

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

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

TIME

15

Last_Modified_By

2

TEXT

16

Last_Modified_Date

2

DATE

17

Last_Modified_Time

2

TIME

18

AP_Application_Amount1

NUMERIC100XBRL GLタクソノミ要素

説明(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
入力が最後に変更された日付。
(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:amount
機能通貨またはグループ通貨で記録された取引金額。すべて取引が単一通貨に記録されているため、多通貨換算を実行する必要はない。

19

Amount_Currency

1

TEXT

3

20

AP_Activity_Amount_Reporting

1

NUMERIC

21

Amount_Reporting_Currency

1

TEXT

22

AP_Activity_Amount_Local

1

NUMERIC

23

Amount_Local_Currency

1

TEXT

3

24

GL_Line_Debit_Account_Number

2

TEXT

100

25

GL_Line_Credit_Account_Number

2

TEXT

100

3

gl-muc:amountCurrency

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

フ ィ
フィールド名ー ル
ド 番
号
26 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 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]は情報収集に共通しているものを説明する説明フィールドであAP_Cash_Application_YYYYMMDD_YYYYMMDD”
り、
この表現に関連して収集するタイプの監
査データ標準の名前空間と修飾子を導入する。
*
入金は、多くの場合複数の請求書に反映され、請求書は複数の出荷および注文に対して発行されるため、各支払に割り当てられる明細行の関係は独立したentryDetailとして表示され、割り当てられた各明細行と根本的な原始証
憑は区別される。

2.10 AP_Adjustments_YYYYMMDD_YYYYMMDD

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

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

3

Adjustment_Document_Number

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

1

TEXT

TEXT

25

100

XBRL GLタクソノミ要素

説明

gl-cor:documentType using 取引の借方または貸方金額が供給
provided enumerations or 業者によって消滅または借方となった方法のコード値/指標(例えgl-cor:documentType =ば、貸方メモ、借方メモ、手数{other} and gl-bus:pay
料、その他の調整など)。「1.9 A
mentMethod with codes
P_Adjustment_Type_Listing_YYYY
from
AP_Adjustment_Type_Listin MMDD」を参照。
g_YY
YYMMDD
gl-cor:documentNumber
外部で作成された調整文書(例えば、貸方メモ)の識別番号。

4

Invoice_ID

1

TEXT

100

5

Adjustment_Date

1

DATE

100

6

Adjustment_Fiscal_Year

1

TEXT

4

gl-taf:originatingDocumen 各請求書に一意の識別子。このID
tNumber with glは、各取引を一意に識別するため
taf:originatingDocumentTy のフィールド(例えば、文書番
号、文書種別、および年)を連結
pe = “invoice”
することによって作成される必要がある。請求書データを含む次のすべてのテーブルと同じIDが使用されていなければならない(Invoices_Received_YYYYMMDD_YY
YYMMDD、Open_Accounts_Payables_YYYYMMDD、AP_Cash_Application_YYYYMMDD_YYYYMMDD、およびAP_A
djustments_YYYYMMDD_YYYYMMD
D)。
調整が顧客レベルのみ(請求書レベルではない)の場合は、空白のままとする。
gl-cor:postingDate
取引の日付。取引が入力された日
付とは関係がない。
gl-bus:fiscalYearEnd
Receipt_Dateが記帳された会計年度。YYYYは区切りに使用される。
XBRL GLタクソノミフレームワー
クのための会計期末CCYY-MMDD(ISO 8601)。

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

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

TEXT

10

8

Business_Unit_Code

1

TEXT

50

9

Supplier_Account_ID

1

TEXT

100

10

Entered_By

1

TEXT

100

XBRL GLタクソノミ要素

gl-bus:postingCode

説明

Receipt_Dateが記帳された会計期間。

例には、週単位の期間としてW1–
W53、月単位の期間としてM1–M1
2、四半期単位の期間としてQ1–Q4を含む。
gl-bus:organizationIdenti 財務諸表が監査対象となるレベル
fierで事業単位、地域、支店などを識別するために利用される。Busine
ss_Unit_Listingファイル内のBus
iness_Unit_Codeと一致しなければならない。
gl-cor:identifierCode wit 支払先の供給業者の識別子か、買h glcor:identifierType = 掛計上先の供給業者の識別子。
Supplier_Listing_YYYYMMDDファ“vendor”
イル内のSupplier_Account_IDに一致しなければならない。

gl-cor:identifierCode wit 記録を残した人の(User_Listingh glcor:identifierCategor ファイル内の)User_ID。
y = “systemUser”

11Entered_Date

1

DATE

12

Entered_Time

2

TIME

13

Approved_By

2

TEXT

14

Approved_By_Date

2

DATE

15

Approved_By_Time

2

TIME

gl-cor:enteredDate

100

取引がシステムに入力された日付。これは、時に作成日と呼ばれる。可能な場合、これは、(ユーザが入力した日付ではなく)シス
テムで生成された日付にする必要がある。この日付は、必ずしも、実際の取引の日付に対応していない。
(This is included in the この取引をシステムに入力した時
ISO 8601 representation o 間。ISO 8601表記の24時間制の時
f glcor:enteredDate, abov 刻(HHMM)(例: PM1:00 = 1300)。
e)
gl-cor:entryResponsiblePe 入力を承認した人の(User_Listin
rson
gファイルの)ユーザID。
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.)フ ィフィールド名ー ル
ド 番
号
16 Last_Modified_By
17
18

19

20

21

22

Last_Modified_Date
Last_Modified_Time

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

TEXT

2
2

DATE
TIME

100

XBRL GLタクソノミ要素

説明

gl-bus:enteredByModified

この入力を最後に修正したユーザの(User_Listingの)User_ID。
gl-usk:lastDateRepeat
入力が最後に変更された日付。
(This is included in the 入力が最後に変更された時間。ISISO 8601 representation o O 8601表記の24時間制の時刻(HHM
f gllastDateRepeat, menti M) (例: PM1:00 = 1300)。

oned previously.)
注記:詳細(明細項目)データが提供される場合、次のフィールドは省略される場合がある。
Adjustment_Amount1
NUMERIC
gl-cor:amount
機能通貨またはグループ通貨で記録された取引金額。すべて取引が単一通貨に記録されているため、多通貨換算を実行する必要はな
い。
Adjustment_Amount_Currency
1
TEXT
3
gl-muc:amountCurrency
調整金額に関連する機能通貨やグループ通貨。ISO 4217コーデ
ィングを参照。
Adjustment_Amount_Reporting
1
NUMERIC
gl報告通貨で記録された取引金額。
muc:amountTriangulationAm
ount
Adjustment_Reporting_Currency
1TEXT
3gl非連結報告のための調整の報告金
muc:amountTriangulationCu 額に関連する報告通貨。ISO 4217
rrencyコーディングを参照。

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

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

NUMERIC

24

Adjustment_Local_Currency

1

TEXT

3

25

Tax1_Type

1

TEXT

25

XBRL GLタクソノミ要素

gl-muc:amountOriginalAmou 現地通貨での取引金額。
nt
gl-muc:amountOriginalCurr 現地国の報告で要求される通貨。
ency
ISO 4217コーディングを参照。
gl-cor:taxCode (Note tha 税1タイプのコード(例: 売上税、
t XBRL GL permits an unl 付加価値税)。
imited number of tax codes and amounts with the
gl-cor:taxes structure.)26

Tax2_Type

1

TEXT

25

説明

同上

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

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

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

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

TEXT

25

28

Tax1_Type_Description

1

TEXT

100

29

Tax2_Type_Description

1

TEXT

100

30

Tax3_Type_Description

1

TEXT

100

31

Tax1_Local

2

NUMERICXBRL GLタクソノミ要素

同上説明

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

このフィールドは、Tax_Table_YY
YYMMDDのRegulator_Codeフィール
ドと一致する必要がある。
gl-cor:taxDescription (No 税1タイプの説明(例: 税を支払う
te that XBRL GL formalize 税務当局や、税を特定するためのs the tax authority with その他の情報など)。
gl-cor:taxAuthority and p
rovides other standard fi
elds as well.)
同上
税2タイプの説明(例: 税を支払う
税務当局や、税を特定するためのその他の情報など)。
同上
税3タイプの説明(例: 税を支払う
税務当局や、税を特定するためのその他の情報など)。
gl-cor:taxAmount
税1タイプの金額は、取引に含ま32

Tax2_Local

2

NUMERIC33

Tax3_Local

2

NUMERIC34

GL_Debit_Account_Number

2

TEXT

100

35

GL_Credit_Account_Number

2

TEXT

100

れている。現地通貨で記録される。
同上
税2タイプの金額は、取引に含まれている。現地通貨で記録される。
同上
税3タイプの金額は、取引に含まれている。現地通貨で記録される。
gl-cor:accountMainID with 取引において借方に記帳されたGL
glcor:accountPurposeDescr 勘定科目の番号。
iption = “debit-value”
in a second account structure
gl-cor:accountMainID with 取引において貸方に記帳されたGL
glcor:accountPurposeDescr 勘定科目の番号。
iption = “credit-value”
in a second account struc
ture

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

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

TEXT

100

XBRL GLタクソノミ要素

説明

XBRL GL does not have fie 税1の取引において借方に記帳さ
lds explicitly associatin れたGL勘定科目の番号。
g GL accounts to tax, alt
hough it does permit spec
ification of accounts as
tax accounts (glcor:accountPurposeCode);
it associates tax detailin the glcor:taxes structure with specific accou
nts by including them within the same gl-cor:ent
ryDetail if the gl-cor:amount is the same, or wi
thin the same glcor:entr
yHeader if amounts differ.As with the previous G
L lines, the account num
bers would be mapped togl-cor:accountMainID.

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

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

XBRL GLタクソノミ要素

説明

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

1

TEXT

100

同上

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

42

Segment01

2

TEXT

25

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

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

hierarchy ID, hierarchy
description, and hierarc
hy type, so it can trackcode NA, description N.
America, and type global
area using

43

Segment02

2

TEXT

25

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

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]は情報収集に共通しているものを説明する説明フィールドであAP_Adjustments_YYYYMMDD_YYYYMMDD”
り、
この表現に関連して収集するタイプの監
査データ標準の名前空間と修飾子を導入する。
*
調整は、複数の根本的な原始証憑を表す場合があり、各調整の関連は独立したentryDetailとして表示され、調整と根本的な原始証憑は区別される。

2.11 AP_Adjustments_Lines_YYYYMMDD_YYYYMMDD

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

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

Invoice_Line_ID

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

XBRL GLタクソノミ要素

説明

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

1

TEXT

100

gl-taf:originatingDocument
Number with gl-taf:origina
tingDocumentType = “invoi
ce”

1

TEXT

10

gl-cor:lineNumber*

調整が顧客レベルのみ(請求書レベ
ルではない)の場合は、空白のまま
とする。

4

Adjustment_Line_Amount1

NUMERIC

5

Adjustment_Line_Amount_Currenc
y

1

TEXT

6

Adjustment_Line_Amount_ReportingAdjustment_Line_Reporting_Curr
ency

1

NUMERIC

1

TEXT

8

Adjustment_Line_Amount_Local

1

NUMERIC

9

Adjustment_Line_Local_Currency

1

TEXT

7

gl-cor:amount

3

3

3

機能通貨またはグループ通貨で記録された取引金額。すべて取引が単一通貨に記録されているため、多通貨換算を実行する必要はな
い。
gl-muc:amountCurrency
調整金額に関連する機能通貨やグ
ループ通貨。ISO 4217コーディン
グを参照。
gl-muc:amountTriangulation 報告通貨で記録された取引金額。
Amountgl非連結報告のための調整の報告金
muc:amountTriangulationCur 額に関連する報告通貨。ISO 4217
rency
コーディングを参照。
gl-muc:amountOriginalAmoun 現地通貨での取引金額。
t
gl-muc:amountOriginalCurre 現地国の報告で要求される通貨。Incy
SO 4217コーディングを参照。

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

1112

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フィールドと一致する必要がある。

13

Tax1_Type_Description

1

TEXT

100

14

Tax2_Type_Description

1

TEXT

100

15

Tax3_Type_Description

1

TEXT

100

16

Tax1_Local

2

NUMERIC17

Tax2_Local

2

NUMERIC18

Tax3_Local

2

NUMERIC19

GL_Line_Debit_Account_Number

2

TEXT

100

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

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

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

21

GL_Tax1_Debit_Account_Number

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

TEXT

100

1

TEXT

100

XBRL GLタクソノミ要素

説明

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 a

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

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

ccount numbers would be mapped to gl-cor:accountMa
inID.
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勘定科目の番号。

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

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

TEXT

25

XBRL GLタクソノミ要素

説明

gl-cor:accountSubID with

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

associated gl-cor:account
SubType (Note:XBRL GL trackshierarchy 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.)
28

Segment02

2

TEXT

25

上記参照

上記参照

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

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

XBRL GLタクソノミ要素

説明

2

TEXT

25

上記参照

上記参照

30

Segment04

2

TEXT

25

上記参照

上記参照

31

Segment05

2

TEXT

25

上記参照

上記参照

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

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

2.12 Payment_Type_Listing_YYYYMMDD

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

Payment_Type_Description

1

TEXT

100

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

XBRL GLへの追加コメントXBRL GLは、gl-cor:documentTypeに計数値を使用して、異なるタイプの取引文書と関連する目的を区別する。Payment_T
ype_Listing_YYYYMMDDとARPAdjustment_Type_Listingの記録における違いは、gl-cor:documentTypeを含めることによって、Payment_Type_Listing_YYYYMMDDの場合は支払の種別(例えば、小切手、その他の支払)、PR_Adjustment_Type_Listi
ng_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”

コメント[entriesType]は必須フィールドである。
[other]は列挙型の値である。

gl-cor: entriesComment

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

2.13 AP_Adjustment_Type_Listing_YYYYMMDD

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

AP_Adjustment_Type_Descriptio
n

1

TEXT

100

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

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

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

2.14 Supplier_Listing_YYYYMMDD

Supplier_Listing_YYYYMMDDファイルには、調査中の期間に生じる変更に対応するために、1回以上データが生成されることが求められる。ファイルが生成される日付はファイル名の一部として記録される。
フ ィフィールド名レ ベ フラットファイルXBRL GLタクソノミ要素
説明
ー ル
ル
データ
ド 番
データ型
長さ
号
1
Supplier_Account_ID
1
TEXT
100
gl-cor:identifierCode for 支払先の供給業者の識別子か、買掛internal # with gl-cor:id 計上先の供給業者の識別子。
entifierType = “vendor”
2
Supplier_Account_Name
1
TEXT
100
gl-cor:identifierDescript 供給業者の名前。
ion
3
Supplier_Group
2
TEXT
100
gl-cor:identifierCategory 組織によって供給業者をグループに区分する場合、この供給業者が区分されるグループ。
4
Supplier_Physical_Street_Addr 1
TEXT
100
gl-bus:identifierStreet
供給業者の住所の行1。
ess1(*) with glbus:identifier
AddressPurpose = “physical”
5Supplier_Physical_Street_Addr 1
TEXT
100
gl-bus:identifierAddressS 供給業者の住所の行2。
ess2
treet2*
6
Supplier_Physical_City
1
TEXT
100
gl-bus:identifierCity*供給業者が位置する都市。

フ ィフィールド名レ ベ フラットファイル
ー ル
ル
データ
ド 番
データ型 長さ
号
7
Supplier_Physical_State_Provi 1
TEXT
6
nce
8
Supplier_Physical_ZipPostalCo 1
TEXT
20
de
9
Supplier_Physical_Country
1
TEXT
3

10

Supplier_TIN

1

TEXT

100

11

Supplier_Billing_Address1

1

TEXT

100

12

Supplier_Billing_Address2

1

TEXT

100

13

Supplier_Billing_City

1

TEXT

100

14

Supplier_Billing_State_Provin
ce

1

TEXT

6

XBRL GLタクソノミ要素

説明

gl-bus:identifierStateOrP
rovince*gl-bus:identifierZipOrPos
talCode*gl-bus:identifierCountry*

供給業者が位置する国や都道府県。
ISO 3166-2を推奨。
供給業者が位置する都市の郵便番号。
供給業者が位置する国別コード。IS
O 3166-1アルファ2またはISO 31661アルファの3形式(XXまたはXXX)を推奨。
gl-cor:identifierAuthorit 供給業者の納税者番号。
yCode for tax #gl-bus:identifierStreet
供給業者の請求先住所1。
(**) with glbus:identifie
rAddressPurpose =“billing”
gl-bus:identifierAddressS 供給業者の請求先住所2。
treet2**gl-bus:identifierCity**
供給業者の請求先の都市。
gl-bus:identifierStateOrP 供給業者の請求先の国。ISO 3166-2
rovince**
を推奨。

15

1

TEXT

20

16

Supplier_Billing_ZipPostalCode
Supplier_Billing_Country

1

TEXT

3

17

Active_Date

2

DATE

18

Inactive_Date

2

DATE

19

Transaction_Credit_Limit

2

NUMERIC

20

Overall_Credit_Limit

2

NUMERIC

gl-bus:identifierZipOrPos 供給業者の請求先の郵便番号。
talCode**gl-bus:identifierCountry* 供給業者の請求先の国番号。ISO 31*
66-1アルファ2またはISO 3166-1ア
ルファの3形式(XXまたはXXX)を推奨。
XBRL GL uses gl供給業者がアクティブとなった日
cor:identifierActive to n 付。
ote that the supplier iscurrently active or inact
ive.
gl-cor:dateAcknowledged
gl-cor:confirmedDate

供給業が非アクティブとなった日付。
gl-muc:amountRestatedAmou 供給業者によって確立された請求書
nt
与信限度。
gl-cor:amount
供給業者に承認された合計未払残高に対する与信限度。

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

22

Terms_Discount_Days

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

NUMERIC

2

NUMERICXBRL GLタクソノミ要素

gl-cor:terms

説明

請求書の一定の日数前に支払われる
場合の供給業者が提示する割引率。
フラットファイルでは、小数点以下１桁として表現される(例えば、10％が10.0として表現される)。拡張
事業報告言語のXBRL GLタクソノミ
フレームワークにおいては、3つのフィールドTerms_Discount_Percent
age、Terms_Discount_DaysおよびTe
rms_Due_Daysの3つのフィールド
は、「xx.x％ dd Net dd」の形式で入力されることになる。例えば実質支払期間が30日で、10日以内に支払うと2％割引となる場合では「2％ 10 Net 30」で表現される。
See description for field 請求書日付からの日数は、供給業
number 8
者が割引を許可するために有利である。これは小数点以下がない桁数(例えば、nnn)として数字として表現される。

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

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

NUMERIC

24

Entered_By

1

TEXT

25

Entered_Date

2

DATE

26

Entered_Time

2

TIME

27

Approved_By

2

TEXT

フ ィ
ー ル

フィールド名100

100

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

XBRL GLタクソノミ要素

説明

See description for field
number 8; explicit in glcor: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 of glcor:enteredDate, ment
ioned previously.)
gl-cor:entryResponsiblePerson
XBRL GLタクソノミ要素

取引がシステムに入力された日付。
これは、時に作成日と呼ばれる。可能な場合、これは、(ユーザが入力した日付ではなく)システムで生成された日付にする必要がある。この日付は、必ずしも、実際の取引の日付に対応していない。
この取引をシステムに入力した時間。ISO 8601表記の24時間制の時
刻(HHMM)(例: PM1:00 = 1300)。
入力を承認した人の(User_Listing
ファイルの)ユーザID。
説明

ド 番
号
28 Approved_By_Date

データ型
2

DATE

長さ
gl-cor:confirmedDateRepeat(This is included in the
ISO 8601 representation of glusk:confirmedDateRepe
at, mentioned previously.)gl-bus:enteredByModified

入力が承認された日付。

29

Approved_By_Time

2

TIME

30

Last_Modified_By

2

TEXT

31

Last_Modified_Date

2

DATE

gl-usk:lastDateRepeat32

Last_Modified_Time

2

TIME

33

PrimaryContact_Name

2

TEXT

34

PrimaryContact_Phone

2

NUMERIC

35

PrimaryContact_Email

2

TEXT

(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

100

100

100

入力が承認された時間。ISO 8601表
記の24時間制の時刻(HHMM)(例: PM1:00 = 1300)。

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

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

内容

gl-cor:entriesType

value = “account”

gl-cor: entriesComment

value = “ads:Supplier_Listing_Y
YYYMMDD”

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

3.0 仕入・支払標準データプロファイルングレポート

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

説明

要求されたすべてのファイルおよびデータフィール
ドが提供されていることを確認する。

次の日付における最小値および最大値。
•

•

•

•

•

•

Purchase_Orders_YYYYMMDD_YYYYMMDD− Purchase_Order_Date− Entered_Date
Goods_Received_YYYYMMDD_YYYYMMDD− Transaction_Date− Entered_Date
Invoices_Received_YYYYMMDD_YYYYMMDD− Invoice_Date− Invoice_Due_Date− Entered_Date
Open_Accounts_Payables_YYYYMMDD、− Invoice_Date− Invoice_Due_Date
AP_Cash_Application_YYYYMMDD_YYYYMMDD− AP_Activity_Date− Entered_Date
Payments_Made_YYYYMMDD_YYYYMMDD••Control totals(コン
トロールト
ータル)− Payment_Date− Entered_Date
AP_Adjustments_YYYYMMDD_YYYYMMDD− Adjustment_Date− Entered_Date
Supplier_Listing_YYYYMMDD − Entered_Date

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

Purchase_Orders_YYYYMMDD_YYYYMMDD
Goods_Received_YYYYMMDD_YYYYMMDD
Invoices_Received_YYYYMMDD_YYYYMMDD
Open_Accounts_Payables_YYYYMMDD、
AP_Cash_Application_YYYYMMDD_YYYYMMDD
Payments_Made_YYYYMMDD_YYYYMMDD
AP_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.

すべての取引の時間フィールドは単一のタイムゾーンに正規化されているか。正規化されている場合、タイムゾーンは何か。