Overview

Company credit cards are common forms of payment in businesses, and it falls to the accounting teams to ensure no fraud is committed on these cards. This is done with a process known as reconciliation, where an accountant goes through a credit card statement and needs to check that each transaction is valid. As this is typically a monthly task, being able to do this efficiently and thoroughly is of high importance to accounting teams.

Where Procurify benefits this process is being able to provide historical information on company transactions that an accountant can match up with their credit card statement transactions. Having the full context on their business purchases gives teams confidence to reconcile a transaction, as they can verify it was not fraudulent.

For this project, I worked with a team to reimagine and improve Procurify’s current Reconciliation experience to help accounting and finance teams validate their spend.

Identifying the Problem

One of Procurify’s upcoming projects was a way for customers to set up recurring purchases in their system. An insight that surfaced from the project was that a high amount of these recurring purchases were paid with credit cards, and needed to be validated in the Credit Card Reconciliation module. This placed future importance on the module and ensuring it met the customer needs was vital.

In addition, Procurify’s target customer at the time was companies in the tech industry, who we found to have a majority of their spend done through company credit cards. This meant to service their full purchase cycle, they would need to validate their spend in the Reconciliation module.

The previous Reconciliation page

I worked with my Project Manager to get an idea of the current state of the module and understand the usage. From interviewing customers and other internal team members, we identified that the module not only slowed down the spend validation process but also generated incorrect data. 

We noticed customers had an initial interest in using the module - 33% of our user base had exposure or attempted to use the tool, but stopped using it only after 4 weeks. We uncovered that the module did not meet expectations and prevented accounting teams to fully centralize their processes with Procurify, resulting in using other tools like spreadsheets, emails, or other third-party options to reconcile credit card spend.

Mapping The Experience

The Invoice Processing User Journey Map

Based on interviews with customers and internal team members, we created a user journey map to fully understand the experience and identify painpoints. The map showed us that one of the points causing the most frustration was the action of matching of Procurify and credit card transactions.

Digging further into this, we learned the specifics behind why it was so difficult to match transactions. When an accountant needs to reconcile credit card transactions in Procurify, they typically look for the following:

• The transaction amounts match
• The vendor names match
• The transaction dates match
• There is a confirmation of purchase or receipt of the original transaction (usually in the form of an attachment)

The Reconciliation module however made it difficult for users to find this information:

• Procurify breaks down transactions by individual line items during the reconciliation process. For example, if a purchase order had 5 items paid by one credit card through one transaction, our reconciliation module will break these 5 items separately in the matching page. This creates confusion for the user where if they were to look for the statement transaction within Procurify, they will not be able to because the costs are separated into different items, which would have to be added up. 
• The vendor names never match - the vendor name from Procurify is not often the same as bank statement names, which is common but adds friction to the reconciliation process.
• The transactions are missing other costs such as taxes and shipping. This makes matching almost impossible since most transactions already include those costs within an entire order.

Ideation and Solutioning

Having the problem defined, I lead a design sprint session with my development team to gather initial ideas for solutions.
‍
One of the emergent ideas was to have a way to group items based on their Order groupings, instead of users having to select them separately. This came from the insight that typically each transaction on a credit card statement would correspond to a purchase order in Procurify. By grouping items, this would more likely match them together.

First concept of a Procurify item as it would appear in the Reconciliation Module - expands to show the item breakdown and additional costs

Since item has all items and additional costs included, it now matches the corresponding transaction in the credit card statement

There were also “quality of life” improvements suggested by the team, including helping guide users in the workflow. 
‍
An insight that surfaced from our research was that users were missing one of the first steps of filling in reconciliation details due to the fact that it was not as obvious. To help remedy this, we suggested numbering each step and providing instructions to guide them in the process.

Added header instructions for each step to guide the Reconciliation workflow

Getting Feedback

From the generated ideas, I created a concept prototype to validate through with stakeholders and customers. The feedback received on it was positive as it addressed the root of the matching problem. With the idea validated, I produced a high-fidelity mockup to guide the team and spec out the solution.

Final Result

The final product is still in development, but the feedback received from customers seeing the solution mockups has been positive

For a high fidelity prototype, click here.

My Contributions

• Worked with Project Manager to communicate and receive feedback from both internal stakeholders and customers
• Lead experience and visual design for the project
• Gathered ideas from internal team members and development team and synthesized them to produce solutions that addressed the problem

Takeaways

This project was a good example of learning to think about how a design would come to life, and how the development team would be able to ship it in valuable increments. This meant thinking about what a first shippable iteration could look like and how it would help customers with the problem at hand.
‍
I also found rapid, lightweight communication with customers and stakeholders to be valuable and helped validate my hypothesis. Simply emailing a concept of a design was enough to get the answers I needed to move forward.