Project type: Design project at AI-powered Accounts Payable Solutions Company
Project length: 3 months
My role: Lead Product Designer
Collaborators: Product managers, engineering team, customers, design manager
Project length: 3 months
My role: Lead Product Designer
Collaborators: Product managers, engineering team, customers, design manager
This project is a continuation of the Purchase Order Matching case study, with a focus on the admin workflow for defining tolerance levels. If you haven’t read Part 1, I recommend starting there for a more complete overview of the PO matching evolution and context.
Background: PO matching basics & why tolerance matters
Purchase Order (PO) Matching helps Accounts Payable teams verify that invoice details match the original purchase order—ensuring companies only pay for goods or services that were actually ordered and received.
Tolerance levels play a key role by defining acceptable discrepancies, so minor mismatches can be auto-approved while larger ones get flagged for review. With well-defined tolerances, companies reduce manual work, minimize errors, and streamline their approval workflows.
The Challenge: Defining flexible tolerances for everyone
When I began this project, our biggest challenge was having only one beta customer to research with—making it difficult to understand the broader landscape of tolerance policies. The product manager and I leaned heavily on secondary research, tapping into online resources and insights from our internal finance team. Despite the limited access to users, our beta customer played a key role in shaping the admin workflow. They shared their own tolerance policies, which I used to ensure the design could support real-world complexity and scale for future customers.
Existing System: Where we started
Fortunately, the platform already had an approval flow engine for invoice approvals, so I was able to reuse many of the existing components. This helped us keep the user experience familiar and reduced development effort.
Invoice Approval Flow Engine
The invoice approval screen used a dual-pane layout:
Left side: Users defined rules or triggers (e.g., department name, total amount)
Right side: Users configured multi-step approval flows to support internal checks and balances. Additional triggers can be set if needed.
Left side: Users defined rules or triggers (e.g., department name, total amount)
Right side: Users configured multi-step approval flows to support internal checks and balances. Additional triggers can be set if needed.
The unique challenge with PO mismatches was supporting nuanced tolerance logic—allowing admins to set thresholds for vendors, quantity, unit price, and line amount, and defining when these tolerances should trigger an approval flow.
Early Exploration: Mapping the messy middle
To organize my thinking, I began by diagramming all the different types of tolerances the system might need to support.
In the first iteration, I created three trigger types and prioritized readability. Each trigger read like a sentence—for example, “If Received Line Amount is greater than or less than the acceptable percentage”—with supporting example shown in lighter text below.
To simplify the user experience in setting up trigger conditions, I revised the initial three options to two core choices: "Not an exact match" and "Is greater or less than the received % or value." This focused approach directly facilitates the subsequent selection between percentage and absolute value comparisons for defining approval workflows.
To switch between percent and absolute values, I considered several UI patterns:
• A dropdown to toggle between % and $
• Clicking directly on the symbol
• A button inside the input field
I ultimately chose the inline button approach—it felt intuitive and kept the layout compact. Although it required a new component, I was able to work closely with our UI engineer to get buy-in.
I also explored using “≥” and “≤” symbols for compactness, but internal feedback indicated they were less readable than plain language.
Later Exploration: Refining language and logic
In subsequent iterations, I implemented several key changes.
1. I moved the vendor & vendor tag selection to the top of the flow configuration—since it was always a required input for PO matching.
2. We also decided to replace the term “Received” with “Expected” for broader clarity. This change was necessary because different companies follow different levels of PO matching:
• 2-way matching: compares the invoice to the purchase order
• 3-way matching: adds the receipt of goods into the comparison
• 4-way matching: also factors in inspection or quality check results
Since not all companies use the same level of matching, “Expected” became the most neutral and inclusive term to describe the comparison baseline.
3. Further refining the trigger options, I rephrased "is greater or less than the acceptable % or value" to the more concise and equally readable "Is not a match within tolerance." This optimization reduced the dropdown text while maintaining clarity for administrators. To further streamline the interface, I also removed the detailed explanation and example previously displayed below the option.
4. Addressing feedback that admins needed more granular control over condition definitions (e.g., specifying only "less than" tolerances), I introduced toggle buttons preceding the "Greater than/Greater than or equal to" and "Less than/Less than or equal to" options. This iteration directly responded to internal feedback, resulting in a significantly clearer and more flexible interface for rule configuration.
Final Design
Final Design: Clear, Scalable, and Familiar
We finalized a layout that supported flexible configurations without overwhelming users. A few more highlights during the implementation phase:
• The team agreed on the scope of the approval step builder for v1.
• I proposed a cleaner, more readable "Read-Only" state that would display rules in natural language. While the team loved this concept, we postponed it for a future release due to engineering constraints.
• We did, however, implement a frequently requested enhancement from our invoice approval flow engine: showing the timestamp of when the flow was last applied.
This was a small but meaningful win that improved user trust and aligned with known pain points in the invoice approval engine.
Final Thoughts
Even without formal usability testing, this project was highly iterative. I continuously incorporated feedback from the product manager, my design manager, the engineering team, and our finance SMEs.
When we presented the final design to our beta customer, the response was entirely positive—an encouraging signal that we had solved a real workflow pain point. It also reinforced the value of staying close to internal stakeholders and using a systems-thinking approach when user research is limited.
This project highlighted the power of designing for flexibility and building scalable admin tools that support complex enterprise needs.
