Interface File Creation

Even if you relish a challenge, developing an electronic Commercial Card interface file for a particular system (finance or other) can seem like a daunting task. However, by breaking down the project into manageable steps, a pain-free experience is possible. The following offers direction on four key aspects associated with interface file development.

Don't forget to subscribe to the blog (no charge) to receive educational content!

Do not let an interface file project overwhelm you. Break it down into manageable stages.

Do not let an interface file project overwhelm you. Break it down into manageable stages.

Four Key Aspects

  1. Determine what you need the interface file to do/accomplish.

  2. Identify the system into which the interface file will be uploaded, and the related specifications.

  3. Select the relevant card-related data to be included in the interface file.

  4. “Map” where each piece of card data belongs in the interface file, based on system specifications.

In reality, you might work on these aspects concurrently. Remember to build time into your project for file testing purposes. 

Breaking It Down 

1. What Do You Want the File to Accomplish?

What are you seeking and why? Will you need to add or modify fields in the system used for transaction reconciliation? For example, is there a piece of data you need to capture in the interface file that would need to be supplied by cardholders?

Most commonly, an interface file is needed for the finance system, but you need to decide which one—AP system or general ledger. Further, there is more than one way to approach it. For example, will the interface file serve to initiate a payment to the card issuer? Maybe; maybe not. It could depend on how often you pay the issuer, how often cardholders reconcile transactions, and/or other factors.

2. Where Will the Card Data Go?

Can the identified system (#2 above) accommodate a file upload? If so, what are the requirements and specifications? Elements to explore include: fields to be populated, field length and type (e.g., alpha, numeric, or either), any prohibited characters that could cause problems during the file upload, etc. You may need to consult with the system provider/vendor. Also, your card issuer might be able to offer some insight if any of their other end-user clients have an interface file for the same system. 

3. What Card Data is Available?

There are three broad categories of card-related data:

  • Transaction information, such as date, amount, sales tax, and line-item detail (if available); may also include any data entered by the cardholder during reconciliation

  • Supplier information, such as name, address, and merchant category code (MCC)

  • Cardholder/card information, such as name, zip code, and account number

You likely do not need every piece of available data. Determine the information that best supports what you want to accomplish.

4. Where Does Each Piece of Card Data Belong?

The system into which you will upload the file probably does not have field names that exactly match the names of card-related data. You need to figure out what to put where.

Lastly, some data might need to be automatically added to the interface file—to satisfy certain field requirements—versus originating from the card activity. For example, the file specifications might include a field designated as “Payment Type” for which you want a constant default of “PCARD” each time the interface file is downloaded.