Accounting Entries

Again, every organization might be a little different, but the following types of entries could occur:

Upon receipt of goods (e.g., debit an asset account and credit accounts payable)

Following invoice processing, when AP initiates the related Virtual Card payment through its electronic accounts payable (EAP) provider (e.g., debit accounts payable and credit a designated Virtual or Commercial Card payable account to keep these payments separate from other payment types)

When AP pays the EAP provider (e.g., debit the designated payable account and credit cash)

Reconciliation

Chances are, the statement total from the EAP provider does not exactly match the amount in the associated payable account because you are still waiting for one or more suppliers to process Virtual Card transactions. The key is to streamline your reconciliation process. Pay the EAP provider and then focus on the remaining amount in the payable account.

Which pending Virtual Card transaction(s) does the remaining amount represent?

Which pending transactions are associated with Virtual Cards that have expired while waiting for the supplier to act?

What does your EAP provider offer in terms of reporting to help you easily identify pending transactions (Virtual Card payments you have initiated but suppliers have not acted on), including any expired cards?

If needed, does your ERP system offer any reporting to simplify the reconciliation?

Additional Virtual Card Tips

As you add suppliers to your Virtual Card program, include relevant training.

Work with suppliers to identify who within their organizations will need training.

Train the applicable supplier personnel on the Virtual Card process. See a related blog post on Virtual Card acceptance.

Provide documented instructions for their ongoing reference.

Within your organization:

Determine your Virtual Card expiration date strategy.

Decide if you want to send reminders to suppliers before a Virtual Card expires.

Document procedures for how AP should address Virtual Card payments that suppliers do not process in timely manner. Besides training and communications with suppliers, this might involve extending the card expiration date if possible or reissuing a Virtual Card. While you do not want to wade into the waters of unclaimed property, try to avoid defaulting back to a check payment for the offending supplier, which can derail your Virtual Card program.

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

Determine what you need the interface file to do/accomplish.
Identify the system into which the interface file will be uploaded, and the related specifications.
Select the relevant card-related data to be included in the interface file.
“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.

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

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.