A2P SMS Billing Reconciliation: CDRs, DLRs and Invoices Without False Equivalences

What problem does A2P SMS billing reconciliation solve?

A2P SMS billing reconciliation makes it possible to verify whether a provider’s charges can be explained through traceable operational evidence. Its purpose is not to turn a delivery metric into an automatic financial decision, but to compare record sets, identify discrepancies and apply the agreed commercial rule for the route and provider.

This function should involve operations, wholesale, vendor management and finance. Finance can control amounts, periods and approvals, but it will not usually have the context needed to interpret identifiers, retries, routes, segments, error codes or late statuses on its own.

The central principle is simple: technical acceptance, provider CDRs, DLRs and observed handset receipt are different signals. Sound reconciliation preserves that distinction instead of summarizing all events under a single “delivered” or “billable” label.

• Do not use a DLR as a universal billing rule.
• Do not treat the absence of a DLR as automatic proof of failure or non-billability.
• Do not discuss discrepancies using aggregate totals alone when message identifiers exist.
• Apply the documented contractual rule before calculating adjustments or accepting charges.

The four sources of evidence that must be compared

Reproducible reconciliation starts with separate source records. Each source answers a different question and has different limitations. The internal record confirms what your platform attempted to send; the acceptance response indicates how the provider or SMSC responded to the submission; the CDR supports the set reported by the provider; and the DLR provides a subsequent technical status when it has been requested and received.

In SMPP, submit_sm_resp is the response to submit_sm and may include the message identifier assigned by the SMSC. Delivery receipts are returned later through deliver_sm or data_sm. This sequence matters: receiving an acceptance does not mean a final status is available, and having a final status does not replace the agreed billing rule.

• Internal send record: own ID, original destination, payload or content reference, sender, intended route, timestamp and local outcome.
• Acceptance response: response code, provider or SMSC ID where available, and receipt timestamp.
• CDR or equivalent extract: records, fields, period and criteria provided by the provider.
• DLR or status: original value, normalized status, error code, available network evidence, and submit and final timestamps where received.

DLRs, acceptance and receipt: what each signal proves

Technical acceptance shows that the receiving system accepted or responded to the submission attempt according to the interface in use. It does not, on its own, prove delivery to a device or reading by a person. The exact scope of that acceptance must be interpreted according to the applicable integration and operational agreement.

A DLR represents a subsequent event reported by the messaging chain. The SMPP standard includes receipt statuses and formats, including provider-specific formats. In addition, the technical specification distinguishes reports issued by the Service Centre from those issued by the mobile station: a report from the Service Centre may confirm receipt by that centre, whereas one issued by the mobile station confirms receipt by the device, not human reading.

Observed receipt on a handset can be additional evidence in controlled tests, but it must not automatically be confused with reading, consent, identity or a billing obligation. The billing basis is not determined by the general semantics of a DLR: it must be expressly defined in the contract or operational agreement for each provider and route.

• Acceptance: evidence of a response to the technical submission of a message.
• DLR: evidence of a reported status; preserve its original value and context.
• Handset receipt: may demonstrate technical receipt in testing, not human reading.
• Billing: the result of a documented commercial rule, not an isolated technical label.

Define the reconcilable unit before comparing

The reconciliation object must be defined before traffic begins or before the next billing cycle. If one party compares logical messages and the other compares technical segments, a discrepancy may be apparent rather than a billing error. Concatenation requires an explicit decision on the unit of comparison and settlement.

SMPP includes fields for identifying concatenated messages, including a reference number, the total number of segments and the sequence of each segment. Retain these fields when available and link each segment to the relevant logical message without substituting one for the other.

Correlation must not depend solely on time or arrival order. SMPP allows out-of-sequence responses. Therefore, the internal identifier and the identifier returned by the provider or SMSC should be the primary keys where available, with supplementary attributes used to resolve incomplete cases.

• Immutable internal ID for the send attempt.
• Provider- or SMSC-assigned ID, when received.
• Original destination and normalized destination in accordance with a documented policy.
• Internal send timestamp, acceptance timestamp, provider submit timestamp and final-status timestamp, including time zone and precision.
• Provider, route or commercial reference applicable at the time of sending.
• Sender, traffic type and content reference where needed for investigation.
• Segmentation data and relationship to the logical message.
• Original status, error code and available network-evidence fields.

Agree billing rules and data exchange

The SMPP specification defines technical mechanisms for sending, responses, identifiers and statuses, but it does not define which event is billable. Therefore, every provider relationship must have a commercial and operational rule stating the billed unit, the reference event and how exceptions are handled.

The rule should be associated with the applicable route or product. If an organization uses multiple providers or routes, it should not transfer a reconciliation policy from one relationship to another without validation. Versioning the rules is also advisable so that the rule in force at the time of traffic can be applied.

The data-exchange agreement should prevent ambiguities that emerge at closing: column semantics, identifier formats, time zone, cut-off period, CDR delivery frequency and the window for late statuses.

• Billing unit: segment, logical message or another expressly agreed unit.
• Reference event for charging and treatment of rejections, retries and adjustments.
• CDR schema, file types or interface, encoding and the meaning of each field.
• Correlation keys and priority rules between identifiers.
• Time zone, temporal precision, cut-off period and CDR availability date.
• Window for late DLRs and a reopening or adjustment procedure.
• People responsible for investigation, approval, disputes and recording resolutions.

Build a status model that supports reconciliation

Statuses should be retained at two levels. The first is the original value received from the provider, together with the error code and any additional available evidence. The second is an internally defined category used to operate reconciliation. This normalization makes it possible to compare providers without destroying information needed to review specific cases.

Avoid using an internal category as if it were a universal statement about delivery or billing. A technical status may be useful for classifying a case, but the decision to charge, credit or investigate depends on the agreed policy and available evidence.

The absence of a DLR should be recorded as a lack of status evidence under the specific sending conditions. In SMPP, receipt return depends on what was requested through registered_delivery, and the content may vary by provider. Therefore, a missing DLR does not automatically mean non-delivery or an automatic adjustment.

• Technically accepted.
• Rejected in the submit response, if that event is recorded.
• Final status reported by the provider or SMSC.
• Intermediate or non-final status, where received.
• No DLR available within the agreed window.
• Insufficient correlation.
• Pending investigation or commercial resolution.

Step-by-step process for reconciling CDRs, statuses and invoices

The process should be performed on a working copy without altering the original records. First, ingest internal events, acceptance responses, DLRs and the provider’s CDR. Then validate the schema, log the received files or extracts and preserve their provenance.

Normalization is applied in a versioned manner: destinations, time zones, status names and identifier formats. Next, correlate using strong keys as a priority, especially the internal ID and provider ID. Matches based on secondary attributes should be marked accordingly and remain reviewable.

Only after comparable sets have been identified should the current commercial rule be applied. The result is not merely a balance: it should include classified discrepancies, available evidence, the owner and the next step.

• 1. Close the reference period according to the agreed calendar.
• 2. Ingest and retain sources without modification: internal events, responses, DLRs, CDRs and invoice.
• 3. Validate integrity: mandatory fields, duplicate files, time zone and covered period.
• 4. Apply versioned normalization to identifiers, destinations, timestamps and statuses.
• 5. Correlate using IDs; use secondary attributes only as support and flag the confidence level.
• 6. Group by provider, route, period and agreed billing unit.
• 7. Classify discrepancies and apply the contractual policy.
• 8. Perform operational review, financial approval and record adjustments or disputes.

Common discrepancies and how to handle them

Duplicate records require distinguishing between an event repeated in an export, a legitimate resend and two separate attempts. Do not remove duplicates just because they share a destination or content. Review identifiers, timestamps, route and the relationship between the original submit and any retry.

Concatenation can create discrepancies when one side counts segments and the other groups by logical message. The solution is not to force a later equivalence, but to reconstruct the relationship between segments and the logical message and apply the unit defined in the agreement.

Timing differences can arise because events occur at different moments: internal send, acceptance, submit, final status and billing cut-off. Final DLRs may arrive after the initial close. It is necessary to separate the traffic period from the evidence-availability period and use the agreed adjustment window.

Rejections, late statuses and missing records must be kept as distinct categories. A record missing from the CDR is not the same as a technical rejection; a late DLR is not the same as a non-existent DLR; and a reported status does not replace the provider’s billed record.

• Duplicates: review event identity, retries and repeated exports.
• Concatenation: compare the technical unit and the agreed commercial unit.
• Timestamps: retain the event, time zone, precision and data-receipt date.
• Late statuses: apply the agreed window before definitively closing the investigation.
• Rejections: distinguish a submit rejection from a later final status.
• Missing records: open an exception with searchable keys and a verifiable period.