How We Made Expense Report Closure a Breeze at Fyle?

"Hi, I'm Swapna, and I have been working as a Product Design Manager for the past 2.5 years at Fyle. I transitioned from an individual contributor to a manager role. Looking back, I must say the first 9-10 months of my journey were an absolute thrill because, on day 0, I had no idea what being a manager entailed 😂.

These days, I have a much clearer understanding of my role. It has been a rewarding experience building and nurturing teams, setting them up for success. However, along the way, I realized I missed the role of an individual contributor. The desire to play with colors, space, information, and layouts is still strong within me—nothing has ever matched the feeling of zooming the artboard to the maximum and perfecting that 1px.

And then, life became a little kinder to me."

The inception of the Initiative

During a roadmap discussion with the team, Yash repeatedly asked whether we should make content-related changes to our Payment module to address usability issues. In the past, We received multiple complaints from customers about various problems in this module.

But why content-related changes? - It is because of the vastness and complexity of the module. Any mistake could have caused significant disruption leading to customer dissatisfaction and churn. As a business, we wanted to avoid this, especially during the winter period 😁. Another factor was our previous attempt to solve the problems in this area, which we abandoned about a year ago after investing three months. We were not convinced by the proposed solution at the time.

So there was no point in disagreeing to do content-related changes! However, it took us several 2 to 3-hour-long sessions to realize that words alone would not win the battle, although that may be true in journalism and politics 😛. With each session, our problem statements became clearer, and we became more aware of the technical constraints involved.

I was asked to try different initial solutions in the brainstorming session. Soon all product stakeholders were on the same page, understanding that this would be a significant and challenging initiative. The process involved approximately 7 to 8 weeks of design work, 5 to 7 usability testing sessions, ongoing engineering work spanning over 6+ months, and a well-planned release strategy. Just 3 to 5 days ago, we enabled the new flow for all eligible organizations, and here's the current adaptation rate. However, the new flow is yet to be activated for the remaining half due to a dependency on another feature.

We are on a positive track, and the adaptation rate is expected to soar in the coming days, thanks to the fantastic feedback we have received from our customers. During the customer usability tests, beta phase release, and general release. We have consistently received almost 5-star ratings 😊.

But what is this initiative about?

In the world of expense management, there are three important personas: the spender, the approver, and the finance person.

What does a Spender do?

A spender spends money on behalf of the organization and then sends these expenses to the organization along with receipts as proof. Spenders usually wrap a bunch of expenses into one single or multiple Expense reports and send that report to the organization.

What does an approver do?

An approver approves these expense reports, ensuring all expenses comply with company policies.

What does a finance person do?

The finance person performs the final check and initiates the reimbursement for the spender wherever necessary. They also mark the expense reports as “Closed“and maintain a log of these expenses in the organization’s accounting book (Quickbooks, Zoho, SageIntact) for auditing purposes.

By now, you should have understood how expenses in expense reports travel from the spender to the approver and finally to the finance person. This initiative is specifically focused on addressing the challenges faced by finance personnel.

Great! Let's now dive deeper into the problems at hand."

The Problems

One Size does not fit all

• When a spender makes a purchase, they can use their card, cash, or a company-owned corporate card. However, the mode of payment is entirely controlled by the organization. Some companies require employees to use corporate cards, while others allow personal cards/cash, and some companies accept both methods of payment.

• When the payment method is a personal card/cash, the spender seeks reimbursement. Once the reimbursement is processed, the finance person can then close the expense report.

• On the other hand, when the payment method is a corporate card, the company does not owe any reimbursement to the spender. After reviewing the expense reports, the finance person closes them.

If we look at it, we can observe the finance person has different requirements depending on the payment method chosen by the spender for any given expense.

However, the existing flow does not accommodate this unique need, forcing the finance person to go through multiple steps, leading to delays and confusion in the process."

Misleading Approval/Verification Interface

• The approval stage is company specific too. In some companies, it is 1 step process, and in a few other companies, it is a 2 step process. Approval is needed from an Approver, and then verification is done by a verifier. Verifiers are the finance persons in most of companies.

• The Admin can set this up through the setting. → then it is all cool, right? However, there is an issue with the functionality. Even when the verification option is turned off, the finance person can still see it on the interface as an optional event.

  

• This gave the impression to the finance person that it was a necessary step to perform. In reality, it was meant to be an optional action.

• Highlighting one data point,

  • In organizations that exclusively use corporate cards, approximately 78% of them have disabled the verification settings. Interestingly, in 98% of cases, the finance person still ends up verifying the expenses made with the corporate card.

Loosing out on Context, Mismatch of Expectation, and so much more…

Following the verification process, the subsequent step entails the finance person initiating the payment. But with the existing interface, the finance person needed to send the approved/verified reports to another module, the Payment module.

Since the finance person sends the expense reports to the payment queue, the expectation was to view the sent expense reports. However, the system regroups the expense reports in the payment queue based on employees, introducing learnability. Adding to this, it was confusing to see a column called Liability in the table 😖 → This confusion was further compounded when the liability showed a negative amount, making it particularly challenging for new finance personnel to make sense of the information.

While navigating through these challenges, when the user presses "Start processing," it may give the impression that everything is resolved and the reimbursement has been initiated. However, this is not the case. In reality, pressing "Start processing" sends the report back to the processing queue, creating confusion and a false sense of completion.

After relaxing for a few days, the finance person realizes that the reimbursement has not yet been initiated.

It takes some time for them to figure out that they need to start the reimbursement process from the Processing queue.

Now you should have a good understanding of the various challenges and frictions that finance personnel face in their workflow.

The missing identifier for Reimbursable Eligible Expense Reports

A spender will receive the reimbursement money in their bank account, but to facilitate this, the spender needs to provide their bank account details. If the bank details are not available, the reimbursement for their expense report will fail.

Therefore, during the reimbursement process, the finance person must have visibility and an understanding of which expense reports are eligible for reimbursement. Unfortunately, this visibility was lacking, leading to a higher percentage of failed reimbursement attempts.

Lack of Visibility for Failed Reimbursement Reports

After reimbursement is initiated, there was a fair chance of failed reimbursement for different reasons. The only way in discovering these expense reports was to visit the Payment Module → Payment Processing Queue.

Adding to the misery, it was difficult to understand the error states and filter out the errored reimbursement. Some other UX copies like “Processing Payment Offline” → were confusing as the finance person initiated the payment online.

Mismatched Expectations in Advance Amount Settlement Flow

There was another way where the Spender can take money from the company in advance and utilize that for company expenses. A spender can request multiple advances from the company.

Hence when a spender submits an expense report eligible for reimbursement and holds any advance amount, the finance person settles the reimbursable amount against the advances. While doing so, the finance person tends to settle the amount against each advance instead of the total advance amount.

For example, when 2 advances are issued to the spender, one is for food worth Rs4000 and the other one was travel Rs10,000, the finance person aims to adjust the reimbursement balance against the food or travel advance amount. The interface never allowed them in doing so. Instead, the interface forced the finance person to settle the amount in one shot i.e. against Rs4000+ Rs10000 = Rs14000. If the spender’s reimbursable amount is Rs2000, the system will show a -ve liability of Rs12000 which needs to be collected from the spender. The finance person finds the process of collecting money back as harsh, instead, they preferred to adjust this amount against future reimbursable amounts.

No visibility into set Reimbursement Mode

As per business plan type, a company can opt for different modes for initiating reimbursement. If the company is a Standard plan user, it will get an export-ready sheet that can be used in a 3rd part app for processing payment whereas, in a business plan, the company can initiate the reimbursement within Fyle using ACH.

There was no clear visibility into these payment modes within the app as per organization plan type and the system showed all possible payment modes to the user. Many payment modes were not used by the finance person and in fact, it was alien to them. E.g US companies prefer initiating reimbursement via ACH, hence viewing other modes of payment is an unnecessary cognitive effort for them.

Our problem list is not over yet, but I am making a hard stop here now 🤣. Let's deep dive into the solution phase.

Solutions

If we observe a finance person's workflow, there are 3 basic knobs.

1. Approval Process whenever needed

2. Initiating reimbursement

3. Closing the reports

The first 2 knobs are controlled by Admin through settings. Hence We will solve the problems at the source.

🛠️ Setting up the Approval Process

We did a very minor change here and that brought a significant impact to the workflow.

• A verification setting knob is now provided in settings.

• When it is turned off by the Admin, Verify as an action won't be available to the finance person on the interface.

• When the verification setting is turned on, the finance person will go through the verification process for expense reports once approved.

  To simplify the user interface, we introduced a Verified column in the Approved reports queue instead of a separate tab like in older designs also we asked the user to verify the reports upfront when they interacted with any approved reports.

💸 Setting up Modes of Reimbursement

If an organization is a business plan user, it can initiate the reimbursement using ACH within Fyle whereas if the org is a standard plan user, then it will get exported ready data which can be used in another third-party app for initiating the reimbursement.

The visibility of the reimbursement modes is now available on the settings page as per the org plan type. If you are interested in exploring the IA of this, please refer to this [link].

User Journey

I have demonstrated the user journey of the organization which allows its spenders to use both personal card/cash and corporate card. The image is a bit blurry, So I have added an overall textual version of the flow below.

The overall flow of expense reports:

• When the Spender submits expenses via expense reports, the expense reports stay Submitted.

• These submitted reports appear in the Approver Queue. Once approved, the expense reports are tagged as Approved.

• A finance person now goes through these Approved expense reports. verifies it. (Org Specific)

• Once the finance person is happy with the final check, initiates the reimbursement. Hence the expense reports state changes to Processing.

• As per organizations’ plan types, the expense reports in the Processing state automatically get closed or need manual intervention from the finance person.

  • If any error occurred post-reimbursement, the finance person needs to resolve those.

Now, can you spot these four states (Submitted, Approved, Processing, Closed) in the user flow? This helps the finance person in understanding how the expense report moves from one state to another state.

Cool, If you remembered, we talked about the 3 basic things that the finance person does:

• verification checks as per Org need

• Initiating reimbursement,

• and closing the report.

We have already discussed how the finance person verifies reports in the new flow. So let's deep dive into the Initiating reimbursement flow. Just a gentle reminder on we have set up the reimbursement mode through settings, already.

💰 Initiate the Reimbursement

As mentioned above, we are currently dealing with an org, where spenders can use a personal card/cash and corporate card as modes of payment, hence the expense reports submitted by the Spender can contain

• Expenses made using the corporate card (Hence no reimbursement done to the Spender)

• Expenses that are made using a personal card (Hence reimbursement should be done to the Spender)

• or a mix of both kinds of expenses in a report.

Before initiating Reimbursement

We made sure the finance person knows

• which employee has added the bank details or not

• Which report is in the verified state or not

• Where reimbursement amount is already 0 as it has corporate card expenses etc

➡️ While Initiating Reimbursement

Even if we provide the nudge and identifier, there is a fair possibility that the finance person will miss it and select these reports for initiating reimbursement. Hence we should inform the user about these reports and an easy way out for excluding these.

In the following example, out of 3 reports, 1 was verified, another one was not verified, and bank details were missing for 1 verified report. Hence when the user initiates the reimbursement, the reimbursement interface excluded these ineligible reports along with the reasons.

Have you observed that we have displayed the applicable reimbursement modes (Reimburse via ACH) for initiating the reimbursement process? This has been tailored according to the organization’s business plan type and the preferred option selected in the settings. Once the reimbursement is initiated, the reports are labeled as "Processing" and then placed into the Processing queue.

This interface also solves a couple of other edge cases like

• What happens when a report only has corporate card expenses and the reimbursement amount is 0? Technically there is nothing to reimburse here.

• What happens to corporate card expenses when a report has both corporate card and personal cash expenses and reimbursements initiated?

But not diving into the details here.

⚠️  Handling failed ACH Use case

Reimbursements aren't always a walk in the park. Sometimes, reimbursements may fail due to various reasons, and the lack of discoverability can result in the finance person being unaware of these failures and left out of the loop.

Hence to make this more accessible,

• We provided a task mentioning the number of failed ACH reimbursements on the user's dashboard as soon as they log into the system.

• Upon interaction, the user will be directed to the Processing Queue, where they can find an overview of the overall stats for failed reimbursements and individual reports tagged with the "Failed" status, color-coded for easy identification.

• We have introduced a convenient filter called "State" that enables users to effortlessly switch between failed reports and reports in the processing state.

This interface enables the finance person to re-initiate ACH reimbursements for failed reports, making the process more streamlined and user-friendly.

🔒 Closing the Reports

After a successful ACH reimbursement, we automatically move the report to the Closed state for business plan users. We improved UX Copy from paid to ‘Close’ to make it more universal and suitable for all types of organizations.

There is one more use case, that we haven't discussed yet, and that is the Advance settlement. 😊 I'm delighted to see you making it this far.

🐎 Designing a better Advance Settlement Interface

Instead of forcing the finance person to settle the reimbursement amount in one shot against total advances issued, we enabled them to settle it against a particular advance account,

It's as simple as it sounds! 🤷🏽‍♀️ But I did a mad exploration around it 😛. It was just a damn dialogue box.

To allow users to apply for advances, we placed the call-to-action button near the reimbursement amount for easy discoverability. Upon interaction, we prompt users to select the advanced account they want to settle against. The interface keeps the user informed about the consequences of applying advances.

And finally,

Now we are done! We conducted usability testing with at least 7 to 10 organizations, often during off-hours, to gather validation for our solution. I am very grateful to Gayathiri. She lifted my spirit throughout this initiative by offering feedback, participating in brainstorming sessions, or with a shoutout message like this.

Also not least, for some reason, many one-liners of Siva get printed in my mind. When I self-reflect, I feel someone is telling me good things, and I need to absorb them.

This is one thing that will stay with me forever (O yes, I misremembered it, and then he corrected me, like every time 🙌🏽)

Ultimately I thank everyone (My Product Design and Product Team, Yash, Gayathiri, Abhishek, Siva, Gokul, Customer Success Team, and Customers) for making it a success. It was indeed a true team collaborative effort. 🥂`

Thanks a lot for making it so far. Please reach out to me if you have any feedback.