Case study

Sponsor Payment Reconciliation

Modernizing sponsor payment reconciliation around real-world financial workflows.

Role: Product Design Lead
Scope: Clinical Conductor + OnCore
Org: Advarra

A high-stakes clinical-research workflow where reconciliation errors carry real financial and regulatory consequences. We rebuilt it around the event users actually start from — a payment arriving — not the invoice the old system demanded first.

Challenge

A cumbersome, invoice-first workflow misaligned with how research orgs actually handle sponsor payments.

Approach

Customer research, then a payment-first redesign with role separation, smart matching, and automated records.

Impact

Faster, lower-error reconciliation at scale — adopted across both Clinical Conductor and OnCore.

Fig. A Case · Sponsor Payments

Realigning the workflow with reality

Before

01 Create invoice
02 Add study activities
03 Apply sponsor payment

Research insight
"A sponsor payment arrived." Users started here — not with an invoice.

After

01 Receive payment
02 Record payment
03 Reconcile
04 Generate records

Fig. B Case · Sponsor Payments

Outcomes

0 Setup steps before reconciling

Payments record on arrival — the old invoice-first sequence is gone.

2 products Cross-product adoption

Workflow and patterns adopted across Clinical Conductor and OnCore.

1,000s Entries per reconciliation

Smart filtering and matching handle thousands of activities in a single pass.

Overview

Clinical research organizations depend on accurate sponsor payments to maintain the financial health of their studies. Reconciling those payments against completed study activity is complex and time-consuming — multiple stakeholders, large volumes of data, and significant consequences when mistakes occur.

Within Clinical Conductor, the existing reconciliation workflow was cumbersome, difficult to learn, and misaligned with how users actually worked. Through customer research, workflow analysis, and iterative design, we reimagined the experience around real-world financial operations.

Problem

The process had evolved around system requirements rather than user workflows. It required users to create an invoice, add study activities, then apply payments against it. Technically sound — but not how organizations actually worked.

Through customer conversations, we discovered that users typically began with a different event entirely: a sponsor payment arrived. Only then would they determine what activities it covered and whether it aligned with expected revenue.

The system also struggled with real-world complexity:

Payments spanning multiple studies
Partial payments and overpayments
Missing invoices and outstanding balances
Large volumes of study activity

Constraints

Complex financial rules. Milestone payments, negotiated rates, visit-based compensation, and study-specific requirements.

Large data sets & multiple roles. Hundreds to thousands of activities per reconciliation — and the person entering payments was often not the person reconciling them. Everything had to remain traceable, auditable, and compliant.

Approach

We started with customer research across small sites and large research organizations — how payments were processed, who performed each step, where the friction was. The system’s workflow was fundamentally misaligned with users’ mental models.

Fig. C Case · Sponsor Payments

What the redesign was built on

Financial visibility Reporting & decision support

Automated records Invoices generated on apply

Role separation Entry vs. reconciliation

Workflow alignment Payment-first sequence

Customer research How work actually happens

Instead of forcing invoice creation first, we began with the event that triggered the work — a payment arriving — let entry and reconciliation be performed by different people at different times, surfaced relevant data for faster matching, and auto-generated invoices only when needed. The result extended beyond payment application into reporting that answered real business questions: accrued-but-unreceived revenue, overdue payments, and the financial status of a study.

Reflection

Software often reflects how organizations think work should happen rather than how it actually happens. The original workflow centered on invoices because invoices were seen as the primary object. Research revealed users started when a payment arrived — and that insight changed everything.

Successful enterprise UX isn’t about simplifying the business. It’s about helping users navigate complexity with greater clarity, confidence, and efficiency.