Uncertainty. Pressure. A faster heart rate. These are just some of the things people feel when they have to develop a new, electronic Commercial Card interface file for a particular system (finance or other). Even if you relish the challenge, formulating a plan can take time. Through personal experience and by helping others, I have learned it is best to break down the project into manageable steps. The following offers direction on four key aspects associated with interface file development. Keep this handy for the next time you face this situation.

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. 

Resources

For an introduction to interface files and information about finance system options, visit the Interface Files webpage. If you are seeking external expertise, contact Recharged Education to inquire about consulting services.

About the Author

Blog post author Lynn Larson, CPCP, is the founder of Recharged Education. With more than 15 years of Commercial Card experience, her mission is to make industry education readily accessible to all. Learn more…

Subscribe to the Blog

Receive notice of new blog posts.