When importing general ledger transactions from a CSV or Excel file, you must map fields, so the transactions data displays properly in the engagement. In addition, certain fields are consistent across lines within an entry.
This topic describes the fields within the TRANSACTION DETAILS category that appear in the General ledger dataset.
Note: that some fields are mandatory for specific analytic tests to function properly. Refer to the descriptions below.
entry_number)Sequential identifier that is unique to each journal entry.
If Entry ID is not assigned, there must be no blank Entry Number cells.
If Entry ID is assigned, only the first entry number value for each unique Entry ID will be imported.
amount)Amount of the transaction line. This can be a positive value for a debit and negative for a credit.
Data reconciliation/completeness
In these analytic tests:
Duplicate detection
Recurring numeric pattern
High amounts
Rounded values
detail_comment)Description of the line entry.
In these analytic tests:
Missing information
Keywords
posting_date)Effective date - data entry was posted (validated) to the general ledger, regardless of the date created.
Duplicates
Date entries
To be viewed in the transactions list, transactions must be within fiscal-year range as set within the engagement.
Date format must be properly set:
posting_status)Indicates whether the entry has been posted or not posted.
non-posted are not used for calculating the sum of transactions for data completeness checks. posted are used in analytic tests. To learn more, see View analytic test results for checklists.
Less than 2,500 unique values. These values must be tagged to one of:
Posted
Non-posted
document_type)Enumerated field describing the original source document, with check, debit-memo, credit-memo, finance-charge, invoice, order-customer, order-vendor, payment-other, reminder, tegata, voucher, shipment, receipt, manual-adjustment, other.
document_type values below: