A2P SMS Billable Segment Discrepancies: A Reconciliation Guide

Why the same send can show different counts

A discrepancy does not by itself prove that there is a billing error. The application may estimate segments before sending; the interface may accept or transform the request; the provider may record each attempt or processed unit; and the usage record may apply the agreed rules for counting it. Do not assume that all these systems count the same thing.

The available evidence does not establish a universal calculation, accounting, or correlation rule that applies to all providers. Reconciliation should therefore start with each system’s data and the relevant contractual terms. Consult technical specifications and provider documentation to confirm specific details.

• Treat each count as a data point whose meaning needs to be confirmed.
• Separate differences in calculation, acceptance, transmission, retries, and accounting.
• Do not infer the billable amount from delivery status alone.

Define the reconciliation unit before comparing

Before adding up segments, agree on what each row in each system represents. A logical message is the original application request. A sent segment is a unit resulting from the encoding and format used at a particular stage. An attempt is a sending operation, which may be repeated. A billable record is the unit the provider counts under the applicable terms.

These categories are not interchangeable. If you compare the application’s total logical messages with a provider’s number of attempts, the figures may differ even when every record was generated correctly. Ask each party to define its fields and explain how it aggregates rows.

• Record totals for logical messages, segments, attempts, and usage records separately.
• Clarify whether an identifier is retained across retries and whether a row represents a request or a counted unit.
• Confirm the reporting period and time zone for each report before comparing totals.

Which fields to compare at each stage

Build a record-level table showing the available fields and where they came from. At a minimum, try to retain the request ID, the message ID assigned by the platform or provider, the normalized destination, the timestamp, and the status recorded at that stage. Add the original text and any transformed representation if storing them securely is permitted.

To review encoding, record available metadata such as the declared character set and the length before and after transformation. To investigate concatenation, request the part IDs or references that the system actually exposes. Field availability and meaning vary; do not assume these fields exist or interpret their absence as proof that no transformation occurred.

• Store timestamps with their time zones and preserve the system’s original timestamp.
• Compare destinations in a normalized format without discarding the received value.
• Record length, encoding, and concatenation references only when the platform provides them.
• Protect message content and destination data in accordance with applicable privacy and retention policies.

Separate encoding and concatenation from duplicates and retries

A difference in segment count may arise from how each stage calculates or represents the message. Encoding and concatenation are factors worth checking in the records, but do not apply thresholds or counting rules without specific technical documentation for the relevant mode and system. Confirm what text each stage received and which encoding each record declares.

Duplicates and retries require a different investigation: look for repeated requests, different IDs associated with the same operation, and timestamps close together. Similarity in text and destination can help identify candidates, but it is not enough to declare two rows duplicates; they may represent separate, legitimate sends. Also verify whether the application or platform retried a request and what response it received before retrying.

• First identify whether the content or its encoding changed; then check for repeated requests and attempts.
• Use IDs and event sequence as evidence, not just matching text and destination.
• Consult primary technical documentation and provider terms before attributing a difference to concatenation or a billing rule.

Build a traceable sample and reconcile the records

Start with a defined, limited sample period and keep the original exports from each system. Include both matching and discrepant cases: matching cases help validate correlation, while discrepancies can reveal patterns without assuming that every difference has the same cause.

Align rows by a shared ID when one exists. If there is none, use a documented combination of destination, time, and other available fields to suggest matches, marking them as tentative. Do not treat an approximate match as an unambiguous link. Summarize matched, unmatched, and multiply matched rows separately.

Compare totals only after classifying the rows. For each difference, record the source system, the unit represented, the evidence observed, the explanation confirmed or still pending, and the person responsible for resolving it.

• Define the period, systems included, and time zone before extracting data.
• Keep an unchanged copy of the original files and document any transformations.
• Classify exact matches, tentative matches, confirmed duplicates, and unmatched records.
• Calculate totals by unit type rather than as one aggregated figure.

Incomplete, late, or ambiguously matched records

An export may be incomplete, include events added late, or lack a shared ID. In these cases, leave the difference pending and request the missing details from the system owner. Do not fill missing fields with inferred values or close a discrepancy based only on an approximate time-based correlation.

Agree on a waiting window and cutoff date with the parties, based on their processes and contractual terms; the available evidence does not support a universal timeframe. If a record appears after the cutoff, note when it was received and check whether it changes the reconciliation. Escalate unmatched cases if they could affect the financial outcome or reveal an operational issue.

• Keep explicit categories for late records and incomplete data.
• Request expanded exports or correlation fields if available.
• Document uncertainty and avoid assigning a definitive charge to a row without sufficient evidence.

Document exceptions and agree on rules with the provider

Recurring reconciliation works better when both parties agree in writing on what each field represents, which IDs are retained, how retries are interpreted, and which records support counted usage. The agreement should reflect the contract and the actual capabilities of the platforms involved; do not assume all providers expose the same details.

For each exception, keep the period, available IDs, observed difference, evidence requested and received, conclusion, and any outstanding action. If no verifiable explanation is reached, record the discrepancy as unresolved and use the review process set out in the commercial agreement.

• Agree on definitions for message, segment, attempt, and counted record.
• Specify correlation fields, export format, and how time zones are handled.
• Define the inquiry, response-time, and escalation processes in accordance with the current agreement.
• Do not turn a probable explanation into a general rule without documentary confirmation.

Checklist for resolving a discrepancy

A sound resolution explains what was compared, what evidence supports the conclusion, and what uncertainties remain. Reported delivery status—including a DLR—must be kept separate from the usage record and the contractual accounting rule. The available information does not establish that a DLR alone proves a charge or determines the billable unit.

If the discrepancy cannot be resolved from the available records, the right outcome is to document it as pending, not to infer a cause. The checks below help close only cases with sufficient traceability.

• Was it agreed whether the comparison is by logical message, segment, attempt, or usage record?
• Were the period, time zone, and integrity of the exports confirmed?
• Is there a shared ID, or is the match clearly marked as tentative?
• Were content, encoding, and part references reviewed using data that was actually available?
• Were confirmed duplicates distinguished from legitimate repeated requests and retries?
• Is the conclusion supported by records and applicable terms, without using the DLR as proof of billing?
• Were exceptions, uncertainties, and outstanding actions documented?