- Home
- Industries
- Invoice-Based Payments
Invoice-Based Payments Across Industries
An Invoice Tells You What's Owed. Bonza Helps You Manage What Happens Next.
Connect invoice-driven customer payments with payment activity, receivables, due and overdue visibility, refunds, customer credits and configured gateways inside Salesforce with Bonza Payments.
Part of the Salesforce-native Bonza Payments suiteIllustrative invoice-based payment lifecycle for one sample customer whose Salesforce account context is connected. The invoice column shows invoice INV-1042 for an expected amount of $10,000.00 against a sample customer account. The payment activity column shows $6,000.00 collected through a relevant configured gateway. The current position column shows $4,000.00 outstanding, a relevant expected date and an overdue state where applicable. Beneath them, the question what happens next lists a further payment, a refund, customer credit, another payment event and operational attention. Every figure on this page is illustrative sample data and is not real customer data. Expected payment activity is not guaranteed collection.
Definition
What Are Invoice-Based Payments in Bonza Payments?
A short, direct answer for anyone comparing invoice, receivables and payment-management capabilities.
Invoice-based payments are customer payment workflows where a relevant invoice or payment obligation establishes an amount expected from the customer and subsequent payment activity changes the current payment position.
Bonza Payments helps businesses keep invoice-related payment activity connected with Salesforce customer context, receivables, payment status, refunds, customer credits and the wider payment lifecycle. The invoice states the obligation. The payment lifecycle states what has happened since, and payment management is the layer that keeps the two connected.
The operational gap
Creating the Invoice Is Usually the Easy Part.
The invoice establishes what is expected. Everything that follows is a question somebody in the business still has to answer, and an invoice record on its own answers almost none of them.
Was anything paid against this obligation at all?
How much was actually collected?
What remains outstanding right now?
Is the unpaid amount upcoming, due or overdue?
Which configured gateway handled the payment?
Has a refund changed the position since?
Does the customer have relevant credit recorded?
Does the customer need to make another payment?
Can Customer Service explain the current payment position without calling Finance?
Can Operations see what actually needs attention today?
The invoice starts the payment obligation. The operational work happens afterward.
The distinction that matters
Invoicing, Payment Processing and Receivables Management Are Three Different Jobs.
They are connected, and they are routinely treated as one thing. Separating them is what makes it possible to say where a problem actually lives.
Invoice
Answers: what is expected?- What amount is expected?
- What payment obligation exists?
- Against which customer?
Payment processing
Answers: what happened to the transaction?- Was the transaction authorised?
- Did it succeed or fail?
- Which provider handled it?
Payment & receivables management
Answers: where does the customer stand now?- What has been collected?
- What remains outstanding?
- Is it due? Is it overdue?
- Was there a refund?
- Does customer credit exist?
- What happens next?
The three are connected. They are not the same function, and a gap in one of them does not look like a gap in the others.
Invoice view ≠ payment position
Invoice Status and Payment Position Are Not the Same Thing.
Both of these describe the same $10,000.00 obligation on the same day. One of them is a document. The other is a position.
“What was expected?”
“What is the customer payment position now?”
One record explains the obligation. The other explains what has happened since.
Signature · the position moves, the invoice does not
The Invoice Is the Starting Point—not the End of the Payment Story.
Six moments in the life of one illustrative invoice. The record at the top is written once and never changes. Step through the moments and watch what does.
Invoice record · unchanged in all six moments
This band is written once in the page markup and nothing below it can change it. That is the point being made, not a limitation: payment activity does not rewrite the obligation, and the obligation does not describe the payment activity.
The invoice is raised · an amount is expected, nothing has happened yet
Obligation establishedThe invoice has done its job: it says what is expected. Every figure below it is still zero or unchanged, which is exactly why an invoice on its own cannot answer the question Finance actually asks.
This is the only moment where the invoice and the payment position agree with each other. From here they separate, and the invoice record above never moves again.
Moment 1, invoice raised. Collected zero dollars. Outstanding ten thousand dollars. Timing: upcoming, not yet due. Attention: none. Post-payment: none. The invoice record is unchanged.
No single step changes both the money and the timing. Moments 2 and 3 hold identical amounts and differ only in the date. Moments 3 and 4 do the same. That separation is what makes outstanding, due and overdue useful rather than interchangeable. All figures are illustrative sample data.
An invoice creates an expectation. Payment activity changes the reality. An invoice is an important business document, and it is not the complete payment story.
Expected → collected → open → attention
Invoice-Based Payment Management Should Answer Four Questions.
If a team can answer all four from the same customer record, invoice-based payments are being managed rather than merely issued.
What was expected?
The relevant invoice or payment obligation, and the amount it established against a specific customer.
ExpectedWhat was collected?
Payment activity recorded against that obligation through a relevant configured gateway.
CollectedWhat remains open?
The outstanding receivable: the part of the obligation that payment activity has not yet resolved.
OpenWhat needs attention?
Whether the open amount is upcoming, due or overdue, and any relevant payment signal a person should review.
AttentionWhere invoice-based payments appear
Different Industries. Same Invoice-to-Payment Pattern.
These describe payment patterns, not industry-specific Bonza features. Each entry states plainly what Bonza does not do in that sector, because the pattern being similar does not make the surrounding systems interchangeable.
Financial & professional services Client obligation
A client may receive a relevant invoice or payment obligation and make payment against it. The pattern is simple; the surrounding relationship usually is not, and the payment often needs to be readable next to everything else the firm holds about that client.
Connect payment activity and receivables with the wider client relationship in Salesforce. See Financial & Professional Services.
- Time billing
- Matter billing
- Trust accounting
- Project accounting
- Revenue recognition
Education Learner or payer obligation
A relevant learner or payer payment obligation may be represented through an invoice-based payment process where applicable. The person who owes and the person who pays are not always the same, which is precisely why the payment needs to stay attached to the right record.
Keep invoice-related payment activity connected with Salesforce. See Education.
- Tuition calculation
- Student accounting
- Financial aid
- Education ERP
Healthcare Customer obligation
A relevant customer payment obligation may exist where invoice-based customer payment workflows apply. Bonza operates on the customer payment side of that picture only.
Manage supported payment activity and keep it connected to the relevant Salesforce customer record.
- Medical billing
- Insurance claims
- Patient accounting
- Coding
- Adjudication
Technology & SaaS Invoice-driven, not only recurring
Some relevant customer payments may be invoice-driven rather than purely recurring. A customer on a repeating arrangement can still receive a separate invoice-based obligation, and both should be readable on the same account.
Connect invoice-related payment activity to Salesforce. See Technology & SaaS.
- Subscription billing
- Usage billing
- Proration
- Revenue recognition
- ARR or MRR management
Membership & associations Member obligation
Some relevant member or customer payment obligations may follow an invoice-driven model. Whether an obligation is met has no bearing on membership status, which is held in the membership system or CRM and is never set by Bonza.
Keep payment and receivables context connected. See Membership & Associations.
- Membership renewal logic
- Dues calculation
- Association management
Real estate & property Property-related obligation
Relevant customer payment obligations may be invoice-based where supported. Bonza describes the payment and its position, using neutral payment language rather than narrower terms that would imply functionality it does not provide.
Connect payment activity with the Salesforce customer relationship. See Real Estate & Property.
- Rent ledger
- Lease accounting
- Escrow
- Property accounting
Nonprofits Constituent obligation
Some relevant customer or constituent payment obligations may use invoice-based workflows where applicable. An invoice-based payment is not automatically a donation, and Bonza does not assume otherwise.
Manage the relevant payment activity and its position. See Nonprofits.
- Pledges
- Donations
- Grants
- Fund accounting
Other Salesforce-powered businesses Any obligation-driven model
Where a business creates relevant customer payment obligations and needs visibility into payment and outstanding amounts, Bonza can provide the payment-management layer where its supported capabilities fit. The qualifier matters: this is a payment pattern, not a claim of universal industry compatibility.
Provide the payment-management layer above the gateway. See Other Salesforce-Powered Businesses.
- Universal gateway compatibility
- Universal payment methods
- Vertical-specific functionality
The industry changes. The core payment model remains: obligation, then payment, then current position.
How it works
From Invoice to Current Payment Position.
This is how invoice payments work in Salesforce with Bonza: six stages, with the gateway doing the processing at stage three and Salesforce holding the context throughout.
Establish the payment obligation
A relevant invoice or payment obligation records what is expected, from which customer, and by when.
Present and manage the payment context
The relevant amount is presented with enough customer context that the payer can tell what they are paying, without exposing the organisation's internal payment architecture.
Collect the payment
Bonza passes the payment to a relevant configured gateway, which performs the underlying processing. Salesforce does not process money and Bonza is not the gateway.
Update the payment position
Collected and outstanding amounts are recorded against the customer, with due or overdue timing where relevant.
Manage what happens next
Further payment activity, a refund, customer credit or operational attention. Attention means a person reviews it; nothing on this path resolves itself.
Keep the history connected
Every step above stays attached to the same Salesforce customer and payment context, so the position never has to be reassembled from separate systems.
Invoice + payment processing
The Invoice Defines the Obligation. The Gateway Processes the Transaction.
Configured payment gateways perform relevant underlying payment processing, while Bonza manages the wider Salesforce-native payment lifecycle. Salesforce can be where an invoice payment is initiated and recorded; the money itself moves through the configured provider.
Inside Salesforce, above the gateway.
Performs the relevant underlying transaction processing.
- The customer and account context
- The invoice and payment obligation context
- The payment lifecycle: collected, outstanding, timing, refunds, credits
- The relevant underlying transaction processing
Invoice + receivables
An Invoice Without Receivables Context Only Shows Half the Story.
An invoice and a receivable describe related but different information. An invoice establishes a relevant payment obligation, while receivables visibility helps show what remains outstanding.
Illustrative.
Which one applies decides how soon somebody should look.
The invoice tells you the starting amount. Receivables tells you what remains open.
If the operational question is how Finance gets a clearer view of open items rather than how the lifecycle is structured, Improve Receivables Visibility approaches the same ground from the problem side.
Timing states
Not Every Unpaid Invoice Requires the Same Attention.
Outstanding, due and overdue are different payment states. An amount may be outstanding before it becomes due, while overdue indicates that the relevant expected date has passed.
Still unresolved. Some part of the obligation has not been met by payment activity.
This says nothing on its own about urgency. It is the amount, not the clock.
Outstanding, and not yet due. The relevant expected date is still ahead.
Visible, but not something a person needs to act on today.
Expected now. The relevant date has arrived and the amount has not changed.
A different queue from merely outstanding, and a different urgency.
Past the relevant expected date. Still the same amount as the day before.
The state most receivables reviews are built around.
Surfaced for human review. A person decides what happens next.
Bonza does not decide it for them, and does not resolve it on its own.
If every unpaid amount is treated as overdue, Finance loses the timing context required to understand what actually needs attention. That is the practical cost of collapsing four states into one.
Explore Due & Overdue Payments
For the operational programme rather than the capability, see Reduce Overdue Payments.
Payment patterns around the invoice
Some Invoice Payments Happen Once.
An invoice-based payment does not inherently need to recur. Relevant invoice obligations may be satisfied through individual payment activity, and the position afterward is what matters.
Explore One-Time & Ad Hoc Payments
Some Customer Relationships Combine Invoices and Recurring Payment Activity.
A customer can hold an invoice-based obligation and a recurring arrangement at the same time. These are two payment patterns, not two customers, and the payment history should still connect.
- An invoice-based obligation with a relevant expected amount and date
- Satisfied through individual payment activity
- Recurring payment activity on its own cycle
- Managed as a repeating arrangement, not as an invoice
A customer can have more than one payment pattern. The payment history should still connect.
Gateways
Keep Invoice Payment Management Above the Gateway Layer.
Invoice payments can use more than one configured gateway. What should not happen is each provider becoming its own separate invoice-payment operation with its own version of the truth.
Configured and chosen by the business, not routed automatically.
Explore Multiple Payment Gateways Manage Multiple Payment Gateways
The payer's side
Make It Clear What the Customer Is Paying.
An invoice-based customer payment experience should help the customer understand the payment obligation without exposing the organisation's internal payment architecture.
The relevant invoice or payment obligation.
Explore Customer Payment Experience Improve Customer Payment Experience
Connect Invoice-Based Payment Journeys With Salesforce Experience Cloud.
Customers can pay invoice-related amounts through Experience Cloud where a business already uses it for relevant customer interactions. The payment activity stays connected to the wider Salesforce environment rather than landing in a separate system.
The business's own portal. Bonza does not provide the entire portal.
Post-payment change
When Payment Value Changes, Update the Customer Payment Story—not Just the Transaction.
Bonza Payments can connect invoice-related payment activity with Salesforce customer context, receivables, due and overdue payment visibility, refunds and customer credits.
- Raised through the relevant configured refund process
- Stays attached to the payment it came from
- Updates the payment history rather than replacing it
A refund that happens somewhere else is how a collected figure stops being explainable. Keeping it attached is what makes the number legible later.
- Credit recorded and managed within Bonza Payments
- Available for relevant future payment use where supported
- Sits against the customer, not against a schedule
Customer credit does not reduce an outstanding amount by itself. A person decides whether it is used, and when.
Post-payment changes may alter how the original payment should be understood. Both belong to the same customer payment position.
Explore Refunds Explore Credit Management Simplify Refunds & Credits
Forward view
Invoice-Based Payments Can Create a Forward View of Expected Payment Activity.
Where upcoming payment activity is known, it can be shown alongside what has already happened. Expected payment activity is not guaranteed cash.
- Collected invoice-related payment activity
- Refunds and credits already recorded
- Outstanding
- Due
- Overdue
- Relevant expected payment activity where supported
Explore Payment Forecasting Forecast Upcoming Payments
Use AI to Surface Changes in the Invoice-to-Payment Lifecycle.
AI Payment Insights read the invoice, payment, receivables and timing context already present and point a person at what changed. The insight ends at the person.
- A relevant payment moved into overdue status.
- An outstanding payment position changed.
- Upcoming expected payment activity changed.
- A relevant payment situation deserves review.
- It is presented with its context
- A person reviews it
- A person decides the action
There is no credit-risk scoring, default prediction, autonomous collections, automatic customer outreach, automatic payment decision or autonomous write-off anywhere in this.
One operational view
See Invoice, Payment and Receivables Context in One Operational View.
An invoice payment dashboard should show collected, outstanding, due, overdue and upcoming, the receivables behind them, the payment activity that produced them, and what a person should look at today. Not a trial balance.
Illustrative Payment Command Center view for invoice-based payments. The KPI strip shows $124,500.00 collected, $38,200.00 outstanding, $9,400.00 due, $6,800.00 overdue and $22,000.00 upcoming, all illustrative. The receivables table lists four sample customers with their invoice, amount, outstanding amount and status. The payment activity table lists four sample payments with amount, configured gateway and status. The needs-attention panel lists an overdue payment, a relevant payment exception and an AI payment insight, each requiring human review. The recent activity strip lists an invoice-related payment, a refund, customer credit and a relevant upcoming payment. No general ledger, trial balance, profit and loss statement, balance sheet, journal entry, bank reconciliation, revenue recognition or tax accounting figure appears in this view, and none is provided by Bonza.
| Customer | Invoice | Amount | Outstanding | Status |
|---|---|---|---|---|
| Demo Customer | INV-1042 | $10,000 | $4,000 | Overdue |
| Sample Account | INV-1051 | $7,500 | $7,500 | Due |
| Example Client | INV-1058 | $14,200 | $5,200 | Upcoming |
| Test Organisation | INV-1063 | $21,500 | $21,500 | Upcoming |
| Customer | Payment | Amount | Gateway | Status |
|---|---|---|---|---|
| Demo Customer | PAY-2210 | $6,000 | Configured | Collected |
| Example Client | PAY-2214 | $9,000 | Configured | Collected |
| Sample Account | PAY-2219 | $2,400 | Configured | Collected |
| Demo Customer | REF-0114 | $500 | Configured | Refund |
INV-1042 · $4,000 outstanding, past its relevant expected date.
Human reviewA payment against INV-1051 did not complete through the configured gateway.
Human reviewThe outstanding position on Example Client changed after a recorded refund.
Insight · human reviewAll values illustrative sample data, not real customer data. This is a payment-management view, not an accounting dashboard: it shows no general ledger, trial balance, profit and loss, balance sheet, journal entries, bank reconciliation, revenue recognition or tax accounting, and Bonza provides none of those.
Invoice generation ≠ invoice payment management
Creating the Invoice and Managing the Payment Are Different Responsibilities.
Both are necessary. They are rarely the same system, and assuming they are is how the payment position ends up being reconstructed by hand.
“What should be paid?”
“What has actually happened?”
Good invoice-based payment operations connect both sides.
Two paths
Most Invoice Payments Should Follow a Clear Path. Exceptions Need a Different One.
The normal path is short and needs nobody. The attention path is longer and ends at a person every time, which is the honest description of what happens to an overdue amount.
Nothing needs a decision
Four steps, no review needed. This is the path most invoice-based payments follow, and it is the one worth making frictionless.
Ends at a person
Seven steps, and step six is a person. Bonza does not autonomously resolve overdue payments: it makes them visible with the timing context needed to decide.
What goes wrong
Six Invoice-Payment Mistakes That Create More Work Than the Invoice Itself.
Each of these is defensible in isolation. Together they are why Finance ends up rebuilding the same story every month.
Treating the invoice as the payment system
Connect invoice, payment and receivables so the document and the position can be read together.
Treating payment success as the end of the story
Understand the current payment position afterward, including what remains open.
Treating all unpaid amounts the same
Separate outstanding, due and overdue, so urgency comes from the timing rather than from a guess.
Using the gateway as the receivables view
Keep payment processing separate from payment-management context. The gateway knows transactions, not obligations.
Managing refunds and credits outside the original payment story
Connect post-payment events to the payment they came from, so the collected figure stays explainable.
Looking only backward
Add relevant expected payment visibility where supported, remembering that expected activity is not guaranteed cash.
The cost nobody budgets for
The Hidden Cost Is Reconstructing the Invoice-to-Payment Story.
Nobody plans this work. It simply appears, one customer question at a time, and it is the clearest sign that the invoice and the payment have come apart.
One route, one record, and the same answer whoever asks.
If Finance has to reconstruct what happened after every invoice, the payment operation is still fragmented.
Maturity
How Invoice-Based Payment Operations Mature.
A description of how these operations tend to develop, not a scorecard. There is no assessment here and no level is assigned to anyone.
Invoice-centric
The invoice is created. The payment is handled somewhere else, and the position has to be asked for.
Payment visible
Payment activity becomes easier to see, even if it still has to be matched to the obligation by a person.
Receivables connected
The obligation, the payment and the timing sit together on the customer.
- Invoice
- Payment
- Outstanding
- Due
- Overdue
- Customer context
Lifecycle connected
Post-payment change and the payer's own experience join the same story.
- Refunds
- Customer credits
- Configured gateways
- Customer-facing payment experience
Forward and attention driven
Wider operational awareness, with people still making the decisions.
- Payment Forecasting
- AI Payment Insights
- Payment Command Center
Across the business
One Invoice-Based Payment Story. Different Questions Across the Business.
Five teams, five sets of questions, one lifecycle underneath them. The questions do not need to be reconciled; the record they read does.
- What was invoiced?
- What was collected?
- What remains outstanding?
- What is due or overdue?
- What happened after the commercial event?
- What is still open?
The same connected record underneath every one of these questions, inside Salesforce.
- What needs attention?
- What is expected next?
- What did this customer pay?
- What remains open?
- Was there a refund or credit?
- How do we keep invoice and payment activity connected without building another isolated payment process?
The teams ask different questions. The invoice-to-payment story should still connect.
Team views in more depth: Finance & Accounts Receivable, Revenue Operations, Customer Service and Salesforce Teams.
Patterns
Common Invoice-Based Payment Patterns Across Salesforce-Powered Businesses.
Six situations that recur regardless of sector, and what connecting them actually changes.
A customer payment obligation is created and later collected.
Invoice and payment records become disconnected.
Connect payment activity with relevant Salesforce context.
Clearer payment history.
An invoice remains unresolved.
Finance needs to know what remains open.
Connect receivables visibility.
Clearer current position.
The outstanding amount reaches or passes its relevant due date.
Teams need to understand when attention is required.
Connect due and overdue payment context.
More useful operational visibility.
Payment value changes after collection.
The refund becomes disconnected from the original payment story.
Keep refund context connected.
Clearer payment history.
Relevant payment value becomes customer credit.
The future payment context becomes disconnected.
Record and manage customer credit in the wider payment lifecycle.
Better continuity.
Different relevant payment scenarios use different configured providers.
Invoice payment operations become provider-centric.
Maintain the wider Salesforce payment-management layer.
More consistent payment context.
Business outcomes
What Connecting Invoice and Payment Actually Changes.
Defensible outcomes only. There is no claim here about reduced DSO, faster invoice payment, higher collection rates, lower bad debt, specific productivity gains, specific cost reduction, specific ROI or guaranteed collection.
Keep the relevant payment obligation and payment activity connected on the same customer.
Understand collected, outstanding, due and overdue without assembling them by hand.
Distinguish unresolved from due and overdue, so attention follows the timing.
Keep refunds and customer credits tied to the wider payment story.
Use multiple configured payment providers through one broader payment-management layer.
Keep invoice-related customer payments connected to Salesforce.
Give Finance, Operations, Customer Service and Salesforce teams different views of the same lifecycle.
Use relevant Payment Forecasting where upcoming payment activity is known.
Why Bonza
Why Manage Invoice-Based Payments Through Bonza?
Eight reasons, each of them about continuity rather than about generating the invoice itself.
Keep payment activity connected with relevant Salesforce customer context rather than in a separate system.
Connect what was expected with what was actually collected.
Understand what remains outstanding and what its timing is.
Know when unresolved payment activity may require attention.
Keep refunds and customer credits connected to the original payment history.
Use multiple configured payment gateways without making each one a separate invoice-payment operation.
Connect invoice-related customer payments with internal payment context.
Use Payment Forecasting, AI Payment Insights and the Payment Command Center for broader operational awareness.
The wider lifecycle
Invoice-Based Payments Sit Inside the Wider Bonza Payment Lifecycle.
Not every invoice uses every capability. These are the parts of the suite an invoice-based obligation can touch as it moves from expectation to position.
The invoice starts the payment story. The rest of Bonza helps manage what follows.
FAQ
Invoice-Based Payment Questions.
Twelve questions buyers actually ask, answered against established product boundaries.
What are invoice-based payments?
Invoice-based payments are customer payment workflows where a relevant invoice or payment obligation establishes an amount expected from the customer and subsequent payment activity changes the current payment position. The invoice states what is expected; the payment position states what has happened since.
How do invoice payments work in Salesforce with Bonza?
A relevant invoice or payment obligation records what is expected against a customer. Bonza presents the relevant amount with its customer context, passes the payment to a configured gateway for processing, and records the resulting payment activity against the customer in Salesforce. Collected and outstanding amounts, due and overdue timing, refunds and customer credits are then managed as part of the same payment lifecycle.
What is the difference between an invoice and a receivable?
An invoice and a receivable describe related but different information. An invoice establishes a relevant payment obligation, while receivables visibility helps show what remains outstanding. One is the starting amount; the other is what is still open after payment activity.
What is the difference between outstanding, due and overdue?
Outstanding, due and overdue are different payment states. An amount may be outstanding before it becomes due, while overdue indicates that the relevant expected date has passed. The amount can be identical in all three; what differs is the timing, and therefore how soon a person should look at it.
Can Bonza connect invoices with customer payment activity?
Yes. Bonza Payments can connect invoice-related payment activity with Salesforce customer context, receivables, due and overdue payment visibility, refunds and customer credits. That connection is the purpose of the payment-management layer rather than an add-on to it.
Can Bonza show what remains outstanding after a payment?
Yes. Once payment activity is recorded, the collected and outstanding amounts are visible against the customer alongside the timing state of whatever remains open. The original invoice amount is unchanged by this, which is what makes the two readable side by side.
Can Bonza work with multiple payment gateways for invoice payments?
Yes. Invoice payments can use more than one configured gateway, with the payment-management layer sitting above all of them so each provider does not become a separate invoice-payment operation. Bonza does not perform smart routing, automatic failover, least-cost routing or automatic gateway retries.
Can customers pay invoice-related amounts through Experience Cloud?
Where a business already uses Salesforce Experience Cloud for relevant customer interactions, invoice-related payment activity can remain connected to the wider Salesforce environment. Experience Cloud does not process the payment, and Bonza does not provide the entire portal.
Can invoice-related payments be refunded?
A refund can be raised through the relevant configured refund process and stays attached to the payment it came from, so the payment history is updated rather than replaced. The refund is recorded as part of the same customer payment story rather than as a separate event elsewhere.
Can customer credit be used in a future payment?
Customer credit is recorded and managed within Bonza Payments and is available for relevant future payment use where supported. It sits against the customer rather than against a schedule, it does not reduce an outstanding amount on its own, and it is not a wallet, stored cash, a bank balance, stored funds or escrow.
Can Bonza show upcoming expected payment activity?
Bonza Payment Forecasting can provide forward visibility into relevant expected customer payment activity where supported. Expected payment activity is not guaranteed cash, and this is not revenue, treasury, cash-flow or bank-balance forecasting.
Does Bonza replace accounting software, ERP or revenue recognition, and does it chase overdue invoices?
No to all of these. Bonza Payments is not a general ledger, ERP or revenue-recognition platform. Its focus is customer payment management in Salesforce. It does not provide double-entry accounting, journal entries, a chart of accounts, tax accounting or bank reconciliation, and it does not automatically chase overdue invoices: there is no automatic dunning, no automatic reminders, emails or SMS, no late-fee calculation, no debt collection activity and no automatic write-offs. Overdue amounts are surfaced for a person to review and decide.
Invoice-Based Payments
Don't Stop at the Invoice. Manage What Happens After It.
See how Bonza Payments connects relevant invoice-based payment activity with Salesforce, receivables, due and overdue visibility, refunds, customer credits and configured payment gateways.