What Publishers Should Expect in a Payout Report

A publisher should not have to reverse-engineer a payout.

The final amount matters, but the amount alone is not enough. A professional payout report should explain how the publisher’s traffic moved through the call operation, which calls became payable, which calls did not, what changed after review, and when the resulting balance is expected to be paid.

That explanation is especially important in pay-per-call because a call can pass through several different stages before money is settled. A call may be offered, routed, connected, qualified, disputed, adjusted, held, released, and finally included in a payout batch. In a CPA campaign, the payable event may occur days after the call. In a duration-based campaign, the payable result may depend on a specific connected-duration rule. Duplicate policies, buyer disputes, and manual corrections can change the final result.

Publishers need reporting that can follow that chain.

A useful payout report is not just a payment receipt. It is a finance-grade operating record that helps a serious publisher understand earnings, reconcile internal records, identify strong sources, investigate exclusions, and decide where traffic should scale.

A payout total is not a payout report

A payout total answers one question:

How much is being paid?

A professional payout report should answer several more:

• What reporting period does the payout cover?
• Which publisher account and campaign terms apply?
• Which calls were reviewed?
• Which calls were routed and connected?
• Which calls met the qualification rule?
• Which calls became payable?
• Which calls were excluded, held, or disputed?
• Which sources and sub-sources produced the payable calls?
• Which adjustments changed the original amount?
• What is the current payout status?
• When is payment scheduled or expected?
• Can the total be reconciled to the underlying call-level records?

Without those answers, the publisher receives a number but not an explanation.

That may be tolerable at very low volume. It becomes a serious problem as volume, sources, buyers, campaigns, and settlement rules multiply.

A publisher may be buying media, managing sub-publishers, paying call-center costs, or allocating internal spend across several sources. They need to know whether the payout matches the traffic they generated. They also need enough detail to determine why the result changed from one period to the next.

A correct total that cannot be explained still creates mistrust.

The report should begin with a clear reporting period

Every payout report should identify the exact period being settled.

That sounds basic, but unclear periods create many reconciliation problems. One partner may think a report covers calls received through Sunday night. Another may close the period on Friday. One system may use UTC while the commercial agreement uses Eastern Time. A late CPA conversion may be assigned to the call date, the conversion date, or the settlement date.

A professional report should show:

• Period start.
• Period end.
• Time zone used for the period.
• Date the report was generated.
• Whether the period is open, under review, approved, scheduled, or paid.
• Any cutoff rules for late events.

The time zone should not be implied.

If the campaign operates in Eastern Time, the report should not silently group calls according to UTC day boundaries. A call near midnight can land in a different week or month depending on the time zone. That affects totals, disputes, and payment timing.

The report should also explain how late changes are handled. For example, a CPA outcome reported after the period closes may be included in the next payout as an adjustment rather than rewriting the prior report.

Publishers should be able to tell which activity belongs to which settlement period without comparing several spreadsheets and message threads.

Commercial terms should be visible enough to explain the result

A payout report should identify the terms used to calculate publisher earnings.

That does not mean the publisher needs access to buyer-private pricing, buyer destinations, or the exchange’s margin. Publisher reporting should remain scoped to the publisher’s side of the transaction.

It should still show enough to explain the payout, such as:

• Campaign or offer name.
• Payout model.
• Publisher payout rate.
• Currency.
• Duration threshold, when applicable.
• CPA event definition, when applicable.
• Duplicate policy reference.
• Dispute window.
• Payment terms.
• Any source-specific payout terms.

Terms matter because the same call can settle differently under different agreements.

A 120-second connected call may be payable on one campaign and non-payable on another. A submitted application may count as the CPA event for one buyer, while another requires a completed sale or enrollment. A duplicate caller may be excluded for 30 days under one campaign and treated differently under another.

The report should make the applied rule identifiable.

Publishers should not have to rely on memory to determine which version of the terms was used.

Source-level reporting should be part of payout reporting

Publishers need to understand earnings by source, not only by account total.

A publisher may have several traffic sources operating under one company account. Those sources may use different creatives, media channels, landing pages, call flows, transfer teams, geographic strategies, or sub-publishers. Their results can vary widely.

A useful payout report should identify the source connected to each payable or non-payable call.

At minimum, the report should support stable source labels. When the operation uses sub-sources, it should support those labels as well.

This allows the publisher to answer questions like:

• Which source generated the most payable calls?
• Which source had the strongest payable rate?
• Which source produced the most short calls?
• Which sub-source created the most duplicates?
• Which traffic segment generated the most disputes?
• Which source improved after a creative or routing change?
• Which source should receive more budget?
• Which source should be capped, reviewed, or paused?

Blended payout reporting can hide the truth.

Suppose Source A sends 40 calls and produces 24 payable calls. Source B sends 80 calls and produces only 8 payable calls. An account-level report may show 32 payable calls out of 120. That makes the publisher look weak overall and gives the publisher little direction.

Source-level visibility shows that Source A may be buyer-ready traffic worth scaling, while Source B needs investigation.

Not every source should scale. Payout reporting should help the publisher see the difference.

Sub-source reporting matters when the traffic package is not uniform

A single source label is sometimes too broad.

A publisher may operate one campaign name while using several meaningful traffic paths underneath it. Those paths may include different media buyers, affiliate partners, transfer teams, landing pages, ad groups, or owned-and-operated properties.

When those differences can affect call quality, they should be visible through sub-source reporting.

Good sub-source labels should be:

• Stable over time.
• Unique enough to distinguish material traffic paths.
• Included consistently in call and payout records.
• Defined before traffic scales.
• Protected from accidental reuse.
• Available to the publisher without exposing buyer-private information.

Sub-source reporting creates accountability without forcing the publisher to expose every internal business detail.

The goal is not to publish a complete map of the publisher’s operation. The goal is to preserve enough identity to investigate performance and settle money fairly.

If every sub-source is collapsed into one broad label, the publisher cannot isolate weak traffic. The exchange cannot provide publisher-safe feedback. Strong sources may be paused because another source created the problem.

Clean labels make cleaner call operations possible.

Routed, connected, qualified, and payable calls should be separated

A professional payout report should not treat all calls as one count.

The report should distinguish the major stages of the call lifecycle.

Offered or received calls

These are calls or opportunities presented to the routing operation. Depending on the integration, that may begin with a pre-call ping, a live inbound call, or another accepted event.

Routed calls

These are calls for which the routing system selected an eligible path or buyer target.

A routed call is not automatically a connected call. The destination may fail, the caller may hang up, the reservation may expire, or another routing issue may prevent connection.

Connected calls

These are calls that reached the receiving destination according to the system’s connection rules.

Connection alone does not mean the call qualified.

Qualified calls

These are calls that met the agreed campaign qualification rule. Qualification may depend on connected duration, geography, call type, schedule, caller identity, or another objective rule.

Payable calls

These are calls that earned publisher payout under the final settlement rules.

A qualified call and a payable call are often closely related, but the statuses should still be stored separately. A qualified call may remain on hold during a dispute window. A CPA call may qualify for review but not become payable until a buyer reports the agreed outcome. A duplicate policy or approved dispute may affect payout after the initial qualification event.

Publishers should be able to see the movement between these stages.

For example:

• 500 calls received.
• 420 calls routed.
• 390 calls connected.
• 260 calls qualified.
• 248 calls payable.
• 12 calls held or adjusted.

That sequence tells the publisher much more than a report showing only 248 paid calls.

It helps separate traffic problems from routing problems, destination problems, qualification problems, and finance review.

Every call should have a stable identifier

Call-level reconciliation depends on stable identifiers.

A payout report should include a call ID or another durable key that can be matched to the publisher’s internal record. When a separate ledger entry or payout line item exists, that identifier should also be available.

Useful identifiers may include:

• Call ID.
• Publisher call ID.
• External platform ID.
• Ledger entry ID.
• Payout batch ID.
• Campaign ID.
• Source ID.
• Sub-source ID.

The report does not need to display every internal identifier in the main view. A detailed export should make enough of them available for reconciliation.

Stable identifiers allow both sides to discuss the same call.

Instead of saying, “We are missing a call from Tuesday afternoon,” the publisher can identify the exact record. The operator can then review the route, connection, qualification, duplicate status, dispute history, and financial result tied to that call.

That is what a call flow you can explain looks like.

The call date, route date, and earning date may be different

A payout report should include the timestamps needed to understand settlement.

The call may have occurred on one date, qualified on another system event, earned payout later, and entered a payout batch after the reporting period closed.

Important timestamps can include:

• Call received time.
• Route decision time.
• Connection time.
• Call end time.
• Qualification time.
• CPA outcome time.
• Payout earned time.
• Dispute submitted time.
• Adjustment time.
• Batch approval time.
• Scheduled payment time.
• Paid time.

Not every report needs all of those columns in the default view. The operation should preserve them, and the detailed report should expose the ones needed to explain the payout.

This is particularly important when a publisher compares the report against another platform. The platforms may group records according to different timestamps.

A professional payout report should make the settlement timestamp clear instead of forcing the publisher to guess.

Duration-based settlement should show the measurable rule

Duration-based campaigns are usually easier to explain because the payable event occurs close to the call record.

The report should show the values needed to verify the result:

• Connected duration.
• Qualifying duration threshold.
• Whether the threshold was met.
• Payout rate.
• Payable status.
• Exclusion reason, if not payable.

The definition of duration should be consistent.

Publishers need to know when the clock starts. Does it begin when the caller reaches the platform, when the buyer target answers, when an IVR completes, or at another event? Does hold time count? How are failed bridges treated? How are calls with multiple legs measured?

The payout report does not need to restate the complete telephony specification on every row. It should connect the reported duration to a documented rule.

A row might show:

• Connected duration: 143 seconds.
• Required duration: 120 seconds.
• Qualification: met.
• Payout: $42.00.
• Status: payable.

For a non-payable call:

• Connected duration: 47 seconds.
• Required duration: 120 seconds.
• Qualification: not met.
• Payout: $0.00.
• Reason: below duration threshold.

That is more useful than a blank payout field.

CPA settlement needs additional status visibility

CPA campaigns require stronger reporting because the financial event may happen after the call.

The publisher needs to know what exact event creates payout. It may be a sale, enrollment, retained case, completed appointment, funded account, or another agreed result.

A professional CPA payout report should show:

• Original call ID.
• CPA event definition.
• Current conversion status.
• Date the outcome was reported.
• Who or what system reported the outcome.
• Whether the outcome is pending, approved, sold, not sold, reversed, or otherwise settled.
• Payout amount.
• Reversal or chargeback status, when applicable.
• Final payable date.

A publisher should not see a call disappear into a vague pending category indefinitely.

The report should make the lifecycle clear. For example:

1. Call connected.
2. Buyer review pending.
3. Buyer marked the outcome sold.
4. Conversion entered the reversal window.
5. Payout became earned.
6. Entry was included in the next payout batch.

CPA reporting should also distinguish “not yet reported” from “reported as not sold.” Those are different conditions.

One means the process is incomplete. The other means the buyer submitted a final outcome.

Without that distinction, publishers cannot tell whether they are waiting for data or whether the call failed to produce the agreed result.

Duplicate handling should be explicit

Duplicate policies directly affect publisher payout.

A payout report should not simply show a zero amount without explaining that a call was excluded as a duplicate.

The report should identify:

• Whether the call was flagged as a duplicate.
• The duplicate rule applied.
• The lookback window.
• The scope of the duplicate check.
• Whether the duplicate was detected before routing or after the call.
• Whether the call connected despite being non-payable.
• Whether the duplicate decision is final or reviewable.

The scope matters.

A duplicate may be evaluated by caller number, buyer, campaign, publisher, source, vertical, or another key. A caller who contacted one buyer last month may or may not be considered a duplicate for another buyer today. The rule should match the campaign agreement.

Publishers should not learn about duplicate treatment only after the payout total is reduced.

The policy should be defined before launch, applied consistently, and visible in reporting.

Dispute status should stay connected to the call

Disputes are part of serious pay-per-call operations.

The problem is not that disputes happen. The problem is when a dispute changes the publisher’s payout without leaving a clear record.

A payout report should show whether a call is:

• Not disputed.
• Under review.
• Temporarily held.
• Dispute approved.
• Dispute denied.
• Partially adjusted.
• Escalated for finance review.
• Finalized.

The detailed record should also include the dispute reason and important dates.

For example:

• Dispute reason: wrong service category.
• Submitted: July 8.
• Evidence reviewed: recording and call metadata.
• Decision: approved.
• Payout effect: reversed by $42.00.
• Adjustment date: July 10.

Publishers should have enough information to understand the decision and respond through the agreed process.

Vague rejection language such as “bad call” or “quality issue” is not enough. The reason should connect to a campaign rule or documented review finding.

Publisher-safe feedback should be specific without exposing buyer-private information.

Adjustment history should never be hidden

Payouts sometimes need adjustments.

A call may be credited after a dispute. A duplicate flag may be corrected. A held payout may be released. A CPA outcome may be reversed. A manual correction may be necessary after a reporting issue.

The report should preserve the history rather than silently replacing the original amount.

A strong adjustment record should show:

• Original amount.
• Adjustment amount.
• New net amount.
• Adjustment type.
• Reason.
• Related call or batch.
• Date applied.
• Approval or review reference.
• Whether the adjustment affects the current or a future payout.

Suppose a publisher originally earned $42.00 on a call. A later review approves a full reversal. The reporting should not make the original entry disappear.

It should show the original earning and a separate negative adjustment.

That creates an auditable record and keeps historical reports understandable.

Append-only adjustment history is more dependable than quietly rewriting the past.

Payout timing should be visible as a lifecycle

Publishers need to know more than whether a payout exists.

They need to know where it is in the payment lifecycle.

Useful payout statuses include:

• Open.
• Draft.
• Under review.
• Approved.
• Scheduled.
• Processing.
• Paid.
• Failed.
• Returned.
• Held.
• Partially paid.

The exact labels may vary, but the meaning should be clear.

A professional payout report should show:

• Payment terms.
• Period close date.
• Approval date.
• Expected payment date.
• Scheduled date.
• Paid date.
• Payment reference, when appropriate.
• Any hold reason.

“Net 14” should not be treated as a complete explanation if the publisher cannot tell when the 14-day clock begins.

Does it begin on the call date, the end of the reporting period, invoice approval, or another event? The commercial agreement should define that, and the payout report should use the same convention.

Clear timing helps publishers manage cash flow and reduces unnecessary follow-up.

The payout should reconcile from line items to the total

The central financial test is simple:

The sum of the payout line items, including adjustments, should equal the reported payout total.

A strong report should support reconciliation at several levels:

• Call-level payout amount.
• Source subtotal.
• Campaign subtotal.
• Adjustment subtotal.
• Period total.
• Paid amount.
• Remaining balance, if any.

For example:

• Payable call entries: $18,420.00.
• Positive adjustments: $210.00.
• Negative adjustments: -$336.00.
• Final approved payout: $18,294.00.
• Amount paid: $18,294.00.
• Remaining balance: $0.00.

The detailed export should add to the same total shown in the summary.

If the summary says $18,294.00 but the line items total $18,252.00, the report is not ready. The discrepancy should be resolved before the payout is approved.

Finance-grade reconciliation means the platform should fail closed when the supporting entries do not match the batch total.

The publisher should not be expected to discover the mismatch after payment.

Reports should be downloadable in a useful format

A portal view is helpful, but publishers often need a downloadable report for internal reconciliation.

CSV and spreadsheet exports are practical because they can be matched against media buying records, call tracking systems, sub-publisher statements, and accounting workflows.

A useful detailed export should have:

• Stable column names.
• One row per financial line item or clearly defined record.
• Machine-readable timestamps.
• Consistent currency formatting.
• Stable IDs.
• Source and sub-source labels.
• Qualification and payable statuses.
• Duplicate and dispute indicators.
• Adjustment details.
• Batch and period references.

The report should also offer a summary view for accounting and a detailed view for operations.

The summary answers, “What is owed for this period?”

The detail answers, “Why?”

Both are necessary.

Publisher reporting should protect private information

More reporting does not mean every party should see every field.

A publisher should be able to understand its payout without seeing protected buyer destinations, buyer-private pricing, internal margin, unrelated publisher data, or unnecessary caller information.

Professional reporting should be scoped by partner and role.

That means:

• A publisher sees only its own payout batches and call records.
• Buyer revenue and exchange margin are not included in publisher exports.
• Caller information is masked or limited according to policy.
• Recordings and sensitive data are access-controlled.
• Sub-user permissions follow the publisher organization.
• Exports cannot leak records from another partner.

Privacy and auditability should work together.

The report should reveal enough to explain the publisher’s money while protecting data that does not belong in the publisher view.

The report should preserve an audit trail

A payout report becomes more valuable when it can answer not only what the current status is, but how the status changed.

An audit trail should preserve important actions such as:

• Qualification recorded.
• Payout entry created.
• Entry held.
• Dispute opened.
• Dispute resolved.
• Adjustment created.
• Batch generated.
• Batch approved.
• Payment scheduled.
• Payment marked paid.

The audit trail should identify when the action happened and which authorized user or system performed it.

Publishers may not need every internal audit event in the default report. The operation should still retain that record so questions can be answered later.

Auditability discourages arbitrary changes. It also protects the operator when the report is correct but challenged months later.

Clean records reduce dependence on screenshots, chat messages, and memory.

A payout report should help publishers improve traffic

Payout reporting is not only an accounting function.

It should help publishers operate better.

When payout data is connected to source performance, the publisher can calculate useful measures such as:

• Routed rate.
• Connection rate.
• Qualification rate.
• Payable rate.
• Average connected duration.
• Payout per received call.
• Payout per connected call.
• Duplicate rate.
• Dispute rate.
• Adjustment rate.
• CPA conversion rate.
• Earnings by source and sub-source.

Those metrics should be interpreted carefully. A low payable rate can have several causes.

The source may be weak. The buyer target may have been unavailable. Calls may have arrived outside schedule. A routing rule may have rejected otherwise useful traffic. A buyer may be slow to report CPA outcomes. Duplicate traffic may have increased. A transfer team may have changed its screening process.

The payout report should give the publisher enough detail to investigate instead of assuming every weak number is a traffic-quality problem.

Cleaner reporting creates better conversations between serious publishers, serious buyers, and the operator managing the exchange.

A practical payout report example

Consider a publisher running two sources on a duration-based insurance campaign.

The reporting period covers July 1 through July 7 in Eastern Time.

Summary

• Calls received: 310.
• Calls routed: 274.
• Calls connected: 251.
• Calls qualified: 168.
• Calls initially payable: 164.
• Calls held for dispute review: 4.
• Approved negative adjustments: 2 calls, -$84.00.
• Released holds: 2 calls, +$84.00.
• Final payable calls: 164.
• Publisher payout rate: $42.00.
• Final payout total: $6,888.00.
• Payout status: approved.
• Scheduled payment date: July 21.

Source detail

Source A

• Calls received: 120.
• Connected: 108.
• Payable: 86.
• Payable rate from received calls: 71.7%.
• Duplicate calls: 2.
• Disputes approved: 0.

Source B

• Calls received: 190.
• Connected: 143.
• Payable: 78.
• Payable rate from received calls: 41.1%.
• Duplicate calls: 11.
• Disputes approved: 2.

The blended payout total is useful for accounting.

The source detail is useful for operating.

It shows that Source A may deserve more budget or capacity. Source B needs a closer look at duplicate handling, caller intent, routing hours, or another source-level issue.

The publisher can make that decision because the report preserves the path from traffic to payout.

Red flags publishers should take seriously

A publisher should slow down when payout reporting has several of these problems:

• Only a total is provided.
• Reporting periods are unclear.
• Time zones are not stated.
• Source and sub-source labels are missing.
• Routed, connected, qualified, and payable calls are blended together.
• Non-payable calls have no reason code.
• Duplicate exclusions are not identified.
• CPA outcomes remain pending without status detail.
• Disputes reduce payout without a visible record.
• Adjustments overwrite prior amounts.
• The detailed lines do not add to the summary total.
• Payout dates are communicated only through chat.
• Payment status is unclear.
• Historical reports change without an audit trail.
• Publisher reports expose buyer-private information or data from another partner.
• The operator cannot identify the exact call behind a payout question.

One reporting gap may be fixable.

A pattern of unexplained totals, shifting rules, and untraceable adjustments suggests the operation is not ready for meaningful scale.

A publisher payout report checklist

Before accepting a payout report as complete, confirm that it includes or supports the following:

Period and account

• Publisher account.
• Reporting period.
• Time zone.
• Report generation date.
• Currency.
• Payout batch ID.

Commercial rules

• Campaign or offer.
• Payout model.
• Payout rate.
• Duration threshold or CPA event.
• Duplicate policy reference.
• Payment terms.

Call-level detail

• Stable call ID.
• Source.
• Sub-source, when applicable.
• Call date and time.
• Routed status.
• Connected status.
• Qualification status.
• Payable status.
• Duration or CPA outcome.
• Payout amount.
• Exclusion reason.

Review and corrections

• Duplicate status.
• Dispute status.
• Hold status.
• Adjustment history.
• Final settlement result.

Payment lifecycle

• Batch status.
• Approval date.
• Scheduled payment date.
• Paid date.
• Payment reference, when appropriate.

Reconciliation

• Source subtotals.
• Campaign subtotals.
• Adjustment totals.
• Final payout total.
• Paid amount.
• Remaining balance.
• Detail-to-summary match.

Not every field needs to be crowded into one screen.

The publisher should be able to move from summary to detail and understand the complete result.

Better payout reporting builds better publisher relationships

Publishers take real risk when generating calls.

They may pay for media before the call occurs. They may pay a sub-publisher before receiving final settlement. They may carry payroll, technology, compliance, and creative costs while waiting for payout.

Unclear reporting increases that risk.

When publishers cannot verify earnings, they protect themselves. They reduce traffic. They demand shorter payment terms. They avoid testing new buyers. They add margin to cover uncertainty. They move strong sources elsewhere.

Clear reporting changes the relationship.

The publisher can see which traffic earned, which traffic did not, why the result changed, and when payment is expected. The operator can answer questions from records instead of memory. Disputes become specific. Strong sources can earn more confidence.

Reporting quality is one of the clearest signs that an exchange respects publisher operations.

It shows that payout is not being treated as an afterthought.

What to expect from Dependable Calls

Dependable Calls is being built around the idea that publisher payout should remain connected to the call and financial record that created it.

The current beta direction includes publisher-scoped payout batches, period and status visibility, line-item counts, totals, lifecycle timestamps, and downloadable detail and summary exports. Publisher-facing finance data is designed to stay separated from buyer revenue and exchange margin, with caller information limited according to the publisher’s role.

That is the foundation, not a claim that every ideal reporting field described in this guide is already consolidated into one finished report.

The broader goal is finance-grade reconciliation: source-level visibility, clear payable logic, traceable disputes and adjustments, consistent settlement periods, and payout records that can be explained from the underlying call activity.

Dependable Calls is still in beta. We are building the reporting and finance workflows carefully because serious publishers should not have to choose between sending traffic and understanding how they were paid.

Have buyer-ready traffic? Apply to become a Dependable Calls publisher.