Electronic Invoice Detail Page

Timeline: 06.2021 - 09.2021

My Role: Product Designer in a team of 5

Context

Autonomous AP is an AI-powered invoices processing tool from AppZen. The traditional way of handling an invoice is time-consuming and high-cost, based on the research, the cost of processing a single invoice can be up to $30. AppZen’s Autonomous AP aims to help AP team/AP staff reduce time and cost when getting invoices from suppliers. Ultimately, to help our customers get better control on strategic financial management.

When I joined the team, Autonomous AP was in the early stage of development. The electronic invoice detail page is the product's primary feature, but back then, there were lots of frustrations when the AP staff tried to move the reviewed and corrected invoices to the next step. We were desperately trying to improve the overall user experience.

Research

Learn the Domain Knowledge

To better design the invoice detail page, I need to understand better how to create and process an invoice. A typical invoice creation involves mainly four types of users - the department that requires goods/services, the company's finance team, the supplier, and the AP staff in the finance team.

Autonomous AP mainly targets the process from getting supplier's invoice, processing the invoice, approval for payments, and all the way to record in ERP system. The electronic invoice detail page is mainly for processing, and this would also be my primary focus of this project.

The Traditional Way vs Autonomous AP’s Automation

The technology of Autonomous AP simplifies the most time-consuming and complicated steps in processing an invoice.

How to Process An Invoice

What information an AP staff could rely on when they try to process invoices?

First, they need to know if this invoice is a PO-backed invoice or a Non-PO invoice.

To process a PO-backed invoice, they need to look at the matching way.

To process a Non-PO invoice, they need to look at the accounting segments.

The rules of processing an invoice are the same for manual and Autonomous AP automation. These data entry and data validation all happen in the status called Review Data and Review Validation in Autonomous AP.

Even though our system helps the users simplify the process, there will still be some circumstances and cases that the system can not cover. For example, when the automation fails, the invoice will need manual intervention from AP staff users so that they can continue to process the invoices.

Since most manual intervention happens in the Review Data status, the electronic invoice detail page in Review Data status will be my main focus.

Use Case

The use case of the electronic invoice detail page is clear to me at this point:

“The AP staff users would like to know what needs to be done to move the invoice to the next stage.”

The Problems

Review Data status invoice - PO-backed

Review Data status invoice - Non-PO

The above images are the original version of the Autonomous AP detail page before I joined the team. They are both invoices in Review Data status. But one of them is a PO-backed invoice, and the other one is a Non-PO invoice.

In both images, you could see an Edit button on the top right of the electronic invoice section and some empty fields in the invoice header level like Payment Terms, Company, PO Number, Subtotal, Tax, and Shipping. These fields are all missing, but some are mandatory(Company, Payment Term, and PO Number), and some are optional(Subtotal, Tax, and Shipping). A user will not be able to know until they look carefully at the invoice document section or use the task panel. The task panel has a Missing Fields section along with a Review button. Back then, the expected behavior was when a user lands on this page, they open the panel and click the Review button, and each time they click the Review button, it will lead the user to a required field for the user to make corrections. After all required fields are clear, the Save and Continue button will become enabled, and the user will be able to move the invoice to the next stage for validating. There are a couple of problems I saw when I went through the UI and the flow:

There’s no visual cue to tell the user what is required and what is not.
For both PO-backed invoice and Non-PO invoice, the invoice line level UI look the same:
- The information is not well organized - some of the critical data is missing (eg. qty)
- There’s also no visual cue to tell the user what is required and what is not - this can leads the user to make a wrong decision when there’s no error in the header level
The task panel does not meet the purpose of its original intention.

At this point, the user case became more clear to me:

Use Case 1 - “The AP staff users would like to quickly locate the required actions of the overall invoice.”

Use Case 2 - “When there are no errors in the invoice header level, the AP staff users would like to quickly identify if an invoice is a PO-backed or Non-PO so they could make the proper decision.”

There are also some other facts I needed to keep in mind:

The overall invoice UI needs to be universal and consistent.
The electronic invoice should look similar to the actual invoice document.
The invoice line level will mostly have heavy data but limited spacing on the UI.

Explore Possibilities

Whiteboard

I held several whiteboard sessions with the product manager, engineers team, the customer success team, and other stakeholders to provide better design solutions. We whiteboarded the flows and some initial design thinking/concepts. These sessions helped me understand the technical constraints, the product roadmap, and the business goals from different perspectives.

We determined some directions to start with:

Use obvious visual cues for the fields that need the user’s attention on the electronic invoice
Associate with Task panel to emphasize
Differentiate PO-backed and Non-PO invoices in the line level

Exploration 1

Overall Detail Page(Use case 1)

I used the warning icons to mark all required and missing fields on the electronic invoice, and this applies to both header level and line level fields. When hovering, show a tooltip to tell the user why this field is flagged. When hovering, use the default check icon for low extraction confidence fields and non-required fields to display the extraction confidence score. In the task panel, separate the information into 2 - one is for missing and required fields, one is for non-blocker but better to review fields.

Invoice Line Level(Use case 2)

I used a brick style to display the information at the invoice line level. For both PO-backed and Non-PO invoices, the accounting segments are always in the first row.

For the Non-PO invoices, putting accounting segments in the first row will tell the AP staff quickly if the invoice belongs to the right place so they can process it to the next stage. For the PO-backed invoice, showing the comparison in an up and down structure, AP staff will know if it gets a match to continue.

The Pros

The user has clear visual cues for required and missing fields
There’s a difference between the PO-backed invoice and the Non-PO invoice(But not very intuitive).
AP staff users can tell if they get a match in the invoice line level for PO-backed invoices.

The Cons

The use and the meaning of the warning icon is not relatively consistent and intuitive in header level and line level
The hovering behavior is overused
Warning items are not intuitive on the electronic invoice
The portion of one line is taking too much space, if the segments are more than 5, the portion will become bigger, and the information is limited.

Exploration 2

Overall Detail Page(Use case 1)

In exploration 2, I use the color label to display a different level of attention. The red is for a really low confidence extraction score and required missing fields; the yellow is for a high confidence extraction score but not 100%. I also removed the hovering icon for each field in this version since I only want the users to pay attention to the color-labeled ones. This logic is also reflected in the action panel; the item will disappear in the action panel once the field gets corrected.

I also added an expandable section for Supplier Name and PO Number in this version. This information will help the AP staff identify the values of other fields, but it’s not always needed. The users can click the arrow button to expand or collapse it.

Invoice Line Level(Use case 2)

I applied the same logic used in the header level for the line level - to display the error/fail reason of the high-level warning in the field instead of hovering the tooltip. I used one more thing in this version of design: instead of the segments’ full names, it displays segments codes; this will save lots of spacing in the already so crowded line spacing. The detail information will show in a popup if click the text.

There’s a clear difference between Non-PO invoices and PO-backed invoices. For PO-backed invoices, I used a horizontal comparison to show the PO matching result. If there’s a difference between PO and invoice, the red label will tell the user there’s something wrong with the invoice.

The Pros

The user has clear visual cues for required missing fields and warning fields
The difference between the PO-backed invoice and the Non-PO invoice is clear
AP staff users can tell if they get a match in the invoice line level for PO-backed invoices.
The expandable section and segment code are excellent calls to display secondary information.

The Cons

The yellow text on the UI creates a visual burden.
There are too many colors used in the overall UI
The style for PO-backed invoice lines and Non-PO invoice lines is not entirely consistent.
The PO-backed invoice lines design can’t serve for the long-term; it crops information; the user has to hover the text to view the full content.

Review

I presented these two options with PM, the engineering team, the customer success team, and other stakeholders to collect feedback. I listed all the pros and cons from the designer’s perspective, and the rest of the team provided their insights and understandings about the design solutions. The feedback and suggestions from the reviews helped me be closer to that A-ha moment.

Final Design

Overall Look

Invoice Header Level

For the invoice header level, I still used the color label concept. However, instead of changing the text color and the warning icon, I used a box to mark the fields that need attention. The use of the red box is only for required and missing fields; the yellow box is for non-blocker but low confidence extraction score fields. There will be no warning icon displayed at the header level. The overall look of the header level became more organized and clean.

This solution solves the use case of when there are errors in the header level; the AP staff users can quickly catch them and then make corrections.

I also added the expandable sections to Supplier Name, Entity Name, and PO Number. If there are no errors in the related fields of these three, the additional information will be default collapsed. However, if there are errors, the information will expand automatically; the AP staff will be able to get the data they want to use for the color-labeled fields.

This behavior can help the users to achieve their goals more efficiently.

Invoice Line Level

For the invoice line level, the color label concept still applies.

For PO-backed invoice lines, show the red box for required/missing fields (Extraction fail/PO mismatch fields).

For Non-PO invoice lines, show the red box for required/missing fields(Extraction fail/Prediction fail).

There’s also one significant improvement in the line level. To make the UI look more organized and readable, I added the expandable section concept. The expandable section will defaultly open when landed on the page. It can be collapsed if the user wants to save some spacing.

Action Panel

The action panel also reflects the concept of the color label. The Required Actions will list all the red warning boxes in the invoice. It is separated into two kinds of actions - one is for required missing fields, one is for PO match errors. The users need to clear all the Required Actions to move forward to the next stage. The Warning will list all the yellow warning boxes in the invoice. These items are not blockers; if a user has already cleared the required actions and decided to move forward without changing any of the marked yellow fields, they can do that. These yellow warnings’ goal is good to check but not mandatory.

Deliver and Launch

After reviewing the finalized design with all the stakeholders, I made some minor changes based on the feedback and started to create design documents to handoff.

We successfully launched the new Electronic Invoice Detail Page into production and brought back a lot of learnings and empathy from our domain experts. These learnings help the team improve our product and provide a better user experience.