Pre-Billing Call Validation: What to Check Before Invoicing Buyers and Paying Publishers

A pay-per-call invoice should not begin with an export button.

It should begin with a controlled question:

Which operational call records are ready to become financial obligations, and which records still need review?

That question sits between live call operations and settlement. Before the buyer is charged and before the publisher earns a finalized payout obligation, the operator has to determine whether each call is billable to the buyer, payable to the publisher, both, or neither.

That decision is rarely supported by one field.

A call may have routed successfully but never connected. It may have connected but used the wrong duration clock. It may have crossed a duration threshold but later been identified as a duplicate. A CPA conversion may have arrived after the period cutoff. A buyer disposition may contradict the call record. A provider may have delivered the same terminal event twice. A dispute may still be open. A call may already belong to a prior invoice or payout batch.

Pre-billing call validation is the process of resolving those conditions before operational records become invoice lines or payout obligations.

It is not a general reconciliation exercise after the fact. It is not a list of fields that belong on an invoice. It is not a substitute for a dispute process. It is the exception-driven control point that decides which records are safe to include in a financial batch.

This article is operational education, not legal, tax, accounting, privacy, or record-retention advice. Agreements, accounting methods, evidence requirements, retention periods, and legal obligations vary. Review your specific process with qualified advisers.

The output is not one universal “accepted” status

A serious pre-billing process should preserve separate operational and financial states.

At minimum, operators need to distinguish among:

• Offered: the opportunity was presented to one or more eligible targets.
• Routed: a target was selected and the call path was attempted.
• Connected: the consumer leg and the intended answering leg established the defined connection.
• Qualified: the call met the campaign’s operational qualification rule.
• Billable: the buyer owes the agreed buyer price for the call or conversion.
• Payable: the publisher earns the agreed publisher payout.
• Converted: the agreed CPA outcome was reported and attributed to the call.
• Disputed: a partner has challenged the initial treatment under the allowed process.
• Adjusted: a later approved change modified the financial result.
• Settled: the record has been included in the appropriate finalized financial process.

Those states answer different questions. Our foundational guide to routed, qualified, and billable calls explains the distinctions in more detail.

For pre-billing validation, the practical output should be one of four financial decisions:

A fifth temporary outcome is just as important:

Hold. The record is not ready for a final decision because evidence is missing, contradictory, delayed, or under dispute.

A hold should not be treated as a quiet rejection. It should have an owner, a reason, evidence needed, and a deadline or escalation path.

Why validation has to happen before the invoice and payout batch

Once a record enters a finalized batch, changes become more expensive.

A correction may require a credit, revised invoice, payout adjustment, partner explanation, accounting entry, or a reopening of a closed period. The underlying problem may still be fixable, but the correction now touches more systems and more people.

Pre-billing validation reduces that avoidable rework by testing the financial population before close.

A useful general control principle comes from the U.S. Government Accountability Office’s 2025 Green Book update. The standards apply to federal internal control, not specifically to pay-per-call businesses, but the control pattern is relevant: document risk responses, emphasize preventive controls, and make management responsibility clear. In a call operation, pre-billing validation is a preventive control. It catches weak records before they become external financial statements to a buyer or publisher.

The timing also protects both sides of the market.

Start with a stable call identity and transaction lineage

Every validation step depends on knowing which records belong to the same call and commercial decision.

A canonical call identifier should remain stable across:

• Publisher intake.
• Source and sub-source attribution.
• Campaign eligibility.
• Buyer target evaluation.
• Reservation and routing.
• Telephony provider legs.
• Connection and duration measurement.
• Qualification.
• Buyer billing.
• Publisher payout.
• CPA conversion attribution.
• Disputes and adjustments.
• Invoice and payout batch membership.

Provider identifiers are useful, but the operator still needs a canonical transaction identity.

Twilio’s current Call resource documentation illustrates why. A Call resource has a unique SID and can also include a parent call SID for a related leg. A bridged or transferred call can therefore involve more than one provider call object. The same documentation distinguishes provider status, UTC timestamps, duration, and parent-child relationships.

That means a settlement process should not assume that “one phone conversation” always equals “one provider row.” It should know which leg is canonical for qualification and which related identifiers explain the bridge.

A useful lineage record may include:

• Canonical call ID.
• Publisher ID.
• Source ID.
• Sub-source ID.
• Campaign ID.
• Buyer ID.
• Target ID.
• Reservation or routing-decision ID.
• Provider call IDs for the inbound and buyer legs.
• Conversion-event ID when applicable.
• Ledger-entry IDs.
• Dispute or adjustment IDs.
• Invoice-batch and payout-batch IDs.

The validation rule is straightforward:

Do not create a financial line when the operator cannot trace the line back to one canonical call or conversion and the applicable commercial terms.

Ambiguous identity belongs in an exception queue, not an invoice.

Confirm attribution before testing qualification

A call can be technically connected and still be financially unattributable.

Before testing price, payout, duration, or conversion, confirm who and what the record belongs to.

Publisher, source, and sub-source

The publisher attribution should identify the commercial party that may be owed the publisher payout. The source and sub-source should identify the approved traffic path under which the call was generated.

Validation should ask:

• Was the publisher active and approved when the call occurred?
• Was the source enabled for this campaign and call path?
• Was the sub-source required and present?
• Did the source label change after routing?
• Do intake, route, and call records agree on the source?
• Is the record assigned to a fallback or unknown source bucket that requires review?

A call should not silently inherit today’s source settings. The route-time source attribution should control.

Campaign, buyer, and target

The buyer side needs the same discipline.

Confirm:

• Which campaign rules applied.
• Which buyer target won or received the route.
• Which destination leg was attempted.
• Whether the target was eligible at the decision time.
• Which buyer price and qualification terms were attached to that route.
• Whether the call was rerouted and, if so, which target ultimately received the defined opportunity.

If a call touched more than one target, the operator needs a rule for which event creates billability. A failed first route followed by a successful second route should not produce two buyer charges merely because two targets appear in the event history.

Reconstruct the call path before deciding whether it connected

“Connected” should be a defined operational state, not a provider label copied into finance.

Twilio notes that a completed call indicates that a connection was established and audio transferred, but the answering party could have been a person, an IVR, or voicemail. Its duration field is empty for busy, failed, unanswered, or ongoing calls.

That distinction matters because a provider-completed call may still fail the campaign’s connected-call definition.

Pre-billing validation should compare:

• Inbound call creation.
• Routing or reservation success.
• Buyer-leg creation.
• Buyer-leg answer.
• Bridge establishment.
• Consumer and buyer overlap.
• Terminal status for each relevant leg.
• Disconnect reason when available.
• Canonical connected duration.

What matters is consistency.

If the campaign uses bridge-connected time, do not validate against total inbound-leg duration. If the campaign treats IVR answer as connected, document that choice. If voicemail does not count, a provider-completed status cannot close the question by itself.

Validate the duration rule against the correct clock

Duration-based settlement appears objective only when the measured clock is explicit.

The operator should verify:

1. The measured object. Inbound leg, buyer leg, bridge, talk segment, or another canonical record.
2. The start event. Answer, agent connection, bridge, or another defined event.
3. The end event. Caller disconnect, buyer-leg termination, bridge close, or provider terminal event.
4. The unit and rounding rule. Whole seconds, milliseconds, and how boundary values are treated.
5. The comparison. Greater than versus greater than or equal to the threshold.
6. The route-time threshold. The rule that applied when the call routed, not the current campaign setting.
7. The fallback evidence. What controls when provider and internal measurements disagree.

The detailed operational issues are covered in why call duration rules matter for buyers and publishers.

For pre-billing review, the important question is whether the stored duration decision can be reproduced.

A duration-qualified record should have enough evidence to show:

• Canonical duration.
• Applicable buyer threshold.
• Applicable publisher threshold when different.
• Qualification method.
• Initial result.
• Any later dispute or adjustment.

A missing duration should not default to zero unless the written rule explicitly says so. Zero is a measurement. Missing is an exception.

Validate CPA conversions separately from duration qualification

CPA settlement depends on a downstream event rather than a call clock.

The validation process should confirm:

• The exact conversion event that earns.
• The buyer or system authorized to report it.
• The conversion-event identifier.
• The canonical call to which it is attributed.
• The allowed attribution window.
• Whether the event is pending, confirmed, reversed, or outside the window.
• Whether the same event has already been used.
• Whether one call is allowed to support more than one conversion.
• Whether a late event belongs to the current period or a later adjustment cycle.

Event-driven systems require defensive handling. Stripe’s current webhook documentation is not a pay-per-call settlement rule, but it describes common integration behavior that financial operators should expect: deliveries can be retried, the same event can arrive more than once, and events are not guaranteed to arrive in generation order.

That is why a CPA conversion should be processed idempotently.

A duplicate webhook should not create a second conversion, a second buyer charge, or a second publisher payout. An out-of-order reversal should not be ignored merely because the original conversion event was processed later. A late event should not silently reopen a frozen period.

CPA validation needs a clear cutoff policy:

• Events received before the cutoff may enter the normal batch.
• Events received after the cutoff may enter a later adjustment batch.
• Events still inside a contractual reversal window may remain on hold.
• Unmatched events should stay in an exception queue until they are resolved or expired under policy.

Re-run the campaign eligibility rules that affect money

A call can connect and meet duration while still failing another agreed rule.

The validation population should test the route-time version of the rules that can change billability or payability.

Geography

Confirm the governing geography field and the rule that applied.

Possible evidence includes caller-provided ZIP code, validated service address, area code, IP-derived location, or another agreed field. Those fields are not interchangeable. The commercial rule should identify which one controls.

Schedule and timezone

Confirm that the call occurred during the approved schedule in the schedule’s defined timezone.

Period cutoffs and campaign schedules are separate questions. A call may be eligible for the campaign at 11:30 p.m. Pacific while falling on the next UTC calendar date. The operator should preserve both the UTC event time and the local time used for commercial decisions.

Call type

Confirm whether the record was consumer-initiated inbound, a live transfer, a warm transfer, a callback, or another allowed type.

Do not infer call type only from duration or a phone-number pattern. Use the actual flow record.

Product or service intent

Confirm that the caller requested the category the buyer agreed to purchase. This may rely on intake fields, routing tags, agent disposition, or reviewed evidence, depending on the campaign.

Qualification attributes

Confirm required attributes such as homeowner status, age range, insurance status, property type, legal matter category, or another campaign-specific condition only when the agreed process collected and preserved that information.

A missing field is not automatically a failed field. It may be an evidence exception. The policy should say whether missing evidence causes exclusion, hold, or another outcome.

Apply duplicate and repeat-caller rules consistently

Duplicate handling is one of the easiest places for invoice and payout populations to diverge.

Validation should identify:

• The matching key.
• The lookback window.
• The scope of the rule.
• The event that starts the window.
• Whether only qualified calls count against the window.
• Whether the rule differs for buyer billing and publisher payout.
• Whether repeat callers can become eligible again for a new product, campaign, or service event.

The scope matters.

A caller may be a duplicate for one buyer but not another. A caller may be a duplicate within one campaign but eligible in a different vertical. A repeat service request may be legitimate even when the caller ID matches an earlier call.

Pre-billing validation should show both the result and the record that caused the duplicate decision.

A reason such as “duplicate” without the governing policy and matching prior event is difficult to defend.

Compare buyer dispositions and CRM feedback without letting them rewrite the contract

Buyer feedback is valuable, but it should be interpreted under the commercial model.

A buyer disposition may say:

• Sale.
• No sale.
• Wrong service.
• Existing customer.
• Duplicate.
• Unqualified.
• No agent answer.
• Call dropped.
• Follow-up required.
• Unknown.

Those outcomes can support validation, but they do not all have the same financial meaning.

Under a duration-based campaign, “no sale” may not invalidate a call that met the agreed duration and eligibility rules. Under a CPA campaign, “sale” or another defined conversion may be the event that creates billability. “Existing customer” may be an allowed dispute reason in one campaign and irrelevant in another.

The validation process should ask:

• Is the disposition from an authorized source?
• Is it tied to the canonical call ID?
• Was it submitted within the allowed feedback window?
• Does the disposition map to a written financial rule?
• Does it contradict telephony or intake evidence?
• Is it final, or can the buyer revise it?
• Has the same disposition event already been processed?

Buyer CRM data should inform the decision. It should not silently replace the campaign terms.

Treat missing, contradictory, delayed, and duplicated events as exceptions

A pre-billing process becomes reliable when normal records move quickly and abnormal records stop safely.

Common exception types include:

• Call exists but route record is missing.
• Route exists but buyer leg was never created.
• Buyer leg connected but bridge event is absent.
• Duration is missing after the terminal event.
• Two systems report different durations.
• Source attribution changes across intake and route records.
• Buyer disposition conflicts with the call type.
• CPA conversion is unmatched.
• Terminal callback arrives twice.
• Reversal arrives before the original conversion event.
• The same call appears in more than one candidate batch.
• A previously settled call reappears as eligible.
• Price or payout is missing.
• Currency differs between the rule and financial record.

Do not solve these exceptions with one generic “manual review” bucket.

Each exception should record:

• Exception code.
• Canonical call or conversion ID.
• Affected buyer and publisher side.
• Financial exposure.
• Evidence present.
• Evidence missing.
• Assigned reviewer.
• Created time.
• Review deadline.
• Decision.
• Approver.
• Notes suitable for later partner explanation.

The exception queue should also distinguish blocking from non-blocking issues.

A missing internal analytics tag may not block billing when the commercial identity is clear. A missing buyer price should block billing. A missing publisher payout should block payout. A duplicate batch membership should block both until corrected.

Check disputes, adjustments, and prior settlement before inclusion

Pre-billing validation should not operate as though every call is untouched.

Before adding a record to a batch, ask:

• Is there an open dispute?
• Has the call been placed on hold?
• Was an approved adjustment already created?
• Was the call previously credited?
• Was the call included in an earlier invoice?
• Was the publisher payout already finalized?
• Is this a replacement, reversal, or supplemental entry?
• Does the adjustment point to the original financial record?

Open disputes should follow the campaign’s policy. Some operations hold the affected line. Others invoice initially and apply later credits. Either approach needs clear terms and consistent records.

The broader dispute workflow is covered in how disputes should work in a serious pay-per-call operation. At the pre-billing stage, the control is narrower: do not let an unresolved or already adjusted record enter the wrong financial population.

A previously settled record should not be re-invoiced or repaid simply because it still meets the current query filter.

That requires idempotent batch membership and a clear relationship between original and adjustment entries.

Keep buyer price and publisher payout separate

The buyer price is what the operator charges the buyer.

The publisher payout is what the operator pays the publisher.

They may be attached to the same call, but they are separate obligations under separate terms.

Pre-billing validation should therefore run two financial tests.

Buyer-side test

• Is the call billable under the buyer’s route-time rule?
• What buyer price and currency apply?
• Has the buyer already been charged?
• Is a credit, dispute, or adjustment pending?
• Does the call belong in this buyer’s invoice period?

Publisher-side test

• Is the call payable under the publisher’s route-time rule?
• What publisher payout and currency apply?
• Has the publisher already earned or received settlement credit?
• Is a payout hold or adjustment pending?
• Does the call belong in this publisher’s payout period?

Do not calculate one side by subtracting a margin from the other unless the contract and implementation explicitly use that formula and preserve its version.

The buyer price should be independently explainable. The publisher payout should be independently explainable.

Define period cutoffs before close begins

A period needs more than a start date and end date.

The close policy should define:

• Billing timezone.
• Payout timezone.
• Inclusive and exclusive boundaries.
• Which event date controls for duration-based calls.
• Which event date controls for CPA conversions.
• Grace period for late provider events.
• Buyer feedback cutoff.
• Dispute cutoff.
• CPA conversion and reversal cutoff.
• Treatment of weekends and holidays.
• Treatment of late adjustments.

For example, a call that starts before midnight and ends after midnight needs a period rule. Does the period follow call start, connected time, terminal time, qualification time, or ledger-earned time?

The same applies to late-arriving data. A terminal event may arrive after the period boundary even though the call occurred earlier. A buyer may upload a CPA conversion after the normal close. A provider API may be eventually consistent.

The safest approach is to separate event time from received time and processing time.

Then the close policy can state which one determines period membership and which late records become later adjustments.

Freeze the reviewed population before generating external documents

Once exceptions are resolved or formally deferred, create a reviewed population.

That population should be frozen by identifiers and amounts, not recreated later from mutable campaign settings.

A close process should preserve:

• Included call and conversion IDs.
• Excluded IDs and reasons.
• Held IDs and reasons.
• Buyer prices.
• Publisher payouts.
• Currency.
• Applied qualification terms.
• Period boundaries and timezone.
• Adjustment relationships.
• Reviewer and approver.
• Validation timestamp.
• Batch-generation version or control reference.

Freezing does not mean errors can never be corrected. It means corrections happen through an adjustment process rather than by silently rewriting the reviewed population.

This is the bridge from operational data to financial settlement.

The invoice itself has a different job. For a field-by-field discussion, see what should be included in a pay-per-call invoice. Publishers need a separate view of their side, described in what publishers should expect in a payout report.

A practical pre-billing validation sequence

The following sequence can be applied before generating an invoice batch or payout batch.

1. Define the candidate population

Select calls and conversions using the written period rule, partner, campaign, and financial entry type.

Do not begin with “all completed calls.” Begin with the population that could legally and commercially belong to the batch.

2. Exclude previously settled records

Check prior invoice membership, payout membership, credits, reversals, and finalized adjustments.

Any record that already settled should be excluded unless the new row is an explicit linked adjustment.

3. Validate canonical identity

Require a stable call or conversion ID and confirm the related route, provider, source, buyer, and publisher records can be joined without ambiguity.

4. Validate attribution

Confirm publisher, source, sub-source, campaign, buyer, and target attribution against route-time facts.

Unknown or conflicting attribution moves to an exception queue.

5. Validate the call path

Confirm route, destination leg, answer, bridge, and terminal events under the campaign’s connection definition.

6. Apply duration or CPA logic

For duration campaigns, validate the correct clock and route-time threshold.

For CPA campaigns, validate the conversion identity, attribution window, status, and duplicate handling.

7. Apply nonfinancial eligibility rules

Check geography, schedule, call type, product intent, qualification attributes, source approval, and other written rules that affect billability or payability.

8. Apply duplicate and repeat-caller policy

Use the correct matching key, scope, window, and prior event. Preserve the reason and related record.

9. Incorporate buyer feedback

Map authorized dispositions and CRM outcomes to the written commercial rules. Flag contradictions instead of letting them overwrite records automatically.

10. Resolve disputes and adjustments

Hold or exclude open disputes according to policy. Confirm approved adjustments are represented once and linked to the original entry.

11. Validate buyer price and publisher payout independently

Confirm amount, currency, formula version when applicable, and the separate buyer and publisher decision.

12. Run completeness and duplication checks

Look for missing financial entries, entries without calls, calls without expected entries, duplicate batch membership, orphaned conversions, and totals that do not match their member rows.

13. Review the exception queue

Resolve, defer, or reject each exception under documented approval criteria. Do not let unresolved blocking exceptions disappear from the close report.

14. Approve and freeze

Record the reviewer, approver, included population, excluded population, held population, totals, period, timezone, and control results.

15. Generate invoice and payout batches from the frozen population

Batch generation should consume the approved records. It should not re-evaluate mutable campaign settings and produce a different answer.

16. Reconcile batch totals to member records

The buyer invoice total should equal the sum of included buyer-price entries. The publisher payout total should equal the sum of included publisher-payout entries. Any mismatch should fail the close.

This process is the operational layer beneath finance-grade pay-per-call reconciliation.

Hypothetical validation examples

The following examples are simplified and hypothetical. The amounts, thresholds, windows, and rules are illustrations, not benchmarks or recommendations.

Example 1: Billable and payable

A consumer-initiated inbound call routes to an eligible buyer target during the approved schedule. The correct buyer leg connects. The canonical connected duration exceeds both the buyer threshold and publisher threshold. The caller is not a duplicate. There is no open dispute, and the record has not settled before.

Decision:

• Buyer: billable.
• Publisher: payable.
• Action: include in both approved populations.

Example 2: Billable but not yet payable

A call meets the buyer’s duration and eligibility rules. The publisher payout rule requires an additional source attribute that is missing from the intake record. The source appears approved, but the operator cannot prove the sub-source attribution before close.

Decision:

• Buyer: billable, assuming the buyer rule is independently satisfied.
• Publisher: hold, not automatically rejected.
• Action: include on the buyer side only if approved policy allows separate settlement; place the publisher side in an exception queue with an evidence deadline.

Example 3: CPA event arrives after close

A call occurs during Period A. The buyer reports the agreed CPA conversion after Period A has been frozen.

Decision:

• Buyer and publisher treatment depends on the written attribution and close policy.
• Action: do not silently reopen Period A. Create a linked late-conversion or adjustment record for the permitted later period.

Example 4: Duplicate terminal event

The provider sends the same terminal callback twice. Both events contain the same provider call ID and terminal status.

Decision:

• The second event is a delivery duplicate, not a second call.
• Action: process idempotently and preserve one financial result.

Example 5: Buyer disposition conflicts with the contract

A duration-qualified call is marked “no sale” in the buyer CRM. The campaign pays for the qualified call opportunity, not a downstream sale.

Decision:

• Buyer: remains billable unless another valid rule applies.
• Publisher: remains payable under its rule.
• Action: keep the disposition for performance analysis, but do not rewrite the settlement model after the call.

Approval criteria for closing a batch

A batch should not close merely because the total looks reasonable.

A stronger approval standard asks whether:

• Every included line has a canonical identifier.
• Every included line has valid partner and campaign attribution.
• The call path supports the required connection state.
• Duration or CPA evidence is complete and reproducible.
• The route-time terms are preserved.
• Eligibility and duplicate rules were applied consistently.
• Buyer feedback was mapped under written rules.
• Blocking exceptions are resolved or formally deferred.
• Open disputes are handled under policy.
• Previously settled records are excluded.
• Buyer price and publisher payout are independently supported.
• Period and timezone rules were applied consistently.
• Batch membership is unique.
• Member amounts sum exactly to the batch total.
• The reviewed population is frozen.
• Reviewer and approver actions are recorded.
• The operation can explain why each line was included, excluded, held, or adjusted.

A clean close report should show counts and amounts for each outcome:

• Included.
• Excluded.
• Held.
• Disputed.
• Adjusted.
• Late-arriving.
• Previously settled.
• Failed validation.

Record retention and privacy need deliberate boundaries

Pre-billing validation depends on evidence, but “keep everything forever” is not a safe policy.

Call records can include phone numbers, recordings, transcripts, intake data, and partner information. Retention should be based on applicable law, contract, dispute windows, accounting needs, security controls, and advice from qualified counsel.

Do not assume a provider dashboard is permanent storage. Twilio’s Call resource documentation currently states that standard Call resources can be retrieved through the Calls endpoint for 13 months, with older records available through Bulk Export. Provider policies can change, and different record types may have different retention behavior.

The operational lesson is narrow:

• Identify the evidence needed to support settlement.
• Store only what the operation is authorized to retain.
• Restrict access by role.
• Avoid putting caller data or recording links into broad exports.
• Preserve stable identifiers and decision records even when sensitive evidence has a shorter retention schedule.
• Review provider retention and export behavior rather than discovering a gap during a dispute.

What Dependable Calls is being built around

Dependable Calls is a beta-stage, operator-led exchange being built around explainable call and financial records.

The current software implementation supports route-time financial snapshots, separate buyer-revenue and publisher-payout ledger entries, duration-based qualification, invoice and payout batch generation, batch approval, exports, adjustments, and reconciliation controls.

Automated tests and operating documentation cover important ledger-to-batch invariants, inclusive duration boundaries, duplicate-event safety, and mismatch detection. Buyer invoice views are represented in the portal code.

Those facts do not prove that every finance workflow is fully mature, exposed in every portal, or used at production scale.

A complete operator-facing pre-billing exception queue and every late-event scenario should be judged separately from the existence of core finance code. CPA reversal timing, population completeness, live operating use, publisher payout workflow maturity, and additional hardening remain subject to continued validation.

The direction is clear:

• Preserve route-time terms.
• Separate buyer price from publisher payout.
• Treat retries safely.
• Keep billable and payable decisions distinct.
• Reconcile batch totals to call-level records.
• Record disputes and adjustments without rewriting history.
• Give each partner enough scoped information to understand its side.

Pre-billing validation is where those principles become a financial control rather than a reporting slogan.

Need cleaner call settlement? Talk with Dependable Calls about buyer or publisher workflows.