A2P SMS Operational Reconciliation: A Guide to Resolving Discrepancies
A useful reconciliation process separates requests, status events, and billing data. Learn how to match records, classify differences, and document disputes without assuming that a DLR proves receipt on the handset.
What the process reconciles and why differences arise
Operational reconciliation compares three perspectives that do not necessarily describe the same event: the request recorded by your platform, the status events reported by the provider, and the line items or totals presented for billing. The goal is to explain each difference with evidence and an agreed rule, not to force every system to show identical counts.
Before comparing figures, establish what question each dataset answers. A request accepted by an interface does not, by itself, mean a message was delivered; a status reported by a provider is an event in that provider’s system; and a billed amount must be reviewed against the applicable contract and billing detail. Do not use a DLR as independent proof of receipt on the handset or as an automatic billing criterion.
- Define the scope: accounts, routes, destinations, traffic, currency, and included period.
- Specify whether you are comparing requests, accepted messages, events, billable units, or amounts; do not mix these metrics.
- Document contractual billing rules separately from operational status rules.
Which sources to keep and how to assess their usefulness
Keep a dated, unmodified copy of the records used in the comparison. The exact list depends on the interfaces and formats the parties provide; the available evidence does not support prescribing universal CDR or DLR fields for every A2P environment.
At a minimum, inventory what data you can obtain from each system, who generates it, when it is exported, and what period it covers. Also record the file or report version and any transformations applied before comparison. If a source lacks a common message identifier, note this as a limitation instead of inferring a reliable match.
- Platform: recorded requests and responses, plus the identifiers the system actually exposes.
- Provider: available traffic records and status events, with their stated definitions and timestamps.
- Billing: the invoice and available supporting detail, service period, and agreed charging criteria.
- Rejections and retries: keep them distinct when the system records them; do not automatically treat them as billable or delivered messages.
- Traceability: keep the extraction date, stated time zone, source, owner, and file integrity checks.
Define identifiers and matching rules before counting
Establish a correlation hierarchy using only identifiers present in the systems involved. A platform-specific identifier and one assigned by the provider may refer to the same flow only if a documented link exists between them. Store that link explicitly when the integration provides it.
If there is no common key, define a provisional matching rule and label its results as probable matches, not confirmed facts. Combining recipient, time, or other attributes can produce collisions, and the available evidence provides no universal rule that guarantees a correct match. Avoid deduplicating records simply because they look similar.
- Prioritize a shared message identifier or a verifiable mapping table.
- Keep the request identifier, provider-assigned identifier, and event identifier separate, if they exist.
- Define how to handle retries, concatenated message parts, and repeated records according to your systems’ actual definitions and contract.
- Assign each match a confidence status—confirmed, probable, or unresolved—and keep the reason.
Align periods, time zones, and late events
Before comparing records, agree on a working time zone and also retain each record’s original value and time zone when available. Do not convert timestamps without documenting the transformation. If systems do not specify a time zone, treat that omission as a limitation to resolve with the source owner.
Distinguish the event date, record date, and billing period: they may not match. Define a close window and a follow-up review procedure for events that appear after the cutoff, but do not impose a universal duration; it should be agreed with the parties and adjusted to observed latency and contractual terms.
- Specify the period’s start and end, boundary convention, and common time zone.
- Record the send date, status date, and billing entry or line date separately if each source provides them.
- Mark messages without a final status as pending review, not as delivered or failed by default.
- Define how to reopen a period when late data arrives and how to document subsequent adjustments.
Classify discrepancies without presuming their cause
A shared taxonomy prevents each team from explaining the same case differently. First classify what is observable and treat the cause as a hypothesis until there is sufficient evidence. For example, a difference in quantity does not, by itself, prove a billing error: it may reflect different periods, counting units, retries, or incomplete information.
Keep technical diagnosis separate from the financial decision. An investigation can establish which records match and which events are missing; applying a charge, credit, or adjustment must follow the contract and internal approval controls.
- Missing: a record is present in one source but cannot be found in another.
- Possible duplicate: multiple rows may represent the same message or event; verify each system’s keys and rules.
- Different quantity: compare the unit definition, scope, period, and treatment of retries.
- Incompatible status: preserve the status as reported by each source and request the applicable technical definition.
- Misaligned period: identify differences in time zone, cutoff, or the date used to assign the record.
- No final status: leave the case pending and record what evidence is missing.
Request evidence and document the dispute
Open a dispute with a focused set of reproducible cases, not just an aggregate total. For each case, state the period, the reference that allows it to be located, the observed difference, the rule applied, and the specific response you need from the other party.
Request the definitions of relevant statuses and fields, the detail supporting the disputed count or charge, and an explanation of differences in period or unit. A DLR is a status reported within the available flow; on its own, it is not independent verification that the message was displayed or received on the handset. Nor does it automatically determine whether the message should be billed.
- Attach correlatable references and a representative sample of cases, protecting data in line with your applicable policies and obligations.
- Ask for clarification on the record’s origin, the meaning of the status, and the period to which it was assigned.
- Separate confirmed facts, inferences, and open questions.
- Record the opening date, participants, responses, exchanged files, and conclusion for each case.
- Link any approved adjustment to the dispute and the contractual rule supporting it.
Assign owners, timelines, and approvals
Reconciliation works best when each phase has an explicit owner. Operations can prepare the matching and explain events; the technical team can clarify identifiers or exports; finance can validate amounts and periods; and the commercial or contract owner can interpret the applicable terms. Adapt this division to your organization, and do not assume that a single team can validate every aspect.
Agree on internal timelines for extracting data, reviewing differences, and escalating cases; no universal timeline is supported here. Also define who can approve adjustments and who confirms closure. The audit trail should make it possible to reconstruct what data was compared, which rule was used, who made the decision, and when.
- Name a reconciliation owner and a deputy.
- Assign source owners to resolve questions about exports and status semantics.
- Set review and escalation milestones in line with the contract and internal controls.
- Require appropriate approval before recording credits, corrected charges, or other adjustments.
- Keep the final outcome and its rationale with the source evidence.
Checklist for implementing and reviewing the process
Start with a trial period and a limited scope. Validate that the sources can be obtained, that matching rules produce reviewable results, and that exceptions have an owner. Expand the process only when you can explain its limitations and retain enough evidence to repeat the analysis.
Review definitions and agreements regularly: changes to exports, identifiers, billing criteria, or schedules can invalidate a previous reconciliation. This guide helps organize the work; it does not replace the parties’ technical specifications or contractual terms.
- Is it clear what is being reconciled and which unit is being counted?
- Are the original sources and their extraction metadata retained?
- Are matching keys and deduplication documented and reproducible?
- Are time zones, cutoffs, and late events distinguished?
- Do cases without a final status and uncertain matches remain visible?
- Does every discrepancy have a category, owner, evidence, and resolution?
- Are charges and adjustments decided according to the applicable agreement, not solely on the basis of a delivery status?
- Can another person review the close later using the same records and rules?
Frequently asked questions
Does a DLR prove that the message reached the handset?
It should not be treated as independent verification of receipt on the handset. It is a status reported within the available flow, and its meaning should be confirmed against the source documentation.
Does a DLR automatically determine whether a message is billable?
No. Billing must be reviewed against the available detail and applicable contractual terms; a status alone does not automatically establish a charge.
Which identifier should I use to match records?
First use a shared identifier or a documented mapping between systems. If neither exists, define a provisional rule, mark the match as uncertain, and do not deduplicate based on similarity alone.
What should I do with messages that have no final status at close?
Keep them in a pending category, record what information is missing, and apply an agreed follow-up review rule. Do not classify them as delivered or failed by default.
Sources consulted
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA
- Resolución de discrepancias durante la comparación de facturasMicrosoft Learn