Need to compare files? Our products offer more value than the competition, and are trusted by more than 75% of the top-20 financial institutions in North America. Connect with us at sales@x9ware.com and start a free evaluation today.

Convert X9<->ACH

Convert is a generalized tool which converts:

  • X9 files to ACH
  • ACH files to X9.37

Convert works in a manner similar to Make, where Convert will format logical items that are then routed into our Generate processor. This flow provides greater customization of the output file, since Generate allows you to describe how the header/trailer records are to be populated, batching instructions, and various other attributes that control output file construction.

Convert X9.37 to ACH

In this mode, Convert is used to create a new ACH file from the currently loaded X9.37 file. A user selected standard entry class is used to build the new ACH file. This includes the various entry classes that represent checks (ARC, BOC, POP, RCK, TRC, and XCK) as well as some more generic entry classes which may provide utility within the user environment (CCD and PPD).

The following fields must be entered for the X9 to ACH conversion:

  • Debit transaction code: defines the transaction code to be assigned to debits.
  • Credit transaction code: defines the transaction code to be assigned to credits.
  • Identification number: defines data that is assigned to ACH field 6.7. This value will be automatically assigned from the check serial number for standard entry classes of ARC, BOC, POP, and RCK. Other entry classes allow you to explicitly assign the value to be used. When a value is not entered and has no default, it will otherwise be assigned from the check serial number.
  • Receiver information: defines data that is assigned to ACH field 6.8. This value will be automatically assigned from the process control field and the item sequence number for standard entry classes of TRC and XCK. Other entry classes allow you to explicitly assign the value to be used. When a value is not entered and has no default, it will otherwise be assigned from the trc/xck  process control and item sequence number format.
  • Discretionary data: is an optional two character field that is assigned to ACH field 6.9.
  • Starting sequence number: is a seven (7) digit number that is used to sequentially assign the trace number for the created items, which is populated into ACH field 6.11. The overall trace number is 15 digits and consists of the 8 digit ODFI routing number which is suffixed by this sequence number. On a default basis, this starting sequence number is “DD00000” where DD is a variation taken from Julian day within the current year. However, this default would not be appropriate for large files and when multiple conversions are done within the same day. In those situations, the user must provide the starting sequence number which guarantees the trace number to be unique.

These various parameters will be written to user preferences at the end of the current user session, allowing them to be easily restored and reused in your next session.

Standard Entry Classes

The ACH file format has certain standard entry classes which represent a paper check item, and those formats are especially appropriate for these actions. These are ARC, BOC, POP, RCK, and TRX. Additionally, we support CCD and PPD since they are common layouts; these may be used for data exchange within an organization, but should not be used to route the resulting transactions on an external basis. The supported standard entry classes are:

  • ARC, which represents an eligible check received via the U.S. mail or at a drop box location, which was presented for the payment of goods or services. The source document (the check) is used to identify the Receiver’s routing number, account number, check serial number, and dollar amount for the transaction.
  • BOC, which represents an eligible check received at the point of purchase or manned bill payment location for the in person purchase of goods or services. The source document (the check) is used to identify the Receiver’s routing number, account number, check serial number, and dollar amount for the transaction.
  • POP, which represents a payment for the in person purchase of goods or services by Receivers. These debit entries are initiated by the Originator based on a written authorization between the Originator and Receiver and notice provided by the Originator at the point of purchase or manned bill payment location. The source document, which is voided by the merchant and returned to the Receiver at the point of purchase, is used to collect the Receiver’s routing number, account number, and check serial number that will be used to generate the debit entry to the Receiver’s account. This type of entry may only be used for non-recurring, in-person (at the point-of-purchase) entries for which there is no standing authorization with the merchant for the origination of ACH entries to the Receiver’s account.
  • RCK, which represents a debit initiated by an Originator pursuant to an oral authorization obtained over the telephone to effect a transfer of funds from a Consumer Account of the Receiver. This entry may only be used when there is no standing authorization for the origination of ACH entries to the Receiver’s account. A TEL entry would instead be used when there is an Existing Relationship between the Originator and the Receiver, or, when there is not an Existing Relationship between the Originator and the Receiver, when the Receiver initiates the telephone call.
  • TRC, which represents truncated checks being safe kept by the keeper bank (Originator) as defined by a check truncation program. This entry has one transaction per truncated check. The TRX format (which is not currently supported by this conversion process) allows financial institutions to use a single transaction entry to carry information from multiple checks, where each check is identified within addenda records attached to the item.
  • CCD, which represents funds are transferred between unrelated corporate entities, or transmitted as intra-company cash concentration and disbursement transactions. This entry class can be used for standalone funds transfer, or it can support a limited amount of payment related data with the funds transfer. The CCD class is not appropriate for these items, but is included to facilitate data conversions for files processed within a given single environment.
  • PPD, which Direct Deposit or Pre-authorized Bill Payment. Direct deposit is a credit application that transfers funds into a consumer’s account at the Receiving Depository Financial Institution. The funds being deposited can represent a variety of products, such as payroll, interest, pension, dividends, etc. Pre-authorized payment is a debit application. Companies with billing operations may participate in the ACH through the electronic transfer (direct debit) of bill payment entries. Through standing authorizations, the consumer grants the company authority to initiate periodic charges to his account as bills become due. This concept has met with appreciable success in situations where the recurring bills are regular and do not vary in amount insurance premiums, mortgage payments, and installment loan payments being the most prominent examples. Standing authorizations have also been successful for bills where the amount does vary, such as utility payments. The PPD class is not appropriate for these items, but is included to facilitate data conversions for files processed within a given single environment.

Convert ACH to X9.37

In this mode, Convert is used to create a new X9.37 file from the currently loaded ACH file. This conversion can be from an x9 file that contains checks only, or a more complex POD file that contains both debits and credits. When there a credits, Generate allows you to select the type of credit record that is to be created (type 61 DSTU, type 61 Metavante, type 62, or type 25 with a user defined routing and/or transaction code). 

The conversion of ACH to X9.37 will work best when you define your own customized generator that is dedicated to this purpose. Pay specific attention to the image templates that are assigned. The output x9.37 file will be generally more acceptable when the all retail image templates have been removed and a single business and credit template is assigned and saved within your generator. Ultimately, users will want to customize our image templates for this specific conversion using the Template Editor. We would be glad to to work with you if you have questions about the process. The following is an example of what can be done using our standard templates: 

  • Create and save a new customized generator called “convert937.Generator.xml”.
  • Remove all retail image templates using select none.
  • Remove all business image templates and add back business4.
  • Remove all credit image templates and add back credit1.
  • Save the generator for future reuse.

The following fields must be entered for the ACH to X9 conversion:

  • Debit transaction code to be placed in the process control field. This value is most typically always omitted.
  • Credit transaction code to be placed in the process control field. This value is most typically a two or three digit number, but is not needed when the credit routing uniquely identifies POD credits.
  • Documentation indicator.
  • Return acceptance indicator.
  • MICR valid indicator.
  • BOFD indicator.
  • Correction indicator.
  • Archive indicator.
  • Return reason indicator.

Running Convert

Use the “convert” button to initiate the file conversion process. Convert will launch a new validation process for the converted file, which remains in memory after the conversion process has been run. You must save the results to an external file when you have reviewed results and determined that the output is beneficial based on your requirements.

Convert Summary

Convert is a generalized conversion tool that can be used to translate from one file format to another. X9Ware is in a unique position to implement this functionality given our support for both the X9 and ACH file formats. Convert internally leverages our Generate tool, which provides a large number of options and parameters to control attributes of the target output file. Once a file is converted, it will be launched in our viewer and will also be validated (subject to user licensing). All of this is done within the same tools and using using a consistent user interface.

Scroll to Top