IOSOR

IOSOR Learn

Template unit class on debit rows

Every prepaid debit row must carry a named unit class — template, session, segment, or verify — so finance can join spend without folklore spreadsheets.

A settled debit without a unit class is money with no product story. Finance cannot tell template sends from session units, SMS segments, or verify attempts — recon becomes Slack archaeology. This page is the ledger label contract: every production debit row carries the same unit class product mapped on the catalog — not a session-window pricing essay.

Related: Template review gate and unit class, Debit rows vs delivery status ledger, Fraud burn rows on the prepaid ledger.

IOSOR is white-label prepaid. USD 20 funds a pilot that proves one corridor’s debit rows carry unit class; soft review near USD 1,000/month prices blank or mismatched class as recon debt. Clients see white-label money macros only.

Unit class is a ledger field, not a chat note

Product may say “OTP template” in a thread; finance needs a filterable field: unit class, template ID (when applicable), amount, correlation ID, UTC timestamp. Chat pins are not the ledger of record. Soft USD 1,000/month treats “we know which class it was” as volume debt; USD 20 proves blank class never settles. Happy-path money↔outcome: Debit rows vs delivery status ledger — this page owns class labeling, not DLR lag.

Named classes finance can filter

Unit class Typical send What finance expects
Template unit Approved outbound template Per-send template debit + template ID
Session unit User-initiated window traffic Session-class debit, not template folklore
SMS segment Templated or plain SMS Segment × list; class still named
Verify attempt OTP / code check Attempt or verify row — not “misc messaging”
Other / named Explicit annex only Owner + policy ID before volume language

Review gate maps class before send: Template review gate and unit class. Wrong class turns OTP spend into unreadable misc. Burn and blocked attempts stay visible beside settled rows: Fraud burn rows on the prepaid ledger.

Join catalog truth to every debit

Catalog holds template ID, review state, and unit class. Debit row must join those fields for the same UTC window. Version bumps re-enter Approved; a bumped ID does not inherit yesterday’s class silently. Retire stops production debit under the old ID. Missing join columns force morning recon tickets.

Blank or mismatched class fails closed

Missing unit class → no production settle. Class on debit ≠ class on catalog → fail closed or hold release with honest status — never silent rewrite into another class. Unknown template ID → no settle. Soft USD 1,000/month makes class mismatches exportable; USD 20 proves one corridor where blank class cannot debit.

Buyer checklist for unit class on debit rows

  1. Every settled production debit carries a named unit class?
  2. Template sends include template ID + template unit (or mapped segment) finance can join?

Start with IOSOR

Open the IOSOR console ledger configuration and enable strict schema gating for all outbound messaging debit entries. Set any transaction missing an explicit unit class or catalog template ID to fail closed immediately, placing unclassified traffic into a hold state before financial settlement. Configure your reporting webhooks to emit real-time alerts whenever a debit class deviates from the approved catalog definition.

IOSOR takeaway

Financial reconciliation depends on treating the unit class as an immutable ledger field rather than an informal support note. Every settled debit row must join catalog truth—including template IDs, version states, and message types—so finance teams can cleanly audit template traffic against session and segment usage.

Was this guide helpful?

Related guides