Electronic Invoice Detail Page

Context

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.

Take A Closer Look

Even though our AI helps the users simplify the process, there will still be some circumstances and cases that the system can not cover. Take the examples labeled in the below flow chart. When the automation fails during Review Data and Review Validation stages, the invoice will need manual intervention from AP staff users so that they can continue to process the invoices.

Therefore, the product team would like to provide our AP staff users with design solutions for manual intervention as needed.

How does an AP staff manually process an invoice? First, they need to know if this invoice is a PO-backed invoice or a Non-PO invoice.

Dive Deeper

Problems

The above images are the first version of the Autonomous AP detail page. One is an invoice in Review Data status, and the other is an invoice in Review Validation status. For both states, the AP staff users need to do specific tasks. However, the AP staff users can only know what’s going on when they open the task panel, and they do not know whether this is a PO-backed invoice or a Non-PO invoice since we display the PO# field in line level even for Non-PO invoices.

So the problems of the current UI became clear: 

• The visual cues in the electronic invoice layout are not clear, and confusion happens when landing on the page.

• The clues to distinguish PO-backed and Non-PO invoices that can help process invoices are missing.

Since the manual intervention is primarily needed in Review Data status invoices, the use cases we want to cover will mainly target the invoices of this status.

Use Cases

• The AP staff users would like to quickly locate the risks and missing fields of the Review Data status invoices.

• The AP staff users would like to know what document or information is the source they could rely on to move the invoice to the next stage.

Other Facts

• The invoice line level has limited spacing but heavy data.

• The electronic invoice should look similar to the actual invoice document.

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 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

In option 1, 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.

Exploration 2

Overall Detail Page

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

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.

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. But for PO-backed invoice lines, I added the warning icon for PO mismatch. This indicator is only used when a PO mismatch happens, and it can not exist if there are required missing fields. 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. If there are no missing fields or errors in the line level, the expandable section will collapse, so users don’t need to worry about the line level. On the other hand, if there are missing fields and errors in the line level, the expandable section will be expanding automatically, so users can take action as soon as possible.

By just looking at the warning indicator, a user can easily know if this is a PO-backed invoice or a Non-PO invoice, and the expandable section will provide the information that is needed to move forward.

Action Panel

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.