Straight Through Processing for Healthcare Reimbursements: An Executive Decision Guide
Key takeaways
Virtual-card reimbursements can still create manual work: providers may receive card details by mail, key them in, and match deposits to remittance data.
STP automates the eligible virtual-card “last mile” after payer approval by moving card and remittance data electronically. It doesn’t replace claims adjudication or cover every payment type.
Whether or not STP fits your needs depends on your payer eligibility, volume, costs, workflow, and controls. Use a measured pilot to track speed, staff effort, exceptions, and reconciliation.
Receiving a virtual-card reimbursement doesn’t always eliminate manual work. Teams may still need to handle payment details and reconcile remittance information. For example, after an insurer approves a claim, the reimbursement is often loaded onto a virtual card, and the card details are mailed to the provider. Staff enter the details to process the payment, then match the deposit to remittance advice—the information explaining what the payment covers.
CSG Forte and Optum Financial have partnered to offer Straight Through Processing (STP) for eligible virtual-card reimbursements. With STP, patient card details are transmitted and processed electronically, without staff manually entering payment card information. By automating eligible parts of that process with tools like STP, your organization can process payments faster, simpler, and with fewer errors. This allows valuable human energy to remain focused on more complex tasks, like helping clients and patients.
Whether STP is a fit depends on how much of your reimbursement volume is eligible for virtual-card processing, how much manual work your current process requires, and the costs, systems, and controls involved. This article explains how to compare reimbursement payment options and choose an approach that fits your organization.
Start with the reimbursement mix
The first question is not, “Can STP automate payments?”
It’s, “Which of our payment streams could it reasonably address?”
STP is designed for virtual-card payment workflows for business-to-business payments from insurers and consumer-to-business payments made through payer or health-plan channels. O
Before evaluating a business case, your Finance and Revenue Cycle teams should establish:
Which payers send virtual-card reimbursements today?
How many transactions and dollars arrive through those streams each month?
Which transactions are insurer-related versus patient-related?
Which entities, locations, specialties, or tax IDs receive the payments?
Which payer programs are confirmed as eligible?
How much of the organization’s reimbursement would remain outside the evaluated scope?
This analysis prevents a common mistake: applying an attractive automation model to a payment category that represents too little volume, or isn’t supported for the organization’s payer mix.
Map the current workflow before discussing outcomes
STP changes the payment workflow after the payer makes the payment available. It does not replace claims adjudication. The payer continues to generate the virtual card, while payment and remittance data move electronically through participating merchant processors for acceptance, settlement, and posting.
Document the current process from payment availability through final reconciliation. Include every step, handoff, queue, and exception:
Payment details are received or retrieved.
Staff process the virtual card.
Payment and remittance information are matched.
The transaction is posted to the revenue-cycle workflow.
Exceptions are researched and resolved.
The deposit is reconciled to the bank, remittance, and general ledger.
Then quantify the work. Useful baseline measures include staff touch time per payment, time from payment availability to posting, time from posting to reconciliation, exception volume, unapplied cash, unmatched remittances, and the number of systems involved.
The goal is to determine where the existing process creates enough cost, delay, or control risk to justify evaluation.
Resolve the commercial case
A credible STP evaluation should compare total workflow cost—not simply the visible processing fee.
Ask your Finance and Procurement teams to model:
Current processor and network fees.
Labor cost associated with retrieval, card processing, posting, research, and reconciliation.
The cost of exceptions, unapplied cash, and delayed close activities.
Any lockbox, terminal, portal, or third-party costs that would change.
Fees associated with the proposed STP arrangement.
Costs that would remain for payment streams outside the scope.
The financial effect of routing payments to different entities or accounts.
A useful comparison is: Current cost per eligible payment versus projected STP cost per eligible payment, including labor, fees, exception handling, and implementation dependencies. That comparison should be built from your organization’s own data. Avoid using a generic savings calculator as the primary justification.
Test the operating and technical fit
An STP evaluation should include IT, Revenue Cycle, Finance, and the teams responsible for payment operations. The central question is where the payment and remittance data go after processing.
STP supports payment and remittance posting through participating merchant processors, with a common API framework for merchant-processor, and revenue-cycle integrations. That establishes a model for connected workflows, but does not mean that every provider’s electronic health records, practice-management system, or revenue-cycle platform is already integrated.
Resolve these questions before the pilot:
Which system remains the system of record?
How will payment and remittance data reach the posting workflow?
What data is available for B2B and C2B transactions?
Can staff identify the deposit, payment, remittance, and relevant reference information?
Which steps remain manual if a direct integration is unavailable?
How will exceptions be routed, tracked, and reported?
What access, security, banking, and underwriting requirements apply?
Who owns configuration changes and data-quality issues?
CSG Forte Dex offers transaction visibility, funding activity, reporting, and reconciliation, with 835 downloads available for applicable B2B transactions.
Assign ownership before automation begins
Automation does not eliminate accountability. It changes where people spend their time and where decisions must be made. It’s important to establish named owners for:
Eligibility and payer-stream selection.
Bank-account and entity configuration.
Daily transaction monitoring.
Exception review and escalation.
Posting-quality oversight.
Fee and invoice review.
IT or RCM integration support.
Provider education and change management.
STP offers exception handling when payments or remittance data cannot be automatically matched. That should be treated as a reason to design an exception process—not as evidence that exceptions will disappear.
For a health system, the pilot may need a central owner with local representatives from participating facilities or specialties. For a physician group, the accountable owner may sit in billing, revenue cycle, or finance. In either case, leadership should decide who can approve scope changes, who signs off on reconciliation, and who can stop the pilot if controls are not working.
Build a measured pilot scorecard
A pilot should answer a business question, not simply demonstrate that a transaction can be processed.
Define the population before launch. Use a specific payer, entity, specialty, location, or payment stream with enough volume to produce meaningful observations. Record exclusions so the results aren’t overstated.
A practical scorecard can include four categories.
Volume and coverage
Eligible transaction count.
Eligible payment dollars.
Percentage of the organization’s reimbursement represented.
B2B and C2B mix, where applicable.
Percentage of transactions successfully included in the pilot.
Speed and effort
Time from payment availability to deposit.
Time from deposit to posting.
Time from posting to reconciliation.
Staff minutes per payment.
Number of manual touches and systems used.
Exceptions and control
Exception rate and exception type.
Unapplied-cash balance and aging.
Unmatched remittances.
Reconciliation completion rate.
Data completeness.
Escalation volume and resolution time.
Audit or control issues identified during the pilot.
Economics and adoption
Total cost per eligible payment.
Processing fees and other direct costs.
Estimated labor cost.
Training and support effort.
User adoption and recurring workarounds.
Any volume or workflow changes that affected the comparison.
Use a representative baseline period and the same definitions before and after implementation. Product reports may support some measures, but the organization should also use its own bank, revenue-cycle, staffing, and general-ledger data.
Decide what evidence is enough
Set decision rules before results arrive. Scale the evaluation when eligible volume is material, the workflow is operationally stable, total cost is acceptable under the agreed methodology, reconciliation remains controlled, and accountable owners support broader deployment.
Change the design when results are mixed. A partial rollout may make more sense if one payer stream, entity, or specialty performs well while another produces unresolved exceptions.
Stop or defer when eligible volume is too small, commercial terms erase the expected value, required remittance data is unavailable, ownership is unclear, or the organization cannot reconcile deposits confidently.
The right conclusion may also be that STP is useful for one portion of the reimbursement mix while ACH, checks, or other workflows remain in place elsewhere. STP is not a universal reimbursement rail. Current materials describe it as focused on virtual-card payments, while ACH and other payment methods remain separate workflows.
CSG Forte’s STP in collaboration with Optum Financial can be a reasonable candidate for evaluation when the organization has eligible virtual-card volume, measurable manual work, and the governance needed to test a controlled change. The next step is to validate those conditions with your own payment and revenue-cycle data. If the case is credible, Talk to an expert about the current scope, eligibility, commercial terms, and implementation questions.
FAQs
What should a healthcare organization evaluate first before considering STP?
Start with eligible virtual-card volume, payer and provider availability, current manual effort, payment-to-remittance matching, total cost, and accountable ownership. Availability varies by payer and provider.
Does STP replace ACH or EFT?
No. STP focuses on virtual-card payment workflows. ACH and other payment methods remain separate reimbursement workflows and may continue alongside STP.
What should a healthcare STP pilot measure?
Measure eligible volume, staff effort, time to post and reconcile, exception and unapplied-cash levels, data completeness, total cost per payment, and user adoption. These are proposed evaluation measures, not guaranteed product analytics or outcomes.
Does STP eliminate the need for human review?
No. Exceptions, configuration questions, unmatched data, and financial decisions can still require human judgment. Optum describes exception handling for payments or remittance data that cannot be automatically matched.