Designing ERP Matching for Touchless AP Invoice Processing
Reducing time from upload to posted invoice through transparent AI matching, easy manual overrides, and business validations.
Overview
Snapshot
- Duration: Aug 2022 – Nov 2025
- Role: Product Designer (Lead, 0→1)
- Product stage: Commercial launch → sunset
- Team: 1 PM, 6 engineers (2 ML), 1 tech-lead
- Focus: ERP matching for touchless AP invoice processing
TL;DR
I had end-to-end design ownership of Lexana, from early discovery through commercial launch and sunset.
This case study focuses on ERP matching, the step that turns extracted AP invoice data into validated, ERP-ready documents. I designed matching as both a user workflow and an automation system, defining how AI suggestions, business rules, and manual overrides work together in practice.
Through continuous discovery and testing, I refined a productivity-first matching model with visible automation, explicit validations, and clear fallbacks. While the product was sunset shortly after launch and full measurement was not required, the work was guided by a clear north-star metric: Total Processing Time from upload to posted invoice.
* All the data seen in the mockups is fictional and for display purposes only.
Context & Constraints
Context
In August 2022, Boyum acquired Paperflow ApS, which had built a strong OCR and AI extraction layer called the Paperflow Engine.
Lexana was built as a plug-and-play ERP application on top of this engine, with the goal of delivering a native matching and posting experience for SAP Business One without requiring custom integrations for our customers.
Constraints
- Tech stack switch mid-project (Blazor/.NET → Angular)
- SAP Business One APIs imposed strict workflow limitations
- Design system and componenet library still evolving
- Missing key components (especially for data-heavy tables)
- First commercial product on a new cloud framework
The Problem: AP Processing for Supply Chain
AP invoice processing is a long and repetitive workflow.
For most of Boyum’s customers, AP is tightly coupled with supply chain operations. Invoices are expected to reference base documents such as purchase orders and goods receipts, and to pass a three-way match before they can be posted in the ERP. This ensures consistency between purchasing, logistics, and finance.
As a result, a significant amount of processing time is spent checking, correcting, and aligning data across documents and ERP fields. Even small mismatches can trigger manual decisions and exception handling, pulling finance and operations into time-consuming loops.
Where AP processing time accumulates. Manual data entry and line-level coding dominate user effort.
From Invoice Data to ERP Records
Matching is the step where extracted invoice data gets connected to ERP records/master data, such as suppliers, base documents, items, G/L accounts, VAT codes, and payment terms.
Without this step, an invoice cannot be created or posted to SAP.
Matching in Lexana is a two-step loop: the system pre-matches fields (AI), users fix exceptions, and those fixes become historical matches for next time.
Designing for automation, not just UI
Matching is presented to users as an interaction, but the long-term goal for Lexana is automation. The UI is not the product. Reliable automated matching is.
Alongside UI exploration, I worked closely with the PM and engineers to define how automatic matching should behave across different invoice fields. Instead of a single approach, we designed a system that applies different matching strategies based on the type of data.
For example, matching G/L accounts requires understanding the semantic meaning of an invoice line, not just labels or codes. Other fields rely on simpler techniques, confidence thresholds, and fallback rules. The result was a shared matching schema that defines when Lexana can apply a match automatically and when user input is required.
This schema directly shaped the interface:
- Auto-matched fields are visually distinct
- Users can override decisions
- Corrections are captured as learning signals
Understanding the ERP Reality
Through interviews with partners, end customers, and internal consultants, and by reviewing over 25 IDP competitors, I identified the following "realities" for ERP matching.
- 3-way matching (PO → GRPO → AP invoice) is essential for our target market in SBO
- ERP users think in the vocabulary and constraints of their system
- Matching design and ERP integration are tightly coupled
- Most IDP tools don’t support base-document matching
- Most competitors outsource their OCR/AI engine
Two key design iterations
Along the way, I explored many iterations, testing different labels, fields order, and layouts. The sections below focus on two key design directions that shaped the final solution.
Design Direction: Maximum Flexibility
I designed the matching flow to expose full context by expanding each invoice line into a detailed allocation table. Multiple columns acted as identifiers to help users choose the correct base document.
Usability testing showed that exposing too many options at once significantly increased cognitive load. Users had to scan, compare, and reason across multiple dimensions simultaneously, which slowed decision-making and made the workflow difficult to scale for high-volume invoices.
Key takeaway: Too many simultaneous options slowed users down and undermined processing efficiency.
Advanced allocation view exposing multiple base documents and identifiers for a single invoice line, increasing cognitive load and decision time
Simplified matching structure using a PO to GRPO hierarchy.
Design Direction: Structural Clarity
I simplified the matching experience by removing embedded tables and introducing a clear PO to GRPO structure. This reduced visual complexity and made the available options easier to follow.
However, testing showed that clarity alone was not sufficient. Users still had to expand invoice lines to act, and the underlying “allocation” model did not align with how users think about booking invoices. Even with fewer options, the interaction remained slower than expected for high-volume workflows.
Key takeaway: Structural clarity helps, but manual matching must be optimized for speed and minimal interaction cost.
These explorations clarified that reducing processing time required more than cleaner structure or increased control. Matching had to be designed around speed first.
Final direction: Productivity-first matching with visible automation
The final concept is designed for speed. I moved matching into a familiar, spreadsheet-like table with inline dropdowns, so users can quickly scan, choose, and move through lines without drilling into nested structures.
Auto-matched fields are clearly distinguished from manual matches, and users can override decisions at any time. Corrections are treated as learning signals so the system improves over time.
Final invoice processing UI. Slide to reveal the matching pattern.
green – invoice data, purple – ERP data
How it works (high level):
- Invoice data and ERP data are shown side-by-side so the match relationship is always visible
- Users can match fields inline using dropdowns (similar to ERP / Excel patterns)
- When the system is confident, it auto-matches and surfaces the result transparently
- When the system is uncertain, it falls back to user input without breaking flow
Context where decisions are made
When doing a manual 3-way match, it's essential for the users to get the full context to choose the right ERP objects.
For example, base documents selectors are shown as tables, so quantities, prices, descriptions, delivery times, etc. are immediately comparable. This mirrors SAP’s own document structures and avoids guesswork.
Safeguards before posting
We shipped basic business validations early, and they quickly proved their value.
In nearly every customer conversation the feedback was positive, and the users asked for more of them. There were multiple requests for us to automate as much as possible , and auto-post the invoice if there is nothing wrong with the data.
Inline warnings for mismatches, such as total amounts or tax discrepancies helped prevent posting mistakes and improved data quality.
The validations keep users in control, while making issues visible before they become costly errors.
Decision ownership (AI vs manual)
The system doesn’t explain how a match was made, but it clearly shows who made it.
Users instantly see whether a field was matched automatically or manually, building trust without exposing internal logic or meaningless confidence.
Measuring success (metrics)
We didn’t ship Lexana long enough to gather meaningful customer metrics, but from day one we aligned on a clear success signal: Total Processing Time (upload → posted invoice in ERP).
Processing time is the outcome. Auto-match performance is the lever, because it determines how much manual work users still need to do.
North Star Metric: Total Processing Time
Definition: time from document upload → posted invoice in ERP
Why it mattered:
- users care about throughput
- it’s comparable (“before vs after Lexana”)
- it reflects the whole system (OCR, matching, validations, approvals)
Example:
Upload timestamp: 23/07/2024 | 15:46
ERP posting timestamp: 23/07/2024 | 17:50
Total processing time: 2 hours 4 minutes
Leading Indicator: Auto-Match Performance
Processing time tells us if Lexana delivers value. Auto-match performance explains why performance improves (or doesn’t), by measuring how much matching the system handles and how often users trust it.
We planned to track:
- Auto-Match Coverage: How many matchable fields get a system suggestion?
- Auto-Match Accuracy: How often users accept suggestions without changing them?
- Auto-Match Score (combined): A simple blended score to summarise performance.
Example:
80 suggestions out of 100 matchable fields → 80% coverage
60 accepted out of 80 suggestions → 75% accuracy
(80% coverage + 75% accuracy) / 2 = 77.5% auto-match score
Outcome & reflection
Lexana launched commercially and pilot adoption confirmed demand for the product. At the same time, the IDP and AP automation space evolved quickly, with capabilities becoming more standardized and increasingly available across platforms, including natively within ERP ecosystems. In that context, the company made a strategic decision to retire Lexana and focus on domains where Boyum can deliver clearer long-term differentiation.
This clarified something important for me: shipping is not the finish line; sustained differentiation is.
Even so, we built a matching foundation grounded in ERP mental models, trust signals, and performance metrics.
Lexana was retired, but the work strengthened how I design automation, and sharpened how I evaluate opportunities where market timing matters as much as UX quality.
Copyright
© 2026 — Ionut Andrei Sacaleanu
Contact
Links
