IOSOR

IOSOR Learn

Debit rows vs delivery status on the same ledger

Correlate each prepaid unit debit with DLR or channel outcome on one wallet ledger so finance never treats a sent badge as free money or a free failure as a silent write-off.

A sent badge is not a free lunch. On prepaid, every billable unit leaves a debit row finance can join to an outcome — delivered, failed, undelivered, accepted, connected, or needs attention — without screenshots. Separate debit and delivery silos invent “free sends” and silent write-offs at close.

IOSOR is white-label prepaid: one wallet across messaging, verification, email, voice, and JIT number intents. USD 20 funds a pilot that must prove ledger honesty; soft review near USD 1,000/month only makes mismatches louder. Narrow siblings: SMS segment accounting for segment math; DLR failed retry policy under prepaid for retry timing. Here: wallet-wide money↔outcome join.

Sent is not free money truth

“Accepted by the network” is a product event, not a balance gift. Settled units show amount, currency, channel, and intent ID. Non-billable units leave no settled debit — or an explicit release/refund. Treating sent as free while money moved is a finance lie; treating failed as free while a debit stayed settled is the opposite.

Happy path: Prepaid hold before first debit. Fail path: Hold fail auto-refund and status truth. Correlation between them: one row that still reads after DLR lag.

One row needs debit + outcome fields

One joinable row per billable intent:

Field Why
Intent / correlation ID Join wallet and product
Debit amount + currency Prove money moved once
Channel + unit type SMS ≠ voice ≠ verify units
Outcome / DLR status Delivered, failed, pending, needs attention
Outcome timestamp Lag visible; second debit blocked
Idempotency key Retries reuse money — idempotency, retries, and money

Separate money and DLR CSVs without a shared key force invented joins. Prefer one export with both.

DLR and status lag without double charge

Outcomes arrive late. Pending after settle is normal; a second charge for the same key is not. Settle once under the hold, update outcome in place, never open a parallel debit because a DLR flipped. Retries under one key show one money move and many status transitions.

When fail is final, keep the settled debit with a failed outcome (billable attempt) or release/refund when never owed — never settled debit with a fake Delivered badge. Lag belongs in timestamps, not duplicate rows.

Channel outcomes are not interchangeable

Messaging DLR ≠ email accept ≠ verify success ≠ voice connect. Copying “Delivered” onto every channel hides burn and breaks caps. Keep outcome vocabularies per channel while sharing money columns. Segment detail stays in the SMS article; wallet export needs charged unit and channel-native outcome.

Buyer checklist for ledger honesty

  1. Can finance join every settled debit to an outcome without ops?
  2. Does a late DLR update the same row instead of a second debit?

Start with IOSOR

Pick one SMS unit. Hold, settle the prepaid debit, then require the terminal DLR on that same ledger row. Export one line: debit amount, DLR status, timestamps. A debit without DLR — or a DLR without debit — stays an incident. This is money versus receipt on one row, not CRM hygiene and not an alert handover.

IOSOR takeaway

One ledger row holds debit and DLR, or finance cannot close the send.

Do: join debit to terminal DLR on the same row and keep unmatched rows open.

Don't: treat sent as settled, or close the month from chat while rows lack a receipt.

Was this guide helpful?

Related guides