August 2013

Audit Data Standards

General Ledger
Standard

AuditDataStandards.GL.August2013

Prepared by the AICPA Assurance Services Executive Committee

Emerging Assurance Technologies Task Force

aicpa.org/FRC

Permission to utilize, copy, distribute and/or transmit the Work (including the right to make commercial use thereof) is permitted, as
long as an attribution statement substantially in the following form is prominently included within your product or material:
Copyright 2013 by American Institute of Certified Public Accountants, Inc. (AICPA). All rights reserved. Used with permission.
Any such utilization is further conditioned upon there being no suggestion that AICPA endorses either the person, firm or other
entity utilizing the Work or the actual use being made of the Work. No derivative rights are included within or by this grant of
permission. To inquire about additional permission issues or to utilize the Work in any other fashion, contact AICPAs Permissions
Team: copyright@aicpa.org.

Page 2 of 25

Assurance Services Executive Committee (20122013)

William R. Titera, Chair
Dorsey Baskin
Greg Bedard
Robert Dohrer
Glenn Galfond
Theresa Grafenstine
Charles Harris

Chris Kradjan
Mark Mayberry
Fain McDaniel
Beth Schneider
Leslie Thompson
Miklos Vasarhelyi

Emerging Assurance Technologies Task Force

Audit Data Standard Working Group
William R. Titera, Chair
Glenn Galfond, Lead
Paul Barbour
Karl Busch
Thomas Duncan
Charles Harris

Kristine Hasenstab
Steven Henchock
Mark Mayberry
Phillip McCollough
Joel Pinkus
Miklos Vasarhelyi

Additional Contributors
Eric E. Cohen
D.J. Elmore

Gianluca Garbellotto
Fain McDaniel

AICPA Staff
Amy Pawlicki
Director
Business Reporting, Assurance and Advisory
Services

Dorothy McQuilken
Manager
Business Reporting, Assurance and Advisory
Services

Page 3 of 25

Audit Data Standards

The benefits of standardization are well-recognized and have led to the development of various general IT
standards. One reason data standards are needed is to address the ongoing challenge that management and
internal and external auditors face in the efficient exchange of a companys data. This process is complicated by
the fact that accounting and IT personnel approach requests for such information from different perspectives.
For example, in some cases, audit-related data requests are forwarded directly to a companys1 IT department,
with limited further involvement from the accounting or finance department. In many cases, the burden is on the
auditors to acquire the data.
The AICPA Assurance Services Executive Committee believes that audit data standards (ADSs) will contribute
to the efficiency and effectiveness of the audit process through standardization of the format for fields and files
commonly requested for audit and other related purposes. Similarly, other consumers of the standardized
information (such as creditors) also would benefit if a company chose to share that data with them. Companies
large and small, public and private, also stand to benefit from the application of the ADSs. By standardizing the
data requested by auditors on a regular basis, companies will be able to automate and replicate the information
request process, thereby reducing the amount of time and effort required to provide the requested data.
Company staff and internal audit will also benefit from enhanced analytical capabilities by leveraging the
standardized data for internal purposes. The standard also will make the data usable for external auditors to
perform enhanced data analysis.
These standards represent leading practices that well-designed accounting and financial reporting systems are
capable of adhering to. This publication addresses the general ledger (GL).
ADSs address both the technical design (files, tables, fields, formats, and so on) and supplemental questions
about the data that are essential for an understanding of its use. The former generally is best addressed though
IT systems design and the latter is commonly provided by accounting or finance personnel, with input from IT
personnel. Please note that these are voluntary, recommended data standards for the extraction of information.
These data extract standards are not required, nor do they represent authoritative audit or accounting standards.
Recognizing the value of uniformity and the benefits of individual adaptation, particularly for companies of
varying sizes and industry characteristics, these standards provide some degree of flexibility. This is a minimum
standard and is not meant to be limiting, so users may create customized, user-defined fields (for example, items
should not be subtracted, but they may be added where they do not already exist in the standard). However, to
achieve the benefits of standardization (when not specifically indicated), individual customization should be
avoided (in other words if an item is defined in the standard, do not redefine it). Once a company adopts a
particular convention, it should consistently export its data according to that convention, unless a major IT
system conversion is undertaken or the producers and consumers of the standardized data mutually agree on an
expansion, or both.
Companies implementing the ADSs should first contact their enterprise resource planning (ERP) or accounting
package vendor for assistance. If the vendor does not have a solution for adopting the ADSs, extract, transform,
load (or ETL) vendors have developed scripts that can be used to map to the ADSs.

Please note that the term company is meant to represent companies, partnerships, government agencies, not-for-profit entities, and so
on, and is not limited to commercial entities.

Page 4 of 25

Prior to implementing this data standard, an evaluation should be made of the reliability of the data through the
use of controls and segregation of duties testing. Guidance for these types of evaluation criteria is available at
aicpa.org.
Additional detail on the contents of each section follows. The following figure provides a data diagram that
shows the relationship between tables in the current standard. It is important to note that the GL ADS should be
used in conjunction with the base standard document located on the aicpa.org website.

Data Relationships Among Tables in the Audit Data Standards

General Ledger

GL_Detail_YYYYMM
DD_YYYYMMDD

GL_Account_Number,
GL_Subaccount_Number

Source

Business_Unit

Segment01, ...,
Segment05

Chart_Of_Accounts
_YYYYMMDD

GL_Account_Number,
GL_Subaccount_Number

Trial_Balance_YYYY
MMDD

Source_Listing_YYY
YMMDD

Business_Unit_Listi
ng

Segment01_Listing

Segment05_Listing

User_ID*
User_Listing

Business_Unit

Segment01, ...,
Segment05

Legend
Table in GL Standard
Table in Base Standard

* The User_Listing table can be joined to three fields, all of which contain a user ID: User_ID, Approved_By, Last_Modified_By

Page 5 of 25

1. General Ledger Standard

GL standard audit data is defined with multiple tables containing related information. The Level column
within each table has a label of either 1 or 2 to indicate the importance of the data. Level 1items are required
(when available through IT systems or additional means). The level 2 items are recommended, but may not
always be available. The client should specify those fields that are not available.
Following the standardized data is a data profiling report and questionnaire that should be used to further
describe the data, accounting processes, and financial IT systems.
GL Standardized Data

GL_Detail

Trial_Balance

Chart_Of_Accounts

Source_Listing

GL Standard Data Profiling Report

GL Questionnaire

Page 6 of 25

1.1 GL_Detail_YYYYMMDD_YYYYMMDD
The GL_Detail table stores all the journal entry lines and includes all the journal entry header information as well. Each row in this table contains
detailed information for transactions on each journal entry, such as the associated journal entry ID, the associated account number, and the debits or
credits associated with the journal entry line. The file should be at the journal entry line level (not a more summarized level).

Journal_ID

Flat File Data

XBRL GL Taxonomy
Element2
DataType Length3
TEXT
100 gl-cor:entryNumber

Journal_ID_Line_Number

TEXT

100 gl-cor:lineNumber

JE_Header_Description

TEXT

256 gl-cor:entryComment

JE_Line_Description

TEXT

256 gl-cor:detailComment

Source

TEXT

Field #

Field Name

Level

25 gl-cor:SourceJournalID
(fixed/enumerated list) or
gl-cor:
sourceJournalDescription
(free form)

Description
Identifier that is unique for each
journal entry. May require
concatenation of multiple fields.
Identifier that is unique for each line
within a journal entry.
Description of the entire journal entry
as described by the journal entry
header.
Description of the individual line
within the journal entry.
Posting source (code for source from
which the journal entry originated,
such as sales journal, cash receipts
journal, general journal, payroll
journal, accountant manual entry,
spreadsheet, and so on).

Taken from entry point of XML schema file gl-plt-2006-10-25.xsd found in the subdirectory \plt\case-c-b-m-u-t of the extensible business reporting language global ledger
taxonomy framework (or XBRL GL) file structure; this should be used for the schemaLocation and schemaRef, although alternatives may be used if required. User should use the
most current recommended version available, unless agreement on a later draft is made and beneficial.
3

Throughout the document, this column represents a suggested maximum length.

Page 7 of 25

Field #

Field Name

Level

Business_Unit_Code

Fiscal_Year

Period

Flat File Data

XBRL GL Taxonomy
Description
3
Element2
DataType Length
TEXT
25 gl-cor:accountSubID with gl- Used to identify the business unit,
cor:accountSubType of
region, branch, and so on at the level
Business_Unit
that financial statements are being
audited and for which the trial balance
is generated. For example, you may
use a code aligned with the concept of
a reportable segment as defined in
Financial Accounting Standards Board
(FASB) Accounting Standards
Codification (ASC) 280, Segment
Reporting.
TEXT
4 gl-bus:fiscalYearEnd
Fiscal yearYYYY for delimited,
CCYY-MM-DD fiscal year end (ISO
8601) for extensible business reporting
language global ledger taxonomy
framework (XBRL GL).
TEXT
10 gl-bus:postingCode
Code for posting to period (for
example, one period per month, period
113 in which period 13 represents
fiscal year closing entries, 445 in
which each number represents the
number of weeks per period in a
quarter, and so on) based on codes in
an accounting period file. Examples
include W1W53, M1M13, and Q1
Q4.

Page 8 of 25

Effective_Date

Flat File Data

XBRL GL Taxonomy
3
Element2
DataType Length
DATE
gl-cor:postingDate

10

Entry_Date

DATE

11

User_ID

TEXT

100 gl-cor:enteredBy

12

GL_Account_Number4

TEXT

100 gl-cor:accountMainID

Field #

Field Name

Level

gl-cor:enteredDate

Account_Number may include alphanumeric characters.

Page 9 of 25

Description
The date of the journal entry, no
matter what date the entry is received
or entered. This is sometimes referred
to as the accounting date or accounting
effective date. For example, if the user
wants to see the financial results for
the period ending March 5, 20X1, the
journal entry can be created on any
day during the open period and be
assigned to the period ending March 5,
20X1.
Date the journal entry was entered into
the system. This is sometimes referred
to as the creation date. This should be
a system-generated date (rather than
user-entered date), when possible. This
date does not necessarily correspond
with the date when the journal entry
was posted to the GL or the period-end
date.
User ID, initials, or name of operator
originally submitting the entry.
Identifier for the GL financial account.
The GL_Account_Number in this file
must match the GL_Account_Number
used in the Trial_Balance and
Chart_Of_Accounts files.

Field #

Field Name

Level

Flat File Data

XBRL GL Taxonomy
3
Element2
DataType Length
NUMER
gl-cor:amount
IC

13

Amount

14

Amount_Credit_Debit_Indicator

TEXT

1 gl-cor:debitCreditCode

15

Amount_Currency

TEXT

3 gl-muc:amountCurrency

16

Last_Modified_Date

DATE

gl-usk:lastDateRepeat

17

Last_Modified_By

TEXT

50 gl-bus:
enteredByModified

18
19

Approved_Date
Approved_By

2
2

DATE
TEXT

20

EntryDate_Time

TIME

21

Reporting_Amount

NUMER
IC

22

Reporting_Amount_Currency

TEXT

gl-usk:nextDateRepeat
50 gl-cor:
entryResponsiblePerson
gl-cor:enteredDate
(both date and time are
provided within the same
field)
glcor:amountTriangulationAm
ount
3 glmuc:amountTriangulationCu
rrency

23

Local_Amount

NUMER
IC

gl-muc:
amountOriginalAmount
Page 10 of 25

Description
Transaction monetary amount
recorded in the functional or group
currency for the entity under audit. No
multicurrency translation should need
to be performed on this amount
because all transactions are recorded in
a single currency.
Indicates whether the amount is a
credit or debit. C=credit; D=debit.
The functional or group currency
related to the amount. See ISO 4217
coding.
The date the entry was last modified
before posting.
User ID, initials, or name of last
person modifying this entry before
posting.
The date the entry was approved.
User ID, initials, or name of person
who approved the entry.
The time the journal entry was entered
into the GL.

The amount recorded in the currency

in which a reporting entity prepares its
financial statements.
The currency which a reporting entity
prepares its financial statements (for
example, USD, EUR; see ISO 4217
coding).
Amount in the local country currency
where the transaction originated.

Field #

Field Name

Level

Flat File Data

XBRL GL Taxonomy
3
Element2
DataType Length
TEXT
3 gl-muc:
amountOriginalCurrency

24

Local_Amount_Currency

25

Reversal_Indicator

TEXT

26

Reversal_Journal_ID

TEXT

27

Segment01

TEXT

28
29
30

Segment02
Segment03
Segment04

2
2
2

TEXT
TEXT
TEXT

1 gl-usk:reverse
true = entry is to be reversed
false with glusk:reversingDate =
provided = entry is a reversal
not provided = none of the
above.

100 gl-usk:reversingStdId

25 XBRL GL tracks
hierarchy ID, hierarchy
description, and hierarchy
type, so it can track code
NA, description N. America,
and type global area using
gl-cor:accountSubID, glcor:accountSubDescription,
and gl-cor:accountSubType,
respectively.
Interrelations and hierarchies
are captured by glcor:parentSubAccountType
(what is the hierarchy type
this unit rolls up to).
25 Same as above.
25 Same as above.
25 Same as above.
Page 11 of 25

Description
The currency used for local country
reporting requirements (for example,
USD, EUR; see ISO 4217 coding).
Indicates whether this entry is a
reversal or to be reversed. 1=entry is
a reversal, 2=entry is to be reversed,
and empty ()=none of the above or
system generated indicators. For
XBRL GL, this is a Boolean, in which
true indicates it is to be reversed;
false with provision of a
reversingDate indicates the entry is a
reversal.
When the Reversal_Indicator=1, this
identifies the Journal_ID of the entry
being reversed.
Reserved segment field that can be
used for profit center, division, fund,
program, branch, project, and so on.

Same as above.
Same as above.
Same as above.

Field #
31

Field Name

Level
2

Segment05

Flat File Data

XBRL GL Taxonomy
3
Element2
DataType Length
TEXT
25 Same as above.

Description
Same as above.

Additional Comment for XBRL GL:

1. gl-cor:sourceJournalID is an enumerated list, promoting clearer understanding of the following:
cdcash disbursements (sending checks to vendors)
crcash receipts (receiving checks from others)
fafixed assets
gigiro or other bank adjustments
gjgeneral journal
iminventory management
jcjob cost
pjpurchase journal (liabilities from purchases)
plpayroll or journal
sjsales journal
sestandard entries
uduser defined
otother sources of entries
For a GL detail listing, additional required or recommended fields include the following.
Element
gl-cor:entriesType

gl-cor: entriesComment

Content
value = journal or entries

Comment
[Entries] is used for a broad list of accounting journal
entries; an enumerated value [journal] is used for a list of
like entries when debits explicitly equal credits.
value =
[entriesComment] is the descriptive field describing what
ads:GL_Detail_YYYYMMDD_YYYYMMDD is common in the collection of information; introducing
audit data standard namespace and qualifier for type of
collection ties it to this representation.

Page 12 of 25

1.2 Trial_Balance_YYYYMMDD
The Trial_Balance table stores all the ledger account balance information. The Trial_Balance file should contain the ending balances at a point in
time. The Trial_Balance should be created at the same time as the GL_Detail to prevent differences in transactions and balances.
Field #

Field Name

Level

GL_Account_Number

Fiscal_Year

Period

Balance_AsOf_Date

Amount_Ending

Flat File Data

XBRL GL Taxonomy Element
Description
DataType Length
TEXT
100 gl-cor:accountMainID
Identifier for the GL financial account.
The GL_Account_Number in this file
must match the GL_Account_Number
used in the GL_Detail and
Chart_Of_Accounts files.
TEXT
4 gl-bus:fiscalYearEnd - ccyyFiscal yearYYYY. For XBRL GL
mm-dd
use the full fiscalYearEnd
TEXT
10 gl-bus:postingCode
Accounting period number. Code for
posting to period (for example, period
113) based on codes in an accounting
period file. Possibilities include W1
W53, M1M13, and Q1Q4.
DATE
A common end-of date is noted Date of the provided balance, not
by gl-cor:periodCoveredEnd;
when the Trial_Balance file was
mixed period end dates could
created (for example, 20X01231 if
be noted by gl-cor:postingDate year-end balance, even if the report
was run on 20X10122).
NUME
gl-cor:amount with optional gl- Period ending balance amount
RIC
cor:xbrlInclude =
recorded in the functional or group
{ending_balance}
currency. No multicurrency translation
should need to be performed on this
amount because all are recorded in a
single currency.

Page 13 of 25

Field #

Field Name

Level

Flat File Data

XBRL GL Taxonomy Element
DataType Length
NUME
XBRL GL does not have
RIC
separate beginning and ending
amounts on a line. This would
use a second line, with optional
gl-cor:xbrlInclude =
{beginning_balance} and glcor:periodCoveredStart
NUME
glRIC
muc:amountOriginalTriangulati
onAmount with glcor:xbrlInclude =
{beginning_balance}
NUME
gl-muc:amountOriginalAmount
RIC
with gl-cor:xbrlInclude =
{beginning_balance}
TEXT
3 gl-muc:amountCurrency

Amount_Beginning

Amount_Beginning_Reporting

Amount_Beginning_Local

Amount_Currency

10

Business_Unit_Code

TEXT

11

Amount_Ending_Reporting

NUME
RIC

12

Amount_Reporting_Currency

TEXT

25 gl-cor:accountSubID with glcor:accountSubType of

Business_Unit

glmuc:amountOriginalTriangulati
onAmount
3 glmuc:amountOriginalTrangulati
onAmountCurrency

Page 14 of 25

Description
Period beginning balance amount (that
is, the ending balance from the prior
period) recorded in the functional or
group currency. No multicurrency
translation should need to be
performed on this amount because all
are recorded in a single currency.
Period beginning balance amount in
reporting currency used for statutory
reporting.

Period beginning balance amount in

the local country currency for
multicurrency tracking.
The functional or group currency
related to the balance. See ISO 4217
coding.
Used to identify the business unit,
region, branch, and so on at the level
that financial statements are being
audited and for which the trial balance
is generated. For example, you may
use a description aligned with the
concept of a reportable segment as
defined in FASB ASC 280.
Period ending balance amount in
reporting currency used for statutory
reporting.
The currency used for
nonconsolidated reporting as opposed
to functional or consolidated reporting
or local or actual amounts. See ISO
4217 coding.

Field #

Field Name

Level

13

Amount_Ending_Local

14

Amount_Local_Currency

15

Segment01

16
17
18
19

Segment02
Segment03
Segment04
Segment05

2
2
2
2

Flat File Data

XBRL GL Taxonomy Element
Description
DataType Length
NUME
gl-muc:amountOriginalAmount Period ending balance amount in the
RIC
local country currency for
multicurrency tracking.
TEXT
3 glThe currency used for local country
muc:amountOriginalCurrency
reporting requirements. See ISO 4217
coding.
TEXT
25 gl-cor:accountSubID associated Reserved segment field that can be
with the gl-cor:accountSubType used for profit center, division, fund,
as defined in the
program, branch, project, and so on.
Segment_Listing.
(Note: XBRL GL tracks
hierarchy ID, hierarchy
description, and hierarchy type,
so it can track code NA,
description N. America, and
type global area using
gl-cor:accountSubID, glcor:accountSubDescription, and
gl-cor:accountSubType,
respectively.)
TEXT
TEXT
TEXT
TEXT

25
25
25
25

Same as above.
Same as above.
Same as above.
Same as above.

Same as above.
Same as above.
Same as above.
Same as above.

Additional Comment for XBRL GL:

Trial balances are rarely beginning and ending of period alone. They are more often beginning, period change (often period debits and separate
period credits), and ending.

Page 15 of 25

For a trial balance listing, additional required or recommended fields include the following.
Element
gl-cor:entriesType
gl-cor: entriesComment

Content
value = trialbalance

Comment
Explicitly defines this as a trial balance, as per XBRL
GLs standard enumerations.
value =
[entriesComment] is the descriptive field describing what
ads:Trial_Balance_YYYYMMDD is common in the collection of information; introducing
audit data standard namespace and qualifier for type of
collection ties it to this representation.

Page 16 of 25

1.3 Chart_Of_Accounts
The chart of accounts table is used to store the information about all the GL accounts, including name, description, and mapping to the financial
statement captions. If different charts of accounts are needed for different business units, business unit fields should be utilized to distinguish
between the local and consolidating sets of accounts.
Field #

Field Name

Level

Flat File Data

XBRL GL Taxonomy Element
DataType Length
TEXT
100 gl-cor:accountMainID

GL_Account_Number

2
3

GL_Account_Name
Account_Type

1
1

TEXT
TEXT

Account_Subtype

TEXT

FS_Caption

TEXT

100

GL_Account_Description

TEXT

256 gl-cor:accountTypeDescription

100 gl-cor:accountMainDescription
25 gl-cor:mainAccountType

25 glcor:mainAccountTypeDescription

gl-cor:summaryReportingElement

Page 17 of 25

Description
Identifier for the GL financial
account. The
GL_Account_Number in this file
must match the
GL_Account_Number used in the
GL_Detail and Trial_Balance
files.
Name for the GL account.
Grouping for high-level category
on the financial statements. Values
should be assets, liabilities, equity,
revenue, expenses, and so on.
Grouping for lower-level
categories on the financial
statements. Examples include
reserve account, suspense account,
intercompany account, and so on.
Financial statement caption.
Grouping for the caption the GL
account rolls up to on the financial
statements (for example, cash and
cash equivalents, accounts
payable, cost of sales, and so on).
Sometimes may prefer to be at the
trial balance level.
Label or description associated
with GL_Account_Number.

Field #

Field Name

Level

Flat File Data

XBRL GL Taxonomy Element
DataType Length
TEXT
25 gl-cor:accountSubID with glcor:accountSubType of
Business_Unit

Business_Unit_Code

Parent_GL_Account_Number

TEXT

Segment01

TEXT

25 gl-cor:accountSubID associated
with gl-cor:accountSubType from
Segment_Table
(Note: XBRL GL tracks
hierarchy ID, hierarchy description,
and hierarchy type, so it can track
code NA, description N. America,
and type global area using
gl-cor:accountSubID, glcor:accountSubDescription, and glcor:accountSubType, respectively.)

10
11
12
13

Segment02
Segment03
Segment04
Segment05

2
2
2
2

TEXT
TEXT
TEXT
TEXT

25
25
25
25

100 gl-cor:parentAccountMainID

Same as above.
Same as above.
Same as above.
Same as above.

Page 18 of 25

Description
Used to identify the business unit,
region, branch, and so on at the
level that financial statements are
being audited and for which the
trial balance is generated. For
example, you may use a
description aligned with the
concept of a reportable segment as
defined in FASB ASC 280.
A reference to the
GL_Account_Number that is the
parent in an account hierarchy.
Provided to allow more than the
predefined levels of hierarchy in
the chart of accounts table.
Reserved segment field that can be
used for profit center, division,
fund, program, branch, project,
and so on.

Same as above.
Same as above.
Same as above.
Same as above.

Additional Comment for XBRL GL:

For a chart of accounts listing, additional required or recommended fields include the following.
Element
gl-cor:entriesType

Content
value = account

gl-cor: entriesComment

value = ads:Chart_Of_Accounts

Comment
Explicitly defines this as a listing of accounts, as per
XBRL GLs enumerations.
[entriesComment] is the descriptive field describing what
is common in the collection of information; introducing
audit data standard namespace and qualifier for type of
collection ties it to this representation.

Page 19 of 25

1.4 Source_Listing
The source code listing provides additional information about the sources provided in the GL_Detail file. Each source should have a description,
which ERP module or subledger it originates in, along with information relating to the business process it is a part of.
Field #

Field Name

Level

Flat File Data

XBRL GL Taxonomy Element
DataType Length
TEXT
25 gl-cor:sourceJournalID if an
enumerated set is feasible;
gl-cor:sourceJournalDescription
otherwise.

Source

Source_Description

TEXT

100 gl-bus:batchDescription if glcor:sourceJournalDescription is

used above.

ERP_Subledger_Module

TEXT

100 gl-bus:measurableDescription

System_Manual_Identifier

TEXT

Business_Process_Major

TEXT

1 gl-bus: entryOrigin

100 glbus:measurableCodeDescription
Page 20 of 25

Description
Posting source (code for source from
which the journal entry originated,
such as sales journal, cash receipts
journal, general journal, payroll
journal, accountant manual entry,
spreadsheet, and so on). The code
must be a unique indication for the
underlying source.
Must match the source field in the
GL_Detail file.
A plain English description of the
source. Some of the more common
journals are purchases, sales, cash
receipts, cash disbursements, and
general journal.
Description of the subledger or ERP
module the journal entry originated
from. Should tie back to a system or
significant accounting process. In
some instances, may be represented
by source.
Define if the source creates systemgenerated or manually entered
journal entries. Provide an S or
M for the value.
The major class of transaction
associated with a business process
(for example, sales).

Field #
6

Field Name

Level
2

Business_Process_Minor

Flat File Data

XBRL GL Taxonomy Element
DataType Length
TEXT
100 gl-bus:measurableCodeCategory

Description
A subprocess of the major business
process (for example, orders, returns,
discounts, and so on).

Additional Comment for XBRL GL:

For a source listing, additional required or recommended fields include the following:
Element
gl-cor:entriesType

Content
value = other

gl-cor:entriesComment

value = ads:Source_Listing

Comment
[entriesType] is a mandatory field; [other] is an
enumerated value.
[entriesComment] is the descriptive field describing what
is common in the collection of information; introducing
audit data standard namespace and qualifier for type of
collection ties it to this representation.

Page 21 of 25

1.5 GL Standard Data Profiling Report

For each set of data that is extracted from ERP or the GL, the following tests should be performed by the data
provider and independently confirmed by the auditor. Validation should be performed for each period for which
the data is requested. The data validation should include the following:
Test
Date and Control Totals
Required files
Date ranges

Control totals

Description
Confirm all requested files and data fields have been provided.
Minimum and maximum dates for Entry_Date (GL_Detail).
Minimum and maximum dates for Effective_Date (GL_Detail).
Minimum and maximum dates for Effective_Date with each period for the
data provided (GL_Detail).
Line item count, sum of total debits, sum of total credits, and total sum of
amount (GL_Detail).
GL account count and total sum of balance amount (Trial_Balance).

JE and TB review
Missing data
Invalid data

Number of missing or blank values listed by field.

Count of records by field that do not comply with field format requirements
(for example, date or time fields not compliant with date or time format,
numeric fields not including two decimal places, and so on).
Nonbalancing entries
Count and percentage of journal entries that do not balance to $0.
Nonbalancing sources
From GL_Detail, the count of records and total of amount by source.
Accounts missing from TB Count and total of amount by GL_Account_Number for GL accounts that are
found in the GL_Detail but not in the Trial_Balance.
Completeness/Financial Statement Roll-Forward
Account roll-forward
Roll forward all accounts from the beginning of the fiscal year to the end of
the period (that is, for each GL_Account_Number, the Amount_Beginning
[from Trial_Balance], total of Amount [from GL_Detail], Amount_Ending
[from Trial_Balance], and the difference between the Amount_Ending and
sum of Amount_Begining and total amount).

Page 22 of 25

1.6 GL Questionnaire
The following information is integral to the understanding and use of the companys IT data. A companys
financial management, in consultation with its IT personnel, should address each of the items each time data is
provided, if applicable. These questions are not intended to be all-inclusive and are presented as examples only.
Prior to implementing the use this data standard, an evaluation should be made of the reliability of the system
data through the use of controls and segregation of duties testing, which are not covered by this questionnaire.

GL
1. Is there an implicit structure for creating a unique Journal_ID field (for example, is it a
concatenation of two or more other fields)? If so, what is the structure?
2. When are journal entries recognized in the financial statements (for example, when entered, when
approved, and so on)?
3. Does the unique account number sequence capture classifications such as business units,
subaccounts, and so on (account flexfield)? If so, describe the account number sequence.
4. How are related-party transactions identified (for example, transactions with wholly or partially
owned subsidiaries)?
5. Do separate GL systems (for example, instances within ERP or multiple GL or ERP installations)
need to be considered when analyzing the data? How are various ledgers in the data differentiated?
6. Which GL system(s) is (are) this data extraction from? Provide documentation for the data
extraction (for example, identify ERP program used or provide SQL code for custom query).
6.1 How many applications or posting sources, including spreadsheets, are supporting the GL
across all business units?
6.2 What are the types and names (application = ERP Module, subledger, or other source of
entries into the GL)?
6.3 What type of applications are used in the consolidation process and how do they relate to the
underlying company ledgers and subledgers?
6.4 What is the process for handling eliminations, and is it replicated in the ERP system?
7. What is the process for financial statement consolidation? Are the financial statements
systematically consolidated? If so, describe the process.
8. If ERP is used for consolidation purposes, at what point in the financial reporting process is
consolidation performed: daily, monthly, or quarterly?
9. Are top-side entries made when consolidating and preparing the financial statements? How are these
captured, and how are they incorporated into the GL or ERP?
10. Are reversal entries entered manually, or is it an automated process?
Page 23 of 25

11. Are there transactions in the data that are not related to the financial statements (for example, memo
entries)? If so, how are they identified?
12. How did you use GL Account_Type and Account_Subtype?
13. Is any nonfinancial data included and, if so, how can it be identified?
14. How does the application define a manual versus an automated journal entry? Describe the
transaction criteria that distinguish a standard transaction from a nonstandard transaction.
15. How is currency conversion handled?
16. How is currency identified within the application?
17. Do foreign currency transaction records contain both the local (native) currency and amount and the
reporting (home) currency amount? If so, when is foreign currency translated into the parent or
consolidated (functional) GL currency (monthly, daily, and so on)?
18. Does the system allow the posting of unbalanced entries? If so, what are the reasons for unbalanced
entries in this data submission, and how are journal entries that dont balance to zero handled?
19. Does the application allow one-sided journal entries? If so, under what circumstances are these
types of entries allowed?
20. Does the GL allow individual transactions to exist in the system as header information without the
associated detail information? If so, are these entries flagged and identified for further evaluation?
21. Can a user post a journal entry to a prior closed period? Under what circumstances is the backposting of entries allowed? Does the system identify or track back-posting of entries?
22. Can a journal entry identifier number be reused within the GL? If so, what makes a journal entry
number unique?
23. How often are entries posted to the GL (real-time or batch process)? If posted via a batch process,
what is the posting schedule?
24. How are journal entries from business units or segments posted to the system? Are they summarized
or posted in detail?
25. How are times recorded for journal entries (East Coast time, GMT, and the like)?

User and Business Unit Administration

26. How are manual entry approvals handled? Is it a paper-based process, or is the approval process
built into the GL system?
27. How are journal entries reviewed? Is there a policy regarding required levels of review depending
on the dollar amount of the journal entry? Is this process built into the system or is it a manual
process?
28. Who are the authorized users who can create, modify, and approve manual journal entries
(including spreadsheet and MS Access uploads and so on)? Please provide a list of these users.
Page 24 of 25

29. Is batch uploading of manual journal entries allowed or used?

30. When providing extracted GL data, are the number of line items and the sum of amounts generated
manually or by the application used to extract the data?

Page 25 of 25