CPA Calls vs Duration-Based Calls: How Settlement Changes

CPA calls and duration-based calls can begin with the same basic event: a consumer calls, the call routes, and a buyer answers.

What happens financially after that is very different.

In a duration-based campaign, settlement can usually begin when the call is complete and the recorded duration can be compared with the agreed thresholds.

In a CPA campaign, call completion is only the beginning. The operation may need to wait for a sale, enrollment, appointment, retained case, funded transaction, or another defined outcome. That event must be reported, matched to the correct call, checked for duplication, accepted under the applicable rule, and sometimes held through a reversal window before it belongs in an invoice or payout batch.

That distinction changes:

• When buyer revenue is earned.
• When publisher payout is earned.
• Which evidence matters.
• How duplicates are detected.
• How corrections work.
• When records become invoice-ready or payout-ready.
• Which side carries more timing and reporting risk.

This article focuses on settlement: the process that turns a call or conversion outcome into explainable buyer charges and publisher earnings.

For the broader commercial comparison, start with Duration-Based Call Buying vs CPA Call Buying. Here, we will stay closer to the finance and operating record.

The short answer

The simplest distinction is this:

Duration-based settlement asks whether the completed call met the applicable duration rule. CPA settlement asks whether a separately defined conversion event happened and can be attributed to the call.

That difference affects almost every downstream step.

Neither model is automatically cleaner.

Duration-based settlement is easier to trigger, but only if call completion and duration are trustworthy.

CPA settlement is closer to a downstream business result, but only if outcome reporting is timely, specific, and auditable.

Settlement is not the same as routing or payment

Pay-per-call teams often use “settled” loosely.

A call can be:

• Routed to a buyer.
• Connected to an agent.
• Completed by the telephony provider.
• Qualified under a buyer rule.
• Billable to the buyer.
• Payable to the publisher.
• Entered into the financial ledger.
• Included in an invoice.
• Included in a payout report.
• Paid by the buyer.
• Paid to the publisher.

Those are separate events.

For this article, settlement means the financial decision and record that determine whether buyer revenue and publisher payout were earned, under which rules, for what amounts, and with what supporting evidence.

Settlement creates the financial facts that later feed invoices, payout reports, disputes, credits, and reconciliation.

It does not necessarily mean cash has moved.

Duration-based settlement begins with a completed call

A duration-based campaign normally has enough information to evaluate the call soon after the call ends.

The operation needs a reliable completed-call record that includes the duration used for qualification.

A practical settlement flow looks like this:

1. The call routes under a defined campaign and buyer target.
2. The route records the commercial terms or rule versions that apply.
3. The telephony provider reports the completed call and measured duration.
4. The operation checks duplicate and other billing policies.
5. The buyer duration rule is evaluated.
6. The publisher payout duration rule is evaluated.
7. Buyer revenue and publisher payout entries are recorded according to their separate outcomes.
8. Eligible entries move into the applicable invoice and payout periods.
9. Exports reconcile the detail to the batch totals.

The entire financial decision can happen without waiting for the buyer to report a sale.

That is the main operational advantage of duration-based settlement.

The duration must come from a defined source of truth

“Call duration” can mean several things:

• Total call length from inbound start to disconnect.
• Buyer-leg connected duration.
• Talk time after answer.
• Time including ringing.
• Time including hold.
• Time after a transfer handoff.
• Platform-calculated wall-clock time.
• Provider-reported completed duration.

The parties need to know which measurement governs settlement.

A duration threshold is not dependable if the invoice uses one timer, the buyer report uses another, and the publisher dashboard shows a third.

The settlement record should preserve:

• The measured duration.
• The duration source.
• The buyer threshold.
• The publisher threshold.
• The rule version or effective terms.
• The qualification result for each side.

See why call-duration rules matter for buyers and publishers for a deeper treatment of threshold definitions.

Buyer billing and publisher payout can separate under duration settlement

Buyer price and publisher payout are different commercial facts.

A duration-based campaign may use:

• One buyer billable-duration threshold.
• A different publisher payout-duration threshold.
• A fixed buyer price.
• A separate publisher payout.

That means a completed call can produce several legitimate outcomes.

Neither side earns

The call does not meet the buyer threshold or publisher threshold.

The call may have routed and connected, but it is neither billable nor payable.

Both sides earn

The call meets both thresholds.

The buyer owes the buyer price, and the publisher earns the publisher payout.

The buyer is billable while the publisher is not yet payable

The call meets the buyer threshold but not the publisher threshold.

Whether this structure is appropriate depends on the agreement and operating model, but it illustrates why billable and payable should never be collapsed into one status.

Duplicate policy changes one side but not the other

A duplicate policy may make a call non-billable to the buyer, non-payable to the publisher, or both.

The settlement engine must apply the policy at the correct scope. “Duplicate” by itself does not say which financial outcome changed.

Our article on why duplicate policies matter in call campaigns explains these distinctions.

Duration settlement needs an exactly-once completion path

Telephony callbacks can be retried.

A completed-call notification may arrive more than once because of network problems, provider retry behavior, or an internal processing failure.

The operation must be able to retry safely without billing the same completed call twice.

A robust duration settlement path should:

• Claim the call for duration settlement once.
• Evaluate the applicable rules from a stable snapshot.
• Create the buyer and publisher financial entries together.
• Roll back the entire settlement if a required write fails.
• Return the existing result when the same completion is delivered again.
• Record enough audit information to explain the outcome.

This is a form of idempotency.

Stripe’s official idempotent request documentation describes the general engineering principle: a retried request should not accidentally perform the same operation twice. Pay-per-call settlement needs the same protection around financial events.

The key is not merely adding a “processed” checkbox after the entries are written.

The claim and the financial writes need to behave as one controlled unit. Otherwise, a crash can leave a buyer charge without a publisher payout, or a retry can create a second pair of entries.

CPA settlement begins with a pending outcome

A CPA call normally cannot be settled from call duration alone.

The call may complete successfully and still remain financially pending.

A practical CPA lifecycle may look like this:

1. The call routes and completes.
2. A pending conversion record is created or preserved.
3. The buyer or an approved system reports an outcome.
4. The event is matched to the correct call.
5. The operation validates the conversion type, time, buyer, campaign, currency, and required evidence.
6. The event is checked for duplicate submission and duplicate payable outcomes.
7. The applicable buyer revenue and publisher payout rules are resolved.
8. A sold outcome records the financial entries.
9. A not-sold outcome closes the pending conversion without buyer revenue or publisher payout.
10. A later reversal creates adjustments or a finance-review item rather than silently deleting the original sale.
11. Eligible entries move into invoice and payout batches.

CPA settlement therefore depends on a second record beyond the call itself: the conversion event.

Call completion does not prove the CPA outcome

A long call may not produce the agreed action.

A short call may produce a valid action.

An agent may complete the sale after follow-up rather than during the call.

A consumer may cancel later.

A buyer may initially report a sale and later reverse it.

Duration remains useful operating context, but it is not the CPA settlement trigger unless the agreement says otherwise.

The CPA conversion must be defined before traffic runs

“Pay on conversion” sounds clear until the parties try to settle it.

The conversion definition should specify:

• The exact action or acquisition.
• The buyer entity and campaign.
• Whether the event must occur during the call or can occur later.
• The attribution window.
• Required data or evidence.
• Which system is authoritative.
• Who may submit the outcome.
• How quickly outcomes must be reported.
• Whether one call can produce more than one payable action.
• Duplicate treatment.
• Cancellation and reversal treatment.
• The buyer price.
• The publisher payout.
• The invoice and payout timing.
• Dispute rights and deadlines.

A phrase such as “sold lead” is not enough.

In one vertical, sold may mean an application was submitted. In another, it may mean payment cleared. In another, it may mean a policy was issued, an appointment was attended, a case was retained, or a loan funded.

Settlement needs the same definition the commercial agreement uses.

CPA settlement depends on attribution

The operation has to connect the reported outcome to the call that produced it.

Useful attribution fields may include:

• Call ID.
• Buyer-side call ID.
• Conversion-event ID.
• Order or transaction ID.
• Buyer account.
• Campaign.
• Buyer target.
• Conversion type.
• Conversion timestamp.
• Reporting source.
• Original submission timestamp.
• Rule version.
• Currency.
• Evidence reference.

Caller phone number alone is a weak conversion identifier.

Numbers can be shared, recycled, formatted differently, masked, or entered incorrectly. They may also create unnecessary privacy exposure.

A stable call ID and a stable conversion-event ID create a cleaner relationship between the operating event and the financial event.

Duplicate conversions are not the same as duplicate calls

CPA settlement has at least two different duplicate problems.

Duplicate technical submission

The same sale is reported twice because:

• A webhook retries.
• A user uploads the same CSV twice.
• The CRM and a manual report both send the event.
• A confirmation page fires twice.
• A user clicks “sold” after an integration already recorded it.

This should normally create one conversion record and one financial settlement.

Google Ads recommends a unique transaction or order ID to prevent the same conversion from being counted twice. Its official guidance explains that the identifier should be unique for each transaction and consistent across data sources. See Use a transaction ID to minimize duplicate conversions.

The same operating principle applies here: retries need a stable event identity.

Duplicate payable outcome across calls

A buyer may report two sold calls for the same consumer and campaign within a defined window.

That may be:

• One legitimate sale reported against the wrong call.
• A duplicate sale.
• Two distinct payable actions.
• A repeat purchase.
• A policy rewrite.
• A second appointment.
• An allowed exception.

The agreement must define the scope.

A technical event ID prevents one event from being processed twice. A business duplicate policy determines whether two different events should both be payable.

Do not use one rule as a substitute for the other.

CPA settlement is usually delayed

Duration settlement can often occur minutes after the call.

CPA settlement may take:

• Minutes.
• Hours.
• Days.
• Weeks.
• Longer in verticals with underwriting, funding, attendance, retention, or cancellation windows.

That delay affects both sides.

Buyer finance

The buyer may receive the value before the invoice is created, but the payable event may land in a later period than the call.

Publisher cash flow

The publisher has already spent money to generate the call but may wait for outcome reporting and the next payout batch.

Operator reconciliation

The operation must keep pending calls visible, age the queue, investigate stale outcomes, and decide when a period is complete enough to close.

Performance reporting

Recent calls may appear to have a low conversion rate simply because the reporting window is incomplete.

A CPA report should distinguish:

• Pending.
• Not sold.
• Sold.
• Reversed.
• Under review.
• Stale or missing outcome.

Treating every unreported call as not sold can understate performance. Treating every pending call as a future sale overstates it.

Settlement timing should follow the earned event

A common reporting question is:

Which period should receive the financial entry: the call date or the conversion date?

There is no universal answer for every contract and accounting method, but the operation needs a consistent rule.

Duration-based settlement often uses the completed call and its earned timestamp because the qualifying event occurs at call completion.

CPA settlement often uses the accepted conversion timestamp or the timestamp when the conversion becomes financially earned.

The invoice can still include the original call date as supporting context.

What should not happen is silent inconsistency:

• The buyer invoice uses conversion date.
• The publisher payout uses call date.
• The dashboard uses submission date.
• The margin report uses invoice date.

That creates period drift even when every individual amount is correct.

The system should preserve all relevant timestamps and state which one drives batching.

Reversal windows change CPA batch eligibility

Some CPA outcomes are reversible.

Examples include:

• Consumer cancellation.
• Policy rescission.
• Appointment cancellation or no-show.
• Returned product.
• Unfunded transaction.
• Rejected application.
• Duplicate sale discovered after review.
• Buyer correction.

A campaign may define a period during which the sale can be reversed before it becomes eligible for final invoicing or payout.

That window changes settlement timing.

One approach is:

1. Record the sold conversion and linked financial entries.
2. Keep the entries out of final invoice and payout batches until the reversal window closes.
3. Reverse or adjust the entries if a valid reversal arrives.
4. Release the entries for batching after the window.

Another approach is to invoice immediately and apply later credits. The contract, accounting process, cash-flow needs, and system capabilities determine which model is appropriate.

The important point is to make the treatment explicit.

Reversals should create adjustments, not erase history

A sold conversion may later become reversed.

The operation should preserve:

• The original call.
• The original conversion event.
• The sold decision.
• The original buyer revenue entry.
• The original publisher payout entry.
• The reversal event.
• The reason.
• The resulting adjustment, credit, hold, or review item.
• The invoices or payout batches affected.

Deleting the original sale makes it difficult to explain what happened.

For finalized invoices, common accounting systems use credits rather than silently changing the original document. Stripe’s credit note guidance is one example: the credit is associated with the invoice or line item while the original invoice remains part of the record.

The same principle helps pay-per-call reconciliation even when a different accounting system is used.

Duration corrections and CPA reversals are different

Duration settlement can also require correction, but the failure modes differ.

Duration correction examples

• Provider duration was updated.
• The wrong call leg was measured.
• A transfer included pre-connect time.
• A duplicate policy was applied incorrectly.
• A route was attributed to the wrong buyer.
• The wrong threshold version was used.

CPA reversal examples

• Buyer changed sold to not sold.
• Consumer canceled.
• The event was attributed to the wrong call.
• The same sale was submitted twice.
• The conversion failed a required validation.
• The outcome did not satisfy the agreed definition.

Both models need adjustments and audit history.

CPA settlement usually needs a richer event history because the outcome can change after the call is complete.

Invoices look different under the two models

A duration-based buyer invoice can often show:

• Call ID.
• Call date and time.
• Campaign.
• Connected duration.
• Buyer threshold.
• Billable result.
• Buyer price.
• Adjustment or dispute status.

A CPA buyer invoice may need:

• Call ID.
• Conversion-event ID.
• Call date.
• Conversion date.
• Conversion type.
• Sold status.
• Buyer price.
• Reversal-window or finalization status.
• Adjustment or credit reference.

A CPA invoice should not say only “10 conversions.”

The buyer should be able to identify the ten accepted events and understand which definition made them billable.

See what should be included in a pay-per-call invoice for a complete invoice checklist.

Payout reports also change

A duration-based publisher payout report may focus on:

• Call ID.
• Source.
• Connected duration.
• Publisher threshold.
• Payable result.
• Publisher payout.
• Duplicate or dispute treatment.

A CPA publisher payout report may focus on:

• Call ID.
• Conversion-event ID.
• Conversion type.
• Conversion date.
• Sold, pending, reversed, or approved status.
• Publisher payout.
• Reversal or adjustment reference.

Publishers do not need confidential buyer price or buyer destination information to understand their payout.

They do need enough evidence to reconcile which outcomes earned, which remained pending, and which were reversed.

See what publishers should expect in a payout report.

Disputes start from different evidence

A duration dispute usually asks questions such as:

• Did the buyer answer?
• Which call leg was measured?
• What was the connected duration?
• Which threshold applied?
• Was the call a duplicate?
• Was the call disconnected because of a routing or provider failure?
• Did the caller meet any other defined qualification rule?

A CPA dispute asks different questions:

• Did the agreed action occur?
• Which system recorded it?
• Which call produced it?
• Was the outcome reported on time?
• Was the event already settled?
• Was the consumer cancellation valid?
• Did the reversal fall within the agreed window?
• Did the buyer apply the same conversion definition consistently?
• Was the outcome rejected because of buyer handling rather than traffic quality?

The dispute process should request evidence that matches the settlement model.

A call recording may be relevant to both, but it does not necessarily prove a later funded transaction or cancellation.

Our guide to pay-per-call disputes covers the broader workflow.

CPA requires a pending-work queue

Duration settlement can be driven by completed-call events.

CPA settlement needs a way to manage calls that have completed but do not yet have a final outcome.

A useful finance or operations queue should support:

• Pending conversions.
• Oldest-pending first.
• Buyer and campaign filters.
• Call and conversion timestamps.
• Submission source.
• Sold, not-sold, reversed, and review states.
• Missing or invalid evidence.
• Duplicate conflicts.
• Currency or rule conflicts.
• Manual review notes.
• Audit history.

Without a queue, pending CPA calls tend to disappear into spreadsheets and email threads.

That creates two predictable failures:

1. Valid publisher earnings are missed.
2. Old calls are suddenly reported as sold after finance believed the period was closed.

Aging rules and reporting deadlines should be agreed before traffic scales.

The source of the outcome must be visible

CPA outcomes can arrive through:

• Buyer portal action.
• Admin review.
• CRM webhook.
• Postback.
• API.
• Scheduled import.
• CSV upload.
• Manual finance correction.
• Another authorized integration.

The settlement record should preserve the submission source.

That does not mean every source is equally trusted.

A buyer-submitted outcome may still need validation. An integration may fail. A CSV may contain stale or duplicate rows. A model-generated suggestion should not silently become a financial event without the required review.

The operation should distinguish:

• Raw submitted event.
• Validated event.
• Accepted settlement.
• Suggested outcome.
• Manual override.
• Reversal.

That separation keeps automation from becoming unexplained money movement.

Rule provenance matters more than a current settings screen

When finance reviews an old call, the current campaign settings may no longer match the terms that applied when the event occurred.

A settlement record should reference the rule version used to calculate:

• Buyer price.
• Publisher payout.
• Currency.
• Duration threshold.
• CPA conversion value.
• Reversal window.
• Duplicate treatment.

Otherwise, an operator may open the current settings, see a different price, and conclude that the old ledger is wrong.

The route or conversion record should freeze enough commercial context to reproduce the result later.

A hypothetical duration settlement

The following example is hypothetical.

A call completes with 185 seconds of provider-reported connected duration.

The applicable terms are:

• Buyer billable threshold: 120 seconds.
• Buyer price: $80.
• Publisher payout threshold: 180 seconds.
• Publisher payout: $65.
• Currency: USD.

The call meets both thresholds.

The settlement record creates:

• Buyer revenue: $80 earned.
• Publisher payout: $65 earned.

The entries later appear in their separate buyer invoice and publisher payout batches.

If the same completed callback is delivered again, the operation should return the existing settlement rather than creating a second $80 charge and $65 payout.

A hypothetical CPA settlement

The following example is hypothetical.

A call completes on August 3.

The buyer reports a qualifying sale on August 6 with:

• Call ID: CALL-HYP-204.
• Conversion-event ID: SALE-HYP-918.
• Conversion type: completed enrollment.
• Conversion time: August 6.
• Buyer price: $300.
• Publisher payout: $225.
• Reversal window: seven days.
• Currency: USD.

The operation validates the event, confirms it has not already been settled, resolves the applicable rules, and records the sold conversion with linked buyer and publisher entries.

The entries are not batch-eligible until the reversal window closes.

If the buyer sends the same event again with the same event identity, the operation should treat it as a retry rather than a second sale.

If the buyer later sends an approved reversal within the window, the operation should preserve the sold event and record the reversal or adjustment.

Which model produces faster cash flow?

Duration-based settlement usually produces faster financial certainty because the qualifying event occurs at call completion.

That can support:

• Faster invoice batching.
• Faster payout batching.
• Fewer pending outcomes.
• Simpler period close.

CPA settlement may produce slower certainty because the conversion can be delayed and reversible.

That can create:

• Longer publisher cash cycles.
• More working-capital pressure.
• More incomplete recent-period data.
• More buyer reporting obligations.
• More operator review.
• More credits or reversals.

The higher CPA amount may compensate for that risk, but the economics have to support the actual reporting and reversal behavior.

A high stated payout is not dependable if outcomes arrive late, change often, or cannot be verified.

Which model creates more trust risk?

Both can create trust problems, but in different places.

Duration-based trust depends heavily on:

• Accurate call state.
• Accurate duration.
• Clear thresholds.
• Correct route attribution.
• Duplicate policy.
• Consistent recordings and call records.

CPA trust depends heavily on:

• Clear conversion definition.
• Buyer reporting.
• Stable event identity.
• Attribution.
• Timeliness.
• Reversal policy.
• Rule consistency.
• Access to review evidence.

CPA gives the buyer more control over the financially decisive event.

That can be appropriate when the buyer is the only party that can observe the outcome. It also means the publisher and operator need stronger reporting controls.

Hybrid models need two clearly separated triggers

Some campaigns use a hybrid structure.

Examples include:

• A smaller amount at a duration threshold plus a CPA bonus.
• Duration-based publisher payout with buyer billing on CPA.
• A duration-qualified call with a later conversion adjustment.
• Different models for different sources or targets.

Hybrid structures are possible, but the financial records must keep the triggers separate.

A single status called “qualified” is not enough.

The operation should identify:

• Which event created the first buyer charge.
• Which event created the later buyer charge or adjustment.
• Which event created publisher payout.
• Whether one event depends on the other.
• Duplicate treatment for each event.
• Reversal treatment.
• Invoice and payout timing.

Hybrid models become dangerous when one spreadsheet formula tries to infer all of this after the fact.

A settlement-readiness checklist

Before launching a duration-based campaign, confirm:

• The duration source is defined.
• Buyer and publisher thresholds are separate fields.
• Buyer price and publisher payout are separate.
• Route-time terms are preserved.
• Completion retries cannot double-settle.
• Duplicate policy states the buyer and publisher effect.
• Under-threshold calls remain visible but non-earned.
• Invoice and payout periods use explicit timestamps and timezones.
• Disputes and credits preserve history.

Before launching a CPA campaign, confirm:

• The conversion action is defined.
• The authoritative reporting source is known.
• Every event has a stable identity.
• Events match to stable call IDs.
• Pending calls are visible and aged.
• Submission deadlines are defined.
• Duplicate technical events are idempotent.
• Business duplicate outcomes have a separate policy.
• Buyer price and publisher payout rules are versioned.
• Reversal windows are defined.
• Reversals create adjustments or review records.
• Invoice and payout batching use a consistent earned timestamp.
• Buyers and publishers receive the appropriate detail without confidential cross-party economics.

What the current Dependable Calls implementation supports

Dependable Calls is being built around separate duration and CPA settlement paths rather than treating every completed call as the same financial event.

The current application implementation supports duration-settlement components including:

• Route-time financial snapshots.
• Provider-reported duration evaluation.
• Separate buyer and publisher qualification outcomes.
• Exactly-once settlement claims for completed calls.
• All-or-nothing buyer-revenue and publisher-payout posting.
• Duplicate-policy gates with separate buyer-billing and publisher-payout effects.
• Rule-version references on financial entries.
• Invoice and payout batching from earned ledger entries.

The current CPA implementation supports components including:

• Pending-sale conversion records.
• Sold and not-sold outcomes.
• Admin and integration-oriented conversion event handling.
• Duplicate and re-settlement guards.
• Buyer revenue and publisher payout rule resolution.
• Transactional creation of linked financial entries.
• Conversion timestamps and rule provenance.
• Reversal windows that can delay batch eligibility.
• Reversal handling through adjustments or finance review.
• Audited conversion settlement and a finance work queue.

These are implementation-level capabilities. Code and tests do not prove that every path is fully exposed, configured, or operationally mature in live production.

The platform remains beta-stage and subject to live validation, secure infrastructure, partner-specific configuration, accounting reconciliation, operator review, and continued hardening.

The settlement model should be chosen with the record in mind

Duration-based and CPA campaigns are not different only because one pays on seconds and the other pays on a sale.

They create different financial timelines.

Duration settlement asks the call system to prove that a completed conversation met the applicable thresholds.

CPA settlement asks the operation to prove that a later business event occurred, belongs to the call, has not already been paid, and remains valid under the reversal policy.

The commercial model should not be chosen before the parties know how they will produce that proof.

A dependable campaign needs more than an attractive buyer price or publisher payout.

It needs a settlement record that can survive retries, reporting delays, duplicate events, disputes, reversals, invoices, payout reports, and period close.

That is how the buyer, publisher, and operator can look at the same call and understand why money did—or did not—move.

Need a more controlled settlement workflow for duration or CPA calls? Start a conversation with Dependable Calls.