The Impact
Before we get into the process — this is what the redesign moved.
Avg. session time to create and submit a factoring unit, measured over the first 14 days post-release. Not a lab number — this is what randomly sampled users actually did.
Why it matters. For corporate treasury teams creating multiple FUs a week, 5 minutes saved per submission compounds fast. The process went from something people dreaded to something they don’t think about.
How we got here. The answer wasn’t a UI polish pass. It was removing a process step entirely — replacing a multi-file manual export with a single PDF upload and IDP extraction. The sections below explain the thinking.
Dissecting the Brief
“Users have been complaining about how tough our factoring unit creation process is.”
Before designing anything, I pushed back on two words.
“Users” — who, exactly?
Corporate treasury teams familiar with SAP S/4HANA ERP — not a general consumer audience. They were uploading invoice data they had already prepared in another system.
“Tough” — relative to what?
Relative to their ERP workflow, where invoice data was already structured and clean. Re-exporting a CSV and compiling a ZIP was redundant work layered on top of work already done.
Reframed problem. Users weren’t struggling to understand the product. They were frustrated at being asked to repackage data they already had — just to hand it back to us in a different format.
Discovery
I used four methods in sequence. Each pass narrowed the problem definition before the next.
Session recordings
Reviewed existing recordings to find drop-off, hesitation, and retry patterns. The CSV upload step showed the highest abandonment rate.
User interviews
Spoke with corporate treasury users. They described CSV preparation as a ‘translation tax’ — moving data from S/4HANA into a format KredX would accept.
User flow mapping
Drew the end-to-end flow from invoice creation in the ERP to submission on KredX. Every handoff, every file, every manual touch point.
SAP S/4HANA deep dive
Watched ERP tutorials to understand how users actually generate and manage invoice data. The critical finding: every field we required already existed in their system, accurately structured. The invoice PDF was the source of truth.
CSV formatting errors
Column mismatches, wrong delimiters, merged cells from Excel — the upload failed silently or threw cryptic error messages with no clear recovery path.
ZIP compilation overhead
Manually selecting, naming, and zipping invoice PDFs. Any filename mismatch between CSV rows and ZIP contents caused the entire submission to fail.
No partial recovery
One bad row in the CSV invalidated the whole factoring unit. Users had to fix, re-export, and re-upload the full batch from scratch.
The unlock. Every field we required — invoice number, amount, due date, counterparty — was already printed on the invoice PDF. The CSV was users manually transcribing their own documents for us.
Ideation & Tradeoffs
The natural solution was IDP — upload invoice PDFs, extract fields automatically. But one question kept surfacing before I could commit to the design direction.
Factoring units can carry invoice-level deductions — TDS, quality holdbacks, advance adjustments. In the old CSV flow, these were just columns. In a PDF-first flow, they’d need manual entry. For large batches, that could be a real problem.
The question that mattered. If we remove the CSV, how do users enter deductions across 50 invoices? Is that a real problem we need to solve upfront, or are we optimizing for a rare case?
So before designing around the assumption, I pulled the data.
The Redesigned Flow
The new flow replaced a three-step manual process with a single upload interaction, letting IDP do the work users had been doing by hand.
Upload invoice PDFs
Users drop their invoice PDFs directly — the same files they already have from S/4HANA. No reformatting, no renaming, no ZIP compilation required.
IDP auto-extraction
Intelligent Document Processing reads each PDF and populates all required fields — invoice number, amount, date, counterparty — automatically. Users review, not re-enter.
Modular deductions
Deduction entry is available as an opt-in step. It doesn’t impose on users creating standard factoring units, but it’s there when needed.
Eliminated the translation tax. The CSV required users to convert structured ERP data into a format we could read. IDP reads the source document directly — that overhead is gone entirely.
Reduced error surface. No CSV means no column mismatches, no delimiter errors, no merge-cell surprises. The primary failure mode of the old flow is removed at the architecture level.
Validation & Outcome
UAT with 5 users. Ran User Acceptance Testing with 5 corporate users before go-live. Sessions covered the full PDF upload → IDP review → submit flow. No significant blockers surfaced.
Shipped to production. The redesigned flow went live. All 5 UAT participants completed their first FU without assistance — no training material required.
Next: TDS percentage auto-apply. Planned improvement: allow users to enter TDS as a fixed percentage and apply it uniformly across all invoices in a FU — eliminating the last repetitive manual step for deduction-heavy cases.
Design principle. Don’t ask users to give you data they’ve already given to another system. If the invoice PDF exists, read the invoice PDF. The user’s job is to confirm, not transcribe.
By replacing a multi-file manual upload with a single PDF drop and letting IDP handle the rest, factoring unit creation went from a source of daily frustration to a routine background task.