Healthcare
What the Payer Covers Is One Question. What the Person Owes Is Another.
Bonza Payments manages the second one — the payment lifecycle around amounts a person is responsible for, connected to the Salesforce customer record. Claims, medical billing, revenue cycle management and clinical systems handle the first, and Bonza replaces none of them.
Salesforce-Native Payment Management — not medical billing
Two money questions, two different systems
Before the handover
“What will the payer cover?”
- Coding
- Claim submission
- Adjudication
- Remittance and denials
- Appeals
↓ the handover: an amount becomes a person's responsibility ↓
After the handover
“What does this person owe, and did they pay it?”
- Expected
- Collected
- Outstanding
- Due and overdue
- Payment plans
- Refunds and credits
- What is expected next
Bonza lives entirely on the right of that line. Everything on the left stays with the systems that already do it.
The landscape
Four Systems Touch Money in Healthcare. Bonza Is One of Them.
Knowing which is which prevents the most expensive kind of mis-scoping.
Clinical
Clinical system or EHR
What happened clinically, and the record of care.
Bonza holds no clinical record and no part of this.
Payer-facing
Claims and medical billing
Coding, submission, adjudication and what the payer will cover.
Bonza is not a medical billing system and performs no claim submission or adjudication.
Financial operations
Revenue cycle management
Posting, denial management, appeals and the wider revenue cycle.
Bonza is not an RCM platform and does not replace one.
Person-facing
Bonza Payments
The payment lifecycle for amounts a person is responsible for, connected to the Salesforce customer record.
This is the only one of the four that Bonza is.
Healthcare organisations rarely need a fifth system. They need the part that already exists in Salesforce — the relationship with the person — to know what that person owes and whether they paid.
The real problem
The Claim Closes. The Person's Balance Is Where the Story Goes Quiet.
Everything upstream is instrumented. The last stretch usually is not.
Most healthcare organisations have invested heavily in the payer side: coding, submission, denial management, remittance posting. That work is measured, staffed and reported on. Then an amount becomes a person's responsibility, and it leaves those systems for a statement, a portal that does not know the relationship, and a spreadsheet somebody maintains.
The result is familiar. Nobody can say quickly whether a person paid in part or in full, whether a payment plan is on track, whether an overpayment was refunded, or whether the card backing next month's instalment is about to expire. Not because the records are missing, but because they are not connected to the person they belong to.
“Patient payments are part of revenue cycle management.”
actually
RCM is built around the payer relationship. The person-responsibility balance is a customer payment lifecycle, and it behaves like one — expected, collected, outstanding, due, changed by refunds and credits.
“If we can take a card payment, we have solved it.”
actually
Taking the payment is the easy part. Knowing what remains after a partial payment, what a plan still owes, and what is expected next is the part that stays unanswered.
“The billing system already shows the balance.”
actually
It shows a balance. It rarely distinguishes outstanding from due from overdue, and it usually sits apart from the Salesforce record where the relationship with that person lives.
“We need a healthcare-specific payment product.”
actually
The payer side is genuinely healthcare-specific. The person-responsibility side behaves like any other customer payment lifecycle, which is why a general payment-management model fits it without pretending to be a clinical or claims system.
The hard part is not collecting the payment. It is being able to say, at any moment, where one person stands.
Ownership
Eleven Money Events, and the System That Owns Each One.
Move through them. The first four belong to other systems entirely.
One person's money story, end to end
1 of 11
A payment product that claimed all eleven would be claiming to be a clinical system, a billing system and an RCM platform at once. Bonza claims the last stretch, and says so.
One obligation
What a Person-Responsibility Balance Actually Does Over Time.
Eleven states. No single obligation passes through all of them.
The same obligation, throughout
1 of 11
This is a conceptual illustration of how different payment events can belong to one obligation. Most of the states above are marked as reached by some obligations only, and a balance paid in full on first request never enters them at all.
Where it applies
Healthcare Payment Scenarios That Behave Like Payment Management.
Five situations, none of which requires Bonza to touch a claim.
01
A balance paid across several instalments
Situation
A person agrees to clear a remaining balance over time.
Problem
The plan exists as a schedule somewhere, with no connected history and nothing visible about the next instalment.
Bonza model
A recurring obligation with its history behind it, the next expected payment ahead of it, and payment-method timing read against it.
Outcome
The plan's position is answerable without reconstructing it.
02
A partial payment that leaves a balance open
Situation
Someone pays part of what they owe.
Problem
The transaction succeeded, so the payment record looks closed while the person is not settled.
Bonza model
Collected and outstanding both recorded against the same obligation, with due and overdue kept distinct.
Outcome
Partial payment stops being invisible.
03
An overpayment that has to go back
Situation
Insurance later pays more than expected and the person has overpaid.
Problem
The refund becomes a separate event, detached from the payment it relates to.
Bonza model
A refund attached to the original payment, or value recorded as customer credit for supported future payment use.
Outcome
The post-payment story stays attached to the person.
04
Programme, membership or service fees outside a claim
Situation
Payments that never involve a payer at all — wellness programmes, memberships, courses, non-covered services.
Problem
They are too small to justify a billing system and end up in a disconnected process.
Bonza model
One-time and recurring payment activity against the Salesforce customer record, in the same model as everything else.
Outcome
No separate process per payment type.
05
Someone calls to ask what they owe
Situation
A person contacts the organisation about their balance.
Problem
The answer lives in a system the person on the phone cannot see from the customer record.
Bonza model
Payment position beside the Salesforce record: collected, outstanding, due, overdue, refunded, credited, expected next.
Outcome
The question is answerable while the person is still on the line.
By team
Different Teams, the Same Balance.
Four groups who ask about the same money in different words.
Patient financial services and billing operations
Needs to understand
- What remains after the payer settled
- What is outstanding, due and overdue — kept distinct
- Which plans are on track
- Which balances changed after a refund or credit
This team already owns the payer side well. The gap is usually the stretch after responsibility transfers. See the Finance and AR view.
Patient access and contact centre
Needs to understand
- What this person owes, right now
- Whether anything was refunded
- Whether credit exists
- What is expected next
These answers have to sit beside the customer record, because they are needed while someone is waiting. See the Customer Service view.
Operations and administration
Needs to understand
- What happened
- What is open
- What is expected next
- What deserves someone's attention
The coordinating view across person-responsibility payment activity. See the Business Operations view.
Salesforce team
Needs to understand
- Where the payment layer sits relative to clinical and billing systems
- What Bonza does and does not touch
- How payment records attach to the person
- What stays out of scope, permanently
The boundary question matters more here than in any other industry, because the adjacent systems are regulated and specialised. See the Salesforce design guidance.
What good looks like
What a Connected Person-Payment Model Should Be Able to Do.
Capability statements, not promises about collection rates.
Attach to the person
Every obligation traces to the Salesforce record for that person, not to a statement number in a separate system.
Survive partial payment
Collected and outstanding can both be true, and the difference between outstanding, due and overdue is preserved.
Hold a plan together
A repeating obligation keeps its history and its next expected instalment in the same place.
Keep reversals connected
Refunds and recorded credits stay attached to the payment they came from.
Look forward
Expected activity and payment-method timing are visible before the date rather than discovered afterwards.
Stop at the boundary
It does not drift into claims, coding, adjudication or clinical records, and says so explicitly.
Boundaries
What Bonza Is Not, Stated Before You Ask.
In healthcare this list matters more than the feature list.
Bonza Payments is not
A medical billing system
A claims or adjudication system
A revenue cycle management platform
Patient accounting software
A clinical system, EHR or EMR
A payment gateway, bank or acquirer
An accounting system, general ledger or ERP
A debt-collection agency
No compliance claim is made on this page
No healthcare-specific certification, attestation, audit report or compliance status has been established for publication, so none is claimed here. Nothing on this page should be read as a statement about HIPAA, protected health information handling, business associate agreements, data residency or any other healthcare regulatory requirement. Those questions are legitimate and usually decisive, and they have to be answered directly rather than inferred from a marketing page.
Bonza does not need to replace a billing, claims or clinical system to make the person-responsibility balance answerable.
Ask about scope and boundaries directlyOperational change
What a Connected Model Can Make Easier.
Qualitative only. No collection-rate or revenue claim is made.
- Clearer view of what a person owes after the payer has settled
- Partial payments and remaining balances visible in one place
- Outstanding, due and overdue kept distinct rather than collapsed
- Payment plans with history behind them and the next instalment ahead
- Refunds and recorded credits connected to the original payment
- Payment-method timing visible before the next expected instalment
- Payment position answerable beside the Salesforce customer record
- Fewer separate processes per payment type
None of the above is quantified. No collection-rate improvement, bad-debt reduction, DSO change, revenue increase, cost saving, ROI figure or productivity gain has been measured for Bonza, so none is claimed. No customer name, reference or case study appears on this page because none has been approved for publication.
Keep reading
Where to Take This Next.
Depending on which part you need to settle.
FAQ
Healthcare Payment Questions, Answered.
Including every question where the honest answer is a boundary.
Is Bonza Payments a medical billing system?
No. Bonza performs no coding, no claim preparation, no claim submission, no eligibility checking and no payer communication. Medical billing is a different system doing a different job. Bonza manages the payment lifecycle for amounts a person is responsible for, which begins after the payer side has determined what that amount is.
Does Bonza process insurance claims or adjudication?
No. Claim adjudication, remittance posting, denial management and appeals belong to claims systems and revenue cycle management platforms. Bonza does none of them and does not replace those systems. It picks up at the point where a balance becomes a person's responsibility.
Is Bonza patient accounting software?
No. Patient accounting and general accounting are separate disciplines with their own systems. Bonza is not an accounting system, a general ledger, an ERP or a treasury platform, and it performs no bank or settlement reconciliation. Seeing what a person still owes within the payment lifecycle is a different thing from accounting for it.
Does Bonza connect to an EHR or clinical system?
Bonza holds no clinical record and makes no claim about clinical system integration. It is a Salesforce-native payment management suite: it works with the customer and business context that lives in Salesforce. Whether and how an organisation connects clinical systems to Salesforce is a separate architectural question that this page makes no claim about.
Is Bonza HIPAA compliant?
No compliance claim is made anywhere on this site. No healthcare-specific certification, attestation, audit report or compliance status has been established for publication, so none is stated here, and nothing on this page should be read as a statement about HIPAA, protected health information handling, business associate agreements or data residency. These are legitimate and usually decisive questions, and the honest answer is that they need a direct conversation rather than a claim on a web page.
What part of healthcare payments does Bonza actually handle?
The payment lifecycle around amounts a person is responsible for: what was expected, what was collected, what remains outstanding, what is due or overdue, what repeats as a payment plan, what changed through a refund or recorded credit, what is expected next, and what may deserve review. All of it connected to the Salesforce customer record. Configured payment gateways perform the processing itself.
Can Bonza handle payment plans for a balance?
Yes, as recurring payment management: a repeating obligation with its history behind it and the next expected instalment visible ahead of it, including how payment-method expiry timing compares to that instalment. This is narrower than full subscription billing and includes no usage billing, metered billing or proration.
What happens when someone pays only part of what they owe?
Collected and outstanding are both recorded against the same obligation. This is the case a transaction result cannot describe on its own: the payment succeeded, and the person is still not settled. Keeping outstanding, due and overdue distinct is what tells a team whether anything needs following up.
How are overpayments and refunds handled?
A refund returns value to the person and stays attached to the payment it came from rather than becoming an unrelated record. Alternatively value can be held as recorded customer credit for supported future payment use. Recorded credit is not stored cash, not a bank balance and not a digital wallet, and Bonza does not hold money on anyone's behalf.
Does Bonza chase people for overdue balances?
No. Bonza surfaces balances that have gone overdue and positions that have changed, and hands them to a person. It performs no autonomous collections, no automatic customer outreach, no automatic dunning, applies no late fees, records no promises to pay, and is not a debt-collection agency. What to do about an overdue healthcare balance is a judgement that stays with the organisation.
Can people pay through a Salesforce experience?
Yes, where the organisation uses Salesforce Experience Cloud, payment experiences can be connected to it so the person-facing journey and the internal payment context describe the same obligation. Experience Cloud is the customer-facing environment; it does not itself process the payment, which remains the configured gateway's role.
Does Bonza work for payments that never involve insurance?
Yes, and these are often the most straightforward fit: wellness programmes, memberships, courses, non-covered services and other fees where no payer is involved at all. There is no claim, no adjudication and no handover — just a customer payment obligation, which is exactly what Bonza manages.
The last stretch
The Payer Side Is Already Solved. Talk About the Part That Is Not.
Describe what happens after a balance becomes a person's responsibility — how it is requested, tracked, paid, changed and followed up today. That is enough to have a useful conversation about whether the payment model fits.
The claim closes. The balance is where the work starts.