Payment Reconciliation

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. Often alongside it came a remittance — the sponsor’s own record of which activities, captured in systems like Epic, the payment was meant to cover. But sponsors didn’t always send one, which left the site to reconstruct that matching itself.

The system also struggled with real-world complexity:

• Payments spanning multiple studies
• Partial payments and overpayments
• Remittances that were missing, incomplete, or inconsistent with site records
• 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.

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, and auto-generated invoices only when needed. Amounts that once required manual entry are now calculated automatically, over- and underpayments are handled without workarounds, and activities can be found, filtered, and sorted instead of scanned by hand. The same flow now works whether or not a sponsor sends a remittance — when one arrives, its activities are matched automatically; when it doesn’t, the site can reconcile directly against its own records just as easily. 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.