Introduction to Interface Files

In relation to a Commercial Card program, an electronic interface file is comprised of card-related data that an end-user organization uploads into a designated system. Some organizations refer to this file as a “mapper” or other term. Such files are an important part of card program implementation and management; specifically, the finance/accounting-related aspects. Keep reading to learn more.

Who is Involved?

Typically, the card issuer creates the file per specifications provided by the end-user client, based on the system into which the client will upload it. Most interface file projects require the participation of a cross-functional group. It may or may not include IT. You may or may not need to consult with the system provider/vendor. It depends on the project and the knowledge level of group members.

Use of an electronic interface file eliminates manual data entry by an end-user organization.

Use of an electronic interface file eliminates manual data entry by an end-user organization.

Why Create a File?

Use of an electronic interface file eliminates manual data entry by an end-user organization. Most commonly, the file captures card-related data relevant for the accounting aspect of a Commercial Card program. However, an interface can also be developed for other reasons (e.g., for auditing technology, for a contract database, etc.).

A new or modified interface may be needed if/when an organization has a system or process change, such as a new or modified ERP system. If an organization changes card issuers, it should be able to forward the specifications of its current interface file and await the same rendition from the new issuer.

Interface File for Finance System

Upon first implementing a P-Card program, an end-user organization should, at a minimum, do the following.

  1. Determine which finance system an interface file should be developed in order to account for card activity. This could mean the AP system or the general ledger. There are pros and cons associated with both, as noted below.

  2. Work with its issuer to develop the necessary interface file(s).

  3. Thoroughly test the file(s) before incorporating into a live environment.

AP System

Pros: Card transaction details reside with other payments, so there is one central location through which applicable employees can view information for all types of payments.

Cons: Card transactions reside in more than one location, cluttering the AP system, and they still need to be accounted for in the GL. In addition, the card data will not exactly match other payment records. For example, in the AP system, a Vendor Name field is intended to reflect the vendor from whom an organization acquired goods/services. For card transactions, an organization typically populates this field (through the interface file) to show the card issuer name. If it wants the “real” vendor name to be included for each transaction, then the organization would need to identify an alternate field, if available, for such data.   

General Ledger (GL)

Pros: By-passing the AP system means less clutter in that system and it streamlines the process for recording expenses for the balance sheet.

Cons: To view information for all types of payments, employees might need to access multiple systems. For example, card transaction detail could reside in an external system (e.g., Web-based card issuer technology) while everything else could be accessible through the AP system.