IOSOR

IOSOR Learn

Segment accounting: why one SMS is not one spend line

A pricing guide to SMS segment accounting — GSM-7 vs UCS-2 encoding, multipart concatenation overhead, and how to reconcile every send against the prepaid wallet without guesswork.

A user typed one message. The prepaid wallet debited three units. That gap is not a bug — it is segment accounting, and finance teams that do not understand GSM-7 vs UCS-2 and multipart concatenation will file support tickets against a billing engine that is working exactly as designed.

IOSOR treats every SMS spend line as reconstructable to segment count, encoding, and destination — not an opaque platform fee. Near USD 1,000+ monthly platform usage, segment discipline is the difference between a clean monthly reconciliation and a recurring "why did this cost more" escalation.

Why one SMS is not one spend line

What the sender sees What the wallet sees
"I sent one text" 1–3 billed units depending on encoding and length
One emoji added at the end The whole message flips to UCS-2
A template variable a few characters longer The message crosses a segment boundary

GSM-7 vs UCS-2: why the character set changes the math

  • GSM-7 covers a limited Latin alphabet and a small symbol set; each character costs less "budget" per segment
  • UCS-2 (any character outside GSM-7 — emoji, most non-Latin scripts, some punctuation) forces the whole message into a wider encoding with a lower per-segment character limit
  • One "invisible" character (a smart quote pasted from a document, a checkmark, an emoji) can silently flip the whole message from GSM-7 to UCS-2

Multipart segmentation and concatenation overhead

Encoding Single-segment limit Multipart segment limit Why multipart is smaller
GSM-7 160 chars 153 chars Concatenation header reserves space
UCS-2 70 chars 67 chars Same header, smaller alphabet budget

Crossing the single-segment limit does not "round up" gracefully — the message splits into multiple segments, each carrying concatenation overhead, and rebills accordingly.

Where segment counts hide

  • A composer preview showing "1 message" while the actual encoding produces 2–3 billed segments
  • Template variables that push length over a boundary only for some recipients
  • Locale-specific characters (accents, non-Latin scripts) that pass QA in one language and multiply cost in another

Red flags

  • Composer or API response reporting message count instead of segment count
  • No visibility into which encoding was used for a specific send
  • Support says "encoding issues are rare, don't worry about it"
  • Ledger rows that cannot be traced back to length, encoding, and destination
  • Bulk sends billed as a flat estimate reconciled only at month-end

Start with IOSOR

Review your outbound template payloads in the IOSOR console before triggering large dispatches. Configure API validation gates to flag any payload that exceeds a single segment or unexpectedly shifts from GSM-7 to UCS-2 encoding. Ensure your delivery report webhooks explicitly tie balance deductions back to exact billed segment counts rather than generic message counts.

IOSOR takeaway

A single outbound text message rarely translates into a single spend line. The choice between GSM-7 and UCS-2 encodings, combined with the header overhead of multipart concatenation, means a slight variation in dynamic text or a single special character can easily double your billing per recipient.

Do enforce strict character encoding checks and template length limits at the dispatch composer level. Don't rely on high-level message-count previews or untraceable ledger rows that mask encoding flips and multi-segment billing penalties.

Was this guide helpful?

Related guides