Automating HealthPay Reconciliation So Payouts Could Move at Business Speed

Payment systems look simple when a transaction succeeds.

A customer pays.
A provider receives money.
The business moves on.

But behind that simple moment sits a complicated financial chain: payment gateways, internal payment systems, benefit consumption, voucher usage, health coins, claims, settlement reports, bank credits, payout rails, provider accounts, failures, retries, reversals, and audit trails.

In HealthPay, that complexity had become an operating problem.

The business needed faster and more accurate settlement. Providers needed timely payouts. Finance needed control. Operations needed visibility. Product needed to make the entire flow scalable.

That was the core of the HealthPay Recon & Settlement Automation project.

I led this project as Lead PM in 2023, immediately after Service Guarantee. The goal was to automate pay-in and payout reconciliation across HealthPay, including doctor and lab payouts, with RazorpayX as the final payout rail.

The situation

HealthPay was not a simple payment collection product.

A single transaction could involve multiple components:

• customer-paid amount,
• voucher discount,
• HealthCoin usage,
• claim benefit,
• payment gateway settlement,
• PG charges,
• taxes,
• provider payout,
• lab payout,
• doctor payout,
• UTR,
• refund or failure state.

These components were distributed across multiple systems.

PayU and RazorPay handled payment gateway flows.
PayRx stored HealthPay transaction data.
HRx and DRx carried booking, benefit, and transaction context.
Labs systems contributed appointment and fulfilment data.
Voucherify, HealthCoin, and Claims represented benefit usage.
RazorpayX acted as the payout rail for doctors and providers.
Finance needed final settlement visibility.

The operating challenge was clear:

If each system holds only part of the truth, reconciliation becomes the process of rebuilding the truth every day.

Before automation, this meant manual reconciliation effort, open mismatches, delayed visibility, payout dependency, and controllership risk.

What was actually broken

The obvious problem was reconciliation effort.

But the deeper issue was that HealthPay’s payment ecosystem had too many partial ledgers.

Each source knew something, but no single source had the full picture.

Payment gateways knew the cash payment

PayU or RazorPay knew whether a payment was captured, failed, settled, or refunded.

But the gateway did not know the complete business context of the transaction.

PayRx knew the HealthPay order

PayRx had the internal HealthPay transaction record.

But it still had to match with gateway data, benefit consumption, settlement values, and payout status.

DRx / HRx knew the appointment and benefit context

These systems carried booking and benefit context, such as voucher, HealthCoin, claim benefit, and net payable amount.

But they were not the final settlement source.

Voucherify, HealthCoin, and Claims had benefit-level truth

Each benefit system knew its own utilization.

But final settlement required benefit values to reconcile with the order, provider payout, and net customer payment.

Finance needed the money trail

Finance needed the gateway settlement, bank credit, service fee, taxes, net received amount, and provider payout to agree.

This created multiple failure modes:

• count mismatch,
• amount mismatch,
• missing transaction,
• duplicate transaction,
• partial match,
• proposed match,
• open item,
• payout failure,
• invalid bank/UPI detail,
• delayed UTR,
• manual correction,
• unclear audit trail.

The problem was not just operational effort.

It was financial trust.

The product insight

The obvious product answer would have been:

“Build a reconciliation dashboard.”

But a dashboard alone would not solve the problem.

A dashboard can show mismatch.
It cannot automatically create trust.

The deeper insight was:

HealthPay needed a reconciliation operating system, not just a reporting screen.

That meant the product had to support the complete lifecycle:

1. ingest raw data,
2. validate data quality,
3. match transactions across systems,
4. identify exceptions,
5. route exceptions to manual review,
6. allow controlled correction,
7. audit every change,
8. trigger payouts,
9. track payout status,
10. give finance and operations real-time visibility.

The product had to move reconciliation from a manual exercise to a controlled system workflow.

What I shaped

As Lead PM, I owned the full HealthPay Recon & Settlement Automation project.

My ownership covered:

• PRD,
• user stories,
• dashboard design,
• matching logic,
• raw data ingestion requirements,
• manual upload fallback,
• exception handling,
• manual review flow,
• audit log requirements,
• maker-checker controls,
• payout triggering,
• operations review until stabilization.

The project covered both pay-in and pay-out automation.

It included doctor payouts and lab payouts.

API ingestion went live for all sources, while manual upload was retained as fallback.

Track 1: Pay-in reconciliation

The pay-in side had to reconcile money collected from customers.

Different payment scenarios required different logic.

Full PG payment

For a normal full payment, the system had to match:

• transaction count,
• transaction amount,
• payment gateway order ID,
• PayRx transaction ID,
• captured/success status.

This was the cleanest case.

Partial PG payment

Some payments were not fully paid by the customer.

A customer could use a combination of:

• voucher,
• HealthCoin,
• claim benefit,
• net customer payment.

In such cases, the product had to validate:

PayRx order amount = RazorPay amount + Voucher + HealthCoin + Claim benefit

This was more complex because the payment gateway saw only the net paid amount, while the business transaction included non-cash benefit components.

Benefit-only transaction

Some transactions could be completed using benefits without a full cash payment.

In those cases, reconciliation needed to validate benefit utilization across DRx, HRx, Voucherify, HealthCoin, Claims, and PayRx.

The system had to understand that payment value was not always equal to cash collected.

That was one of the central complexities of HealthPay recon.

Track 2: Benefit reconciliation

Benefit reconciliation was critical because HealthPay transactions could include more than money.

The system needed to reconcile:

• voucher usage,
• HealthCoin usage,
• claim benefit,
• net payable amount,
• gross order amount,
• transaction source,
• customer identity,
• provider context.

This made HealthPay different from a simple payment gateway integration.

The product had to reconcile both financial and non-financial instruments.

Without this, provider payouts would either be delayed, incorrect, or manually adjusted.

Track 3: Settlement reconciliation

Settlement was where finance trust was established.

The product had to validate the relationship between:

• payment gateway settlement report,
• service fee,
• service tax,
• net settlement amount,
• bank credit,
• PayRx transaction value,
• DRx / HRx transaction value.

The key question was:

Did the money that should have arrived actually arrive, after gateway charges and taxes?

This required matching transaction value, settlement value, and bank credit.

A mismatch here could not be treated casually. It had finance, audit, and provider-trust implications.

Track 4: Doctor and lab payout automation

The payout side was equally important.

Providers do not care how complex the reconciliation is behind the scenes. They care about when they get paid and whether the amount is correct.

The project covered both doctor and lab payouts.

RazorpayX was used as the final payout rail.

The payout design had to account for:

• appointment booking value,
• net amount received,
• benefits applied,
• PG charges,
• provider payable amount,
• payout trigger,
• payout status,
• UTR,
• payout failure,
• retry or manual action.

The target was to move payouts reliably to T+1.

That became one of the most important operational outcomes.

Track 5: Raw data ingestion and visibility

Automation cannot work on bad data.

So the product first needed strong raw data ingestion and visibility.

The system supported:

• API ingestion from all sources,
• manual upload as fallback,
• raw data visibility,
• source-wise data tables,
• import date and time,
• import method,
• API response visibility for authorized users,
• issue highlighting.

This was important because operations and finance teams needed to trust the data before trusting automation.

If a transaction did not match, users needed to know whether the issue came from the transaction itself, the source file, the API response, a missing value, or a manual correction.

Track 6: Matching engine

The matching engine was the heart of the product.

It had to compare records across systems using defined identifiers and validation rules.

The matching logic included:

Transaction count check

The first level was count validation.

If one system had extra transactions, the system had to identify:

• which transaction was extra,
• which source it came from,
• whether it should move to manual review.

Transaction amount check

The second level was amount validation.

If the amount did not match, the system had to apply exception logic and then decide whether the record was:

• matched,
• partially matched,
• proposed match,
• open item,
• manual review required.

This moved reconciliation from spreadsheet comparison to system-led matching.

Track 7: Manual review and exception management

No reconciliation system can assume that every case will match automatically.

The product had to support exceptions properly.

Manual review was designed for cases such as:

• count mismatch,
• amount mismatch,
• failed payout,
• invalid VPA,
• invalid account,
• invalid UPI,
• beneficiary bank downtime,
• processing payment stuck,
• failed/reverted payment,
• open items.

The product supported:

• manual review queue,
• email notifications,
• PayRx UI notifications,
• exception details,
• action options,
• retry/reinitiation,
• failure handling,
• stakeholder notification.

This was important because automation without exception handling simply shifts the problem elsewhere.

Track 8: Audit logs and controllership

Financial automation needs strict governance.

The product included:

• role-based edit permissions,
• full audit logging,
• maker-checker approval,
• edit reason capture,
• before and after values,
• editor identity,
• update timestamp,
• transaction timeline,
• manual payout approval controls.

Every manual correction was audit-logged.

Maker-checker approval existed for edited raw data and manual payout.

This made the system suitable for finance operations, not just product reporting.

The principle was:

Users can correct data, but the system must remember exactly who changed what, when, why, and what the value was before and after.

That is what made the product controllership-ready.

Track 9: Recon and settlement dashboard

The dashboard was designed to give leadership, finance, and operations visibility into reconciliation health.

It showed payments by:

• matched,
• partial match,
• proposed match,
• open,
• total.

It supported count and amount visibility across payment sources.

It also supported open item tracking and trend views.

The goal was to let teams answer:

• How much is fully reconciled?
• How much is partially matched?
• What is still open?
• Where are the exceptions?
• Which source has issues?
• What needs manual action?
• Are open items increasing or decreasing?

This turned reconciliation from a backend activity into an operationally visible process.

How the workflow changed

Before automation, the workflow looked like this:

Download reports → compare transactions manually → identify mismatches → check benefit data → validate settlement reports → coordinate with finance/ops → trigger payout manually → track failures manually → maintain audit trail separately.

After automation, the workflow became:

Ingest source data → validate raw data → run matching engine → classify matched/partial/open items → send exceptions to manual review → apply controlled correction if needed → approve through maker-checker → trigger payout → track status and UTR → view dashboard and audit trail.

This was a fundamental shift.

The old workflow made people reconcile data.
The new workflow made the system reconcile data and made people handle exceptions.

What made this hard

This project was hard because reconciliation problems are unforgiving.

A small mismatch is not a UI bug. It can delay payout, create provider escalation, distort finance reporting, or create audit risk.

Several challenges made this complex.

Multiple systems carried partial truth

No single system had the full picture. The product had to stitch together the truth across payment, benefit, booking, settlement, and payout systems.

Cash and non-cash components had to reconcile together

A transaction could include PG payment, voucher, HealthCoin, and claim benefit. That required business-specific matching logic.

Finance required trust and traceability

Automation was not enough. Every exception, edit, payout, and manual correction needed governance.

Payouts affected provider trust

Doctors and labs expected timely settlement. Delays could create escalations and damage trust.

Fallbacks were still needed

API ingestion went live for all sources, but manual uploads were retained as fallback. That was the right product decision because financial operations cannot stop if one integration fails.

What was achieved

The HealthPay Recon & Settlement Automation project went live with all major capabilities:

• dashboard,
• raw data ingestion,
• API ingestion from all sources,
• manual upload fallback,
• matching engine,
• manual review,
• audit logs,
• role-based edit permissions,
• maker-checker approval,
• payout triggering,
• RazorpayX payout flow.

The project completely automated the reconciliation process and eliminated manual reconciliation effort.

Payouts moved to T+1.

Payout delays and provider escalations reduced.

The project improved:

• payout TAT,
• settlement accuracy,
• auditability,
• compliance,
• financial controllership,
• provider payout confidence,
• operational visibility.

The primary metrics were payout TAT and settlement accuracy.

No before/after numeric metrics are available, so the strongest accurate statement is:

The reconciliation process became completely automated, manual reconciliation effort was eliminated, and payouts moved to T+1.

Why this mattered for HealthPay

This project strengthened HealthPay’s financial operating foundation.

A payment product cannot scale if reconciliation is manual.
A provider network cannot trust the product if payouts are delayed.
Finance cannot support growth without accurate settlement controls.
Operations cannot manage exceptions without visibility.

By automating reconciliation and payout workflows, HealthPay gained the financial infrastructure needed to scale transaction volume, support provider trust, and reduce operational dependency.

What this says about my product approach

This project reflects my ability to work on deep operational and financial systems where product quality is measured by control, accuracy, and reliability.

The product was not glamorous in a consumer-facing sense. But it solved a critical business problem.

It required thinking across:

• payment flows,
• benefit utilization,
• settlement logic,
• payout rails,
• exception handling,
• finance controls,
• auditability,
• operational fallback,
• dashboard visibility.

The key product principle was:

Automate the predictable, isolate the exceptions, and make every manual action auditable.

That principle made the system scalable and trustworthy.