Reporting is the capability that health plans most consistently underestimate when evaluating premium billing software. A billing platform that cannot show you an accurate aging report, break down delinquency, or export raw transaction data to your data warehouse will constrain your billing operations every day. Certifi’s William™ platform, built on the Perfect Balance™ accounting architecture, ships with a complete operational and performance reporting stack and exposes billing data for member portals and analytics platforms. This post covers the specific questions to ask every vendor before you sign.
The reason reporting gets shortchanged in evaluations is that vendors rarely demo it. The demo defaults to invoice generation, payment processing, and delinquency workflow screens. These are the visually engaging parts of a billing platform. Reporting is shown briefly, usually with a canned screenshot of an aging report that looks clean because it contains fabricated data. Buyers walk away thinking reporting is fine. Then, go-live happens, and the finance team discovers they cannot get the delinquency breakdown they need, and exporting raw transactions to the data warehouse requires a manual process. This post is designed to help you avoid that outcome.
Why Reporting Deserves More Evaluation Time Than It Gets
Reporting in a billing platform serves three distinct audiences. Each audience has different needs and a different relationship to billing data. Understanding this before you evaluate helps you ask the right questions of the right people during the assessment.
The billing operations team uses reports daily to manage exceptions. They need the aging report to prioritize follow-up, the suspense report to process unmatched payments, the delinquency report to track delinquent accounts, and the remittance report to review the remittance process. These reports need to be fast, filterable, and accurate. A report that takes 15 minutes to run, cannot be filtered by line of business, or lags actual transaction activity by 24 hours, is not operationally useful, regardless of how complete it looks on a spec sheet.
The finance and leadership team uses reports periodically to monitor performance, support audits, and manage revenue. They need trend reporting across billing periods, collection rate performance by segment, and general ledger integration data for financial close. A billing platform that serves the billing operations team well but cannot produce the data the finance team needs for CMS compliance is only half a reporting solution.
The data and analytics team needs access to raw transaction data for the health plan’s data warehouse, member portal, and analytics platform. They typically don’t access reports inside the billing platform. They need an API or data export that delivers billing data to their systems.
Most billing platform demos address the first audience adequately and the second partially. The third audience is almost never addressed in a standard demo unless you ask specifically. All three matter.
The Standard Reports Every Billing Platform Should Ship
Before getting to the harder questions, confirm that the platform ships these standard operational reports natively — without custom development, add-on modules, or third-party reporting tools:
Aging report
Outstanding balances segmented by age bucket: current, 30 days, 60 days, 90 days, 90-plus days. Filterable by line of business, employer group, plan, and member population. The aging report is the daily working tool for collections prioritization. If it cannot be filtered by segment, it is not operationally useful for a health plan serving multiple market segments simultaneously.
What to ask: Can this be filtered by ACA, Medicare Advantage, Medicaid, and commercial? Can you export it to Excel or CSV directly from the interface? How current is the data? Is it real-time or the end of the prior business day?
Delinquency report
Accounts in the delinquency workflow are detailed by days delinquent. This report drives daily delinquency management and should show each member’s current position in the workflow at a glance.
What to ask: Does it distinguish between APTC and non-APTC members since they have different delinquency workflows? Can you see which phase of the APTC grace period a member is in? Can you filter by the delinquency event to identify all members in a specific delinquency workflow?
Suspense report
Payments received but not yet matched to a member account. This is the daily exception queue for payment matching staff.
What to ask: What information does each suspense record show? How old can items in the suspense queue get?
Remittance report
Record of what should be remitted to external entities like technology partners, brokers, or other carriers.
What to ask: What level of detail can be provided? What filters are available?
Invoice and payment detail
Member-level detail of every invoice generated and every payment received in a given period. Necessary for member dispute resolution, invoice or payment analysis, or audit support.
What to ask: Does the payment detail report show the payment method? Does it show refunds, moves, and non-sufficient funds (NSF)? Does the invoice detail show relevant invoice data like the month, statement date, due date, remaining unpaid amount, and other relevant information?
Demo requirement
Ask to see all five of these reports in a live demo with real (sanitized) data, not a screenshot. How fast they load, how easily they filter, and how clearly they present exception information tell you more about reporting quality than any specification document.
Ad Hoc Reporting: The Question Most Buyers Forget to Ask
Standard reports cover the expected questions. Ad hoc reporting is what you need when the question is not on the standard report list. In health plan billing operations, unexpected questions are routine.
Examples of ad hoc reporting needs that arise regularly:
- Which employer groups had a payment discrepancy of more than $500 in the last 90 days?
- How many members enrolled in the silver plan in the Midwest region have an outstanding balance older than 60 days?
- Which members have had more than three retroactive adjustments in the current benefit year?
None of these is a standard report. Each requires the ability to filter, segment, and combine billing data in ways that the standard report library does not anticipate. Health plans that cannot answer these questions without submitting a custom report request to IT or the vendor are operating with blind spots in their billing operations.
How billing platforms handle ad hoc reporting
Billing platforms handle ad hoc reporting in one of three ways:
- Built-in ad hoc report builder: The platform includes a report builder that allows operations staff to construct custom queries against billing data using a no-code interface. This is the most operationally capable approach and requires no IT involvement for routine analytical questions.
- Data export to external analytics tools: The platform exports raw transaction data in a format that can be loaded into Excel, Tableau, Power BI, or the health plan’s data warehouse. Ad hoc analysis happens outside the billing platform in the health plan’s preferred analytics environment. This requires some technical capability but gives analysts full flexibility.
- Custom report development by the vendor: Ad hoc reports require submitting a request to the vendor’s development team, waiting for scoping and prioritization, and waiting for delivery. This is the least useful approach. It means the billing team cannot answer urgent analytical questions in real time and accumulates a backlog of reporting requests.
Most billing platforms use a combination of the first two approaches.
Raw Data Access: What Happens When You Need to Leave the Platform
Every health plan’s billing data ultimately needs to live in more places than the billing platform. The finance team needs it in the general ledger. The analytics team needs it in the data warehouse. The member portal needs it to show current balances. The member services CRM needs it to surface payment history for reps. The executive dashboard needs it for revenue trend reporting.
The question is not whether the billing platform needs to share data. The question is how.
API access
The most capable modern billing platforms expose billing data via REST API, allowing authorized systems to retrieve current balance, invoice history, payment history, and delinquency status in real time on a per-member basis. This is the integration that powers live billing data in the member portal. When a member logs in and sees their current balance, they are seeing data pulled from the billing platform via API in real time rather than data synced the previous night.
What to ask: What billing data is available via API? Is it real-time? What authentication is required? What is the rate limit? Does the vendor provide API documentation for integration development?
Flat file export
Most health plans also need a scheduled flat file export. This daily or weekly file contains all billing transactions in a defined format that loads into the data warehouse or general ledger. This is separate from the API and serves different purposes: batch analytics, financial reporting, and historical data archiving.
What to ask: What is the default export format? Can the schema be customized to match the health plan’s data warehouse requirements? How frequently can exports be scheduled? Is there a full transaction history export available?
Data ownership and portability
This is the question most health plans do not think to ask until they are in a contract termination discussion: when you leave the platform, what happens to your data?
Ask every vendor before you sign: What is the process for exporting a complete transaction history upon contract termination? In what format is the data delivered? What is the timeline? Is there a fee? A vendor that is vague, slow, or expensive about data export at contract termination is signaling that data portability was not a design priority.
Certifi and data access
William exposes billing data via REST API for real-time member portal data, supports scheduled flat file export for data warehouse loading, and provides complete transaction history export API documentation that is available during integration development.
The Reporting Evaluation Questions to Ask Every Vendor
Use these questions in every billing platform evaluation. The answers reveal whether the vendor designed reporting as a core capability or added as an afterthought.
Can you show me the aging report, delinquency report, and suspense report in a live environment with real data?
If the vendor pivots to screenshots or a demo environment with fabricated data, that is a signal. Ask again — specifically for live data.
How does the aging report handle a health plan serving ACA, Medicare Advantage, Medicaid, and commercial employer groups simultaneously?
The answer should describe population-level filtering. If the aging report is aggregate only, you will not be able to manage collections by segment.
Does the platform have a built-in ad hoc report builder, or do custom reports require vendor development?
Either a built-in builder or a robust data export for external analytics is acceptable. Vendor-dependent custom report development is not.
What billing data is available via API, and is it real time or cached?
Real-time API access to current balance and payment history is the standard for modern platforms. Batch-only data access means your member portal billing data will always lag.
What is the process for exporting our complete transaction history if we terminate the contract?
Ask this before you sign. The answer tells you whether the vendor views data portability as important or as an afterthought.
Can I talk to a member of your current client’s billing operations team about how they use reporting day to day?
References focused specifically on reporting rather than general platform satisfaction will tell you whether the reporting delivers in production what it promises in the demo.
Frequently Asked Questions
What reports should health plan billing software include as standard?
Health plan billing software should ship natively with at least five key operational reports: an aging report showing outstanding balances by age bucket and filterable by line of business; a delinquency report showing delinquent accounts; a suspense report showing unmatched payments; a remittance report showing funds to be remitted to partners, brokers, or other carriers; and member-level invoice and payment history. Reports that require custom development to produce are a capability gap, not a standard feature.
How should premium billing software handle APTC reconciliation reporting for ACA marketplace plans?
APTC reconciliation reporting should show the expected subsidy amount for each APTC-eligible member in a payment period alongside the amount actually received in the monthly exchange payment, and flag discrepancies between the two. Health plans that manage APTC reconciliation through manual spreadsheets outside the billing platform find it both operationally burdensome and difficult to defend in a CMS compliance audit.
What is ad hoc reporting in premium billing software, and why does it matter?
Ad hoc reporting is the ability to construct custom queries against billing data to answer questions that the standard report library does not anticipate. In health plan billing operations, these questions arise regularly: which employer groups had payment discrepancies above a threshold, what is the payment rate for a specific delinquency notice stage, and which members have had multiple retroactive adjustments in the current benefit year. Billing platforms handle ad hoc reporting in three ways: a built-in no-code report builder, data export to external analytics tools, or vendor-dependent custom report development. The first two approaches support operational decision-making in real time. The third creates a reporting backlog and analytical blind spots.
How should health plan billing software provide raw data access for analytics and reporting?
A modern billing platform should provide two data access mechanisms. First, a REST API that allows authorized systems to retrieve current balance, invoice history, payment history, and delinquency status per member in real time. This is the integration that powers live billing data in the member portal and member services CRM. Second, a scheduled flat file export for loading into the health plan’s data warehouse or general ledger. Ask every vendor what billing data is exposed via API, whether it is real-time or cached, and what export format options exist for data warehouse loading.
What should health plans ask about data portability before signing a billing software contract?
Before signing any billing software contract, ask the vendor specifically: what is the process for exporting a complete transaction history if we terminate the contract, in what format is the data delivered, what is the timeline for delivery, and is there a fee? A vendor that answers these questions clearly and without hesitation has designed data portability into the platform. A vendor that is vague, requires a negotiated process, or charges a significant exit fee for data export has not. Data portability is not a clause to negotiate at termination. Health plans should define it in the contract before signing, with a specific format, timeline, and cost commitments documented.
Related Resources
For deeper coverage of the topics in this post:
Premium Billing Software Features and Capabilities
Evaluating Premium Billing Software Vendors (Knowledge Center):
ACA and Regulatory Compliance in Premium Billing
Premium Billing for Health Plans: Questions Answered
Certifi’s health insurance premium billing and payment solutions help healthcare payers improve member satisfaction while reducing administrative costs.
