ACH Column Mapping Descriptions

The Universal Importer is a core component of all of Treasury Software applications.

Simply highlight the column you want imported, and then select the field type from the drop down box.

There are only three mandatory fields:
Amount (or substitute)
ACH_Account
ACH_Routing_ABA

Do not be intimidated by the long list below of column/field types. The other fields are for those who want additional functionality and control over their ACH file.

Field types (a.k.a. column mappings):
I. General Fields

I.a. Date - optional. If mapped, this date will become the effective date. If mapped and the date is invalid or missing, the record will not be imported.

If 'Date' is not mapped, the effective date will be the next day (default can be changed at 'File, 'ACH Setup').

I.b. Amount Fields
The sign of the amount is how the system determines whether it is collecting (Debit - typically customers), or sending (Credit - typically payroll, vendors) funds.

When importing transactions, either the Amount, Amount_Reverse_Sign or the Debit and Credit fields must be mapped.

I.b.1. Amount - Use when the amounts are properly signed, positive amounts representing collections from your customers, and negative amounts representing payments out to employees and vendors.

I.b.2. Amount_Reverse_Sign - In some cases, only one type of transaction is being sent through ACH Universal, such as vendor payments. However, the source file lists all of the amounts as positive. In these cases, you can map the 'Amount_Reverse_Sign' to flip the sign.

I.b.3. Debit/Credit - Many accounting systems prepare reports with a debit and credit column, rather than one 'Amount' column. Note: Amounts mapped as a debit will increase your cash balance (create Debit/Collection transactions), and amounts mapped as Credits will decrease your cash balance (create Credit/Payment transactions).

I.b.4. Sign - Some reports will contain an unsigned amount column with another field indicating it's sign, such as Debit/Credit, DR/CR, Inc/Dec, etc...

If this is your scenario, map the amount column as 'Amount', and the column containing the sign indicator as 'Sign'. In addition, you must specify the text representing debit and credit in the option settings (from the main menu, 'File', 'Options', 'General', 'Import' tab).

I.c. Filter - (optional) Used when importing records from a source file that contains information for more than one ACH Universal account. See How Do we Filter...

II. ACH Specific Columns
All of the fields below refer to the other party in the transaction, also called the 'recipient'. We use the term recipient, as you are the 'originator' of the transaction between your company and the Customer, Employee or Vendor. This applies to both your sending and collecting funds.

Of all of the fields below, only the first two are mandatory:
ACH_Account
ACH_Routing_ABA

If you choose to utilize any of the additional fields, they still do not need to be imported with each transaction. They can be stored in an ACH Universal profile - called a Customer, Employee, Vendor record.

II.a. ACH_Account - Account number. Mandatory.

II.b. ACH_Routing_ABA - 9 digit Routing/ABA number. This number identifies their bank. Mandatory.

II.c. ACH_Name_Internal (Look-up) - Name/title of their account within your records. Will appear in the text of the recipient's bank statement.

If ACH_Account and ACH_Routing_ABA are mapped, the system will import the data as is, and will not use the lookup feature.

If ACH_Account and ACH_Routing_ABA are not mapped, the system will look-up each name in against the profiles already created, and use the profile data. If there is no profile, the record is not imported.

II.d. ACH_ID_Internal - Their account number within your records, i.e. a vendor, customer or employee number. If mapped, this will appear in the text of the recipient's bank statement.

II.e. ACH_Email Address - Stores their email address in the local database. Not used in the ACH transmission process.

II.f. ACH_CheckingorSavings - ACH transactions use different codes based on whether the recipient's account is a checking or savings account. If mapped, use a 0 (zero) to indicate a checking account, and a 1 to indicate a savings account.

If not mapped, the system will use the default setting in 'File', 'ACH Setup'.

II.g. ACH_PPD0_CCD1_CTX2 - ACH transactions are 'batched' within a file, based on date, batch description and ACH application (PPD, CCD, CTX). If mapped, use a 0 (zero) to indicate PPD, a 1 to indicate CCD, and a 2 to indicate CTX.

If not mapped, the system will use the default setting in 'File', 'ACH Setup'.

For a description of PPD, CCD, and CTX.

II.h. ACH_PreNoteDRCR - For future development.

II.i. ACH_CEV_Ext0_Int1_Orig2 - Used when importing Corporate Transfer Accounts and Customer, Employee and Vendor Accounts.
Valid field values:
0 (default) - Customer, Employee and Vendor Account
1 - Corporate Transfer Account - Corporate Controlled Account (unlimited number of accounts)
2 - Corporate Transfer Account - 'Master' Account - represents the ACH enabled account (only one account).

The above fields were all related to the recipient. The following fields are related to the transaction, and as such, cannot be stored within the Customer, Employee, and Vendor profile.

II.j. ACH_Text_Addenda - Used to pass additional descriptive data through the ACH system to the recipient. Creates 'addenda' records, and will be placed in positions 4 - 83 of the addenda records (#7).

Notes:
--As PPD and CCD are limited to one addenda record per ACH standards, only the first 80 characters will be used.
--CTX can accommodate up to 9,999 addenda records, which exceeds the capacity of this field. For full CTX functionality, use CTX specific fields.

II.k. CTX_Invoice - Used in CTX addenda records. For full CTX functionality, please contact our licensing department for additional information.

II.l. CTX_DiscountTaken - Used in CTX addenda records. For full CTX functionality, please contact our licensing department for additional information.